CANopen

Das Network Management ist CANopen-Geräte orientiert und folgt einer Master-Slave-Struktur. NMT benötigt ein CANopen-Gerät im Netzwerk, welches die Rolle des CANopen-Masters einnimmt. Alle anderen Geräte haben die Rolle des NMT-Slaves. Jeder NMT-Slave kann durch seine individuelle Node-ID im Bereich von [1..127] angesprochen werden. Durch NMT-Services können CANopen-Geräte initialisiert, gestartet, beobachtet, resetet oder gestoppt werden.

Dabei folgt die Steuerung dem Zustandsdiagramm aus der nachfolgenden Abbildung. Der Zustand "Initialization" wird nur nach dem Einschalten erreicht oder durch Senden eines NMT-Befehls "Reset Communication" oder "Reset Node". Der Zustand "Pre-Operational" wird nach der Initialisierung automatisch angesteuert.

Die "Network Management"-Nachricht hat die CAN-ID 0. Eine Nachricht ist immer zwei Bytes lang und hat folgenden Aufbau:

Das Synchronisationsobjekt wird benutzt, um den Zeitpunkt von PDO-Daten für alle Geräte am Bus gleichzeitig gültig werden zu lassen. Die Sync-Nachricht baut sich folgendermaßen auf:

Für den SYNC-Betrieb wird normalerweise für die RX-PDOs der Übertragungsmodus (Transmission Type) 0 verwendet (Daten werden mit dem nächsten SYNC gültig), für die TX-PDOs wird ein Übertragungsmodus zwischen 1-240 gewählt. (Details: siehe Process Data Object (PDO)).

Nach dem Erhalt einer SYNC-Nachricht gib es ein Zeitfenster ("synchronous window"), innerhalb dessen PDO-Nachrichten gesendet und empfangen werden dürfen. Ist die Zeit des Fensters abgelaufen, müssen alle Geräte das Senden von PDOs einstellen.

Ein typischer CAN-SYNC-Betrieb gliedert sich in vier Phasen (siehe auch nachfolgende Abbildung):

1. Die SYNC-Nachricht wird empfangen. Damit werden die vorher empfangenen RX-PDO-Daten in das Objektverzeichnis kopiert (falls vorhanden). Zu dem Zeitpunkt werden auch die Daten gesampelt und in die TX-PDOs kopiert und das Senden dieser Nachrichten veranlasst.
2. Anschließend werden von allen Slaves am Bus die TX-PDOs verschickt.
3. Danach werden vom CANopen-Master die PDOs versendet. Nachdem die Zeit des "synchronous window length" abgelaufen ist, sind keine PDOs mehr zulässig.
4. Spätestens wenn das "synchronous window" wieder geschlossen ist, können SDO-Nachrichtenausgetauscht werden.

Eine Nachricht des Types "Emergency" wird immer dann gesendet, wenn ein Fehler in der Steuerung auftritt, welcher nicht durch einen SDO-Zugriff verursacht wurde. Dieser Service ist unbestätigt und wird mit der CAN-ID 80_h+Node-ID verschickt.

Die Emergency-Nachricht hat den folgenden Aufbau:

Expedited Transfer

Mit dieser Methode lassen sich Werte in Objekte des Types (UN)SIGNED8, INTEGER16 oder INTEGER32in das Objektverzeichnis schreiben (download) oder auslesen (upload). Dieser Service ist bestätigt, d.h. auf jeden Zugriff wird entweder mit Daten, einer Bestätigung oder mit einer Fehlermeldung geantwortet.

SDO Download
Eine Expedited-SDO-Nachricht zum Schreiben der Daten in das Objektverzeichnis des Servers ist wie folgt aufgebaut:

Dabei ist das Byte <CMD> abhängig von der Länge der Daten, welche geschrieben werden sollen. <CMD> kann einer der folgenden Werte sein:

• 1 Byte Datenlänge: 2F_h 
• 2 Byte Datenlänge: 2B_h 
• 3 Byte Datenlänge: 27_h 
• 4 Byte Datenlänge: 23_h

Das Feld <Data> wird mit den zu schreibenden Daten beschrieben, das LSB der Daten wird in Byte 4 eingetragen. 

