CL3-E CANopen/USB/Modbus RTU Online-Handbuch

CANopen Dienste

Der CANopen-Stack bietet die in der nachfolgenden Tabelle abgedruckten Dienste (auch Services genannt) an, genauere Beschreibungen sind in den jeweiligen Kapiteln hinterlegt.


Default CAN-ID	Service	Beschreibung in
`000`_h	Network Management (NMT)	Abschnitt Network Management (NMT)
`080`_h	Synchronizing Object	Abschnitt Synchronisations-Objekt (SYNC)
`080`_h+Node-ID	Emergency	Abschnitt Emergency Object (EMCY)
`180`_h+Node-ID	TX Process Data Objects (PDO)	Abschnitt Process Data Object (PDO)
`200`_h+Node-ID	RX Process Data Objects (PDO)
`280`_h+Node-ID	TX Process Data Objects (PDO)
`300`_h+Node-ID	RX Process Data Objects (PDO)
`380`_h+Node-ID	TX Process Data Objects (PDO)
`400`_h+Node-ID	RX Process Data Objects (PDO)
`480`_h+Node-ID	TX Process Data Objects (PDO)
`500`_h+Node-ID	RX Process Data Objects (PDO)
`580`_h+Node-ID	TX Service Data Objects (SDO)	Abschnitt Service Data Object (SDO)
`600`_h+Node-ID	RX Service Data Objects (SDO)	Abschnitt Service Data Object (SDO)
`700`_h+Node-ID	BOOT-UP Protocol	Abschnitt Boot-Up Protocol
`700`_h+Node-ID	Nodeguarding und Heartbeat	Abschnitt Heartbeat und Nodeguarding

Network Management (NMT)

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-Befehl "Reset Communication" oder "Reset Node". Der Zustand "Pre-Operational" wird nach der Initialisierung automatisch angesteuert.

In der nachfolgenden Tabelle finden Sie eine Übersicht, welche die Aktivität der Services in den entsprechenden Zuständen darstellt. Zu beachten ist, dass der Zustand Stopped die Kommunikation gänzlich einstellt und nur noch die Steuerung der NMT-Zustandsmaschine zulässt.


Service	Initializing	Pre-Operational	Operational	Stopped
PDO			aktiv
SDO		aktiv	aktiv
SYNC		aktiv	aktiv
EMCY		aktiv	aktiv
BOOT-UP	aktiv
NMT		aktiv	aktiv	aktiv

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

Das <CMD> entspricht dabei einem der folgenden Bytes (siehe auch Legende in der Abbildung des NMT-Zustandsdiagramms):


`<CMD>`	Bedeutung
`01`_h	Schalte in den Zustand "Operational"
`02`_h	Schalte in den Zustand "Stop"
`80`_h	Schalte in den Zustand "Pre-Operational"
`81`_h	Reset Node
`82`_h	Reset Communication

Der Wert für <Node-ID> kann die 00_h sein, dann gilt der NMT-Befehl für alle Geräte am CAN-Bus (Broadcast). Wird eine Zahl ungleich Null verwendet, wird nur das Gerät mit der entsprechenden Node-ID adressiert.

Der Befehl "Reset Node" startet die Steuerung komplett neu, der Befehl "Reset Communication" setzt nur die Einstellungen von CANopen zurück und startet die Kommunikation neu.

Beispiel: Sollen alle Geräte am CAN-Bus in den Betriebszustand "Stop" gebracht werden, kann ein Broadcast mit dem Befehl "Schalte in den Zustand Stop" verwendet werden. Die NMT-Nachricht baut sich wie folgt auf:

000 | 02 00

Soll nur das Gerät mit der Node-ID 42 vollständig neu gestartet werden, ist folgende CAN-Nachricht zu verschicken:

000 | 81 2A

