Wenn ich über den CAN-Bus ein Telegramm (1 Datenbyte) sende, das beim Empfängerknoten dafür sorgt (1 bestimmtes Bit im Datenbyte ist gesetzt), dass ein Relais anzieht, wie kann ich sicher sein, dass das Relais angezogen hat bzw., dass das Telegramm angekommen ist? Nun habe ich mir gedacht, dass das Bit, das das Relais anziehen lässt gleichzeitig auf einen Eingang des Empfängerknotens zulegen und so abfragen kann (per Remotetelegramm z. B.), ob zumindest das Bit, welches das Relais anziehen lässt, gesetzt ist. Ist das üblich - oder gibt es etwas besseres?
es gibt doch ein ACK-Bit wo alle Teilnehmer den Empfang bestätigen. Damit kannst du aber nicht sicherstellen dass das Relais angezogen hat, das müsstest du im Entsprechenden Relaiskreis abfragen und mit zurücksenden.
Es gibt verschiedene Überwachungsalgorithemen beim CAN-Bus, alle durch entsprechende Software zu erledigen. Hier mal eine kleine Auswahl: - Der Empfangskonoten überwacht das zyklische Empfangen des Telegramms. Wenn dies ausbleibt (typ. 3x normale Zeit), werden alle Ausgänge ausgeschaltet bzw. der sichere Zustand hergestellt - Der Sendeknoten überwacht ein zyklisches Telegramm des Empfangsknoten (s.o.) - Der Sendeknoten macht ein "Nodeguarding" gemäß CANopen-Standard, hier wird ein Remote-Telegramm gesendet und der Empfänger antwortet mit einem Bit, was jeweils getoggelt wird (0,1,0,1 usw.). Reaktion ansonsten wie oben - Der Empfangsknoten sendet ein "Heartbeat"-Signal und signalisiert so dem Sender, dass er noch lebt Wenn Du ganz sicher sein willst (kommt auf die Anwendung an), würde ich den emfangenen Zustand mittels Telegramm zurücksenden. Dann kannst Du die Software entsprechend verriegeln. Noch sicherer ist natürich, ein Hilfskontakt des Relais einzulesen, dann hast Du gleich noch die Ausgangsstufe und die Relaispule mit überwacht. Einzuschließen ist dann natürlich auch die Überwachung des "Aus"-Zustandes. Ich könnte noch beliebig weiterschreiben, aber ich denke, Du solltest das Grundprinzip verstehen. Gruß, Jürgen
Martin schrieb: > bzw., dass das Telegramm angekommen ist? Das garantiert dir der CAN-Bus auf Hardwareebene (solange er funktioniert). > wie kann ich sicher sein, dass das Relais angezogen hat Gar niemand. Es könnte ja eine Unterbrechung in der Spule sein, oder der Schalttransistor ist defekt, oder der Kontakt im Relais ist abgefackelt... > Noch sicherer ist natürich, ein Hilfskontakt des Relais einzulesen, > dann hast Du gleich noch die Ausgangsstufe und die Relaispule mit > überwacht. Mit einem abgebrannten Kontakt im Relais würde nicht mal das helfen... Du müsstest für eine maximale Sicherheit(=Garantie) also die geschaltete Last abfragen, ob dort letzendlich der gewünschte Schaltimpuls angekommen ist.
Vielen Dank für alle Antworten. >> bzw., dass das Telegramm angekommen ist? > Das garantiert dir der CAN-Bus auf Hardwareebene (solange er > funktioniert). Das ist nicht richtig. Es ist lediglich garantiert, dass 1 Knoten (mit der Bestätigung durch das ACK-Bit) das Telegramm korrekt empfangen hat. > Wenn Du ganz sicher sein willst (kommt auf die Anwendung an), würde ich > den emfangenen Zustand mittels Telegramm zurücksenden. Dann kannst Du > die Software entsprechend verriegeln. Diesen Weg werde ich gehen :)
Hi Martin, Martin schrieb: >>> bzw., dass das Telegramm angekommen ist? > >> Das garantiert dir der CAN-Bus auf Hardwareebene (solange er >> funktioniert). > > Das ist nicht richtig. Es ist lediglich garantiert, dass 1 Knoten (mit > der Bestätigung durch das ACK-Bit) das Telegramm korrekt empfangen hat. Da liegst du falsch. Die ACK-Bits sagen dem Controller (allem Knoten am Bus, also Sender und Empfänger) das alle Knoten keinen Übertragungsfehler erkannt haben. Sobald ein einziger Knoten einen Übertragungsfehler registriert, wird er den Fehlerzustand in der Nachricht setzen. Lothar hat schon recht. Du musst auch das beachten was in der Klammer stehen hat. Weil das der einzige Fall ist, in dem die Nachricht nicht fehlerhaft gekennzeichnet wird und dein Knoten die Nachricht nicht erhalten hat. Genau dann wenn der Emfangsknoten sich selber als Fehlerquelle erkannt hat "trennt" er sich vom Bus ab und startet neu. Es ist aber ein Unterschied ob der CAN-Controller oder die Verarbeitungseinheit, die Nachricht erhalten hat. Der CAN-Controller überwacht nur die reine Übertragung über den Bus und packt die Nachricht in eine Empfangsbox. Bis hier her ist die Übertragungssicherheit durch den CAN-Standard sichergestellt. Ob die Nachricht jemals aus der Empfangsbox ausgelesen verarbeitet wird musst du eben durch die weiter oben beschrieben Verfahren sicherstellen. Das trifft aber auch auf jede andere Kommunikation zu und ist somit nicht CAN-spezifisch.
TManiac schrieb: > Hi Martin, > > Martin schrieb: >>>> bzw., dass das Telegramm angekommen ist? >> >>> Das garantiert dir der CAN-Bus auf Hardwareebene (solange er >>> funktioniert). >> >> Das ist nicht richtig. Es ist lediglich garantiert, dass 1 Knoten (mit >> der Bestätigung durch das ACK-Bit) das Telegramm korrekt empfangen hat. > > Da liegst du falsch. Die ACK-Bits sagen dem Controller (allem Knoten am > Bus, also Sender und Empfänger) das alle Knoten keinen Übertragungsfehler > erkannt haben. Es gibt nur ein ACK-Bit, und das sagt lediglich, daß mindestens ein Knoten die Nachricht fehlerfrei empfangen hat. > Sobald ein einziger Knoten einen Übertragungsfehler registriert, wird er > den Fehlerzustand in der Nachricht setzen. Das geschieht aber nicht über das ACK-Bit, sondern über Error-Flags. > Lothar hat schon recht. Du musst auch das beachten was > in der Klammer stehen hat. Weil das der einzige Fall ist, in dem die > Nachricht nicht fehlerhaft gekennzeichnet wird und dein Knoten die > Nachricht nicht erhalten hat. Genau dann wenn der Emfangsknoten sich > selber als Fehlerquelle erkannt hat "trennt" er sich vom Bus ab und > startet neu. Er zieht sich langsam in mehreren Schritten vom Bus zurück, sofern der Fehler bestehen bleibt. Ob er dann wieder neu startet, ist Sache der Software.
TManiac schrieb: > Da liegst du falsch. Die ACK-Bits sagen dem Controller (allem Knoten am > Bus, also Sender und Empfänger) das alle Knoten keinen > Übertragungsfehler erkannt haben. Da das ACK Bit vom Sender rezessiv rausgeblasen wird und von jeder Node, die den Frame korrekt empfangen hat, dominant gesetzt wird reicht eine einzige Node aus. Wie der Name schon sagt kann jede Node ein rezessives Bit auf dominant setzen, aber umgekehrt eben nicht.
Ok da hab ich mich wohl zu schwammig ausgedrückt und zu stark vereinfacht. Das ACK-Bit kommt nach den Datenbits und dem CRC-Bits. Und ja es wird von den Empfängern auf dominant gesetzt und überschreibt somit den rezessiven Zustand des Senders, der nun wiederum das Überschreiben erkennt. Aber: Auf die gleiche Weise nur länger wird auch der Fehlerzustand signalisiert und damit geht das ACK-Bit zwischen den anderen 5 dominanten Error-Bits unter. Nun wird wieder jemand schreien, aber die Error-Bits müssen nicht am Ende stehen. Auch das stimmt, sie werden sofort auf den Bus gelegt sobald die Nachricht als fehlerhaft erkannt wird. Aber auch dann wird es nie zu einem positiven Acknowledge kommen. Also, sobald das ACK-Bit als solches erkannt wird ist die Nachricht auch richtig, zu mindest bis zu dem Bit selber. Die CAN Spec sagt zum Übergang vom Zustand Bus-off zu active folgendes: > An node which is ’bus off’ is permitted to become ’error active’ > (no longer ’bus off’) with its error counters both set to 0 after 128 > occurrances of 11 consecutive ’recessive’ bits have been monitored on > the bus. Es muss also für einen Restart des CAN Controllers nur ausreichend Busruhe vorhanden sein. Aber solche Sachen sehe ich eher als Interna an. mit denen man sich als Nutzer eigentlich nicht rumschlagen muss. Entweder die Nachricht ist richtig übertragen oder eben nicht.
TManiac schrieb: > Ok da hab ich mich wohl zu schwammig ausgedrückt und zu stark > vereinfacht. Yep, du sprichst vom Error Frame, nicht vom ACK Bit.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.