CANopen - Lütze Transportation

Transcription

CANopen
Funktionsbeschreibung
für den Einsatz in DIORAIL/DIOLINE20-Modulen
Version 2.30
April 2014
1/39
Die Lütze Transportation GmbH behält sich das Recht vor, Änderungen an ihren Produkten
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 Produktnamen 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 17-19
D-71384 Weinstadt - Großheppach
Germany
Telefon - Zentrale:
Telefax:
e-mail:
Website:
2/39
++49/ (0)7151/ 6053-545
++49/ (0)7151/ 6053-6454
[email protected]
http://www.luetze-transportation.de
Funktionsbeschreibung CANopen Vers. 2.30
Inhalt
Inhaltsverzeichnis
1
Funktionsumfang ............................................................................ 6
2
CANopen Kommunikation .............................................................. 7
2.1 Das CANopen Kommunikationsmodell ............................................................... 7
2.2 Default-Identifier und Prioritäten der Kommunikationskanäle.............................. 8
3
CANopen-Objektverzeichnis .......................................................... 9
3.1 Prinzipielle Struktur CANopen-Objektverzeichnis ............................................... 9
3.2 Übersicht CANopen-Objektverzeichnis ............................................................. 10
4
Das Netzwerkmanagement NMT .................................................. 13
4.1 Konfiguration und Start ..................................................................................... 13
4.2 Minimal Boot-Up................................................................................................ 14
4.3 Funktionalität der Knotenmodule in den Betriebszuständen ............................. 15
4.3.1
4.3.2
4.3.3
4.3.4
Power On, Reset ......................................................................................................................... 15
Stopped ....................................................................................................................................... 15
Pre-Operational ........................................................................................................................... 15
Operational .................................................................................................................................. 15
5
Das Servicedatenobjekt SDO ....................................................... 16
5.1
5.2
5.3
5.4
Upload von Daten ............................................................................................. 16
Download von Daten ......................................................................................... 16
Aufbau eines SDO-Telegramms ....................................................................... 17
Servicedatenobjekte mit Geräteinformation ...................................................... 17
6
Das Prozessdatenobjekt PDO ...................................................... 19
6.1 PDO Kommunikationsparameter....................................................................... 19
6.1.1
6.1.2
6.1.3
6.1.4
COB-ID ........................................................................................................................................ 20
Übertragungsart .......................................................................................................................... 20
Ruhezeit (Inhibit Time) ................................................................................................................ 21
Ereignis Timer (Event Timer) ...................................................................................................... 21
6.2 Mapping-Parameter und Mapping-Objekte ....................................................... 22
6.2.1 Mapping-Parameter .................................................................................................................... 22
6.2.2 Mapping-Objekte ......................................................................................................................... 24
6.2.3 PDO-Belegung ............................................................................................................................ 25
7
Das Emergency-Objekt und Fehlerverhalten.............................. 27
3/39
Inhalt
7.1 Das Emergency-Telegramm ............................................................................. 27
7.2 Fehlerregister (Objekt 1001H) ........................................................................... 28
7.3 Hersteller-Statusregister (Objekt 1002H) .......................................................... 29
7.3.1 Tabelle Error-Codes .................................................................................................................... 29
7.4 Fehlermeldung (Objekt 1003-01H) .................................................................... 30
7.5 Fehlerverhalten des Moduls .............................................................................. 31
7.5.1 Fehlerverhalten der digitalen Ausgänge ..................................................................................... 32
7.5.2 Fehlerverhalten der analogen Ausgänge .................................................................................... 33
8
Parameterspeicherung ................................................................. 34
9
Ausfallüberwachung ..................................................................... 35
9.1 Node-/Lifeguarding ............................................................................................ 36
9.2 Heartbeat-Ausfallüberwachung .........................................................................37
10 Verhalten der Ein- und Ausgänge ............................................... 38
11 Änderungshistorie ........................................................................ 39
4/39
Inhalt
Abbildungsverzeichnis
Abb. 1: CANopen Kommunikationsmodell ...............................................................................................7
Abb. 2: Blockbild Minimal-Boot-Up ........................................................................................................ 14
Abb. 3: Node-/Lifeguarding ................................................................................................................... 36
Abb. 4: Heartbeat-Ausfallüberwachung ................................................................................................ 37
5/39
Funktionsumfang
1 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:
CAN Application Layer for Industrial Applications
CiA DS-301, V4.01:
CANopen Communication Profile for Industrial Systems
CiA DSP 401, V2.0:
Device Profile for I/O-Modules
Unterstützte CANopen-Merkmale
 Boot-Up-Message
 NMT-Objekt
 Emergency-Objekt
 SYNC-Objekt
 Servicedaten (SDO-Transfer)
 Prozessdaten (PDO-Transfer)