Synchronisations-Objekt (SYNC)

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 Kapitel 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. Die "synchronous window length" kann im Objekt 1007_h:00_h in Millisekunden eingestellt werden.

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

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.
Anschließend werden von allen Slaves am Bus die TX-PDOs verschickt.
Danach werden vom CANopen-Master die PDOs versendet. Nachdem die Zeit des "synchronous window length" abgelaufen ist, sind keine PDOs mehr zulässig.
Spätestens wenn das "synchronous window" wieder geschlossen ist, können SDO-Nachrichten ausgetauscht werden.

Emergency Object (EMCY)

Eine Nachricht des Types "Emergency" wird immer dann gesendet, wenn ein Fehler in der Steuerung auftritt, welcher nicht durch ein 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:

Dabei werden insgesamt drei Fehlercodes übertragen, der "Emergency Error Code" (<EMCY Error Code>), der Inhalt des Objektes "Error Register" (1001_h, <E-REG>) und ein herstellerspezifscher Code (Manufacturer Specific Error)

Fehlerbehandlung

Ein Modul zur Fehlerbehandlung verarbeitet alle intern auftretenden Fehler. Jeder Fehler ist in eine Fehlerklasse eingeteilt.

Jeder auftretende Fehler wird folgendermaßen behandelt:

Das zum Fehler gehörige Bit im Objekt "Error Register" (1001_h) wird gesetzt.
Anschließend werden drei Informationen zusammen in das Objekt "Pre-defned Error Field" (1003_h:01) geschrieben:
1. Der Emergency Error Code
2. Das Error Register
3. Der herstellerspezifsche Fehlercode
Steht kein weiterer Fehler mehr an, wird folgende Nachricht verschickt:
80 + Node-ID | 00 00 00 00 00 00 00 00

Service Data Object (SDO)

Ein "Service Data Object" lässt einen lesenden oder schreibenden Zugriff auf das Objektverzeichnis zu.

Im Nachfolgenden wird der Besitzer des Objektverzeichnisses "Server" genannt, der CAN-Knoten - welcher die Daten anfordert oder schreiben will - "Client". Mit einem "Upload" wird das Lesen eines Wertes eines Objektes aus dem Objektverzeichnisses bezeichnet, ein "Download" ist entsprechend das Schreiben eines Wertes in das Objektverzeichnis. Zudem werden folgende Kürzel in den Diagrammen benutzt:

<IDX>: Index des zu lesenden oder schreibenden Objektes im Objektverzeichnis; das LSB des Indexes steht dabei im Byte 1. Beispiel: das Statusword der Steuerung hat den Index 6041_h, Byte 1 wird dann mit 41_h und Byte 2 mit 60_h beschrieben. Die SDO-Antwort enthält bei Expedited Transfer den gleichen Index, wie den der Anforderung.
<SUBIDX>: Subindex des Objektes im Objektverzeichnis von 00_h bis FF_h. Die Antwort der SDO-Nachricht der Steuerung enthält bei Expedited Transfer ebenfalls den Subindex der Anforderung.

Da CAN-Nachrichten des Types SDO sehr viele Meta-Daten beinhalten, sollte mit SDO-Nachricht nur die Konfiguration der Steuerung vorgenommen werden. Sollte es notwendig sein, im laufenden Betrieb Daten zyklisch auszutauschen, ist es sinnvoller, auf CANopen-Nachricht des Types PDO zurück zu greifen (siehe Unterabschnitt Process Data Object).

Die SDO-Transfers unterteilen sich in drei Sorten des Zugriffs:

"expedited transfer" für die Übertragung von einem Objekt mit bis zu vier Bytes.
"normal transfer" für die Übertragung von beliebig vielen Bytes, wobei jede CAN-Nachricht einzeln bestätigt wird.
"block transfer" ebenfalls für beliebig viele Bytes, dabei wird jeweils ein Block an CAN-Tickets auf einmal bestätigt.

Eine SDO-Nachricht wird an die CAN-ID 600_h + Node-ID verschickt, die Antwort kommt mit der CAN-ID 580_h + Node-ID.

Expedited Transfer

