CANopen. Funktionsbeschreibung. für den Einsatz in DIORAIL/DIOLINE20-Modulen. Version April /39

Transkript

1 CANopen Funktionsbeschreibung für den Einsatz in DIORAIL/DIOLINE20-Modulen Version 2.30 April /39

2 Die Lütze Transportation GmbH behält sich das Recht vor, Änderungen an ihren Pdukten vorzunehmen, die der technischen Weiterentwicklung dienen. Diese Änderungen werden nicht notwendigerweise in jedem Einzelfall dokumentiert. Dieses Handbuch und die darin enthaltenen Informationen wurden mit der gebotenen Sorgfalt zusammengestellt. Die Lütze Transportation GmbH übernimmt jedoch keine Gewähr für Druck- oder andere Fehler oder daraus entstehende Schäden. Die in diesem Buch genannten Marken und Pduktnamen sind Warenzeichen oder eingetragene Warenzeichen der jeweiligen Titelhalter. Copyright 2014 by Lütze Transportation GmbH. Alle Rechte vorbehalten. So können Sie uns erreichen Lütze Transportation GmbH Bruckwiesenstraße D Weinstadt - Gßheppach Germany Telefon - Zentrale: ++49/ (0)7151/ Telefax: ++49/ (0)7151/ sales.transportation@luetze.de Website: 2/39

3 Funktionsbeschreibung CANopen Vers Inhalt Inhaltsverzeichnis 1 Funktionsumfang CANopen Kommunikation Das CANopen Kommunikationsmodell Default-Identifier und Prioritäten der Kommunikationskanäle CANopen-Objektverzeichnis Prinzipielle Struktur CANopen-Objektverzeichnis Übersicht CANopen-Objektverzeichnis Das Netzwerkmanagement NMT Konfiguration und Start Minimal Boot-Up Funktionalität der Knotenmodule in den Betriebszuständen Power On, Reset Stopped Pre-Operational Operational Das Servicedatenobjekt SDO Upload von Daten Download von Daten Aufbau eines SDO-Telegramms Servicedatenobjekte mit Geräteinformation Das Pzessdatenobjekt PDO PDO Kommunikationsparameter COB-ID Übertragungsart Ruhezeit (Inhibit Time) Ereignis Timer (Event Timer) Mapping-Parameter und Mapping-Objekte Mapping-Parameter Mapping-Objekte PDO-Belegung Das Emergency-Objekt und Fehlerverhalten /39

4 Inhalt Funktionsbeschreibung CANopen Vers Das Emergency-Telegramm Fehlerregister (Objekt 1001H) Hersteller-Statusregister (Objekt 1002H) Tabelle Err-Codes Fehlermeldung (Objekt H) Fehlerverhalten des Moduls Fehlerverhalten der digitalen Ausgänge Fehlerverhalten der analogen Ausgänge Parameterspeicherung Ausfallüberwachung Node-/Lifeguarding Heartbeat-Ausfallüberwachung Verhalten der Ein- und Ausgänge Änderungshistorie /39

5 Funktionsbeschreibung CANopen Vers Inhalt Abbildungsverzeichnis Abb. 1: CANopen Kommunikationsmodell...7 Abb. 2: Blockbild Minimal-Boot-Up Abb. 3: Node-/Lifeguarding Abb. 4: Heartbeat-Ausfallüberwachung /39

6 Funktionsumfang Funktionsbeschreibung CANopen Vers Funktionsumfang Diese Funktionsbeschreibung enthält die erforderlichen Informationen für die CANopen-Anbindung der DIORAIL/DIOLINE20-Module. Grundlagen für die Software-Realisierung bilden die von CAN in Automation (CiA) spezifizierten Standards: CiA DS-201: CiA DS-207: CiA DS-301, V4.01: CiA DSP 401, V2.0: CAN Application Layer for Industrial Applications CANopen Communication Pfile for Industrial Systems Device Pfile for I/O-Modules Unterstützte CANopen-Merkmale Boot-Up-Message NMT-Objekt Emergency-Objekt SYNC-Objekt Servicedaten (SDO-Transfer) Pzessdaten (PDO-Transfer) - ereignisgesteuert (Eingangsänderung) - anfragegesteuert (Remotely-Requested = RTR, bzw. Remote-Requested only) - zeitgesteuert intern (Timer Driven) - synchngesteuert extern (Sync-Objekt) Life-/Nodeguarding Heartbeat Fehlerverhalten I/O-Modul (Objekt 1029) Fehlerverhalten digitale Ausgänge (Objekt 6206, 6207) Fehlerverhalten analoge Ausgänge (Objekt 6443, 6444) PDO-Auslösung analoger Eingänge über Wertänderungsfenster (Objekt 6426) Modulfehlererkennung. 6/39

7 Funktionsbeschreibung CANopen Vers Kommunikation 2 CANopen Kommunikation 2.1 Das CANopen Kommunikationsmodell Darstellung aus der Sicht des Slaves: Ablaufsteuerung Daten / Parameter vom Slave Objekt- Verzeichnis Master Slave CAN-Bus / CANopen NMT EMCY GUARD SDO Funktionen vom Slave Spezifische Device Hardware z. B. E/A PDO SYNC Dig. E. Dig. A. Antrieb Logische Kommunikationskanäle Abb. 1: CANopen Kommunikationsmodell 7/39

8 Kommunikation Funktionsbeschreibung CANopen Vers Default-Identifier und Prioritäten der Kommunikationskanäle 000H 080H 080H 081 H 0FFH NMT - Service (000H) SYNC - Message (080H) EMERGENCY - Message (080H + Node ID) 180H TRANSMIT PDO 1 (180H + Node ID) 1FFH 200H RECEIVE PDO 1 (200H + Node ID) 27FH Hohe Priorität 280H TRANSMIT PDO 2 (280 + Node ID) 2FFH 300H RECEIVE PDO 2 (300H + Node ID) 37FH 380H TRANSMIT PDO 3 (380H + Node ID) 3FFH 400H RECEIVE PDO 3 (400H + Node ID) 47FH 480H TRANSMIT PDO 4 (480H + Node ID) Niedrige Priorität 4FFH 500H RECEIVE PDO 4 (500H + Node ID) 57FH 580H 5FFH TRANSMIT SDO (580H + Node ID) 600H 67FH RECEIVE SDO (600H + Node ID) 700H 77FH NODE GUARDING (700H) 8/39