- ereignisgesteuert (Eingangsänderung)
- anfragegesteuert (Remotely-Requested = RTR, bzw. Remote-Requested only)
- zeitgesteuert intern (Timer Driven)
- synchrongesteuert 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
Kommunikation
2 CANopen Kommunikation
2.1
Das CANopen Kommunikationsmodell
Darstellung aus der Sicht des Slaves:
Daten / Parameter vom Slave
ObjektVerzeichnis
Funktionen
vom Slave
Master
Slave
CAN-Bus / CANopen
NMT
EMCY
GUARD
SDO
Spezifische Device Hardware
z. B. E/A
Ablaufsteuerung
PDO
SYNC
Dig. E.
Dig. A.
Antrieb
Logische Kommunikationskanäle
Abb. 1: CANopen Kommunikationsmodell
7/39
Kommunikation
2.2
Default-Identifier und Prioritäten der Kommunikationskanäle
000H
NMT - Service (000H)
080H
080H
SYNC - Message (080H)
081 H
0FFH
EMERGENCY - Message (080H + Node ID)
180H
TRANSMIT PDO 1 (180H + Node ID)

1FFH
200H
RECEIVE PDO 1 (200H + Node ID)
27FH
280H


Hohe Priorität
TRANSMIT PDO 2 (280 + Node ID)
2FFH
300H
37FH
380H
3FFH
400H
47FH
480H

4FFH
500H
580H
TRANSMIT SDO (580H + Node ID)
600H
67FH
RECEIVE SDO (600H + Node ID)
700H
77FH
8/39


