CANopen Dienste
Der CANopen-Stack bietet die in der nachfolgenden Tabelle angegebenen 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 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.
Sie können im Objekt 1F80h einstellen, ob danach automatisch in den Zustand "Operational" gewechselt werden soll, damit Sie den Versand eines zusätzlichen NMT-Kommandos vermeiden.
In der nachfolgenden Tabelle finden Sie eine Übersicht, welche die Aktivität der Services in den entsprechenden Zuständen darstellt.
Achten Sie darauf, 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:
<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 |
Mit dem Befehl "Reset Node" starten Sie die Steuerung komplett neu. Mit dem Befehl "Reset Communication" setzten Sie die Einstellungen von CANopen zurück und starten die Kommunikation neu.
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.
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 | 01 2A
Synchronisations-Objekt (SYNC)
Das Synchronisations-Objekt 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 in der Regel 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 gibt 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 Mikrosekunden 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.
Falls der Sync Producer einen Sync Counter unterstützt, enthält die Sync-Nachricht einen zusätzlichen 1-Byte-Zählwert. Dieser Zähler erhöht sich um den Wert "1" pro gesendete Sync-Nachricht und wird jedes Mal zurückgesetzt, wenn er den Wert von 1019h Synchronous Counter Overflow Value erreicht.
Für jedes TX-PDO kann dann im Subindex 06h des dazugehörigen Kommunikationsparameters (z.B. in 1800h:06h) ein Startwert des Sync Counter festgelegt werden, ab welchem der Slave auf den Sync zum ersten Mal reagieren und das PDO senden soll. Die Funktion wird erst aktiviert, wenn in 1019h ein Wert größer 1 eingestellt wird.
Emergency Object (EMCY)
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 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 - die "Error Number" (
E-Number)
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:
- Der Emergency Error Code
- Das Error Register
- Der herstellerspezifsche Fehlercode
- Steht kein weiterer Fehler mehr an, wird folgende Nachricht
verschickt:
80 + Node-ID | 00 00 E-REG E-Number 00 00 00 00
Im Objekt 1029h können Sie konfigurieren, ob und wie die Steuerung im Fehlerfall ihren NMT-Zustand ändern soll.
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".
<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 Index6041h, Byte 1 wird dann mit41h und Byte 2 mit60h beschrieben. Die SDO-Antwort enthält bei Expedited Transfer den gleichen Index, wie den der Anforderung.<SUBIDX>: Subindex des Objektes im Objektverzeichnis von00h bisFFh. 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, sollten Sie mit SDO-Nachrichten nur die Konfiguration der Steuerung vornehmen. Sollte es notwendig sein, im laufenden Betrieb Daten zyklisch auszutauschen, greifen Sie auf CANopen-Nachrichten des Types PDO zurück (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 können Sie 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 (
7Ah60h): Index des Objektes ist607Ah - Byte 4 (
00h): Subindex des Objektes ist00h - Byte 5 bis 8 (
E8h03h00h00h): Wert des Objektes:000003E8h
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 (
41h60h): Index des Objektes ist6041h - Byte 4 (
00h): Subindex des Objektes ist00h - Byte 5 bis 6 (
40h02h): Wert des Objektes:0240h - Byte 7 bis 8 (
00h2h h h): leer. Eine SDO-Nachricht besteht immer aus 8 Bytes.
Normal Transfer
Im Gegensatz zur CANopen-Übertragung "expedited", ist der "normal transfer" nicht auf maximal vier Byte beschränkt. 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.
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, indem der Client - wie bei einem "expedited transfer" auch - ein "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 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 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 zuzugreifen (Index fehlerhaft). |
06040041h |
objekt cannot be pdo mapped: Es wurde versucht, ein Objekt in das PDO zu mappen, für welches 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 einen ungültigen Subindex eines Objektes zuzugreifen, 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 (=64 Bit) 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 Sende- und Empfangs-Konfiguration. Die Empfangs-Konfiguration beschreibt die Verarbeitung für PDO-Nachrichten, die empfangen werden, und die Sende-Konfiguration der zusendenden PDO-Nachrichten.
RX-Konfiguration
Um ein RX-PDO zu konfigurieren, müssen Sie drei Objektkategorien im Objektverzeichnis berücksichtigen:
- 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 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 Eintrag607A0020. Es mappt also die folgenden vier Byte (=20hBit) in das Objekt 607Ah:00h
Dummy-Objekte
Sie können RX-PDOs so konfigurieren, dass mehr als ein Teilnehmer darauf reagiert. In diesem Fall kann es gewünscht sein, nur einen Teil der im PDO enthaltenen Daten in einem der Geräte auszuwerten. Für lokal nicht genutzte Daten können Sie ein Dummy-Objekt von einem der unterstützten Datentypen in das Mapping des PDOs eintragen:
| Index | Datentyp |
|---|---|
| 0002h | INTEGER8 |
| 0003h | INTEGER16 |
| 0004h | INTEGER32 |
| 0005h | UNSIGNED08 |
| 0006h | UNSIGNED16 |
| 0007h | UNSIGNED32 |
TX-Konfiguration
Um ein TX-PDO zu konfigurieren, müssen Sie drei Objektkategorien im Objektverzeichnis berücksichtigen:
- 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 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)).
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:02hBedeutung 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 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 1019h 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 1A00h mit allen Subindizes das erste Mapping, das 1A01h 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 1A00h:00h auf "0" gesetzt, ist das TX-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, also60410010. Das zweite Mapping (1A00h:02h) enthält den Inhalt60640020. 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):
2. Mapping (CAN-ID: 300h + Node-ID):
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):
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
- 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.
- Deaktivieren Sie das Mapping, indem Sie den Subindex 00h des dazugehörigen Mapping Parameter (z.B. 1600h:00h) auf "0" setzen.
- Ändern Sie das Mapping in den gewünschten Subindizes (z.B. 1600h:01h).
- Aktivieren Sie das Mapping, indem Sie die Anzahl der zu mappenden Objekte in den Subindex 00h des dazugehörigen Mapping Parameter (z.B. 1600h:00h) schreiben.
- Aktivieren Sie das PDO, indem Sie Bit 31 des Subindex 01h des dazugehörigen Communication Parameter (z.B. 1400h:01h) auf "0" setzen.
- Speichern sie die Konfiguration, indem Sie den Wert "65766173" in 1010h:03h schreiben.
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.
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 finden. 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 wechselt 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 100Ch:00 hinterlegt (Einheit: Millisekunden)
- 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.
- 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. Sie aktivieren diesen Service, indem Sie die Zeit Producer Heartbeat Time im Objekt 1017h:00h auf einen anderen Wert als Null setzen. 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.
Der Slave kann auch einen Heartbeat von einem anderen Producer (Master oder anderem Slave) überwachen. Dazu müssen Sie die Zeit Consumer Heartbeat Time und die Node-ID des Producer im Objekt 1016h eintragen.
Fehler, die bei dieser Überwachung auftreten, werden zurückgesetzt, wenn entweder die Funktion deaktiviert wird oder der Heartbeat wieder in der korrekten Zeit gesendet wird.