9 Funktionsbeschreibung CANopen Vers Objektverzeichnis 3 CANopen-Objektverzeichnis 3.1 Prinzipielle Struktur CANopen-Objektverzeichnis (hex) Objekt 0000 nicht belegt 0001 Statische Datentypen F Komplexe Datentypen F Herstellerspezifische Datentypen F Gerätespezifische Datentypen (statisch) F Gerätespezifische Datentypen (komplex) 00A0-00FF Reserviert für anderweitige Nutzung FF reserviert FFF reserviert FFF Kommunikationspfile FFF Herstellerspezifische Pfile FFF Standardisierte Gerätepfile A000-FFFF Reserviert für anderweitige Nutzung C000-FFFF reserviert 9/39

10 Objektverzeichnis Funktionsbeschreibung CANopen Vers Übersicht CANopen-Objektverzeichnis Definition Datentypen ( FH) reserviert (0060-0FFFH) Kommunikationsspezifischer Pfilbereich (1000-1FFFH) (hex) Objekttyp Objektname Datentyp Zugr. typ Obj. Kl. Mapping (PDO x) 1000 VAR Gerätetyp const M 1001 VAR Fehlerregister Unsigned 8 M 1002 VAR Hersteller Statusregister O 1003 ARRAY Fehlermeldung O 1004 ARRAY Anzahl unterstützter PDOs O 1008 VAR Herstellerspez. Gerätenamen Visible-String const O 1009 VAR Hardware Version Visible-String const O 100A VAR Software Version Visible-String const O 100C VAR Guard Zeit Unsigned 16 rw O 100D VAR Life Time Faktor Unsigned 8 rw O 1010 ARRAY Parameter sichern wo O 1011 ARRAY Default-Parameter zurückladen wo O 1016 ARRAY Consumer Heartbeat Zeit rw O 1017 VAR Pducer Heartbeat Zeit Unsigned 16 rw O 1018 ARRAY Identity Object Identity M 1029 ARRAY Fehlerverhalten Modul Unsigned 8 rw O Receive PDO Kommunikations-Parameter (1400H) 1400 RECORD Receive PDO 1 Komm.-Param. PDOCommPar rw O 1401 RECORD Receive PDO 2 Komm.-Param. PDOCommPar rw O 1402 RECORD Receive PDO 3 Komm.-Param. PDOCommPar rw O 1403 RECORD Receive PDO 4 Komm.-Param. PDOCommPar rw O Receive PDO Mapping-Parameter (1600H) 1600 RECORD Receive PDO 1 Mapping-Param. PDOMapPar O 1601 RECORD Receive PDO 2 Mapping-Param. PDOMapPar O 1602 RECORD Receive PDO 3 Mapping-Param. PDOMapPar O 1603 RECORD Receive PDO 4 Mapping-Param. PDOMapPar O 10/39

11 Funktionsbeschreibung CANopen Vers Objektverzeichnis (hex) Objekttyp Objektname Datentyp Zugr. typ Obj. Kl. Mapping (PDO x) Transmit PDO Kommunikations-Parameter (1800H) 1800 RECORD Transmit PDO 1 Komm.-Param. PDOCommPar rw O 1801 RECORD Transmit PDO 2 Komm.-Param. PDOCommPar rw O 1802 RECORD Transmit PDO 3 Komm.-Param. PDOCommPar rw O 1803 RECORD Transmit PDO 4 Komm.-Param. PDOCommPar rw O Transmit PDO Mapping-Parameter (1A00H) 1A00 RECORD Transmit PDO 1 Mapping-Param. PDOMapPar O 1A01 RECORD Transmit PDO 2 Mapping-Param. PDOMapPar O 1A02 RECORD Transmit PDO 3 Mapping-Param. PDOMapPar O 1A03 RECORD Transmit PDO 4 Mapping-Param. PDOMapPar O Herstellerspezifischer Pfilbereich (2000 5FFFH) 2000 VAR Node ID EEPROM Unsigned 8 rw O 2001 VAR Baudrate EEPROM Unsigned 8 rw O 5FF8 VAR Herstellerspez. Gerätenamen EEPROM Visible String wo O 5FF9 VAR Hardware Version EEPROM Visible String wo O Standardisierter Gerätepfilbereich (6000 9FFFH) Digitale Eingänge ( FFH) 6000 ARRAY 8 digitale Eingänge lesen Unsigned 8 O D-TxP1 Digitale Ausgänge ( FFH) 6200 ARRAY 8 digitale Ausgänge schreiben Unsigned 8 rw O D-RxP ARRAY Fehlerverhalten 8 dig. Ausgänge Unsigned 8 rw O 6207 ARRAY Fehlerzustand 8 dig. Ausgänge Unsigned 8 rw O Analoge Eingänge ( FFH) 6401 ARRAY Analoge Eingänge lesen Signed 16 O D-TxP ARRAY Interrupt analoger Eing., Delta +/- Signed 16 rw O 11/39

12 Objektverzeichnis Funktionsbeschreibung CANopen Vers (hex) Objekttyp Objektname Datentyp Zugr. typ Obj. Kl. Mapping (PDO x) Analoge Ausgänge ( FFH) 6411 ARRAY Analoge Ausgänge schreiben Signed 16 rw O D-RxP ARRAY Fehlerverhalten analoge Signed 8 rw O Ausgänge 6444 ARRAY Analogwert Ausgänge Signed 16 rw O reserviert für weitere Funktionen (6800H -...) reserviert (A000 FFFFH) Legende: Zugr.typ r read (Zugriffstyp) w write o only Mapping (PDO x) D Default Rx Receive, vom Slave aus gesehen Tx Transmit Obj.Kl. M Mandatory (Objektklasse) O Option 12/39

