CANopen. Function Description. For use in DIORAIL/DIOLINE20 Modules

Transcription

1 CANopen Function Description For use in DIORAIL/DIOLINE20 Modules Version 2.40 March 2015

2 Lütze reserves the right to make changes to its pducts in the interest of technical development. Such changes will not be documented, in every case. This guide and the information it contains has been compiled with due care. However, Lütze does not assume liability for printing or other errs, or any resulting damages that might arise fm that. The listed brand names and pduct names in this manual are the registered trademarks of their respective holders. Copyright 2014 by Lütze Transportation GmbH. All rights reserved. How to contact us Lütze Transportation GmbH Postfach 1224 D Weinstadt - Gßheppach Germany Phone Switchboard: ++49/ (0)7151/ Fax: ++49/ (0)7151/ sales.transportation@luetze.de Website: 2 /39

3 Table of Graphics Content 1 Scope of Functions CANopen Communication The CANopen Communication Model Default Identifier and Priorities of the Communication Channels CANopen Object Dictionary General Structure of the CANopen Object Dictionary Overview of the CANopen Object Dictionary The Network Management NMT Configuration and Start Minimal Boot-Up Functionality of the Node Modules in the Operating States Power On, Reset Stopped Pre-Operational Operational The Service Data Object SDO Upload of Data Download of Data Structure of the SDO Telegram Service Data Objects with Device Information Node ID Baudrate L-Bus Statusbyte L-Bus Topology Data The Pcess Data Object PDO PDO Communication Parameters COB ID Mode of Transmission Inhibit Time Event Timer Mapping Parameters and Mapping Objects Mapping Parameters Mapping Objects PDO Assignment The Emergency Object and Err Behavior The Emergency Telegram Err Register (Object 1001H) Manufacturer Status Register (Object 1002H) Table of the Err Codes Err Message (Object H) Err Behavior of the Module Err Behavior of the Digital Outputs Err Behavior of the Analog Outputs Storage of Parameters Failure Monitoring /39

4 Table of Graphics 9.1 Node Guarding / Life Guarding Heartbeat Failure Monitoring Behavior of the Inputs and Outputs Change History /39

5 Table of Graphics Table of Graphics Figure 1: CANopen Communication Model... 7 Figure 2: Block Diagram Minimal Boot-Up Figure 3: Node Guarding / Life Guarding Figure 4: Heartbeat Failure Monitoring /39

6 Scope of Functions 1 Scope of Functions The functional description contains the necessary information for the CANopen connection of the DIORAIL/DIOLINE20 Modules. The basics for the software realization are the following standards specified by "CAN in Automation (CiA)": 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 Supported CANopen Characteristics Boot-Up message NMT object Emergency object SYNC object Service data (SDO transfer) Pcess data (PDO transfer) - event contlled (alteration of inputs) - request contlled (remotely requested = RTR, resp. remote requested only) - time contlled internal (timer driven) - synchnous contlled external (Sync object) Life guarding / Node guarding Heartbeat Err behavior I/O module (object 1029) Err behavior digital outputs (object 6206, 6207) Err behavior analog outputs (object 6443, 6444) PDO activation of analog inputs via the value alteration window (object 6426) Err detection for modules. 6 /39

7 CANopen Communication 2 CANopen Communication 2.1 The CANopen Communication Model Presentation fm the slave perspective: Sequence contl Daten / Slave parameters Object directory Master Slave CAN-Bus / CANopen NMT EMCY GUARD SDO PDO Function of Slave Specific Device Hardware SYNC Dig. I. Dig.O.D rive Logical communication channels Figure 1: CANopen Communication Model 7 /39

8 CANopen Communication 2.2 Default Identifier and Priorities of the Communication Channels 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 CANopen Object Dictionary 3 CANopen Object Dictionary 3.1 General Structure of the CANopen Object Dictionary (hex) Object 0000 Not in use 0001 Static data types F Complex data types F Manufacturer specific data types F Device specific data types (static) F Device specific data types (complex) 00A0-00FF Reserved for further use FFF Communication pfile definition FFF Manufacturer specific pfile definition FFF Standardized device pfile definition A000-FFFF Reserved for further use C000-FFFF Reserved 9 /39

