N5 CANopen Technisches-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
000h Network Management (NMT) Abschnitt Network Management (NMT)
080h Synchronizing Object Abschnitt Synchronisations-Objekt (SYNC)
080h+Node-ID Emergency Abschnitt Emergency Object (EMCY)
180h+Node-ID TX Process Data Objects (PDO) Abschnitt Process Data Object (PDO)
200h+Node-ID RX Process Data Objects (PDO)
280h+Node-ID TX Process Data Objects (PDO)
300h+Node-ID RX Process Data Objects (PDO)
380h+Node-ID TX Process Data Objects (PDO)
400h+Node-ID RX Process Data Objects (PDO)
480h+Node-ID TX Process Data Objects (PDO)
500h+Node-ID RX Process Data Objects (PDO)
580h+Node-ID TX Service Data Objects (SDO) Abschnitt Service Data Object (SDO)
600h+Node-ID RX Service Data Objects (SDO)
700h+Node-ID BOOT-UP Protocol Abschnitt Boot-Up Protocol
700h+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
01h Schalte in den Zustand "Operational"
02h Schalte in den Zustand "Stop"
80h Schalte in den Zustand "Pre-Operational"
81h Reset Node
82h Reset Communication

Der Wert für <Node-ID> kann die 00h 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 1007h:00h in Millisekunden eingestellt werden.

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-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 80h+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" (1001h, <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" (1001h) wird gesetzt.
  • Anschließend werden drei Informationen zusammen in das Objekt "Pre-defned Error Field" (1003h: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 6041h, Byte 1 wird dann mit 41h und Byte 2 mit 60h beschrieben. Die SDO-Antwort enthält bei Expedited Transfer den gleichen Index, wie den der Anforderung.
  • <SUBIDX>: Subindex des Objektes im Objektverzeichnis von 00h bis FFh. 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 600h + Node-ID verschickt, die Antwort kommt mit der CAN-ID 580h + 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: 2Fh
  • 2 Byte Datenlänge: 2Bh
  • 3 Byte Datenlänge: 27h
  • 4 Byte Datenlänge: 23h

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 607Ah:00h (Target position, SIGNED32) auf den Wert 3E8h (=1000d) einer Steuerung mit der Node-ID 3:

603 | 23 7A 60 00 E8 03 00 00

Dabei entspricht

  • Byte 1 (23h): SDO expedited download, 4Bytes Daten (SIGNED32)
  • Byte 2 und 3 (7Ah 60h): Index des Objektes ist 607Ah
  • Byte 4 (00h): Subindex des Objektes ist 00h
  • Byte 5 bis 8 (E8h 03h 00h 00h): Wert des Objektes: 000003E8h
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: 4Fh
  • 2 Byte Datenlänge: 4Bh
  • 3 Byte Datenlänge: 47h
  • 4 Byte Datenlänge: 43h

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" (6041h: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 (4Bh): SDO expedited upload, 2 Bytes Daten (UNSIGNED16)
  • Byte 2 und 3 (41h 60h): Index des Objektes ist 6041h
  • Byte 4 (00h): Subindex des Objektes ist 00h
  • Byte 5 bis 6 (40h 02h ): Wert des Objektes: 0240h
  • Byte 7 bis 8 (00h 2h 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 6505h (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 6505h:01, 6505h:02, 6505h: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 011b = 03d 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" (100Ah) 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
603h 40 0A 10 00 00 00 00 00 Init Upload; Index: 100Ah; Subindex: 00
583h 41 0A 10 00 11 00 00 00 Init Upload; Size: indicated; transfer type: normal; Num of bytes: 17; Index: 100Ah; Subindex: 00
603h 60 0A 10 00 00 00 00 00 Upload Segment Req.; Toggle bit: not set
583h 00 46 49 52 2D 76 31 37 Upload Segment Conf.; More segments: yes; num of bytes: 7; Toggle bit: not set
603h 70 0A 10 00 00 00 00 00 Upload Segment Req.; Toggle bit: set
583h 10 34 38 2D 42 35 33 38 Upload Segment Conf.; More segments: yes; num of bytes: 7; Toggle bit: set
603h 60 0A 10 00 00 00 00 00 Upload Segment Req.; Toggle bit: not set
583h 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
05030000h 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.
05040001h command specifier unknown: Das Byte 0 des Datenblocks enthielt einen nicht zulässigen Befehl.
06010000h unsupported access: Falls über CAN over EtherCAT (CoE) ein "complete access" angefordert wurde (wird nicht unterstützt.)
06010002h read only entry: Es wurde versucht, auf ein konstantes oder nur lesbares Objekt zu schreiben.
06020000h object not existing: Es wurde versucht, auf ein nicht vorhandenes Objekt zu zugreifen (Index fehlerhaft).
06040041h objekt cannot be pdo mapped: Es wurde versucht, ein Objekt in das PDO zu mappen, für dass das nicht zulässig ist.
06040042h 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.
06070012h parameter length too long: Es wurde versucht, auf ein Objekt mit zu vielen Daten zu schreiben; zum Beispiel mit <CMD>=23h (4 Byte) auf ein Objekt des Types Unsigned8, korrekt wäre das <CMD>=2Fh.
06070013h parameter length too short: Es wurde versucht, auf ein Objekt mit zu wenig Daten zu schreiben; zum Beispiel mit <CMD>=2Fh (1 Byte) auf ein Objekt des Types Unsigned32, korrekt wäre das <CMD>=23h.
06090011h subindex not existing: Es wurde versucht, auf ein ungültiges Subindex eines Objektes zu zugreifen, der Index hingegen würde existieren.
06090031h 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 1003h:00 nur auf den Wert "0" gesetzt werden, alle anderen Zahlenwerte provozieren diesen Fehler.
06090032h 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.
08000000h general error: Allgemeiner Fehler, der in keine andere Kategorie passt.
08000022h 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 1400h bis 1407h, 1600h bis 1607h, 1800h bis 1807h und 1A00h bis 1A07h 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:

  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 1400h gespeichert. Das zweite Mapping wird in 1401h konfiguriert und so weiter. Im Folgenden wird jeweils vom 140Nh gesprochen. Die Konfiguration betrifft dabei die COB-ID der PDO-Nachricht und die Übertragungsart.

Die Objekte 140Nh 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 (1600h..1603h) 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 1604h...1607h 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
    1600h 200h + Node-ID
    1601h 300h + Node-ID
    1602h 400h + Node-ID
    1603h 500h + Node-ID
    1604h xxxh + Node-ID
    1605h xxxh + Node-ID
    1606h xxxh + Node-ID
    1607h xxxh + 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.
    140Nh:02h Bedeutung
    00h-F0h Synchronous: Die Daten werden zwischengespeichert und erst mit dem Erhalt der nächsten SYNC-Nachricht gültig und in das Objektverzeichnis übernommen.
    F1h-FDh Reserviert
    FEh, FFh 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 1600h mit allen Subindizes das erste Mapping, das 1601h das zweite RX-PDO-Mapping usw.
  • Der Subindex 00h gibt an, wie viele Objekte sich in einem Mapping befinden. Er gibt gleichzeitig an, wie viele der Subindizes gültig sind. Wird das Objekt 1600h:00h 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 1600h:03h und 1600h:04h ist damit nicht aktiv (grau dargestellt).
  • Jeder Subindex von 1600h:01h bis 1600h:0Fh 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 6040h:00h geschrieben werden. In hexadezimaler Schreibweise setzt sich der Inhalt des 1600h:01h dann aus

    <Index><Subindex><Bitlänge>

    zusammen, also 60400010. Das zweite Mapping (1600h:02h) enthält den Eintrag 607A0020. Es mappt also die folgenden vier Byte (=20hBit) in das Objekt 607Ah:00h

TX-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 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 1800h gespeichert. Das zweite Mapping wird in 1801h konfiguriert und so weiter. Im Folgenden wird jeweils vom 180Nh gesprochen. Die Konfiguration betrifft dabei die COB-ID der PDO-Nachricht und die Übertragungsart.

Die Objekte 180Nh 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 (1A00h..1A03h) 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 1A04h...1A07h 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)).Da diese Daten im Dataflash der Steuerung abgelegt werden, sollte die Einstellung der CobIDs über die Datei "canopen.on" mithilfe von NanoIP oder mittels Plug & Drive Studio vorgenommen werden.
    Mapping COB-ID
    1A00h 180h + Node-ID
    1A01h 280h + Node-ID
    1A02h 380h + Node-ID
    1A03h 480h + Node-ID
    1A04h xxxh + Node-ID
    1A05h xxxh + Node-ID
    1A06h xxxh + Node-ID
    1A07h xxxh + 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 180Nh: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.

    180Nh:02h Bedeutung
    0 Synchronous (acyclic) : Die Daten werden mit dem Eintreffen des SYNC in das TX-PDO kopiert aber erst mit dem Event versendet.
    01h-F0h 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).
    F1h-FBh Reserviert
    FCh RTR-Only (synchronous): Die Daten werden mit dem Eintreffen jeder SYNC-Nachricht kopiert aber erst auf Anforderung mittels einer RTR-Nachricht verschickt.
    FDh RTR-Only (event-driven): Die Daten werden mit dem Erhalt einer RTR-Nachricht in die TX-PDO-Nachricht kopiert und daraufhin sofort versendet.
    FEh, FFh 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 1A00h mit allen Subindizes das erste Mapping, das 1A01h 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 1A00h:00h auf "0" gesetzt, ist das RX-Mapping damit vollständig abgeschaltet. Im nachfolgendem Beispiel werden somit zwei Objekte in den Einträgen 1A00h:01h - 1A00h:02h gemappt. Die Objekte in den Einträgen 1A00h:03h - 1A00h:04h werden somit nicht gemappt (grau dargestellt).
  • Jeder Subindex von 1A00h:01h bis 1A00h:0Fh 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 6041h:00h gelesen werden. In hexadezimaler Schreibweise setzt sich der Inhalt des 1A00h:01h dann aus <Index><Subindex><Bitlänge> zusammen, also 60410010. Das zweite Mapping (1A00h:02h) enthält den Inhalt 60640020. Es mappt also die folgenden vier Byte (entspricht 32 Bits) aus dem Objekt 6064h:00h in die TX-PDO-Nachricht.