13 Funktionsbeschreibung CANopen Vers Netzwerkmanagement 4 Das Netzwerkmanagement NMT 4.1 Konfiguration und Start Master Request Slave CANopen erlaubt einen sehr einfachen Boot-Up des CAN-Netzwerkes. Die Module befinden sich nach der Initialisierung automatisch im Zustand Pre-Operational. In diesem Zustand kann bereits über Service-Daten-Objekte mit Default-Identifiern auf das Objektverzeichnis zugegriffen werden. Die Module können also konfiguriert werden. Da für die meisten Einträge im Objektverzeichnis Default-Einstellungen vorhanden sind, kann auch in den meisten Fällen auf eine Konfiguration verzichtet werden. Die verwendeten Netzwerkmanagement-Nachrichten haben folgenden Aufbau: CAN-ID 0 mit 2 Bytes Daten. Das erste Datenbyte enthält den Command-Specifier [cs], das zweite Datenbyte die Knotenadresse, wobei die Knotenadresse 0 alle Knoten anspricht (Badcast). Zum Starten der Module ist nur eine einzige Nachricht erforderlich: Start Remote Node. Im Zustand Operational beginnt die eigentliche Datenübertragung. 13/39

14 Netzwerkmanagement Funktionsbeschreibung CANopen Vers Minimal Boot-Up (4) Initialization Stopped (6) (2) (3) (5) (6) (4) (4) (1) (2) Pre-Operational Operational (3) (5) (5) Abb. 2: Blockbild Minimal-Boot-Up Legende: Nr. Status Beschreibung (1) Initialization finished Automatischer Übergang in Zustand Pre-Operational (2) Start Remote Node [cs=01h] (3) Enter Pre-Operational Mode [cs=80h] (4) Reset Node [cs=81h] (5) Reset Communication [cs=82h] (6) Stop Remote Node [cs=02h] Startet das Modul, gibt die Ausgänge frei, startet die Übertragung von PDOs Stoppt die PDO-Übertragung, SDO ist weiter aktiv Führt einen Modul-Reset durch (einschließlich der Applikation) Führt einen Reset der Kommunikationsfunktionen durch Stoppt die Kommunikation, mit Ausnahme der Funktionen Nodeguarding und Heartbeat 14/39

15 Funktionsbeschreibung CANopen Vers Netzwerkmanagement 4.3 Funktionalität der Knotenmodule in den Betriebszuständen Power On, Reset Nach Power On oder Reset führt die Baugruppe die benötigten Initialisierungen durch und schaltet in den Zustand Pre-Operational. Beim Eintritt in diesen Zustand wird einmalig eine Boot-Up- Message gesendet. Boot-Up-Message auf Guarding-Kanal (ID: 700H + Node ID): Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 00H Stopped Im Zustand Stopped verhält sich das Modul passiv und unterbricht die Datenkommunikation mit Ausnahme von Guarding und Heartbeat, sofern eines davon aktiviert ist. Ein Zustandsübergang nach Pre-Operational bzw. Operational ist durch ein entsprechendes NMT-Kommando an das Modul möglich Pre-Operational Im Zustand Pre-Operational sind die PDOs noch nicht aktiv. Nodeguarding ist bereits möglich, die Default-Identifier für das SDO stehen zur Verfügung. Bei einem Fehler auf dem Modul wird das Emergency-Telegramm abgesetzt. Alle gewünschten Baugruppenkonfigurationen sollten, sofern nicht mit Defaulteinstellungen gearbeitet werden kann, zu diesem Zeitpunkt ausgeführt werden. Grundsätzlich kann die Konfiguration aber auch während des Betriebes verändert werden. Sind alle Konfigurationen durchgeführt, kann mittels Start_Remote_Node in den aktiven Betriebszustand (Operational) gewechselt werden. Im Zustand Pre-Operational können Ausgänge nur über SDO-Zugriff auf die entsprechenden Objekte aktiviert werden. Ebenso ist es möglich, über SDO die Eingänge via Verzeichnis zu lesen Operational Im Zustand Operational können Ein-/Ausgangsdaten direkt über PDOs ausgetauscht werden. Ein Umkonfigurieren über SDO ist grundsätzlich möglich. Sind die Ausgänge einer Baugruppe im Fehlerzustand, so bewirkt ein Zustandswechsel nach Operational das Freigeben der Ausgänge => die Ausgänge können wieder neu beschrieben werden. Deswegen ist ein Zustandswechsel von Operational nach Operational zulässig und gegebenenfalls auch sinnvoll. 15/39

16 Servicedatenobjekt Funktionsbeschreibung CANopen Vers Das Servicedatenobjekt SDO Client Request Response Server Mit dem Servicedatenobjekt (SDO) wird der Zugriff auf das Objektverzeichnis unterstützt. Für Parameterdaten beliebiger Größe steht mit dem SDO ein leistungsfähiger Datenkanal zur Verfügung. Typische Geräteparameter können mit einem einzigen Telegramm-Handshake ins Objektverzeichnis der Geräte geschrieben bzw. aus diesem ausgelesen werden. Weiteres zum Zugriff auf das Objektverzeichnis, bzw. Up-/Download von Parameterdaten ist den bereits erwähnten Draft-Standards DS 2XX und DS 301 zu entnehmen. 5.1 Upload von Daten Ein Client (z.b. ein vorhandener Bus-Master) fordert ein Objekt mit einem Initiate Upload Request aus einem CAN-Bus-Modul an. Upload Request --- Anfrage Client Upload Response --- Objekt CANopen E/A-Knoten 5.2 Download von Daten Ein Client sendet Daten mit einem Initiate Download Request an ein CAN-Bus-Modul: Download Request --- Daten Client Download Response --- Quittung CANopen E/A-Knoten 16/39

17 Funktionsbeschreibung CANopen Vers Servicedatenobjekt 5.3 Aufbau eines SDO-Telegramms Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 SDO- Cmd Sub- SDO-Daten 5.4 Servicedatenobjekte mit Geräteinformation SDO Sub- Bedeutung Datentyp Wert Zugriff 1000H 00 Gerätetyp 0xF H 00 Anzahl unterstützter PDOs insgesamt 0x Anzahl synchner PDOs 0x0 02 Anzahl asynchner PDOs 0x H 00 Herstellerspezifische Gerätenamen Visible-String DR-CO- CMxxx 1009H 00 Hardware Version Visible-String B * 100AH 00 Software Version Visible-String 2.0 * 1018H 00 Anzahl Einträge Unsigned Vendor ID 0x H 00 Node ID EEPROM Unsigned rw 2001H 00 Baudrate EEPROM Unsigned rw 2010H - L-Bus Statusbyte Unsigned H 00 Anzahl E/A-Module (L-Bus Slave) Unsigend H ID E/A-Module (L-Bus Slaves 01 16) Unsigend 8 * Stand Drucklegung 17/39