10 CANopen Object Dictionary 3.2 Overview of the CANopen Object Dictionary Definition Data Types ( FH) Reserved (0060-0FFFH) Communication-Specific Pfile Area (1000-1FFFH) (hex) Object Type Object Name Data Type Acc. Type Obj. Cat. Mapping (PDO x) 1000 VAR Device type const M 1001 VAR Err register Unsigned 8 M 1002 VAR Manufacturer status register O 1003 ARRAY Err message O 1004 ARRAY Number of supported PDOs O 1008 VAR Manufacturer specific device names Visible string const O 1009 VAR Hardware version Visible string const O 100A VAR Software version Visible string const O 100C VAR Guard time Unsigned 16 rw O 100D VAR Life time factor Unsigned 8 rw O 1010 ARRAY Store parameters wo O 1011 ARRAY Restore default parameters wo O 1016 ARRAY Consumer heartbeat time rw O 1017 VAR Pducer heartbeat time Unsigned 16 rw O 1018 ARRAY Object identity Identity M 1029 ARRAY Err behavior module Unsigned 8 rw O Receive PDO Communication Parameters (1400H) 1400 RECORD Receive PDO 1 comm. param. PDOCommPar rw O 1401 RECORD Receive PDO 2 comm. param. PDOCommPar rw O 1402 RECORD Receive PDO 3 comm. param. PDOCommPar rw O 1403 RECORD Receive PDO 4 comm. param. PDOCommPar rw O Receive PDO Mapping Parameters (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 CANopen Object Dictionary (hex) Object Type Object Name Data Type Acc. Type Obj. Cat. Mapping (PDO x) Transmit PDO Communication Parameters (1800H) 1800 RECORD Transmit PDO 1 comm. param. PDOCommPar rw O 1801 RECORD Transmit PDO 2 comm. param. PDOCommPar rw O 1802 RECORD Transmit PDO 3 comm. param. PDOCommPar rw O 1803 RECORD Transmit PDO 4 comm. param. PDOCommPar rw O Transmit PDO Mapping Parameters (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 Manufacturer Specific Pfile Area (2000-5FFFH) 2000 VAR Node ID EEPROM Unsigned 8 rw O 2001 VAR Baud rate EEPROM Unsigned 8 rw O 5FF8 VAR Manufacturer specific device Visible string wo O names EEPROM 5FF9 VAR Hardware version EEPROM Visible string wo O Standardized Device Pfile Area (6000-9FFFH) Digital Inputs ( FFH) 6000 ARRAY Read 8 digital inputs Unsigned 8 O D-TxP1 Digital Outputs ( FFH) 6200 ARRAY Write 8 digital outputs Unsigned 8 rw O D-RxP ARRAY Err behavior 8 digital outputs Unsigned 8 rw O 6207 ARRAY Err status 8 digital outputs Unsigned 8 rw O Analog Inputs ( FFH) 6401 ARRAY Read analog inputs Signed 16 O D-TxP ARRAY Interrupt analog input, delta +/- Signed 16 rw O 11 /39

12 CANopen Object Dictionary (hex) Object Type Object Name Data Type Acc. Type Obj. Cat. Mapping (PDO x) Analog Outputs ( FFH) 6411 ARRAY Write analog outputs Signed 16 rw O D-RxP ARRAY Err behavior analog outputs Signed 8 rw O 6444 ARRAY Analog value outputs Signed 16 rw O Reserved for Further Functions (6800H -...) Reserved (A000 FFFFH) Legend: Access type r read w write o only Mapping (PDO x) D Default Rx Receive, fm point of view of slave Tx Transmit Obj.Kl. M Mandatory (object class) O Option 12 /39

13 The Network Management NMT 4 The Network Management NMT 4.1 Configuration and Start Master Request Slave By using of CANopen the Boot-up of a CAN network is very easy. After the initialization, the modules are in the "Pre-Operational state, automatically. In this state, the access to the object dictionary is possible. The access will be realized via service data objects with default identifiers. The modules can be configured. For the most items default settings are available in the object dictionary. Therefore a configuration is not necessary in many cases. The used network management messages have the following structure: CAN-ID "0" with 2 bytes of data. The first data byte includes the Command Specifier [cs], the second data bytes includes the node address. The node address "0" responds all nodes (badcast). Only one message is necessary to start the modules: "Start Remote Node". The real data transfer will be started in the "Operational" state. 13 /39

14 The Network Management NMT 4.2 Minimal Boot-Up (4) Initialization Stopped (6) (2) (3) (5) (6) (4) (4) (1) (2) Pre-Operational Operational (3) (5) (5) Figure 2: Block Diagram Minimal Boot-Up Legend: No. Status Description (1) Initialization finished Enter the state "Pre-Operational" automatically (2) Start Remote Node [cs=01h] The module will be started, the outputs will be released, and the transfer of PDOs will be started (3) Enter Pre-Operational Mode The PDO transfer will be stopped, SDO is active [cs=80h] continuous (4) Reset Node Realizes a module reset (including a reset of the [cs=81h] application) (5) Reset Communication Realizes a reset of the communication functions [cs=82h] (6) Stop Remote Node The communication will be stopped with the exception of [cs=02h] the functions node guarding and heartbeat 14 /39

15 The Network Management NMT 4.3 Functionality of the Node Modules in the Operating States Power On, Reset After Power On or Reset the device realizes the required initializations and switches into the "Pre- Operational state. When that state is entered, a unique boot-up message will be sent (see DS 301 V4.00). Boot-up message on guarding channel (ID: 700H + Node ID): Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 00H Stopped In the "Stopped" state, the module is passive, and breaks the data communication with the exception of guarding and heartbeat, if one aspect of them is active. A change of the state into "Pre- Operational resp. "Operational is possible via a corresponding NMT command to the module Pre-Operational In the "Pre-Operational state, the PDOs are not active. Node guarding is possible at this time because the default identifiers for the SDO are available. If the module has an err, the emergency telegram will be sent. All needed device configurations should be realized at this time pvided the default settings can not be used. The configuration can be modified on principle also during the operation. If all configurations are realized the active operational state ("Operational") can be entered via sending a Start_Remote_Node. In the state "Pre-Operational the outputs can be activated via SDO access to the corresponding objects only. It is also possible to read the inputs by using of SDO via the dictionary Operational In the "Operational state, the input/output data can be changed over directly via PDOs. Alterations of the configuration (via SDO) are possible on principle. If the outputs of a device are in an err state then a change of the state to "Operational achieves the release of the outputs => the outputs can be written with new values. Therefore a change of the state fm "Operational to "Operational is permissible and some times useful. 15 /39

16 The Service Data Object SDO 5 The Service Data Object SDO Client Request Response Server The access to the object dictionary will be supported with the service data object (SDO). With the SDO an efficient data channel is available for the transfer of parameter data in an unlimited size. Typical device parameters can be written into respectively read out fm the object dictionary of the devices with only one telegram handshake. More information about the access to the object dictionary and the upload/download of parameter data you can find in the draft standards DS 2XX and DS Upload of Data A client (e.g. an existing bus master) requests an object fm a CAN bus module by using of an "Initiate Upload Request": Client Upload Request --- Inquiry Upload Response --- Object CANopen I/O Node 5.2 Download of Data A client sends data to a CAN bus module by using an "Initiate Download Request": Client Download Request --- Data Download Response --- Acknowledgement CANopen I/O Node 5.3 Structure of the SDO Telegram Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 SDO- Cmd Sub SDO Data 16 /39

17 The Service Data Object SDO 5.4 Service Data Objects with Device Information SDO Sub Signification Data Type Value Access 1000H 00 Device type 0xF H 00 Total number of supported PDOs 0x Number of synchnous PDOs 0x0 02 Number of asynchnous PDOs 0x H 00 Manufacturer specific device names Visible string DR-CO- CMxxx 1009H 00 Hardware version Visible string B * 100AH 00 Software version Visible string 2.0 * 1018H 00 Number of items Unsigned Vendor ID 0x H 00 Node ID EEPROM Unsigned rw 2001H 00 Baud rate EEPROM Unsigned rw 2010H - L-Bus status byte Unsigned H 00 Number of I/O modules (L-Bus slave) Unsigend H ID I/O module (L-Bus slaves 01 16) Unsigend 8 * status printing The values for Node ID ( ) and baud rate ( ) will be used at the corresponding positions of the tary switches only. An alteration of this value will be used at the next start-up without call of the function "Store Parameters SDO Node ID Value SDO Node ID (decimal) 00 not permitted F F not permitted... not permitted FF not permitted 17 /39

18 The Service Data Object SDO Baudrate Value SDO CAN Baud Rate 0 1 MBit/s kbit/s kbit/s kbit/s kbit/s 5 50 kbit/s 6 20 kbit/s 7 10 kbit/s The values for and will be stored within the EEPROM immediately. They will be not influenced by SDO 1010 or SDO L-Bus Statusbyte The L-Bus status byte contains per L-Bus slave a collective err signalization. The L-Bus status byte is part of the SDO index Example : 10 Slaves L-Bus slave err entry Position: after master ascending order fm 0 Status byte[0] Bit Status byte[1] Bit7 0 x x x x x x Example: 4 Slaves L-Bus slave err entry Position: after master ascending order fm 0 Status byte[0] Bit7 0 x x x x Status byte[1] Bit7 0 x x x x x x x x 18 /39

19 The Service Data Object SDO L-Bus Topology Data The L-Bus topology data consist of the SDO indexes number of slaves and IDs of slaves. The IDs are defined as in the table below. Pos. Type ID hex 1 Spacer F0 2 DO 8; RO 6 F1 3 DI 8 F2 4 DI 16 E0 5 DO 16 E1 6 DIO 8/8; DO6 Diag. E2 7 DO 8 Diag. E3 8 AI AO Reserved Reserved AI Reserved AIO 2/ /39

20 The Pcess Data Object PDO 6 The Pcess Data Object PDO The pcess data objects (PDOs) is used for the transfer of real time data. Client Request (optional) (PDO) Response Server SYNC 6.1 PDO Communication Parameters With communication parameters (object 1400H, 1800H) are defined when the data are transferred: SDO Sub Signification Data Type Value Access 1400H 00 Largest supported sub index 5 01 COB ID of the RxPDO 0x200 digital outputs 1 to 64 + Node ID 02 Mode of transmission Unsigned rw 03 Inhibit time Unsigned rw 04 Compatibility entry Unisgned Event timer Unsigned rw 1401H 01 COB ID of the RxPDO analog outputs 1 to H 01 COB ID of the RxPDO analog outputs 5 to H 01 COB ID of the RxPDO analog outputs 9 to H 01 COB ID of the TxPDO digital inputs 1 to H 01 COB ID of the RxPDO analog inputs 1 to H 01 COB ID of the RxPDO analog inputs 5 to H 01 COB ID of the RxPDO analog inputs 9 to 12 0x300 + Node ID 0x400 + Node ID 0x500 + Node ID 0x180 + Node ID 0x280 + Node ID 0x380 + Node ID 0x480 + Node ID The structure of the sub index 0, and 2 to 5 is identical COB ID The content specifies the address (COB ID) of the PDO, which will be used for the data transfer on the bus. The address is fixed and can not be changed. 20 /39

21 The Pcess Data Object PDO Mode of Transmission Value Cyclic Acyclic Synchnous Asynchnous RTR Polling 0 x x x x x x reserved x 253 only 254 x x 255* x x * default value At the transmission mode 0, the PDOs will be transferred acyclic (event contlled, i.e. with the next SYNC). The sync object will be sent fm the master. At the time of the sync object, all inputs will be read and sent subsequently (in case of changing only). At the time of the sync object, the outputs will be updated on a value sent before. At the transmission modes the PDOs will be transferred resp. interpreted synchnous to each n th SYNC. The output devices write the output values to the outputs only on receipt of the nth SYNC - also when the values were transferred some earlier. The input devices read their inputs on receipt of the n th SYNC and send the corresponding PDO directly (SYNC Mode). The transmission mode 253 means that no PDOs will be transferred although an event is occurred. But the corresponding PDOs can be read out via RTR telegrams (RTR only). At the transmission mode 254 the transfer of a PDO will be released by a manufacturer specific event on the device (event mode). This is equivalent to the transmission mode 255. The transfer of a PDO in the transmission mode 255 will be released by an event described in the device pfile (Event Mode). At that adjustment, a time base can be used as the event additionally (timer driven). In this case, the timer for the time base will be adjusted via the sub index 5 of the apppriate communication object (SDO and SDO ). An occurred event triggers the timer once again Inhibit Time The content determines the time in 0.1 ms until it will be allowed to send a new PDO fm the module. This prevents the blocking of the bus if a module with high priority sends constantly a new PDO. The resolution in the internal software is 1 ms. Example: The value 122 means 12 ms Event Timer The content determines the time in ms after that a new PDO will be sent fm the module, at the latest. The input signals will be repeated cyclically in this way. A PDO will be sent immediately, and the timer will be reset if an input alteration appears, or a possible inhibit time is running off during the course of this time. 21 /39

22 The Pcess Data Object PDO 6.2 Mapping Parameters and Mapping Objects Mapping Parameters The mapping parameters determine the index, the sub index, and the length (in bits) of the mapped objects. SDO Sub Signification Data Type Value Access 1600H 00 1 st RxPDO Number of mapped objects 01 PDO-Mapping 1st byte digital outputs PDO-Mapping 8th byte digital outputs 1601H 00 2 nd RxPDO Number of mapped objects 01 PDO-Mapping 1st analog output PDO-Mapping 4th analog output 1602H 00 3 rd RxPDO Number of mapped objects 01 PDO-Mapping 5th analog output PDO-Mapping 8th analog output 1603H 00 4 th RxPDO Number of mapped objects 01 PDO-Mapping 9th analog output PDO-Mapping 12 th analog output Unsigned x00 or 0x x00 or 0x Unsigned x00 or 0x x00 or 0x Unsigned x00 or 0x x00 or 0x Unsigned x00 or 0x x00 or 0x /39

23 The Pcess Data Object PDO SDO Sub Signification Data Type Value Access 1A00H 00 1 st TxPDO Number of mapped objects 01 PDO-Mapping 1st byte digital inputs PDO-Mapping 8th byte digital inputs 1A01H 00 2 nd TxPDO Number of mapped objects 01 PDO-Mapping 1st analog input PDO-Mapping 4th analog input 1A02H 00 3 rd TxPDO Number of mapped objects 01 PDO-Mapping 5th analog input PDO-Mapping 8th analog input 1A03H 00 4 th TxPDO Number of mapped objects 01 PDO-Mapping 9th analog input PDO-Mapping 12 th analog input Unsigned x00 or 0x x00 or 0x Unsigned x00 or 0x x00 or 0x Unsigned x00 or 0x x00 or 0x Unsigned x00 or 0x x00 or 0x Sub index 1 to 8 value: 0xaaaa bb cc with: aaaa = index, bb = sub index, cc = number of bits The order of the data within the PDOs is defined by the assembly/wiring of the I/O modules. On the left (and at the top) are placed the low-order bytes. The data of the inputs will be transferred via the Transmit PDOs (TxPDO1 to TxPDO4). The digital inputs will be mapped at TxPDO1 and the analog inputs at TxPDO2 and TxPDO4. The data of the Receive PDOs (RxPDO1 to RxPDO4) will be mapped at outputs. The digital outputs are allocated to the RxPDO1 and the analog outputs to the RxPDO2 and RxPDO4. 23 /39

24 The Pcess Data Object PDO Mapping Objects The input and output data will be mapped fm these SDOs into the PDOs, and can be read and written also via SDO transfer. SDO Sub Meaning Data Type PDO Mapping Access 6000H 00 Number of bytes digital inputs Unsigned digital inputs 1 to 8 Unsigned 8 TxPDO digital inputs 57 to H 00 Number of bytes digital outputs Unsigned digital outputs 1 to 8 Unsigned 8 RxPDO1 rw 08 8 digital outputs 57 to H 00 Number of analog inputs Unsigned st analog input Unsigned 16 TxPDO th analog input 05 5 th analog input Unsigned 16 TxPDO th analog input 09 9 th analog input Unsigned 16 TxPDO th analog input 6411H 00 Number of analog outputs Unsigned 8 rw 01 1 st analog output Unsigned 16 RxPDO2 rw 04 4 th analog output 05 5 th analog output Unsigned 16 RxPDO3 rw 08 8 th analog output 09 9 th analog output Unsigned 16 RxPDO4 rw th analog output 24 /39

25 The Pcess Data Object PDO PDO Assignment Via the fixed mapping of the DIORAIL/DIOLINE20 Modules, the following PDO assignment is valid: 1st TxPDO (Send PDO for Digital Inputs 1-64) COB ID Byte 0 Byte 1 Byte 2 Byte node ID Input 1-8 Input 9-16 Input Input Digital Byte 4 Byte 5 Byte 6 Byte 7 Inputs Input Input Input Input LSB = 1 st input, MSB = 8 th input,... 2nd TxPDO (Send PDO for Analog Inputs 1-4) COB-ID Byte 0 Byte 1 Byte 2 Byte node ID Low byte channel 1 High byte channel 1 Low byte channel 2 High byte channel 2 Analog Byte 4 Byte 5 Byte 6 Byte 7 Digital Low byte channel 3 High byte channel 3 Low byte channel 4 High byte channel 4 3rd TxPDO (Send PDO for Analog Inputs 5-8) COB-ID Byte 0 Byte 1 Byte 2 Byte Node ID Lowbyte channel 5 Highbyte channel 5 Lowbyte channel 6 Highbyte channel 6 Analoge Byte 4 Byte 5 Byte 6 Byte 7 Eingänge Lowbyte channel Highbyte channel Lowbyte channel Highbyte channel th TxPDO (Send PDO for Analog Inputs 9-12) COB-ID Byte 0 Byte 1 Byte 2 Byte Node ID Lowbyte channel 9 Highbyte channel 9 Lowbyte channel 10 Highbyte channel 10 Analog Byte 4 Byte 5 Byte 6 Byte 7 Inputs Lowbyte channel Highbyte channel Lowbyte channel Highbyte channel /39

26 The Pcess Data Object PDO 1st RxPDO (Receive PDO for Digital Outputs 1-64) COB-ID Byte 0 Byte 1 Byte 2 Byte Node ID Output 1-8 Output 9-16 Output Output Digital Byte 4 Byte 5 Byte 6 Byte 7 Outputs Output Output Output Output LSB= 1 st input, MSB= 8 th input, 2nd RxPDO (Receive PDO for Analog Outputs 1-4) COB-ID Byte 0 Byte 1 Byte 2 Byte Node ID Lowbyte channel 1 Highbyte channel 1 Lowbyte channel 2 Highbyte channel 2 Analog Byte 4 Byte 5 Byte 6 Byte 7 Outputs Lowbyte channel Highbyte channel Lowbyte channel Highbyte channel rd RxPDO (Receive PDO for Analog Outputs 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 4th RxPDO (Receive PDO for Analog Outputs 9-12) COB-ID Byte 0 Byte 1 Byte 2 Byte Node ID Lowbyte channel 9 Highbyte channel 9 Lowbyte channel 10 Highbyte channel 10 Analog Byte 4 Byte 5 Byte 6 Byte 7 Outputs Lowbyte channel Highbyte channel Lowbyte channel Highbyte channel /39

27 The Emergency Object and Err Behavior 7 The Emergency Object and Err Behavior 7.1 The Emergency Telegram Client Server Request The emergency object is released in case of a fatal err situation in a device, and will be sent on the bus with a very high priority. If the reason of the err is removed, then an err telegram is again sent, and the corresponding bit will be reset. An alteration of the "Actual Bus State" does not result in an activation of the telegram. Only one time the err telegram will be sent per "Err Event", resp. if the err is deleted. The emergency telegram has a length of 8 bytes and includes a lot of err information. The structure of an emergency message is designed as follows: Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Err Message (Object 1003H) Err Register (Object 1001H) Manufacturer Status Register (Object 1002H) Empty The emergency telegram is built fm the following service data objects: SDO Sub Signification Data Type Value Access 1001H 00 Err register Unsigned 8 see below 1002H 00 Manufacturer status register see below 1003H 00 Number of err messages Unsigned 8 0x01 01 Err message see below 27 /39

28 The Emergency Object and Err Behavior 7.2 Err Register (Object 1001H) The object 1001H is a general err register. The device can map internal errs in this byte. 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 Value = 0: Value = 1: Man.Spec. Dev.Spec. Temp. Voltage Current Comm. Generic No err Err Specific manufacturer err, specified in object 1002H Err flag, device specific (not in use) Module temperature monitoring (not in use) e.g. input voltage outside of valid range (not in use) e.g. overload at outputs Communication err Not specified, set for each err message 28 /39

29 The Emergency Object and Err Behavior 7.3 Manufacturer Status Register (Object 1002H) The object 1002H includes the actual manufacturer-specific status of the module. LSByte MSByte Status Byte 1 Status Byte 2 Status Byte 3 Status Byte 4 MSBit Byte 1 ShortC ComE OrE SubCom LSBit Byte 2 InFM OutFM MemE Byte 3 Actual Bus State Byte 4 Value = 0: Value = 1: no err corresponding err Table of the Err Codes ShortC ComE OrE SubCom AInFM AOutFM InFM OutFM MemE Actual Bus State Short circuit at the digital outputs Communication err (CAN warning limit is exceeded) CAN overrun err (CAN loss of data) Communication err L-Bus module(s) Analog inputs within err mode Analog outputs within err mode Digital inputs within err mode Digital outputs within err mode Err within the non-volatile memory (EEPROM) 0x7F for Pre-Operational 0x05 for Operational Actual CAL state of the node (according to state in the CAL node guarding telegram) 29 /39

30 The Emergency Object and Err Behavior 7.4 Err Message (Object H) The object H includes the emergency err code according to DS301. Value Signification Additional Information 00,00H No err, err removed 21,xxH 1) Current (input side) E.g. short circuit sensor supply 23,xxH 1) Current (output side) E.g. short circuit actuator output 63,xxH Storage data Err EEPROM 70,xxH 1) Expansion modules Err internal expansion bus 81,xxH Communication Err within the CAN communication 50,01H Hardware err analog input module Err code leaned on DS301 50,02H Hardware err analog output module Err code leaned on DS301 1) will be used only at corresponding hardware implementation 30 /39

