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