18 Servicedatenobjekt Funktionsbeschreibung CANopen Vers Die Werte für Node ID ( ) und Baudrate ( ) werden nur bei entsprechender Schalterstellung der Drehschalter verwendet. Eine Änderung dieses Wertes wird ohne Aufruf der Funktion Parameter sichern SDO 1010 beim nächsten Start-Up verwendet. Wert SDO Node ID dec. 00 nicht erlaubt F F nicht erlaubt... nicht erlaubt FF nicht erlaubt Wert SDO CAN-Baudrate 0 1 Mbit/s kbit/s kbit/s kbit/s kbit/s 5 50 kbit/s 6 20 kbit/s 7 10 kbit/s Die Werte für und werden sofort im EEPROM gespeichert und nicht durch SDO 1010 oder SDO 1011 beeinflusst. 18/39

19 Funktionsbeschreibung CANopen Vers Pzessdatenobjekt 6 Das Pzessdatenobjekt PDO Mit Pzessdatenobjekten (PDOs) werden Echtzeitdaten übertragen. Client Request (optional) (PDO) Response Server SYNC 6.1 PDO Kommunikationsparameter Mit Hilfe der Kommunikationsparameter (Objekt 1400H.., 1800H.. ) wird definiert, wann die Daten übertragen werden: SDO Sub- Bedeutung Datentyp Wert Zugriff 1400H 00 größter unterstützter Sub- 01 COB-ID des RxPDO digitale Ausgänge 1 bis 64 Unsigned 8 5 0x200 + Node ID 02 Übertragungsart Unsigned rw 03 Ruhezeit Unsigned rw 04 Kombatibilitätseintrag Unsigned Ereignis Timer Unsigned rw 1401H 01 COB-ID des RxPDO analoge Ausgänge 1 bis H 01 COB-ID des RxPDO analoge Ausgänge 5 bis H 01 COB-ID des RxPDO analoge Ausgänge 9 bis H 01 COB-ID des TxPDO digitale Eingänge 1 bis H 01 COB-ID des RxPDO analoge Eingänge 1 bis H 01 COB-ID des RxPDO analoge Eingänge 5 bis H 01 COB-ID des RxPDO analoge Eingänge 9 bis 12 0x300 + Node ID 0x400 + Node ID 0x500 + Node ID 0x180 + Node ID 0x280 + Node ID 0x380 + Node ID 0x480 + Node ID Die Sub-Indizes 0 und 2 bis 5 sind identisch im Aufbau. 19/39

20 Pzessdatenobjekt Funktionsbeschreibung CANopen Vers COB-ID Der Inhalt gibt die Adresse (COB-ID) des PDOs an, der zur Datenübertragung auf dem Bus verwendet wird. Die Adresse ist fest und kann nicht verändert werden Übertragungsart Wert zyklisch azyklisch synchn asynchn RTR Polling 0 x x x x x x reserved x 253 only 254 x x 255* x x *Defaultwert Bei der Übertragungsart 0 werden die PDOs azyklisch (ereignisgesteuert, d.h. mit dem nächsten SYNC) übertragen. Das Sync-Objekt wird vom Master gesendet. Zum Zeitpunkt des Sync- Objektes werden alle Eingänge gelesen und anschließend gesendet (nur bei Änderung). Die Ausgänge werden zum Zeitpunkt des Sync-Objektes auf einen zuvor gesendeten Wert aktualisiert. Bei den Übertragungsarten werden die PDOs synchn zu jedem n-ten SYNC übertragen bzw. ausgewertet. Die Ausgangsbaugruppen schreiben die Ausgangswerte erst beim Empfang des n-ten SYNC zu den Ausgängen, auch wenn die Werte einige SYNCs früher übertragen wurden. Die Eingangsbaugruppen lesen ihre Eingänge beim Empfang des n-ten SYNCs aus und senden das entsprechende PDO direkt im Anschluss (SYNC Mode). Die Übertragungsart 253 bedeutet, dass ttz des Eintretens eines Ereignisses kein PDO übertragen wird. Die entsprechenden PDOs können aber über RTR-Telegramme ausgelesen werden (RTR only). Bei der Übertragungsart 254 wird die Übertragung eines PDOs durch ein herstellerspezifisches Ereignis auf der Baugruppe ausgelöst (Event Mode). Das entspricht der Übertragungsart 255. Die Übertragung eines PDOs der Übertragungsart 255 wird durch ein im Gerätepfil beschriebenes Ereignis ausgelöst (Event Mode). In dieser Einstellung kann zusätzlich auch eine Zeitbasis als Ereignis verwendet werden (Timer Driven). Der Timer für die Zeitbasis wird hierbei über den Sub- 5 des zugehörigen Kommunikationsobjektes (SDO und SDO ) eingestellt. Ein eingetretenes Ereignis triggert dabei den Timer erneut nach. 20/39

21 Funktionsbeschreibung CANopen Vers Pzessdatenobjekt Ruhezeit (Inhibit Time) Der Inhalt gibt die Zeit in 0,1 ms an, bis ein neues PDO vom Modul gesendet werden darf. Dies verhindert, dass ein Modul mit hoher Priorität den Bus bei laufender Eingangsänderung durch ständiges Senden eines neuen PDO blockiert. Die Auflösung in der internen Software beträgt 1 ms. Beispiel: Der Wert 122 bedeutet 12 ms Ereignis Timer (Event Timer) Der Inhalt gibt die Zeit in ms an, nach der spätestens ein neues PDO vom Modul gesendet wird. Dadurch werden Eingangssignale zyklisch wiederholt. Tritt während des Ablaufes dieser Zeit ein Eingangswechsel auf und ist eine eventuelle Ruhezeit abgelaufen, wird sofort ein PDO gesendet und der Timer wird zurückgesetzt. 21/39