57FH
5FFH
Niedrige Priorität
NODE GUARDING (700H)
Objektverzeichnis
3 CANopen-Objektverzeichnis
3.1
Prinzipielle Struktur CANopen-Objektverzeichnis
Index (hex)
Objekt
0000
nicht belegt
0001
Statische Datentypen
0020-003F
Komplexe Datentypen
0040-005F
Herstellerspezifische Datentypen
0060-007F
Gerätespezifische Datentypen (statisch)
0080-009F
Gerätespezifische Datentypen (komplex)
00A0-00FF
Reserviert für anderweitige Nutzung
0260-03FF
reserviert
0400-0FFF
reserviert
1000-1FFF
Kommunikationsprofile
2000-5FFF
Herstellerspezifische Profile
6000-9FFF
Standardisierte Geräteprofile
A000-FFFF
Reserviert für anderweitige Nutzung
C000-FFFF
reserviert
9/39
Objektverzeichnis
3.2
Übersicht CANopen-Objektverzeichnis
Definition Datentypen (0001 - 005FH)
reserviert (0060 - 0FFFH)
Kommunikationsspezifischer Profilbereich (1000 - 1FFFH)
Index Objekttyp
(hex)
Objektname
Datentyp
Zugr. Obj. Mapping
typ
Kl. (PDO x)
1000
VAR
Gerätetyp
Unsigned 32
const
M
1001
VAR
Fehlerregister
Unsigned 8
ro
M
1002
VAR
Hersteller Statusregister
Unsigned 32
ro
O
1003
ARRAY
Fehlermeldung
Unsigned 32
ro
O
1004
ARRAY
Anzahl unterstützter PDOs
Unsigned 32
ro
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
Unsigned 32
wo
O
1011
ARRAY
Default-Parameter zurückladen
Unsigned 32
wo
O
1016
ARRAY
Consumer Heartbeat Zeit
Unsigned 32
rw
O
1017
VAR
Producer Heartbeat Zeit
Unsigned 16
rw
O
1018
ARRAY
Identity Object
Identity
ro
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
PDOCommPar
rw
O
1402
RECORD
PDOCommPar
rw
O
1403
RECORD
PDOCommPar
rw
O
Receive PDO Mapping-Parameter (1600H)
1600
RECORD
Receive PDO 1 Mapping-Param. PDOMapPar
ro
O
1601
RECORD
ro
O
1602
RECORD
ro
O
1603
RECORD
ro
O
10/39
Index Objekttyp
(hex)
Objektname
Objektverzeichnis
Datentyp
Zugr. Obj. Mapping
typ
Kl. (PDO x)
Transmit PDO Kommunikations-Parameter (1800H)
1800
RECORD
Transmit PDO 1 Komm.-Param.
PDOCommPar
rw
O
1801
RECORD
PDOCommPar
rw
O
1802
RECORD
PDOCommPar
rw
O
1803
RECORD
PDOCommPar
rw
O
Transmit PDO Mapping-Parameter (1A00H)
1A00
RECORD
Transmit PDO 1 Mapping-Param. PDOMapPar
ro
O
1A01
RECORD
ro
O
1A02
RECORD
ro
O
1A03
RECORD
ro
O
Herstellerspezifischer Profilbereich (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äteprofilbereich (6000 – 9FFFH)
Digitale Eingänge (6000 – 61FFH)
6000
ARRAY
8 digitale Eingänge lesen
Unsigned 8
ro
O
D-TxP1
D-RxP1
Digitale Ausgänge (6200 – 63FFH)
6200
ARRAY
8 digitale Ausgänge schreiben
Unsigned 8
rw
O
6206
ARRAY
Fehlerverhalten 8 dig. Ausgänge
Unsigned 8
rw
O
6207
ARRAY
Fehlerzustand 8 dig. Ausgänge
Unsigned 8
rw
O
Analoge Eingänge (6400 – 61FFH)
6401
ARRAY
Analoge Eingänge lesen
Signed 16
ro
O
6426
ARRAY
Interrupt analoger Eing., Delta +/- Signed 16
rw
O
D-TxP2..3
11/39
Objektverzeichnis
Index Objekttyp
(hex)
Objektname
Datentyp
Zugr. Obj. Mapping
typ
Kl. (PDO x)
Analoge Ausgänge (6411 – 67FFH)
6411
ARRAY
Analoge Ausgänge schreiben
Signed 16
rw
O
6443
ARRAY
Fehlerverhalten analoge
Ausgänge
Signed 8
rw
O
6444
ARRAY
Analogwert Ausgänge
Signed 16
rw
O
reserviert für weitere Funktionen (6800H - ....)
reserviert (A000 – FFFFH)
Legende:
Zugr.typ
(Zugriffstyp)
Mapping (PDO x)
Obj.Kl.
(Objektklasse)
12/39
r
read
w
write
o
only
D
Default
Rx
Receive, vom Slave aus gesehen
Tx
Transmit
M
Mandatory
O
Option
D-RxP2..3
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 (Broadcast).
Zum Starten der Module ist nur eine einzige Nachricht erforderlich: „Start Remote Node“.
Im Zustand „Operational“ beginnt die eigentliche Datenübertragung.
13/39
Netzwerkmanagement
4.2
Minimal Boot-Up
(4)
Stopped
(6)
(3)
(4)
(1)
Initialization
(2)
(5)
(6)
(4)
(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]
Startet das Modul, gibt die Ausgänge frei, startet die
Übertragung von PDOs
(3)
Enter Pre-Operational Mode
[cs=80H]
Stoppt die PDO-Übertragung, SDO ist weiter aktiv
(4)
Reset Node
[cs=81H]
Führt einen Modul-Reset durch (einschließlich der
Applikation)
(5)
Reset Communication
[cs=82H]
Führt einen Reset der Kommunikationsfunktionen durch
(6)
Stop Remote Node
[cs=02H]
Stoppt die Kommunikation, mit Ausnahme der Funktionen
Nodeguarding und Heartbeat
14/39
4.3
Netzwerkmanagement
Funktionalität der Knotenmodule in den Betriebszuständen
4.3.1
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-UpMessage 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
4.3.2
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.
4.3.3
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.
4.3.4
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
Servicedatenobjekt
5 Das Servicedatenobjekt SDO
Request
Client
Server
Response
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
CANopen
E/A-Knoten
Upload Response --- Objekt
5.2
Download von Daten
Ein Client sendet Daten mit einem „Initiate Download Request“ an ein CAN-Bus-Modul:
Download Request --- Daten
CANopen
E/A-Knoten
Client
Download Response --- Quittung
16/39
5.3
Aufbau eines SDO-Telegramms
Byte 0
Byte 1
SDOCmd
Index
5.4
Servicedatenobjekt
Byte 2
Byte 3
Byte 4
SubIndex
SDO-Daten
Byte 5
Byte 6
Byte 7
Servicedatenobjekte mit Geräteinformation
SDO
Index
SubIndex
Bedeutung
Datentyp
Wert
Zugriff
1000H
00
Gerätetyp
Unsigned 32
0xF0191
ro
1004H
00
Anzahl unterstützter PDOs insgesamt
Unsigned 32
0x30003
ro
01
Anzahl synchroner PDOs
Unsigned 32
0x0
ro
02
Anzahl asynchroner PDOs
Unsigned 32
0x30003
ro
1008H
00
Herstellerspezifische Gerätenamen
Visible-String
DR-COCMxxx
ro
1009H
00
Hardware Version
Visible-String
B*
ro
100AH
00
Software Version
Visible-String
2.0 *
ro
1018H
00
Anzahl Einträge
Unsigned 8
1
ro
01
Vendor ID
Unsigned 32
0x64
ro
2000H
00
Node ID EEPROM
Unsigned 8
1 - 127
rw
2001H
00
Baudrate EEPROM
Unsigned 8
0-7
rw
2010H
-
L-Bus Statusbyte
Unsigned 16
ro
2011 H
00
Anzahl E/A-Module (L-Bus Slave)
Unsigend 8
ro
2011 H
01…16
ID E/A-Module 01…16
(L-Bus Slaves 01…16)
Unsigend 8
ro
* Stand Drucklegung
17/39
Servicedatenobjekt
Die Werte für Node ID (2000-00) und Baudrate (2001-00) 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 2000-00
Node ID dec.
00
nicht erlaubt
01
1
...
...
0F
15
10
16
...
...
7F
127
80
nicht erlaubt
...
nicht erlaubt
FF
nicht erlaubt
Wert SDO 2001-00
CAN-Baudrate
0
1 Mbit/s
1
800 kbit/s
2
500 kbit/s
3
250 kbit/s
4
125 kbit/s
5
50 kbit/s
6
20 kbit/s
7
10 kbit/s
Die Werte für 2000-00 und 2001-00 werden sofort im EEPROM gespeichert und nicht durch
SDO 1010 oder SDO 1011 beeinflusst.
18/39
Prozessdatenobjekt
6 Das Prozessdatenobjekt PDO
Mit Prozessdatenobjekten (PDOs) werden Echtzeitdaten übertragen.
Request (optional)
Client
Server
(PDO) Response
SYNC
6.1
PDO Kommunikationsparameter
Mit Hilfe der Kommunikationsparameter (Objekt 1400H.., 1800H.. ) wird definiert, wann die Daten
übertragen werden:
SDO
Index
SubIndex
Bedeutung
Datentyp
Wert
Zugriff
1400H
00
größter unterstützter SubIndex
Unsigned 8
5
ro
01
COB-ID des RxPDO
digitale Ausgänge 1 bis 64
Unsigned 32
0x200
+ Node ID
ro
02
Übertragungsart
Unsigned 8
0 - 255
rw
03
Ruhezeit
Unsigned 16
0 - 65535
rw
04
Kombatibilitätseintrag
Unsigned 8
0 – 255
ro
05
Ereignis Timer
Unsigned 16
0 - 65535
rw
1401H
01
COB-ID des RxPDO
analoge Ausgänge 1 bis 4
Unsigned 32
0x300
+ Node ID
ro
1402H
01
COB-ID des RxPDO
Unsigned 32
0x400
+ Node ID
ro
1403H
01
COB-ID des RxPDO
Unsigned 32
0x500
+ Node ID
ro
1800H
01
COB-ID des TxPDO
digitale Eingänge 1 bis 64
Unsigned 32
0x180
+ Node ID
ro
1801H
01
COB-ID des RxPDO
analoge Eingänge 1 bis 4
Unsigned 32
0x280
+ Node ID
ro
1802H
01
COB-ID des RxPDO
Unsigned 32
0x380
+ Node ID
ro
1803H
01
COB-ID des RxPDO
Unsigned 32
0x480
+ Node ID
ro
Die Sub-Indizes 0 und 2 bis 5 sind identisch im Aufbau.
19/39
Prozessdatenobjekt
6.1.1
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.
6.1.2
Übertragungsart
Wert
zyklisch
0
1-240
241-252
x
azyklisch
synchron
asynchron
x
x
x
x
x
reserved
x
253
RTR Polling
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 SyncObjektes 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 1 - 240 werden die PDOs synchron 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 trotz 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äteprofil
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-Index 5 des zugehörigen Kommunikationsobjektes (SDO 1400 ... 1402 und
SDO 1800 ... 1802) eingestellt. Ein eingetretenes Ereignis triggert dabei den Timer erneut nach.
20/39
6.1.3
Prozessdatenobjekt
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.
6.1.4
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
Prozessdatenobjekt
6.2
Mapping-Parameter und Mapping-Objekte
6.2.1
Mapping-Parameter
Die Mapping-Parameter geben den Index, den Sub-Index und die Länge (in Bits) des gemappten
Objektes an.
SDO
Index
SubIndex
Bedeutung
Datentyp
Wert
Zugriff
1600H
00
1. RxPDO
Anzahl der gemappten Objekte
Unsigned 8
0-8
ro
01
PDO-Mapping
1. Byte digitale Ausgänge
Unsigned 32
0x00 oder
0x6200 01 08
ro
08
PDO-Mapping
8. Byte digitale Ausgänge
Unsigned 32
0x00 oder
0x6200 08 08
ro
00
2. RxPDO
Unsigned 8
0-4
ro
01
PDO-Mapping
1. analoger Ausgang
Unsigned 32
0x00 oder
0x6411 01 10
ro
04
PDO-Mapping
4. analoger Ausgang
Unsigned 32
0x00 oder
0x6411 04 10
ro
00
3. RxPDO
Unsigned 8
0-4
ro
01
PDO-Mapping
5. analoger Ausgang
Unsigned 32
0x00 oder
0x6411 05 10
ro
04
PDO-Mapping
8. analoger Ausgang
Unsigned 32
0x00 oder
0x6411 08 10
ro
00
4. RxPDO
Unsigned 8
0-4
ro
01
PDO-Mapping
9. analoger Ausgang
Unsigned 32
0x00 oder
0x6411 09 10
ro
PDO-Mapping
12. analoger Ausgang
Unsigned 32
0x00 oder
0x6411 12 10
ro

1601H

1602H

1603H

04
22/39
Prozessdatenobjekt
SDO
Index
SubIndex
Bedeutung
Datentyp
Wert
Zugriff
1A00H
00
1. TxPDO
Unsigned 8
0-8
ro
01
PDO-Mapping
1. Byte digitale Eingänge
Unsigned 32
0x00 oder
0x6000 01 08
ro
08
PDO-Mapping
8. Byte digitale Eingänge
Unsigned 32
0x00 oder
0x6000 08 08
ro
00
2. TxPDO
Unsigned 8
0-4
ro
01
PDO-Mapping
1. analoger Eingang
Unsigned 32
0x00 oder
0x6401 01 10
ro
04
PDO-Mapping
4. analoger Eingang
Unsigned 32
0x00 oder
0x6401 04 10
ro
00
3. TxPDO
Unsigned 8
0-4
ro
01
PDO-Mapping
5. analoger Eingang
Unsigned 32
0x00 oder
0x6401 05 10
ro
04
PDO-Mapping
8. analoger Eingang
Unsigned 32
0x00 oder
0x6401 08 10
ro
00
4. TxPDO
Unsigned 8
0-4
ro
01
PDO-Mapping
9. analoger Eingang
Unsigned 32
0x00 oder
0x6401 09 10
ro
PDO-Mapping
12. analoger Eingang
Unsigned 32
0x00 oder
0x6401 12 10
ro

1A01H

1A02H

1A03H

04
Sub-Index 1 bis 8 Wert: 0xaaaa bb cc mit: aaaa = Index, bb = Sub-Index, 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
Prozessdatenobjekt
6.2.2
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
Index
SubIndex
Bedeutung
Datentyp
6000H
00
Anzahl Bytes digitale Eingänge
Unsigned 8
01
8 digitale Eingänge 1 bis 8
Unsigned 8
PDO
Mapping
Zugriff
ro
TxPDO1
ro

6200H
08
8 digitale Eingänge 57 bis 64
00
Anzahl Bytes digitale Ausgänge
Unsigned 8
01
8 digitale Ausgänge 1 bis 8
Unsigned 8
ro
RxPDO1
rw

6401H
08
8 digitale Ausgänge 57 bis 64
00
Anzahl analoge Eingänge
Unsigned 8
01
1. analoger Eingang
Unsigned 16
TxPDO2
ro
Unsigned 16
TxPDO3
ro
Unsigned 16
TxPDO4
ro
ro

04
4. analoger Eingang
05
5. analoger Eingang

08
8. analoger Eingang
09
9. analoger Eingang

6411H
12
12. analoger Eingang
00
Anzahl analoge Ausgänge
Unsigned 8
01
1. analoger Ausgang
Unsigned 16
RxPDO2
rw
Unsigned 16
RxPDO3
rw
Unsigned 16
RxPDO4
rw
rw

04
4. analoger Ausgang
05
5. analoger Ausgang

08
8. analoger Ausgang
09
9. analoger Ausgang

12
24/39
12. analoger Ausgang
6.2.3
Prozessdatenobjekt
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 3
180 + Node ID
Eingang 1-8
Eingang 9-16
Eingang 17-24
Eingang 25-32
Digitale
Byte 4
Byte 5
Byte 6
Byte 7
Eingänge
Eingang 33-40
Eingang 41-48
Eingang 49-56
Eingang 57-64
LSB = 1. Eingang, MSB = 8. Eingang, ...
2. TxPDO (Sende-PDO für analoge Eingänge 1-4)
COB-ID
Byte 0
Byte 1
Byte 2
Byte 3
280 + 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
COB-ID
Byte 0
Byte 1
Byte 2
Byte 3
380 + 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
COB-ID
Byte 0
Byte 1
Byte 2
Byte 3
480 + 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
Prozessdatenobjekt
1. RxPDO (Empfangs-PDO für digitale Ausgänge 1-64)
COB-ID
Byte 0
Byte 1
Byte 2
Byte 3
200 + Node ID
Ausgang 1-8
Ausgang 9-16
Ausgang 17-24
Ausgang 25-32
Digitale
Byte 4
Byte 5
Byte 6
Byte 7
Ausgänge
Ausgang 33-40
Ausgang 41-48
Ausgang 49-56
Ausgang 57-64
LSB = 1. Ausgang, MSB = 8. Ausgang, ...
2. RxPDO (Empfangs-PDO für analoge Ausgänge 1-4)
COB-ID
Byte 0
Byte 1
Byte 2
Byte 3
300 + 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
COB-ID
Byte 0
Byte 1
Byte 2
Byte 3
400 + 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
COB-ID
Byte 0
Byte 1
Byte 2
Byte 3
500 + 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
Emergency-Objekt
7 Das Emergency-Objekt und Fehlerverhalten
7.1
Das Emergency-Telegramm
Client
Server
Request
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 pro „Error 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
Fehlermeldung
(Objekt 1003H)
Byte 2
Byte 3
Byte 4
Fehler
Register
(Objekt
1001H)
(Objekt 1002H)
Byte 5
Byte 6
Byte 7
leer
Das Emergency-Telegramm setzt sich somit aus folgenden Service-Daten-Objekten zusammen:
SDO
Index
SubIndex
Bedeutung
Datentyp
Wert
Zugriff
1001H
00
Fehlerregister
Unsigned 8
siehe unten
ro
1002H
00
Unsigned 32
siehe unten
ro
1003H
00
Anzahl Fehlermeldung
Unsigned 8
0x01
ro
01
Fehlermeldung
Unsigned 32
siehe unten
ro
27/39
Emergency-Objekt
7.2
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:
kein Fehler
Wert = 1:
entsprechender Fehler
Man.Spec.
Herstellerspezifischer Fehler, wird in Objekt 1002H genauer spezifiziert.
Dev.Spec.
Fehlerflag, gerätespezifisch (nicht benutzt)
Temp.
Temperaturüberwachung im Modul (nicht benutzt)
Voltage
z.B. Eingangsspannung außerhalb des gültigen Bereiches (nicht benutzt)
Current
z.B. Überlast an den Ausgängen
Comm.
Kommunikationsfehler
Generic
Nicht näher spezifiziert, ist bei jeder Fehlermeldung gesetzt
28/39
7.3
Emergency-Objekt
Hersteller-Statusregister (Objekt 1002H)
Das Objekt 1002H gibt den aktuellen herstellerspezifischen Status des Moduls an.
LSByte
MSByte
Status Byte 1
Status Byte 2
Status Byte 3
Status Byte 4
MSBit
LSBit
Byte 1
ShortC
Byte 2
ComE
OrE
InFM
OutFM
Byte 3
SubCom
MemE
Actual Bus State
Byte 4
Wert = 0:
kein Fehler
Wert = 1:
entsprechender Fehler
7.3.1
Tabelle Error-Codes
ShortC
Kurzschluss an den digitalen Ausgängen
ComE
Kommunikationsfehler (CAN Warning Limit überschritten)
OrE
CAN Overrun Error (CAN-Datenverlust)
SubCom
Kommunikationsfehler L-Bus-Modul(e)
InFM
Eingänge im Fehlermodus
OutFM
Ausgänge im Fehlermodus
MemE
Fehler im nichtflüchtigen Speicher (EEPROM)
Actual Bus State
0x7F für Pre-Operational
0x05 für Operational
Derzeitiger CAL-Status des Knotens (entspricht Status in
CAL Nodeguarding Telegramm)
29/39
Emergency-Objekt
7.4
Fehlermeldung (Objekt 1003-01H)
Das Objekt 1003-01H enthält den Emergency Error Code nach DS301.
Wert
Bedeutung
00,00H
Kein Fehler, Fehler behoben
21,xxH
1)
Strom (eingangsseitig)
z.B. Kurzschluss Sensorversorgung
23,xxH
1)
Strom (ausgangsseitig)
z.B. Kurzschluss Aktorausgang
Datenspeicherung
Fehler EEPROM
Erweiterungsmodule
Fehler interner Erweiterungsbus
81,xxH
Kommunikation
Fehler in der CAN-Kommunikation
50,01H
Hardware-Fehler Analog-In-Modul
Error-Code in Anlehnung an DS301
50,02H
Hardware-Fehler Analog-Out-Modul
Error-Code in Anlehnung an DS301
63,xxH
70,xxH
1)
Zusatzinformation
1)
finden nur bei entsprechend ausgeführter Hardware Verwendung
30/39
7.5
Emergency-Objekt
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
Index
SubIndex
Bedeutung
Datentyp
Wert
Zugriff
1029H
00
Größter unterstützter Sub-Index
Unsigned 8
3
ro
01
Fehlerverhalten bei
Kommunikationsfehler
Unsigned 8
0-2
rw
02
Fehlerverhalten bei Ausgangsfehler
Unsigned 8
0-2
rw
03
Fehlerverhalten bei Eingangsfehler
Unsigned 8
0-2
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
Emergency-Objekt
7.5.1
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 NMTKommandos „Start Remote Node“ wird der Fehlerzustand wieder verlassen und die Ausgänge
nehmen den zuletzt eingestellten Zustand wieder ein.
SDO
Index
SubIndex
Bedeutung
Datentyp
Wert
Zugriff
6206H
00
Unsigned 8
8
ro
01
Fehlermodus Ausgänge 1 bis 8
Unsigned 8
0-0xFF
rw

