MELARECON und CANopen

MELARECON und CANopen

canopen-logo

Was ist CAN?

CAN steht für „Controller Area Network“ und wurde von den Firmen Bosch und Intel ursprünglich als Bussystem für die Fahrzeugtechnik entwickelt. Inzwischen hat sich CAN aber auch im Bereich der Automatisierungstechnik als Feldbus bewährt. Der CAN-Bus ist ein serielles Bussystem, bei dem alle angeschlossenen Stationen (Knoten oder Nodes) gleichberechtigt sind. Dies bedeutet, dass jedes Steuergerät sowohl senden als auch empfangen darf und somit gegenseitig Informationen austauschen können. Durch die lineare Bus-Struktur sind bei Ausfall einer Station alle anderen Stationen weiterhin voll verfügbar. Um Reflexionen an den Bus-Enden zu vermeiden, sind diese mit einem Abschlusswiderstand zu versehen. Auf dem MELARECON-Mainboard sind hierzu entsprechende Dip-Schalter vorhanden, die bei den jeweils letzten Teilnehmern eingeschaltet werden können.

Anschlussbeispeil für CAN-Bus-Teilnehmer
Anschlussbeispeil für CAN-Bus-Teilnehmer

Die maximale Buslänge, also die Kabellänge zwischen dem ersten und letzten Teilnehmer, ist abhängig von der Übertragungsgeschwindigkeit. Am MELARECON ist werksseitig eine Übertragungsrate von 125kBit/s eingestellt, was eine Buslänge von 500m ermöglicht. Diese kann aber am MELARECON beliebig eingestellt werden.

Bit-RateMax. Leitungslänge
10 kBit/s6,7 km
20 kBit/s3,3 km
50 kBit/s1,0 km
100 kBit/s600 m
125 kBit/s500 m
250 kBit/s250 m
500 kBit/s125 m
800 kBit/s75 m
1 MBit/s40 m
Leitungslänge zu Übertragungsrate

Zur optimalen Übertragung sollten stets spezielle, für CAN-Bus geeignete, Kabel eingesetzt werden (z.B. Lapp UNITRONIC BUS CAN UL/CSA 2x2x0,5 2170267). Die Leitung sollte mindestens drei Adern enthalten, wobei zwei Adern verdrillt (für CAN-H und CAN-L) sind. Weiterhin sollte die Leitung geschirmt sein.

CAN-LeitungBedeutung
CAN-L (Gelb)Signal-Leitung CAN-Low
CAN-H (Grün)Signal-Leitung CAN-High
CAN-GND (Weiß)Ground-Leitung
CAN-VCC (Braun)Versorgungs-Leitung (Optional)
CAN-SHLDSchirmgeflecht
CAN-Signal-Leitungen

Bei CAN werden generell keine Stationen adressiert, sondern der Inhalt einer Nachricht wird durch einen eindeutigen Nummerncode (Identifier) gekennzeichnet. Die Nachrichtenübertragung erfolgt bitweise auf den differentiellen Leitungspaar CAN-L und CAN-H. Dabei werden für die Bitinformation zwei Zustände (dominant = 0 und rezessiv = 1) unterschieden. Im folgenden Bild wird der allgemeine Aufbau eines Telegramms aufgezeigt.

Aufbau CAN-Telegramm
Aufbau CAN-Telegramm

Aus dem Aufbau des Telegramms ist zu erkennen, dass dieses immer mit dem Identifier beginnt. Dadurch ergibt sich automatisch eine Priorität einer Nachricht auf dem Bus. Je kleiner ein Identifier ist, um so höher ist die Priorität des Telegramms auf dem Bus, da eine zu übertragende 0 immer dominant ist.

Was ist CANopen?

Während CAN selbst lediglich für die OSI Schichten 1 und 2 in der ISO 11898 genormt ist, wird durch CANopen ein Schicht-7 Protokoll auf CAN aufgesetzt. Dadurch wird einerseits das „Wie“ der Kommikation festgelegt, also mit welchen Telegrammen und welchem Aufbau der Telegramme die Geräte angesprochen werden können und andererseits das „Was“ der Kommunikation festgelegt, sprich was ist die Bedeutung einer Einstellung am Gerät bzw. welche Einstellungen bietet das Gerät überhaupt. Dieses wird in Geräteprofilen bzw. Applikationsprofilen festgelegt.

