CANopen

canopen motor controller for integrated stepper motor and bldc motor

Um die Länge der Kabelbäume in Fahrzeugen zu reduzieren und Gewicht zu sparen, hat die Firma Bosch im Jahr 1987 den sogenannten CAN-Bus zur Vernetzung von Steuergeräten entwickelt. CAN ist die Abkürzung für ‚Controller Area Network‘ und wird häufig in Kombination mit ‚Bus‘ (Binary Unit System) verwendet, um ein System zur Datenübertragung zwischen verschiedenen Komponenten auf einem gemeinsamen Übertragungsweg zu beschreiben.

CANopen ist ein auf CAN basierendes Kommunikationsprotokoll, das hauptsächlich in der Automatisierungstechnik und zur Vernetzung komplexer oder zeitkritischer Maschinen und Anlagen verwendet wird. Seit 1995 wird es von der Organisation CAN in Automation (CiA) gepflegt und ist als Europäische Norm EN 50325-4 standardisiert. CANopen standardisiert nicht nur die untere Kommunikationsebene, wie z.B. RS485, sondern auch die Befehlsstruktur für verschiedene Gerätetypen.

Vorteile 

  • robuste Technologie, ideal geeignet für Netzwerktopologien mit kurzen Stichleitungen und verdrillten Kabelpaarsätzen
  • Bis zu 127 Knoten/Geräte in einem Netzwerk möglich, auch für Mehrachssysteme verwendbar 
  • Datenübertragungsraten bis zu 1 Mbit/s 
  • Standardisiertes Protokoll, für viele Gerätetypen verwendbar

Nanotec bietet Motor Controller sowie bürstenlose DC-Motoren und Schrittmotoren mit integriertem Controller und CANopen-Schnittstelle an. 

Die Nanotec-Controller entsprechen dem Standard CiA402 für elektrische Antriebe und sind somit kompatibel mit Produkten anderer Hersteller.


Controller mit CANopen

Motoren mit CANopen


CANopen Dienste

Der CANopen-Stack bietet die in der nachfolgenden Tabelle abgedruckten Dienste (auch Services genannt) an.   

Default CAN-IDService Beschreibung in
000Network Management (NMT)Kapitel Network Management (NMT)
080h Synchronization ObjectKapitel Synchronization object (SYNC)
080h+Node-lD Emergency Kapitel Emergency Object (EMCY) 
180h+Node-lD TX Process Data Objects (PDO) Kapitel Process Data Object (PDO)
200h+Node-lD RX Process Data Objects (PDO) Kapitel Process Data Object (PDO)
280h+Node-lD TX Process Data Objects (PDO) Kapitel Process Data Object (PDO)
300h+Node-lD RX Process Data Objects (PDO) Kapitel Process Data Object (PDO)
380h+Node-lD TX Process Data Objects (PDO) Kapitel Process Data Object (PDO)
400h+Node-lD RX Process Data Objects (PDO) Kapitel Process Data Object (PDO)
480h+Node-lD TX Process Data Objects (PDO) Kapitel Process Data Object (PDO)
500h+Node-lD RX Process Data Objects (PDO) Kapitel Process Data Object (PDO)
580h+Node-lD TX Service Data Objects (SDO) Kapitel Service Data Object (SDO)
600h+Node-lD RX Service Data Objects (SDO)Kapitel Service Data Object (SDO)
700h+Node-lD BOOT-UP ProtocolKapitel Boot-Up Protocol 
700h+Node-lD Nodeguarding and HeartbeatKapitel 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-Befehls "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 lnitializing Pre-Operational Operational Stopped
PDOaktiv
SDOaktivaktiv
SYNCaktivaktiv
EMCYaktivaktiv
BOOT-UP aktiv
NMTaktivaktivaktiv

 

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
01hSchalte in den Zustand "Operational"
02hSchalte in den Zustand "Stop"
80hSchalte in den Zustand "Pre-Operational"
81hReset Node 
82hReset 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.


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 Process Data Object (PDO)).

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

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

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



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>) 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: 

  1. Das zum Fehler gehörige Bit im Objekt "Error Register" (1001h) wird gesetzt.
  2. 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
  3. Steht kein weiterer Fehler mehr an, wird folgende Nachricht verschickt:
    80 + Node-ID 1 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.
  • <SUBIDX>: Subindex des Objektes im Objektverzeichnis von 00h bis FFh.