31 The Emergency Object and Err Behavior 7.5 Err Behavior of the Module Object 1029H (err behavior) defines the reaction of the module to the following err situations: Communication err (CAN communication resp. guarding/heartbeat violation) Err on the output (short circuit) Err on the input. SDO Sub Signification Data Type Value Access 1029H 00 Largest supported sub index Unsigned Err behavior at communication err Unsigned rw 02 Err behavior at output err Unsigned rw 03 Err behavior at input err Unsigned rw 04 Saving of err status Unsigned rw Between the following err reactions can be selected (valid fur sub index 01 03): Value: 0 Return back to the "pre-operational" condition (default) 1 No condition change 2 Transfer into the stopped condition If storing the err status active, the first occurred err will be stored in the objects 1001h 1003h. The err will be set back fm pre-operational to operational. A one-time signalization per err will be occur via an EMCY message. If storing the err status inactive, every occurring err type will be signalized via an EMC message. If all errs of an err type are solved in the system a further signalization via an EMCY message occurs. Value: 0 Active storing of the err status (err freeze on default) 1 Inactive storing of the err status (err freeze off) 31 /39

32 The Emergency Object and Err Behavior Err Behavior of the Digital Outputs The state which takes a digital output at an err situation can be defined with the objects 6206H err mode: Value Bit 0 to 7: 0 Retained condition 1 Accept value of 6207H (Default) and 6207H err value: Value Bit 0 to 7: 0 Shut off output (default) 1 Turn on output can be set, which condition is to take a digital output in the err situation. Via a state alteration to operational, or sending the NMT command Start Remote Node, it is possible to pass the err state. The outputs assume again the last adjusted state. SDO Sub Signification Data Type Value Access 6206H 00 Largest supported sub index Unsigned Err mode outputs 1 to 8 Unsigned 8 0-0xFF rw Err mode outputs 57 to H 00 Largest supported sub index Unsigned Err value outputs 1 to 8 Unsigned 8 0-0xFF rw Err value outputs 57 to /39