Die Antwort des Servers ist entweder eine Bestätigung des Schreibvorganges oder eine Fehlermeldung (Aufbau der Nachrichten: siehe nachfolgende Abbildung). Im letzteren Fall wird der Grund des Fehlers in den Daten mitgesendet (siehe Liste der SDO-Fehlermeldungen in Abschnitt SDO-Fehlermeldungen).

Beispiel
Setzen des Objekts 607A_h:00h (Target position, SIGNED32) auf den Wert 3E8_h (=1000_d) einer Steuerung mit der Node-ID 3:

603 | 23 7A 60 00 E8 03 00 00  

• Byte 1 (23_h): SDO expedited download, 4Bytes Daten (SIGNED32)
• Byte 2 und 3 (7A_h 60_h): Index des Objektes ist 607A_h
• Byte 4 (00_h): Subindex des Objektes ist 00h
• Byte 5 bis 8 (E8_h 03_h 00_h 00_h): Wert des Objektes: 000003E8_h

lf successful, the controller responds with this message:

583 | 60 7A 60 00 00 00 00 00

SDO upload 
A CAN message for reading an object from the object dictionary has the following structure:

Der Server antwortet dabei mit einer der nachfolgenden Nachrichten. 

RX-Konfiguration

Um ein RX-PDO zu konfigurieren, müssen drei Objektkategorien im Objektverzeichnis berücksichtigt werden:

1. Die Objekte, welche die Funktionalität des Mappings beschreiben.
2. Die Objekte, welche den Inhalt des Mappings beschreiben.
3. Die Objekte, welche die empfangenen Daten erhalten sollen.

Konfiguration der Funktionalität (Communication Parameter)
Die Konfiguration des ersten Mappings wird in den Subindizes des Objektes 1400_h gespeichert. Das zweite Mapping wird in 1401_h konfiguriert und so weiter. Im Folgenden wird jeweils vom 140N_h gesprochen. Die Konfiguration betrifft dabei die COB-ID der PDO-Nachricht und die Übertragungsart.

Die Objekte 140N_h besitzen nur drei Subindizes:

• Subindex 0 (max. subindex): Anzahl der gesamten Subindizes
• Subindex 1 (COB-ID): Hier wird die COB-ID hinterlegt. Für PDO-Mapping 1-4 (1600_h..1603_h) gilt, dass die CAN-ID abhängig von der Node-ID fix ist und nur das Valid-Bit (Bit 31) in der COB-ID gesetzt werden kann. Von 1604_h...1607_h kann die CAN-ID eigenständig gesetzt werden (mit der Einschränkung, dass diese nicht von anderen Diensten verwendet wird, siehe Tabelle) und auch das Valid-Bit. Die Änderung einer COB-ID wird erst nach dem Neustart der Steuerung oder der Kommunikation aktiv (siehe Network Management (NMT)).

• Subindex 2 (transmission type): In diesem Subindex wird eine Nummer hinterlegt, die den Zeitpunkt definiert, zu dem die empfangenen Daten gültig werden. Die Nummer und die zugehörige Bedeutung können Sie aus der nachfolgenden Tabelle entnehmen.

Inhalt eines Mappings

Die Konfiguration des Inhalts eines Mappings setzt sich wie folgt zusammen (siehe auch nachfolgende Abbildung als Beispiel): 

• Alle Subindizes eines Konfigurationsobjektes gehören zusammen, so beschreibt das 1600_h mit allen Subindizes das erste Mapping, das 1601_h das zweite RX-PDO-Mapping usw.
• Der Subindex 00_h gibt an, wie viele Objekte sich in einem Mapping befinden. Er gibt gleichzeitig an, wie viele der Subindizes gültig sind. Wird das Objekt 1600_h:00_h auf "0" gesetzt, ist das RX-Mapping damit vollständig abgeschaltet. In dem Beispiel aus der nachfolgenden Abbildung werden somit zwei Objekte gemappt, das Objekt 1600_h:03_h und 1600_h:04_h ist damit nicht aktiv (grau dargestellt).
• Jeder Subindex von 1600_h:01_h bis 1600_h:0F_h beschreibt fortlaufend ohne Lücken jeweils ein Ziel des Mappings. Dabei wird der Index, Subindex und die Bitlänge codiert. Beispiel aus nachfolgender hexadezimaler Schreibweise setzt sich der Inhalt des 1600_h:01_h dann aus <Index><Subindex><Bitlänge>
  zusammen, also 60400010. Das zweite Mapping (1600_h:02_h) enthält den Eintrag 607A0020. Es mappt also die folgenden vier Byte (=20_hBit) in das Objekt 607A_h:00_h