Da CAN-Nachrichten des Types SDO sehr viele Meta-Daten beinhalten, sollte mit SDO-Nachrichten nur die Konfiguration der Steuerung vorgenommen werden. Sollte es notwendig sein, im laufenden Betrieb Daten zyklisch auszutauschen, ist es sinnvoller, auf CANopen-Nachrichten des Types PDO zurück zu greifen (siehe 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 INTEGER32in das Objektverzeichnis schreiben (download) oder auslesen (upload). Dieser Service ist bestätigt, d.h. auf jeden Zugriff wird entweder mit Daten, einer Bestätigung oder mit einer Fehlermeldung geantwortet.

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

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

  • 1 Byte Datenlänge: 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  

  • 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

lf successful, the controller responds with this message:

583 | 60 7A 60 00 00 00 00 00

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

Der Server antwortet dabei mit einer der nachfolgenden Nachrichten. 

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): leer. Eine SDO-Nachricht besteht immer aus 8 Bytes.

SDO-Fehlermeldungen

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

Error CodeBeschreibung
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. 
05040000hcommand specifier unknown: Das Byte 0 des Datenblocks enthielt einen nicht zulässigen Befehl. 
06010000hunsupported access: Falls über CAN over EtherCAT (CoE) ein "complete access" angefordert wurde (wird nicht unterstützt.)
06010002hread only entry: Es wurde versucht, auf ein konstantes oder nur lesbares Objekt zu schreiben. 
06020000hobject not existing: Es wurde versucht, auf ein konstantes oder nur lesbares Objekt zu schreiben.
06040041hobject 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.
06070012hparameter 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.
06070013hparameter 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.
06090011hsubindex not existing: Es wurde versucht, auf einen ungültigen Subindex eines Objektes zuzugreifen, der Index hingegen würde existieren.
06090031hvalue 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.
06090032hvalue 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.
08000000hgeneral error: Allgemeiner Fehler, der in keine andere Kategorie passt.
08000022hdata 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 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 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) 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)).
MappingCOB-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:02hBedeutung
00h-F0hSynchronous: Die Daten werden zwischengespeichert und erst mit dem Erhalt der nächsten SYNC-Nachricht gültig und in das Objektverzeichnis übernommen.
F1h-FDhReserviert 
FEh,FFhAsynchronous: 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 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 TX-PDO zu konfigurieren, müssen drei Objektkategorien im Objektverzeichnis berücksichtigt werden:

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

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

Konfiguration der Funktionalität (Communication Parameter)

Die Konfiguration der Funktionalität des ersten Mappings wird in den Subindizes des Objektes 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) 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)).
MappingCOB-ID
1A00h180h + Node-ID
1A01h280h + Node-ID
1A02h380h + Node-ID
1A03h480h + Node-ID
1A04hXXXh + Node-ID
1A05hXXXh + Node-ID
1A06hXXXh + Node-ID
1A07hXXXh + 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
0Synchronous (acyclic): Die Daten werden mit dem Eintreffen des SYNC in das TX-PDO kopiert aber erst mit dem Event versendet. 
01h-F0hSynchronous (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-FBhReserviert
FChRTR-Only (synchronous): Die Daten werden mit dem Eintreffen jeder SYNC-Nachricht kopiert aber erst auf Anforderung mittels einer RTR-Nachricht verschickt.
FDhRTR-Only (event-driven): Die Daten werden mit dem Erhalt einer RTR-Nachricht in die TX-PDO-Nachricht kopiert und daraufhin sofort versendet.
FEh,FFhDie Daten werden beim Eintreten des Events kopiert und sofort versendet.
  • Subindex 3 (inhibit time): Dieser Subindex enthält eine Zeitsperre (siehe nachfolgende Abbildung). Hier kann eine Zeit eingestellt werden, die nach einem Senden eines PDOs abgelaufen sein muss, damit ein weiteres Mal das PDO verschickt wird. Diese Zeit gilt nur für asynchrone PDOs. Dadurch soll verhindert werden, dass asynchrone PDOs permanent verschickt werden, wenn sich das gemappte Objekt dauernd ändert.
  • Subindex 4 (compatibility entry): Dieser Subindex hat keine Funktion und ist nur aus Gründen der Kompatibilität vorhanden.
  • Subindex 5 (event timer): Diese Zeit kann benutzt werden um ein Event auszulösen, welcher für das Kopieren der Daten und Senden des PDOs sorgt.
  • Subindex 6 (sync start value): hier wird der Startwert des Sync Counter eingetragen, ab welchem der Slave auf den Sync zum ersten Mal reagieren und das PDO senden soll. Wird global erst aktiviert, wenn in 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, 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.

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 and 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.
  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, indem die Zeit Producer Heartbeat Time im Objekt 1017h:00auf einen anderen Wert als Null gesetzt wird. 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.

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.

Zurück

Fragen? Kommentare?

Haben Sie Fragen oder Anmerkungen zu diesem Artikel?

Support kontaktieren