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.
>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
> 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?
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
Das Senden mußt du selbst (Dein Programm) stoppen. Werte dazu den Fehlerzähler aus.
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".
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?
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.
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.
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.
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).
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.
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?
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
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.
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.
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.
Wenn das wieder ein Politiker mitbekommt werden folgende Messages in CAN-Netzwerken wegen Diskriminierung von Minderheiten verboten: Can_ack Can_nack
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.