Hallo an alle, ich versuche gerade den Can Fehlerbehandlung zu verstehen. Mir geht es primär darum ob meine Gedanken richtig sind...Das Wissen dabei habe ich zum größtenteils auf der Verctor Homepageseite her. Nun zu den Fragen. Im Anhang befindet sich ein Teil des Can Netzwerk Topologie zur besseren Verständnis. Sei gegeben Fehler 1: Der Can Knoten ist vom Bus getrennt. Was passiert? Meine Antwort: Der Sender versucht die Telegramme zu schicken, aber bekommt keinen dominantes ACK, somit inkrementiert sich der tx-errorcounter bis 128 und geht in den error passiv Zustand. Sei gegeben Fehler 2: Nur Leitung RX ist unterbrochen. Was passiert? In diesem Fall erkennt das Bitmonitoring den Fehler, weil es Unterschiede zwischen den gesendeten Daten und Buspegel gibt. Wiederholt die Daten zu senden bis RX errorcounter auf 128 ist. Sei gegeben Fehler 3: Nur Leitung TX ist unterbrochen. Was passiert? Da kein ACK von den Empfänger ankommen wird, wird der tx-errcounter auch hier hochgezählt Ich hoffe ihr könnt mir dabei Helfen, da ich mit dem Skript vom Prof. nicht so ganz klar komme. Ich brauch die Sicherheit, dass ich es zumindest ansatzweise Verstanden habe. Vielen Dank und Grüße CS
dunno.. schrieb: > Kommt auf den rest des busses an. Ack senden alle knoten.. Genau. In diesem Fall sollte mein Schaubild nur ein ausschnitt sein mit mehreren Knoten. Wollte nur nicht, dass das "Schaubild" überladen wird. Sind meine Erklärungen in diesem Fall plausibel? LG
Counter S. schrieb: > Sei gegeben Fehler 1: Der Can Knoten ist vom Bus getrennt. > Was passiert? > Meine Antwort: Der Sender versucht die Telegramme zu schicken, aber > bekommt keinen dominantes ACK, somit inkrementiert sich der > tx-errorcounter bis 128 und geht in den error passiv Zustand. Richtig > Sei gegeben Fehler 2: Nur Leitung RX ist unterbrochen. > Was passiert? > In diesem Fall erkennt das Bitmonitoring den Fehler, weil es > Unterschiede zwischen den gesendeten Daten und Buspegel gibt. Wiederholt > die Daten zu senden bis RX errorcounter auf 128 ist. Ja wenn RxD floatend high ist. Wenn die offene Leitung auf Low geht wird ein dominater Pegel erkannt. Damit sollte der Knoten bereits in der Arbitrierung aufgeben, er glaubt dann der Bus wäre belegt. > Sei gegeben Fehler 3: Nur Leitung TX ist unterbrochen. > Was passiert? > Da kein ACK von den Empfänger ankommen wird, wird der tx-errcounter auch > hier hochgezählt Richtig.
soul e. schrieb: > Counter S. schrieb: > >> Sei gegeben Fehler 1: Der Can Knoten ist vom Bus getrennt. >> Was passiert? >> Meine Antwort: Der Sender versucht die Telegramme zu schicken, aber >> bekommt keinen dominantes ACK, somit inkrementiert sich der >> tx-errorcounter bis 128 und geht in den error passiv Zustand. > > Richtig Macht mein bxCAN nicht - der sendet bis zum Sankt-Nimmerleinstag..
dunno.. schrieb: > Kommt auf den rest des busses an. Ack senden alle knoten.. Nö, nur die Knoten senden ein ACK, die sich für eine Nachricht "interessieren" (also wo sie durch den Filter kommt). tinCAN schrieb: > Macht mein bxCAN nicht - der sendet bis zum Sankt-Nimmerleinstag.. So kenne ich das (leider) auch. Die Problematik ist aber eigentlich eher akademisch... Die Anzahl der Fälle in denen RX oder TX zwischen Transceiver und Controller unterbrochen wird, ist sehr klein. Beim Auto kann ich mir das gerade nur vorstellen, wenn es eh egal ist (Unfall bei dem das Steuergerät mechanisch beschädigt wird). Normalerweise ist der Fehler dann doch eher jenseits des Transceivers an den Busleitungen - Unterbrechung oder Kurzschluss (untereinander oder nach Masse/Versorgung).
mmm schrieb: >> Kommt auf den rest des busses an. Ack senden alle knoten.. > > Nö, nur die Knoten senden ein ACK, die sich für eine Nachricht > "interessieren" (also wo sie durch den Filter kommt). Ich kenne es auch so, dass alle formal korrekten Botschaften ein ACK erhalten, auch wenn sie niemanden interessieren. > Sei gegeben Fehler 3: Nur Leitung TX ist unterbrochen. > Was passiert? Auch hier sollte das Monitoring des RX - Pins schon einen Fehler zeigen, lange bevor man am ACK Bitslot ist. Der Transceiver sollte sein Ende der TX Leitung mit einem Widerstand so hinziehen, dass er daraus den Pegel für rezessiv macht. Sollte der TX Pin dauerhaft ein dominat befehlen, schlägt das Timeout im CAN-Transceiver zu. In allen diesen Fällen erkennt der CAN-Controller, dass die über RX gemeldeten Zustände des Busses nix mit dem zu tun haben, was er gerade ausgeben wollte. Bzw. erkennen alle Busteilnehmer eine Error-Condition, weil bei normaler Übertragung längst ein rezessives Stuffbit eingeworfen worden sein müsste. > Macht mein bxCAN nicht - der sendet bis zum Sankt-Nimmerleinstag.. Die Error Counter sind in Software (sprich im Can-Treiber) realisiert, oder halt nicht, wenn billig statt standardkonform bei der Entwicklung im Vordergrund stand.
tinCAN schrieb: > Macht mein bxCAN nicht - der sendet bis zum Sankt-Nimmerleinstag.. Falsch konfigurierte Softwarestacks zeichnen sich dadurch aus, dass ihr Verhalten nicht der Spezifikation entspricht. Unter Umständen kann das ja auch gewollt sein: ein Diagnosetester darf ruhig solange alleine in die Welt hineinsenden, bis ein Steuergerät angeschlossen wird und antwortet. So muss man das Anklemmen nicht jedesmal neu bestätigen. Geräte, die ausschließlich im Systemverbund laufen, sollten sich aber spezifikationskonform verhalten und error passive unterstützen.
mmm schrieb: > Die Problematik ist aber eigentlich eher akademisch... Du hast es erfasst! Ich selbst besitze kein Can Controller. Ich bereite mich nur für die Klausur vor. Da andere Freunde von mir auch nicht sicher waren und bis jetzt mikrocontroller.net immer mir helfen konnte, war ich gezwungen meine Fragen hier zu schreiben. LG
fop schrieb: > Auch hier sollte das Monitoring des RX - Pins schon einen Fehler zeigen, > lange bevor man am ACK Bitslot ist. > Der Transceiver sollte sein Ende der TX Leitung mit einem Widerstand so > hinziehen, dass er daraus den Pegel für rezessiv macht. Sollte der TX > Pin dauerhaft ein dominat befehlen, schlägt das Timeout im > CAN-Transceiver zu. > In allen diesen Fällen erkennt der CAN-Controller, dass die über RX > gemeldeten Zustände des Busses nix mit dem zu tun haben, was er gerade > ausgeben wollte. > Bzw. erkennen alle Busteilnehmer eine Error-Condition, weil bei normaler > Übertragung längst ein rezessives Stuffbit eingeworfen worden sein > müsste. Super Danke! LG CS
soul e. schrieb: > tinCAN schrieb: > >> Macht mein bxCAN nicht - der sendet bis zum Sankt-Nimmerleinstag.. > > Falsch konfigurierte Softwarestacks zeichnen sich dadurch aus, dass ihr > Verhalten nicht der Spezifikation entspricht. bxCAN ist HARDWARE..
soul e. schrieb: > Counter S. schrieb: > >> Sei gegeben Fehler 1: Der Can Knoten ist vom Bus getrennt. >> Was passiert? >> Meine Antwort: Der Sender versucht die Telegramme zu schicken, aber >> bekommt keinen dominantes ACK, somit inkrementiert sich der >> tx-errorcounter bis 128 und geht in den error passiv Zustand. > > Richtig Richtig? So schweigen sich z.B. zwei Knoten in einem zwei-Knoten-Bus gegenseitig an, auch nach dem sie wieder miteinander verbunden sind.
Restbus-Simulant schrieb: > Richtig? Was willst du uns sagen? > So schweigen sich z.B. zwei Knoten in einem zwei-Knoten-Bus gegenseitig > an, auch nach dem sie wieder miteinander verbunden sind. Kann man so nicht sagen. Ein Knoten besteht ja nicht nur aus dem CAN-Controller, sondern auch aus einem Mikrocontroller mit Firmware drauf. Geht der CAN-Controller in einen Fehlermode so hängt das weitere von der eigentlichen Firmware ab: Versucht diese zu einem späteren Zeitpunkt nochmals aktiv das Senden? Oder geht der Knoten in ein Notfallprogramm ohne Kommunikation? Oder schaltet er sich komplett ab? Oder....
mmm schrieb: > Nö, nur die Knoten senden ein ACK, die sich für eine Nachricht > "interessieren" (also wo sie durch den Filter kommt). Das ist falsch. Die message muss formal korrekt sein, dann gibts ein ack. Der Filter kommt erst danach.
Wenn lediglich das ACK vom Bus fehlt, sendet der Knoten natürlich weiter. Ggf bis zum Sankt-Nimmerleinstag. Aufgrund der ACK geht der Tx Errorcount hoch bis 128 und der Knoten ist dann Error passive. Aber auch in diesem Zustand darf der Knoten senden. Im Zustand Error Passive wird Tx Errorcounter bei ACK Fehler nicht inkrementiert.
> Sei gegeben Fehler 1: Der Can Knoten ist vom Bus getrennt. > Was passiert? > Meine Antwort: Der Sender versucht die Telegramme zu schicken, aber > bekommt keinen dominantes ACK, somit inkrementiert sich der > tx-errorcounter bis 128 und geht in den error passiv Zustand. Richtig. Und auch in error passive wird der Frame weiter wiederholt. Der Tx Errorcounter wird in error passive aber nicht aufgrund eines ACK-Fehlers inkrementiert. > Sei gegeben Fehler 2: Nur Leitung RX ist unterbrochen. > Was passiert? > In diesem Fall erkennt das Bitmonitoring den Fehler, weil es > Unterschiede zwischen den gesendeten Daten und Buspegel gibt. Wiederholt > die Daten zu senden bis RX errorcounter auf 128 ist. Wenn beim Senden der rückgelesene Pegel nicht dem gesendeten entspricht, wird aber nicht der Rx, sondern der Tx Errorcounter erhöht. Wenn die Leitung dauerhaft unterbrochen ist, versucht der Knoten fortlaufend den Frame zu senden und erhält ständig Bit Fehler. Nach 16 Versuchen (Tx Errorcount = 16*8 = 128) geht der Knoten nach Error passive. Nach 16 weiteren Versuchen (Tx Errorcount = 32*8 = 256) geht der Knoten nach BusOff. Dann sendet er wirklich nicht mehr. Empfang geht auch nicht mehr. Der Zustand kann nur verlassen werden, wenn das von außen angestoßen wird. (Erkennen und Behandeln des Busoff Zustands in der Software) > Sei gegeben Fehler 3: Nur Leitung TX ist unterbrochen. > Was passiert? > Da kein ACK von den Empfänger ankommen wird, wird der tx-errcounter auch > hier hochgezählt Eigentlich wie Fehler 2. Der Knoten geht auch ziemlich flott nach Busoff, wenn er versucht zu senden. Einziger Unterschied zwischen Fehler 2 und Fehler 3: Bei unterbrochener Rx Leitung ist der Empfang weiter möglich.
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.