TX-Konfiguration

Um ein TX-PDO zu konfigurieren, müssen drei Objektkategorien im Objektverzeichnis berücksichtigt werden:

1. Die Objekte, welche die Funktionalität des Mappings beschreiben.
2. Die Objekte, welche den Inhalt des Mappings beschreiben.
3. Die Objekte, welche die zu sendenden Daten erhalten sollen.

Zudem ist zu beachten, dass der Zeitpunkt - zu dem die Daten in die TX-PDO-Nachricht kopiert werden - und der Zeitpunkt des Versendens nicht der gleiche sein müssen (abhängig vom Modus). 

Konfiguration der Funktionalität (Communication Parameter)

Die Konfiguration der Funktionalität des ersten Mappings wird in den Subindizes des Objektes 1800_h gespeichert. Das zweite Mapping wird in 1801_h konfiguriert und so weiter. Im Folgenden wird jeweils vom 180N_h gesprochen. Die Konfiguration betrifft dabei die COB-ID der PDO-Nachricht und die Übertragungsart.

Die Objekte 180N_h besitzen folgende Subindizes: 

• Subindex 0 (max. subindex): Anzahl der gesamten Subindizes
• Subindex 1 (COB-ID): Hier wird die COB-ID hinterlegt. Für PDO-Mapping 1-4 (1A00_h..1A03_h) gilt, dass die CAN-ID abhängig von der Node-ID fix ist und nur das Valid-Bit (Bit 31) in der COB-ID gesetzt werden kann. Von 1A04_h...1A07_h kann die CAN-ID eigenständig gesetzt werden (mit der Einschränkung dass diese nicht von anderen Diensten verwendet wird, siehe Tabelle) und auch das Valid-Bit. Die Änderung einer COB-ID wird erst nach dem Neustart der Steuerung oder der Kommunikation aktiv (siehe Network Management (NMT)).

• Subindex 2 (transmission type): In diesem Subindex wird eine Nummer hinterlegt, welche den Zeitpunkt definiert, zu dem die Daten in die PDO-Nachricht kopiert und wann dieses gesendet werden soll. Die Nummer und die zugehörige Bedeutung kann aus der nachfolgenden Tabelle entnommen werden. Im Folgenden wird von einem Event gesprochen, der das Kopieren und/oder das Senden der Daten anstoßen kann. Zu diesem Event zählen drei Ereignisse, die unabhängig voneinander betrachtet werden:
  
  - Schalten der NMT-Zustandsmaschine auf "operational".
  - Die gegenwärtigen Daten haben sich gegenüber der letzten PDO-Nachricht geändert.
  - Der Event Timer ist abgelaufen (siehe 180N_h:5).
  
  Wird der Event Timer benutzt, wird dieser unabhängig von den Änderungen behandelt, der Event Timer wird erst nach Ablauf desselben neu gestartet, nicht aufgrund eines anderen Events.

• Subindex 3 (inhibit time): Dieser Subindex enthält eine Zeitsperre (siehe nachfolgende Abbildung). Hier kann eine Zeit eingestellt werden, die nach einem Senden eines PDOs abgelaufen sein muss, damit ein weiteres Mal das PDO verschickt wird. Diese Zeit gilt nur für asynchrone PDOs. Dadurch soll verhindert werden, dass asynchrone PDOs permanent verschickt werden, wenn sich das gemappte Objekt dauernd ändert.
• Subindex 4 (compatibility entry): Dieser Subindex hat keine Funktion und ist nur aus Gründen der Kompatibilität vorhanden.
• Subindex 5 (event timer): Diese Zeit kann benutzt werden um ein Event auszulösen, welcher für das Kopieren der Daten und Senden des PDOs sorgt.
• Subindex 6 (sync start value): hier wird der Startwert des Sync Counter eingetragen, ab welchem der Slave auf den Sync zum ersten Mal reagieren und das PDO senden soll. Wird global erst aktiviert, wenn in 1019_h Synchronous Counter Overflow Value ein Wert größer 1 eingestellt wird.

