CANopen Diagnose
Dieses Kapitel beschreibt die Diagnosemöglichkeiten, die das CANopen-Protokoll bietet.
CANopen-Zustand
Ein CANopen-Netzwerk besteht aus einem NMT-Master (Network Management) und NMT-Slaves. Der NMT-Master kontrolliert dabei alle Geräte und kann deren Kommunikationszustände ändern. Dabei befindet sich ein CANopen-Gerät in einem von 4 möglichen Zuständen:
Inizialization: Nach dem Einschalten durchläuft der Knoten diesen Zustand. Dabei erfolgt die Initialisierung der Geräteapplikation und der Gerätekommunikation (Bitrate und Knotenadresse). Danach geht der Knoten selbstständig in den Zustand „Pre-Operational“.
Pre-Operational: Eine Kommunikation mit dem Knoten über SDOs ist möglich. Der Knoten ist jedoch nicht in der Lage, eine PDO-Kommunikation durchzuführen.
Operational: Der CANopen-Knoten hat die volle Betriebsbereitschaft. Er kann selbständig Prozessdaten senden und empfangen.
Stopped: Der Knoten wird vollständig vom Netz getrennt. Es ist keine SDO- oder PDO-Kommunikation möglich. Der Knoten kann nur durch ein entsprechendes Netzwerkkommando (beispielsweise Start-Node) in einen anderen Netzwerkzustand gebracht werden.
Error-Register
Gemäß CiA 301 hat jedes CANopen-Gerät ein Error-Register (Objekt 16#1001). Dieses Register kann per SDO ausgelesen werden und liefert im Fehlerfall weitergehende Information zum Fehler.
In dem Fehlerregister ist nur Bit 0 (Generischer Fehler) verpflichtend. Die anderen Bits sind optional und werden nicht von jedem Slave gesetzt. Sobald ein Gerät irgendeinen Fehler erkennt, ist zumindest Bit 0 dieses Objekts gesetzt.
Bit | Beschreibung |
|---|---|
0 | Generischer Fehler |
1 | Strom |
2 | Spannung |
3 | Temperatur |
4 | Kommunikationsfehler (overrun error state) |
5 | Geräteprofil-spezifisch |
6 | reserviert (immer 0) |
7 | Hersteller-spezifisch |
Emergency und Predefined Error Field (EMCY)
Zur Signalisierung von Fehlern definiert CANopen das optionale Emergency (EMCY) Protokoll. Eine Emergency ist eine CAN-Botschaft, die gemäß dem Pre-defined Connection Set mit CAN-ID 16#80 + NODE-ID übertragen wird.
Das Telegramm hat folgenden Aufbau:
Die Länge einer Emergency-Nachricht ist immer 8 Byte. In den ersten beiden Byte wird der jeweilige Emergency-Fehlercode (EEC: Emergency Error Code) übertragen. Danach folgt der aktuelle Wert des Error-Registers 0x1011 (ER: Error Register) und 5 herstellerspezifische Byte (MEF: Manufacturer-specific Error Field).
Die jeweilige Interpretation der Fehlercodes muss dem Handbuch des Herstellers entnommen werden. Das Emergency-Protokoll wird nicht von allen Slaves unterstützt und muss auch entsprechend vom CANopen Manager konfiguriert werden.
Der Verlauf der aufgetretenen Emergencies (Error History) kann per SDO aus dem Objekt 16#1003 ausgelesen werden. Dabei beinhaltet Subindex 0 die Anzahl der gespeicherten Fehler und die nachfolgenden Subobjekte jeweils den Dateninhalt des gesendeten Emergencys.
Überwachungsmechanismen: Heartbeat und Nodeguarding
Eine Überwachung eines CAN-Knotens ist dann erforderlich, wenn dieser nicht ständig Botschaften sendet (zyklische PDOs). Dazu sind die Mechanismen ‚Heartbeat‘ und ‚Nodeguarding‘ vorhanden, die alternativ genutzt werden können.
Node-Guarding: Bei diesem Protokoll werden durch den NMT-Master Botschaften (CAN-Remote-Frames) an die vorhandenen CANopen-Slaves gesendet. Die Slaves müssen innerhalb einer bestimmten Zeit auf diese Botschaften antworten. Wenn keine Antwort erfolgt, wird dies durch den NMT-Master registriert. Da CAN-Remote Frames generell vermieden werden sollten, ist die Überwachung mittels Heartbeat zu bevorzugen.
Heartbeat: Das Heartbeat-Protokoll wurde mit CANopen Version 4.0 veröffentlicht und ist die bevorzugte Überwachungsmethode. Hierbei sendet jeder Knoten autark eine Botschaft in zyklischen Abstand. Diese Nachricht kann von jedem anderen Teilnehmer im Netzwerk überwacht werden.