MELARECON und CANopen
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.
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-Rate | Max. Leitungslänge |
|---|---|
| 10 kBit/s | 6,7 km |
| 20 kBit/s | 3,3 km |
| 50 kBit/s | 1,0 km |
| 100 kBit/s | 600 m |
| 125 kBit/s | 500 m |
| 250 kBit/s | 250 m |
| 500 kBit/s | 125 m |
| 800 kBit/s | 75 m |
| 1 MBit/s | 40 m |
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-Leitung | Bedeutung |
|---|---|
| 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-SHLD | Schirmgeflecht |
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.
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.
| Geräteprofile (CiA) | für Gerätetypen |
|---|---|
| DS 401 | Digitale und analoge E/A |
| DS 402 | Antriebe |
| DS 403 | Bedienen und Beobachten |
| DS 404 | Sensoren / Regler |
| DS 405 | Programmierbare Geräte |
| DS 406 | Encoder |
| DS … | (weitere Profile) |
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 |
|---|---|
| 0000 | Wird nicht genutzt |
| 0001 – 001F | Statische Datentypen |
| 0020 – 003F | Komplexe Datentypen |
| 0040 – 005F | Hersteller spezifische komplexe Datentypen |
| 0060 – 007F | Geräteprofil spezifische statische Datentypen |
| 0080 – 009F | Geräteprofil spezifische komplexe Datentypen |
| 00A0 – 0FFF | Reserviert |
| 1000 – 1FFF | Parameter aus Kommunikationsprofil |
| 2000 – 5FFF | Hersteller spezifische Parameter |
| 6000 – 9FFF | Standardisierte Parameter aus Geräteprofil |
| A000 – FFFF | Reserviert |
| Index | Subindex | Name | Access | PDO-Mapping |
|---|---|---|---|---|
| 0005 | – | Dummy 8 | ro | Yes |
| 0006 | – | Dummy 16 | ro | Yes |
| 0007 | – | Dummy 32 | ro | Yes |
| 1000 | – | Device Type | ro | – |
| 1001 | – | Error Register | ro | – |
| 1002 | – | Status Register | ro | – |
| 1005 | – | COB-ID SYNC | rw | – |
| 1008 | – | Device Name | ro | – |
| 1009 | – | Hardware-Version | ro | – |
| 100A | – | Software-Version | ro | – |
| 100C | – | Guard Time | rw | – |
| 100D | – | Life Time Factor | rw | – |
| 100E | – | COB-ID Guard | rw | – |
| 1014 | – | COB-ID Emergency | rw | – |
| 1015 | – | Inhibit Time Emergency | rw | – |
| 1018 | Identity Object | |||
| 0 | no. of subentries | ro | – | |
| 1 | Vendor ID | ro | – | |
| 2 | Product Code | ro | – | |
| 3 | Revision Number | ro | – | |
| 4 | Serialnumber | ro | – | |
| 2000 | – | Device Manufacturer | ro | – |
| 6000 | Digital Input 8-Bit | |||
| 0 | no. of subentries | ro | – | |
| 1 | Digital inputs 1 to 8 | ro | Yes | |
| 2 | Digital inputs 9 to 16 | ro | Yes | |
| 3 | Digital inputs 17 to 24 | ro | Yes | |
| 4 | Digital inputs 25 to 32 | ro | Yes |
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.
| PDO | SDO |
|---|---|
| Echtzeitdaten | System-Parameter |
| Telegramm wird nicht beantwortet (Schnelle Übertragung) | Telegramm wird immer beantwortet (Langsame Übertragung) |
| Hohe Priorität | Niedrige Priorität |
| Max. 8 Bytes pro Telegramm | Daten können auf mehrere Telegramme verteilt werden. |
| Vorvereinbartes Datenformat | Indexadressierbare Daten |
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 |
|---|---|---|
| 00000000000 | 0 | Netzwerkmanagement |
| 00010000000 | 80 | Synchronisation |
| 0001xxxxxxx | 81-FF | Emergency |
| 0011xxxxxxx | 181-1FF | TxPDO1 |
| 0100xxxxxxx | 201-27F | RxPDO1 |
| 0101xxxxxxx | 281-2FF | TxPDO2 |
| 0110xxxxxxx | 301-37F | RxPDO2 |
| 0111xxxxxxx | 381-3FF | TxPDO3 |
| 1000xxxxxxx | 401-47F | RxPDO3 |
| 1001xxxxxxx | 481-4FF | TxPDO4 |
| 1010xxxxxxx | 501-57F | RxPDO4 |
| 1011xxxxxxx | 581-5FF | SDO senden |
| 1100xxxxxxx | 601-67F | SDO empfangen |
| 1110xxxxxxx | 701-77F | NMT Error Control |
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:
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.
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.
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.
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.
