Hi, Ich habe momentan irgendwie ein Durcheinander bei folgendem Fall. Es geht um einen CAN Bus mit 3 Teilnehmern A,B und M, wobei M der Master sein soll und Befehle an die anderen Teilnehmern schickt. A und B kommunizieren nur mit M und nicht untereinander. Nun möchte ich also jedem Knoten eine Message ID zuordnen für den Arbitration Prozess: M = 0x00 //Gewinnt Arbitration immer A = 0x01 B = 0x02 Wenn nun aber M z.B an A schickt, dann muss doch die Message ID = 0x01 sein, damit dieser die Nachricht als seine erkennt, wenn jetzt aber gleichzeitig A ein Feedback an M senden will, dann gibt das eine Kollision, da beide den Arbitration Prozess gewinnen. Wie löst man dieses Problem?
Bert S. schrieb: > A ein Feedback an M senden Auch mit Message ID 0x01? Dann erfolgt die Arbitrierung durch den restlichen Inhalt der Nachricht. Aber wenn M als Sender immer gewinnen soll, dann sollte jede Nachricht mit der Sender-ID beginnen, und danach erst die Empfänger-ID folgen, oder? LG, Sebastian
Ok, ich glaube ich sehe das durcheinander, zuvor hatte ich mal CANOpen verwendet, dort haben die Geräte dann eine eigene Adresse, bei CAN alleine ist ja nur eine Message ID vorhanden, sprich empfangen und senden sollte auf unterschiedlichen IDs sein. Dann wäre wohl so etwas schlau: A hat RX ID 0x01 und TX ID 0x101 B hat RX ID 0x02 und TX ID 0x102 M sendet dann immer an 0x01 und 0x02 und empfängt auf 0x101 und 0x102, oder?
Bert S. schrieb: > M sendet dann immer an 0x01 und 0x02 und empfängt auf 0x101 und 0x102, > oder? M sendet nicht "an", sondern M verbreitet die Nachrichten 0x01 und 0x02. Wer zuhört, geht M überhaupt nichts an. A reagiert auf 0x01 mit Message ID 0x101, B reagiert auf 0x02 mit Message ID 0x102.
Rainer W. schrieb: > Bert S. schrieb: >> M sendet dann immer an 0x01 und 0x02 und empfängt auf 0x101 und 0x102, >> oder? > > M sendet nicht "an", sondern M verbreitet die Nachrichten 0x01 und 0x02. > Wer zuhört, geht M überhaupt nichts an. > A reagiert auf 0x01 mit Message ID 0x101, B reagiert auf 0x02 mit > Message ID 0x102. Genau, habe mich da immer noch falsch ausgedrückt.
Bert S. schrieb: > A,B und M, wobei M der Master sein soll und Befehle an die anderen Teilnehmern schickt. > A und B kommunizieren nur mit M und nicht untereinander. Bei CAN gibt es keinen offiziellen Master. Alle Knoten sind erst mal gleichberechtigt und alle kommunizieren miteinander. > Nun möchte ich also jedem Knoten eine Message ID zuordnen für den > Arbitration Prozess: Arbitriert wird eigentlich eine Botschaft. > Wenn nun aber M z.B an A schickt, dann muss doch die Message ID = 0x01 > sein, damit dieser die Nachricht als seine erkennt M schickt nicht explizit an A sondern auf den Bus. Alle Knoten empfangen die Botschaft erst mal und senden ein ACK. Erst dann wird im Empfangsfilter die Botschaft ausgesondert oder an die Empfangs-Software weitergegeben. Oder man gibt alle empfangenen Botschaften ohne Filter an die Software weiter und filtert die unerwünschten erst dort aus. So mache ich es wenn die Buslast nur gering ist.
Sebastian W. schrieb: > Dann erfolgt die Arbitrierung durch den restlichen Inhalt der Nachricht. Nein. Arbitrierung erfolgt bei CAN nicht auf dem ganzen Frame.
Mich würden mal deine Zeitkriterien interessieren. Da A und B ja nichts von sich aus etwas auf den Bus senden, hat doch M alle Zeit der Welt Befehle abzuschicken. Und wenn mal gerade eine Antwort von A oder B eintrudelt, dann muss er eben die Antwort abwarten, so lange dauert es ja nicht.
Μαtthias W. schrieb: > Sebastian W. schrieb: >> Dann erfolgt die Arbitrierung durch den restlichen Inhalt der Nachricht. > > Nein. Arbitrierung erfolgt bei CAN nicht auf dem ganzen Frame. Du hast recht. Ich lag falsch. Bei Kollisionen im Anschluß an ID und RTR-Feld kommt es anscheinend zu Error-Frames, und es setzt sich nicht die dominantere Nachricht durch. Danke für die Korrektur! LG, Sebastian
Sebastian W. schrieb: > Bei Kollisionen im Anschluß an ID Sowas sollte nie vorkommen: Gleiche CAN-IDs sollten nie von zwei Knoten aus gesendet werden. Bei Verlust der Arbitrierung während der Übertragung der CAN-ID hört der Looser einfach auf zu Senden und versucht es zu einem späteren Zeitpunkt wieder. Ein Error wird dabei noch nicht gesetzt.
Rainer W. schrieb: > Wer zuhört, geht M überhaupt nichts an. Mit nur einer klitzekleinen Ausnahme : wenn es keiner gehört hat (fehlendes ACK), muss der Sender das beachten und sich quasi fragen, woran das wohl liegt. Sprich wenn ihm das öfters passiert, muss er damit rechnen, dass er Stuss sendet, den niemand versteht und damit aufhören. Ansonsten ist das richtig, jede ID darf nur von maximal einem Busteilnehmer gesendet werden. Was Du vielleicht meinst, sind die RETR Frames, mit denen das Senden eines Frames angefordert wird. Es gibt aber CAN-Busse, die kommen komplett ohne aus. Einen Plan, wer was wo wie codiert wann in welcher Botschaft sendet und wer sich alles dafür interressiert, braucht man für Software, die Quellcode für die Software im Busteilnehmer generiert.
Zusammengefasst: - bei CAN gibt es eigentlich keinen Master oder Slave. Alle Teilnehmer sind gleichberechtigt. - die Botschafts-ID ist keine Kennung des Absenders, sondern des Inhalts, also welche Daten in der Botschaft drin stecken. Woher die dann kommt, ist zweitrangig. - es gibt auch kein Senden an bestimmte Teilnehmer. Alle Botschaften sind Broadcasts und lesen tut sie jeder, der sich dafür interessiert. - Arbitrierung hat damit erst mal nichts zu tun. Bei dieser geht es darum, dass, falls zwei Knoten genau gleichzeitig eine Botschaft senden wollen, die mit der niedrigeren ID durchkommt, während für die andere später nochmal ein Versuch unternommen werden muss. Wenn man etwas anderes als das mit CAN machen will, braucht man eine zusätzliche darauf aufsetzende Protokollebene, so wie es z.B. CANopen macht. Frank O. schrieb: > Einen Plan, wer was wo wie codiert wann in welcher Botschaft sendet und > wer sich alles dafür interressiert, braucht man für Software, die > Quellcode für die Software im Busteilnehmer generiert. Und für Software, mit der man analysiert, was da so auf dem Bus umherschwirrt.
:
Bearbeitet durch User
Hallo, Rolf M. schrieb: > Zusammengefasst:........ 100 Punkte endlich einer der den Can-Bus versteht. SW: Vielleicht mal bei Vector reinschauen.
Rolf M. schrieb: > Zusammengefasst Dem bleibt nur noch eines hinzuzufügen: mit einem request kann jeder Teilnehmer eine beliebige Nachricht anfordern. Sg
Bei gleichem ID versuchen beide Sender, es ewig zu wiederholen, bis die Fehlerabschaltung erfolgt. Auf das Datenpaket erfolgt keine Arbitration mehr, d.h. da gibt es nur noch Fehlerpakete. Ich würde CAN2.0B mit 29Bit Identifier nehmen, dann kann man Empfänger- und Senderadresse mit hinein packen.
Kann man machen, es erhöht aber auch die Buslast, da die Nachrichten länger sind. So ein Hobbyprojekt sollte doch mit 2048 möglichen IDs zurechtkommen. Da du ja nur ein paar Teilnehmer hast könntest du ja einfach die ersten oder letzen Bits der ID als Absenderkennung verwenden So das du Temp1 von Teilnehmer1 in der ID codieren kannst. Aber meiner Meinung ist es uninteressant woher Temp1 kommt, wichtig ist nur das eben nur ein Teilnehmer Temp1 sendet und die anderen dann eben Temp2 oder Temp3 verwenden müssen.
Peter D. schrieb: > Ich würde CAN2.0B mit 29Bit Identifier nehmen, dann kann man Empfänger- > und Senderadresse mit hinein packen. Genau genommen ist das dann aber kein klassischer CAN mehr da du ja dann schon ein zusätzliches Sender-Empfänger-Protokoll hinzugefügt hast.
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.