mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik CAN Bus und ACK


Autor: Madin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nach meinen Infos wird ein sendender Knoten nach nicht-erfolgreichem 
ACK-Bit (bleibt rezessiv) seinen Frame erneut versuchen zu senden. Hört 
der irgendwann auf dies zu versuchen? Z.B. wenn der Ziel-Knoten vom Buss 
abgeschaltet ist, sollte er das. Es kommt ja sonst u.U. zum totalen 
Blockieren dieses Knoten.

Autor: Stefan Kleinwort (_sk_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Z.B. wenn der Ziel-Knoten vom Buss
>abgeschaltet ist, sollte er das. Es kommt ja sonst u.U. zum totalen
>Blockieren dieses Knoten.

Das ACK sendet jeder Controller, der die msg korrekt erhalten hat. Auch 
wenn er die msg anschliessend verwirft. Dieses Verhalten (ständiges 
ACK-Senden bekommst Du eigendlich nur, wenn nur ein einziger 
Busteilnehmer (nämlich der Sender) vorhanden ist.

Gruß, Stefan

Autor: Madin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das ACK sendet jeder Controller, der die msg korrekt erhalten hat.

Und genau den Fall dass die Msg ebend nicht korrekt erhalten wurde, will 
ich hinterfragen.
Ich merke das nämlich bei meinem µC ---- CANoe
Schalte ich CANoe aus und lasse den µC auf Knopfdruch einen Frame 
senden, so sendet er scheinbar unaufhörlich.... bis ich CANoe einschalte 
und dort die Message angkommt.

Dieses ständige Wiederolen der Nachricht kann doch so nicht sein... oder 
wird sie bei der nächsten vom Host kommenden Nachricht überschrieben?

Autor: Patrick (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo Madin,

>>Dieses ständige Wiederolen der Nachricht kann doch so nicht sein..

doch, sofern der Sender einen Ack Fehler erkennt, sendet er die 
Botschaft noch einmal. Das besondere am Ack Fehler ist, dass der Tx 
Fehlerzähler nicht bis zum BusOff hochgezählt wird, sondern der Sender 
nur passiv wird. Daher hört er auch nicht auf.

Gruß
Patrick

Autor: Obelix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Senden mußt du selbst (Dein Programm) stoppen. Werte dazu den 
Fehlerzähler aus.

Autor: Madin (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
achso läuft das.

> Fehlerzähler nicht bis zum BusOff hochgezählt wird, sondern der Sender
> nur passiv wird.

In meiner Übersicht (von vector) zählt er in 8er Schritten das TEC hoch. 
Jedoch nur bis 127. Danach wohl nicht mehr. Also bleibt er immer 
"Error-activ".

Autor: rothy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich dachte bisher dieses das pausenlose Wiederholen gilt nur für die 
allererste Nachricht die ein CAN-Kontroller sendet nachdem er an den Bus 
gegangen ist. Danach können wiederholte ACK-Fehler auch zum 
"Error-activ" führen.
Liege ich hier falsch?

Autor: DB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Errorcounter erhöht sich mit jedem Fehler um 8 mit jeder Fehlerfrei 
übertragenen Nachricht wird der Counter um 1 verringert.
Werden also also nach einem Fehler mehr als 8 Frames richtig versandt 
wird der Counter auf 0 gesetzt.

Aufgrund dieses Counters wird der Bus in drei Zustände eingeteilt

error active (normal) bis 126
error passive (Teilnehmer darf nur noch passive – das heißt rezessive – 
Error-Frames senden)   -> ab 127
bus off (Teilnehmer darf nicht mehr senden) -> ab 256

Je nachdem welchen Controller man verwendest kann man dann irgendwelche 
ErrorInterrupts aktivieren und z.B. einen Reset durchführen oder 
Ähnliches.

Ob es sich um den gleichen Fehler oder Verschiedene handelt kann der 
Errorcounter nicht erkennen. Er zählt einfach nur ob ein Fehler passiert 
ist oder nicht.

Autor: Frank Bockwurst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
einfach mal die ISO11898-1:2003 lesen :-)

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim ATMega16M1 kann ich dir sagen das dieser ununterbrochen senden wenn 
es keinen weiteren Teilnehmer am Bus gibt und ergo kein ACK kommt, habe 
noch keine Auswertung programmiert, sind nur die ersten versuche.

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die CAN-Unit im 90CANxx und 16M1 sendet automatisch weiter wenn sie die 
Botschaft nicht los wird, ja.

Mal davon ab, dass das bei einem CAN-Teilnehmer ja auch nicht weiter 
stört und ich daher auch noch nichts dagegen gemacht habe,
ich wüsste spontan auch nicht, wie man eine Message-Box einfach nur vom 
weiteren Senden abhält.
Okay, man könnte die CAN-Unit resetten und neu initialisieren.

Wichtiger als das dauerhafte Senden zu unterbinden ist doch dafür zu 
sorgen, dass sich das Programm nicht dadurch aufhängt das die 
Message-Box dauerhaft beschäftigt ist.

Wenn ich die Verbindung trenne läuft der Rest des Programmes einfach 
weiter.

Autor: Bronco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rudolph schrieb:
> Wichtiger als das dauerhafte Senden zu unterbinden ist doch dafür zu
> sorgen, dass sich das Programm nicht dadurch aufhängt das die
> Message-Box dauerhaft beschäftigt ist.

Nein.
Ein Grundprinzip von CAN ist es, dass ein einzelner fehlerhafter 
Teilnehmer nicht den gesamten Bus lahmlegen darf. Aus diesem Grund ist 
das von DB oben beschriebene Error-System eingebaut:
Wenn der CAN-Controller (also die CAN-Hardware, nicht Deine Software) 
merkt, dass er den Bus stört (oder stören könnte), koppelt er sich 
selbständig schrittweise ab (ACTIVE -> PASSIVE -> BUS OFF).

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie geschrieben, wenn der Fehler dadurch auftritt, dass nur ein 
Teilnehmer am Bus ist - egal.

Aber okay, ja, es könnte ja einen anderen Grunde dafür geben, dass das 
ACK nicht erkannt wird.

Die Beschreibung im Datenblatt vom Mega16M1 finde ich jetzt etwas 
seltsam.
In "Figure 19-12" wird im Zustandsdiagramm der Übergang von "Error 
passive" auf "Bus off" bei "TEC > 255" dargestellt.
Dabei hat das CANTEC Register aber nur 8 Bit.

Es fehlt auch eine Beschreibung, wie REC und TEC bedient werden.

Da TEC ja der Transmit-Error-Counter ist ist zu vermuten, dass dieser 
bei erfolgreich Transfers runtergezählt und bei fehlgeschlagenen 
Transfers erhöht wird.
Nur, wenn das der Fall ist kommt man aus dem "Bus off" ja nicht wieder 
raus
weil Senden ja nicht mehr passieren darf?

Auf der anderen Seite suggeriert das Datenblatt das der Zustands-Automat 
dazu in Hardware implementiert ist, im CANGSTA Register gibt es das BOFF 
Bit: "BOFF gives the information of th state of the CAN channel.".

Das ist nur nicht, was man auf dem Scope sehen kann, ohne anderen 
Teilnehmer versucht die Message-Box einfach weiter die Botschaft 
loszuwerden, bisher habe ich nicht beobachtet, dass das auch irgendwann 
aufhört.

Autor: Bronco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
BUS OFF schaltet nur den Transmitter ab, der Receiver bleibt aktiv.
Wenn Du im BUS OFF bist und der Receiver 128x 11 rezessive Bits auf dem 
Bus gesehen hat, geht der CAN-Controller selbständig wieder aus BUS OFF 
heraus und der Transmitter kann wieder senden.
Der Sinn ist, das sich das System selbständig wieder herstellt, falls 
nur eine temporäre Störung (EMV etc.) vorgelegen hat.

Rudolph schrieb:
> Das ist nur nicht, was man auf dem Scope sehen kann, ohne anderen
> Teilnehmer versucht die Message-Box einfach weiter die Botschaft
> loszuwerden, bisher habe ich nicht beobachtet, dass das auch irgendwann
> aufhört.
Kann ich jetzt so auch nicht verstehen. Wo steht den der TEC in diesem 
Fall?

Autor: Markus D. (mowlwurf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rudolph schrieb:
> Das ist nur nicht, was man auf dem Scope sehen kann, ohne anderen
> Teilnehmer versucht die Message-Box einfach weiter die Botschaft
> loszuwerden, bisher habe ich nicht beobachtet, dass das auch irgendwann
> aufhört.

Der ACK-Fehler wird gesondert behandelt.

Dazu steht im CAN-Standard 11898-1:
"If during system start-up only one node is on-line and if this node 
transmits some frame, it shall not get ACK, detect an error and repeat 
the frame. According to 13.1.4.2, c), 1), it may become error-passive 
but not bus-off."

Das heißt: solange nur ein Teilnehmer im Bus vorhanden ist, wird dieser 
sein zu sendendes Telegramm solange wiederholen, bis er von einem 
zweiten Teilnehmer ein ACK bekommt. Dabei geht er nur in den 
Passive-error Zustand.

: Bearbeitet durch User
Autor: Steffen Rose (steffen_rose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein ACK Error tritt nur auf, wenn kein weiterer Teilnehmer am Bus ist.

Die Sendewiederholung führt der CAN Controller autonom durch. Ein 
Blockieren der Applikation beruht dann eher darauf, dass man irgendwo 
eine while() loop hat und darauf wartet, dass der Sendepuffer frei wird.

Bei einem Ack Fehler geht der CAN knapp ins Passive rein. Die 
erfolgreiche Übertragung dieser einen Nachricht sollte somit dazu 
führen, dass der CAN sofort wieder ins Active wechselt. Den Fall konnte 
ich so aber noch nicht selbst beobachten. Sinngemäß durfte es heißen: 
Bei einem Ack Error wird der TX Error Counter nicht erhöht, wenn dieser 
>127 ist, d.h er ist mind. 128 == passive.

Ein Ack Error hat wenig damit zu tun, ob eine Nachricht erfolgreich oder 
nicht übertragen wurde. Im Falle einer nicht erfolgreichen Übertragung 
senden der empfangene Knoten ein Error Flag (sofern er Active ist, kann 
man es auch sehen). Dieses Error Flag signalisiert einen fehlerhafte 
Übertragung.

Autor: Rudolph (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Also okay, dann ist es ja in Ordnung wenn bei nur einem Teilnehmer 
dieser weiter versucht die Botschaft abzusetzen.

Die ganze Geschichte müsste eigentlich in der State-Machine der CAN-Unit 
implementiert sein, also wann das Ding in Passiv und Bus-Off geht sollte 
eigentlich in der Hardware stecken und über die Software nur abfragbar 
sein.

Aber REC und TEC werde ich mir bei Gelegenheit mal ansehen.

Und die wesentliche Maßnahme in der Software besteht wirklich darin, 
dass diese sich nicht dadurch aufhängt, dass die Message-Box nicht 
bereit wird neue Daten anzunehmen.

Weiter gehende Maßnahmen wie das Gerät auf sowas reagiert sind ja eine 
Frage der Anwendung, also wie kritisch der Verlust der Bus-Anbindung 
ist.

Ich habe zum Beispiel eine per CAN angesteuerten Prüfumgebung für andere 
Steuergeräte die ein Timeout implementiert hat.
Wenn für ein paar Sekunden keine Botschaften kommen wird der Prüfling in 
einen sicheren alles-aus Zustand gebracht.

Autor: Markus D. (mowlwurf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rudolph schrieb:
> Die ganze Geschichte müsste eigentlich in der State-Machine der CAN-Unit
> implementiert sein, also wann das Ding in Passiv und Bus-Off geht sollte
> eigentlich in der Hardware stecken und über die Software nur abfragbar
> sein.

So ist es.

Autor: Jans R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, sehr hilfreich
- @ http://helprace.com/heldpesk

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das wieder ein Politiker mitbekommt werden folgende Messages in 
CAN-Netzwerken wegen Diskriminierung von Minderheiten verboten:

Can_ack
Can_nack

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.