Voreinstellung

Voreingestellt ist folgende Konfiguration:

RX-PDO

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

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

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

  • 607Ah:00h (target position)
  • 6081h:00h (profile velocity)

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

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

TX-PDO

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

  • 6041h:00h (statusword)
  • 6061h:00h (Position actual value)

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

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

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

PDO-Mapping ändern

  1. Deaktivieren Sie das PDO, indem Sie das Valid Bit (Bit 31) des Subindex 01h des dazugehörigen Communication Parameter (z.B. 1400h:01h) auf "1" setzen.
  2. Deaktivieren Sie das Mapping indem Sie den Subindex 00h des dazugehörigen Mapping Parameter (z.B. 1600h:00h) auf "0" setzen.
  3. Ändern Sie das Mapping in den gewünschten Subindizes (z.B. 1600h:01h).
  4. Aktivieren Sie das Mapping in dem Sie die Anzahl der zu mappenden Objekte in den Subindex 00h des dazugehörigen Mapping Parameter (z.B. 1600h:00h) schreiben.
  5. Aktivieren Sie das PDO indem Sie Bit 31 des Subindex 01h des dazugehörigen Communication Parameter (z.B. 1400h:01h) 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 2007h: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 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 (Einheit: Millisekunden)
  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.

Folgende drei Bedingungen werden beim Nodeguarding geprüft:

  1. Der NMT-Master muss innerhalb der "possible live time" die RTR-Anforderung verschicken.
  2. Der Slave muss innerhalb der "possible live time" die Antwort auf die RTR-Anforderung verschicken.
  3. 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 1017h:00h 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.

▶   next

Contents