In einem CANopen Netzwerk existiert immer ein Teilnehmer, der das Netzwerk-Management übernimmt, der sogenannte NMT Master. Der NMT Master kann den Zustand der anderen Teilnehmer im Netz (diese nennt man NMT Slaves) verändern. Für diesen Zweck wird eine CAN-Nachricht mit der höchst möglichen Priorität verwendet, d.h. der CAN-Identifier hat den Wert “0”.

Die CANopen NMT Slave Geräte können die folgenden Zustände annehmen:

• Initialisierung
• Pre-Operational
• Operational
• Stopped

Nach dem Einschalten oder einem Reset durchläuft jedes Slave Gerät den Zustand Initialisierung und sendet mit Eintreten in den Zustand Pre-Operational die Bootup-Nachricht /1/.

 

 

NMT Zustand überwachen

Der NMT-Zustand von CANopen Geräten kann durch das Heartbeat-Protokoll überwacht werden. Hierzu wird ein Timer in dem Gerät auf dem Index 1017h parametriert, der bei Ablauf die Aussendung der Heartbeat-Nachricht veranlasst. Die Zeit wird in Milli-Sekunden angegeben. Das folgende Beispiel zeigt die Einstellung des Heartbeat-Timers auf den Wert 1000 ms bei einem Gerät mit der Adresse 127 (7Fh).

 

Wo sind meine Prozessdaten?

Um von einem CANopen Gerät Prozessdaten in Form von PDO Nachrichten zu erhalten, muss dieses in den Zustand Operational geschaltet werden. Dies erfolgt typischerweise durch den NMT Master, indem eine Botschaft in der folgenden Form versendet wird:

ID DLC Data
000 2 01 03 ; start node with node-ID 3
000 2 01 00 ; start all remote nodes

Der folgende CAN-Trace zeigt den Start eines Teilnehmers mit der Adresse 3 und das ereignis-gesteuerte Senden einer PDO.

 

Zu schnelle NMT Master

Durch die Aussendung der Bootup-Nachricht wird die Betriebsbereitschaft des CANopen Teilnehmers signalisiert (siehe Bild 1). Eine Kommunikation mit dem Teilnehmer im Zustand Initialisierung ist nicht möglich. Leider ist in letzter Zeit ein Anstieg von Master Implementierungen auf dem Markt zu beobachten, die sich darum wenig kümmern. Das typische Fehlverhalten ist in Bild 4 dargestellt.

Der NMT Master sendet einen NMT Reset Node Kommando, direkt gefolgt von einem SDO Request. Nachdem dieser Request nicht beantwortet wird und die folgende Bootup-Nachricht einfach ignoriert wird, beginnt der Zyklus erneut. Für den Anwender stellt sich das Problem als “der CANopen Teilnehmer funktioniert nicht” dar.

Die NMT Botschaft wird immer von allen CANopen Geräten im Netzwerk ausgewertet, unabhängig von Nachrichteninhalt! Bei einer Bitrate von 1 MBit/s beträgt die Länge der Nachricht ca. 65 Mikrosekunden. Diese Zeit hat das CANopen Gerät zur Verfügung, um die Nachricht auszuwerten, bis die nächste Nachricht diesen Typs einläuft. Dies ist nicht bei allen auf dem Markt verfügbaren CANopen Geräten möglich, zumal wenn die Hardware schon etwas älter ist.

Daher müssen sogenannte NMT Bursts durch den NMT Master auf jeden Fall vermieden werden. Für diesen Zweck wurde das Objekt 102Ah (NMT Inhibit time) in /2/ definiert, um eine Verzögerung zwischen den CANopen NMT Nachrichten zu gewährleisten. Im CANopen Master Stack kann dies zusätzlich durch die Funktion ComNmtSetInhibit() erreicht werden.

Automatisch starten

CANopen Teilnehmer müssen nicht zwingend durch einen NMT Master gestartet werden. Über das optionale Objekt 1F80h (NMT Startup, definiert in /2/) kann ein Teilnehmer autonom in den Zustand Operational wechseln. Eine Anleitung hierzu findet sich hier in der Application Note AN1203.

Referenzen

/1/ CiA 301 V4.2.0 – CANopen application layer and communication profile
/2/ CiA 302 DSP V4.1.0 – CANopen additional application layer functions

21. Oktober 2012, Uwe Koppe

Stichworte: CANopen, Heartbeat, Network Management, NMT

Geschrieben in: CAN, CANopen, Fachbeiträge, Produkte