CANopen SDO Abort Codes verstehen

Wer CANopen-Geräte in Betrieb nimmt, kennt die Situation: Ein SDO-Zugriff  auf ein Objekt schlägt fehl und das Tool meldet einen 32-Bit-Wert wie 0x06090011 oder 0x08000022. Ohne Nachschlagen sagt diese Zahl wenig aus – dabei enthält sie die entscheidende Information, warum der Zugriff abgelehnt wurde. Dieser Artikel erklärt den Aufbau der Abort Codes und zeigt für die Fälle, die in der Praxis tatsächlich auftreten, was wirklich dahintersteckt.

Was ist ein SDO Abort?

Der SDO-Dienst (Service Data Object) überträgt Konfigurations- und Diagnosedaten zwischen einem SDO-Client (meist ein CANopen-Manager (Master) oder ein Tool) und einem SDO-Server (dem adressierten Gerät). Kann eine laufende Übertragung nicht regulär beantwortet werden, bricht die Gegenseite sie mit einem Abort SDO Transfer ab.

Das Abort-Telegramm ist immer 8 Byte lang und wie folgt aufgebaut:

Byte	Inhalt
0	Command Specifier 0x80
1–2	Index des betroffenen Objekts (LSB zuerst)
3	Subindex
4–7	Abort Code, 32 Bit, LSB zuerst

Wichtig für die Trace-Analyse: Der Abort Code steht little endian auf dem Bus. Der Code 0x06020000 erscheint im Telegramm also als 00 00 02 06. Wer Traces von Hand liest, sollte sich diese Umkehrung merken – sie ist eine der häufigsten Verwechslungsquellen.

Ein Abort wird nicht quittiert. Er beendet die Übertragung sofort, und zwar in beide Richtungen: Auch der Client kann abbrechen, etwa bei einem eigenen Timeout oder wenn der Anwender einen laufenden Download abbricht.

Aufbau des Abort Codes

Der 32-Bit-Wert ist nicht willkürlich, sondern gegliedert:

Bits	Bedeutung	Typische Werte
31–24	Fehlerklasse	0x05 Protokollfehler, 0x06 Zugriffsfehler, 0x08 sonstige Fehler
23–16	Fehlercode innerhalb der Klasse	z. B. 0x04 bei Zugriffsfehlern
15–0	Additional Code, präzisiert den Fehler	z. B. 0x0011 für „Subindex existiert nicht“

Grob gilt: 0x05… betrifft das SDO-Protokoll selbst, 0x06… das Objektverzeichnis, 0x08… die dahinterliegende Applikation. Für die tägliche Arbeit ist diese Einteilung allerdings nur eine erste Orientierung – entscheidend ist der vollständige Code samt Additional Code, denn erst der benennt die konkrete Ursache.

CiA 301 definiert die Abort Codes

Die normative Quelle für alle definierten Abort Codes ist CiA 301 („CANopen application layer and communication profile“), im Abschnitt zum SDO-Protokoll. Dort sind sie vollständig und verbindlich tabelliert – inklusive der Werte, die man im Feld nie zu sehen bekommt. Das Dokument ist bei CAN in Automation erhältlich und gehört ohnehin auf den Rechner jedes CANopen-Entwicklers.

Diese Liste hier zu wiederholen, bringt niemandem etwas: Nachschlagen sollte man einen Abort Code ohnehin nicht in einer Tabelle, sondern sich vom Tool anzeigen lassen. Interessanter ist die andere Frage – welche Codes treten überhaupt auf, und was bedeuten sie jenseits ihrer Definition?

Die Codes, die in der Praxis wirklich auftreten

0x05040000 – SDO Timeout

Der mit Abstand häufigste Fehler bei der Inbetriebnahme, und derjenige, der am seltensten am Objektverzeichnis liegt. Typische Ursachen, in der Reihenfolge, in der man sie prüfen sollte:

• Falsche Node-ID. Der Client sendet auf 0x600 + Node-ID und wartet auf 0x580 + Node-ID. Stimmt die Knotennummer nicht, antwortet schlicht niemand.
• Gerät im NMT-Zustand Stopped. Im Zustand Stopped sind nur NMT und die Fehlerüberwachung aktiv – SDOs werden nicht bedient. Ein Enter Pre-Operational löst das Problem sofort. Details dazu im Artikel zum CANopen Netzwerkmanagement.
• Bitratenfehler oder fehlende Terminierung. Wenn gar keine Telegramme quittiert werden, ist der Bus das Problem, nicht CANopen.
• Zu kurzer Timeout beim Client. Geräte, die beim Schreiben in den Flash oder bei einem Store-Vorgang blockieren, brauchen länger als üblich. Manche Server senden zwar korrekt, aber verspätet.