22 Pzessdatenobjekt Funktionsbeschreibung CANopen Vers Mapping-Parameter und Mapping-Objekte Mapping-Parameter Die Mapping-Parameter geben den, den Sub- und die Länge (in Bits) des gemappten Objektes an. SDO Sub- Bedeutung Datentyp Wert Zugriff 1600H RxPDO Anzahl der gemappten Objekte 01 PDO-Mapping 1. Byte digitale Ausgänge 08 PDO-Mapping 8. Byte digitale Ausgänge 1601H RxPDO Anzahl der gemappten Objekte 01 PDO-Mapping 1. analoger Ausgang 04 PDO-Mapping 4. analoger Ausgang 1602H RxPDO Anzahl der gemappten Objekte 01 PDO-Mapping 5. analoger Ausgang 04 PDO-Mapping 8. analoger Ausgang 1603H RxPDO Anzahl der gemappten Objekte 01 PDO-Mapping 9. analoger Ausgang 04 PDO-Mapping 12. analoger Ausgang Unsigned x00 oder 0x x00 oder 0x Unsigned x00 oder 0x x00 oder 0x Unsigned x00 oder 0x x00 oder 0x Unsigned x00 oder 0x x00 oder 0x /39

23 Funktionsbeschreibung CANopen Vers Pzessdatenobjekt SDO Sub- Bedeutung Datentyp Wert Zugriff 1A00H TxPDO Anzahl der gemappten Objekte 01 PDO-Mapping 1. Byte digitale Eingänge 08 PDO-Mapping 8. Byte digitale Eingänge 1A01H TxPDO Anzahl der gemappten Objekte 01 PDO-Mapping 1. analoger Eingang 04 PDO-Mapping 4. analoger Eingang 1A02H TxPDO Anzahl der gemappten Objekte 01 PDO-Mapping 5. analoger Eingang 04 PDO-Mapping 8. analoger Eingang 1A03H TxPDO Anzahl der gemappten Objekte 01 PDO-Mapping 9. analoger Eingang 04 PDO-Mapping 12. analoger Eingang Unsigned x00 oder 0x x00 oder 0x Unsigned x00 oder 0x x00 oder 0x Unsigned x00 oder 0x x00 oder 0x Unsigned x00 oder 0x x00 oder 0x Sub- 1 bis 8 Wert: 0xaaaa bb cc mit: aaaa =, bb = Sub-, cc = Anzahl Bits Die Reihenfolge der Daten innerhalb der PDOs ist definiert durch die Anordnung/Verdrahtung der E/A-Module. Links (und oben) sitzen die niederwertigen Bytes. Die Daten der Eingänge werden über die Transmit PDOs (TxPDO1 bis TxPDO4) übertragen. Die digitalen Eingänge werden dabei auf TxPDO1, die analogen Eingänge auf TxPDO2 bis TxPDO4 abgebildet. Die Daten der Receive PDOs (RxPDO1 bis RxPDO4) werden auf Ausgängen abgebildet. Hierbei sind die digitalen Ausgängen der RxPDO1 zugeordnet und die analogen Ausgängen den RxPDO2 bis RxPDO4. 23/39

24 Pzessdatenobjekt Funktionsbeschreibung CANopen Vers Mapping-Objekte Die Eingangs- und Ausgangsdaten werden aus diesen SDOs in die PDOs gemappt und können auch über SDO-Transfer gelesen und geschrieben werden. SDO Sub- Bedeutung Datentyp PDO Mapping Zugriff 6000H 00 Anzahl Bytes digitale Eingänge Unsigned digitale Eingänge 1 bis 8 Unsigned 8 TxPDO digitale Eingänge 57 bis H 00 Anzahl Bytes digitale Ausgänge Unsigned digitale Ausgänge 1 bis 8 Unsigned 8 RxPDO1 rw 08 8 digitale Ausgänge 57 bis H 00 Anzahl analoge Eingänge Unsigned analoger Eingang Unsigned 16 TxPDO analoger Eingang analoger Eingang Unsigned 16 TxPDO analoger Eingang analoger Eingang Unsigned 16 TxPDO analoger Eingang 6411H 00 Anzahl analoge Ausgänge Unsigned 8 rw analoger Ausgang Unsigned 16 RxPDO2 rw analoger Ausgang analoger Ausgang Unsigned 16 RxPDO3 rw analoger Ausgang analoger Ausgang Unsigned 16 RxPDO4 rw analoger Ausgang 24/39

25 Funktionsbeschreibung CANopen Vers Pzessdatenobjekt PDO-Belegung Durch das feste Mapping der DIORAIL/DIOLINE20-Module ergibt sich folgende PDO-Belegung: 1. TxPDO (Sende-PDO für digitale Eingänge 1-64) COB-ID Byte 0 Byte 1 Byte 2 Byte Node ID Eingang 1-8 Eingang 9-16 Eingang Eingang Digitale Byte 4 Byte 5 Byte 6 Byte 7 Eingänge Eingang Eingang Eingang Eingang LSB = 1. Eingang, MSB = 8. Eingang, TxPDO (Sende-PDO für analoge Eingänge 1-4) COB-ID Byte 0 Byte 1 Byte 2 Byte Node ID Lowbyte Kanal 1 Highbyte Kanal 1 Lowbyte Kanal 2 Highbyte Kanal 2 Analoge Byte 4 Byte 5 Byte 6 Byte 7 Eingänge Lowbyte Kanal 3 Highbyte Kanal 3 Lowbyte Kanal 4 Highbyte Kanal 4 3. TxPDO (Sende-PDO für analoge Eingänge 5-8) COB-ID Byte 0 Byte 1 Byte 2 Byte Node ID Lowbyte Kanal 5 Highbyte Kanal 5 Lowbyte Kanal 6 Highbyte Kanal 6 Analoge Byte 4 Byte 5 Byte 6 Byte 7 Eingänge Lowbyte Kanal 7 Highbyte Kanal 7 Lowbyte Kanal 8 Highbyte Kanal 8 4. TxPDO (Sende-PDO für analoge Eingänge 9-12) COB-ID Byte 0 Byte 1 Byte 2 Byte Node ID Lowbyte Kanal 9 Highbyte Kanal 9 Lowbyte Kanal 10 Highbyte Kanal 10 Analoge Byte 4 Byte 5 Byte 6 Byte 7 Eingänge Lowbyte Kanal 11 Highbyte Kanal 11 Lowbyte Kanal 12 Highbyte Kanal 12 25/39

