Hallo, ich möchte ein CAN Bus 2.0A mit LOW Speed 125 KHz aufbauen. Es sind 16 CAN Knoten vorhanden, die so oft wie möglich je 2 Integer senden sollen. Stimmt meine Zykluszeitberechnung mit 10 ms ? Oder werden zwischen zwei Frames oder sonst irgendwann Wartezeiten ausgeführt ? Welche Werte sind in der Praxis zu erwarten?
Angehängte Dateien:
-
CAN_Low_speed.JPG
40 KB
Das lässt sich gar nicht so eindeutig sagen, da noch Stuff Bits dazu kommen können.
Dirk F. schrieb: > Es sind 16 CAN Knoten vorhanden, die so oft wie möglich je 2 Integer > senden sollen. Klingt nach Hektik und schlechtem Konzept. > Stimmt meine Zykluszeitberechnung mit 10 ms ? Könnte grob hinkommen. > Oder werden zwischen zwei Frames oder sonst irgendwann Wartezeiten > ausgeführt ? Nö, aber wenn alle Knoten unsychronisiert senden wollen, gibt es viel Stau (Kollisionen beim Buszugriff) und sie behindern sich gegenseitig. Wenn man den Bus dermaßen knapp auslaten will, muss man es cleverer machen. Da muss jeder Knoten mithören (was sie sowieso tun) und erkennen, wenn der Vorgänger gesendet hat. Dann muss der Knoten senden, alle anderen halten die Klappe. Damit erreicht man minimale Kollisionen und maximale Busauslastung. Ich würde die Sache nicht übertreiben wollen und mindesten 10% Buskapazität Luft lassen. Sonst kracht es irgendwann, irgendwie.
Ja OK. Aber mit welcher Größenordnung kann ich rechnen `? Werden es eher 11ms oder 20 ms ?
Dirk F. schrieb: > Aber mit welcher Größenordnung kann ich rechnen `? > Werden es eher 11ms oder 20 ms ? Müssen ja wahnsinnig wichtige Daten sein. Dreh doch einfach die Baudrate hoch, das ist einfach! https://de.wikipedia.org/wiki/Controller_Area_Network#Daten-Frame Ich zähle hier 19 Bit Header 4x8 Bit Daten 25 Bit CRC+EOF 3 Bit Inter frame gap (min) Macht in Summe 79 Bit. Passt scho!
Dirk F. schrieb: > Ja OK. > Aber mit welcher Größenordnung kann ich rechnen `? > Werden es eher 11ms oder 20 ms ? Mit effektiven Maßnahmen zur Kollisionsvermeidung (z.B. exakte Zeitsynchronisation aller Knoten) sind so gefühlt 12-15ms drin. Ohne jegliche derartige Maßnahmen wirst Du exzessiv Kollisionen bekommen und vielleicht 50 oder gar 100ms bekommen. fchk
Stuff Chef schrieb: > Das lässt sich gar nicht so eindeutig sagen, da noch Stuff Bits dazu > kommen können. Stopfbits kommen nach 5 gleichen Bits eingefügt, also maximal 79/5 = 16 Bit. Real sind es wohl eher 5 oder weniger, denn so viele gleiche Bits gibt es statistisch eher nicht.
Falk B. schrieb: > Nö, aber wenn alle Knoten unsychronisiert senden wollen, gibt es viel > Stau (Kollisionen beim Buszugriff) und sie behindern sich gegenseitig. Kollisionen gibt es bei CAN nicht. Aber es kann sein, dass die Botschaften mit höherer ID von denen mit niedriger ID verdrängt werden und dann lange Zeit nicht dran kommen. > Wenn man den Bus dermaßen knapp auslaten will, muss man es cleverer > machen. Ja, ein einfaches "fire & forget" funktioniert da nicht mehr. > Da muss jeder Knoten mithören (was sie sowieso tun) und > erkennen, wenn der Vorgänger gesendet hat. Dann muss der Knoten senden, > alle anderen halten die Klappe. Damit erreicht man minimale Kollisionen > und maximale Busauslastung. Allerdings bleibt dann die Kommunikation komplett stehen, wenn einer der Knoten mal nicht da ist.
Frank K. schrieb: > Ohne jegliche derartige Maßnahmen wirst Du exzessiv Kollisionen bekommen Wieso denn Kollisionen? Die Nachrichten niedriger Priorität verschieben sich bei CAN doch einfach nur bis in einen Slot wo sie dann die höhere Priorität haben ... LG, Sebastian
Rolf M. schrieb: > Falk B. schrieb: >> Nö, aber wenn alle Knoten unsychronisiert senden wollen, gibt es viel >> Stau (Kollisionen beim Buszugriff) und sie behindern sich gegenseitig. > > Kollisionen gibt es bei CAN nicht. Jaja, aber der Buszugriff kommt nicht, bzw. verzögert zustande, wenn 16 Knoten mit DAUERFEUER versuchen, CAN-Meldungen zu senden! https://de.wikipedia.org/wiki/Controller_Area_Network#Arbitrierung,_Priorit%C3%A4t
Rolf M. schrieb: > Allerdings bleibt dann die Kommunikation komplett stehen, wenn einer der > Knoten mal nicht da ist. Tja, wenn beim Token Ring der Token verloren geht, ist Schicht im Schacht ;-) Dann muss der Steiger, ähhh, Master schauen was geht und die Runde neu starten.
Falk B. schrieb: > Jaja, aber der Buszugriff kommt nicht, bzw. verzögert zustande, wenn 16 > Knoten mit DAUERFEUER versuchen, CAN-Meldungen zu senden! Es soll ja nur jeder Knoten einmal alle x ms eine Nachricht mit 32 Bit Nutzdaten senden. Wenn x also so gewählt ist dass die Busbandbreite nicht völlig ausgefüllt wird dann sollte es auch ohne Synchronisation der Knoten funktionieren dass jeder Knoten an die Reihe kommt. Jedenfalls habe ich CAN bisher so verstanden (und erlebt). LG, Sebastian
Also ich möchte CAN Low Speed machen, weil das Konzept besser von der Terminierung her passt. Also mehr als 125 KBit/s geht dann ja nicht. Es sollen 16 Slaves an eine Master CPU angekoppelt werden. Buslänge ca. 50 cm. Da überlege ich doch auf SPI umzusteigen. Sollte einfacher gehen, aber hat eben keine automatische Fehlererkennung.
Dirk F. schrieb: > Es sollen 16 Slaves an eine Master CPU angekoppelt werden. > Buslänge ca. 50 cm. Ach herje! > Da überlege ich doch auf SPI umzusteigen. Tu das! > Sollte einfacher gehen, aber > hat eben keine automatische Fehlererkennung. Wozu auch? Bei 50cm bekommt man so stabil hin, da0 das nicht nötig ist.
Falk B. schrieb: > Rolf M. schrieb: >> Falk B. schrieb: >>> Nö, aber wenn alle Knoten unsychronisiert senden wollen, gibt es viel >>> Stau (Kollisionen beim Buszugriff) und sie behindern sich gegenseitig. >> >> Kollisionen gibt es bei CAN nicht. > > Jaja, aber der Buszugriff kommt nicht, bzw. verzögert zustande, wenn 16 > Knoten mit DAUERFEUER versuchen, CAN-Meldungen zu senden! Das hab ich ja geschrieben. Falk B. schrieb: > Rolf M. schrieb: >> Allerdings bleibt dann die Kommunikation komplett stehen, wenn einer der >> Knoten mal nicht da ist. > > Tja, wenn beim Token Ring der Token verloren geht, ist Schicht im > Schacht ;-) Ja, wer kennt ihn nicht, den Toten Ring? 😉
Falk B. schrieb: > Stopfbits kommen nach 5 gleichen Bits eingefügt, also maximal 79/5 = 16 > Bit. Real sind es wohl eher 5 oder weniger, denn so viele gleiche Bits > gibt es statistisch eher nicht. Vermutlich eher noch weniger. Nur wenn man schon dabei ist den Bus nahe 100% auszulasten, ein möglicher Stolperstein. Falk B. schrieb: > Jaja, aber der Buszugriff kommt nicht, bzw. verzögert zustande, wenn 16 > Knoten mit DAUERFEUER versuchen, CAN-Meldungen zu senden! Ähm, wenn jeder Knoten sauber nur seine individuelle ID sendet, sollte es gar keine Probleme geben. Dirk F. schrieb: > Also ich möchte CAN Low Speed machen, weil das Konzept besser von der > Terminierung her passt. Also mehr als 125 KBit/s geht dann ja nicht. > Es sollen 16 Slaves an eine Master CPU angekoppelt werden. > Buslänge ca. 50 cm. > Da überlege ich doch auf SPI umzusteigen. Sollte einfacher gehen, aber > hat eben keine automatische Fehlererkennung. Muss mit den Daten etwas in Echtzeit passieren? Oder spricht etwas dagegen den Overhead zu reduzieren und alle 8 Bytes einer Nachricht zu verwenden? Der Aufwand 16 bzw. 17 Transceiver zu nutzen, nur um schon eine "fertige" Fehlererkennung zu haben erscheint mir fragwürdig. Geld spielt wohl keine Rolle?
Wenn du mit einem Master und den Rest als Slaves nutzen willst, dann kannst du auch mit Request Messages (mit gesetzten RTR Bit) arbeiten. Beim Request wird nur der Header gesendet. Ich gerade überlegen ob der "Empfänger" unmittelbar auffüllt 🤔 Das nutzt man sonst so selten 🙈 Jedenfalls bekommt man damit ein gezieltes Frage-Antwort-Verfahren hin. Bei 50cm Buslänge sehe ich auch kein Problem in der Terminierung bis 1Mbit 🙄 Im Auto liegen mehrere Meter.
Dirk F. schrieb: > Sollte einfacher gehen, aber hat eben keine automatische > Fehlererkennung. CAN erkennt auch nicht alle Fehler. Zum Beispiel ist auch bei CAN nicht völlig ausgeschlossen dass eine Nachricht verlorengeht. Wenn SPI eine Alternative ist, also es einen Master gibt der die Knoten reihum abfragen kann, dann ist die Berechnung und Kontrolle einer Prüfsumme keine Herkulesaufgabe. LG, Sebastian
Hi, ach Gott, bei 50cm Bus kann man ganz entspannt 500kBit nehmen, die auch noch mit einer einseitigen Terminierung an nur einem Node (60Ohm) ohne Stress arbeiten. Und nein, es gibt keinen Arbitrierungszeitverlust bei Kollisionen: Wäre ja schlimm, wenn dem so wäre, dann müsste man ja die Nodes synchronisieren, was im z.B. Kfz niemand tut. Bei 17 Nodes und 121Bit/frame (64bit Nutzdaten). Könnte man dann locker mit 10ms Zykluszeit auskommen. Wenn es gesondert gesichert werden soll, dann noch Alive-Counter und zusätzliche Checksumme in die Botschaft und das war es. Grüsse Frank
Dirk F. schrieb: > Es sind 16 CAN Knoten vorhanden, die so oft wie möglich je 2 Integer > senden sollen. Ich kenne den Hintergrund dieser Planung nicht. Sowas macht man mit CAN entweder als intellektuelle Fingerübung (wie bekommt man einen Umzug mit einem Ferrari erledigt?) oder als verzweifelte Notlösung, wenn man eine fehlgeplante Hardware benutzen muß. Sonst kommen noch irgendwelche Anfänger daher und wollen sowas als ernsthafte Lösung verkaufen (auf mikrocontroller.net wurde das aber so gemacht!). Ich schreibe das, weil ich schon einen Professor habe sagen hören, CAN sei nicht echtzeitfähig, weil ein hochpriorisierter Dienst den ganzen BUS belegen kann. Für den waren nur Interbus-S und ASI echtzeitfähig (die für genau die hier anvisierte Problemstellung optimiert sind). Just my 2 cents P.S. Für die Anfänger: CAN ist ein priorisierter BUS. Adressiert werden Dienste, nicht Knoten. Im Idealfall haben keine 2 Dienste dieselbe Wichtigkeit.
Beitrag #7277203 wurde vom Autor gelöscht.
Falk B. schrieb: > wenn alle Knoten unsychronisiert senden wollen, gibt es viel > Stau (Kollisionen beim Buszugriff) und sie behindern sich gegenseitig. Das interpretiere ich geringfügig anders. Der mit der höchsten Prio setzt sich durch und alle Anderen kommen nicht durch. Die Unterlegenen müssten den Höchstpriorisierten erkennen und dürfen nach ihm nur 1 (in Worten:eine) erfolgreiche Meldung absenden und müssen dann die Klappe halten. Der Höchstpriorisierte muß erkennen, daß er der Häuptling ist und muß nach einer erfolgreichen Meldung schweigen und mitzählen, bis 16 Meldungen durch sind und sendet dann genau einmal wieder und alles geht von vorn los. Die 15 niedriger Priorisierten werden von der CAN-Arbitrierung auf Linie gebracht, so daß sogar die Reihenfolge der Knoten vorherbestimmt ist. Das sollte eine endlose Kette ohne Unterbrechung ergeben. Sollte ein Teilnehmer ausfallen gibt es eine Pause und der Programmierer darf aussuchen, welches Verhalten dann dem Problem am Besten angemessen ist (neuer Häuptling oder nur Reduktion auf 15 Teilnehmer oder Meldung an Hauptstelle oder oder oder). Gruß Klaus (der soundsovielte)
Ich komme bei 16*4 Byte Nutzdaten mit Overhead auf etwa 1,5ms. Wenn also alle Teilnehmer alle 2ms senden, bist Du auf der sicheren Seite. 10ms reichen daher dicke.
:
Bearbeitet durch User
Peter D. schrieb: > Ich komme bei 16*4 Byte Nutzdaten mit Overhead auf etwa 1,5ms. Bei 125 KBit/s ??????
Peter D. schrieb: > Ich komme bei 16*4 Byte Nutzdaten mit Overhead auf etwa 1,5ms. > Wenn also alle Teilnehmer alle 2ms senden, bist Du auf der sicheren > Seite. > 10ms reichen daher dicke 125kbit/s : 79 bit/Nachricht : 16 Knoten = 99 Nachrichten / Knoten und s 10ms reichen also nicht. Zumal - wie oben schon jemand anmerkte - Stuff bits noch gar nicht berücksichtigt sind. Generell: "so schnell wie möglich" funktioniert bei CAN nicht, weil dann höhere IDs nie zum Zug kommen. CAN, mit einem CSMA/CA-Buszugriffsverfahren verträgt zwar mehr, aber grundsätzlich sollte man einen Bus nur auf 50% Auslastung auslegen. Geh auf 250kBit, dann gehen 10ms Zykluszeit.
Anonymer User schrieb: > Geh auf 250kBit, dann gehen 10ms Zykluszeit. Um bei der CAN Spezifikation "LOW SPEED" zu bleiben: 125 KBit/s >> 20 ms mit 50 % Reserve.
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.