Funktionsprinzip des CANopen-Protokolls
Einführung in das CANopen-Netzwerk
CANopen ist ein auf dem seriellen Bus Controller Area Network (CAN) basierendes Netzwerksystem. Das CANopen-Kommunikationsprofil (CiA DS-301) unterstützt sowohl den direkten Zugriff auf Geräteparameter als auch die Kommunikation zeitkritischer Prozessdaten.
Das CANopen-Geräteprofil für LTMR-Controller ist ein herstellerspezifisches Profil. Dieses Profil legt Standards für grundlegende Gerätefunktionen fest und bietet gleichzeitig breiten Spielraum für zusätzliche, herstellerspezifische Gerätefunktionen.
CANopen nutzt das gesamte Potenzial der CAN-Technologie, indem es einen direkten Austausch von Peer-to-Peer-Daten zwischen Knoten auf organisierte und deterministische Art und Weise ermöglicht.
CANopen-Protokoll
Das CANopen-Protokoll basiert auf der CAN 2.B passive-Spezifikation (mit 11 Bits codierter Kennung).
Die Schnittstelle des LTMR-CANopen-Controllers entspricht den CANopen-Spezifikationen (DS301 V4.02).
Die Controller sind in den EDS-Dateien (Electronic Data Sheet = Elektronisches Datenblatt) beschrieben, die in die Konfigurationstools eingebunden werden müssen.
CANopen-Nachrichtenformat
Nachfolgend ist das Standard-Nachrichtenformat für CANopen beschrieben:
SOF |
COB-ID |
RTR |
CTRL |
Datensegment |
CRC |
ACK |
EOF |
---|---|---|---|---|---|---|---|
1 Bit |
11 Bits |
1 Bit |
5 Bits |
0-8 Bytes |
16 Bits |
2 Bits |
7 Bits |
SOF |
Start of frame (Frame-Beginn) |
COB-ID |
Feld zur Identifikation der CAN-Nachricht, bestehend aus einem Funktionscode (4 Bits) und einer Modul-ID (7 Bits). Der Funktionscode bestimmt die Objektpriorität. Auf diese Weise ist die Kommunikation zwischen einem Netzwerkmanager und 127 Stationen möglich. Der Funktionscode wird mit einem Objektverzeichnis im Geräteprofil bestimmt. Das Senden (Broadcast) wird durch eine Modul-ID von Null angezeigt. |
RTR |
Remote Transmission Request (Dezentrale Übertragungsanforderung) |
CTRL |
Kontrollfeld (d.h. Datenlänge) |
CRC |
Cyclic Redundancy Check (Zyklische Redundanzprüfung) |
ACK |
Acknowledge (Bestätigen) |
OEF |
End of frame (Frame-Ende) |
CANopen-Dienste
CANopen-Kommunikationsobjekte, die über das CAN-Netzwerk übertragen werden, werden durch Dienste beschrieben:
-
NETZWERKMANAGEMENT
Starten des Busses, Parametereinstellung, Überwachung
-
HOCHGESCHWINDIGKEITSÜBERTRAGUNG VON PROZESSDATEN
PDOs (Prozessdaten-Objekte) für Steuerbefehle in Echtzeit
-
NIEDERGESCHWINDIGKEITSÜBERTRAGUNG VON DIENSTDATEN
SDOs (Servicedatenobjekte) zur Konfiguration, Einstellung und Diagnose
Netzwerkmanagement (NMT)
Das CANopen-Netzwerkmanagement ist knotenorientiert und folgt einer Client/Server-Struktur. Im Netzwerk wird ein Gerät benötigt, das die Funktion des NMT-Clients übernimmt. Die anderen Knoten sind NMT-Server.
(1) |
Beim Start geht das Gerät in den Initialisierungszustand über. |
(2) |
Nach Abschluss der Initialisierung wird automatisch der „präoperationale“ Zustand aktiviert (es können Parameter gesendet werden). Hinweis: Im präoperationalen Zustand können einige per Konfiguration gewählte Parameter geschrieben werden. |
(3) (6) |
Start_Remote_Node (Start_Dezentral_Knoten) |
(4) (7) |
Enter_Pre-Operational_State, and apply fallback (Übergang in präoperationalen Zustand und Ausführung der Fehlerausweichsequenz) |
(5) (8) |
Stop_Remote_Node (Stopp_Dezentral_Knoten) |
(9) (10) (11) |
Reset_Node (Rückstellen_Knoten) |
(12) (13) (14) |
Reset_Communication (Rückstellen_Kommunikation) |
Prozessdatenobjekte (PDOs)
Die Übertragung von Echtzeitdaten erfolgt mittels PDO-Telegrammen (Process Data Object). Process Data sind zeitkritische Daten, die zur Überwachung und Steuerung des Geräts verwendet werden.
Das CANopen-Controller-Kommunikationsmodul weist folgende Merkmale auf:
PDOs |
Beschreibung |
Status |
---|---|---|
Sende-PDO1 |
Zur Überwachung (Übertragung von Daten durch den Server) |
Vorkonfiguriert und aktiviert |
Empfangs-PDO1 |
Zur Steuerung (Übertragung von Daten durch den Client) |
|
Sende-PDO2 |
Verwendung zum Datenaustausch (bei der Konfiguration festgelegt) |
Zu konfigurieren und zu aktivieren |
Empfangs-PDO2 |
||
Sende-PDO3 |
||
Empfangs-PDO3 |
||
Sende-PDO4 |
Für den Zugriff (Lesen oder Schreiben) auf ein beliebiges Register per Programmierung |
Vorkonfiguriert und aktiviert |
Empfangs-PDO4 |
Die RPDO- (Empfangs-PDO) und TPDO-Objekte (Sende-PDO) können so konfiguriert werden, dass sie 8 Byte an Daten enthalten (z. B. als vier 16-Bit-Register oder ein 64-Bit-Objekt angeordnet).
Die RPDO-Objekte verfügen über Schreibzugriff.
Je nach Applikation muss der PDO-Kommunikationsmodus auf asynchron, zyklisch oder azyklisch synchron eingestellt werden.
Im Synchron-Modus ist die PDO-Übertragung mit dem SYNC-Objekt verknüpft, das zyklisch vom CANopen-Client ausgegeben wird. Sie enthält keine Daten. Die Werkseinstellung ist 0x080.
Übertragungsmodus:
Übertragungstyp |
PDO-Übertragung |
|||
---|---|---|---|---|
Zyklisch |
Azyklisch |
Synchron |
Asynchron |
|
0 PDO wird synchron mit dem SYNC-Objekt gesendet, ausgelöst durch eine Datenwertänderung. |
√ |
√ |
||
1–240 PDO wird ein Mal alle 1 bis 240 Eingänge des SYNC-Objekts durch das Kommunikationsmodul gesendet. |
√ |
√ |
||
255 Werkseinstellung für den Kommunikationsmodus |
√ |
√ |
Weitere Informationen zu PDOs finden Sie unter Using PDOs.
Servicedatenobjekte (SDOs)
Servicedatenobjekte (SDOs) dienen zur Gerätekonfiguration und zur Festlegung von Typ und Format der über die PDOs gesendeten Informationen.
SDOs ermöglichen den Zugriff auf ein beliebiges Objekt im Objektverzeichnis des Gerätes.
CANopen-Clients senden azyklisch Meldungen über SDOs. Sie werden ebenfalls für asynchrone, aperiodische Anforderungen verwendet. Ein SDO kann beispielsweise eingesetzt werden, um die Identifikation einer Steuereinheit zu lesen.
Das CANopen-Kommunikationsmodul verwaltet einen SDO-Server, der zwei COB-IDs empfängt:
-
Eine für Anforderungen (vom Client an den CANopen-LTMR gesendete Telegramme)
-
Eine für Antworten (vom CANopen-LTMR an den Client zurückgesendete Telegramme)
Weitere Informationen zu SDOs finden Sie unter Using SDOs.