33 The Emergency Object and Err Behavior Err Behavior of the Analog Outputs The state which takes an analog output at an err situation can be defined with the objects 6443H err mode: Value: 0 Condition retained 1 Accept value of 6444H (default) and 6444H err value: Value: 0 to 0 = default value 0xaaaa aaaa = output value can be set, which condition is to take a analog output in the err situation. Via a state alteration to Operational or sending the NMT command "Start Remote Node it is possible to pass the err state. The outputs again assume the last adjusted state. Signification Data Type Value Access SDO Sub 6443H 00 Largest supported sub index Unsigned Err mode analog output 1 Unsigned rw Err mode analog output H 00 Largest supported sub index Unsigned Err value analog output 1 Unsigned xFFFF rw Err value analog output /39

34 Storage of Parameters 8 Storage of Parameters After the first switch-on the CANopen devices assume a default configuration. All relevant communication and device parameters will be reset on the standard value (default value). For specification see CANopen standard CiA DS 301. All needed parameters of a node are stored in a serial EEPROM. After the next switch-on or after a reset the corresponding configuration is available again. At an alteration the parameters Node ID SDO 2000 and CAN baud rate SDO 2001 will be stored immediately via SDO. All other parameters needs to stored explicit via the object 1010H. By using of the object 1011H the device can be reset on the default parameters. The default parameters are active after the reset. SDO Sub Signification Data Type Value Access 1010H 00 Largest supported sub index Unsigned Storage of all parameters ASCII save rw 02 Storage of the communication ASCII save rw parameters 03 Storage of the application parameters ASCII save rw 04 Storage of the manufacturer specific ASCII save rw parameters 1011H 00 Largest supported sub index Unsigned Load of all default parameters ASCII load rw 02 Load of the default communication ASCII load rw parameters 03 Load of the default application parameters 04 Load of the default manufacturer specific parameters ASCII load rw ASCII load rw Communication parameter Manufacturer-specific parameter Applicatin parameter SDO 1000 to 1FFF SDO 2000 to 5FFF SDO 6000 to 6FFF 34 /39

