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.
:
Bearbeitet durch User
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 > mitgeteilt Kai 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.
Thread beobachten
Seitenaufteilung abschalten
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.