@rudi86

Ja, FUP habe ich mir angeschaut, aber das hat mich für den Anfang etwas erschrocken. Mit ST habe ich das Gefühl, mehr Kontrolle über den Code zu haben.

Aber ich habe ja noch einige Programmteile zu bauen, vielleicht schaue ich mir das noch mal an.

Habe mittlerweile auch das zyklische Senden nach Timeout oder bei Werte-Aktualisierung hinbekommen. Die Basisadresse für das eine verbleibende RPDO ist auch 0x1C0. Wenn man vom
„Fake“-Knoten 15 senden möchte also 0x1CF.

Mehr Schwierigkeiten sind mit derzeit nicht über den Weg gelaufen, bin hauptsächlich damit beschäftigt, den Code einigermaßen schön zu machen und meine ganzen Debug-Nachrichten und Haltepunkte zu entfernen

@Rudi86: nochmals herzlichen Dank, ohne deine Hilfe wäre ich nicht so weit gekommen!

@rudi86

Ich habe erst vor ein paar Wochen auf Hobby-Ebene damit angefangen. Ich muss Daten von einem Wechselrichter abholen und zur Steuerung eines Heizstabs verwenden. Die CMI ist einfach zu unflexibel, da man dort nur einzelne ModBus-Register auslesen kann
Ich habe eine alte Wago SPS im Einsatz. Die 750-8204 kann CAN-Bus und Modbus RTU. Modbus TCP kann man einfach über einen der Ethernet-Porta nutzen, grandios. Bleiben halt die nicht unerheblichen Kosten für die Codesys-Runtime aber ich habe am Ende alles in einem Gerät.

Außerdem bringt mich ST zurück in die alten Pascal-Zeiten. Das Abrufen von Daten vom Modbus und weiterleiten auf den CAN-Bus ging fast ohne Code - mit dem neuen Format ist es etwa Arbeit.

An 200 SPSen würde mich allerdings nicht ran wagen - ST-Programmierung lasse ich mir derzeit von ChatGPT beibringen - ich denke, um
mehrere Steuerungen zu kontrollieren, reicht das Halbwissen nicht aus.

Zum Thema: den entscheidenden Hinweis, um Daten senden zu können, hat TA in seiner Antwort geliefert. Meine Ergebnisse:

Schreiben an die alten COB-IDs funktioniert weiterhin. Das halt den Nachteil, dass man nicht 4 Byte nutzen kann.

Das aktivieren des alten Sendeformats via eines Fake-Heartbeats habe ich nicht ausprobiert, da ich gleich einen Schritt weitergegangen bin.

Das Problem war, dass das Senden im neuen Format mit einer COB-ID, die physisch nicht existiert, nicht funktioniert. Also Absende-Node 15 - COB-ID 0x1cf - wird von den existierenden Nodes einfach ignoriert.

Lösung: ich kopiere die Heartbeat-Nachricht des EZ3 einfach mit neuer COB-ID auf den Bus und die CMI zeigt daraufhin einen weiteren EZ3 im CAN-Netz an und nimmt von diesem Fake-Node auch endlich wieder Nachrichten an.

Jetzt muss ich nur noch die Serialisierung des Arrays mit den 64 Daten-Punkten einigermaßen sinnvoll implementieren. Ich denke, ich werde einfach alle 500 ms das ganze Array auf den Bus schreiben, bevor ich jetzt anfange kompliziert auszulesen, welcher Wert, den ich übertragen will, geändert wurde.

Sollte mir dabei noch was irreguläres über den Weg laufen, würde ich es hier dokumentieren. Auf jeden Fall herzlichen Dank für die Zusammenarbeit, das war wirklich hilfreich!

@rudi86

Vielen Dank für deine umfangreiche Antwort und Zeit, die du investiert hast.

Ich habe mittlerweile noch herausgefunden, dass Byte 3 der Typ der Daten ist, der übertragen wird.

Ich bin derzeit noch garnicht soweit, iobroker einzusetzen, da ich die Daten erst auf einer SPS sammle und dort weiterverarbeite und dann Richtung iobroker senden möchte.

Ich konnte deinen Code aber nutzen, um meine Steuerung zu programmieren und das funktioniert hervorragend. Ich kann das serialisierte Array welches von der EZ3 kommt wieder einlesen.