Diese sogenannten CANopen-Profile sind in Tabellenform (Objektverzeichnis) organisiert. Allen Geräteprofilen gemeinsam ist das sogenannte „Kommunikationsprofil“ durch welches grundlegende Gerätedaten abgefragt bzw. eingestellt werden können. Dies können sein die Gerätebezeichnung, Hardware- und Software-Version, Fehlerstatus und andere Parameter. Durch die Geräteprofile wird das Kommunikationsprofil um die Geräte spezifischen Einstellungen und Parameter erweitert und definiert. So gibt es Profile für digitale und analoge E/A, Antriebe, Sensoren, Regler usw.

Aufbau OSI-Schichten und Geräteprofile bei CANopen
Aufbau OSI-Schichten und Geräteprofile bei CANopen
Geräteprofile (CiA)für Gerätetypen
DS 401Digitale und analoge E/A
DS 402Antriebe
DS 403Bedienen und Beobachten
DS 404Sensoren / Regler
DS 405Programmierbare Geräte
DS 406Encoder
DS …(weitere Profile)
Beispiele für Geräteprofile

Das Objektverzeichnis

CANopen beschreibt die Eigenschaften von Geräten in sogenannten Geräteprofilen. Diese sind im Prinzip definierte Variablensätze. Abhängig vom Gerätetyp werden bestimmte Daten bzw. Parameter in einem Objektverzeichnis fest definiert. Hierbei handelt es sich um eine Zusammenstellung aller Variablen und Parameter (Objekte) eines CANopen Geräts. Dabei enthalten die Daten das Prozessabbild und mit den Parametern kann das Funktionsverhalten eines CANopen Gerätes beeinflusst werden.

Ein Objektverzeichnis ist so aufgebaut, dass einige Parameter für alle Geräte einer Kategorie zwingend vorgeschrieben sind und andere frei definiert und verwendet werden dürfen.

Jedes Objekt erhält in CANopen vornehmlich eine Nummer (den sogenannten Index), mit welchem jeder Parameter bzw. Objekt eindeutig adressiert werden kann. Die Objekte können einfache Datentypen wie z.B. Bytes, Integer, Longs oder auch Strings sein. Bei komplexeren Strukturen, wie z.B. Arrays, wird die Adressierung der einzelnen Elemente zusätzlich über einen Subindex realisiert.

Die Struktur des Objektverzeichnisses, die Vergabe der Index-Nummern sowie einige Pflichteinträge sind in den Geräteprofilen spezifiziert.

Object Index (hex)Object
0000Wird nicht genutzt
0001 – 001FStatische Datentypen
0020 – 003FKomplexe Datentypen
0040 – 005FHersteller spezifische komplexe Datentypen
0060 – 007FGeräteprofil spezifische statische Datentypen
0080 – 009FGeräteprofil spezifische komplexe Datentypen
00A0 – 0FFFReserviert
1000 – 1FFFParameter aus Kommunikationsprofil
2000 – 5FFFHersteller spezifische Parameter
6000 – 9FFFStandardisierte Parameter aus Geräteprofil
A000 – FFFFReserviert
Prinzipielle Vergabe der Objekt-Index-Nummern
IndexSubindexNameAccessPDO-Mapping
0005Dummy 8roYes
0006Dummy 16roYes
0007Dummy 32roYes
1000Device Typero
1001Error Registerro
1002Status Registerro
1005COB-ID SYNCrw
1008Device Namero
1009Hardware-Versionro
100ASoftware-Versionro
100CGuard Timerw
100DLife Time Factorrw
100ECOB-ID Guardrw
1014COB-ID Emergencyrw
1015Inhibit Time Emergencyrw
1018Identity Object
0no. of subentriesro
1Vendor IDro
2Product Codero
3Revision Numberro
4Serialnumberro
2000Device Manufacturerro
6000Digital Input 8-Bit
0no. of subentriesro
1Digital inputs 1 to 8roYes
2Digital inputs 9 to 16roYes
3Digital inputs 17 to 24roYes
4Digital inputs 25 to 32roYes
Auszug aus dem Objektverzeichnis des MELARECON´s

Wie funktioniert der Zugriff auf das Objektverzeichnis bei CANopen?