Mit dieser Methode lassen sich Werte in Objekte des Types (UN)SIGNED8, INTEGER16 oder INTEGER32 in 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:00_h (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

Dabei entspricht

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 00_h
Byte 5 bis 8 (E8_h 03_h 00_h 00_h): Wert des Objektes: 000003E8_h

Im Erfolgsfall antwortet die Steuerung mit dieser Nachricht:

583 | 60 7A 60 00 00 00 00 00

SDO-Upload

Eine CAN-Nachricht zum Lesen eines Objektes aus dem Objektverzeichnis hat den nachfolgenden Aufbau:

Der Server antwortet dabei mit einer der nachfolgenden Nachrichten.

Die Länge der Daten ist im <CMD> der Antwort verschlüsselt:

1 Byte Datenlänge: 4F_h
2 Byte Datenlänge: 4B_h
3 Byte Datenlänge: 47_h
4 Byte Datenlänge: 43_h

Das LSB der Daten steht dabei wieder im Byte 4.

Im Fehlerfall ist der Grund des Fehlers in den Daten mit angegeben (siehe Liste der SDO- Fehlermeldungen in SDO-Fehlermeldungen).

Beispiel: Um das Objekt "Statusword" (6041_h:00) aus dem Objektverzeichnis zu lesen, reicht es aus, folgende Nachricht zu senden (immer 8 Bytes):

603 | 40 41 60 00 00 00 00 00

Die Steuerung antwortet im Regelfall mit folgender Nachricht:

583 | 4B 41 60 00 40 02 00 00

Dabei entspricht

Byte 1 (4B_h): SDO expedited upload, 2 Bytes Daten (UNSIGNED16)
Byte 2 und 3 (41_h 60_h): Index des Objektes ist 6041_h
Byte 4 (00_h): Subindex des Objektes ist 00_h
Byte 5 bis 6 (40_h 02_h ): Wert des Objektes: 0240_h
Byte 7 bis 8 (00_h 2_h _h _h): leer. Eine SDO-Nachricht besteht immer aus 8 Bytes.

Normal Transfer

Die CANopen-Übertragung "expedited" ist auf maximal vier Byte beschränkt, um diese Schranke zu überschreiten, muss der sogenannte "normal transfer" unterstützt werden. Bei dieser Übertragungsart wird der Inhalt mehrerer Nachrichten inhaltlich zusammengefasst, ein solcher Block an Nachrichten wird im Folgenden als "Transfer" bezeichnet. Jede Nachricht innerhalb eines Transfers wird dabei einzeln bestätigt.

Das ist zum Zeitpunkt der Erstellung des Dokumentes nur für Objekte des Types "String" notwendig. Da ein String die Zugriffsbeschränkung "read only" hat, ist ein SDO-Download nicht nötig, in diesem Dokument wird daher nur auf den SDO-Upload eingegangen.

Fehlende Unterstützung des "normal transfer" eines Masters

Sollte die Steuerung von einem Master bedient werden, welcher keinen "normal transfer" unterstützt, kann der Zugriff auf Objekte mit dem Datentyp String auch anders gelöst werden: Jeder String kann mit einem SDO-Upload auf den Subindex 1 und den folgenden Subindizes zeichenweise ausgelesen werden.

Beispiel: Das Objekt 6505_h (http drive catalogue address) soll ausgelesen werden. Unterstützt der Master "normal transfer", reicht es aus, den Upload des Objektes über den Subindex 00 zu beginnen, die Steuerung stellt automatisch auf "normal transfer" um. Sollte der Master nur "expedited transfer" unterstützen, kann über die Objekte 6505_h:01, 6505_h:02, 6505_h:03 usw. der String Zeichen für Zeichen ausgelesen werden.

SDO-Upload

In nachfolgender Abbildung ist die Vorgehensweise eines "SDO Uploads" dargestellt (Client lässt sich den Inhalt eines Objektes schicken). Die Übertragung zerfällt in zwei Phasen: Einer Initialisierungs- und einer Übertragungsphase.

Der Upload beginnt, in dem der Client - wie bei einem "expedited transfer" auch - einen "Init SDO Update" an den Server schickt (siehe nachfolgende Abbildung).

Die Antwort für einen "normal transfer" enthält die Menge der zu empfangenen Bytes nicht im <CMD> codiert, sondern im Datenbereich eingetragen wie es in der nachfolgenden Abbildung im Bereich <DATA LENGTH> zu sehen ist.

Damit gilt die Initialisierung als abgeschlossen, im Anschluss erfolgt nur noch der Upload der Daten. Ein Datenpaket wird mit folgenden SDO-Request angefordert:

Das Byte 0 mit dem Kommando <CMD> setzt sich folgendermaßen zusammen:

Das Bit mit der Bezeichnung t alterniert mit jeder Anforderung ("toggle bit"). Es beginnt mit jedem Transfer bei 0, auch wenn der vorherige Transfer abgebrochen wurde.

Die Steuerung antwortet auf die obige Nachricht mit den Daten, wobei die Nachricht folgendermaßen aufgebaut ist:

Das Byte 0 mit <CMD> setzt sich folgendermaßen zusammen:

Die Bits haben dabei folgende Bedeutung:

t (toggle bit): Das Bit alterniert mit jeder Nachrichtensequenz, es ändert sich nicht innerhalb einer Sequenz zwischen "Request" und "Response".
n (number of bytes): Diese drei Bits geben an, wie viele Bytes keine Daten enthalten. Beispiel: sind Bit 2 und 1 auf 0, Bit 3 auf 1 dann sind 011_b = 03_d Bytes nicht gültig. Im Umkehrschluss bedeutet das, dass Byte 1 bis Byte 4 Zulässige Werte enthalten und Byte 5 bis Byte 7 nicht beachtet werden sollen.
c (more segments): Wenn keine weiteren SDO-Segmente mehr verschickt werden und es sich dann hierbei um das letzte Segment handelt, wird das Bit auf 1 gesetzt.

Beispiel: In diesem Beispiel soll das Objekt "Manufacturer Software Version" (100A_h) ausgelesen werden. Die Node-ID des Knotens ist in diesem Beispiel die 3.

Die dazugehörige SDO-Nachrichten-Sequenz wird in nachfolgender Tabelle aufgelistet. Der auszulesende String variiert von Steuerung zu Steuerung.


COB-ID	Daten	Beschreibung
603_h	40 0A 10 00 00 00 00 00	Init Upload; Index: 100A_h; Subindex: 00
583_h	41 0A 10 00 11 00 00 00	Init Upload; Size: indicated; transfer type: normal; Num of bytes: 17; Index: 100A_h; Subindex: 00
603_h	60 0A 10 00 00 00 00 00	Upload Segment Req.; Toggle bit: not set
583_h	00 46 49 52 2D 76 31 37	Upload Segment Conf.; More segments: yes; num of bytes: 7; Toggle bit: not set
603_h	70 0A 10 00 00 00 00 00	Upload Segment Req.; Toggle bit: set
583_h	10 34 38 2D 42 35 33 38	Upload Segment Conf.; More segments: yes; num of bytes: 7; Toggle bit: set
603_h	60 0A 10 00 00 00 00 00	Upload Segment Req.; Toggle bit: not set
583_h	09 36 36 32 00 00 00 00	Upload Segment Conf.; More segments: no (last segment); num of bytes: 3; Toggle bit: not set

46 49 52 2D 76 31 37 34 38 2D 42 35 33 38 36 36 32

Das entspricht dem String: "FIR-v1748-B538662"

Abbruch der SDO-Übertragung

Sowohl der Server als auch der Client sind jederzeit berechtigt, den derzeitigen Transfer abzubrechen. Dazu muss ein "Abort SDO Transfer" gesendet werden, was nachfolgend abgebildet ist.

Nach dem Empfang der Nachricht gilt die SDO-Übertragung als beendet, der Service ist nicht bestätigt. Eine neue SDO-Übertragung muss anschließend komplett von vorne begonnen werden. Das Übertragen des <ERROR CODE> ist optional, die Steuerung wertet den Code nicht aus.

SDO-Fehlermeldungen

Im Falle eines Fehlers wird im Bereich der Daten eine Fehlernummer mitgesendet, die den Grund des Fehlers angibt.


Error Code	Beschreibung
`05030000`_h	toggle bit not changed: Gültig nur bei "normal transfer" oder "block transfer". Das Bit, welches nach jeder Übertragung zu alternieren hat, hat seinen Zustand nicht geändert.
`05040001`_h	command specifier unknown: Das Byte 0 des Datenblocks enthielt einen nicht zulässigen Befehl.
`06010000`_h	unsupported access: Falls über CAN over EtherCAT (CoE) ein "complete access" angefordert wurde (wird nicht unterstützt.)
`06010002`_h	read only entry: Es wurde versucht, auf ein konstantes oder nur lesbares Objekt zu schreiben.
`06020000`_h	object not existing: Es wurde versucht, auf ein nicht vorhandenes Objekt zu zugreifen (Index fehlerhaft).
`06040041`_h	objekt cannot be pdo mapped: Es wurde versucht, ein Objekt in das PDO zu mappen, für dass das nicht zulässig ist.
`06040042`_h	mapped pdo exceed pdo: Würde das gewünschte Objekt in das PDO-Mapping angehängt werden, würden die 8Byte des PDO-Mappings überschritten.
`06070012`_h	parameter length too long: Es wurde versucht, auf ein Objekt mit zu vielen Daten zu schreiben; zum Beispiel mit `<CMD>`=`23`_h (4 Byte) auf ein Objekt des Types Unsigned8, korrekt wäre das `<CMD>`=`2F`_h.
`06070013`_h	parameter length too short: Es wurde versucht, auf ein Objekt mit zu wenig Daten zu schreiben; zum Beispiel mit `<CMD>`=`2F`_h (1 Byte) auf ein Objekt des Types Unsigned32, korrekt wäre das `<CMD>`=`23`_h.
`06090011`_h	subindex not existing: Es wurde versucht, auf ein ungültiges Subindex eines Objektes zu zugreifen, der Index hingegen würde existieren.
`06090031`_h	value too great: Einige Objekte unterliegen Restriktionen in der Größe des Wertes, in diesem Fall wurde versucht, einen zu hohen Wert in das Objekt zu schreiben. Zum Beispiel darf das Objekt "Pre-defined error field: Number of errors" bei 1003_h:00 nur auf den Wert "0" gesetzt werden, alle anderen Zahlenwerte provozieren diesen Fehler.
`06090032`_h	value too small: Einige Objekte unterliegen Restriktionen in der Größe des Wertes. In diesem Fall wurde versucht, einen zu niedrigen Wert in das Objekt zu schreiben.
`08000000`_h	general error: Allgemeiner Fehler, der in keine andere Kategorie passt.
`08000022`_h	data cannot be read or stored in this state: Die Parameter des PDOs dürfen nur im State Stopped oder "Pre-Operational" verändert werden. Ein Schreibzugriff auf die Objekte 1400_h bis 1407_h, 1600_h bis 1607_h, 1800_h bis 1807_h und 1A00_h bis 1A07_h ist im Zustand "Operational" nicht zulässig.

Process Data Object (PDO)

Eine Nachricht, die nur Prozessdaten enthält, wird als "Process Data Object" (PDO) bezeichnet. Gedacht ist das PDO für Daten, die zyklisch ausgetauscht werden müssen. Die Idee einer PDO-Nachricht ist es, sämtliche Zusatzinformationen (Index, Subindex und Datenlänge) aus einer CAN-Nachricht zu entfernen und die CAN-Nachricht nur noch mit Daten zu füllen. Die Quell- und Zielinformationen zu dem PDO werden separat im sogenannten PDO-Mapping gespeichert.

PDOs lassen sich nur verwenden, wenn sich die NMT-State Maschine im Zustand "Operational" befindet (siehe Abschnitt Network Management (NMT)), die Konfiguration der PDOs muss im NMT-Zustand "Pre-Operational" erfolgen.

Die Steuerung unterstützt insgesamt 8 unabhängige PDO-Mappings, jede zugehörige PDO-Nachricht kann maximal acht Bytes (=64Bit) an Nutzdaten tragen. Damit lassen sich beispielsweise zwei Unsigned32-Werte übertragen oder ein UNSIGNED32 und ein UNSIGNED08, die Nachricht muss dabei nicht alle acht Datenbytes voll ausnutzen. Die PDOs unterscheiden sich noch einmal in der Konfiguration in die Sende- und Empfangs-Konfiguration. Die Empfangs-Konfiguration beschreibt die Verarbeitung für PDO-Nachrichten, die empfangen werden, und die Sende-Konfiguration der zu sendenden PDO-Nachrichten.

RX-Konfiguration

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

Die Objekte, welche die Funktionalität des Mappings beschreiben.
Die Objekte, welche den Inhalt des Mappings beschreiben.
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 am Anfang des Kapitels CANopen Dienste) 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)).