Ein Blick in den Trace klärt das in Sekunden: Ist überhaupt eine Anfrage auf dem Bus zu sehen, und antwortet der Knoten mit irgendetwas?

0x06020000 – Objekt existiert nicht

Das Gerät kennt den Index nicht. Fast immer eine der drei Ursachen:

• Die verwendete EDS-Datei passt nicht zur tatsächlichen Firmware-Version des Geräts. Besonders bei herstellerspezifischen Objekten ab 0x2000 ein Dauerbrenner.
• Der Index wurde falsch eingegeben oder das Tool interpretiert die Byte-Reihenfolge anders als erwartet.
• Ein optionales Objekt ist im konkreten Gerät schlicht nicht implementiert. Viele Objekte aus CiA 301 sind optional – etwa 0x1015 (Inhibit Time EMCY) oder 0x1003 (Fehlerhistorie).

Vom Subindex-Fehler 0x06090011 unterscheidet sich der Code klar: Bei 0x06020000 fehlt das gesamte Objekt, bei 0x06090011 existiert es, aber der angefragte Subindex nicht. Bei Arrays lohnt sich dann ein Blick auf Subindex 0, der die Information über den höchsten implementierten Subindex liefert.

0x06010002 – Schreibversuch auf ein nur lesbares Objekt

Neben dem offensichtlichen Fall (Schreiben auf 0x1018 Identity Object) gibt es zwei Klassiker:

• Subindex 0 von Arrays und Records ist in vielen Objekten als const definiert und lässt sich nicht verändern.
• Änderung eines PDO-Mappings bei gültigem PDO. Nach CiA 301 muss zuerst Bit 31 im COB-ID-Eintrag des PDO gesetzt (PDO ungültig), dann Subindex 0 des Mapping-Parameters auf 0 geschrieben, dann das Mapping geändert, dann Subindex 0 auf die neue Anzahl gesetzt und zuletzt das PDO wieder gültig geschaltet werden. Wer diese Reihenfolge überspringt, bekommt je nach Stack einen SDO-Abort. Mehr dazu im Artikel zum PDO Linking.

0x06070010, 0x06070012, 0x06070013 – Längenfehler

Der Client hat eine andere Datenlänge geschickt, als das Objekt erwartet. In der Praxis fast immer ein Tool- oder Client-Problem, nicht ein Gerätefehler: Beim Expedited Download muss die Anzahl der gültigen Bytes über die n-Bits im Command Specifier korrekt angegeben werden. Wird ein UNSIGNED16 mit vier Bytes beschrieben, lehnt ein normkonformer Server dies ab. Manche Stacks sind hier tolerant und akzeptieren zu lange Zugriffe stillschweigend – ein Gerät, das korrekt abbricht, ist also nicht das schlechtere.

0x06090030, 0x06090031, 0x06090032 – Wert außerhalb des Bereichs

Der Datentyp stimmt, der Wert nicht. Die zulässigen Grenzen stehen in der EDS-Datei in den Einträgen LowLimit und HighLimit. Wenn ein Gerät hier abbricht, obwohl der Wert laut EDS erlaubt sein müsste, ist oft die EDS-Datei veraltet.

0x08000022 – Falscher Gerätezustand

Der Zugriff wäre grundsätzlich zulässig, ist aber im aktuellen Zustand gesperrt. Typische Situationen:

• Konfigurationsparameter, die sich nur im Zustand Pre-Operational ändern lassen.
• Antriebe nach CiA 402, bei denen bestimmte Parameter im Zustand Operation Enabled gesperrt sind.
• Ein laufender Speicher- oder Update-Vorgang blockiert weitere Zugriffe.

Der Unterschied zu 0x08000021 (lokale Steuerung) ist subtil: Dort verhindert eine lokale Bedienung – etwa ein Handterminal oder ein Wahlschalter am Gerät – den Zugriff über den Bus.

0x08000020 – Applikation lehnt die Daten ab

Der generische Rückfall, wenn ein Applikations-Callback im Gerät den Wert zurückweist, ohne einen spezifischeren Grund zu liefern. Ein häufiges Beispiel: das Schreiben auf 0x1010 (Store Parameters) ohne die vorgeschriebene Signatur. Erwartet wird die ASCII-Folge „save“ als UNSIGNED32, also 0x65766173; analog verlangt 0x1011 (Restore) den Wert „load“, also 0x64616F6C. Jeder andere Wert führt zum Abbruch.

0x05030000 – Toggle-Bit nicht gewechselt