Derzeit versuche ich mich daran, Daten zu senden. Ein RPDO mit exakt gleichem Inhalt (außer geänderter Node ID) zu erzeugen, bzw. zu befüllen, klappt nicht. Da werde ich wohl noch mal auf dem CAN-bus zwischen CMI und EZ3 lauschen müssen. Ggfs. hat es was mit dem ersten Byte zu tun.

Der Support von TA hat mittlerweile geantwortet. Das neue Datenformat geben sie nicht heraus aber man kann wohl das Senden des alten Formats erzwingen, wenn man einen bestimmten Heartbeat sendet:

Zitat:

MSG-ID = 0x700 + Node ID (irgendeine Knotennummer die Sie in Ihrem Netzwerk nicht verwenden)
Frame/Size = 1
Daten = 5

Sobald ich Zeit habe, probiere ich das aus!

Ich melde mich, so bald ich mehr weiß.

@rudi86

Hi Rudi, anbei ein dump mit den CAN-Ausgängen 1 bis 64, die korrespondierend mit den Werten 1 bis 64 belegt sind. Wenn ich die Ausgabe vom TPDO richtig interpretiere, dann zeigt Byte 2 den Ausgang (0-63) und Byte 4 (vermutlich 4 bis 8 ) den Wert an. Das würde meine initiale Vermutung bestätigen, dass nicht mehr jeder Ausgang fix einem TPDO zugeordnet ist, sondern nur noch ein TPDO existiert, dass "bedarfsweise" (nach Wertänderung oder per eingestellter Aktualisierungsrate, z.B. 1 Minute) mit Ausgangsnummer und entsprechenden Wert befüllt und übertragen wird. Das ist natürlich ein netter Trick, um die Übertragung von 4 Byte breiten Werten und faktisch unendlich vielen Ausgängen zu ermöglichen, aber macht jedes Skript kaputt, was auf der vorhergehenden statischen Adressierung beruht.

Von TA habe ich noch keine Antwort erhalten. Ich habe immer noch Hoffnung, dass man das alte Verhalten irgendwie erzwingen kann. Ansonsten muss ich dauerhaft zurück zur 1.29.

can_dump.txt

HINWEIS: Nach Durchsicht ist mir aufgefallen, dass manche Ausgänge nicht oder nicht korrekt belegt waren, das ist kein Fehler im Log. Die Ausgänge sollten eigentlich 1:1 mit dem TA-Ausgang entsprechendem Zahlenwert belegt sein aber scheinbar habe ich da ein paar Fehler eingebaut.

@rudi86 Ich baue mir mal eine „Steuerung“ mit Fixwerten 1-64 für Ausgänge 1-64 und schneide dann den Traffic mit. Wird etwas dauern, ist arg fricklig, selbst mit TAPPS2.

@rudi86 Danke für die schnelle Antwort.

Hier ein Ausschnitt. Leider habe ich nicht mehr alle Werte im Kopf, die ich erwarte, da ich meinen Sniffer erst mal wieder abgebaut habe (Kabel vom Keller eine Etage hoch hat nicht viel Sympathien gefunden). Im Zweifelsfall kann ich natürlich noch mal ein neues Log erzeugen.

Meine beiden Nodes sind 40 (EZ3A) 56 (CMI).

0x1e8 (1C0 + 40) ist die neue Basisadresse - 88 59, gleich in der ersten Nachricht ist ein Spannungswert (Netzspannung in Volt). Es sind noch weitere Ausgänge belegt aber wie man sieht, scheint die neue Firmware die definierten CAN-Ausgänge zyklisch in das PDO zu schreiben. Die Werte sind jetzt INT32, d.h. zwei Werte werden in dem PDO übertragen. Der erste Block scheint irgendeine ID zu sein und der zweite Block enthält den eigentlichen Nutzwert. Meine Hypothese ist, dass die ID zur Zuordnung benutzt wird.

0x678 und 5f8 kann man ignorieren, dass sind SDO requests und responses, weil ich nebenbei auf der CMI via Webinterface unterwegs war.

0x738 und 728 sind die Heartbeats von Node 40 und 56.

Ich habe nebenher auch eine Anfrage bei TA direkt laufen, sollte ich da eine Antwort bekommen, poste ich sie hier.

Experimentiert habe ich auch, ob ich die alten PDOs mit einer RTR-Nachricht triggern kann - hat nicht funktioniert. Ich habe auch die CMI aus dem CAN-Netz genommen, da laut der Release-Notes das neue Format nur verwendet wird, wenn es alle Teilnehmer verstehen - das hat leider auch nicht geholfen. Ich würde vermuten, dass es irgendeinen Schalter für das alte Format gibt, den man per SDO triggern kann aber ohne konkreten Index finde ich das nicht raus.

