Hallo allerseits, ich bin gerade in der CANopen-Recherche für ein neues Projekt und kenne es daher nur aus Büchern (und auch nur einen kleinen Teil davon); Das Frage, die sich mir stellt, betrifft die Implementierung von CANopen und ob/wie das folgende Problem ohne Konsistenz-Probleme gelöst werden kann: Im Beispiel gibt es 2 Raumbedienteile mit 7-Segment-Anzeige (Node-ID 1 und Node ID 2) vorhanden; beide Bedienteile können die Solltemperatur (für z.B. eine Heizung) verändern; wird an Bedienteil 1 die SollTemperatur geändert (ein TPDO wird bei jeder Änderung gesendet), sollte der neue Wert auf Bedienteil 2 übernommen werden und umgekehrt; beide Bedienteile müssen immer die selbe Temperatur anzeigen; RPDO1 von Node 1 wird mit der Default-TPDO1 von Node 2 gelinkt (0x182) RPDO1 von Node 2 wird mit der Default-TPDO1 von Node 1 gelinkt (0x181) Auf beiden Nodes sind jeweils TPDO1 und RPDO1 auf das Objekt 0x2000 gemapped - hier steht in dem Beispiel die Solltemperatur; wenn nun gleichzeitig auf Bedienteil 1 die Temperatur gesenkt und auf Bedienteil 2 die Temperatur erhöht wird (beide schicken unmittelbar ein TPDO ab) werden diese der Reihe nach am Bus gesendet; kann es nun passieren dass anschließend die Bedienteile unterschiedliche Werte anzeigen? Ist dieses Vorgehen überhaupt erlaubt (ein TPDO und RPDO auf das selbe Object mappen)? Benötige ich gar 2 RPDOs pro Node für die Aufgabe bzw. können bei CANopen Nodes die gesendeten TPDOs mit eigenen RPDOs gelinkt werden? Ich bin für jeden Hinweis dankbar. mfG, Andreas
Hallo Andreas, das geschilderte Szenario wird funktionieren. Ich sehe hier von CANopen Seite kein Problem. Beide Nodes tauschen sich über 2 PDOs den Inhalt des Objekts 0x2000 aus, synchronisieren sich darauf. Und wie oft im Leben, wer zuletzt den Wert setzt und per PDO zum Bus sendet, hat gewonnen und bestimmt den Wert. Nur wenn wirklich beide gleichzeitig den Wert senden, wird PDO1 von Knoten 1 die Arbitrierung gewinnen und zuerst am Bus sein, darauf TPDO1 von Knoten 2 und damit den Wert bestimmen. Heinz
Hallo Heinz, danke für die Antwort! Meine Vermutung war, dass ich sogar jeweils 1 TPDO + 2 RPDOs pro Node in diesem Fall benötige um die Konsistenz der Solltemperatur zwischen beiden Nodes gewährleisten zu können - ich muss da etwas weiter ausholen: Beispiel (wie zuvor): Die Solltemperatur auf beiden Nodes ist 21°C (sie muss auch auf beiden Bedienteilen gleich sein); Ein Benutzer an Node 1 erhöht die Solltemperatur (22°C). Die Applikation auf Node 1 ändert also den Wert und der CANopen stack sieht, dass TPDO1 gesendet werden muss (Senden bei Änderung des Werts); der CANopen stack erstellt die CAN-Message für die höhere Solltemperatur und legt sie in eines der Message objects auf dem uC/CAN-Controllers ab; der uC an Node 1 sieht, dass der Bus frei ist und beginnt sogleich TPDO1 zu senden (gewinnt auch die Arbitrierung); soweit so gut; Noch während das Packet (22°C) gesendet wird, reduziert ein anderer Benutzer auf Node 2 die Solltemperatur (auf 20°C); der CANopen stack auf Node 2 macht nun das selbe wie Node 1 - message generieren und selbige in ein message object ablegen, damit es der CANcontroller bei Freiwerden des Busses sendet; Jetzt wurde das Message object TPDO1 von Node 1 (22°C) fertig gesendet; sofort erkennt der CAN-Controller auf Node2 den Idle-Zustand am Bus und macht sich ans Übertragen seines TPDO1 (20°C) das im Buffer des CANcontrollers schon ungeduldig auf den freien Bus wartet; der CANcontroller auf Node2 informiert den CANopen stack ausserdem, dass eine CANMessage (TPDO von Node 1) empfangen wurde, für das er ein Mapping hat (RPDO1); das Packet wird interpretiert und in Object 0x2000 - die Solltemperatur - abgelegt; Node 2 hat nun die höhere Solltemperatur (22°C); nun wurde auch die Message von Node 2 fertig am Bus versendet (TPDO1 mit 20°C) und der CANopen stack auf Node 1 wird darüber informiert - auch dieser interpretiert das TPDO (das die niedrigere Solltemperatur enthält) und schreibt den Wert in Object 0x2000; Node 1 hat nun die niedrigere Solltemperatur (20°C); die "richtige" Solltemperatur (die letzte die am Bus gesendet wurde) ist 20°C; ich könnte mir vorstellen, dass die Sache funktioniert (Konsistenz der Daten auf beiden Bedienteilen), wenn die Nodes RPDOs mit eigenen TPDOs linken können; Node 2 müsste dazu in dem Beispiel (sofern die bisherigen Annahmen stimmen) ein weiteres RPDO verwenden -> auf das eigene TPDO1 gelinkt! Node 2: RPDO1 <- TPDO1 (Node1) (wie zuvor) RPDO2 <- TPDO1 (Node2) (Erweiterung: auf eigenes TPDO1 gelinkt - geht das?) das Mapping von RPDO2 wäre komplett identisch mit dem von RPDO1 (also auf Object 0x2000); für Node 1 wäre entsprechend die selbe Erweiterung notwendig; Sind meine Bedenken begründet oder bin ich vielleicht komplett auf dem Holzweg? mfG, Andreas
Hallo Andreas, ich würde, wenn mehrere Bedienteile die Werte einer Steuerung verändern, die Sollwerte nicht in den Bedienteilen ablegen. Also wenn Sollwert verändert wird, den neuen Wert per PDO vom Bedienteil an die Steuerung (Heiztung,etc) schicken. Wenn die Heizung einen neuen Sollwert empfangen hat, kann sie einen PDO mit dem neuen (übernommenen) Sollwert auf den Bus legen. Dieses PDO können alle Bedienteile empfangen. Somit kann es keine inkonsistenzen in der Anzeige von Verschiedenen Bedienteilen geben.
Hallo Andreas und Jimbo, Jimbo hat natürlich Recht, gibt es eine zentrale Steuerung, so gibt es nur einen zu verändernden Parameter darin, welcher im Ojektverzeichnis der Steuerung angelegt ist. Den Istwert kann die Steuerung auch per PDO versenden. Und entsprechend ein Producer, ein oder mehr Consumer, kann dieser Wert von allen Bedienteilen empfangen und quasi gleichzeitig in der Anzeige aktualisiert werden. Nur, wie kommen die Sollwerte in die Steuerung? Der Sollwert steht im Objektverzeichnis, jedoch benötigt jede Bedieneinheit ein eigens PDO zum Senden des neu eingestellten Sollwertes und die Steuerung demnach 2 RPDO zum Empfang. Wobei die beiden Inhalte auf das gleiche 'sollwert' Objekt in der Steuerung gemappt werden. Auch hier gilt: wer zuletzt den Sollwert ändert, hat gewonnen. Mein am Datum: 23.05.2012 20:27 geschildertes Szenario geht nach wie vor, die Beiden Bedienteile müssen sich synchronisieren wie geschildert. Nun kann eines der Bedienteile auch die Steuerung sein, oder diese ist ein selbständiges Gerät. Nun, alles Klar? Oder alle Klarheiten beseitigt :-) Heinz
Hallo Heinz und jimbo, jetzt ist mit klar wie man das angeht. Danke für Eure Antworten! mfg, Andreas
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.