26 Pzessdatenobjekt Funktionsbeschreibung CANopen Vers RxPDO (Empfangs-PDO für digitale Ausgänge 1-64) COB-ID Byte 0 Byte 1 Byte 2 Byte Node ID Ausgang 1-8 Ausgang 9-16 Ausgang Ausgang Digitale Byte 4 Byte 5 Byte 6 Byte 7 Ausgänge Ausgang Ausgang Ausgang Ausgang LSB = 1. Ausgang, MSB = 8. Ausgang, RxPDO (Empfangs-PDO für analoge Ausgänge 1-4) COB-ID Byte 0 Byte 1 Byte 2 Byte Node ID Lowbyte Kanal 1 Highbyte Kanal 1 Lowbyte Kanal 2 Highbyte Kanal 2 Analoge Byte 4 Byte 5 Byte 6 Byte 7 Ausgänge Lowbyte Kanal 3 Highbyte Kanal 3 Lowbyte Kanal 4 Highbyte Kanal 4 3. RxPDO (Empfangs-PDO für analoge Ausgänge 5-8) COB-ID Byte 0 Byte 1 Byte 2 Byte Node ID Lowbyte Kanal 5 Highbyte Kanal 5 Lowbyte Kanal 6 Highbyte Kanal 6 Analoge Byte 4 Byte 5 Byte 6 Byte 7 Ausgänge Lowbyte Kanal 7 Highbyte Kanal 7 Lowbyte Kanal 8 Highbyte Kanal 8 4. RxPDO (Empfangs-PDO für analoge Ausgänge 9-12) COB-ID Byte 0 Byte 1 Byte 2 Byte Node ID Lowbyte Kanal 9 Highbyte Kanal 9 Lowbyte Kanal 10 Highbyte Kanal 10 Analoge Byte 4 Byte 5 Byte 6 Byte 7 Ausgänge Lowbyte Kanal 11 Highbyte Kanal 11 Lowbyte Kanal 12 Highbyte Kanal 12 26/39

27 Funktionsbeschreibung CANopen Vers Emergency-Objekt 7 Das Emergency-Objekt und Fehlerverhalten 7.1 Das Emergency-Telegramm Client Request Server Das Emergency-Objekt wird durch das Auftreten einer fatalen Fehlersituation in einer Baugruppe ausgelöst und mit sehr hoher Priorität über den CAN-Bus gesendet. Ist der Fehlergrund beseitigt, so wird erneut ein Fehlertelegramm abgesetzt, bei dem das entsprechende Bit zurückgesetzt ist. Eine Änderung des Actual Bus State führt nicht zur Auslösung des Telegramms. Das Fehlertelegramm wird p Err Event, bzw. wenn der Fehler gelöscht ist, nur einmal gesendet. Das Emergency-Telegramm hat eine Länge von 8 Bytes und enthält umfangreiche Fehlerinformationen. Die Struktur der Emergency-Nachricht sieht wie folgt aus: Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Fehlermeldung (Objekt 1003H) Fehler Register (Objekt 1001H) Hersteller Statusregister (Objekt 1002H) leer Das Emergency-Telegramm setzt sich somit aus folgenden Service-Daten-Objekten zusammen: SDO Sub- Bedeutung Datentyp Wert Zugriff 1001H 00 Fehlerregister Unsigned 8 siehe unten 1002H 00 Hersteller Statusregister siehe unten 1003H 00 Anzahl Fehlermeldung Unsigned 8 0x01 01 Fehlermeldung siehe unten 27/39

28 Emergency-Objekt Funktionsbeschreibung CANopen Vers Fehlerregister (Objekt 1001H) Das Objekt 1001H ist ein allgemeines Fehlerregister. Die Baugruppe kann interne Fehler in dieses Byte mappen. Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Man.Spec. res. Dev.Spec. Comm. Temp. Voltage Current Generic Wert = 0: Wert = 1: Man.Spec. Dev.Spec. Temp. Voltage Current Comm. Generic kein Fehler entsprechender Fehler Herstellerspezifischer Fehler, wird in Objekt 1002H genauer spezifiziert. Fehlerflag, gerätespezifisch (nicht benutzt) Temperaturüberwachung im Modul (nicht benutzt) z.b. Eingangsspannung außerhalb des gültigen Bereiches (nicht benutzt) z.b. Überlast an den Ausgängen Kommunikationsfehler Nicht näher spezifiziert, ist bei jeder Fehlermeldung gesetzt 28/39

29 Funktionsbeschreibung CANopen Vers Emergency-Objekt 7.3 Hersteller-Statusregister (Objekt 1002H) Das Objekt 1002H gibt den aktuellen herstellerspezifischen Status des Moduls an. LSByte Status Byte 1 Status Byte 2 Status Byte 3 Status Byte 4 MSByte MSBit LSBit Byte 1 ShortC ComE OrE SubCom Byte 2 InFM OutFM MemE Byte 3 Actual Bus State Byte 4 Wert = 0: Wert = 1: kein Fehler entsprechender Fehler Tabelle Err-Codes ShortC ComE OrE SubCom InFM OutFM MemE Actual Bus State Kurzschluss an den digitalen Ausgängen Kommunikationsfehler (CAN Warning Limit überschritten) CAN Overrun Err (CAN-Datenverlust) Kommunikationsfehler L-Bus-Modul(e) Eingänge im Fehlermodus Ausgänge im Fehlermodus Fehler im nichtflüchtigen Speicher (EEPROM) 0x7F für Pre-Operational 0x05 für Operational Derzeitiger CAL-Status des Knotens (entspricht Status in CAL Nodeguarding Telegramm) 29/39

30 Emergency-Objekt Funktionsbeschreibung CANopen Vers Fehlermeldung (Objekt H) Das Objekt H enthält den Emergency Err Code nach DS301. Wert Bedeutung Zusatzinformation 00,00H Kein Fehler, Fehler behoben 21,xxH 1) Stm (eingangsseitig) z.b. Kurzschluss Sensorversorgung 23,xxH 1) Stm (ausgangsseitig) z.b. Kurzschluss Aktorausgang 63,xxH Datenspeicherung Fehler EEPROM 70,xxH 1) Erweiterungsmodule Fehler interner Erweiterungsbus 81,xxH Kommunikation Fehler in der CAN-Kommunikation 50,01H Hardware-Fehler Analog-In-Modul Err-Code in Anlehnung an DS301 50,02H Hardware-Fehler Analog-Out-Modul Err-Code in Anlehnung an DS301 1) finden nur bei entsprechend ausgeführter Hardware Verwendung 30/39