35 Failure Monitoring 9 Failure Monitoring The functions node guarding resp. the pducer heartbeat are available for the failure monitoring of a CAN node. The life guarding resp. the consumer heartbeat will be used for the monitoring of different CAN partners. i Note: Either the guarding or the heartbeat can be active. SDO Sub Signification Data Type Value Access 100CH 00 Guard time Unsigned 16 0xbb bb rw 100DH 00 Life time factor Unsigned rw 1016H 00 Number of items 0x01 rw 01 Consumer heartbeat time 0x00 aa bb bb rw 1017H 00 Pducer heartbeat time Unsigned 16 0xbb bb rw aa = Node ID of the monitored participant bb bb = Time in ms 35 /39

36 Failure Monitoring 9.1 Node Guarding / Life Guarding Master Request Response Slave At the node guarding the master sends "Remote-Frames" to the slaves, which have to be monitored. The slaves answer with the guarding message. The message includes the CAL status of the slave and a toggle bit, which have to be changed after each message. If the status or the toggle bit have different values as fm the NMT master expected, or if no answer comes after the defined time then the master will be interpreted the situation as a slave err. At the life guarding (which starts with the first received remote frame) the slave expects a new remote frame within the life time (= guard time x life time factor). Otherwise the slave will be interpreted a master err and an err reaction will be initiated. 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 Figure 3: Node Guarding / Life Guarding After the initialization the devices send a guarding telegram to detect the readiness for working resp. the existence of the device after the boot-up. The sender of the telegram can be detected via the identifier. 36 /39