Inhalt eines Mappings

Die Konfiguration des Inhalts eines Mappings setzt sich wie folgt zusammen (siehe nachfolgende Abbildung als Beispiel):

• Alle Subindizes eines Konfigurationsobjektes gehören zusammen, so beschreibt das 1A00_h mit allen Subindizes das erste Mapping, das 1A01_h das zweite TX-PDO-Mapping usw.
• Der Subindex 00 gibt an, wie viele Objekte sich in einem Mapping befinden. Es gibt gleichzeitig an, wie viele der Subindizes gültig sind. Wird das Objekt 1A00_h:00_h auf "0" gesetzt, ist das TX-Mapping damit vollständig abgeschaltet. Im nachfolgendem Beispiel werden somit zwei Objekte in den Einträgen 1A00_h:01_h - 1A00_h:02_h gemappt. Die Objekte in den Einträgen 1A00_h:03_h - 1A00_h:04_h werden somit nicht gemappt (grau dargestellt).
• Jeder Subindex von 1A00_h:01_h bis 1A00_h:0F_h beschreibt fortlaufend ohne Lücken (für eine Lücke können Dummy-Objekte verwendet werden) jeweils eine Quelle des Mappings. Dabei wird der Index, Subindex und die Bitlänge kodiert. Beispiel aus nachfolgender Abbildung: die ersten zwei Byte der Nachricht sollen aus dem Objekt 6041_h:00_h gelesen werden. In hexadezimaler Schreibweise setzt sich der Inhalt des 1A00_h:01_h dann aus <Index><Subindex><Bitlänge> zusammen, also 60410010. Das zweite Mapping (1A00_h:02_h) enthält den Inhalt 60640020. Es mappt also die folgenden vier Byte (entspricht 32 Bits) aus dem Objekt 6064_h:00_h in die TX-PDO-Nachricht.

Erreicht der CAN-Slave den NMT-Zustand "Pre-Operational" (siehe nachfolgende Abbildung), dann wird die nachfolgende Nachricht verschickt, um die Betriebsbereitschaft zu signalisieren.

Nodeguarding

Dieser Service basiert darauf, dass der NMT-Master eine RTR-Nachricht mit der CAN-ID 700h + Node-ID an den jeweiligen Slave verschickt. Anschließend muss der Slave eine Nachricht als Antwort verschicken, welche nachfolgend abgebildet ist. Das Bit 7 alterniert dabei bei jeder Übertragung, somit kann festgestellt werden, ob eine Nachricht verloren ging. In den Bits 6 bis 0 wird der momentane NMT-Status des Slaves eingetragen.

Es existieren beim Nodeguarding drei Zeitintervalle (siehe auch nachfolgende Abbildung):

1. guard time: Die Zeit, zwischen zwei RTR-Nachrichten. Diese kann für jeden CAN-Knoten unterschiedlich sein und wird im Slave im Objekt 100Ch:00 hinterlegt.
2. live time factor: Ein Multiplikator für die guard time, diese wird im CAN-Slave im Objekt 100Dh:00 hinterlegt und kann für jeden Slave am CAN-Bus unterschiedlich sein.
3. possible live time: Die Zeitdauer, welche sich aus der Multiplikation aus guard time und live time factor ergibt.

Heartbeat

Ist der Heartbeat aktiviert, sendet der Slave ohne weitere Aufforderung zyklisch seinen NMT-Zustand auf dem CAN-Bus. Aktiviert wird dieser Service, indem die Zeit Producer Heartbeat Time im Objekt 1017_h:00_h auf einen anderen Wert als Null gesetzt wird. Die vom Slave verschickte Nachricht hat die nachfolgend abgebildete Form: