www.mikrocontroller.net

Forum: Haus & Smart Home CAN "Kollision" nach der ID


Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich benutze den CAN Controller MCP2515 und würde gerne wissen, was
passiert wenn 2 meiner Nodes eine CAN Nachricht mit gleicher ID aber
unterschiedlichem Payload senden (kein RTR).

Die Arbitrierung läuft ja ,soweit ich das im Datenblatt ersehen konnte,
auch nach der ID weiter. Was passiert aber nun wenn der Controller mit
seiner Message "verliert" und genau die ID die er gerade absetzen
wollte soweben auf dem Bus war? Bei RTR hab ich gelesen, das die RTR
Nachricht dann sinnvollerweise verworfen wird, aber was passiert bei
einer Nachricht die das RTR Bit nicht gesetzt hat?

Vielen Dank schonmal
Gruß Philipp

Autor: Schmittchen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin mir nicht ganz sicher, was da passiert. Zwei Erklärungen habe ich:

1.) Der zweite Sender merkt, dass auf dem Bus was nicht stimmt
(schreibt ja rezessiv und liest dominant) also vermerkt er einen
Tx-Error (+8) und schickt ein ErrorFrame. Die Botschaft wird dadurch
von allen Busteilnehmern verworfen und wiederholt - auch vom ersten,
eigentlichen Sender. Das Spiel wiederholt sich, bis sich der zweite
Sender wegen Erreichen seiner TX-Fehlerschwelle vom Bus zurückzieht.
(Er zieht sich vom Bus als erster zurück, weil er seinen
Tx-Fehlerzähler als aktiver Sender schneller inkrementiert wie die
anderen Knoten, die nur passiv einen Fehler erkennen). Danach kommt
endlich die Nachricht des ersten Senders durch.

2.) Das Rücklesen der gerade gesendeten Daten findet nur in der
Arbitrierungsphase statt, danach nicht mehr. Also merkt der zweite
Sender vom Problem nichts - schreibt also munter weiter. Tritt jetzt
der Fall ein, dass der zweite Sender den ersten Sender mit einem
dominanten Bit überschreibt, dann kommts in den restlichen Knoten zu
Fehlern (je nach Fehlerbit kann das z.B. ein CRC-Fehler,
Bitstuffingfehler usw. sein). Die anderen Knoten senden einen
Errorframe, der die beiden Sender veranlasst ihre Nachrichten zu
wiederholen. Das Spiel beginnt von vorne, bis sich die beiden selbst
abschalten. Grund siehe unter 1.
Überschreibt der zweite Sender keine Bits des ersten Senders, so würde
das Problem eigentlich gar nicht auffallen... Hm.

@all: Kann ein CAN-Experte hier weiterhelfen?

Und nein, die Arbitrierung (=wer darf den Bus benutzen) ist per
Definition nach dem RTR-Bit beendet.

Deshalb niemals zwei CanIds von 2 unterschiedlichen Knoten verschicken
lassen!

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok vielen Dank

scheint ja echt ne Frage zu sein die man so einfach nicht beantworten
kann :)

Dann muss ich mir wohl was anderes überlegen

Gruß Philipp

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
unauflösbarer buskonflikt und ende gelände. sie schalten sich ab.

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich verstehe nur nicht ganz, warum du nicht einfach auf eine andere CAN 
ausweichst. Schliesslich warst du bereits in der Annahme, durch den 
Nachrichteninhalt die Priorität der Nachrichte weiter zu bestimmen.
Die kannst du ja dann ganz einfach um den Bereich dein CAN_ID einfügen.
Es gibt ja auch noch CAN 2.0b, falls dir die 2^11 Identifier ausgehen 
;-)

grüße

Autor: daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich habe mal eine andere Frage. Wie werden diese ID's festgelegt?
Sind diese in Hardware implementiert und haben eine allgemein gehaltene 
Bedeutung. Oder werden diese in der Software der einzelnen Busteilnehmer 
festgelegt.
Wenn diese von jedem Controller per Software verwaltet werden, ergibt 
sich bei mir folgender Gedanke.
Da ja die 0 bei CAN dominant ist, kann man fuer jeden Busteilnehmer und 
dessen Bedeutung, seine eigene Prioritätsstufe mittels ID festlegen. 
Somit wäre die ID 0x000 (11bit), diese welche die hoechste Priorität 
hat. Alle anderen werden  darauf aufgebaut und wuerden nach Prorität das 
Senderecht bekommen. Damit es wie in diesem Post beschrieben nicht zu 
einem Buskonflikt kommt. Muesste jede ID nur einmal  als Sendeversuch 
(RTR=0) auftreten.
Der CAN - Bus selbst ist ja nur eine OSI-Schicht 2. Das heisst er baut 
auf beliebige Uebertragungsmedien(Schicht 1) auf und wird von einer 
selbsterdachten Kontrollsoftware(Schicht 3) gesteuert.
Gibt es da schon offene Programmieralgorithmen fuer Mikrokontroller 
welche sozusagen die Schicht 3 oder hoeher darstellen? Wenn ja, wo finde 
ich diese?

MfG Daniel

Autor: Axel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Da ja die 0 bei CAN dominant ist, kann man fuer jeden Busteilnehmer und
dessen Bedeutung, seine eigene Prioritätsstufe mittels ID festlegen.
Somit wäre die ID 0x000 (11bit), diese welche die hoechste Priorität
hat. Alle anderen werden  darauf aufgebaut und wuerden nach Prorität das
Senderecht bekommen. Damit es wie in diesem Post beschrieben nicht zu
einem Buskonflikt kommt. Muesste jede ID nur einmal  als Sendeversuch
(RTR=0) auftreten."

Genau so ist das auch gedacht.

Gruss
Axel

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.