Mapping	COB-ID
1600_h	200_h + Node-ID
1601_h	300_h + Node-ID
1602_h	400_h + Node-ID
1603_h	500_h + Node-ID
1604_h	xxx_h + Node-ID
1605_h	xxx_h + Node-ID
1606_h	xxx_h + Node-ID
1607_h	xxx_h + Node-ID

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.


140N_h:02_h	Bedeutung
00_h-F0_h	Synchronous: Die Daten werden zwischengespeichert und erst mit dem Erhalt der nächsten SYNC-Nachricht gültig und in das Objektverzeichnis übernommen.
F1_h-FD_h	Reserviert
FE_h, FF_h	Asynchronous : Die Daten werden mit dem Erhalt der PDO-Nachricht gültig und in das Objektverzeichnis übernommen.

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 Abbildung: die ersten zwei Bytes der Nachricht sollen in das Objekt 6040_h:00_h geschrieben werden. In 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 RX-PDO zu konfigurieren, müssen drei Objektkategorien im Objektverzeichnis berücksichtigt werden:

Die Objekte, welche die Funktionalität des Mappings beschreiben.
Die Objekte, welche den Inhalt des Mappings beschreiben.
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 am Anfang des Kapitels CANopen Dienste) 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)).


Mapping	COB-ID
1A00_h	180_h + Node-ID
1A01_h	280_h + Node-ID
1A02_h	380_h + Node-ID
1A03_h	480_h + Node-ID
1A04_h	xxx_h + Node-ID
1A05_h	xxx_h + Node-ID
1A06_h	xxx_h + Node-ID
1A07_h	xxx_h + Node-ID

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 derEvent Timerbenutzt, wird dieser unabhängig von den Änderungen behandelt, der Event Timer wird erst nach Ablauf desselben neu gestartet, nicht aufgrund eines anderen Events.