6207H
08
Fehlermodus Ausgänge 57 bis 64
00
Unsigned 8
8
ro
01
Fehlerwert Ausgänge 1 bis 8
Unsigned 8
0-0xFF
rw

08
32/39
Fehlerwert Ausgänge 57 bis 64
7.5.2
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 NMTKommandos „Start Remote Node“ wird der Fehlerzustand wieder verlassen und die Ausgänge
nehmen den zuletzt eingestellten Zustand wieder ein.
SDO
Index
SubIndex
Bedeutung
Datentyp
Wert
Zugriff
6443H
00
Unsigned 8
12
ro
01
Fehlermodus analoger Ausgang 1
Unsigned 8
0-1
rw

6444H
12
Fehlermodus analoger Ausgang 12
00
Unsigned 8
12
ro
01
Fehlerwert analoger Ausgang 1
Unsigned 16
0-0xFFFF
rw

12
Fehlerwert analoger Ausgang 12
33/39
Parameterspeicherung
8 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
Index
SubIndex
Bedeutung
Datentyp
Wert
Zugriff
1010H
00
Unsigned 8
4
ro
01
Speicherung aller Parameter
Unsigned 32
ASCII save
rw
02
Speicherung der KommunikationsParameter
Unsigned 32
ASCII save
rw
03
Speicherung der ApplikationsParameter
Unsigned 32
ASCII save
rw
04
Speicherung der herstellerspezifischen Parameter
Unsigned 32
ASCII save
rw
00
Unsigned 8
4
ro
01
Laden aller Default-Parameter
Unsigned 32
ASCII load
rw
02
Laden der Default-KommunikationsParameter
Unsigned 32
ASCII load
rw
03
Laden der Default-ApplikationsParameter
Unsigned 32
ASCII load
rw
04
Laden der DefaultHerstellerspezifischen-Parameter
Unsigned 32
ASCII load
rw
1011H
Kommunikations-Parameter
SDO 1000 bis 1FFF
Herstellerspezifische-Parameter
SDO 2000 bis 5FFF
Applikations-Parameter
SDO 6000 bis 6FFF
34/39
Ausfallüberwachung
9 Ausfallüberwachung
Für die Ausfallüberwachung eines CANopen Knotens stehen die Funktionen Nodeguarding bzw. das
Producer-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
Index
SubIndex
Bedeutung
Datentyp
Wert
Zugriff
100CH
00
Guard Zeit
Unsigned 16
0xbb bb
rw
100DH
00
Life Time Faktor
Unsigned 8
0 - 255
rw
1016H
00
Anzahl Einträge
Unsigned 32
0x01
rw
01
Consumer Heartbeat Zeit
Unsigned 32
0x00 aa bb bb
rw
00
Producer Heartbeat Zeit
Unsigned 16
0xbb bb
rw
1017H
aa = Node ID des überwachten Teilnehmers
bb bb = Zeit in ms
35/39
Ausfallüberwachung
9.1
Node-/Lifeguarding
Request
Master
Slave
Response
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 NMTMaster 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
Slave
Remote Transmit Request
0
7
t
1
Indication
6…0
Status
Response
Confirm
Indication
Request
0
7
t
Confirm
Life Time
Guard Time
Request
1
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
9.2
Ausfallüberwachung
Heartbeat-Ausfallüberwachung
Im Gegensatz zum Guarding-Protokoll verwendet das Heartbeat-Protokoll keine Remote-Frames.
Der Heartbeat-Producer sendet zyklisch im Abstand der Heartbeat-Producer-Zeit eine HeartbeatMessage, welche von den Heartbeat-Consumern empfangen wird.
Empfängt ein Heartbeat-Consumer innerhalb der Heartbeat-Consumer-Zeit keine weitere HeartbeatMessage, so spricht die Ausfallüberwachung (Heartbeat-Event) an.
Das Heartbeat-Protokoll 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 programmiert, so wird entsprechend die HeartbeatMessage-Generierung bzw. die Heartbeat-Message-Überwachung nicht aktiviert.
Master
Slave
0
7
t
1
Indication
6…0
Status
Response
Confirm
Indication
Request
0
7
t
Life Time
Guard Time
Request
1
6…0
Status
Confirm
Response
Abb. 4: Heartbeat-Ausfallüberwachung
Bei neuen Applikationen ist die Heartbeat-Ausfallüberwachung vorzuziehen.
37/39
Verhalten der Ein-/Ausgänge
10 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 Prozessdaten-Nachricht (PDO) auszulösen.
Verhalten der digitalen Ausgänge
Neue Prozessdaten (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 ProzessdatenNachricht (PDO) ausgelöst.
SDO
Index
SubIndex
Bedeutung
Datentyp
DefaultWert
Zugriff
6426H
00
Unsigned 8
12
ro
01
Deltawert analoger Eingang 1
Unsigned 16
0-0xFFFF
rw

12
Deltawert analoger Eingang 12
Verhalten der analogen Ausgänge
Neue Prozessdaten (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
Änderungshistorie
11 Änderungshistorie
Version
2.0
Änderung
Juni 2003
Vorlage
2.10
Jan. 2007
6.1.3
(Überschrift) Inhabit  Inhibit (FB CANopen)
6.1.1
... des PDOs an, der zur Datenübertragung...(FB CANopen)
9
Eintrag in Tabelle muss lauten 1017H – 00 –Producer …
4.3.1
Hinweis auf DS 301 V4.00 entfernt
6.1
1400-00 Datentyp Unsigned 8 anstatt 32
1400-04 Kombatibilitätseintrag hinzugekommen
11
Änderungshistorie hinzugekommen
7.3
Error-Codes für analoge Ein- und Ausgänge entfernen. Digitale Ein- und
Ausgangsfehler als allgemeine Ein- Ausgangsfehler bezeichnen.
2.20
April 2008
2.30
April 2014
Produktfamilie DIORAIL  DIORAIL/DIOLINE20
Erweiterung Objektverzeichniseinträge Kapitel 5.4 „Servicedatenobjekte
mit Geräteinformationen“
Anpassung Bildwortmarke und Kontaktdaten
39/39

CANopen - Lütze Transportation

Transcription

Documents pareils

Datentechnik

Lösungen

Ethernet I/O-Module ETHIO - Wachendorff Prozesstechnik

Material zum Praktikumsversuch Buffer Overflows - Ruhr

Adapterboard deRFmega256-23T13 Datenblatt

Gstaad: Ein Chalet-Dorf im Paradies

Aufbauanleitung Anlagen neu Form40.cdr

Wasserstraße Gemeinde Ufer Typ Kanal Bocholt