Nur bei segmentierten Transfers relevant. Jedes Segment muss das Toggle-Bit alternierend setzen. Der Fehler deutet auf doppelt empfangene Telegramme, eine Retransmission auf CAN-Ebene oder eine fehlerhafte Client-Implementierung hin – bei kommerziellen Stacks wie von emotas auf beiden Seiten praktisch nie zu sehen.

Das richtige Werkzeug spart das Nachschlagen

Niemand sollte Abort Codes aus einer Tabelle heraussuchen müssen – und aus einem rohen CAN-Trace die Bytes 80 17 10 00 02 00 01 06 von Hand zurückzuübersetzen, ist reine Zeitverschwendung. Ein Tool mit CANopen-Interpretation nimmt einem beides ab: Es erkennt das Abort-Telegramm, dreht die Byte-Reihenfolge um, löst Index und Subindex gegen die EDS-Datei auf und zeigt den Abort Code im Klartext an.

Zwei Werkzeuge von emotas decken die typischen Anwendungsfälle ab:

• emotas CANinterpreter mit dem PlugIn CANopen Interpretation – der Weg der Wahl, wenn man beobachten will, was ein fremder CANopen-Manager oder ein Host-Controller auf dem Bus tatsächlich tut. Statt der Datenbytes zeigt das Tool den CANopen-Dienst an, also beispielsweise den lesenden SDO-Zugriff auf das Heartbeat-Producer-Objekt 0x1017 – und im Fehlerfall eben den aufgelösten Abort Code. Filtern lässt sich sowohl nach Knotennummer als auch nach CANopen-Dienst, was in Netzen mit hoher Buslast den Unterschied macht. Zusammen mit der Aufzeichnungs- und Replay-Funktion ist das die richtige Wahl für sporadische Fehler, die sich nicht auf Kommando reproduzieren lassen.
• emotas CANopen DeviceExplorer – der Weg der Wahl, wenn man den Zugriff selbst auslöst. Der Objektbrowser liest die EDS-Datei ein und stellt jedes Objekt mit Datentyp, Zugriffsrechten und Wertegrenzen dar. Damit sieht man in vielen Fällen schon vor dem Zugriff, warum er scheitern wird – etwa weil ein Objekt ro ist oder der gewünschte Subindex gar nicht existiert. Schlägt ein SDO doch fehl, wird der Abort Code direkt im Klartext gemeldet. Die integrierte CANopen-Interpretation ist bereits im Basic-Paket enthalten, sodass man Objektzugriff und Trace-Sicht im selben Werkzeug hat.

Für wiederkehrende Prüfungen lohnt sich das Scripting-PlugIn in der Full Version des CDE : Ein Skript, das eine Liste von Objekten durchschreibt und die zurückgemeldeten Abort Codes protokolliert, findet Inkonsistenzen zwischen EDS und Firmware in Sekunden statt in Stunden.

Vorgehen bei der Fehlersuche

Eine pragmatische Reihenfolge, die die meisten Fälle in wenigen Minuten klärt:

1. Trace mitschneiden und interpretieren lassen. Erst wenn Anfrage, Antwort und Abort im Klartext vorliegen, weiß man, ob das Gerät überhaupt geantwortet hat und mit welchem Code. Ohne diesen Schritt rät man.
2. NMT-Zustand prüfen. Manche Timeouts erledigen sich durch ein Enter Pre-Operational.
3. EDS gegen Gerät gegenprüfen. Objekt tatsächlich vorhanden, Zugriffsrechte, Datentyp, Wertegrenzen – im Objektbrowser eine Sache von Sekunden.
4. Zugriff isoliert wiederholen. Ein einzelner SDO-Zugriff aus dem Tool heraus, ohne parallel laufenden CANopen-Manager, trennt echte Objektfehler von zustandsabhängigen Sperren.
5. Beim Hersteller nachfragen – aber mit dem konkreten Abort Code, Index und Subindex. Das verkürzt jede Supportanfrage erheblich.

Für Gerätehersteller

Der Abort Code ist Teil der Bedienoberfläche des Geräts. Wer pauschal 0x08000000 (allgemeiner Fehler) zurückgibt, zwingt jeden Integrator zum Raten und erzeugt Supportaufwand. Drei Empfehlungen:

• Den spezifischsten passenden Code verwenden, insbesondere die Wertebereichsfehler 0x06090030 bis 0x06090032 statt eines generischen 0x08000020.
• Zustandsabhängige Sperren konsequent mit 0x08000022 melden und in der Gerätedokumentation angeben, in welchem Zustand welche Objekte beschreibbar sind.
• Die vom Gerät verwendeten Abort Codes dokumentieren – genauso wie die Emergency-Fehlercodes.