31 Funktionsbeschreibung CANopen Vers Emergency-Objekt 7.5 Fehlerverhalten des Moduls Mit dem Objekt 1029H (Fehlerverhalten) wird definiert, wie sich das Modul bei folgenden Fehlersituationen verhalten soll: Kommunikationsfehler (CAN-Kommunikation bzw. Guarding/Heartbeat-Verletzung) Fehler am Ausgang (Kurzschluss) Fehler am Eingang. SDO Sub- Bedeutung Datentyp Wert Zugriff 1029H 00 Größter unterstützter Sub- Unsigned Fehlerverhalten bei Kommunikationsfehler Unsigned rw 02 Fehlerverhalten bei Ausgangsfehler Unsigned rw 03 Fehlerverhalten bei Eingangsfehler Unsigned rw Zwischen den folgenden Fehlerreaktionen kann hierbei gewählt werden: Wert: 0 Zurückfallen in den Zustand Pre-Operational (Default) 1 Kein Zustandswechsel 2 Übergang in den Stopped-Zustand 31/39

32 Emergency-Objekt Funktionsbeschreibung CANopen Vers Fehlerverhalten der digitalen Ausgänge Mit den Objekten 6206H Fehlermodus: Wert Bit 0 bis 7: 0 Zustand beibehalten 1 Wert von 6207H annehmen (Default) und 6207H Fehlerwert: Wert Bit 0 bis 7: 0 Ausgang ausschalten (Default) 1 Ausgang einschalten kann eingestellt werden, welchen Zustand ein digitaler Ausgang im Fehlerfall einnehmen soll. Durch einen Zustandswechsel nach Operational oder auch nur durch Absetzen des NMT- Kommandos Start Remote Node wird der Fehlerzustand wieder verlassen und die Ausgänge nehmen den zuletzt eingestellten Zustand wieder ein. SDO Sub- Bedeutung Datentyp Wert Zugriff 6206H 00 Größter unterstützter Sub- Unsigned Fehlermodus Ausgänge 1 bis 8 Unsigned 8 0-0xFF rw 08 Fehlermodus Ausgänge 57 bis H 00 Größter unterstützter Sub- Unsigned Fehlerwert Ausgänge 1 bis 8 Unsigned 8 0-0xFF rw 08 Fehlerwert Ausgänge 57 bis 64 32/39

33 Funktionsbeschreibung CANopen Vers Emergency-Objekt Fehlerverhalten der analogen Ausgänge Mit den Objekten 6443H Fehlermodus: Wert: 0 Zustand beibehalten 1 Wert von 6444H annehmen (Default) und 6444H Fehlerwert: Wert: 0 bis 0 = Defaultwert 0xaaaa aaaa = Ausgangswert kann eingestellt werden, welchen Zustand ein analoger Ausgang im Fehlerfall einnehmen soll. Durch einen Zustandswechsel nach Operational oder auch nur durch Absetzen des NMT- Kommandos Start Remote Node wird der Fehlerzustand wieder verlassen und die Ausgänge nehmen den zuletzt eingestellten Zustand wieder ein. SDO Sub- Bedeutung Datentyp Wert Zugriff 6443H 00 Größter unterstützter Sub- Unsigned Fehlermodus analoger Ausgang 1 Unsigned rw 12 Fehlermodus analoger Ausgang H 00 Größter unterstützter Sub- Unsigned Fehlerwert analoger Ausgang 1 Unsigned xFFFF rw 12 Fehlerwert analoger Ausgang 12 33/39

34 Parameterspeicherung Funktionsbeschreibung CANopen Vers Parameterspeicherung Nach dem ersten Einschalten nehmen die CANopen-Baugruppen eine Default-Konfiguration an. Hierbei werden alle relevanten Kommunikations- und Geräteparameter auf einen Standardwert (Default-Wert) zurückgesetzt (Spezifikation, siehe CANopen Standard CiA DS 301). Alle notwendigen Parameter eines Knotens sind in einem seriellen EEPROM abgespeichert. Nach dem nächsten Einschalten bzw. Reset steht die entsprechende Konfiguration damit wieder zur Verfügung. Die Parameter Node ID SDO 2000 und CAN-Baudrate SDO 2001 werden bei Änderung durch SDO immer sofort gespeichert. Alle anderen Parameter müssen explizit über das Objekt 1010H gespeichert werden. Über das Objekt 1011H kann die Baugruppe auf die Default-Parameter zurückgesetzt werden. Nach dem anschließenden Reset sind dann die Default-Parameter aktiv. SDO Sub- Bedeutung Datentyp Wert Zugriff 1010H 00 Größter unterstützter Sub- Unsigned Speicherung aller Parameter ASCII save rw 02 Speicherung der Kommunikations- Parameter 03 Speicherung der Applikations- Parameter 04 Speicherung der herstellerspezifischen Parameter ASCII save rw ASCII save rw ASCII save rw 1011H 00 Größter unterstützter Sub- Unsigned Laden aller Default-Parameter ASCII load rw 02 Laden der Default-Kommunikations- Parameter 03 Laden der Default-Applikations- Parameter 04 Laden der Default- Herstellerspezifischen-Parameter ASCII load rw ASCII load rw ASCII load rw Kommunikations-Parameter Herstellerspezifische-Parameter Applikations-Parameter SDO 1000 bis 1FFF SDO 2000 bis 5FFF SDO 6000 bis 6FFF 34/39

35 Funktionsbeschreibung CANopen Vers Ausfallüberwachung 9 Ausfallüberwachung Für die Ausfallüberwachung eines CANopen Knotens stehen die Funktionen Nodeguarding bzw. das Pducer-Heartbeat zur Verfügung. Zur Überwachung anderer CAN-Teilnehmer wird das Lifeguarding bzw. das Consumer-Heartbeat benutzt. i Achtung: Es kann hierbei aber immer nur entweder Guarding oder Heartbeat aktiv sein. SDO Sub- Bedeutung Datentyp Wert Zugriff 100CH 00 Guard Zeit Unsigned 16 0xbb bb rw 100DH 00 Life Time Faktor Unsigned rw 1016H 00 Anzahl Einträge 0x01 rw 01 Consumer Heartbeat Zeit 0x00 aa bb bb rw 1017H 00 Pducer Heartbeat Zeit Unsigned 16 0xbb bb rw aa = Node ID des überwachten Teilnehmers bb bb = Zeit in ms 35/39