`180N_h:02_h`	Bedeutung
0	Synchronous (acyclic) : Die Daten werden mit dem Eintreffen des SYNC in das TX-PDO kopiert aber erst mit dem Event versendet.
01_h-F0_h	Synchronous (cyclic): Die Daten werden mit dem Eintreffen der n-ten SYNC-Nachricht kopiert und sofort im Anschluss verschickt (n entspricht der Zahl 1 bis 240, der transmission type "1" sendet bei jedem SYNC die neuen Daten).
F1_h-FB_h	Reserviert
FC_h	RTR-Only (synchronous): Die Daten werden mit dem Eintreffen jeder SYNC-Nachricht kopiert aber erst auf Anforderung mittels einer RTR-Nachricht verschickt.
FD_h	RTR-Only (event-driven): Die Daten werden mit dem Erhalt einer RTR-Nachricht in die TX-PDO-Nachricht kopiert und daraufhin sofort versendet.
FE_h, FF_h	Die Daten werden beim Eintreten des Events kopiert und sofort versendet.

Subindex 3 (inhibit time): Dieser Subindex enthält eine Zeitsperre in 100-µs-Schritten (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 (in ms) kann benutzt werden um einen Event auszulösen, welcher für das Kopieren der Daten und Senden des PDOs sorgt.

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 RX-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 RX-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.

Voreinstellung

Voreingestellt ist folgende Konfiguration:

RX-PDO

1. Mapping (CAN-ID: 200_h + Node-ID):

6040_h:00_h (controlword)
6060_h:00_h (mode of operation)
3202_h:02_h (motor drive submode select)

2. Mapping (CAN-ID: 300_h + Node-ID):

607A_h:00_h (target position)
6081_h:00_h (profile velocity)

3. Mapping (CAN-ID: 400_h + Node-ID): Objekt 6042_h:00_h (vl target velocity)

4. Mapping (CAN-ID: 500_h + Node-ID): Objekt 60FE_h:01_h (digital outputs)

TX-PDO

1. Mapping (CAN-ID: 180_h + Node-ID):

6041_h:00_h (statusword)
6061_h:00_h (Position actual value)

2. Mapping (CAN-ID: 280_h + Node-ID): 6064_h:00_h (Position actual value)

3. Mapping (CAN-ID: 380_h + Node-ID): 6044_h:00_h (vl velocity actual value)

4. Mapping (CAN-ID: 480_h + Node-ID): Objekt 60FD_h:00_h (Digital Inputs)

PDO-Mapping ändern

Deaktivieren Sie das PDO, indem Sie das Valid Bit (Bit 31) des Subindex 01h des dazugehörigen Communication Parameter (z.B. 1400_h:01_h) auf "1" setzen.
Deaktivieren Sie das Mapping indem Sie den Subindex 00h des dazugehörigen Mapping Parameter (z.B. 1600_h:00_h) auf "0" setzen.
Ändern Sie das Mapping in den gewünschten Subindizes (z.B. 1600_h:01_h).
Aktivieren Sie das Mapping in dem Sie die Anzahl der zu mappenden Objekte in den Subindex 00h des dazugehörigen Mapping Parameter (z.B. 1600_h:00_h) schreiben.
Aktivieren Sie das PDO indem Sie Bit 31 des Subindex 01h des dazugehörigen Communication Parameter (z.B. 1400_h:01_h) auf "0" setzen.

Boot-Up Protocol

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

Dieser Service ist unbestätigt, es erfolgt keine Antwort.

Anmerkung: Der Bootloader sendet eine eigene Boot-Up-Nachricht. Diese kann unterdrückt werden, siehe Objekt 2007_h:00

Heartbeat und Nodeguarding

Mit den Services "Heartbeat" und "Nodeguarding" (oft auch mit "Liveguarding" bezeichnet) lassen sich abgeschaltete oder abgestürzte Geräte am CAN-Bus detektieren. Dazu fordert der NMT-Master zyklisch eine Nachricht mit dem aktuellen NMT-Zustand des Slaves an (Nodeguarding). Die Alternative ist, dass jeder Slave unaufgefordert und zyklisch eine Nachricht versendet (Heartbeat). Eine Kombination aus Nodeguarding und Heartbeat ist nicht zulässig. Es wird zudem empfohlen, den Heartbeat dem Nodeguarding vorzuziehen, da Nodeguarding eine höhere Auslastung des CAN-Busses verursacht.

Nodeguarding

Dieser Service basiert darauf, dass der NMT-Master eine RTR-Nachricht mit der CAN-ID 700_h + 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):

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

Folgende drei Bedingungen werden beim Nodeguarding geprüft:

Der NMT-Master muss innerhalb der "possible live time" die RTR-Anforderung verschicken.
Der Slave muss innerhalb der "possible live time" die Antwort auf die RTR-Anforderung verschicken.
Der Slave muss mit seinem NMT-Zustand antworten. Zudem muss das "toggle bit" korrekt gesetzt sein.

Heartbeat

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

Der Slave muss innerhalb der heartbeat consumer time die Heartbeat-Nachricht verschicken. Diese Zeit ist nur dem Master bekannt und wird in der Steuerung nicht hinterlegt.

▶ weiter