37 Failure Monitoring 9.2 Heartbeat Failure Monitoring The heartbeat ptocol is not using remote frames in contrast to the guarding ptocol. The heartbeat pducer sends a heartbeat message (cyclic in the interval of the heartbeat pducer timer), which will be received, fm the heartbeat consumers. If a heartbeat consumer receives no additional heartbeat messages within the heartbeat consumer time then the failure monitoring (heartbeat event) will be activated. The heartbeat ptocol starts with the first heartbeat message at the alteration fm the state Initialization into the state Pre-Operational. If one or all heartbeat times are pgrammed with a ze then the corresponding heartbeat message generation resp. the heartbeat message monitoring will not be activated. 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 Figure 4: Heartbeat Failure Monitoring The heartbeat failure monitoring has to be preferred at new applications. 37 /39

38 Behavior of the Inputs and Outputs 10 Behavior of the Inputs and Outputs Behavior of the Digital Inputs An alteration on a digital input will be used as event to activate a pcess data message (PDO) in the state "Operational" at corresponding adjusted transmission mode. Behavior of the Digital Outputs New pcess data (PDO) for a digital output result in an alteration on the respective output in the state "Operational" at corresponding adjusted transmission mode. In the state "Pre-Operational" an output can be defined also via a service data message (SDO). Behavior of the Analog Inputs With the object 6462H (interrupt analog input, delta positive/negative) will be defined the value of the alteration on an analog input. The overflow of this value releases a new event. In the state "Operational" a new pcess data message (PDO) will be released at corresponding adjusted transmission mode. Signification Data Type SDO Sub Default Value 6426H 00 Largest supported sub index Unsigned Delta value analog input 1 Unsigned xFFFF rw 12 Delta value analog input 12 Access Behavior of the Analog Outputs New pcess data (PDO) for an analog output result in an alteration on the respective output in the state "Operational" at corresponding adjusted transmission mode. In the state "Pre-Operational" an output can be defined also via a service data message (SDO). 38 /39

39 Change History 11 Change History Version Change 2.0 June 2003 Draft 2.10 Jan (Title) Inhabit Inhibit (FB CANopen) of the PDOs to, of the for data transmission...(fb CANopen) 9 Entry in Table must be 1017H 00 Pducer Note on DS 301 V4.00 removed data type Unsigned 8 instead of compatiblity note added 11 Change history added 7.3 Remove err codes for analog inputs and outputs. Digital input and output effers described as general input/output errs April 2008 Pduct family DIORAIL DIORAIL/DIOLINE April 2014 New service data objects chapter Service Dta Objects with Device Information 2.40 March 2015 Supplements in chapter Err Behavior of the Module and L-Bus Statusbyte 39 /39