Nochmals vielen Dank!

11:48:50.165 1 0x1e8 STD Rx 8 02 3F 0D 00 88 59 00 00
11:48:51.258 1 0x678 STD Rx 8 40 E2 57 00 00 00 00 00
11:48:51.258 1 0x5f8 STD Rx 8 41 E2 57 00 0A 00 00 00
11:48:51.258 1 0x678 STD Rx 8 60 00 00 00 00 00 00 00
11:48:51.268 1 0x5f8 STD Rx 8 00 61 DC AD 67 00 00 00
11:48:51.268 1 0x678 STD Rx 8 70 00 00 00 00 00 00 00
11:48:51.268 1 0x5f8 STD Rx 8 19 00 00 00 00 00 00 00
11:48:52.060 1 0x738 STD Rx 1 05
11:48:52.060 1 0x738 STD Rx 8 05 8A 01 01 00 00 00 00
11:48:54.569 1 0x728 STD Rx 1 05
11:48:54.571 1 0x728 STD Rx 8 05 8F 01 01 9D 9B 9D 91
11:48:54.575 1 0x1e8 STD Rx 8 01 06 2C 2C 2B 2B 2B 2B
11:48:54.621 1 0x1e8 STD Rx 8 02 02 0D 00 B0 59 00 00
11:48:56.258 1 0x678 STD Rx 8 40 E2 57 00 00 00 00 00
11:48:56.262 1 0x5f8 STD Rx 8 41 E2 57 00 0A 00 00 00
11:48:56.264 1 0x678 STD Rx 8 60 00 00 00 00 00 00 00
11:48:56.267 1 0x5f8 STD Rx 8 00 66 DC AD 67 00 00 00
11:48:56.269 1 0x678 STD Rx 8 70 00 00 00 00 00 00 00
11:48:56.272 1 0x5f8 STD Rx 8 19 00 00 00 00 00 00 00
11:48:57.586 1 0x1e8 STD Rx 8 02 01 0D 00 9C 59 00 00
11:49:01.257 1 0x678 STD Rx 8 40 E2 57 00 00 00 00 00
11:49:01.259 1 0x5f8 STD Rx 8 41 E2 57 00 0A 00 00 00
11:49:01.262 1 0x678 STD Rx 8 60 00 00 00 00 00 00 00
11:49:01.264 1 0x5f8 STD Rx 8 00 6B DC AD 67 00 00 00
11:49:01.264 1 0x678 STD Rx 8 70 00 00 00 00 00 00 00
11:49:01.264 1 0x5f8 STD Rx 8 19 00 00 00 00 00 00 00
11:49:01.659 1 0x1e8 STD Rx 8 02 3F 0D 00 D8 59 00 00
11:49:02.328 1 0x738 STD Rx 1 05

Hi Rudi,

dein Post hier hat mir bei meinen Abenteuern mit dem CAN-Bus und TA-Geräten extrem weitergeholfen. In der Tat konnte ich so die Basis-Adresse der PDOs herausfinden über die TA-Geräte Daten auf dem CAN-Bus zur Verfügung stellen.

Ich habe nun folgendes Problem. Mit einem Firmware-Update hat TA offiziell das Datenformat am CAN-Bus geändert. Es werden nun 4 Byte statt 2 Byte genutzt, was die Auflösung erhöht. Seit diesem Update gehen die Basis-Adresse nicht mehr. Es gibt auf dem CAN-Bus keine Nachrichten mehr von, z.B., 0x200 + Node ID. Stattdessen scheint es eine neue Basisadresse 1C0 zu geben. Dort finde ich zwar Daten, die ich auf die Ausgänge gelegt habe, wieder, aber das Format der Ausgabe verstehe ich nicht. Statt einer Ausgabe von allen Werte auf einmal, scheint das x2 Gerät (ein EZ3A um genau zu sein) jetzt über die eine Basis-Adresse zyklisch und nacheinander die Werte der Ausgänge auszugeben.
Lange Rede kurzer Sinn: hast du ein x2-Gerät mit neuer Firmware und konntest beobachten, dass dein Ansatz nicht mehr funktioniert? Falls ja, hast du einen Workaround gefunden?

Danke und viele Grüße!