DOCA0132DE-01

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.

HINWEIS: Weitere Informationen über CANopen finden Sie auf der „Can In Automation“-Website: http://www.can-cia.de.

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.

Die CANopen-NMT-Servergeräte implementieren eine Zustandsmaschine, die nachfolgend beschrieben ist:

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

QR Code is a registered trademark of DENSO WAVE INCORPORATED in Japan and other countries.

War das hilfreich für Sie?