Hallo zusammen, Ich habe eine generelle Frage zu CAN-Netzwerken: Wir haben zwei CAN-Netzwerke, an die jeweils diverse Nodes angeschlossen sind (6x STM32F4 Controller mit MAX3059 CAN Tranceiver (Selbstentwickelte PCBs, 4 Wechselrichter, Datalogger). Zum Analysieren des Netzwerks verwenden wir ein VN1640 von Vector mit zugehöriger Software bzw. ein PCAN-USB. Die Buslast liegt auf beiden Bussen bei ca 30% bei 500kbit/s Es kommt nun vor, dass Nachrichten "verschwinden". Da CAN mit CSMA/CR arbeitet, sollten ja generell alle Nachrichten "ankommen", im Kollisionsfall die Nachricht mit der niedrigeren Priorität eben mit leichter Verzögerung. Sendet bspw. nur ein Node auf den CAN, ist dies auch der Fall. Wenn man die Nachrichten auf dem Bus auswertet kommen alle an. Sobald nun aber mehrere Nodes gleichzeitig senden, "verschwinden" teilweise Nachrichten: Sowohl die Transmit Error Counter bzw. Receive Error Counter der Nodes, als auch die Vector Auswertesoftware (CANalyzer) zeigen 0 Errorframes an, einzelne Nachrichten sind aber immer wieder nicht vorhanden (Auf Datalogger, im CANalyzer und auch mit PCAN) Es werden bspw. 4 Nachrichten im 20ms an die Wechselrichter gesendet. Diese senden insgesamt weitere 16 Nachrichten, teilweise mit 20ms, teilweise mit 100ms Zykluszeit. Einzelne Nachrichten haben dann kurze Ausfälle, und werden somit erst nach 40ms, 60ms oder 80ms wieder gesendet. Manche Nachrichten betrifft dies stärker als andere, es gibt jedoch keinerlei Zusammenhand zur Priorität Dieser. Auf den Controllern ist die Standard Peripherals CAN Library implementiert. Zum versenden wird die Funktion CAN_Transmit() verwendet. Sind alle 3 Mailboxes voll, wird die jeweilige Nachricht in einem Ringpuffer gespeichert und dann sobald wie möglich über den Transmit Mailbox Empty Interrupt versendet. Auf den Controllern ist zumTeil FreeRTOS implementiert, zum Teil ein selbstentwickelter Scheduler. Bei Beidem wurde anaylsiert, das sämtliche Tasks im richtigen Zeitraster aufgerufen werden, die Nachrichten auch tatsächlich in den Transmit-Mailboxes landen, keine Buffer überlaufen etc. Jeder Bus ist mit zwei 120 Ohm Abschlusswiderständen versehen und läuft, solange nur die Niederspannungsseite des Systems an ist, mit 0 Errorframes auch über einen längeren Zeitraum. Das Verhalten tritt an zwei verschiedenen Kabelbäumen in etwa dem selben Maße auf. Ein sehr ähnliches System wurde bereits im letzten Jahr verwendet (Software wie Hardware). Dort trat dieses Problem nie auf. Das Verhalten ist dasselbe, egal ob mit Datalogger, Vector VN1640 oder PCAN-USB "gemonitored" wird. Auch ein Tausch der CAN-Tranceiver (von MAX3059 auf MCP2551) führte zum jeweils exakt selben Verhalten. Rein hardware-mäßig ist die Analyse schwierig. Wir haben zwar einen einfachen Logic Analyzer, mit diesem ist es uns jedoch nicht möglich, festzustellen, an welcher Stelle die Nachrichten noch kommen (Da Ausfälle i.d.R < 1%) Nun zur Frage: Hat jemand irgendeinen Ansatz oder eine Erklärung für dieses Phänomen? Oder noch besser Ansätze wie man das verhindern bzw. die Fehlerursache eingrenzen kann?
Formula Student Electric? ;-)
Sind die Bus-Kabel geschirmt?
Könntest du einen Controller so programmieren dass er einen Pin auf
"High" setzt, wenn eine Nachricht hätte kommen sollen, aber nicht kommt?
Dann könntest du ein Oszilloskop darauf triggern, und gleichzeitig den
CAN-Bus aufzeichnen lassen, sodass du eventuelle Störungen zu diesem
Zeitpunkt sehen kannst.
Allgemein sollte man vielleicht sagen "ein bisschen Verlust ist immer",
und die Software so auslegen, dass der Verlust einzelner Nachrichten
nicht das System lahmlegt.
Könnte es sein dass die Nachrichten zwar bei einem ("nahen") Controller
ankommen (und dieser ACK sendet s.d. der Controller keinen Fehler
bemerkt), aber eben nicht bei allen? Mal die CAN-Logger an verschiedene
Stellen im Bus geklemmt?
Das Problem kommt mir bekannt vor, ich hatte vor einer Weile versucht, einen CAN-Router zu bauen, der durch Dauerfeuer (mit recht großen Pausen zwischen den Paketen) vom ersten Bus den Rückkanal vom zweiten auf den ersten verstopft bekam. Ich habe es damals nicht weiter verfolgt, anscheinend ist das CAN-Modul zu lahm, in meinem Fall war vermutlich der Zwischenspeicher voll, dann war es aber zu spät, einzugreifen. Microchip hat das besser gelöst, da gibt es iirc auch Interupts für halbvolle Empfangspuffer. Außerdem ließ sich scheinbar der Interrupt des einen Moduls nicht während des Empfangs des anderen Moduls deaktivieren, jedenfalls funkte es dann immer noch bei gleichzeitigem Empfang dazwischen.
An der STM Hardware wird es nicht liegen, wir haben hier einen CAN-Router/Gateway gebaut der auch 99% Buslast auf beiden Kanälen problemlos dauerhaft schaft.
Hallo zusammen, erstmal danke für die schnellen Antworten. Formula Student Electric ist richtig ;) Alle Busleitungen sind geschirmt. Störungstechnisch haben wir auch keine Probleme. Das ganze System ist auch so ausgelegt, dass der Verlust einzelner Nachrichten kein Problem darstellt, außerdem sind überall timeouts implementiert, so dass das System im Falle von zu vielen nicht angekommenen Nachrichten in einen sicheren Zustand schaltet, egal um welches Node es sich handelt. Interessant ist eben, warum es zu dem "Verlust kommt". Das mit dem Oszi ist auf jeden Fall eine gute Idee, ich werde mal schauen was sich da realisieren lässt. Generell geht das natürlich nur mit unseren eigenen Controllern und nicht mit Wechselrichtern und Dataloggern. ACK ist ein guter Gedanke, Wechselrichter und mit ihm kommunizierende Controller sind jedoch "direkt nebeneinander" und auch hier kommt es zu Verlusten. Die STM Hardware schließe ich auch aus, da wir diese bereits letztes Jahr in Kombination mit anderen Wechselrichtern verwendet haben, und keinerlei Probleme hatten. Generell sollte es ja möglich sein, jede Nachricht mit beliebig vielen Nodes zu empfangen. Kann es hier dann vllt. dennoch generell zu Problemen kommen, wie eben auch dem angesprochenen ACK eines Controllers? Die kleineren Nodes haben Hardwarefilter, die beiden großen Controller empfangen aktuell alle Nachrichten, da sie eh 60-70% davon weiter verarbeiten. Auf Wechselrichter und Datalogger hat man natürlich eh keinen Einfluss
Ein Hardwareproblem würde ich ausschließen. Wir hatten vor einiger Zeit ein ähnliches Phänomen. Der Bus war ebenfalls zu 35% ausgelastet, aber in unregelmäßigen Abständen traten Errorframes auf . Bei uns lag es damals daran, dass eines der Steuergeräte seinen Tx Frame für ein paar Millisekunden nicht loswurde, weil höher priore Nachrichten den Bus zu genau der Zeit blockierten. Das Steuergerät hat dann "aus Protest" einen Errorframe erzeugt. Hätte es dies nicht getan so wäre das Verhalten exakt identisch zu dem Euren gewesen. So wie du das beschreibst hast du Logfiles mit Zeitstempeln. Schau doch mal ob an der Stelle an der eine bestimmte Nachricht fehlt mehrere Nachrichten mit höherer Priorität direkt hintereinander auf dem Bus liegen. In CANoe werden im CAN Statistik Fenster solche Datenpaketketten als "Bursts" angezeigt. Mein Workaround damals war übrigens dem Tx Frame des problematischen Steuergerätes die höchste Priorität zu geben. Nicht schön aber es funktioniert... Viel Erfolg bei der Fehlersuche!
Simon O. schrieb: > Nun zur Frage: Hat jemand irgendeinen Ansatz oder eine Erklärung für > dieses Phänomen? Wenn keine Error-Frames kommen liegt es an der Software auf der Senderseite. (Sendebuffer überschrieben bevor gesendet wurde). Gruß Anja
Das Problem tritt auch mit Nachrichten auf, die vom STM32 gesendet werden, ja? Hast du bei diesen das automatische Sende-Widerholen bei Fehler abgeschaltet (NART bit im CANx->MCR register bzw. CAN_InitTypeDef::CAN_NART gesetzt)? Wenn nein, müsste der Controller das Senden so lange wiederholen, bis das ACK bit kommt. Da bei dir ja scheinbar nicht wiederholt wird, bedeutet das, dass das ACK bit eben kommt, von irgendeinem Controller der die Nachricht doch korrekt empfängt. Kannst du herausfinden ob ein Controller doch alle Nachrichten bekommt? Könnte es an Stichleitungen liegen, dass Nachrichten nicht überall ankommen? Simon O. schrieb: > Jeder Bus ist mit zwei 120 Ohm Abschlusswiderständen versehen und läuft, > solange nur die Niederspannungsseite des Systems an ist, mit 0 > Errorframes auch über einen längeren Zeitraum. Simon O. schrieb: > Störungstechnisch haben wir auch keine > Probleme. Das klingt aber als würde das Tractive System da irgendwie stören?! Wir haben in unserem Auto auch gelegentliche Störungen dadurch, aber nicht weiter nachgeforscht...
Wenn es ganz blöd läuft ist der Bus bei schnellen Botschaften und blödem Timeing kurz so voll dass eine Botschaft nicht gesendet werden kann weil kein "Slot" da ist aber dann schon die nächste Botschaft raus soll. Je na Konfigutation geht die erste dabei hops. Darum wird in echten Fahrzeugen auch alle so ausgelegt dass sogar für Sicherheitskritische Funktionen Botschaften für ein paar Botschaftszeiten ausfallen dürfen bevor man reagiert. Ist hald CAN, der ist nicht deterministisch.
Prinzipell erstmal mit dem Analyser prüfen, was auf dem Bus los ist. Dann kann man eindeutig sagen, ob die Nachrichten verloren gehen. Eure eigenen Transceiver arbeiten korrekt? Beim Sender muss man aufpassen, dass man nicht in einen Sendepuffer schreibt, der noch voll ist. Ggf. ignoriert ihr entsprechende Fehler. Störungen auf dem Bus werden durch Errorframes angezeigt. Da reicht es, dass einer den Fehler sieht. Beim Empfänger kann es auch Overflows geben. Dies erkennt man ua auch daran, dass einige Knoten die Nachricht emfangen und andere nicht.
Hallo zusammen, Danke erstmal für die schnellen, weiteren Antworten. Störungstechnisch haben wir wie gesagt keine großen Probleme. Wenn nur die LV Seite an ist, haben wir gar keine Störungen, bei aktiviertem Tractive System gibt es sporadisch mal ein paar Error-Frames (i.d.R. weniger als einen pro Sekunde) und ich denke das ist bei 600V / 200A maximum ok oder? Das "Verschwinden" tritt eben auch bereits bei nur LV und 0 Error-Frames auf. Um weitere hardware-seitige Tests zu machen hatten wir leider jetzt keine Zeit mehr, aber ich konnte zumindest mal mit dem NART bit im CANx->MCR Register testen: NART (No-automatic retransmission) war bis jetzt auf ENABLE, also wurde bei Fehler NICHT nochmals gesendet. Da es auf dem Bus keine Error-Frames gab, bin ich davon ausgegangen dass das Senden eben klappt. Offensichtlich wird jedoch vom sendenden Controller selbst ein Fehler erkannt, denn mit NART auf DISABLE "verschwinden" keine Nachrichten mehr. Wenn ich mir die Zykluszeiten jetzt anschaue, scheint es in ähnlichen Abständen, wie denen, in denen früher die Nachrichten gar nicht ankamen, zu leichten Verzögerungen (< 1ms) zu kommen. Das bedeutet für mich, dass der sendende Controller eben einen Fehler erkennt und dann automatisch nochmals sendet. Die Frage ist jetzt, wo der Fehler liegen könnte. Der STM32 hat 3 "Transmit-Mailboxes", in die zu verschickende Nachrichten geschrieben werden. Ab dann hat man keinen Einfluss mehr. Die Funktion CAN_Transmit() der Standard-Peripherals-Library prüft, ob eine dieser Mailboxes frei ist. Falls dies nicht der Fall ist, schreibe ich die Nachricht in einen Ringpuffer und aktiviere den "CAN_IT_TME", also den Transmit-Mailbox-Empty Interrupt. Die Nachricht wird dann vom Interrupt gesendet, sobald wieder eine Mailbox frei ist. Falls jemand in diesem System ein Problem sieht, oder eine bessere Lösung weiß darf er mir dies gerne schreiben. Generell funktionierte dieses System aber das gesamte letzte Jahr ohne Probleme, mein eigener Ringpuffer enthält nie mehr als 3-4 Nachrichten und über das Prüfen der Mailboxes und ggf. das Senden über die ISR sollte doch eigentlich sichergestellt sein, dass kein Sendepuffer überschrieben werden kann. Ich kann mir nicht ganz erklären, wie der sendende Controller einen Fehler sieht und dementsprechend neu sendet, auf dem Bus aber keine Error-Frames vorliegen. Da der Controller aber ja offensichtlich neu sendet, habe ich erwartet, dass zumindest der CAN Transmit Error Counter ansteigt. Sowohl Transmit als auch Receive Error Counter stehen jedoch die ganze Zeit auf Null. Hat hierfür jmd. eine Erklärung? Bei uns steht jetzt direkt das nächste Event an, anschließend werde ich versuchen das ganze hardwareseitig noch genauer zu analysieren und die Vorschläge hier mit einzubeziehen.
Simon O. schrieb: > NART (No-automatic retransmission) war bis jetzt auf ENABLE, also wurde > bei Fehler NICHT nochmals gesendet. Da es auf dem Bus keine Error-Frames > gab, bin ich davon ausgegangen dass das Senden eben klappt. > Offensichtlich wird jedoch vom sendenden Controller selbst ein Fehler > erkannt, denn mit NART auf DISABLE "verschwinden" keine Nachrichten > mehr. In normalen CAN Umgebungen wird der retransmit nicht abgeschaltet. Eine Fehlerkorrektur ist erwünscht. Er wird nur in Realtime Umgebungen, wie TTC, abgeschaltet, um den Bus in einem kalkulierbaren Zustand zu halten. Natürlich ist es dann an der Software auf Fehler zu reagieren. Simon O. schrieb: > Ich kann mir nicht ganz erklären, wie der sendende Controller einen > Fehler sieht und dementsprechend neu sendet, auf dem Bus aber keine > Error-Frames vorliegen. > Da der Controller aber ja offensichtlich neu sendet, habe ich erwartet, > dass zumindest der CAN Transmit Error Counter ansteigt. Sowohl Transmit > als auch Receive Error Counter stehen jedoch die ganze Zeit auf Null. Ich weiß garnicht, ob die Error Counter im TTC mode überhaupt funktionieren. Für den Fall Retransmission aktiv sollten die Error Counter kurz hochzählen. Vielleicht verpasst Du den Augenblick? Bit 15 ERRIE: Error interrupt enable Der Error Interrupt könnte hier evtl. helfen.
Dazu noch eine Frage: Wenn es zu einer Kollision kommt aufgrund gleichzeitigem Senden, "gewinnt" ja das rezessive Bit, also die Nachricht mit der niedrigeren Priorität. Was passiert in diesem Fall wenn NART enabled bzw. disabled wird? Ich gehe davon aus dass kein Error-Frame gesendet wird, da die höher-priore Nachricht ja ohne Unterbrechung fertig gesendet wird, die niedrigere dann sobald wie möglich danach nochmals gesendet werden sollte. Wird diese dann bei NART enabled nicht nochmals gesendet?
kurze Korrektur: - dominant gewinnt (rezessive ist der Ruhepegel) - dominant ist Wert 0 => Daher gewinnt die '0'. - bei CAN gibt es keine Kollisionen -> hier Arbitierung Die Arbitrierung löst kein Error Frame aus. Zum Verhalten bei mehreren Nachrichten, während der Retransmit ausgeschaltet ist, kann ich nichts sagen, da wir kein TTC nutzen.
Bei gesetztem NART Bit ist dieses Verhalten normal. Sogar gewollt! Auszug aus dem Reference Manual: Nonautomatic retransmission mode This mode has been implemented in order to fulfil the requirement of the Time Triggered Communication option of the CAN standard. To configure the hardware in this mode the NART bit in the CAN_MCR register must be set. In this mode, each transmission is started only once. If the first attempt fails, due to an arbitration loss or an error, the hardware will not automatically restart the message transmission. Falls der STM32 die Arbitrierung verliert (andere Nachricht hat eine höhere Priortät) wird das Senden dieser Nachricht einfach verworfen. Die Error-Counter werden nicht hochgezählt, da dies eigentlich keine Fehler sind. Du wirst bei einer weitern Hardware-Analyse auf dem Bus nichts finden.
Ich hatte das Problem, das der CAN Bootloader des STM einen anderen Samplepoint hatte als die Standard Einstellung meiner CAN PCI Karte. Der Software Download hat mit der USB Hardware vom selben Hersteller funktioniert, mit der PCI Karte nicht. Und da kommt es auch auf jede Nachricht an.
Danke nochmal für die schnelle Hilfe. Kam jetzt einiges dazwischen, aber mittlerweile konnte ich nochmal testen: Letztenendes lag tatsächlich alles an dem falsch gesetzten NART-Bit und beide CAN-Netzwerke funktionieren jetzt einwandfrei.
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.