Der Datenaustausch in CANopen erfolgt in Form von Telegrammen, mit denen die Nutzdaten übertragen werden. Unterschieden werden hierbei die Servicedatenobjekte (Service data objects > SDO), die zur Übermittlung der Servicedaten aus dem bzw. in das Objektverzeichnis verwendet werden, und die Prozessdatenobjekte (Process data objects > PDO), die zum Austausch von aktuellen Prozesszuständen dienen. Zusätzlich gibt es noch Telegramme für das Netzwerk Management und für die Fehlermeldungen.

Mit SDO kann auf die Einträge im Objektverzeichnis zugegriffen werden. Dieses erfolgt nach dem Client-Server-Prinzip. Ein Gerät stellt eine Anfrage und die entsprechende Gegenstelle antwortet. In der Praxis werden SDOs meist zur Initialisierung während eines Boot-Vorgangs verwendet.

PDOs sind im Prinzip eine Zusammenfassung verschiedener Objekte aus dem Objektverzeichnis, welche entweder zyklisch, bei Zustandsveränderung oder durch Senden von Synchronisations-Telegrammen gesendet werden. Ein PDO kann maximal 8 Byte beinhalten. Der Inhalt eines PDOs kann frei konfiguriert werden (das sogenannte PDO-Mapping). Im Gegensatz zu den SDOs wird ein PDO-Telegramm nicht beantwortet und ist somit deutlich schneller.

PDOSDO
EchtzeitdatenSystem-Parameter
Telegramm wird nicht beantwortet
(Schnelle Übertragung)
Telegramm wird immer beantwortet
(Langsame Übertragung)
Hohe PrioritätNiedrige Priorität
Max. 8 Bytes pro TelegrammDaten können auf mehrere Telegramme verteilt werden.
Vorvereinbartes DatenformatIndexadressierbare Daten
Vergleich PDO zu SDO

Bei CANopen wird auf die Multimasterfähigkeit zu Gunsten des Netzwerkmanagements verzichtet und führt daher einen CAN-Master (NMT-Master) ein, der die Aufgaben des Netzwerkmanagements implementiert. Alle weiteren CAN-Knoten (Nodes) werden als sogenannte Slave-Baugruppen implementiert.

Ein Master steuert das Netzwerk durch:

  • Kommunikationsobjekte für den Boot-Up (Starten, Anhalten, Zurücksetzen usw.)
  • Kommunikationsobjekte für das Nodeguarding oder Lifeguarding – Damit kann eine Überwachung des Netzwerks durchgeführt werden
  • Kommunikationsobjekte für die Synchronisierung
  • Kommunikationsobjekte für Notfallmeldungen (Emergency)

Generell sind alle Identifier komplett frei konfigurierbar. Um Konfigurationsaufwand zu sparen, gibt es eine Default-Identifier-Verteilung. Diese ist in CANopen wie folgt definiert:

Identifier (binär)Identifier (hex)Funktion
000000000000Netzwerkmanagement
0001000000080Synchronisation
0001xxxxxxx81-FFEmergency
0011xxxxxxx181-1FFTxPDO1
0100xxxxxxx201-27FRxPDO1
0101xxxxxxx281-2FFTxPDO2
0110xxxxxxx301-37FRxPDO2
0111xxxxxxx381-3FFTxPDO3
1000xxxxxxx401-47FRxPDO3
1001xxxxxxx481-4FFTxPDO4
1010xxxxxxx501-57FRxPDO4
1011xxxxxxx581-5FFSDO senden
1100xxxxxxx601-67FSDO empfangen
1110xxxxxxx701-77FNMT Error Control
Default-Identifier -> xxxxxxx = Knotennummer 1-127

Um nun also zu der eigentlichen Frage, die oben gestellt wurde, zurück zu kommen: Wie fragt man nun einen Eintrag im Objektregister ab bzw. wie beschreibt man einen solchen Eintrag?

Man erstellt eine CAN-Message mit dem Identifier 600h + Node-ID (1-127 dezimal) mit einem speziellen Dateninhalt. Diese Nachricht wird gesendet und der entsprechende Partner antwortet mit dem Identifier 580h + Node-ID und entsprechenden Daten. Das Protokoll einer SDO-Anfrage sieht wie folgt aus:

Aufbau SDO-Protokoll
Aufbau SDO-Protokoll

Wie funktioniert PDO?

Anders als bei SDO gibt es für PDO-Telegramme kein festes Protokoll. Ein PDO enthält nur Daten und der Dateninhalt ist generell dynamisch und kann in der Regel über die Einstellungen des Kommunikationsprofils (DS 301) eingesehen bzw. festgelegt werden. Ein Node unterscheidet zwischen zwei PDO-Typen:

  • Tx: Ausgabe von Prozesszuständen an das Netzwerk
  • Rx: Entgegennahme von Prozesszuständen vom Netzwerk

Wann ein PDO gesendet wird bzw. vom Node übernommen wird, wird ebenfalls über die Einstellungen des Kommunikationsprofils festgelegt. Hierbei gibt es die Möglichkeit Prozessdaten ereignisgesteuert oder zeitgesteuert zu übertragen. Das Verhalten der einzelnen PDOs kann über den Transmission Type im Objektverzeichnis (z.B. Index 1400h; Subindex 2) eingestellt werden. Die nachfolgende Tabelle zeigt das entsprechende Verhalten auf.

Tabelle für Transmission Type

Der Inhalt eines PDOs kann über die Indexe 1600h – 1603h für empfangene Daten und 1800h – 1803h für zu sendende Daten eingesehen werden. Über das Display oder über eine Remote-Verbindung zum MELARECON können diese Ein- bzw. Ausgaben ebenfalls editiert werden. Wechseln Sie dazu in die Installationseinstellungen, wählen Sie dann die E/A-Konfiguration und danach Feldgeräte und dann auf CAN2.

Node-Einstellungen am MELARECON
Node-Einstellungen am MELARECON
Editierung der PDO am MELARECON
Editierung der PDO am MELARECON

Netzwerk-Management

In einem CANopen-Netzwerk gibt es maximal einen NMT-Master, welcher die Organisation im Netzwerk übernimmt. Dieser versetzt die einzelnen Netzwerk-Teilnehmer in verschiedene Betriebsmodi und übernimmt in der Regel die Initialisierung der einzelnen Stationen. Insgesamt gibt es vier Betriebszustände:

  • Initialisierung: Zustand den jeder Knoten beim Einschalten oder Neustart durchläuft. Nach der Initialisierung geht der Knoten automatisch in einen der anderen drei Zustände. Dies kann in der Regel über das Objektverzeichnis festgelegt werden.
  • Pre-Operational: In diesem Zustand (auch Pre-OP genannt) kann mit dem Knoten nur über SDO kommuniziert werden. Eine PDO-Kommunikation ist nicht möglich.
  • Operational: Im Zustand „OP“ hat der Node die volle Betriebsbereitschaft und kann selbstständig Prozessdaten senden und empfangen.
  • Stopped: Im Zustand „STOP“ wird der Knoten vollständig vom Netz abgeschaltet. Weder SDO- als auch PDO-Kommunikation ist möglich. Der Knoten hört nur noch auf entsprechende Netzwerk-Kommandos. In der Regel kann über das Objektregister konfiguriert werden welche Zustände Ausgänge in diesem Modus einnehmen sollen.
Betriebsmodi von Nodes in CANopen
Betriebsmodi von Nodes in CANopen

Funktionen von CANopen am MELARECON

Der MELARECON verfügt über zwei CAN-Bus-Anschlüsse. Einer davon (CAN1) wird als NMT-Master betrieben. Hier ist es möglich jedes beliebige CANopen-Gerät anzuschließen und deren Prozessdaten und Servicedaten zu lesen und zu beschreiben. Der CAN1 übernimmt dabei das volle Netzwerk-Management vom Wechseln in die einzelnen Betriebsmodi, über die Initialisierung der Nodes bis hin zur Überwachung mittels Node-Guarding.

Der zweite Anschluss (CAN2) ist als vollständiger CANopen-Node implementiert. Hierüber ist es möglich die Peripherie des MELARECON´s in ein bestehendes CANopen-Netzwerk einzubinden und z.B. von einer SPS steuern und auswerten zu lassen.

 

Diese Seite verwendet Cookies, um die Nutzerfreundlichkeit zu verbessern. Mit der weiteren Verwendung stimmst du dem zu.

Datenschutzerklärung