36 Ausfallüberwachung Funktionsbeschreibung CANopen Vers Node-/Lifeguarding Master Request Response Slave Beim Nodeguarding setzt der Master Remote-Frames an die zu überwachenden Slaves ab. Diese antworten mit der Guarding-Nachricht. Sie enthält den CAL-Status des Slaves sowie ein Toggle-Bit, das nach jeder Nachricht wechseln muss. Falls Status oder Toggle-Bit nicht mit denen vom NMT- Master erwarteten Werten übereinstimmen oder falls nach definierter Zeit keine Antwort erfolgt, geht der Master von einem Slavefehler aus. Beim Lifeguarding, welches mit dem ersten empfangenen Remote-Frame beginnt, erwartet der Slave innerhalb der Life Time (= Guard Zeit x Life Time Faktor) einen erneuten Remote-Frame. Ansonsten geht der Slave von einem Masterfehler aus und es wird eine Fehlerreaktion ausgelöst. Master Remote Transmit Request Slave Request 0 1 Indication Guard Time Confirm Request 7 t 6 0 Status Remote Transmit Request 0 1 Response Indication Life Time Confirm 7 t 6 0 Status Response Abb. 3: Node-/Lifeguarding Um die Betriebsbereitschaft bzw. das Vorhandensein einer Baugruppe nach dem Boot-Up erkennen zu können, setzen die Baugruppen nach der Initialisierung ein Guarding-Telegramm ab. Der Absender des Telegramms kann über den Identifier der Nachricht bestimmt werden. 36/39

37 Funktionsbeschreibung CANopen Vers Ausfallüberwachung 9.2 Heartbeat-Ausfallüberwachung Im Gegensatz zum Guarding-Ptokoll verwendet das Heartbeat-Ptokoll keine Remote-Frames. Der Heartbeat-Pducer sendet zyklisch im Abstand der Heartbeat-Pducer-Zeit eine Heartbeat- Message, welche von den Heartbeat-Consumern empfangen wird. Empfängt ein Heartbeat-Consumer innerhalb der Heartbeat-Consumer-Zeit keine weitere Heartbeat- Message, so spricht die Ausfallüberwachung (Heartbeat-Event) an. Das Heartbeat-Ptokoll startet beim Übergang vom Zustand Initialisierung in den Zustand Pre-Operational mit der ersten Heartbeat-Message. Wurde für eine oder alle Heartbeat-Zeiten eine 0 pgrammiert, so wird entsprechend die Heartbeat- Message-Generierung bzw. die Heartbeat-Message-Überwachung nicht aktiviert. Master Remote Transmit Request Slave Request 0 1 Indication Guard Time Confirm Request 7 t 6 0 Status Remote Transmit Request 0 1 Response Indication Life Time Confirm 7 t 6 0 Status Response Abb. 4: Heartbeat-Ausfallüberwachung Bei neuen Applikationen ist die Heartbeat-Ausfallüberwachung vorzuziehen. 37/39

38 Verhalten der Ein-/Ausgänge Funktionsbeschreibung CANopen Vers Verhalten der Ein- und Ausgänge Verhalten der digitalen Eingänge Eine Änderung an einem digitalen Eingang dient als Ereignis, um im Zustand Operational bei entsprechend eingestellter Übertragungsart eine Pzessdaten-Nachricht (PDO) auszulösen. Verhalten der digitalen Ausgänge Neue Pzessdaten (PDO) für einen digitalen Ausgang bewirken eine Änderung am zugehörigen Ausgang im Zustand Operational bei entsprechend eingestellter Übertragungsart. Im Zustand Pre-Operational kann ein Ausgang ebenfalls mit einer Servicedaten-Nachricht (SDO) definiert werden. Verhalten der analogen Eingänge Mit dem Objekt 6426H (Interrupt Analog-Eingang, Delta positiv/negativ) wird der Betrag der Änderung an einem analogen Eingang definiert, der bei Überschreitung ein neues Ereignis auslöst. Im Zustand Operational wird dann, bei entsprechend eingestellter Übertragungsart, eine neue Pzessdaten- Nachricht (PDO) ausgelöst. SDO Sub- Bedeutung Datentyp Default- Wert Zugriff 6426H 00 Größter unterstützter Sub- Unsigned Deltawert analoger Eingang 1 Unsigned xFFFF rw 12 Deltawert analoger Eingang 12 Verhalten der analogen Ausgänge Neue Pzessdaten (PDO) für einen analogen Ausgang bewirken eine Änderung am zugehörigen Ausgang im Zustand Operational bei entsprechend eingestellter Übertragungsart. Im Zustand Pre-Operational kann ein Ausgang ebenfalls mit einer Servicedaten-Nachricht (SDO) definiert werden. 38/39

39 Funktionsbeschreibung CANopen Vers Änderungshistorie 11 Änderungshistorie Version Änderung 2.0 Juni 2003 Vorlage 2.10 Jan (Überschrift) Inhabit Inhibit (FB CANopen) des PDOs an, der zur Datenübertragung...(FB CANopen) 9 Eintrag in Tabelle muss lauten 1017H 00 Pducer Hinweis auf DS 301 V4.00 entfernt Datentyp Unsigned 8 anstatt Kombatibilitätseintrag hinzugekommen 11 Änderungshistorie hinzugekommen 7.3 Err-Codes für analoge Ein- und Ausgänge entfernen. Digitale Ein- und Ausgangsfehler als allgemeine Ein- Ausgangsfehler bezeichnen April 2008 Pduktfamilie DIORAIL DIORAIL/DIOLINE April 2014 Erweiterung Objektverzeichniseinträge Kapitel 5.4 Servicedatenobjekte mit Geräteinformationen Anpassung Bildwortmarke und Kontaktdaten 39/39