Hallo,
Ich habe da ein Verstädnisproblem zu dem CAN Bus, da ich diesen immer
wieder mit anderen BUS Systemen vergleiche(zBsp I2C)..
Je niedriger die ID, desto höher die Priorisierung.
Was passiert, wenn zwei verschiedene Steuergeräte !gleichzeitig! zwei
Nachrichten mit der gleichen ID senden? Was wenn zwei Nachrichten mit
der höchsten Priorität gleichzeitig gesendet werden? Normalerweise
dürfte das doch gar nicht möglich sein?
Bei zwei verschiedenen Priorisierungen: Es liegt eine Nachricht mit der
ID 4 auf dem BUS. Ein anderes Steuergerät möchte nun eine Nachricht mit
der ID 5 senden. Wird diese nun trotzdem auf den BUS gelegt und von der
anderen Nachricht überschrieben oder prüft der CAN Controller vorher,
dass der BUS belegt ist und nichts senden darf?
Bei gleicher Priorisierung: Es liegt eine Nachricht mit der ID 2 auf dem
BUS und ein anderes Steuergerät möchte nun eine Nachricht mit der ID 2
senden. Was passiert?
Meiner Meinung nach, wird nicht geprüft ob der BUS belegt ist, da sonst
die Priorisierung jedes Mal entfallen würde..?
Vielen Dank
Phil schrieb:> Was passiert, wenn zwei verschiedene Steuergeräte !gleichzeitig! zwei> Nachrichten mit der gleichen ID senden? Was wenn zwei Nachrichten mit> der höchsten Priorität gleichzeitig gesendet werden? Normalerweise> dürfte das doch gar nicht möglich sein?
Ist ein Konfigurationsfehler.
Irgendwann dann Bit Kollision -> Rücklesefehler -> Error Frame.
Phil schrieb:> oder prüft der CAN Controller vorher,> dass der BUS belegt ist und nichts senden darf?
Ja. Nennt sich Inter frame space (11 Bit Idle)
Phil schrieb:> Es liegt eine Nachricht mit der ID 2 auf dem> BUS und ein anderes Steuergerät möchte nun eine Nachricht mit der ID 2> senden. Was passiert?
Es wird warten. Danach senden.
Phil schrieb:> Meiner Meinung nach, wird nicht geprüft ob der BUS belegt ist, da sonst> die Priorisierung jedes Mal entfallen würde..?
Wie gut, dass deine Meinung nicht dem CAN Standard entspricht.
Die Priorisierung greift nur, falls 2 Teilnehmer gleichzeitig anfangen
verschiedene Nachrichten zu senden.
-> Sie funktioniert nur wenn beide gleichzeitig anfangen, siehe Prinzip
mit dominanten/rezessiven Bits
Ansonsten wird der Bus abgehört, und nur bei Idle eine Nachricht auf den
Bus gelegt.
Erik schrieb:> Phil schrieb:>> Was passiert, wenn zwei verschiedene Steuergeräte !gleichzeitig! zwei>> Nachrichten mit der gleichen ID senden? Was wenn zwei Nachrichten mit>> der höchsten Priorität gleichzeitig gesendet werden? Normalerweise>> dürfte das doch gar nicht möglich sein?>> Ist ein Konfigurationsfehler.> Irgendwann dann Bit Kollision -> Rücklesefehler -> Error Frame.
Wie wird das denn überprüft? Aus deiner Antwort erkenne ich ja dass eine
Überprüfung statt findet, ob der BUS belegt ist oder nicht.
Aber wenn diese Überprüfung statt findet, was hat es dann mit der
Priorisierung auf sich? (Erstes Beispiel in meinem Post mit zwei
verschiedenen ID's) ?
mukel schrieb:> Die Priorisierung greift nur, falls 2 Teilnehmer gleichzeitig> anfangen> verschiedene Nachrichten zu senden.> -> Sie funktioniert nur wenn beide gleichzeitig anfangen, siehe Prinzip> mit dominanten/rezessiven Bits>> Ansonsten wird der Bus abgehört, und nur bei Idle eine Nachricht auf den> Bus gelegt.
Achso, das bedeutet, wenn gerade eine Nachricht mit der ID 5 auf dem BUS
unterwegs ist, und jemand anderes eine Nachricht mit der ID 1 senden
will, dann muss er warten bis der BUS frei ist ?
Und wenn 2 STGeräte !gleichzeitig! senden, dann wird die Priorisierung
durchgeführt. Zwei Nachrichten mit der gleichen ID können also nicht
gleichzeitig gesendet werden. Wie wird dieser Fall denn vermieden?
Es gibt eine Arbitrationsphase und eine Datenphase.
Während der Arbitrationsphase gewinnen alle dominanten States (0).
Kann ein Knoten nicht sein Bit rücklesen, was er auf den Bus legt, so
zieht er sich zurück.
Während der Datenphase führen Rücklesefehler zum Error State / Error
Frame.
Phil schrieb:> Achso, das bedeutet, wenn gerade eine Nachricht mit der ID 5 auf dem BUS> unterwegs ist, und jemand anderes eine Nachricht mit der ID 1 senden> will, dann muss er warten bis der BUS frei ist ?
Ja.
Phil schrieb:> Zwei Nachrichten mit der gleichen ID können also nicht> gleichzeitig gesendet werden. Wie wird dieser Fall denn vermieden?
Wie gesagt, Konfigurationsfehler.
Und beim Rücklesefehler gibs dann das Error Frame.
Die Priorisierung kommt durch die Entstehung der Bits.
Ein Sender gibt 1 auf den Bus, das Bit ist also rezessiv, da passiv
"high".
Der andere gibt 0 auf den Bus, ein dominantes Bit, da aktiv "low".
Beide lesen ihr gesendetes Bit, der "1"er sieht Null wo eine Eins sein
müsste und bricht den Vorgang ab.
Der "0" merkt nix davon und macht weiter.
Zack: Priorisierung: die niedrige ID geht durch.
Mag jetzt sein, das ich die Pegel vertauscht habe, aber das Prinzip ist
so.
Lange her das ich da was mit gemacht hab.
Nun,
IDLE wird erkannt wenn 11 bit zeiten keine Nachricht gesehen wurde, also
der Bus dauerhaft auf 1 steht.
0-> Differenzspannung von 2V zwischen CAN_Low CAN_HIGH
1-> Differenzspannung ist 0V
Da 0 dominat ist - wenn ein Steuergerät die Busleitungen auseinaderzieht
- kann ein anderes Steuergerät keine 1 Senden. zusammgengezogen auf 0V
Differnz werden beide Leitungen durch die Terminierung von 120ohm. Das
ist vergleichbar mit den Pull-Up Widerständen von I2C.
Beim Senden mit Priorisierung starten beide Teilnehmer gleichzeitig:
Soll-Buszustand (Ausschnitt ID)
ID 2 0010
ID 1 0001
Ist-Buszustand
Bus 0001
-> Bei bit 3 erkennt das Steuergerät mit der ID 2, dass seine Bitfolge
nicht auf dem Bus vorhanden ist und stoppt den Sendevorgang. Daher wird
das 4 Bit für die ID 1 Richtig auf den Bus gelegt.
Phil schrieb:> Achso, das bedeutet, wenn gerade eine Nachricht mit der ID 5 auf dem BUS> unterwegs ist, und jemand anderes eine Nachricht mit der ID 1 senden> will, dann muss er warten bis der BUS frei ist ?>> Und wenn 2 STGeräte !gleichzeitig! senden, dann wird die Priorisierung> durchgeführt. Zwei Nachrichten mit der gleichen ID können also nicht> gleichzeitig gesendet werden. Wie wird dieser Fall denn vermieden?
Zu 1. Ja genau. Eine gerade gesendete Nachricht kann nicht unterbrochen
werden. Das macht die Timing und Echtzeitanalyse für CAN auch
aufwendiger als für preemptive systeme.
Zu 2. Ganz einfach, es dürfen keine 2. Geräte senden. Per Konfiguration.
Falls doch, müssen CAN-Controller den Bus überwachen und falls sie nicht
ihre Nachricht sehen, weil die andere Nachricht mit der selben ID an der
stelle eine 0 hat, direkt abschalten und ein Errorframe versenden.
Falls dies zu häufig passiert, müssen sich die einzelnen Knoten
selbständig komplett abschalten.
es sollen/dürfen ja nicht die gleichen Identifier verwendet werden, wenn
also das ABS Steuergerät und ein Getriebesteuergerät eine
Geschwindigkeit x erkennen dann senden nicht beide mit dem Identifier
Geschwindigkeit auf den Bus sondern der eine sendet Geschwindigkeit1 = x
und der andere sendet Geschwindigkeit2 = x
Durch die Vergabe der IDs in der Planung bestimmt man gleich die
Priorität der einzelnen Identifier.
Phil schrieb:> Wird diese nun trotzdem auf den BUS gelegt und von der> anderen Nachricht überschrieben oder prüft der CAN Controller vorher,> dass der BUS belegt ist und nichts senden darf?
Er prüft bei jedem Bit der ID, ob er noch senden darf. Falls sein Bit
von einem dominanten überschrieben wurde, hat er verloren und und muss
die Klappe halten. Die auf Grund der ID höher prorisierte Nachricht hat
gewonnen und wird übertragen.
Auf dem Bus regelt die HW über die Priorisierung den Datenverkehr.
So wie ich das verstehe bekommt jeder Zustand/Messwert eine eigene ID.
Ändert sich ein Zustand wird dies mit der zugehörigen ID dem Bus
mitgeteilt. Jeder der sich dafür interessiert weiß dann Bescheid.
Messwerte können auch zyklisch auf dem Bus aktualisiert werden.
Was für Funktionen hat man in der Regel beim CAN Protokoll?
Fragt man auch IDs ab?
Z.B. "Lese Dig. Ausgang1 ID:1234" und er antwortet dann?
Gibt es auch Klassen IDs? Also jeder Dig. Ausgang hat seine eindeutige
ID und es es gibt eine zusätzliche ID "Alle Dig. Ausgänge". Ein
Schreiben dieser ID würde dann alle Dig. Ausgänge gleichzeitig setzen.
Bei einem Lesen würden alle Dig. Ausgänge ihren Zustand auf den Bus
legen. Das würde dann wohl eher Chaos geben.
Kai schrieb:> Ändert sich ein Zustand wird dies mit der zugehörigen ID dem Bus> mitgeteiltKai schrieb:> Fragt man auch IDs ab?> Z.B. "Lese Dig. Ausgang1 ID:1234" und er antwortet dann?
Du wiedersprichst dir selbst.
Es ist ein Multi-Master Bus (one to many). Es ist KEIN Master-Slave Bus.
Es sind einfach nur Nachrichten. Mit IDs.
Es gibt kein "Lesen", kein "Schreiben".
Die Interpretation der Nachricht obliegt vollständig dem Empfänger.
Kai schrieb:> Fragt man auch IDs ab?
IDs selbst nicht, aber es gibt "remote frames", damit kann man gezielt
veranlassen, dass der angesprochene antwortet. Habe ich aber noch nie
gebraucht und dementsprechend nie genutzt.
> Z.B. "Lese Dig. Ausgang1 ID:1234" und er antwortet dann?
So nicht vorgesehen,und auf CAN-Ebene eh sinnlos. Wäre dann eine Aufgabe
für den übergeorneten MC/Software, diese Anfrage zu erkennen und
entsprechend zu antworten.
Ist aber i.a. auch unnötig, lass einfach alle im ausreichenden
Zeitraster ihre Daten rausschleudern.
Man kann natürlich ein Master-Slave Modell drüberstülpen, indem man die
IDs entsprechend definiert.
Entweder jeder Slave bekommt eine Read und eine Write ID und der Master
kennt sie alle.
Oder man schickt Read-Requests an alle Teilnehmer mit einer weiteren ID
im Payload.
Es gibt die Möglichkeit der Anforderung und dem Antworten (Remote Frame)
oder eben das die einzelnen Teilnehmer einfach ihre Werte zyklisch oder
bei Änderung übertragen. Das kannst du einrichten wie du willst. Du hast
die freie Wahl ID=0 könnte z.B. Alarm heißen und wenn die rumgeschickt
wird, reagieren alle Alarmgeber oder man Gruppiert das ganze ID=0 ist
Alarm1 und ID=1 ist Alarm2... in den Daten übergibts du dann z.B.
ein/aus/..... Jeder Teilnehmer wertet anhand der ID nur das aus was er
braucht das können auch mehrere oder alle IDs sein.
Als Alternative kann man die Message ID auch unterteilen in virtuelle
Unterabschnitte.
Beispiel UAVCAN:
https://uavcan.org/Specification/figures/can_id_format.png
Damit geht dann Multi-Master Point-to-Point.
Was allerdings nicht darüber hinweg täuscht, dass die Nachrichten von
allen* empfangen werden.
*sofern die Akzeptanzfilter im Controller entsprechend konfiguriert sind
Mir macht der Can Bus einen Knoten ins Hirn.
Ich verstehe schon den Grundsatz wie Daten ausgetauscht werden.
Allerdings verstehe ich nicht wer kompliziertere Logik übernimmt.
Nehmen wir z.B. eine Innenraumbeleuchtung der Fußräume im Auto.
Jede Tür stellt einen Busteilnehmer der den Zustand auf den Bus legt.
Jeder Fußraum stellt einen Busteilnehmer der die Leuchte steuert.
Busteilnehmer 1 : ID 10: Zustand Fahrertür
Busteilnehmer 2 : ID 20: Zustand Beifahrertür
Busteilnehmer 3 : ID 30: Zustand Hinten links
Busteilnehmer 4 : ID 40: Zustand Hinten rechts
Busteilnehmer 5 : ID 50: Zustand Kofferraum
Busteilnehmer 6 : ID 60: Beleuchtung Fahrertür
Busteilnehmer 7 : ID 70: Beleuchtung Beifahrertür
Busteilnehmer 8 : ID 80: Beleuchtung Hinten links
Busteilnehmer 9 : ID 90: Beleuchtung Hinten rechts
Busteilnehmer 10 : ID 100: Beleuchtung Kofferraum
Busteilnehmer 6 ist nun so konfiguriert dass er bei einer Meldung "ID 10
= true" die Beleuchtung im Fahrerfußraum einschaltet. Anschließend
sendet er eine Meldung "ID 60 = true" auf den Bus usw..
Was ist aber wenn eine ID von mehreren Busteilnehmern abhängig ist?
Erwünscht wäre z.B. eine virtuelle ID 1000 die die "Innenraumbeleuchtung
gesamt" repräsentiert.
Diese ID wäre für höhere Logik von Interesse die es nicht interessiert
wieviele Leuchten
es im Auto gibt sondern nur ob alles aus oder alles an ist.
Solche virtuellen Adressen könnte ein zentraler Broker verwalten.
Dieser würde quasi alle realen Adressen mithören und durch logische
Operationen die virtuellen Adressen
zur Verfügung stellen.
Allerdings schwindet mir da der Charme der dezentralen Verteilung. Fällt
dieser Broker aus, bricht die gesamte höhere Logik einfach weg.
Kai schrieb:> Busteilnehmer 1 : ID 10: Zustand Fahrertür> Busteilnehmer 2 : ID 20: Zustand Beifahrertür
(...)
Globaler Denkfehler.
ID10: Sendedaten ausgehend von Busteilnehmer 1
ID11: weitere Sendedaten ausgehend von Busteilnehmer 1
ID10: Sendedaten ausgehend von Busteilnehmer 2
usw
"Fahrertür offen" ist ein Signal mit der Länge 2 bit (für die Zustände
"init", "offen", "zu" und "Fehler"), welches Busteilnehmer 1 zyklisch
zusammen mit allen anderen von ihm ausgehenden Daten in der ID10
abstrahlt. Das kann empfangen wer will.
> Solche virtuellen Adressen könnte ein zentraler Broker verwalten.> Dieser würde quasi alle realen Adressen mithören und durch logische> Operationen die virtuellen Adressen zur Verfügung stellen.
Die Lichtsteuerung erfolgt üblicherweise im Bordnetzsteuergerät. Dort
werden die Statusmeldungen der Teilnehmer eingesammelt und die
Steuerbefehle (global oder eine ID pro Teilnehmer, beides ist möglich)
abgesendet.
Jede CAN-Nachricht hat eine ID.
Eine CAN-Nachricht kann mehrere Signale enthalten.
Normalerweise gibt es keine zwei Geräte die Nachrichten mit der gleichen
ID aussenden.
Häufig wird so implementiert das ein Signal ein Zustand des sendenden
Geräts (Steuergerät/ECU/Electronic Control Unit) entspricht.
Eine andere ECU kann dann auf eine oder mehrere Signale reagieren und
einen ihren eigen internen Zustände ändern und z.B. einen Aktor
schalten.
Das man über eine CAN-Nachricht einen Befehl absetzt ist auch möglich,
aber nicht der gängige weg.
