You are on page 1of 207

CAN in Automation e. V.

CANopen
Application Layer and Communication Profile

CiA Draft Standard 301

Version 4.0 Date: 16.6.1999

History

CANopen

CiA

History
Date June 1999 Changes Document completely revised; Summary of major changes: Object Dictionary structure reviewed Object services and NMT services included (former in CiA DS-201 .. CiA DS-207 specified) Data type definitions included (former in CiA DS-201 .. CiA DS-207 specified) and extended Boot Up Message specified Optional Heartbeat specified Additional Emergency error codes specified Additional SDO abort codes specified Timer-driven PDO transmission specified PDO Communication parameter enhanced PDO Mapping procedure clarified SDO Block transfer specified Pre-defined Identifier set extended

ii

CONTENTS

CANopen

CiA

CONTENTS
CONTENTS ................................................................................................................................... III 1 2 3 4 4.1 4.2 5 5.1 6 6.1 6.2 TABLES ............................................................................................................................1-1 FIGURES ..........................................................................................................................2-1 SCOPE ..............................................................................................................................3-1 REFERENCES..................................................................................................................4-1 Normative references ..................................................................................................4-1 Informative references.................................................................................................4-1 DEFINITIONS AND ABBREVIATIONS ......................................................................5-1 Abbreviations ...............................................................................................................5-1 MODELING.......................................................................................................................6-1 Reference Model .........................................................................................................6-1 Device Model ..............................................................................................................6-2 6.2.1 6.2.2 6.3 General ..............................................................................................................6-2 The Object Dictionary .......................................................................................6-3

Communication Model................................................................................................6-4 6.3.1 6.3.2 6.3.3 Master/Slave relationship .................................................................................6-5 Client/Server relationship..................................................................................6-6 Producer/Consumer relationship - Pull/Push model .......................................6-6

7 7.1 7.2 8 8.1 9 9.1

PHYSICAL LAYER ........................................................................................................7-1 Transceiver ..................................................................................................................7-1 Bit rates and timing......................................................................................................7-1 DATA LINK LAYER .....................................................................................................8-1 CAN Frame Type.........................................................................................................8-1 APPLICATION LAYER ..................................................................................................9-1 Data Types and Encoding Rules ................................................................................9-1 9.1.1 9.1.2 General Description of Data Types and Encoding Rules................................9-1 Data Type Definitions........................................................................................9-1 iii

CONTENTS 9.1.3 9.1.4 9.1.5 9.1.6 9.2

CANopen Bit Sequences ...................................................................................................9-2 Basic Data Types ..............................................................................................9-3 Compound Data Types.....................................................................................9-6 Extended Data Types .......................................................................................9-6

CiA

Communication Objects ..............................................................................................9-7 9.2.1 9.2.2 9.2.3 9.2.4 9.2.5 9.2.6 Process Data Object (PDO) .............................................................................9-7 Service Data Object (SDO) ............................................................................9-11 Synchronisation Object (SYNC) .....................................................................9-36 Time Stamp Object (TIME).............................................................................9-37 Emergency Object (EMCY) ............................................................................9-38 Network Management Objects .......................................................................9-41

9.3

Synchronisation of the SYNC Consumer .................................................................9-49 9.3.1 9.3.2 Transmission of Synchronous PDO Messages .............................................9-49 Optional High Resolution Synchronisation Protocol......................................9-50

9.4

Network Initialisation and System Boot-Up ..............................................................9-52 9.4.1 9.4.2 9.4.3 Initialisation Procedure ...................................................................................9-52 NMT State Machine ........................................................................................9-52 Pre-Defined Connection Set...........................................................................9-55

9.5

Object Dictionary .......................................................................................................9-56 9.5.1 9.5.2 9.5.3 9.5.4 General Structure of the Object Dictionary ....................................................9-56 Dictionary Components ..................................................................................9-58 Data Type Entry Specification ........................................................................9-58 Specification of Predefined Complex Data Types .........................................9-60

9.6

Communication Profile Specification ........................................................................9-61 9.6.1 9.6.2 9.6.3 Detailed Object Specification..........................................................................9-61 Overview Object Dictionary Entries for Communication ...............................9-62 Detailed Specification of Communication Profile specific Objects................9-64

10 11

IMPLEMENTATION RECOMMENDATIONS .............................................................10-1 INDEX..............................................................................................................................11-1

iv

TABLES

CANopen

CiA

1 TABLES
Table 1: Object Dictionary Structure...........................................................................................6-3 Table 2: Recommended Bit Timing Settings..............................................................................7-1 Table 3: Write PDO .....................................................................................................................9-9 Table 4: Read PDO .....................................................................................................................9-9 Table 5: SDO Download........................................................................................................... 9-13 Table 6: Initiate SDO Download............................................................................................... 9-13 Table 7: Download SDO Segment........................................................................................... 9-14 Table 8: SDO Upload ............................................................................................................... 9-14 Table 9: Initiate SDO Upload ................................................................................................... 9-15 Table 10: Upload SDO Segment ............................................................................................. 9-15 Table 11: Abort SDO Transfer ................................................................................................. 9-15 Table 12: SDO Block Download .............................................................................................. 9-16 Table 13: Initiate SDO Block Download .................................................................................. 9-16 Table 14: Download SDO Block .............................................................................................. 9-17 Table 15: End SDO Block Download....................................................................................... 9-17 Table 16: SDO Block Upload ................................................................................................... 9-18 Table 17: Initiate SDO Block Upload ....................................................................................... 9-18 Table 18: Upload SDO Block ................................................................................................... 9-19 Table 19: End SDO Block Upload ........................................................................................... 9-19 Table 20: SDO abort codes...................................................................................................... 9-26 Table 21: Emergency Error Codes .......................................................................................... 9-38 Table 22: Start Remote Node .................................................................................................. 9-41 Table 23: Stop Remote Node .................................................................................................. 9-41 Table 24: Enter Pre-Operational.............................................................................................. 9-41 Table 25: Reset Node .............................................................................................................. 9-42 Table 26: Reset Communication ............................................................................................. 9-42 Table 27: Node Guarding Event .............................................................................................. 9-43 Table 28: Life Guarding Event ................................................................................................. 9-43 Table 29: Heartbeat Event ....................................................................................................... 9-43 Table 30: Bootup Event............................................................................................................ 9-43 Table 31: Trigger for State Transition...................................................................................... 9-53 Table 32: States and Communication Objects........................................................................ 9-55 Table 33: Broadcast Objects of the Pre-defined Connection Set........................................... 9-56 Table 34: Peer-to-Peer Objects of the Pre-defined Connection Set ...................................... 9-56 Table 35: Format of Object Dictionary Headings .................................................................... 9-56 Table 36: Object Dictionary Object Definitions........................................................................ 9-57 Table 37: Access Attributes for Data Objects ......................................................................... 9-57 Table 38: Object Dictionary Data Types.................................................................................. 9-58 Table 39: complex data type example..................................................................................... 9-60 Table 40: PDO Communication Parameter Record................................................................ 9-60 1-1

TABLES

CANopen

CiA

Table 41: PDO Mapping Parameter Record ........................................................................... 9-61 Table 42: SDO Parameter Record........................................................................................... 9-61 Table 43: Identity Record ......................................................................................................... 9-61 Table 44: Format of an Object Description.............................................................................. 9-61 Table 45: Object Value Description Format ............................................................................ 9-62 Table 46: Standard Objects ..................................................................................................... 9-62 Table 47: Structure of the Error Register ................................................................................ 9-65 Table 48: Description of SYNC COB-ID entry......................................................................... 9-67 Table 49: Structure of read access.......................................................................................... 9-71 Table 50: Structure of restore read access ............................................................................. 9-73 Table 51: Description of TIME COB-ID entry .......................................................................... 9-75 Table 52: Description of SDO COB-ID entry........................................................................... 9-80 Table 53: Description of PDO COB-ID entry........................................................................... 9-83 Table 54: Description of transmission type ............................................................................. 9-83

1-2

FIGURES

CANopen

CiA

2 FIGURES
Figure 1: Reference Model..........................................................................................................6-1 Figure 2: Service Types ..............................................................................................................6-2 Figure 3: Device Model ...............................................................................................................6-3 Figure 4: Unconfirmed Master Slave Communication ...............................................................6-5 Figure 5: Confirmed Master Slave Communication ...................................................................6-5 Figure 6: Client/Server Communication......................................................................................6-6 Figure 7: Push model ..................................................................................................................6-6 Figure 8: Pull model.....................................................................................................................6-6 Figure 9: Transfer Syntax for Bit Sequences .............................................................................9-3 Figure 10: Transfer syntax for data type UNSIGNEDn..............................................................9-4 Figure 11: Transfer syntax for data type INTEGERn.................................................................9-4 Figure 12: Transfer syntax of data type REAL32.......................................................................9-5 Figure 13: Synchronous and Asynchronous Transmission .......................................................9-8 Figure 14: Write PDO Protocol ................................................................................................ 9-10 Figure 15: Read PDO Protocol ................................................................................................ 9-10 Figure 16: Download SDO Protocol......................................................................................... 9-20 Figure 17: Initiate SDO Download Protocol ............................................................................ 9-21 Figure 18: Download SDO Segment Protocol......................................................................... 9-22 Figure 19: Upload SDO Protocol ............................................................................................. 9-23 Figure 20: Initiate SDO Upload Protocol ................................................................................. 9-24 Figure 21: Upload SDO Segment Protocol ............................................................................. 9-25 Figure 22: Abort SDO Transfer Protocol ................................................................................. 9-26 Figure 23: SDO Block Download Protocol .............................................................................. 9-28 Figure 24: Initiate SDO Block Download Protocol .................................................................. 9-29 Figure 25: Download SDO Block Segment ............................................................................. 9-30 Figure 26: End SDO Block Download Protocol....................................................................... 9-31 Figure 27: Upload SDO Block Protocol ................................................................................... 9-32 Figure 28: Initiate SDO Block Upload Protocol ....................................................................... 9-33 Figure 29: Upload SDO Block Segment Protocol ................................................................... 9-34 Figure 30: End SDO Block Upload Protocol ........................................................................... 9-35 Figure 31: SYNC Protocol........................................................................................................ 9-36 Figure 32: TIME Protocol ......................................................................................................... 9-37 Figure 33: Emergency State Transition Diagram.................................................................... 9-39 Figure 34: Emergency Object Data ......................................................................................... 9-39 Figure 35: Emergency Object Protocol.................................................................................... 9-40 Figure 36: Start Remote Node Protocol .................................................................................. 9-44 Figure 37: Stop Remote Node Protocol................................................................................... 9-44 Figure 38: Enter Pre-Operational Protocol .............................................................................. 9-45 Figure 39: Reset Node Protocol............................................................................................... 9-45 Figure 40: Reset Communication Protocol.............................................................................. 9-46 2-1

FIGURES

CANopen

CiA

Figure 41: Node Guarding Protocol ......................................................................................... 9-47 Figure 42: Heartbeat Protocol.................................................................................................. 9-48 Figure 43: Bootup Protocol ...................................................................................................... 9-49 Figure 44: Bus Synchronisation and Actuation ....................................................................... 9-50 Figure 45: Bus Synchronisation and Sampling ....................................................................... 9-50 Figure 46: Optional High Resolution Synchronisation Protocol ............................................. 9-51 Figure 47: Flow Chart of the Network Initialisation Process................................................... 9-52 Figure 48: State Diagram of a Device ..................................................................................... 9-53 Figure 49: Structure of the Initialisation state.......................................................................... 9-54 Figure 50: Identifier allocation scheme for the pre-defined connection set ........................... 9-56 Figure 51: structure sub-index FFh.......................................................................................... 9-60 Figure 52: Structure of the Device Type Parameter ............................................................... 9-64 Figure 53: Structure of the pre-defined error field................................................................... 9-65 Figure 54: Structure of SYNC COB-ID entry........................................................................... 9-66 Figure 55: Storage write access signature .............................................................................. 9-70 Figure 56: Storage read access structure ............................................................................... 9-70 Figure 57: Restoring write access signature ........................................................................... 9-72 Figure 58: restore procedure ................................................................................................... 9-73 Figure 59: Restoring default values read access structure .................................................... 9-73 Figure 60: Structure of TIME COB-ID entry ............................................................................ 9-74 Figure 61: Structure of the EMCY Identifier entry ................................................................... 9-76 Figure 62: Structure of Consumer Heartbeat Time entry ....................................................... 9-77 Figure 63: Structure of Revision number................................................................................. 9-78 Figure 64: Structure of SDO COB-ID entry ............................................................................. 9-79 Figure 65: Structure of PDO COB-ID entry ............................................................................. 9-83 Figure 66: Structure of PDO Mapping Entry ........................................................................... 9-86 Figure 67: Principle of PDO mapping ...................................................................................... 9-86

2-2

SCOPE

CANopen

CiA

3 SCOPE
This Part of prEN 50325 specifies the following particular requirements for CANopen: (1) Requirements for interfaces between controllers and switching elements; (2) Normal service conditions for devices; (3) Constructional and performance requirements.

3-1

REFERENCES

CANopen

CiA

4 REFERENCES
4.1 Normative references prEN 50325-1: 199X ISO 11898 (CAN)-based Controller-device interfaces Part 1: General requirements ISO 7498-1: 1994 ISO 8859: 1998 ISO 11898: 1993 ISO 646: 1991 4.2 Information technology - Open Systems Interconnection - Basic Reference Model: The Basic Model Information technology - 8-bit single-byte coded graphic character sets Road vehicles - Interchange of digital information - Controller area network (CAN) for high-speed communication Information technology - ISO 7-bit coded character set for information interchange

Informative references

IEEE 754: 1985 Standard for binary floating-point arithmetic

4-1

DEFINITIONS AND ABBREVIATIONS

CANopen

CiA

5 DEFINITIONS AND ABBREVIATIONS


5.1 Abbreviations ARQ: Automatic Repeat Request. CAN: Controller Area Network is an internally standardized serial bus system.. COB: Communication Object. A unit of transportation in a CAN network. Data must be sent across a CAN Network inside a COB. There are 2048 different COB's in a CAN network. A COB can contain at most 8 bytes of data. COB-ID: Each COB is uniquely identified in a CAN network by a number called the COB Identifier (COB-ID). The COB-ID determines the priority of that COB for the MAC sub-layer. Remote COB: A COB whose transmission can be requested by another device. CRC: Cyclic Redundancy Check. CSDO: Client SDO. LLC: Logical Link Control. One of the sub-layers of the Data Link Layer in the CAN Reference Model that gives the user an interface that is independent from the underlying MAC layer. MAC: Medium Access Control. One of the sub-layers of the Data Link Layer in the CAN Reference Model that controls who gets access to the medium to send a message. MDI: Medium Dependent Interface. One of the sub-layers of the Physical Layer in the CAN Reference Model that specifies the mechanical and electrical interface between the medium and a module. NMT: Network Management. One of the service elements of the application layer in the CAN Reference Model. The NMT serves to configure, initialise, and handle errors in a CAN network. OSI: Open Systems Interconnection. PDO: Process Data Object. PLS: Physical Layer Signalling. One of the sub-layers of the Physical Layer in the CAN Reference Model that specifies the bit representation, timing and synchronisation. PMA: Physical Medium Attachment. One of the sub-layers of the Physical Layer in the CAN Reference Model that specifies the functional circuitry for bus line transmission/reception and may provide means for failure detection. RPDO: Receive PDO.

5-1

DEFINITIONS AND ABBREVIATIONS SDO: Service Data Object. SSDO: Server SDO. SYNC: Synchronisation Object. TPDO: Transmit PDO.

CANopen

CiA

5-2

MODELING

CANopen

CiA

6 MODELING
CAN-based networks use the following reference model, device model, and communication model. 6.1 Reference Model Application Process

Application

Application (1)

Presentation Session Transport Network

Datalink

LLC MAC PLS PMA MDI (2)

Physical

(2)

(1) specified in this document (2) specified in ISO 11898

Figure 1: Reference Model The communication concept can be described similar to the ISO-OSI Reference Model (left side of figure). Application Layer: The Application Layer comprises a concept to configure and communicate real-time-data as well as the mechanisms for synchronization between devices. The functionality the application layer offers to an application is logically divided over different service objects in the application layer. A service object offers a specific functionality and all the related services. These services are described in the Service Specification of that service object. Applications interact by invoking services of a service object in the application layer. To realize these services, this object exchanges data via the CAN Network with (a) peer service object(s) via a protocol. This protocol is described in the Protocol Specification of that service object. Service Primitives: Service primitives are the means by which the application and the application layer interact. There are four different primitives: a request is issued by the application to the application layer to request a service an indication is issued by the application layer to the application to report an internal event detected by the application layer or indicate that a service is requested

6-1

MODELING

CANopen

CiA

a response is issued by the application to the application layer to respond to a previous received indication a confirmation is issued by the application layer to the application to report the result of a previously issued request.

Application Layer Service Types

Application X
request

Application X
indication

Local Service

Provider Initiated Service

Application X

Application Y, Z, ..
indication indication indication

Application X
request

Application Y
indication

confirmation

response

Unconfirmed Service
Figure 2: Service Types

Confirmed Service

A service type defines the primitives that are exchanged between the application layer and the cooperating applications for a particular service of a service object. A local service involves only the local service object. The application issues a request to its local service object that executes the requested service without communicating with (a) peer service object(s). An unconfirmed service involves one or more peer service objects. The application issues a request to its local service object. This request is transferred to the peer service object(s) that each pass it to their application as an indication. The result is not confirmed back. A confirmed service can involve only one peer service object. The application issues a request to its local service object. This request is transferred to the peer service object that passes it to the other application as an indication. The other application issues a response that is transferred to the originating service object that passes it as a confirmation to the requesting application. A provider initiated service involves only the local service object. The service object (being the service provider) detects an event not solicited by a requested service. This event is then indicated to the application. Device Model General

Unconfirmed and confirmed services are collectively called remote services. 6.2 6.2.1

A device is structured like the following (see Figure 3): Communication This function unit provides the communication objects and the appropriate functionality to transport data items via the underlying network structure. Object Dictionary The Object Dictionary is a collection of all the data items which have an influence on the behavior of the application objects, the communication objects and the state machine used on this device. Application The application comprises the functionality of the device with respect to the interaction with the process environment. 6-2

MODELING

CANopen

CiA

Thus the Object Dictionary serves as an interface between the communication and the application. The complete description of a devices application with respect to the data items in the Object Dictionary is named device profile. Object Dictionary Application

Communication

State machine

Application object Entry 1 Entry 2 : Application object

Comm. object Comm. object

Comm. object Entry n Comm. object

Application object

Application object

Bus system

Process

Figure 3: Device Model 6.2.2 The Object Dictionary

The most important part of a device profile is the Object Dictionary description. The Object Dictionary is essentially a grouping of objects accessible via the network in an ordered pre-defined fashion. Each object within the dictionary is addressed using a 16-bit index. The overall layout of the standard Object Dictionary is shown below. This layout closely conforms with other industrial serial bus system concepts: Table 1: Object Dictionary Structure Index (hex) 0000 0001-001F 0020-003F 0040-005F 0060-007F 0080-009F 00A0-0FFF 1000-1FFF 2000-5FFF 6000-9FFF A000-FFFF Object not used Static Data Types Complex Data Types Manufacturer Specific Complex Data Types Device Profile Specific Static Data Types Device Profile Specific Complex Data Types Reserved for further use Communication Profile Area Manufacturer Specific Profile Area Standardised Device Profile Area Reserved for further use

The Object Dictionary may contain a maximum of 65536 entries which are addressed through a 16-bit index.

6-3

MODELING

CANopen

CiA

The Static Data Types at indices 0001h through 001Fh contain type definitions for standard data types like BOOLEAN, INTEGER, floating point, string, etc. These entries are included for reference only, they cannot be read or written. Complex Data Types at indices 0020h through 003Fh are pre-defined structures that are composed of standard data types and are common to all devices. Manufacturer Specific Complex Data Types at indices 0040h through 005Fh are structures composed of standard data types but are specific to a particular device. Device Profiles may define additional data types specific to their device type. The static data types defined by the device profile are listed at indices 0060h - 007Fh, the complex ones at indices 0080h 009Fh. A device may optionally provide the structure of the supported complex data types (indices 0020h 005Fh and 0080h - 009Fh) at read access to the corresponding index. Sub-index 0 then provides the number of entries at this index, and the following sub-indices contain the data type encoded as UNSIGNED16 according to Table 38. The Communication Profile Area at indices 1000h through 1FFFh contains the communication specific parameters for the CAN network. These entries are common to all devices. The standardised device profile area at indices 6000h through 9FFFh contains all data objects common to a class of devices that can be read or written via the network. The device profiles may use entries from 6000h to 9FFFh to describe the device parameters and the device functionality. Within this range up to 8 different devices can be described. In such a case the devices are denominated Multiple Device Modules. Multiple Device Modules are composed of up to 8 device profile segments. By this feature it is possible to build devices with multiple functionality. The different device profile entries are shifted with 800h. For Multiple Device Modules the object range 6000h to 67FFh is shifted as follows: 6000h to 67FFh device 0 6800h to 6FFFh 7000h to 77FFh 7800h to 7FFFh 8000h to 87FFh 8800h to 8FFFh device 1 device 2 device 3 device 4 device 5

9000h to 97FFh device 6 9800h to 9FFFh device 7 The PDO distribution shall be used for every segment of a Multiple Device Module with an offset of 64, e.g. the first PDO of the second segment gets the number 65. In this way a system with a maximum of 8 segments is supported. The Object Dictionary concept caters for optional device features which means a manufacturer does not have to provide certain extended functionality on his devices but if he wishes to do so he must do it in a pre-defined fashion. Space is left in the Object Dictionary at indices 2000h through 5FFFh for truly manufacturer-specific functionality. 6.2.2.1 Index and Sub-Index Usage A 16-bit index is used to address all entries within the Object Dictionary. In case of a simple variable the index references the value of this variable directly. In case of records and arrays however, the index addresses the whole data structure. To allow individual elements of structures of data to be accessed via the network a sub-index is defined. For single Object Dictionary entries such as an UNSIGNED8, BOOLEAN, INTEGER32 etc. the value for the sub-index is always zero. For complex Object Dictionary entries such as arrays or records with multiple data fields the sub-index references fields within a data-structure pointed to by the main index. The fields accessed by the sub-index can be of differing data types. 6.3 Communication Model

The communication model specifies the different communication objects and services and the available modes of message transmission triggering. The communication model supports the transmission of synchronous and asynchronous messages. By means of synchronous message transmission a network wide coordinated data acquisition and actuation is possible. The synchronous transmission of messages is supported by pre-defined communication objects (Sync message, time stamp message). Synchronous messages are transmitted with respect to a pre-defined synchronization message, asynchronous message may be transmitted at any time. 6-4

MODELING

CANopen

CiA

Due to the event character of the underlying communication mechanism it is possible to define inhibit times for the communication. To guarantee that no starvation on the network occurs for data objects with low priorities, data objects can be assigned an inhibit time. The inhibit-time of a data object defines the minimum time that has to elapse between two consecutive invocations of a transmission service for that data object. Inhibit-times can be assigned by the application. With respect to their functionality, three types of communication relationships are distinguished Master/Slave relationship (Figure 4 and Figure 5) Client/Server relationship (Figure 6) Producer/Consumer relationship (Figure 7 and Figure 8) 6.3.1 Master/Slave relationship

At any time there is exactly one device in the network serving as a master for a specific functionality. All other devices in the network are considered as slaves. The master issues a request and the addressed slave(s) respond(s) if the protocol requires this behavior.

Master

Slaves
indication

request

indication

data

indication

Figure 4: Unconfirmed Master Slave Communication

Master
request Remote Transmit Request

Slave
indication

confirmation

data

response

Figure 5: Confirmed Master Slave Communication

6-5

MODELING 6.3.2 Client/Server relationship

CANopen

CiA

This is a relationship between a single client and a single server. A client issues a request (upload/download) thus triggering the server to perform a certain task. After finishing the task the server answers the request.

Client
request

Server
indication

data

confirmation

data

response

Figure 6: Client/Server Communication 6.3.3 Producer/Consumer relationship - Pull/Push model

The producer/consumer relationship model involves a producer and zero or more consumer(s). The push model is characterized by an unconfirmed service requested by the producer. The pull model is characterized by a confirmed service requested by the consumer.

Producer

Consumers
indication

request

indication

data

indication

Figure 7: Push model

Producer
indication Remote Transmit Request

Consumers
request request request

response

data

confirmation indication indication

Figure 8: Pull model

6-6

PHYSICAL LAYER

CANopen

CiA

7 PHYSICAL LAYER
The physical medium for devices is a differentially driven two-wire bus line with common return according to high-speed transmission specification in ISO 11898. 7.1 Transceiver Using the high-speed transceiver according to ISO 11898 the maximum rating for VCAN_H and VCAN_L shall be +16V. Galvanic isolation between bus nodes is optional. It is recommended to use a transceiver that is capable of sustaining mis-connection of any of the wires of the connector including the optional V+ voltages of up to 30V. 7.2 Bit rates and timing
(4)

The recommended bit rates and corresponding bit timing recommendations One of these bit rates has to be supported. Table 2: Recommended Bit Timing Settings Bit rate Bus length 1 Mbit/s 25 m 800 kbit/s 50 m 500 kbit/s 100 m 250 kbit/s (2) 250 m 125 kbit/s (2) 500 m 50 kbit/s (3) 1000 m 20 kbit/s (3) 2500 m 10 kbit/s (3) 5000 m
(1)

are listed in Table 2.

Nominal bit time tb 1 ms 1,25 ms 2 ms 4 ms 8 ms 20 ms 50 ms 100 ms

Number of time quanta per bit 8 10 16 16 16 16 16 16

Length of time quantum tq 125 ns 125 ns 125 ns 250 ns 500 ns 1,25 ms 3,125 ms 6,25 ms

Location of sample point 6 tq


(750 ns) (1 ms) (1,75 ms) (3,5 ms) (7 ms) (17,5 ms) (43,75 ms) (87,5 ms)

8 tq

14 tq 14 tq 14 tq 14 tq 14 tq

14 tq

The table entries are an example based on the follow acceptance: Oscillator frequency 16 MHz +/-0.1% (1000 ppm) Sampling mode Single sampling Synchronisation mode Recessive to dominant edges only Synchronisation jump width 1 * tq Phase Segment 2 2 * tq Note 1:

SAM = 0 SYNC = 0 SJW = 0 TSEG2 = 1

Note 2:

Note 3:

Rounded bus length estimation (worst case) on basis 5 ns/m propagation delay and a total effective device internal in-out delay as follows: 1M - 800 kbit/s: 210 ns 500 - 250 kbit/s: 300 ns (includes 2 * 40 ns for optocouplers) 125 kbit/s: 450 ns (includes 2 * 100 ns for optocouplers) 50 - 10 kbit/s: 1,5 tq; Effective delay = delay recessive to dominant plus dominant to recessive divided by two. For bus length greater than about 200 m the use of optocouplers is recommended. If optocouplers are placed between CAN controller and transceiver this affects the maximum bus length depending upon the propagation delay of the optocouplers i.e. -4m per 10 ns propagation delay of employed optocoupler type. For bus length greater than about 1 km bridge or repeater devices may be needed.

7-1

PHYSICAL LAYER Note 4

CANopen

CiA

The bit timings in the table are calculated for an oscillator frequency of 16 MHz. If another oscillator is used the number of time quanta may be different. Nevertheless the location of the sample point shall be as near as possible at the recommended sample point.

7-2

DATA LINK LAYER

CANopen

CiA

8 DATA LINK LAYER


The described networks are based on a data link layer and its sub-layers according to ISO 11898. 8.1 CAN Frame Type This specification is based on the CAN Standard Frames with 11-bit Identifier Field. It is not required to support the CAN Extended Frame with 29-bit Identifier Field. However, as certain applications may require the usage of the extended frame with 29-bit Identifier Field the network can be operated in this mode as well if it is supported by all nodes.

8-1

APPLICATION LAYER

CANopen

CiA

9 APPLICATION LAYER
9.1 9.1.1 Data Types and Encoding Rules General Description of Data Types and Encoding Rules

To be able to exchange meaningful data across the CAN network, the format of this data and its meaning have to be known by the producer and consumer(s). This specification models this by the concept of data types. The encoding rules define the representation of values of data types and the CAN network transfer syntax for the representations. Values are represented as bit sequences. Bit sequences are transferred in sequences of octets (bytes). For numerical data types the encoding is little endian style as shown in Figure 9. Applications often require data types beyond the basic data types. Using the compound data type mechanism the list of available data types can be extended. Some general extended data types are defined as Visible String or Time of Day for example (see 9.1.6.2 and 9.1.6.4). The compound data types are a means to implement user defined DEFTYPES in the terminology of this specification and not DEFSTRUCTS (see Table 36: Object Dictionary Object Definitions). 9.1.2 Data Type Definitions

A data type determines a relation between values and encoding for data of that type. Names are assigned to data types in their type definitions. The syntax of data and data type definitions is as follows (see EN 61131-3). data_definition type_definition constructor compound_constructor array_constructor structure_constructor component_list component basic_constructor ::= type_name data_name ::= constructor type_name ::= compound_constructor | basic_constructor ::= array_constructor | structure_constructor ::= ARRAY [ length ] OF type_name ::= STRUCT OF component_list ::= component { , component } ::= type_name component_name ::= BOOLEAN | VOID bit_size | INTEGER bit_size | UNSIGNED bit_size | REAL32 | REAL64 | NIL ::= 1 | 2 | <...> | 64 ::= positive_integer ::= symbolic_name ::= symbolic_name ::= symbolic_name ::= letter { [ _ ] ( letter | digit ) } ::= ( 1 | 2 | <...> | 9 ) { digit } ::= A | B | <...> | Z | a | b | <...> | z ::= 0 | 1 | <...> | 9 9-1

bit_size length data_name type_name component_name symbolic_name positive_integer letter digit

APPLICATION LAYER

CANopen

CiA

Recursive definitions are not allowed. The data type defined by type_definition is called basic (res.~compound) when the constructor is basic_constructor (res. compound_constructor). 9.1.3 9.1.3.1 Bit Sequences Definition of Bit Sequences

A bit can take the values 0 or 1. A bit sequence b is an ordered set of 0 or more bits. If a bit sequence b contains more than 0 bits, they are denoted as bj, j > 0. Let b0, ..., bn-1 be bits, n a positive integer. Then b = b0 b1 ... bn-1 is called a bit sequence of length |b| = n. The empty bit sequence of length 0 is denoted e. Examples: 10110100, 1, 101, etc. are bit sequences. The inversion operator () on bit sequences assigns to a bit sequence b = b0 b1 ... bn-1 the bit sequence b = b0 b1 ... bn-1 Here 0 = 1 and 1 = 0 on bits. The basic operation on bit sequences is concatenation. Let a = a0 ... am-1 and b = b0 ... bn-1 be bit sequences. Then the concatenation of a and b, denoted ab, is ab = a0 ... am-1 b0 ... bn-1 Example: (10)(111) = 10111 is the concatenation of 10 and 111. The following holds for arbitrary bit sequences a and b: |ab| = |a| + |b| and ea = ae = a 9.1.3.2 Transfer Syntax for Bit Sequences

For transmission across a CAN network a bit sequence is reordered into a sequence of octets. Here and in the following hexadecimal notation is used for octets. Let b = b0...bn-1 be a bit sequence with n<64. Denote k a non-negative integer such that 8(k - 1) < n < 8k. Then b is transferred in k octets assembled as shown in Figure 9. The bits bi, i > n of the highest numbered octet are do not care bits. Octet 1 is transmitted first and octet k is transmitted last. Hence the bit sequence is transferred as follows across the CAN network: b7, b6, ..., b0, b15, ..., b8, ...

9-2

APPLICATION LAYER
octet number 1. b7 .. b0

CANopen
2. b15 .. b8 k. b8k 1 .. b8k -8

CiA

Figure 9: Transfer Syntax for Bit Sequences Example: Bit 9 10 2h ... 0001 1h Ch = 21Ch The bit sequence b = b0 .. b9 = 0011 1000 01 represents an UNSIGNED10 with the value 21Ch and is transferred in two octets: First 1Ch and then 02h. 9.1.4 Basic Data Types Bit 0 1100

For basic data types type_name equals the literal string of the associated constructor (aka symbolic_name), e.g., BOOLEAN BOOLEAN is the type definition for the BOOLEAN data type. 9.1.4.1 NIL Data of basic data type NIL is represented by e. 9.1.4.2 Boolean

Data of basic data type BOOLEAN attains the values TRUE or FALSE. The values are represented as bit sequences of length 1. The value TRUE (res. FALSE) is represented by the bit sequence 1 (res. 0). 9.1.4.3 Void Data of basic data type VOIDn is represented as bit sequences of length n bit. The value of data of type VOIDn is undefined. The bits in the sequence of data of type VOIDn must either be specified explicitly or else marked "do not care". Data of type VOIDn is useful for reserved fields and for aligning components of compound values on octet boundaries. 9.1.4.4 Unsigned Integer Data of basic data type UNSIGNEDn has values in the non-negative integers. The value range is 0, ..., 2n-1. The data is represented as bit sequences of length n. The bit sequence b = b0 ...bn-1 is assigned the value UNSIGNEDn(b) = bn-1 2n-1+ ...+ b1 21 + b0 20 Note that the bit sequence starts on the left with the least significant bit. Example: The value 266 = 10Ah with data type UNSIGNED16 is transferred in two octets across the bus, first 0Ah and then 01h.

9-3

APPLICATION LAYER

CANopen

CiA

The following UNSIGNEDn data types are transferred as shown below:


octet number UNSIGNED8 UNSIGNED16 UNSIGNED24 UNSIGNED32 UNSIGNED40 UNSIGNED48 UNSIGNED56 UNSIGNED64 1. b7..b0 b7..b0 b7..b0 b7..b0 b7..b0 b7..b0 b7..b0 b7..b0 b15..b8 b15..b8 b15..b8 b15..b8 b15..b8 b15..b8 b15..b8 b23..b16 b23..b16 b23..b16 b23..b16 b23..b16 b23..b16 b31..b24 b31..b24 b31..b24 b31..b24 b31..b24 b39..b32 b39..b32 b39..b32 b39..b32 b47..b40 b47..b40 b47..b40 b55..b48 b55..b48 b63..b56 2. 3. 4. 5. 6. 7. 8.

Figure 10: Transfer syntax for data type UNSIGNEDn 9.1.4.5 Signed Integer

Data of basic data type INTEGERn has values in the integers. The value range is -2n-1, ..., 2n-1-1. The data is represented as bit sequences of length n. The bit sequence b = b0 .. bn-1 is assigned the value INTEGERn(b) = bn-2 2n-2 + ...+ b1 21 + b0 20 if bn-1 = 0 and, performing two's complement arithmetic, INTEGERn(b) = - INTEGERn(b) - 1 if bn-1 = 1 Note that the bit sequence starts on the left with the least significant bit. Example: The value 266 = FEF6h with data type INTEGER16 is transfered in two octets across the bus, first F6h and then FEh. The following INTEGERn data types are transfered as shown below:
octet number INTEGER8 INTEGER16 INTEGER24 INTEGER32 INTEGER40 INTEGER48 INTEGER56 INTEGER64 1. b7..b0 b7..b0 b7..b0 b7..b0 b7..b0 b7..b0 b7..b0 b7..b0 b15..b8 b15..b8 b15..b8 b15..b8 b15..b8 b15..b8 b15..b8 b23..b16 b23..b16 b23..b16 b23..b16 b23..b16 b23..b16 b31..b24 b31..b24 b31..b24 b31..b24 b31..b24 b39..b32 b39..b32 b39..b32 b39..b32 b47..b40 b47..b40 b47..b40 b55..b48 b55..b48 b63..b56 2. 3. 4. 5. 6. 7. 8.

Figure 11: Transfer syntax for data type INTEGERn

9-4

APPLICATION LAYER 9.1.4.6 Floating-Point Numbers

CANopen

CiA

Data of basic data types REAL32 and REAL64 have values in the real numbers. The data type REAL32 is represented as bit sequence of length 32. The encoding of values follows the IEEE 754-1985 Standard for single precision floating-point. The data type REAL64 is represented as bit sequence of length 64. The encoding of values follows the IEEE 754-1985 Standard for double precision floating-point numbers. A bit sequence of length 32 either has a value (finite non-zero real number, +0, + _) or is NaN (not-anumber). The bit sequence b = b0 b31 is assigned the value (finite non-zero number) REAL32(b) = (-1)S 2E - 127 (1 + F) Here S = b31 is the sign. E = b30 27 + + b23 20, 0 < E < 255, is the un-biased exponent. F = 2-23 (b22 222 + + b1 21 + b0 20) is the fractional part of the number. E = 0 is used to represent + 0. E = 255 is used to represent infinities and NaN's. Note that the bit sequence starts on the left with the least significant bit. Example: 6.25 = 2E -127 (1 + F) with E =129 =27 +20 and F = 2-1 +2-4 = 2 -23(222+219) hence the number is represented as: S b31 0 E b30 .. b23 100 0000 1 F b22 .. b0 100 1000 0000 0000 0000 0000

6.25 = b0 .. b31 = 0000 0000 0000 0000 0001 0011 0000 0010 It is transferred in the following order:
octet number REAL32 1. 00h b7..b0 2. 00h b15..b8 3. C8h b23..b16 4. 40h b31..b24

Figure 12: Transfer syntax of data type REAL32

9-5

APPLICATION LAYER 9.1.5 Compound Data Types

CANopen

CiA

Type definitions of compound data types expand to a unique list of type definitions involving only basic data types. Correspondingly, data of compound type type_name are ordered lists of component data named component_name_i of basic type basic_type_i. Compound data types constructors are ARRAY and STRUCT OF. STRUCT OF basic_type_1 basic_type_2 basic_type_N type_name ARRAY [ length ] OF basic_type type_name component_name_1, component_name_2, component_name_N

The bit sequence representing data of compound type is obtained by concatenating the bit sequences representing the component data. Assume that the components component_name_i are represented by their bit sequences b(i), for i = 1,,N Then the compound data is represented by the concatenated sequence b0(1) .. bn-1(1) .. bn-1(N). Example: Consider the data type STRUCT OF INTEGER10 x, UNSIGNED5 u NewData Assume x = - 423 = 259h and u = 30 = 1Eh. Let b(x) and b(u) denote the bit sequences representing the values of x and u, respectively. Then: b(x) = b0(x) .. b9(x) = 1001101001 b(u) = b0(u) .. b4(u) = 01111 b(xu) = b(x) b(u) = b0(xu) .. b14(xu) = 1001101001 01111 The value of the structure is transferred with two octets, first 59h and then 7Ah. 9.1.6 Extended Data Types

The extended data types consist of the basic data types and the compound data types defined in the following subsections. 9.1.6.1 Octet String The data type OCTET_STRINGlength is defined below; length is the length of the octet string. ARRAY [ length ] OF UNSIGNED8 OCTET_STRINGlength 9.1.6.2 Visible String

The data type VISIBLE_STRINGlength is defined below. The admissible values of data of type VISIBLE_CHAR are 0h and the range from 20h to 7Eh. The data are interpreted as ISO 646-1973(E) 7-bit coded characters. length is the length of the visible string. UNSIGNED8 VISIBLE_CHAR ARRAY [ length ] OF VISIBLE_CHAR There is no 0h necessary to terminate the string. 9.1.6.3 Unicode String VISIBLE_STRINGlength

The data type UNICODE_STRINGlength is defined below; length is the length of the unicode string. ARRAY [ length ] OF UNSIGNED16 UNICODE_STRINGlength 9.1.6.4 Time of Day The data type TIME_OF_DAY represents absolute time. It follows from the definition and the encoding rules that TIME_OF_DAY is represented as bit sequence of length 48.

9-6

APPLICATION LAYER

CANopen

CiA

Component ms is the time in milliseconds after midnight. Component days is the number of days since January 1, 1984. STRUCT OF UNSIGNED28 VOID4 UNSIGNED16 TIME_OF_DAY 9.1.6.5 Time Difference ms, reserved, days

The data type TIME_DIFFERENCE represents a time difference. It follows from the definition and the encoding rules that TIME_DIFFERENCE is represented as bit sequence of length 48. Time differences are sums of numbers of days and milliseconds. Component ms is the number milliseconds. Component days is the number of days. STRUCT OF UNSIGNED28 VOID4 UNSIGNED16 TIME_DIFFERENCE 9.1.6.6 Domain ms, reserved, days

Domains can be used to transfer an arbitrary large block of data from a client to a server and vv. The contents of a data block is application specific and does not fall within the scope of this document. 9.2 Communication Objects The communication objects are described by the services and protocols. All services are described in a tabular form that contains the parameters of each service primitive that is defined for that service. The primitives that are defined for a particular service determine the service type (e.g. unconfirmed, confirmed, etc.). How to interpret the tabular form and what service types exist is defined in 6.3 (Communication Model). All services assume that no failures occur in the Data Link and Physical Layer of the CAN network. These failures are resolved by the application and fall not in the scope of this document. 9.2.1 Process Data Object (PDO)

The real-time data transfer is performed by means of "Process Data Objects (PDO)". The transfer of PDOs is performed with no protocol overhead. The PDOs correspond to entries in the device Object Dictionary and provide the interface to the application objects. Data type and mapping of application objects into a PDO is determined by a corresponding default PDO mapping structure within the Device Object Dictionary. If variable PDOmapping is supported the number of PDOs and the mapping of application objects into a PDO may be transmitted to a device during the device configuration process (see Initialisation Procedure) by applying the SDO services to the corresponding entries of the Object Dictionary. Number and length of PDOs of a device is application specific and have to be specified within the device profile. There are two kinds of use for PDOs. The first is data transmission and the second data reception. It is distinguished in Transmit-PDOs (TPDOs) and Receive-PDOs (RPDOs). Devices supporting TPDOs are PDO producer and devices which are able to receive PDOs are called PDO consumer. PDOs are described by the PDO communication parameter (20h) and the PDO mapping parameter (21h). The structure of these data types are explained in 9.5.4. The PDO communication parameter describes the communication capabilities of the PDO. The PDO mapping parameter contains information about the contents of the PDOs (device variables). The indices of the corresponding Object Dictionary entries are computed by the following formulas: RPDO communication parameter index = 1400h + RPDO-number -1 TPDO communication parameter index = 1800h + TPDO-number -1 RPDO mapping parameter index = 1600h + RPDO-number -1 9-7

APPLICATION LAYER

CANopen

CiA

TPDO mapping parameter index = 1A00h + TPDO-number -1

For each PDO the pair of communication and mapping parameter is mandatory. The entries mentioned above are described in 9.5 (Object Dictionary). 9.2.1.1 Transmission Modes The following PDO transmission modes are distinguished: Synchronous Transmission Asynchronous Transmission In order to synchronise devices a synchronisation object (SYNC object) is transmitted periodically by a synchronisation application. The SYNC object is represented by a pre-defined communication object (see 9.2.3). In Figure 13 the principle of synchronous and asynchronous transmission is shown. Synchronous PDOs are transmitted within a pre-defined time-window immediately after the SYNC object. The principle of synchronous transmission is described in more detail in 9.3.

SYNC Object

Synchronous Window Length

SYNC Object

SYNC Object

time Synchronous PDOs Asynchronous PDOs

Figure 13: Synchronous and Asynchronous Transmission The transmission type parameter of a PDO specifies the transmission mode as well as the triggering mode. For synchronous TPDOs the transmission type also specifies the transmission rate in form of a factor based on the basic SYNC-object transmission period. A transmission type of 0 means that the message shall be transmitted after occurrence of the SYNC but acyclic (not periodically), only if an event occurred before the SYNC. A transmission type of 1 means that the message is transmitted with every SYNC object. A transmission type of n means that the message is transmitted with every n-th SYNC object. Asynchronous TPDOs are transmitted without any relation to a SYNC. The data of synchronous RPDOs received after the occurrence of a SYNC is passed to the application with the occurrence of the following SYNC, independent of the transmission rate specified by the transmission type. The data of asynchronous RPDOs is passed directly to the application. 9.2.1.2 Triggering Modes

Three message triggering modes are distinguished: Event Driven Message transmission is triggered by the occurrence of an object specific event. For synchronous PDOs this is the expiration of the specified transmission period, synchronised by the reception of the SYNC object. For acyclically transmitted synchronous PDOs and asynchronous PDOs the triggering of a message transmission is a device-specific event specified in the device profile. Timer Driven Message transmission is either triggered by the occurrence of a device-specific event or if a specified time has elapsed without occurrence of an event.

9-8

APPLICATION LAYER

CANopen

CiA

Remotely requested The transmission of an asynchronous PDO is initiated on receipt of a remote request initiated by any other device (PDO consumer).

9.2.1.3

PDO Services

PDO transmission follows the producer/consumer relationship as described in 6.3.3. Attributes: - PDO number: - user type: - data type: - inhibit-time: 9.2.1.3.1 Write PDO PDO number [1..512] for every user type on the local device one of the values {consumer, producer} according to the PDO mapping n*100 ms, n >> 0

For the Write PDO service the push model is valid. There are zero or more consumers of a PDO. A PDO has exactly one producer. Through this service the producer of a PDO sends the data of the mapped application objects to the consumer(s). Table 3: Write PDO Parameter Argument PDO Number Data Request / Indication Mandatory mandatory mandatory

9.2.1.3.2

Read PDO

For the Read PDO service the pull model is valid. There are one or more consumers of a PDO. A PDO has exactly one producer. Through this service the consumer of a PDO requests the producer to supply the data of the mapped application objects. The service is confirmed. The remote result parameter will confirm the value. Table 4: Read PDO Parameter Argument PDO Number Remote Result Data Request / Indication Mandatory mandatory Mandatory mandatory Response / Confirm

9-9

APPLICATION LAYER 9.2.1.4 9.2.1.4.1 PDO Protocol Write PDO Protocol

CANopen

CiA

The service for a PDO write request is unconfirmed. The PDO producer sends the process data within a PDO to the network. There can be 0..n PDO consumers. At the PDO consumer(s) the reception of a valid PDO is indicated. Figure 14 shows the Write PDO Protocol.

PDO Producer
0 Request

Write PDO
L (0 L 8)

PDO Consumers
Indication Indication Indication

Process Data

Figure 14: Write PDO Protocol Process-Data: up to L bytes of application data according to the PDO mapping If L exceeds the number of bytes n defined by the actual PDO mapping length only the first n bytes are used by the consumer. If L is less than n the data of the received PDO is not processed and an Emergency message with error code 8210h has to be produced if Emergency is supported. 9.2.1.4.2 Read PDO Protocol The service for a PDO read request is confirmed. One or more PDO consumer transmit a remote transmission request frame (RTR) to the network. At the reception of the RTR frame the PDO producer for the requested PDO transmits the PDO. At all PDO consumers for this PDO the reception is indicated. There can be 0..n PDO consumers. The read service is optional and depends on the hardware capabilities. Figure 15 shows the Read PDO Protocol.

PDO Producer
Indication

Read PDO
Remote Transmit Request L (0 L 8)

PDO Consumers
request

0 response

Process Data

confirmation

Figure 15: Read PDO Protocol Process-Data: up to L bytes of application data according to the PDO mapping If L exceeds the number of bytes n defined by the actual PDO mapping length only the first n bytes are used by the consumer. If L is less than n the data of the received PDO is not processed and an Emergency message with error code 8210h has to be produced if Emergency is supported.

9-10

APPLICATION LAYER 9.2.2 Service Data Object (SDO)

CANopen

CiA

With Service Data Objects (SDOs) the access to entries of a device Object Dictionary is provided. As these entries may contain data of arbitrary size and data type SDOs can be used to transfer multiple data sets (each containing an arbitrary large block of data) from a client to a server and vice versa. The client can control via a multiplexor (index and sub-index of the Object Dictionary) which data set is to be transferred. The contents of the data set are defined within the Object Dictionary. Basically a SDO is transferred as a sequence of segments. Prior to transferring the segments there is an initialisation phase where client and server prepare themselves for transferring the segments. For SDOs, it is also possible to transfer a data set of up to four bytes during the initialisation phase. This mechanism is called an expedited transfer. Optionally a SDO can be transferred as a sequence of blocks where each block is a sequence of up to 127 segments containing a sequence number and the data. Prior to transferring the blocks there is an initialisation phase where client and server can prepare themselves for transferring the blocks and negotiating the number of segments in one block. After transferring the blocks there is a finalisation phase where client and server can optionally verify the correctness of the previous data transfer by comparing checksums derived from the data set. This transfer type mentioned above is called a block transfer which is faster than the segmented transfer for a large set of data. In SDO Block Upload it is possible that the size of the data set does not justify the use of a block transfer because of the implied protocol overhead. In these cases a support for a fallback to the segmented or expedited transfer in initialisation phase can be implemented. As the assumption of the minimal data set size for which a block transfer outperforms the other transfer types depends on various parameters the client indicates this threshold value in bytes to the server in initialisation phase. For the block transfer a Go-Back-n ARQ (Automatic Repeat Request) scheme is used to confirm each block. After block download the server indicates the client the last successfully received segment of this block transfer by acknowledging this segment sequence number. Doing this the server implicitly acknowledges all segments preceding this segment. The client has to start the following block transfer with the retransmission of all not acknowledged data. Additionally the server has to indicate the number of segments per block for the next block transfer. After block upload the client indicates the server the last successfully received segment of this block transfer by acknowledging this segment sequence number. Doing this the client implicitly acknowledges all segments preceding this segment. The server has to start the following block transfer with the retransmission of all not acknowledged data. Additionally the client has to indicate the number of segments per block for the next block transfer. For all transfer types it is the client that takes the initiative for a transfer. The owner of the accessed Object Dictionary is the server of the SDO. Both the client or the server can take the initiative to abort the transfer of a SDO. By means of a SDO a peer-to-peer communication channel between two devices is established. A device may support more than one SDO. One supported Server-SDO (SSDO) is the default case (Default SDO). SDOs are described by the SDO communication parameter record (22h).The structure of this data type is explained in 9.5.4. The SDO communication parameter describes the communication capabilities of the Server-SDOs and Client-SDOs (CSDO). The indices of the corresponding Object Dictionary entries are computed by the following formulas: SSDO communication parameter index = 1200h + SSDO-number -1 CSDO communication parameter index = 1280h + CSDO-number -1

For each SDO the communication parameters are mandatory. If only one SSDO exists the communication parameters can be omitted. The entries mentioned above are described in 9.5 (Object Dictionary). 9.2.2.1 SDO Services The model for the SDO communication is the Client/Server model as described in 0. Attributes: - SDO number: SDO number [1..128] for every user type on the local device - user type: one of the values {client, server} - mux data type multiplexor containing index and sub-index of type STRUCTURE OF UNSIGNED (16) , UNSIGNED (8) , with index specifying an entry of the device Object 9-11

APPLICATION LAYER

CANopen Dictionary and "sub-index" specifying a component of a device object dictionary entry

CiA

- transfer type:

- data type:

depends on the length of data to transfer: expedited for up to 4 data bytes segmented or block for more than 4 data bytes according to the referenced index and sub-index

The following services can be applied onto a SDO depending on the application requirements: SDO Download, which can be split up into - Initiate SDO Download - Download SDO Segment SDO Upload, which can be split up into - Initiate SDO Upload - Upload SDO Segment Abort SDO Transfer When using the segmented SDO download and upload services, the communication software will be responsible for transferring the SDO as a sequence of segments. Expetited transfer has to be supported. Segmented transfer has to be supported if objects larger than 4 Bytes are supported. Optionally the following SDO services for doing a block transfer with higher bus utilisation and performance for a large data set size can be implemented: SDO Block Download, which can be split up into - Initiate Block Download - Download Block - End Block Download SDO Block Upload, which can be split up into - Initiate Block Upload - Upload Block - End Block Upload When using the SDO block download and upload services, the communication software will be responsible for transferring the data as a sequence of blocks. In SDO Block Upload Protocol a support for a switch to SDO Upload Protocol in Initiate SDO Block Upload can be implemented to increase transfer performance for data which size does not justifies using the protocol overhead of the SDO Block Upload protocol. For aborting a SDO block transfer the Abort SDO Transfer Service is used. 9.2.2.1.1 SDO Download Through this service the client of a SDO downloads data to the server (owner of the Object Dictionary). The data, the multiplexor (index and sub-index) of the data set that has been downloaded and its size (only optionally for segmented transfer) are indicated to the server. The service is confirmed. The remote result parameter will indicate the success or failure of the request. In case of a failure, optionally the reason is confirmed. The SDO download consists of at least the Initiate SDO Download service and optional of Download SDO Segment services (data length > 4 bytes).

9-12

APPLICATION LAYER

CANopen Table 5: SDO Download

CiA

Parameter Argument SDO Number Data Size Multiplexor Remote Result Success Failure Reason

Request / Indication Mandatory mandatory mandatory optional mandatory

Response / Confirm

Mandatory selection selection optional

9.2.2.1.2

Initiate SDO Download

Through this service the client of SDO requests the server to prepare for downloading data to the server. Optionally the size of the data to be downloaded is indicated to the server. The multiplexor of the data set whose download is initiated and the transfer type are indicated to the server. In case of an expedited download, the data of the data set identified by the multiplexor and size is indicated to the server. Table 6: Initiate SDO Download Parameter Argument SDO Number Size Multiplexor Transfer type Normal Expedited Data Remote Result Success Request / Indication Mandatory mandatory optional mandatory mandatory selection selection mandatory Mandatory mandatory Response / Confirm

The service is confirmed. The remote result parameter will indicate the success of the request. In case of a failure, an Abort SDO Transfer request has to be executed. In the case of a successful expedited download of a multiplexed DOMAIN, this service concludes the download of the data set identified by multiplexor. 9.2.2.1.3 Download SDO Segment Through this service the client of a SDO supplies the data of the next segment to the server. The segment data and optionally its size are indicated to the server. The continue parameter indicates the server whether there are still more segments to be downloaded or that this was the last segment to be downloaded.

9-13

APPLICATION LAYER

CANopen Table 7: Download SDO Segment

CiA

Parameter Argument SDO number Data Size Continue More Last Remote Result Success

Request / Indication Mandatory mandatory mandatory optional mandatory selection selection

Response / Confirm

Mandatory mandatory

The service is confirmed. The remote result parameter will indicate the success of the request. In case of a failure, an Abort SDO transfer request must be executed. In case of success, the server has accepted the segment data and is ready to accept the next segment. There can be at most one Download SDO Segment service outstanding for a SDO transfer. A successful Initiate SDO Download service with segmented transfer type must have been executed prior to this service. 9.2.2.1.4 SDO Upload Through this service the client of a SDO uploads data from the server. The multiplexor (index and subindex) of the data set that has to be uploaded is indicated to the server. The SDO upload consists of at least the Initiate SDO Upload service and optional of Upload SDO Segment services (data length > 4 bytes). Table 8: SDO Upload Parameter Argument SDO number Multiplexor Remote Result Success Data Size Failure Reason Request / Indication Mandatory mandatory mandatory Mandatory selection mandatory optional selection optional Response / Confirm

The service is confirmed. The remote result parameter will indicate the success or failure of the request. In case of a failure, optionally the reason is confirmed. In case of success, the data and its size (optionally for segmented transfer) are confirmed. 9.2.2.1.5 Initiate SDO Upload Through this service the client of a SDO requests the server to prepare for uploading data to the client. The multiplexor (index and sub-index) of the data set whose upload is initiated is indicated to the server. The service is confirmed. The remote result parameter will indicate the success of the request. In case of a failure, an Abort SDO Transfer request has to be executed. In the case of success, the size (optionally for segmented transfer) of the data to be uploaded is confirmed. In case of successful expedited upload, this service concludes the upload of the data set identified by multiplexor and the corresponding data is confirmed.

9-14

APPLICATION LAYER

CANopen Table 9: Initiate SDO Upload

CiA

Parameter Argument SDO number Multiplexor Remote Result Success Size Multiplexor Transfer type Normal Expedited Data

Request / Indication Mandatory mandatory mandatory

Response / Confirm

Mandatory mandatory optional mandatory mandatory selection selection mandatory

9.2.2.1.6

Upload SDO Segment

Through this service the client of a SDO requests the server to supply the data of the next segment. The continue parameter indicates the client whether there are still more segments to be uploaded or that this was the last segment to be uploaded. There can be at most one Upload SDO Segment service outstanding for a SDO. The service is confirmed. The remote result parameter will indicate the success of the request. In case of a failure, an Abort SDO Transfer request must be executed. In case of success, the segment data and optionally its size are confirmed. A successful Initiate SDO Upload service with segmented transfer type must have been executed prior to this service. Table 10: Upload SDO Segment Parameter Argument SDO number Remote Result Success Data Size Continue More Last Request / Indication Mandatory mandatory Mandatory mandatory mandatory optional mandatory selection selection Response / Confirm

9.2.2.1.7

Abort SDO Transfer

This service aborts the up- or download of a SDO referenced by is number. Optionally the reason is indicated. The service is unconfirmed. The service may be executed at any time by both the client and the server of a SDO. If the client of a SDO has a confirmed service outstanding, the indication of the abort is taken to be the confirmation of that service. Table 11: Abort SDO Transfer Parameter Argument SDO number Multiplexor Reason Request / Indication Mandatory mandatory mandatory mandatory

9-15

APPLICATION LAYER 9.2.2.1.8 SDO Block Download

CANopen

CiA

Through this service the client of SDO downloads data to the server of SDO (owner of the Object Dictionary) using the block download protocol. The data, the multiplexor (index and sub-index) of the data set that has been downloaded and optionally its size are indicated to the server. The service is confirmed. The remote result parameter will indicate the success or failure of the request. In case of a failure, optionally the reason is confirmed. Table 12: SDO Block Download Parameter Argument SDO Number Data Size Multiplexor Remote Result Success Failure Reason Request / Indication Mandatory mandatory mandatory optional mandatory Mandatory selection selection optional Response / Confirm

9.2.2.1.9

Initiate SDO Block Download

Through this service the client of SDO requests the server of SDO (owner of the Object Dictionary) to prepare for downloading data to the server. The multiplexor of the data set whose download is initiated and optionally the size of the downloaded data in bytes are indicated to the server. The client as well as the server indicating their ability and/or demand to verify the complete transfer with a checksum in End SDO Block Download. Table 13: Initiate SDO Block Download Parameter Argument SDO Number Size CRC ability yes no Multiplexor Remote Result Success CRC ability yes no Blksize Request / Indication Mandatory mandatory optional mandatory selection selection mandatory Mandatory mandatory mandatory selection selection mandatory Response / Confirm

The service is confirmed. The Remote Result parameter will indicate the success of the request, the number of segments per block the server of SDO is able to receive and its ability and/or demand to verify the complete transfer with a checksum. In case of a failure, an Abort SDO Transfer request must be executed. 9.2.2.1.10 Download SDO Block By this service the client of SDO supplies the data of the next block to the server of SDO. The block data is indicated to the server by a sequence of segments. Each segment consists of the data and a sequence number starting with 1 which is increased for each segment by 1 up to blksize. The parameter blksize is negotiated between server and client in the Initiate Block Download protocol and can be changed by the server with each confirmation for a block transfer. The continue parameter

9-16

APPLICATION LAYER

CANopen

CiA

indicates the server whether to stay in the Download Block phase or to change in the End Download Block phase. Table 14: Download SDO Block Parameter Argument SDO Number Data Continue More Last Remote Result Success Ackseq Blksize Request / Indication Mandatory mandatory mandatory mandatory selection selection Mandatory mandatory mandatory mandatory Response / Confirm

The service is confirmed. The Remote Result parameter will indicate the success of the request. In case of a success the ackseq parameter indicates the sequence number of the last segment the server has received successfully. If this number does not correspond with the sequence number of the last segment sent by the client during this block transfer the client has to retransmit all segments discarded by the server with the next block transfer. In case of a fatal failure, an Abort SDO Transfer request must be executed. In case of success, the server has accepted all acknowledged segment data and is ready to accept the next block. There can be at most one Download SDO Block service outstanding for a SDO transfer. A successful 'Initiate SDO Block Download' service must have been executed prior to this service. 9.2.2.1.11 End SDO Block Download Through this service the SDO Block Download is concluded. The number of bytes not containing valid data in the last transmitted segments is indicated to the server. If the server as well as the client have indicated their ability and demand to check the complete transfer with a checksum in Initiate SDO Block Download this checksum is indicated to the server by the client. The server also has to generate a checksum which has to be compared with the one generated by the client. Table 15: End SDO Block Download Parameter Argument SDO Number Valid_data Ckecksum Remote Result Success Request / Indication Mandatory mandatory mandatory mandatory if negotiated in initiate Mandatory mandatory Response / Confirm

The service is confirmed. The Remote Result parameter will indicate the success of the request (matching checksums between client and server if negotiated) and concludes the download of the data set . In case of a failure, an Abort SDO Transfer request must be executed. 9.2.2.1.12 SDO Block Upload Through this service the client of SDO uploads data from the server of SDO (owner of the Object Dictionary) using the SDO block upload protocol. The data, the multiplexor (index and sub-index) of the data set that has to be uploaded and optionally its size are indicated to the server. The service is confirmed. The Remote Result parameter will indicate the success or failure of the request. In case of a failure, optionally the reason is confirmed. In case of a success, the data and optionally its size is confirmed. 9-17

APPLICATION LAYER

CANopen Table 16: SDO Block Upload

CiA

Parameter Argument SDO Number Multiplexor Remote Result Success Data Size Failure Reason

Request / Indication Mandatory mandatory mandatory

Response / Confirm

Mandatory selection mandatory optional selection optional

9.2.2.1.13

Initiate SDO Block Upload

Through this service the client of SDO requests the server of SDO (owner of the Object Dictionary) to prepare for uploading data to the client. The multiplexor of the data set whose upload is initiated and the number of segments the client of the SDO is able to receive are indicated to the server. A protocol switch threshold value is indicated to the server. If the number of bytes that has to be uploaded is less or equal this value the server can optionally conclude this data transfer with the SDO Upload Protocol as described in 9.2.2.1.4. The client as well as the server indicating their ability and/or demand to verify the complete transfer with a checksum in End SDO Block Upload Optionally the size of the uploaded data in bytes are indicated to the client. Table 17: Initiate SDO Block Upload Parameter Argument SDO Number Blksize CRC ability Yes No Multiplexor Threshold Remote Result Success CRC ability Yes No Size Request / Indication Mandatory mandatory mandatory mandatory selection selection mandatory mandatory Mandatory mandatory mandatory selection selection optional Response / Confirm

The service is confirmed. In case of a failure, an Abort SDO Transfer request must be executed. In case of success the size of the data in bytes to be uploaded is optionally indicated to the client. If the size of the data that has to be uploaded is less or equal threshold the server can continue with the SDO block upload protocol. In this case the Remote Result parameter and the further protocol is described in 9.2.2.2.14. 9.2.2.1.14 Upload SDO Block Through this service the client of SDO uploads the data of the next block from the server of SDO. The block data is indicated to the client by a sequence of segments. Each segment consists of the segment data and a sequence number starting with 1 which is increased for each segment by 1 up to blksize. The parameter blksize is negotiated between server and client in the Initiate Block Upload protocol and can be changed by the client with each confirmation for a block transfer. The continue parameter indicates the client whether to stay in the Upload Block phase or to change in the End Upload Block phase.

9-18

APPLICATION LAYER

CANopen Table 18: Upload SDO Block

CiA

Parameter Argument SDO Number Data Continue More Last Remote Result Success Ackseq Blksize

Request / Indication Mandatory mandatory mandatory mandatory selection selection

Response / Confirm

Mandatory mandatory mandatory mandatory

The service is confirmed. The Remote Result parameter will indicate the success of the request. In case of a success the ackseq parameter indicates the sequence number of the last segment the client has received successfully. If this number does not correspond with the sequence number of the last segment sent by the server during this block transfer the server has to retransmit all segments discarded by the client with the next block transfer. In case of a fatal failure, an Abort SDO Transfer request must be executed. In case of success, the client has accepted all acknowledged segment data and is ready to accept the next block. There can be at most one Upload Block service outstanding for a SDO transfer. A successful 'Initiate SDO Block Upload' service must have been executed prior to this service. 9.2.2.1.15 End SDO Block Upload

Through this service the SDO Block Upload is concluded. The number of bytes not containing valid data in the last transmitted segments is indicated to the client. If the server as well as the client have indicated their ability and demand to check the complete transfer with a checksum during Initiate SDO Block Upload this checksum is indicated to the client by the server. The client also has to generate a checksum which has to be compared with the one generated by the server. Table 19: End SDO Block Upload Parameter Argument SDO Number Valid_data Checksum Remote Result Success Request / Indication Mandatory mandatory mandatory mandatory if negotiated in initiate Mandatory mandatory Response / Confirm

The service is confirmed. The Remote Result parameter will indicate the success of the request (matching checksums between client and server if demanded) and concludes the download of the data set. In case of a failure, an Abort SDO Transfer request must be executed.

9-19

APPLICATION LAYER 9.2.2.2 SDO Protocols

CANopen

CiA

Six confirmed services (SDO Download, SDO Upload, Initiate SDO Upload, Initiate SDO Download, Download SDO Segment, and Upload SDO Segment) and one unconfirmed service (Abort SDO Transfer) are defined for Service Data Objects doing the standard segmented/expedited transfer. Eight confirmed services (SDO Block Download, SDO Block Upload, Initiate SDO Upload, Initiate SDO Block Download, Download SDO Segment, Upload SDO Segment, End SDO Upload and End SDO Block Download) and one unconfirmed service (Abort SDO Block Transfer) are defined for Service Data Objects doing the optional block transfer. 9.2.2.2.1 Download SDO Protocol

Client

SDO Download (normal)

Server

Client

SDO Download (expedited)

Server

Initiate SDO Download

(e=0)

Initiate SDO Download

(e=1)

Download SDO Segment (t=0, c=0)

Download SDO Segment (t=1, c=0)

Download SDO Segment (t=0, c=0)

Download SDO Segment (t=?, c=1)

Figure 16: Download SDO Protocol This protocol is used to implement the SDO Download service. SDOs are downloaded as a sequence of zero or more Download SDO Segment services preceded by an Initiate SDO Download service. The sequence is terminated by: an Initiate SDO Download request/indication with the e-bit set to 1 followed by an Initiate SDO Download response/confirm, indicating the successful completion of an expedited download sequence. a Download SDO Segment response/confirm with the c-bit set to 1, indicating the successful completion of a normal download sequence. an Abort SDO Transfer request/indication, indicating the unsuccessful completion of the download sequence. a new Initiate Domain Download request/indication, indicating the unsuccessful completion of the download sequence and the start of a new download sequence. If in the download of two consecutive segments the toggle bit does not alter, the contents of the last segment has to be ignored. If such an error is reported to the application, the application may decide to abort the download.

9-20

APPLICATION LAYER 9.2.2.2.2

CANopen

CiA

Initiate SDO Download Protocol

This protocol is used to implement the Initiate SDO Download service for SDOs. Initiate SDO Download
0
7..5 ccs=1 4 X 3..2 n 1 e 0 s

Client

Server
4 8
d

1
m

request

indication

0 confirm
7..5 scs=3 4..0 X

1
m

4
reserved

8 response

Figure 17: Initiate SDO Download Protocol ccs: client command specifier 1: initiate download request scs: server command specifier 3: initiate download response n: Only valid if e = 1 and s = 1, otherwise 0. If valid it indicates the number of bytes in d that do not contain data. Bytes [8-n, 7] do not contain data. e: transfer type 0: normal transfer 1: expedited transfer s: size indicator 0: data set size is not indicated 1: data set size is indicated m: multiplexor. It represents the index/sub-index of the data to be transfer by the SDO. d: data e = 0, s = 0: d is reserved for further use. e = 0, s = 1: d contains the number of bytes to be downloaded. Byte 4 contains the lsb and byte 7 contains the msb. e = 1, s = 1: d contains the data of length 4-n to be downloaded, the encoding depends on the type of the data referenced by index and sub-index e = 1, s = 0: d contains unspecified number of bytes to be downloaded X: not used, always 0 reserved: reserved for further use, always 0

9-21

APPLICATION LAYER 9.2.2.2.3

CANopen

CiA

Download SDO Segment Protocol

This protocol is used to implement the Download SDO Segment service.

Client
0
7..5 ccs=0 4 t

Download SDO Segment


1
3..1 n 0 c seg-data

Server
8

request

indication

0 confirm
7..5 scs=1 4 t 3..0 X

1
reserved

8 response

Figure 18: Download SDO Segment Protocol ccs: client command specifier 0: download segment request scs: server command specifier 1: download segment response seg-data: at most 7 bytes of segment data to be downloaded. The encoding depends on the type of the data referenced by index and sub-index n: indicates the number of bytes in seg-data that do not contain segment data. Bytes [8-n, 7] do not contain segment data. n = 0 if no segment size is indicated. c: indicates whether there are still more segments to be downloaded. 0 more segments to be downloaded 1: no more segments to be downloaded t: toggle bit. This bit must alternate for each subsequent segment that is downloaded. The first segment will have the toggle-bit set to 0. The toggle bit will be equal for the request and the response message. X: not used, always 0 reserved: reserved for further use, always 0

9-22

APPLICATION LAYER 9.2.2.2.4 Upload SDO Protocol

CANopen

CiA

Client

SDO Upload (normal)

Server

Client

SDO Upload (expedited)

Server

Initiate SDO Upload

(e=0)

Initiate SDO Upload

(e=1)

Upload SDO Segment (t=0, c=0)

Upload SDO Segment (t=1, c=0)

Upload SDO Segment (t=0, c=0)

Upload SDO Segment (t=?, c=1)

Figure 19: Upload SDO Protocol This protocol is used to implement the SDO Upload service. SDO are uploaded as a sequence of zero or more Upload SDO Segment services preceded by an Initiate SDO Upload service. The sequence is terminated by: an Initiate SDO Upload response/confirm with the e-bit set to 1, indicating the successful completion of an expedited upload sequence. an Upload SDO Segment response/confirm with the c-bit set to 1, indicating the successful completion of a normal upload sequence. an Abort SDO Transfer request/indication, indicating the unsuccessful completion of the upload sequence. a new Initiate SDO Upload request/indication, indicating the unsuccessful completion of the upload sequence and the start of a new sequence. If in the upload of two consecutive segments the toggle bit does not alter, the contents of the last segment has to be ignored. If such an error is reported to the application, the application may decide to abort the upload.

9-23

APPLICATION LAYER 9.2.2.2.5 Initiate SDO Upload Protocol

CANopen

CiA

This protocol is used to implement the Initiate SDO Upload service.

Client
0
7..5 scs=2

Initiate SDO Upload


1
4..0 X m

Server
8
reserved

request

indication

confirm

0
7..5 ccs=2 4 X 3..2 n 1 e 0 s

1
m

4
d

response

Figure 20: Initiate SDO Upload Protocol ccs: client command specifier 2: initiate upload request scs: server command specifier 2: initiate upload response n: Only valid if e = 1 and s = 1, otherwise 0. If valid it indicates the number of bytes in d that do not contain data. Bytes [8-n, 7] do not contain segment data. e: transfer type 0: normal transfer 1: expedited transfer s: size indicator 0: data set size is not indicated 1: data set size is indicated m: multiplexor. It represents the index/sub-index of the data to be transfer by the SDO. d: data e = 0, s = 0: d is reserved for further use. e = 0, s = 1: d contains the number of bytes to be uploaded. Byte 4 contains the lsb and byte 7 contains the msb. e = 1, s = 1: d contains the data of length 4-n to be uploaded, the encoding depends on the type of the data referenced by index and sub-index e = 1, s = 0: d contains unspecified number of bytes to be uploaded. X: not used, always 0 reserved: reserved for further use , always 0

9-24

APPLICATION LAYER 9.2.2.2.6

CANopen

CiA

Upload SDO Segment Protocol

This protocol is used to implement the Upload SDO Segment service.

Client
0
7..5 ccs=3

Upload SDO Segment


1
4 t 3..0 X reserved

Server
8 indication

request

confirm

0
7..5 scs=0 4 t 3..1 n 0 c

1
seg-data

response

Figure 21: Upload SDO Segment Protocol ccs: client command specifier 3: upload segment request scs: server command specifier 0: upload segment response t: toggle bit. This bit must alternate for each subsequent segment that is uploaded. The first segment will have the toggle-bit set to 0. The toggle bit will be equal for the request and the response message. c: indicates whether there are still more segments to be uploaded. 0: more segments to be uploaded 1: no more segments to be uploaded seg-data: at most 7 bytes of segment data to be uploaded. The encoding depends on the type of the data referenced by index and sub-index n: indicates the number of bytes in seg-data that do not contain segment data. Bytes [8-n, 7] do not contain segment data. n = 0 if no segment size is indicated. X: not used, always 0 reserved: reserved for further use, always 0

9-25

APPLICATION LAYER 9.2.2.2.7 Abort SDO Transfer Protocol

CANopen

CiA

This protocol is used to implement the Abort SDO Transfer Service.

Client/Server
0
7..5 cs=4

Abort SDO Transfer


1
4..0 X m

Server/Client
8
d

request

indication

Figure 22: Abort SDO Transfer Protocol cs: command specifier 4: abort transfer request X: not used, always 0 m: multiplexor. It represents index and sub-index of the SDO. d: contains a 4 byte abort code about the reason for the abort.

The abort code is encoded as UNSIGNED32 value. Table 20: SDO abort codes Abort code 0503 0000h 0504 0000h 0504 0001h 0504 0002h 0504 0003h 0504 0004h 0504 0005h 0601 0000h 0601 0001h 0601 0002h 0602 0000h 0604 0041h 0604 0042h Description Toggle bit not alternated. SDO protocol timed out. Client/server command specifier not valid or unknown. Invalid block size (block mode only). Invalid sequence number (block mode only). CRC error (block mode only). Out of memory. Unsupported access to an object. Attempt to read a write only object. Attempt to write a read only object. Object does not exist in the object dictionary. Object cannot be mapped to the PDO. The number and length of the objects to be mapped would exceed PDO length. 0604 0043h 0604 0047h 0606 0000h 0607 0010h 0607 0012h 0607 0013h 0609 0011h General parameter incompatibility reason. General internal incompatibility in the device. Access failed due to an hardware error. Data type does not match, length of service parameter does not match Data type does not match, length of service parameter too high Data type does not match, length of service parameter too low Sub-index does not exist. 9-26

APPLICATION LAYER 0609 0030h 0609 0031h 0609 0032h 0609 0036h 0800 0000h 0800 0020h 0800 0021h

CANopen Value range of parameter exceeded (only for write access). Value of parameter written too high. Value of parameter written too low. Maximum value is less than minimum value. general error Data cannot be transferred or stored to the application. Data cannot be transferred or stored to the application because of local control.

CiA

0800 0022h

Data cannot be transferred or stored to the application because of the present device state.

0800 0023h

Object dictionary dynamic generation fails or no object dictionary is present (e.g. object dictionary is generated from file and generation fails because of an file error).

The abort codes not listed here are reserved.

9-27

APPLICATION LAYER 9.2.2.2.8

CANopen

CiA

SDO Block Download Protocol

Client

SDO_Block_Download

Server

Initiate Block Download

Download Block

Download Block (normal)

Download Block (normal)

Download Block (last)

End Block Download

Download_Block (normal)

Download_Block (last)

Client

Server

Client

Server

Download segment 0 (c=0, seqno = 0) Download segment 1 (c=0, seqno = 1)

Download segment 0 (c=0, seqno = 0) Download segment 1 (c=0, seqno = 1)

Download segment n (c=0, seqno = n) Confirm block

Download segment n (c=1, seqno = n) Confirm block

Figure 23: SDO Block Download Protocol This protocol is used to implement a SDO Block Download service. SDOs are downloaded as a sequence of Download SDO Block services preceded by an Initiate SDO Block Download service. The SDO Download Block sequence is terminated by: a downloaded segment within a block with the c-bit set to 1, indicating the completion of the block download sequence. an 'Abort SDO Transfer' request/indication, indicating the unsuccessful completion of the download sequence.

The whole SDO Block Download service is terminated with the End SDO Block Download service. If client as well as server have indicated the ability to generate a CRC during the Initiate SDO Block Download service the server has to generate the CRC on the received data. If this CRC differs from the CRC generated by the client the server has to indicate this with an Abort SDO Transfer indication.

9-28

APPLICATION LAYER 9.2.2.2.9

CANopen

CiA

Initiate SDO Block Download Protocol

This protocol is used to implement the Initiate SDO Block Download service.

Client
0
7..5 ccs=6 4..3 X

Initiate Block Download


1
2 cc 1 s 0 cs=0 m

Server
4
size

request

indication

0 confirm
7..5 scs=5 4..3 X 2 sc 1..0 ss=0

1
m

4
blksize

5
reserved

8 response

Figure 24: Initiate SDO Block Download Protocol ccs: client command specifier 6: block download scs: server command specifier 5: block download s: size indicator 0: data set size is not indicated 1: data set size is indicated cs: client subcommand 0: initiate download request ss: server subcommand 0: initiate download response cc: client CRC support cc = 0: Client does not support generating CRC on data cc = 1: Client supports generating CRC on data sc: server CRC support sc = 0: Server does not support generating CRC on data sc = 1: Server supports generating CRC on data m: multiplexor. It represents the index/sub-index of the data to be transfer by the SDO. size: download size in bytes s = 0: size is reserved for further use, always 0 s = 1: size contains the number of bytes to be downloaded Byte 4 contains the lsb and byte 7 the msb blksize: Number of segments per block with 0 < blksize < 128. X: not used, always 0 reserved: reserved for further use, always 0

9-29

APPLICATION LAYER 9.2.2.2.10

CANopen

CiA

Download SDO Block Segment Protocol

Client
0
8 c

Download Block Segment


1
7..1 seqno seg-data

Server
8

request

indicatio

confirm

0
7..5 scs=5 4..2 X 1..0 ss=2

1
ackseq

2
blksize

3
reserved

response

This protocol is used to implement the Block Download service. Figure 25: Download SDO Block Segment scs: server command specifier 5: block download ss: server subcommand 2: block download response c: indicates whether there are still more segments to be downloaded 0: more segments to be downloaded 1: no more segments to be downloaded, enter End SDO block download phase seqno: sequence number of segment 0 < seqno < 128. seg-data: at most 7 bytes of segment data to be downloaded. ackseq: sequence number of last segment that was received successfully during the last block download. If ackseq is set to 0 the server indicates the client that the segment with the sequence number 1 was not received correctly and all segments have to be retransmitted by the client. blksize: Number of segments per block that has to be used by client for the following block download with 0 < blksize < 128. X: not used, always 0 reserved: reserved for further use, always 0

9-30

APPLICATION LAYER 9.2.2.2.11

CANopen

CiA

End SDO Block Download Protocol

This protocol is used to implement the End SDO Block Download service.

Client
0
7..5 ccs=6 4..2 n 1 X

End Block Download


1
0 cs=1 crc

Server
8
reserved

request

indication

confirm

0
7..5 scs=5 4..2 X 1..0 ss=1

1
reserved

response

Figure 26: End SDO Block Download Protocol ccs: client command specifier 6: block download scs: server command specifier 5: block download cs: client subcommand 1: end block download request ss: server subcommand 1: end block download response n: indicates the number of bytes in the last segment of the last block that do not contain data. Bytes [8-n, 7] do not contain segment data. crc: 16 bit Cyclic Redundancy Checksum (CRC) for the whole data set. The algorithm for generating the CRC is described in 9.2.2.2.16. CRC is only valid if in Initiate Block Download cc and sc are set to 1 otherwise CRC has to be set to 0. X: not used, always 0 reserved: reserved for further use, always 0

9-31

APPLICATION LAYER 9.2.2.2.12 Upload SDO Block Protocol

CANopen

CiA

Client

SDO_Block_Upload (normal)

Server

Client SDO_Block_Upload (fallback)


Initiate Block Upload (Phase I) (pst != 0) Fallback to SDO Upload Protocol

Server

Initiate Block Upload (Phase I) Initiate Block Upload (Phase II)

Upload Block (normal)

Upload Block (normal)

Upload Block (last)

End Block Upload

Client

Upload_Block (normal) Server

Upload_Block (last) Client


Upload segment 0 (c=0, seqno = 0) Upload segment 1 (c=0, seqno = 1)

Server

Upload segment 0 (c=0, seqno = 0) Upload segment 1 (c=0, seqno = 1)

Upload segment n (c=0, seqno = n) Confirm block

Upload segment n (c=1, seqno = n) Confirm block

Figure 27: Upload SDO Block Protocol This protocol is used to implement a SDO Block Upload service which starts with the Initiate SDO Block Upload service. The client can indicate a threshold value to the server which is the minimum value in bytes to increase transfer performance using the SDO Block Upload protocol instead of the SDO Upload protocol. If the data set size is less or equal this value the server can continue with the normal or expedited transfer of the SDO Block Upload protocol. Otherwise SDOs are uploaded as a sequence of Upload SDO Block services. The SDO Upload Block sequence is terminated by: an uploaded segment within a block with the c-bit set to 1, indicating the completion of the block upload sequence. an Abort SDO Transfer request/indication, indicating the unsuccessful completion of the uploaded sequence. The whole SDO Block Upload service is terminated with the End SDO Block Upload service. If client as well as server have indicated the ability to generate a CRC during the Initiate SDO Block Upload service the client has to generate the CRC on the received data. If this CRC differs from the CRC generated by the server the client has to indicate this with an Abort SDO Transfer indication.

9-32

APPLICATION LAYER 9.2.2.2.13

CANopen

CiA

Initiate SDO Block Upload Protocol

This protocol is used to implement the Initiate SDO Block Upload service. If the value of the Protocol Switch Threshold parameter indicated by the client in the first request is less or equal the data set size to be uploaded the server can continue with the SDO Upload Protocol as described in 9.2.2.2.4. Initiate Block Upload
0
7..5 ccs=5 4..2 X 2 cc 1..0 cs=0

Client

Server
4 5
blksize pst

1
m

6
X

request

indication

0 confirm
7..5 scs=6 4..3 X 2 cs 1 s

1
0 ss=0 m

4
size

8 response

0
7..5 ccs=5 4..2 X 1..0 cs=3

1
reserved

request

indication

Figure 28: Initiate SDO Block Upload Protocol ccs: client command specifier 5: block upload scs: server command specifier 6: block upload cs: client subcommand 0: initiate upload request 3: start upload ss: server subcommand 0: initiate upload response m: multiplexor. It represents the index/sub-index of the data to be transfer by the SDO. cc: client CRC support cc = 0: Client does not support generating CRC on data cc = 1: Client supports generating CRC on data sc: server CRC support sc = 0: Server does not support generating CRC on data sc = 1: Server supports generating CRC on data pst: Protocol Switch Threshold in bytes to change the SDO transfer protocol pst = 0: Change of transfer protocol not allowed. pst > 0: If the size of the data in bytes that has to be uploaded is less or equal pst the server can optionally switch to the SDO Upload Protocol by transmitting the server response of the SDO Upload Protocol as described in 9.2.2.2.4. s: size indicator 0: data set size is not indicated 1: data set size is indicated size: upload size in bytes s = 0: s = 1: size is reserved for further use, always 0 size contains the number of bytes to be downloaded Byte 4 contains the lsb and byte 7 the msb blksize: Number of segments per block with 0 < blksize < 128. X: not used, always 0 reserved: reserved for further use, always 0 9-33

APPLICATION LAYER 9.2.2.2.14

CANopen

CiA

Upload SDO Block Segment Protocol

This protocol is used to implement the SDO Block Upload service.

Client
0
8 c 7..1 seqno

Upload Block
1
seg-data

Server
8

indicatio

request

response

0
7..5 ccs=6 4..2 X 1..0 cs=2

1
ackseq

2
blksize

3
reserved

confirm

Figure 29: Upload SDO Block Segment Protocol ccs: server command specifier 6: block upload cs: client subcommand 2: block upload response c: indicates whether there are still more segments to be downloaded 0: more segments to be uploaded 1: no more segments to be uploaded, enter End block upload phase seqno: sequence number of segment 0 < seqno < 128. seg-data: at most 7 bytes of segment data to be uploaded. ackseq: sequence number of last segment that was received successfully during the last block upload. If ackseq is set to 0 the client indicates the server that the segment with the sequence number 1 was not received correctly and all segments have to be retransmitted by the server. blksize: Number of segments per block that has to be used by server for the following block upload with 0 < blksize < 128. X: not used, always 0 reserved: reserved for further use, always 0

9-34

APPLICATION LAYER 9.2.2.2.15

CANopen

CiA

End SDO Block Upload Protocol

This protocol is used to implement the End SDO Block Upload service.

Client
0
7..5 scs=6 4..2 n

End SDO Block Upload

Server
3 8
reserved

1
1..0 ss=1 crc

indication 1
7..5 ccs=5 4..3 X 0 cs=1 reserved

request

response

confirm

Figure 30: End SDO Block Upload Protocol ccs: client command specifier 5: block upload scs: server command specifier 6: block upload cs: client subcommand 1: end block upload request ss: server subcommand 1: end block upload response n: indicates the number of bytes in the last segment of the last block that do not contain data. Bytes [8-n, 7] do not contain segment data. crc: 16 bit Cyclic Redundancy Checksum (CRC) for the whole data set. The algorithm for generating the CRC is described in 9.2.2.2.16. CRC is only valid if in Initiate Block Upload cc and sc are set to 1 otherwise crc has to be set to 0. X: not used, always 0 reserved: reserved for further use, always 0 CRC calculation algorithm to verify SDO Block Transfer

9.2.2.2.16

To verify the correctness of a SDO block upload/download client and server calculating a cyclic redundancy checksum (CRC) which is exchanged and verified during End SDO Block Download/Upload protocol. The check polynominal has the formula x^16+x^15+x^5+1.

9-35

APPLICATION LAYER 9.2.3 Synchronisation Object (SYNC)

CANopen

CiA

The Synchronisation Object is broadcasted periodically by the SYNC producer. This SYNC provides the basic network clock. The time period between the SYNCs is specified by the standard parameter communication cycle period (see Object 1006h: Communication Cycle Period), which may be written by a configuration tool to the application devices during the boot-up process. There can be a time jitter in transmission by the SYNC producer corresponding approximately to the latency due to some other message being transmitted just before the SYNC. In order to guarantee timely access to the CAN bus the SYNC is given a very high priority identifier (1005h). Devices which operate synchronously may use the SYNC object to synchronise their own timing with that of the Synchronisation Object producer. The details of this synchronisation are device dependent and do not fall within the scope of this document. Devices which require a more accurate common time base may use the high resolution synchronisation mechanism described in 9.3.2. 9.2.3.1 SYNC Services The SYNC transmission follows the producer/consumer push model as described in 6.3.3. The service is unconfirmed. Attributes: - user type: one of the values {consumer, producer} - data type: nil 9.2.3.2 SYNC Protocol One unconfirmed service (Write SYNC) is defined. Write SYNC

SYNC Producer

Write SYNC

SYNC consumer(s)
Indication

request

Indication L=0 Indication

Figure 31: SYNC Protocol The SYNC does not carry any data (L=0). The Identifier of the SYNC object is located at Object Index 1005h.

9-36

APPLICATION LAYER 9.2.4 Time Stamp Object (TIME)

CANopen

CiA

By means of the Time Stamp Object a common time frame reference is provided to devices. It contains a value of the type TIME_OF_DAY. The Identifier of the TIME Object is located at Object Index 1012h. 9.2.4.1 TIME Services The Time Stamp Object transmission follows the producer/consumer push model as described in 6.3.3. The service is unconfirmed. Attributes: - user type: one of the values {consumer, producer} - data type: TIME_OF_DAY 9.2.4.2 TIME Protocol

One unconfirmed service (Write TIME) is defined. Write TIME

TIME Producer
0 request

Write TIME
L=6

TIME Consumer
Indication Indication Indication

Time Stamp

Figure 32: TIME Protocol Time Stamp: 6 bytes of the Time Stamp Object

9-37

APPLICATION LAYER 9.2.5 9.2.5.1 Emergency Object (EMCY) Emergency Object Usage

CANopen

CiA

Emergency objects are triggered by the occurrence of a device internal error situation and are transmitted from an emergency producer on the device. Emergency objects are suitable for interrupt type error alerts. An emergency object is transmitted only once per 'error event'. As long as no new errors occur on a device no further emergency objects must be transmitted. The emergency object may be received by zero or more emergency consumers. The reaction on the emergency consumer(s) is not specified and does not fall in the scope of this document. By means of this specification emergency error codes (Table 21) and the error register ( Table 47) are specified. Device specific additional information and the emergency condition do not fall into the scope of this specification. Table 21: Emergency Error Codes Error Code (hex) 00xx 10xx 20xx 21xx 22xx 23xx 30xx 31xx 32xx 33xx 40xx 41xx 42xx 50xx 60xx 61xx 62xx 63xx 70xx 80xx 81xx 8110 8120 8130 8140 82xx 8210 8220 90xx F0xx FFxx Voltage Mains Voltage Voltage inside the device Output Voltage Temperature Ambient Temperature Device Temperature Device Hardware Device Software Internal Software User Software Data Set Additional Modules Monitoring Communication CAN Overrun (Objects lost) CAN in Error Passive Mode Life Guard Error or Heartbeat Error recovered from bus off Protocol Error PDO not processed due to length error PDO length exceeded External Error Additional Functions Device specific Meaning Error Reset or No Error Generic Error Current Current, device input side Current inside the device Current, device output side

9-38

APPLICATION LAYER

CANopen

CiA

The emergency object is optional. If a device supports the emergency object, it has to support at least the two error codes 00xx and 10xx. All other error codes are optional. A device may be in one of two emergency states (Figure 33). Dependent on the transitions emergency objects will be transmitted. Links between the error state machine and the NMT state machine are defined in the device profiles. 0. After initialization the device enters the error free state if no error is detected. No error message is sent. 1. The device detects an internal error indicated in the first three bytes of the emergency message (error code and error register). The device enters the error state. An emergency object with the appropriate error code and error register is transmitted. The error code is filled in at the location of object 1003H (pre-defined error field). 2. One, but not all error reasons are gone. An emergency message containing error code 0000 (Error reset) may be transmitted together with the remaining errors in the error register and in the manufacturer specific error field. 3. A new error occurs on the device. The device remains in error state and transmits an emergency object with the appropriate error code. The new error code is filled in at the top of the array of error codes (1003H). It has to be guaranteed that the error codes are sorted in a timely manner (oldest error - highest sub-index, see Object 1003H). 4. All errors are repaired. The device enters the error free state and transmits an emergency object with the error code reset error / no error'.

error free 4

2 error occurred Figure 33: Emergency State Transition Diagram 9.2.5.2 Emergency Object Data The Emergency Telegram consists of 8 bytes with the data as shown in Figure 34: Emergency Object Data. Byte Content 0 1 2 Error register (Object 1001H) 3 4 5 6 7 3

Emergency Error Code (see Table 21)

Manufacturer specific Error Field

Figure 34: Emergency Object Data

9-39

APPLICATION LAYER 9.2.5.3 Emergency Object Services

CANopen

CiA

Emergency object transmission follows the producer consumer push model as described in 6.3.3. The following object attributes are specified for emergency objects: user type: notifying device: producer receiving devices: consumer data type: STRUCTURE OF UNSIGNED(16) emergency_error_code, UNSIGNED(8) error_register, ARRAY (5) of UNSIGNED(8) manufacturer_specific_error_field inhibit time: 9.2.5.4 Application specific Emergency Object Protocol

One unconfirmed service (Write EMCY) is defined. Write EMCY

EMCY Producer

Write EMCY
0 8

EMCY Consumer
Indication Indication Indication

Request

Emergency Object Data

Figure 35: Emergency Object Protocol Is is not allowed to request an Emergency Object by a remote transmission request (RTR).

9-40

APPLICATION LAYER 9.2.6 Network Management Objects

CANopen

CiA

The Network Management (NMT) is node oriented and follows a master-slave structure. NMT objects are used for executing NMT services. Through NMT services, nodes are initialised, started, monitored, resetted or stopped. All nodes are regarded as NMT slaves. An NMT Slave is uniquely identified in the network by its Node ID, a value in the range of [1..127]. NMT requires that one device in the network fulfils the function of the NMT Master. 9.2.6.1 9.2.6.1.1 NMT Services Module Control Services

Through Module Control Services, the NMT master controls the state of the NMT slaves. The state attribute is one of the values {STOPPED, PRE-OPERATIONAL, OPERATIONAL, INITIALISING}. The Module Control Services can be performed with a certain node or with all nodes simultaneously. The NMT master controls its own NMT state machine via local services, which are implementation dependent. The Module Control Services except Start Remote Node can be initiated by the local application. Start Remote Node Through this service the NMT Master sets the state of the selected NMT Slaves to OPERATIONAL. Table 22: Start Remote Node Parameter Argument Node_ID All Indication/Request Mandatory selection selection

The service is unconfirmed and mandatory. After completion of the service, the state of the selected remote nodes will be OPERATIONAL. Stop Remote Node Through this service the NMT Master sets the state of the selected NMT Slaves to STOPPED. Table 23: Stop Remote Node Parameter Argument Node _ID All Request/Indication Mandatory selection selection

The service is unconfirmed and mandatory. After completion of the service, the state of the selected remote nodes will be STOPPED. Enter Pre-Operational Through this service the NMT Master sets the state of the selected NMT Slave(s) to "PREOPERATIONAL". Table 24: Enter Pre-Operational Parameter Argument Node-ID All Request/Indication Mandatory selection selection

The service is unconfirmed and mandatory for all devices. After completion of the service, the state of the selected remote nodes will be PRE-OPERATIONAL.

9-41

APPLICATION LAYER Reset Node

CANopen

CiA

Through this service the NMT Master sets the state of the selected NMT Slave(s) from any state to the "reset application" sub-state. Table 25: Reset Node Parameter Argument Node-ID All Request/Indication Mandatory selection selection

The service is unconfirmed and mandatory for all devices. After completion of the service, the state of the selected remote nodes will be RESET APPLICATION. Reset Communication Through this service the NMT Master sets the state of the selected NMT Slave(s) from any state to the "reset communication" sub-state. After completion of the service, the state of the selected remote nodes will be RESET COMMUNICATION. Table 26: Reset Communication Parameter Argument Node-ID All Request/Indication Mandatory selection selection

The service is unconfirmed and mandatory for all devices. 9.2.6.1.2 Error Control Services Through Error control services the NMT detects failures in a CAN-based Network. Local errors in a node may e.g. lead to a reset or change of state. The definition of these local errors does not fall into the scope of this specification. Error Control services are achieved principally through periodically transmitting of messages by a device. There exist two possibilities to perform Error Control. The guarding is achieved through transmitting guarding requests (Node guarding protocol) by the NMT Master. If a NMT Slave has not responded within a defined span of time (node life time) or if the NMT Slaves communication status has changed, the NMT Master informs its NMT Master Application about that event. If Life guarding (NMT slave guarded NMT master) is supported, the slave uses the guard time and lifetime factor from its Object Dictionary to determine the node life time. If the NMT Slave is not guarded within its life time, the NMT Slave informs its local Application about that event. If guard time and life time factor are 0 (default values), the NMT Slave does not guard the NMT Master. Guarding starts for the slave when the first remote-transmit-request for its guarding identifier is received. This may be during the boot-up phase or later. The heartbeat mechanism for a device is established through cyclically transmitting a message by a heartbeat producer. One or more devices in the network are aware of this heartbeat message. If the heartbeat cycle fails for the heartbeat producer the local application on the heartbeat consumer will be informed about that event. The implementation of either guarding or heartbeat is mandatory. Node Guarding Event Through this service, the NMT service provider on the NMT Master indicates that a remote error occurred or has been resolved for the remote node identified by Node_ID.

9-42

APPLICATION LAYER

CANopen Table 27: Node Guarding Event

CiA

Parameter Argument Node_ID State Occurred Resolved The service is provider initiated and optional. Life Guarding Event

Indication Mandatory mandatory mandatory selection selection

Through this service, the NMT service provider on an NMT Slave indicates that a remote error occurred or has been resolved. Table 28: Life Guarding Event Parameter Argument State Occurred Resolved The service is provider initiated and optional. Heartbeat Event Through this service, the Heartbeat consumer indicates that a heartbeat error occurred or has been resolved for the node identified by Node_ID. Table 29: Heartbeat Event Parameter Argument Node_ID State Occurred Resolved The service is consumer initiated and optional. 9.2.6.1.3 Bootup Event Through this service, the NMT slave indicates that a local state transition occurred from the state INITIALISING to the state PRE-OPERATIONAL. Table 30: Bootup Event Parameter Argument None Indication Mandatory Bootup Service Indication Mandatory mandatory mandatory selection selection Indication Mandatory mandatory selection selection

The service is provider initiated and mandatory.

9-43

APPLICATION LAYER 9.2.6.2 9.2.6.2.1 NMT Protocols Module Control Protocols

CANopen

CiA

Start Remote Node Protocol This protocol is used to implement the 'Start Remote Node' service. NMT Master Request request Start Remote Node 0 CS=1 1 2 Node-ID NMT Slave(s) Indication(s) indication indication indication

COB-ID = 0

Figure 36: Start Remote Node Protocol cs: NMT command specifier 1: start Node-ID: the Node-ID of the NMT Slave as assigned by the NMT Master in the Node Connect Protocol, or 0. If 0, the protocol addresses all NMT Slaves.

Stop Remote Node Protocol This protocol is used to implement the 'Stop Remote Node' service. NMT Master Request request Stop Remote Node 0 CS=2 1 2 Node-ID NMT Slave(s) Indication(s) indication indication indication

COB-ID = 0

Figure 37: Stop Remote Node Protocol cs: NMT command specifier 2: stop Node-ID: the Node-ID of the NMT Slave as assigned by the NMT Master in the Node Connect Protocol, or 0. If 0, the protocol addresses all NMT Slaves.

9-44

APPLICATION LAYER Enter Pre-Operational Protocol

CANopen

CiA

The protocol is used to implement the 'Enter_Pre-Operational' service. NMT Master Request request Enter Pre-Operational 0 1 2 CS=128 Node-ID COB-ID = 0 NMT Slave(s) Indication(s) indication indication indication

Figure 38: Enter Pre-Operational Protocol cs: NMT command specifier

128: enter PRE-OPERATIONAL Node-ID: the Node-ID of the NMT Slave as assigned by the NMT Master in the Node Connect Protocol, or 0. If 0, the protocol addresses all NMT Slaves. Reset Node Protocol The protocol is used to implement the 'Reset Node' service. NMT Master Request request Reset Node 0 1 2 CS=129 Node-ID COB-ID = 0 NMT Slave(s) Indication(s) indication indication indication

Figure 39: Reset Node Protocol cs: NMT command specifier 129: Reset_Node Node-ID: the Node-ID of the NMT Slave as assigned by the NMT Master in the Node Connect Protocol, or 0. If 0, the protocol addresses all NMT Slaves.

9-45

APPLICATION LAYER Reset Communication Protocol

CANopen

CiA

The protocol is used to implement the 'Reset Communication' service. NMT Master Request request Reset Communication 0 1 2 CS=130 Node-ID COB-ID = 0 NMT Slave(s) Indication(s) indication indication indication

Figure 40: Reset Communication Protocol cs: NMT command specifier 130: Reset_Communication Node-ID: the Node-ID of the NMT Slave as assigned by the NMT Master in the Node Connect Protocol, or 0. If 0, the protocol addresses all NMT Slaves.

9-46

APPLICATION LAYER 9.2.6.2.2 Error Control Protocols

CANopen

CiA

Node Guarding Protocol This protocol is used to detect remote errors in the network. Each NMT Slave uses one remote COB for the Node Guarding Protocol. This protocol implements the provider initiated Error Control services. Node/Life Guarding NMT Master request Request COB-ID = 1792 + Node-ID
Remote transmit request

NMT Slave indication Indication(s)

0 7 t 6...0 s

confirm Node Guard time

response

COB-ID = 1792 + Node-ID


Remote transmit request

Node Life Time

request 0 confirm 7 t 6...0 s 1

indication

response

Node Guarding Event* indication


*if guarding error

Life Guarding Event* indication

Figure 41: Node Guarding Protocol s: the state of the NMT Slave 4: STOPPED 5: OPERATIONAL 127: PRE-OPERATIONAL t: toggle bit. The value of this bit must alternate between two consecutive responses from the NMT Slave. The value of the toggle-bit of the first response after the Guarding Protocol becomes active, is 0. The Toggle Bit in the guarding protocol is only resetted to 0 when reset_communication is passed (no other change of state resets the toggle bit). If a response is received with the same value of the toggle-bit as in the preceding response then the new response is handled as if it was not received. The NMT Master polls each NMT Slave at regular time intervals. This time-interval is called the guard time and may be different for each NMT Slave. The response of the NMT Slave contains the state of that NMT Slave. The node life time is given by the guard time multiplied by the life time factor. The node life time can be different for each NMT Slave. If the NMT Slave has not been polled during its life time, a remote node error is indicated through the 'Life Guarding Event' service. A remote node error is indicated through the 'Node guarding event' service if The remote transmit request is not confirmed within the node life time The reported NMT slave state does not match the expected state If it has been indicated that a remote error has occurred and the errors in the guarding protocol have disappeared, it will be indicated that the remote error has been resolved through the 'Node Guarding Event' and 'Life Guarding Event' services. 9-47

APPLICATION LAYER

CANopen

CiA

For the guard time, the life time factor and the COB-ID of the Node Guarding Protocol there are default values specified at the appropriate Object Dictionary entries. Heartbeat Protocol The Heartbeat Protocol defines an Error Control Service without need for remote frames. A Heartbeat Producer transmits a Heartbeat message cyclically. One or more Heartbeat Consumer receive the indication. The relationship between producer and consumer is configurable via the object dictionary. The Heartbeat Consumer guards the reception of the Heartbeat within the Heartbeat Consumer Time. If the Heartbeat is not received within the Heartbeat Consumer Time a Heartbeat Event will be generated. Write Heartbeat COB-ID = 1792 + Node-ID Heartbeat Producer request 0 s 1 Heartbeat Consumer indication indication indication Heartbeat Consumer Time indication indication indication

Heartbeat Producer Time 0 request s 1

Heartbeat Consumer Time

Heartbeat Event Figure 42: Heartbeat Protocol r: reserved (always 0) s: the state of the Heartbeat producer

0: BOOTUP 4: STOPPED 5: OPERATIONAL 127: PRE-OPERATIONAL If the Heartbeat Producer Time is configured on a device the Heartbeat Protocol begins immediately. If a device starts with a value for the Heartbeat Producer Time unequal to 0 the Heartbeat Protocol starts on the state transition from INITIALISING to PRE-OPERATIONAL. In this case the Bootup Message is regarded as first heartbeat message. It is not allowed for one device to use both error control mechanisms Guarding Protocol and Heartbeat Protocol at the same time. If the heartbeat producer time is unequal 0 the heartbeat protocol is used.

9-48

APPLICATION LAYER 9.2.6.2.3 Bootup Protocol

CANopen

CiA

This protocol is used to signal that a NMT slave has entered the node state PRE-OPERATIONAL after the state INITIALISING. The protocol uses the same identifier as the error control protocols. Bootup Event

NMT Master

COB-ID = 1792 + Node-ID 0 1 0

NMT Slave

indication

request

Figure 43: Bootup Protocol One data byte is transmitted with value 0. 9.3 9.3.1 Synchronisation of the SYNC Consumer Transmission of Synchronous PDO Messages

Synchronous transmission of a message means that the transmission of the message is fixed in time with respect to the transmission of the SYNC message. The synchronous message is transmitted within a given time window with respect to the SYNC transmission, and at most once for every period of the SYNC. In general the fixing of the transmission time of synchronous PDO messages coupled with the periodicity of transmission of the SYNC message guarantees that devices may arrange to sample process variables from a process environment and apply their actuation in a co-ordinated fashion. A device consuming SYNC messages will provide synchronous PDO messages too. The reception of a SYNC message controls the moment when the application will interact with the process environment according to the contents of a synchronous PDO. The synchronous mechanism is intended for transferring commanded values and actual values on a fixed timely base. In general a synchronous PDO with a commanded value will be received before a SYNC. The SYNC consuming device will actuate based on this synchronous PDO at the next SYNC message. The reception of a SYNC will also prompt a device operating in the cyclic mode to sample its feedback data and transmit a synchronous PDO with an actual value as soon as possible afterwards. Depending upon its capabilities, a device may also be parameterised with the time period synchronous window length after the SYNC at which it is guaranteed that its commanded value has arrived. It may therefore perform any processing on the commanded value which is required in order to actuate at the next SYNC message.

9-49

APPLICATION LAYER

CANopen

CiA

communication cycle period Synchronous window length SYNC Message SYNC Message

objects mapped in Actuate on synchronous RPDO objects mapped in last received synchronous RPDO

objects mapped in Actuate on synchronous RPDO objects mapped in last received synchronous RPDO

Actuation based on objects mapped in last received synchronous RPDO at next SYNC

Figure 44: Bus Synchronisation and Actuation


communication cycle period synchronous window length SYNC Message object mapped in synchronous TPDO SYNC Message object mapped in synchronous TPDO

Samples immediately taken at SYNC for objects mapped in synchronous TPDO

Figure 45: Bus Synchronisation and Sampling 9.3.2 Optional High Resolution Synchronisation Protocol

The synchronisation message carries no data and is easy to generate. However, the jitter of this SYNC depends on the bit rate of the bus as even the very high priority SYNC has to wait for the current message on the bus to be transmitted before it gains bus access. Some time critical applications especially in large networks with reduced transmission rates require more accurate synchronisation; it may be necessary to synchronise the local clocks with an accuracy in the order of microseconds. This is achieved by using the optional high resolution synchronisation protocol which employs a special form of time stamp message (see Figure 46) to adjust the inevitable drift of the local clocks. The SYNC producer time-stamps the interrupt generated at t1 by the successful transmission of the SYNC message (this takes until t2). After that (at t4) he sends a time-stamp message containing the corrected time-stamp (t1) for the SYNC transmission success indication. The SYNC consumer that have taken local time-stamps (t3) on the reception (t1) of the SYNC can now compare their corrected time-stamp (t1) with the one received in the time-stamp message from the SYNC producer. The difference between these values determines the amount of time to adjust the local clock. With this protocol only the local latencies (t2-t1 on the SYNC producer and t3-t1 on the SYNC consumer ) are time critical. These latencies depend on local parameters (like interrupt processing times and hardware delays) on the nodes which have to be determined once. The accuracy of this determination 9-50

APPLICATION LAYER

CANopen

CiA

is implementation specific, it forms the limiting factor of the synchronisation (or clock adjustment) accuracy. Note that each node only has to know its own latency time as the time-stamp message contains the corrected value t1 and not t2. The time-stamp is encoded as UNSIGNED32 with a resolution of 1 microsecond which means that the time counter restarts every 72 minutes. It is configured by mapping the high resolution time-stamp into a PDO. It is reasonable to repeat the clock adjustment only when the maximum drift of the local clock exceeds the synchronisation accuracy. For most implementations this means that it is sufficient to add this time-stamp message to the standard SYNC once every second. This principle enables the best accuracy that can be achieved with bus-based synchronisation, especially when implemented on CAN controllers that support time-stamping. Note that the accuracy is widely independent of the transmission rate. Further improvement requires separate hardware (e.g. wiring).

SYNC master slave time t1 t2 t3 t4

TIMESTAMP

t5

Figure 46: Optional High Resolution Synchronisation Protocol

9-51

APPLICATION LAYER 9.4 9.4.1

CANopen

CiA

Network Initialisation and System Boot-Up Initialisation Procedure

In Figure 47 the general flow chart of the network initialisation process, controlled by a NMT Master Application or Configuration Application is shown. Configuration of all device parameters, including communication parameters (via Default SDO)

(Optional) start transmission of SYNC, wait for synchronisation of all devices

(Optional) Start of Node Guarding

Setting of all nodes to the operational state

Figure 47: Flow Chart of the Network Initialisation Process In step A the devices are in the node state PRE-OPERATIONAL which is entered automatically after power-on. In this state the devices are accessible via their Default-SDO using identifiers that have been assigned according to the Predefined Connection Set. In this step the configuration of device parameters takes place on all nodes which support parameter configuration. This is done from a Configuration Application or Tool which resides on the node that is the client for the default SDOs. For devices that support these features the selection and/or configuration of PDOs, the mapping of application objects (PDO mapping), the configuration of additional SDOs and optionally the setting of COB-IDs may be performed via the Default-SDO objects. In many cases a configuration is not even necessary as default values are defined for all application and communication parameters. If the application requires the synchronisation of all or some nodes in the network, the appropriate mechanisms can be initiated in the optional Step B. It can be used to ensure that all nodes are synchronised by the SYNC object before entering the node state OPERATIONAL in step D. The first transmission of SYNC object starts within 1 sync cycle after entering the PRE-OPERATIONAL state. In Step C Node guarding can be activated (if supported) using the guarding parameters configured in step A. With step D all nodes are enabled to communicate via their PDO objects. 9.4.2 9.4.2.1 NMT State Machine Overview

In Figure 48 the state diagram of a device is shown. Devices enter the PRE-OPERATIONAL state directly after finishing the device initialisation. During this state device parameterisation and IDallocation via SDO (e.g. using a configuration tool) is possible. Then the nodes can be switched directly into the OPERATIONAL state. The NMT state machine determines the behaviour of the Communication function unit (see 6.2). The coupling of the application state machine to the NMT state machine is device dependent and falls into the scope of device profiles.

9-52

APPLICATION LAYER

CANopen

CiA

Minimal Boot-Up consists of one CAN telegram: a broadcast Start_Remote_Node message. Figure 48: State Diagram of a Device Power on or Hardware Reset (1) Initialisation (2) (14) Pre-Operational (7) (13) (3) (12) Operational (4) (5) (6) (8) Stopped (9) (10) (11)

Table 31: Trigger for State Transition (1) (2) (3),(6) (4),(7) (5),(8) (9),(10),(11) At Power on the initialisation state is entered autonomously Initialisation finished - enter PRE-OPERATIONAL automatically Start_Remote_Node indication Enter_PRE-OPERATIONAL_State indication Stop_Remote_Node indication Reset_Node indication

(12),(13),(14) Reset_Communication indication

9-53

APPLICATION LAYER 9.4.2.2 9.4.2.2.1 States Initialisation

CANopen

CiA

The initialisation state is divided into three sub-states (see Figure 49) in order to enable a complete or partial reset of a node. 1. Reset_Application: In this state the parameters of the manufacturer specific profile area and of the standardised device profile area are set to their power-on values. After setting of the power-on values the state Reset_Communication is entered autonomously. 2. Reset_Communication: In this state the parameters of the communication profile area are set to their power-on values. After this the state Initialising is entered autonomously. 3. Initialising: This is the first sub-state the device enters after power-on or hardware reset. After finishing the basic node initialisation the device executes the write boot-up object service and enters the state PRE-OPERATIONAL autonomously. Power-on values are the last stored parameters. If storing is not supported or has not been executed or if the reset was preceded by a restore_default command (object 1011H), the power-on values are the default values according to the communication and device profile specifications.

Reset Application Initialisation (15) Reset Communication (16) (11) (14) (13) (12) (2) (12),(13),(14) (9),(10)(11) (15) (16) power-on or hardware reset (2) Initialising (10) (9)

Initialisation finished - enter PRE-OPERATIONAL automatically Reset_Communication indication Reset_Node indication Application Reset performed Communication Reset performed Figure 49: Structure of the Initialisation state

9-54

APPLICATION LAYER 9.4.2.2.2 Pre-Operational

CANopen

CiA

In the PRE-OPERATIONAL state, communication via SDOs is possible. PDO communication is not allowed. Configuration of PDOs, device parameters and also the allocation of application objects (PDO-mapping) may be performed by a configuration application. The node may be switched into the operational state directly by sending a Start_Remote_Node request. 9.4.2.2.3 Operational In the OPERATIONAL state all communication objects are active. Object Dictionary Access via SDO is possible. Implementation aspects or the application state machine however may require to limit the access to certain objects whilst being operational, e.g. an object may contain the application program which cannot be changed during execution. 9.4.2.2.4 Stopped By switching a device into the Stopped state it is forced to stop the communication altogether (except node guarding and heartbeat, if active). Furthermore, this state can be used to achieve certain application behaviour. The definition of this behaviour falls into the scope of device profiles. 9.4.2.3 States and Communication Object Relation Table 32 shows the relation between communication states and communication objects. Services on the listed communication objects may only be executed if the devices involved in the communication are in the appropriate communication states. Table 32: States and Communication Objects INITIALISING PDO SDO Synchronisation Object Time Stamp Object Emergency Object Boot-Up Object Network Management Objects PRE-OPERATIONAL OPERATIONAL STOPPED

X X X X X X X X X X X X X

9.4.2.4

State Transitions

State transitions are caused by reception of an NMT object used for module control services hardware reset Module Control Services locally initiated by application events, defined by device profiles 9.4.3 Pre-Defined Connection Set

In order to reduce configuration effort for simple networks a mandatory default identifier allocation scheme is defined. These identifiers are available in the PRE-OPERATIONAL state directly after initialisation (if no modifications have been stored). The identifiers of SYNC, TIME STAMP, EMERGENCY and PDOs may be modified by means of dynamic distribution. A device has to provide the corresponding identifiers only for the supported communication objects. The default profile ID-allocation scheme (Table 33 and Table 34) consists of a functional part, which determines the object priority and a Node-ID-part, which allows to distinguish between devices of the same functionality. This allows a peer-to-peer communication between a single master device and up

9-55

APPLICATION LAYER

CANopen

CiA

to 127 slave devices. It also supports the broadcasting of non-confirmed NMT-objects, SYNC- and TIME-STAMP-objects. Broadcasting is indicated by a Node-ID of zero. The pre-defined connection set supports one emergency object, one SDO, at maximum 4 ReceivePDOs (RPDO) and 4 Transmit-PDOs (TPDO) and the NMT objects. Bit-No.: COB-Identifier 10 0

Function Code

Node-ID

Figure 50: Identifier allocation scheme for the pre-defined connection set Table 33 and Table 34 show the supported objects and their allocated COB-IDs. Table 33: Broadcast Objects of the Pre-defined Connection Set object NMT SYNC TIME STAMP function code (binary) 0000 0001 0010 resulting COB-ID 0 128 (80h) 256 (100h) Communication Parameters at Index 1005h, 1006h, 1007h 1012h, 1013h

Table 34: Peer-to-Peer Objects of the Pre-defined Connection Set object EMERGENCY PDO1 (tx) PDO1 (rx) PDO2 (tx) PDO2 (rx) PDO3 (tx) PDO3 (rx) PDO4 (tx) PDO4 (rx) SDO (tx) SDO (rx) NMT Error Control function code (binary) 0001 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1110 Resulting COB-IDs
129 (81h) 255 (FFh) 385 (181h) 511 (1FFh) 513 (201h) 639 (27Fh) 641 (281h) 767 (2FFh) 769 (301h) 895 (37Fh) 897 (381h) 1023 (3FFh) 1025 (401h) 1151 (47Fh) 1153 (481h) 1279 (4FFh) 1281 (501h) 1407 (57Fh) 1409 (581h) 1535 (5FFh) 1537 (601h) 1663 (67Fh) 1793 (701h) 1919 (77Fh)

Communication Parameters at Index 1014h, 1015h 1800h 1400h 1801h 1401h 1802h 1402h 1803h 1403h 1200h 1200h 1016h, 1017h

Table 34 has to be seen from the devices point of view. The pre-defined connection set always applies to the standard CAN frame with 11-bit Identifier, even if extended CAN frames are present in the network. 9.5 9.5.1 Object Dictionary General Structure of the Object Dictionary

This section details the Object Dictionary structure and entries which are common to all devices. The format of the Object Dictionary entries is shown in Table 35 below: Table 35: Format of Object Dictionary Headings Index (hex) Object (Symbolic Name) Name Type Attrib. M/O

The complete Object Dictionary consists of the six columns shown above. The Index column denotes the objects position within the Object Dictionary. This acts as a kind of address to reference the desired data field. The sub-index is not specified here. The sub-index is used to reference data fields within a complex object such as an array or record. 9-56

APPLICATION LAYER

CANopen

CiA

The Object column contains the Object Name according to Table 36 below and is used to denote what kind of object is at that particular index within the Object Dictionary. The following definitions are used: Table 36: Object Dictionary Object Definitions Object Name NULL DOMAIN DEFTYPE Comments A dictionary entry with no data fields Large variable amount of data e.g. executable program code Denotes a type definition such as a Boolean, UNSIGNED16, float and so on Defines a new record type e.g. the PDOMapping structure at 21h A single value such UNSIGNED8, Boolean, Integer16, visible string etc. as an float, Object Code 0 2 5

DEFSTRUCT VAR

6 7

ARRAY

A multiple data field object where each data field is a simple variable of the SAME basic data type e.g. array of UNSIGNED16 etc. Sub-index 0 is of UNSIGNED8 and therefore not part of the ARRAY data A multiple data field object where the data fields may be any combination of simple variables. Sub-index 0 is of UNSIGNED8 and therefore not part of the RECORD data

RECORD

The name column provides a simple textual description of the function of that particular object. The type column gives information as to the type of the object. These include the following pre-defined types: BOOLEAN, floating point number, UNSIGNED Integer, Signed Integer, visible/octet string, timeof-day, time-difference and DOMAIN (see 9.1). It also includes the pre-defined complex data type PDOMapping and may also include others which are either manufacturer or device specific. It is not possible to define records of records, arrays of records or records with arrays as fields of that record. In the case where an object is an array or a record the sub-index is used to reference one data field within the object. The Attribute column defines the access rights for a particular object. It can be of the following: Table 37: Access Attributes for Data Objects Attribute rw wo ro Const Description read and write access write only access read only access read only access, value is constant

Optional objects listed in the Object Dictionary with the Attribute rw may be implemented as read only. Exceptions are defined in the detailed object specification. The M/O column defines whether the object is Mandatory or Optional. A mandatory object must be implemented on a device. An optional object needs not to be implemented on a device. The support of certain objects or features however may require the implementation of related objects. In this case, the relations are described in the detailed object specification.

9-57

APPLICATION LAYER 9.5.2 Dictionary Components

CANopen

CiA

The overall layout of the Object Dictionary is shown in Table 38. Index 01h - 1Fh contain the standard data types, index 20h - 23h contain predefined complex data types. The range of indices from 24h - 3Fh is not defined yet but reserved for future standard data structures. The range of indices from 40h - 5Fh is free for manufacturers to define own complex data types. The range 60h - 7Fh contains device profile specific standard data types. From 80h 9Fh device profile specific complex data types are defined. The range A0h 25Fh is reserved for the data type definitions for Multiple Device Modules similar to the entries 60h 9Fh. The entries form 360h FFFh are reserved for possible future enhancements . The range 1000h - 1FFFh contains the communication specific Object Dictionary entries. These parameters are called communication entries, their specification is common to all device types, regardless of the device profile they use. The objects in range 1000h - 1FFFh not specified by this document are reserved for further use. The range 2000h - 5FFFh is free for manufacturer specific profile definition. The range 6000h - 9FFFh contains the standardised device profile parameters. The range A000h FFFFh is reserved for future use. 9.5.3 Data Type Entry Specification

The static data types are placed in the Object Dictionary for definition purposes only. However, indices in the range 0001h - 0007h can be mapped as well in order to define the appropriate space in the RPDO as not being used by this device (do not care). The order of the data types is as follows: Table 38: Object Dictionary Data Types Index 0001 0002 0003 0004 0005 0006 0007 0008 0009 000A 000B 000C 000D 000E 000F 0010 0011 0012 0013 0014 0015 0016 0017 0018 DEFTYPE Object DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE Name BOOLEAN INTEGER8 INTEGER16 INTEGER32 UNSIGNED8 UNSIGNED16 UNSIGNED32 REAL32 VISIBLE_STRING OCTET_STRING UNICODE_STRING TIME_OF_DAY TIME_DIFFERENCE BIT_STRING DOMAIN INTEGER24 REAL64 INTEGER40 INTEGER48 INTEGER56 INTEGER64 UNSIGNED24 reserved UNSIGNED40 9-58

APPLICATION LAYER 0019 001A 001B 001C-001F 0020 0021 0022 0023 0024-003F 0040-005F 0060-007F 0080-009F 00A0-00BF 00C0-00DF 00E0-00FF 0100-011F 0120-013F 0140-015F 0160-017F 0180-019F 01A0-01BF 01C0-01DF 01E0-01FF 0200-021F 0220-023F 0240-025F DEFSTRUCT DEFTYPE DEFSTRUCT DEFTYPE DEFSTRUCT DEFTYPE DEFSTRUCT DEFTYPE DEFSTRUCT DEFTYPE DEFSTRUCT DEFTYPE DEFSTRUCT DEFTYPE DEFSTRUCT DEFTYPE DEFSTRUCT DEFSTRUCT DEFSTRUCT DEFSTRUCT DEFSTRUCT DEFTYPE DEFTYPE DEFTYPE

CANopen UNSIGNED48 UNSIGNED56 UNSIGNED64 reserved PDO_COMMUNICATION_PARAMETER PDO_MAPPING SDO_PARAMETER IDENTITY reserved Manufacturer Specific Complex Data Types
Device Profile (0) Specific Standard Data Types Device Profile (0) Specific Complex Data Types Device Profile 1 Specific Standard Data Types Device Profile 1 Specific Complex Data Types Device Profile 2 Specific Standard Data Types Device Profile 2 Specific Complex Data Types Device Profile 3 Specific Standard Data Types Device Profile 3 Specific Complex Data Types Device Profile 4 Specific Standard Data Types Device Profile 4 Specific Complex Data Types Device Profile 5 Specific Standard Data Types Device Profile 5 Specific Complex Data Types Device Profile 6 Specific Standard Data Types Device Profile 6 Specific Complex Data Types Device Profile 7 Specific Standard Data Types Device Profile 7 Specific Complex Data Types

CiA

The data type representations used are detailed in 9.1. Every device does not need to support all the defined data types. A device only has to support the data types it uses with the objects in the range 1000h - 9FFFh. The predefined complex data-types are placed after the standard data-types. Four types are defined at present, the PDO CommPar record (PDO_COMMUNICATION_PARAMETER), the PDO Mapping record (PDO_MAPPING), the SDO Parameter record (SDO_PARAMETER) and the Identity record (IDENTITY). They are placed at index 20h, 21h, 22h and 23h. For devices or device profiles that provide Multiple Device Modules like multiple axis controllers e.g. the DEFTYPE / DEFSTRUCT mechanism is enhanced for each virtual device with an offset of 40h for up to 7 additional virtual devices. A device may optionally provide the length of the standard data types encoded as UNSIGNED32 at read access to the index that refers to the data type. E.g. index 000Ch (Time of Day) contains the value 30h=48dec as the data type Time of Day is encoded using a bit sequence of 48 bit. If the length is variable (e.g. 000Fh = Domain), the entry contains 0h. For the supported complex data types a device may optionally provide the structure of that data type at read access to the corresponding data type index. Sub-index 0 then provides the number of entries at this index not counting sub-indices 0 and 255 and the following sub-indices contain the data type according to Table 38 encoded as UNSIGNED8. The entry at Index 20h describing the structure of the PDO Communication Parameter then looks as follows (see also objects 1400h 15FFh):

9-59

APPLICATION LAYER

CANopen Table 39: complex data type example

CiA

Subindex 0h 1h 2h 3h 4h

Value 04h 07h 05h 06h 05h

(Description) (4 sub indices follow) (UNSIGNED32) (UNSIGNED8) (UNSIGNED16) (UNSIGNED8)

Standard (simple) and complex manufacturer specific data types can be distinguished by attempting to read sub-index 1h: At a complex data type the device returns a value and sub-index 0h contains the number of sub-indices that follow, at a standard data type the device aborts the SDO transfer as no sub-index 1h available. Note that some entries of data type UNSIGNED32 have the character of a structure (e.g. PDO COBID entry, see Figure 65). 9.5.3.1 Organisation of structured Object Dictionary Entries If an Object Dictionary entry (index) contains several sub-indices, then sub-index 0 describes the highest available sub-index that follows, not considering FFh. This entry is encoded as UNSIGNED8. Sub-index FFh describes the structure of the entry by providing the data type and the object type of the entry. It is encoded as UNSIGNED32 and organised as follows: MSB Bits 31-16 Value Reserved (value: 00 00h) 15-8 Data Type (see Table 38) Encoded as UNSIGNED8 LSB 7-0 Object (see Table 36) UNSIGNED8

Figure 51: structure sub-index FFh It is optional to support sub-index FFh. If it is supported throughout the Object Dictionary and the structure of the complex data types is provided as well, it enables one to upload the entire structure of the Object Dictionary. 9.5.4 Specification of Predefined Complex Data Types

This section describes the structure of the predefined complex data types used for communication. The value range and the meaning is explained at the detailed description of the objects using these types. 9.5.4.1 PDO Communication Paramter Record Specification Table 40: PDO Communication Parameter Record Index 0020h Sub-Index 0h 1h 2h 3h 4h 5h
Field in PDO Communication Parameter Record

Data Type UNSIGNED8 UNSIGNED32 UNSIGNED8 UNSIGNED16 UNSIGNED8 UNSIGNED16

number of supported entries in the record COB-ID transmission type inhibit time reserved event timer

9-60

APPLICATION LAYER 9.5.4.2

CANopen

CiA

PDO Mapping Parameter Record Specification Table 41: PDO Mapping Parameter Record Index 0021h Sub-Index 0h 1h 2h ::: :: :::::: 40h
Field in PDO Parameter Mapping Record

Data Type UNSIGNED8 UNSIGNED32 UNSIGNED32 :::::: UNSIGNED32

number of mapped objects in PDO 1st object to be mapped 2


nd

object to be mapped

:::::::: 64 object to be mapped


th

9.5.4.3

SDO Parameter Record Specification Table 42: SDO Parameter Record Index 0022h Sub-Index 0h 1h 2h 3h Field in SDO Parameter Record number of supported entries COB-ID client -> server COB-ID server -> client node ID of SDOs client resp. server Data Type UNSIGNED8 UNSIGNED32 UNSIGNED32 UNSIGNED8

9.5.4.4

Identity Record Specification Table 43: Identity Record Index 0023h Sub-Index 0h 1h 2h 3h 4h Field in Identity Record number of supported entries Vendor-ID Product code Revision number Serial number Data Type UNSIGNED8 UNSIGNED32 UNSIGNED32 UNSIGNED32 UNSIGNED32

9.6 9.6.1

Communication Profile Specification Detailed Object Specification

The structure of the Object Dictionary entries is described in the following manner: All device, interface and application profiles based on this communication profile have to follow this structure. Table 44: Format of an Object Description OBJECT DESCRIPTION INDEX Name Object Code Data Type Category Profile Index Number Name of parameter Variable classification Data type classification Optional or Mandatory

The Object Code must be one of those defined in OBJECT DESCRIPTION Table 44 above. For better readability, the Object Description additionally contains the symbolic Object Name. 9-61

APPLICATION LAYER

CANopen

CiA

Table 45: Object Value Description Format ENTRY DESCRIPTION Sub-Index Description Data Type Entry Category Access Number of sub-indices being described (field only used for Arrays, Records and Structures) Descriptive name of the Sub-Index (field only used for Arrays, Records and Structures) Data type classification (field only used for Records and Structures) Specifies if the Entry is Optional or Mandatory or Conditional in case the Object is present Read Only (ro) or Read/Write (rw) or Write Only (wo) or Const. In OPERATIONAL state the Access to Object Dictionary Entries may be limited, e.g set to ro. Optional/Default/No - can this object be mapped to a PDO. Description: Optional: Object may be mapped into a PDO Default: Object is part of the default mapping (see device profile) No: Value Range Default Value No: Value: Object must not be mapped into a PDO not defined by this specification default value of an object after device initialisation range of possible values, or name of data type for full range

PDO Mapping

For simple variables the value description appears once without the sub-index field and entry category. For complex data types the value description must be defined for each element (sub-index). 9.6.2 Overview Object Dictionary Entries for Communication Table 46: Standard Objects
Index (hex) 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 100A 100B 100C 100D 100E 100F VAR VAR guard time life time factor VAR VAR VAR VAR VAR VAR COB-ID SYNC communication cycle period synchronous window length manufacturer device name manufacturer hardware version manufacturer software version Object (Symbolic Name) VAR VAR VAR ARRAY device type error register manufacturer status register pre-defined error field UNSIGNED32 UNSIGNED8 UNSIGNED32 UNSIGNED32 UNSIGNED32 UNSIGNED32 UNSIGNED32 Vis-String Vis-String Vis-String UNSIGNED16 UNSIGNED8 reserved for compatibility reasons reserved for compatibility reasons ro ro ro ro rw rw rw const const const rw rw M M O O O O O O O O O O Name Type Acc.1 M/O

Table 46 gives an overview over the Object Dictionary entries defined by the communication profile:

reserved for compatibility reasons

reserved for compatibility reasons

Access type listed here may vary for certain sub-indices. See detailed object specification. 9-62

APPLICATION LAYER
1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 ::::: 11FF 1200 1201 ::::: 127F 1280 1281 ::::: 12FF 1300 ::::: 13FF 1400 1401 ::::: 15FF 1600 1601 ::::: 17FF 1800 1801 ::::: 19FF 1A00 1A01 ::::: 1BFF RECORD RECORD ::::: RECORD RECORD RECORD ::::: RECORD RECORD RECORD ::::: RECORD RECORD RECORD ::::: RECORD ::::: RECORD RECORD ::::: RECORD RECORD RECORD ::::: RECORD ::::: ARRAY ARRAY VAR VAR VAR VAR ARRAY VAR RECORD store parameters

CANopen
UNSIGNED32 UNSIGNED32 UNSIGNED32 UNSIGNED32 UNSIGNED32 UNSIGNED16 UNSIGNED32 UNSIGNED16 Identity (23h) ::::: Server SDO Parameter 1 Server SDO parameter 2
nd st

CiA
rw rw rw rw rw rw rw rw ro ::::: O O O O O O O O M :::::

restore default parameters COB-ID TIME high resolution time stamp COB-ID EMCY Inhibit Time EMCY Consumer heartbeat time Producer heartbeat time Identity Object reserved ::::: reserved

SDO Parameter (22h) SDO Parameter (22h) ::::: SDO Parameter (22h) SDO Parameter (22h) SDO Parameter (22h) ::::: SDO Parameter (22h) :::::

ro rw ::::: rw rw rw ::::: rw :::::

O M/O** ::::: M/O** M/O** M/O** ::::: M/O** :::::

Server SDO parameter


th

::::: 128 Server SDO parameter 1 Client SDO parameter 2


nd st

Client SDO Parameter Client SDO parameter


th

::::: 128 Client SDO parameter reserved ::::: reserved

Receive PDO Communication Parameter 1 receive PDO Parameter 2


nd st

PDO CommPar (20h) PDO CommPar (20h) :::::

rw ::::: rw rw rw ::::: rw rw rw ::::: rw rw rw ::::: rw

M/O* M/O* ::::: M/O* M/O* M/O* ::::: M/O* M/O* M/O* :::: M/O* M/O* M/O* ::::: M/O*

receive PDO Parameter


th

::::: 512 receive PDO Parameter 1 receive PDO mapping 2


nd st

PDO CommPar (20h) PDO Mapping (21h) PDO Mapping (21h) ::::: PDO Mapping (21h) PDO CommPar (20h) PDO CommPar (20h) ::::: PDO CommPar (20h) PDO Mapping (21h) PDO Mapping (21h) ::::: PDO Mapping (21h)

Receive PDO Mapping Parameter receive PDO mapping


th

::::: 512 receive PDO mapping 1 transmit PDO Parameter 2


nd st

Transmit PDO Communication Parameter transmit PDO Parameter


th

::::: 512 transmit PDO Parameter 1 transmit PDO mapping 2


nd st

Transmit PDO Mapping Parameter transmit PDO mapping


th

::::: 512 transmit PDO mapping

* If a device supports PDOs, the according PDO communication parameter and PDO mapping entries in the Object Dictionary are mandatory. These may be read_only. ** If a device supports SDOs, the according SDO parameters in the Object Dictionary are mandatory. 9-63

APPLICATION LAYER 9.6.3

CANopen

CiA

Detailed Specification of Communication Profile specific Objects

Object 1000h: Device Type Contains information about the device type. The object at index 1000h describes the type of device and its functionality. It is composed of a 16-bit field which describes the device profile that is used and a second 16-bit field which gives additional information about optional functionality of the device. The Additional Information parameter is device profile specific. Its specification does not fall within the scope of this document, it is defined in the appropriate device profile. For multiple device modules the Additional Information parameter contains FFFFh and the device profile number referenced by object 1000h is the device profile of the first device in the Object Dictionary. All other devices of a multiple device module identify their profiles at objects 67FFh + x*800h with x = internal number of the device (0 7) . These entries describe the device type of the preceding device. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category ENTRY DESCRIPTION Access PDO Mapping Value Range Default Value Byte: MSB Additional Information Device Profile Number

1000h device type VAR UNSIGNED32 Mandatory

ro No UNSIGNED32 No LSB

Figure 52: Structure of the Device Type Parameter Object 1001h: Error Register This object is an error register for the device. The device can map internal errors in this byte. This entry is mandatory for all devices. It is a part of an Emergency object. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category ENTRY DESCRIPTION Access PDO Mapping Value Range Default Value ro Optional UNSIGNED8 No 1001h error register VAR UNSIGNED8 Mandatory

9-64

APPLICATION LAYER

CANopen Table 47: Structure of the Error Register

CiA

Bit 0 1 2 3 4 5 6 7

M/O M O O O O O O O

Meaning generic error current voltage temperature communication error (overrun, error state) device profile specific Reserved (always 0) manufacturer specific

If a bit is set to 1 the specified error has occurred. The only mandatory error that has to be signalled is the generic error. The generic error is signaled at any error situation. Object 1002h: Manufacturer Status Register This object is a common status register for manufacturer specific purposes. In this document only the size and the location of this object is defined. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category ENTRY DESCRIPTION Access PDO Mapping Value Range Default Value Object 1003h: Pre-defined Error Field The object at index 1003h holds the errors that have occurred on the device and have been signaled via the Emergency Object. In doing so it provides an error history. 1. The entry at sub-index 0 contains the number of actual errors that are recorded in the array starting at sub-index 1. 2. Every new error is stored at sub-index 1, the older ones move down the list. 3. Writing a 0 to sub-index 0 deletes the entire error history (empties the array). 4. The error numbers are of type UNSIGNED32 (see Table 7-18) and are composed of a 16 bit error code and a 16 bit additional error information field which is manufacturer specific. The error code is contained in the lower 2 bytes (LSB) and the additional information is included in the upper 2 bytes (MSB). If this object is supported it must consist of two entries at least. The length entry on subindex 0h and at least one error entry at sub-index 1H. Byte: MSB Additional Information Error code LSB ro Optional UNSIGNED32 No 1002h manufacturer status register VAR UNSIGNED32 Optional

Figure 53: Structure of the pre-defined error field

9-65

APPLICATION LAYER OBJECT DESCRIPTION INDEX Name Object Code Data Type Category ENTRY DESCRIPTION Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value

CANopen

CiA

1003h pre-defined error field ARRAY UNSIGNED32 Optional

0h number of errors Mandatory rw No 0 - 254 0 1h standard error field Mandatory ro No UNSIGNED32 No 2h - FEh standard error field Optional ro No UNSIGNED32 No

Object 1005h: COB-ID SYNC message Index 1005h defines the COB-ID of the Synchronisation Object (SYNC). Further, it defines whether the device generates the SYNC. The structure of this object is shown in Figure 54 and Table 48. UNSIGNED32 MSB bits 11-bit-ID 29-bit-ID 31 X X 30 29 28-11
000000000000000000

LSB 10-0 11-bit Identifier 0/1 0 0/1 1

29 -bit Identifier

Figure 54: Structure of SYNC COB-ID entry

9-66

APPLICATION LAYER

CANopen Table 48: Description of SYNC COB-ID entry

CiA

bit number 31 (MSB) 30 29 28 11 10-0 (LSB)

value X 0 1 0 1 0 X X

meaning do not care Device does not generate SYNC message Device generates SYNC message 11-bit ID (CAN 2.0A) 29-bit ID (CAN 2.0B) if bit 29=0 if bit 29=1: bits 28-11 of 29-bit-SYNC-COB-ID bits 10-0 of SYNC-COB-ID

Bits 29, 30 may be static (not changeable). If a device is not able to generate SYNC messages, an attempt to set bit 30 is responded with an abort message (abort code: 06090030h). Devices supporting the standard CAN frame type only either ignore attempts to change bit 29 or respond with an abort message (abort code: 06090030h). The first transmission of SYNC object starts within 1 sync cycle after setting Bit 30 to 1. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category 1005h COB-ID SYNC VAR UNSIGNED32 Conditional; Mandatory, if PDO communication on a synchronous base is supported ENTRY DESCRIPTION Access PDO Mapping Value Range Default Value rw No UNSIGNED32 80h or 8000 0080h

Object 1006h: Communication Cycle Period This object defines the communication cycle period in ms. This period defines the SYNC interval. It is 0 if not used. If the communication cycle period on sync producer is changed to a new value unequal 0 the transmission of sync object resumes within 1 sync cycle of the new value. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category 1006h communication cycle period VAR UNSIGNED32 Conditional; Mandatory for Sync producers

9-67

APPLICATION LAYER ENTRY DESCRIPTION Access PDO Mapping Value Range Default Value Object 1007h: Synchronous Window Length

CANopen

CiA

rw No UNSIGNED32 0

Contains the length of the time window for synchronous PDOs in ms. It is 0 if not used. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category ENTRY DESCRIPTION Access PDO Mapping Value Range Default Value Object 1008h: Manufacturer Device Name Contains the manufacturer device name. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category ENTRY DESCRIPTION Access PDO Mapping Value Range Default Value Object 1009h: Manufacturer Hardware Version Contains the manufacturer hardware version description. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category 1009h manufacturer hardware version VAR Visible String Optional const No No No 1008h manufacturer device name VAR Visible String Optional rw No UNSIGNED32 0 1007h synchronous window length VAR UNSIGNED32 Optional

9-68

APPLICATION LAYER ENTRY DESCRIPTION Access PDO Mapping Value Range Default Value

CANopen

CiA

const No No No

Object 100Ah: Manufacturer Software Version Contains the manufacturer software version description. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category ENTRY DESCRIPTION Access PDO Mapping Value Range Default Value Object 100Ch: Guard Time The objects at index 100Ch and 100Dh include the guard time in milliseconds and the life time factor. The life time factor multiplied with the guard time gives the life time for the Life Guarding Protocol. It is 0 if not used. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category 100Ch guard time VAR UNSIGNED16 Conditional; Mandatory, if heartbeat is not supported ENTRY DESCRIPTION Access PDO Mapping Value Range Default Value rw; ro, if life guarding is not supported No UNSIGNED16 0 const No No No 100Ah manufacturer software version VAR Visible String Optional

9-69

APPLICATION LAYER Object 100Dh: Life Time Factor

CANopen

CiA

The life time factor multiplied with the guard time gives the life time for the node guarding protocol. It is 0 if not used. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category 100Dh life time factor VAR UNSIGNED8 Conditional; Mandatory, if heartbeat is not supported ENTRY DESCRIPTION Access PDO Mapping Value Range Default Value Object 1010h: Store parameters This object supports the saving of parameters in non volatile memory. By read access the device provides information about its saving capabilities. Several parameter groups are distinguished: Sub-Index 0 contains the largest Sub-Index that is supported. Sub-Index 1 refers to all parameters that can be stored on the device. Sub-Index 2 refers to communication related parameters (Index 1000h - 1FFFh manufacturer specific communication parameters). Sub-Index 3 refers to application related parameters (Index 6000h - 9FFFh manufacturer specific application parameters). At Sub-Index 4 - 127 manufacturers may store their choice of parameters individually. Sub-Index 128 - 254 are reserved for future use. In order to avoid storage of parameters by mistake, storage is only executed when a specific signature is written to the appropriate Sub-Index. The signature is save. Signature ISO 8859 (ASCII) hex MSB e 65h v 76h a 61h LSB s 73h rw; ro, if life guarding is not supported No UNSIGNED8 0

Figure 55: Storage write access signature On reception of the correct signature in the appropriate sub-index the device stores the parameter and then confirms the SDO transmission (initiate download response). If the storing failed, the device responds with an Abort SDO Transfer (abort code: 06060000h). If a wrong signature is written, the device refuses to store and responds with Abort SDO Transfer (abort code: 0800002xh). On read access to the appropriate Sub-Index the device provides information about its storage functionality with the following format: UNSIGNED32 MSB bits 31-2 reserved (=0) Figure 56: Storage read access structure 9-70 LSB 1 0 0/1 0/1

APPLICATION LAYER

CANopen Table 49: Structure of read access

CiA

bit number 31-2 1 0

value 0 0 1 0 1

meaning reserved (=0) Device does not save parameters autonomously Device saves parameters autonomously Device does not save parameters on command Device saves parameters on command

Autonomous saving means that a device stores the storable parameters in a non-volatile manner without user request. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category ENTRY DESCRIPTION Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value 0h largest subindex supported Mandatory ro No 1h 7Fh No 1h save all parameters Mandatory rw No UNSIGNED32 (Figure 55) No 2h save communication parameters Optional rw No UNSIGNED32 (Figure 55) No 1010h store parameters ARRAY UNSIGNED32 Optional

9-71

APPLICATION LAYER Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Object 1011h: Restore default parameters

CANopen 3h save application parameters Optional rw No UNSIGNED32 (Figure 55) No 4h - 7Fh save manufacturer defined parameters Optional rw No UNSIGNED32 (Figure 55) No

CiA

With this object the default values of parameters according to the communication or device profile are restored. By read access the device provides information about its capabilities to restore these values. Several parameter groups are distinguished: Sub-Index 0 contains the largest Sub-Index that is supported. Sub-Index 1 refers to all parameters that can be restored. Sub-Index 2 refers to communication related parameters (Index 1000h - 1FFFh manufacturer specific communication parameters). Sub-Index 3 refers to application related parameters (Index 6000h - 9FFFh manufacturer specific application parameters). At Sub-Index 4 - 127 manufacturers may restore their individual choice of parameters. Sub-Index 128 - 254 are reserved for future use. In order to avoid the restoring of default parameters by mistake, restoring is only executed when a specific signature is written to the appropriate sub-index. The signature is load. Signature ASCII hex MSB d 64h a 61h o 6Fh l 6Ch LSB

Figure 57: Restoring write access signature On reception of the correct signature in the appropriate sub-index the device restores the default parameters and then confirms the SDO transmission (initiate download response). If the restoring failed, the device responds with an Abort SDO Transfer (abort code: 06060000h). If a wrong signature is written, the device refuses to restore the defaults and responds with an Abort SDO Transfer (abort code: 0800002xh). The default values are set valid after the device is reset (reset node for sub-index 1h 7Fh, reset communication for sub-index 2h) or power cycled. If the device requires storing on command (see Object1010h), the appropriate command has to be executed after the reset if the default parameters are to be stored permanently.

9-72

APPLICATION LAYER

CANopen

CiA

restore default

reset / power cycle

default values valid

save

Figure 58: restore procedure On read access to the appropriate sub-index the device provides information about its default parameter restoring capability with the following format: UNSIGNED32 MSB bits 31-1 reserved (=0) LSB 0 0/1

Figure 59: Restoring default values read access structure Table 50: Structure of restore read access bit number 31-1 0 value 0 0 1 OBJECT DESCRIPTION INDEX Name Object Code Data Type Category ENTRY DESCRIPTION Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value 0h largest subindex supported Mandatory ro No 1h 7Fh No 1011h restore default parameters ARRAY UNSIGNED32 Optional meaning reserved (=0) Device does not restore default parameters Device restores parameters

9-73

APPLICATION LAYER Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category PDO Mapping Value Range Object 1012h: COB-ID Time Stamp Object

CANopen 1h restore all default parameters Mandatory rw No UNSIGNED32 (Figure 57) No 2h restore communication default parameters Optional rw No UNSIGNED32 (Figure 57) No 3h restore application default parameters Optional rw No UNSIGNED32 (Figure 57) No 4h - 7Fh restore manufacturer default parameters Optional No UNSIGNED32 (Figure 57) defined

CiA

Index 1012h defines the COB-ID of the Time-Stamp Object (TIME). Further, it defines whether the device consumes the TIME or whether the device generates the TIME. The structure of this object is shown in Figure 60 and Table 51. UNSIGNED32 MSB bits 11-bit-ID 29-bit-ID 31 0/1 0/1 30 29 28-11
000000000000000000

LSB 10-0 11-bit Identifier 0/1 0 0/1 1

29 -bit Identifier

Figure 60: Structure of TIME COB-ID entry

9-74

APPLICATION LAYER

CANopen Table 51: Description of TIME COB-ID entry

CiA

bit number 31 (MSB) 30 29 28 11 10-0 (LSB)

value 0 1 0 1 0 1 0 X X

meaning Device does not consume TIME message Device consumes TIME message Device does not produce TIME message Device produces TIME message 11-bit ID (CAN 2.0A) 29-bit ID (CAN 2.0B) if bit 29=0 if bit 29=1: bits 28-11 of 29-bit-TIME-COB-ID bits 10-0 of TIME-COB-ID

Bits 29, 30 may be static (not changeable). If a device is not able to generate TIME messages, an attempt to set bit 30 is responded with an abort message (abort code: 06090030h). Devices supporting the standard CAN frame type only, an attempt to set bit 29 is responded with an abort message (abort code: 06090030h). OBJECT DESCRIPTION INDEX Name Object Code Data Type Category ENTRY DESCRIPTION Access PDO Mapping Value Range Default Value Object 1013h: High Resolution Time Stamp This object contains a time stamp with a resolution of 1 ms (see 9.3.2). It can be mapped into a PDO in order to define a high resolution time stamp message. (Note that the data type of the standard time stamp message (TIME) is fixed). Further application specific use is encouraged. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category ENTRY DESCRIPTION Access PDO Mapping Value Range Default Value rw Optional UNSIGNED32 0 1013h high resolution time stamp VAR UNSIGNED32 Optional rw No UNSIGNED32 100h 1012h COB-ID time stamp message VAR UNSIGNED32 Optional

9-75

APPLICATION LAYER Object 1014h: COB-ID Emergency Object

CANopen

CiA

Index 1014h defines the COB-ID of the Emergency Object (EMCY). The structure of this object is shown in Figure 61. UNSIGNED32 MSB bits 31 30 29 0 1 28-11
000000000000000000

LSB 10-0 11-bit Identifier

11-bit-ID reserved (=0) 29-bit-ID reserved (=0)

29 -bit Identifier

Figure 61: Structure of the EMCY Identifier entry Devices supporting the standard CAN frame type only, an attempt to set bit 29 is responded with an abort message (abort code: 06090030h). OBJECT DESCRIPTION INDEX Name Object Code Data Type Category 1014h COB-ID Emergency message VAR UNSIGNED32 Conditional; Mandatory, if Emergency is supported ENTRY DESCRIPTION Access PDO Mapping Value Range Default Value Object 1015h: Inhibit Time EMCY The inhibit time for the EMCY message can be adjusted via this entry. If this entry exists it must be writable in the object dictionary. The time has to be a multiple of 100ms OBJECT DESCRIPTION INDEX Name Object Code Data Type Category ENTRY DESCRIPTION Access PDO Mapping Value Range Default Value Object 1016h: Consumer Heartbeat Time The consumer heartbeat time defines the expected heartbeat cycle time and thus has to be higher than the corresponding producer heartbeat time configured on the device producing this heartbeat. rw No UNSIGNED16 0 1015h Inhibit Time EMCY VAR UNSIGNED16 Optional rw No UNSIGNED32 80h + Node-ID

9-76

APPLICATION LAYER

CANopen

CiA

Monitoring starts after the reception of the first heartbeat. If the consumer heartbeat time is 0 the corresponding entry is not used. The time has to be a multiple of 1ms. UNSIGNED32 MSB Bits 31-24 Value reserved (value: 00h) Encoded as 23-16 Node-ID UNSIGNED8 LSB 15-0 heartbeat time UNSIGNED16

Figure 62: Structure of Consumer Heartbeat Time entry At an attempt to configure several consumer heartbeat times unequal 0 for the same Node-ID the device aborts the SDO download with abort code 06040043h OBJECT DESCRIPTION INDEX Name Object Code Data Type Category ENTRY DESCRIPTION Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value 0h number entries Mandatory ro No 1 127 No 1h Consumer Heartbeat Time Mandatory rw No UNSIGNED32 (Figure 62) 0 2h 7Fh Consumer Heartbeat Time Optional rw No UNSIGNED32 (Figure 62) No 1016h Consumer Heartbeat Time ARRAY UNSIGNED32 Optional

Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value

9-77

APPLICATION LAYER Object 1017h: Producer Heartbeat Time

CANopen

CiA

The producer hartbeat time defines the cycle time of the heartbeat. The producer heartbeat time is 0 if it not used. The time has to be a multiple of 1ms. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category 1017h Producer Heartbeat Time VAR UNSIGNED16 Conditional; Mandatory if guarding not supported ENTRY DESCRIPTION Access PDO Mapping Value Range Default Value Object 1018h: Identity Object The object at index 1018h contains general information about the device. The Vendor ID (sub-index 1h) contains a unique value allocated to each manufacturer. The manufacturer-specific Product code (sub-index 2h) identifies a specific device version. The manufacturer-specific Revision number (sub-index 3h) consists of a major revision number and a minor revision number. The major revision number identifies a specific CANopen behaviour. If the CANopen functionality is expanded, the major revision has to be incremented. The minor revision number identifies different versions with the same CANopen behaviour. 31 16 15 0 major revision number MSB Figure 63: Structure of Revision number The manufacturer-specific Serial number (sub-index 4h) identifies a specific device. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category ENTRY DESCRIPTION Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value 0h number of entries Mandatory ro No 1 .. 4 No 1018h Identity Object RECORD Identity Mandatory minor revision number LSB rw No UNSIGNED16 0

9-78

APPLICATION LAYER Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Object 1200h - 127Fh: Server SDO Parameter

CANopen 1h Vendor ID Mandatory ro No UNSIGNED32 No 2h Product code Optional ro No UNSIGNED32 No 3h Revision number Optional ro No UNSIGNED32 No 4h Serial number Optional ro No UNSIGNED32 No

CiA

In order to describe the SDOs used on a device the data type SDO Parameter is introduced. The data type has the index 22h in the Object Dictionary. The structure is described in 9.5.4. The number of supported entries in the SDO object record is specified at sub-index 0h. The values at 1h and 2h specify the COB-ID for this SDO. Sub-index 3 gives the server of the SDO in case the record describes an SDO for which the device is client and gives the client of the SDO if the record describes an SDO for which the device is server. UNSIGNED32 MSB bits 11-bit-ID 29-bit-ID 31 0/1 0/1 30 0 0 29 0 1 28-11
000000000000000000

LSB 10-0 11-bit Identifier

29-bit Identifier

Figure 64: Structure of SDO COB-ID entry

9-79

APPLICATION LAYER

CANopen Table 52: Description of SDO COB-ID entry

CiA

bit number 31 (MSB) 30 29 28 - 11 10-0 (LSB)

value 0 1 0 0 1 0 X X

Meaning SDO valid SDO not valid reserved (always 0) 11-bit ID (CAN 2.0A) 29-bit ID (CAN 2.0B) if bit 29=0 if bit 29=1: bits 28-11 of 29-bit-COB-ID bits 10-0 of COB-ID

An SDO is only valid if both SDO-valid-bits are 0. Devices supporting the standard CAN frame type only, an attempt to set bit 29 is responded with an abort message (abort code: 06090030h). These objects contain the parameters for the SDOs for which the device is the server. If a device handles more than one server SDO the default SDO must be located at index 1200h as the first server SDO. This entry is read only2. All additional server SDOs are invalid by default (invalid bit - see Table 52), there description is located at subsequent indicies. The description of the Client of the SDO (sub-index 3h) is optional. It is not available for the default SDO (no Sub-index 3h at Index 1200h), as this entry is read only. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category 1200h - 127Fh Server SDO parameter RECORD SDO Parameter Conditional Index 1200h: Optional Index 1201h - 127Fh: Mandatory for each additionally supported server SDO ENTRY DESCRIPTION Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value 0h number of entries Mandatory ro No Index 1200h: 2 Index 1201h 127F: 2 - 3 No

It must be ensured that the COB-IDs of the default SDO can not be manipulated by writing to the Object Dictionary. 9-80

APPLICATION LAYER Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value

CANopen 1h COB-ID Client->Server (rx) Mandatory Index 1200h: ro, Index 1201h-127Fh: rw No UNSIGNED32 (Table 52) Index 1200h: 600h+Node-ID, Index 1201h-127Fh: No

CiA

Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value

2h COB-ID Server -> Client (tx) Mandatory Index 1200h: ro Index 1201-127Fh: rw No UNSIGNED32 (Table 52) Index 1200h: 580h+Node-ID, Index 1201h-127Fh: No

Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Object 1280h - 12FFh: Client SDO Parameter

3h node ID of the SDO client Optional rw No 1h 7Fh No

These objects contain the parameters for the SDOs for which the device is the client. If the entry is supported, all sub-indices must be available. Starting at index 1280h and subsequent indicies.The entries are described at the Server SDO Parameter. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category 1280h - 12FFh Client SDO parameter RECORD SDO Parameter Conditional; Mandatory for each supported client SDO

9-81

APPLICATION LAYER ENTRY DESCRIPTION Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value

CANopen

CiA

0h number of entries Mandatory ro No 3 3 1h COB-ID Client->Server (tx) Mandatory rw No UNSIGNED32 (Table 52) No 2h COB-ID Server -> Client (rx) Mandatory rw No UNSIGNED32 (Table 52) No 3h node ID of the SDO server Mandatory rw No 1h 7Fh No

Object 1400h - 15FFh: Receive PDO Communication Parameter Contains the communication parameters for the PDOs the device is able to receive. The type of the PDO communication parameter (20h) is described in 9.5.4. The sub-index 0h contains the number of valid entries within the communication record. Its value is at least 2. If inhibit time supported the value is 3. At sub-index 1h resides the COB-ID of the PDO. This entry has been defined as UNSIGNED32 in order to cater for 11-bit CAN Identifiers (CAN 2.0A) as well as for 29-bit CAN identifiers (CAN 2.0B). The entry has to be interpreted as defined in Figure 65 and Table 53.

9-82

APPLICATION LAYER UNSIGNED32 MSB bits 11-bit-ID 29-bit-ID 31 0/1 0/1 30 29 28-11 0/1 0 0/1 1

CANopen

CiA

LSB 10-0 11-bit Identifier


000000000000000000

29-bit Identifier

Figure 65: Structure of PDO COB-ID entry Table 53: Description of PDO COB-ID entry bit number 31 (MSB) 30 29 28 11 10-0 (LSB) value 0 1 0 1 0 1 0 X X meaning PDO valid PDO not valid RTR allowed on this PDO no RTR allowed on this PDO 11-bit ID (CAN 2.0A) 29-bit ID (CAN 2.0B) if bit 29=0 if bit 29=1: bits 28-11 of 29-bit-COB-ID bits 10-0 of COB-ID

The PDO valid/not valid allows to select which PDOs are used in the operational state. There may be PDOs fully configured (e.g. by default) but not used, and therefore set to "not valid" (disabled). The feature is necessary for devices supporting more than 4RPDOs or 4 TPDOs, because each device has only default identifiers for the first four RPDOs/TPDOs. Devices supporting the standard CAN frame type only or do not support Remote Frames, an attempt to set bit 29 to 1 or bit 30 to 0 is responded with an abort message (abort code: 06090030h). The transmission type (sub-index 2) defines the transmission/reception character of the PDO (see 9.2.1.1). Table 54 describes the usage of this entry. On an attempt to change the value of the transmission type to a value that is not supported by the device an abort message (abort code: 06090030h) is generated. Table 54: Description of transmission type transmission type 0 1-240 241-251 252 253 254 255 X X X X X PDO transmission
cyclic acyclic synchronous asynchronous RTR only

X X - reserved X X

Synchronous (transmission types 0-240 and 252) means that the transmission of the PDO shall be related to the SYNC object as described in 9.3. Preferably the devices use the SYNC as a trigger to output or actuate based on the previous synchronous Receive PDO respectively to update the data transmitted at the following synchronous Transmit PDO. Details of this mechanism depend on the device type and are defined in the device profile if applicable. Asynchronous means that the transmission of the PDO is not related to the SYNC object. A transmission type of zero means that the message shall be transmitted synchronously with the SYNC object but not periodically. A value between 1 and 240 means that the PDO is transferred synchronously and cyclically, the transmission type indicating the number of SYNC which are necessary to trigger PDO transmissions/receptions. 9-83

APPLICATION LAYER

CANopen

CiA

The transmission types 252 and 253 mean that the PDO is only transmitted on remote transmission request. At transmission type 252, the data is updated (but not sent) immediately after reception of the SYNC object. At transmission type 253 the data is updated at the reception of the remote transmission request (hardware and software restrictions may apply). These value are only possible for TPDOs. For TPDOs transmission type 254 means, the application event is manufacturer specific (manufacturer specific part of the Object Dictionary), transmission type 255 means, the application event is defined in the device profile. RPDOs with that type trigger the update of the mapped data with the reception. Sub-index 3h contains the inhibit time. This time is a minimum interval for PDO transmission. The value is defined as mutiple of 100ms. Sub-index 4h is reserved. It does not have to be implemented, in this case read or write access leads to Abort SDO Transfer (abort code: 0609 0011h). In mode 254/255 additionally an event time can be used for TPDO. If an event timer exists for a TPDO (value not equal to 0) the elapsed timer is considered to be an event. The event timer elapses as mutiple of 1 ms of the entry in sub-index 5h of the TPDO. This event will cause the transmission of this TPDO in addition to otherwise defined events. The occurence of the events set the timer. Independent of the transmission type the RPDO event timer is used recognize the expiration of the RPDO. OBJECT DESCRIPTION INDEX Name Object Code Data Type Category 1400h - 15FFh receive PDO parameter RECORD PDO CommPar Conditional; Mandatory for each supported PDO ENTRY DESCRIPTION Sub-Index Description Entry Category Access PDO Mapping Value Range Sub-Index Description Entry Category Access 0h largest sub-index supported Mandatory ro No 25 1h COB-ID used by PDO Mandatory ro; rw if variable COB-ID is supported PDO Mapping Value Range Default Value No UNSIGNED32 (Table 53) Index 1400h: 200h + Node-ID, Index 1401h: 300h + Node-ID, Index 1402h: 400h + Node-ID, Index 1403h: 500h + Node-ID, Index 1404h 15FFh: disabled

9-84

APPLICATION LAYER Sub-Index Description Entry Category Access

CANopen 2h transmission type Mandatory ro; rw if variable transmission type is supported

CiA

PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value

No UNSIGNED8 (Table 54) (Device Profile dependent) 3h inhibit time (not used for RPDO) Optional rw No UNSIGNED16 No 4h compatibility entry Optional rw No UNSIGNED8 No 5h event timer Optional rw No 0 not used UNSIGNED16 No

Object 1600h - 17FFh: Receive PDO Mapping Parameter Contains the mapping for the PDOs the device is able to receive. The type of the PDO mapping parameter (21h) is described in 9.5.4. The sub-index 0h contains the number of valid entries within the mapping record. This number of entries is also the number of the application variables which shall be transmitted/received with the corresponding PDO. The sub-indices from 1h to number of entries contain the information about the mapped application variables. These entries describe the PDO contents by their index, sub-index and length (Figure 66). All three values are hexadecimal coded. The length entry contains the length of the object in bit (1..40h). This parameter can be used to verify the overall mapping length. It is mandatory.

9-85

APPLICATION LAYER

CANopen

CiA

The structure of the entries from sub-index 1h 40h is as follows: Byte: MSB index (16 bit) sub-index (8 bit) Figure 66: Structure of PDO Mapping Entry If the change of the PDO mapping cannot be executed (e.g. the PDO length is exceeded or the SDO client attempts to map an object that cannot be mapped) the device responds with an Abort SDO Transfer Service. Subindex 0 determines the valid number of objects that have been mapped. For changing the PDO mapping first subindex 0 must be set to 0 (mapping is deactivated). Then the objects can be remapped. When a new object is mapped by wrinting a subindex between 1 and 64, the device may check whether the object specified by index /subindex exists. If the object does not exist or the object cannot be mapped, the SDO transfer must be aborted with the Abort SDO Transfer Service with one of the abort codes 06020000h or 06040041h. After all objects are mapped subindex 0 is set to the valid number of mapped objects. When subindex 0 is set to a value >0 the device may validate the new PDO mapping before transmitting the response of the SDO service. If an error is detected the device has to transmit the Abort SDO Transfer Service with one of the abort codes 06020000h, 06040041h or 06040042h. When subindex 0 is read the actual number of valid mapped objects is returned. If data types (Index 1h-7h) are mapped they serve as dummy entries. The corresponding data in the PDO is not evaluated by the device. This optional feature is useful e.g. to transmit data to several devices using one PDO, each device only utilising a part of the PDO. It is not possible to create a dummy mapping for a TPDO. A device that supports dynamic mapping of PDOs must support this during the state PREOPERATIONAL state. If dynamic mapping during the state OPERATIONAL is supported, the SDO client is responsible for data consistency. Object Dictionary PDO Mapping 0 1 2 3 yyyyh zzzzh xxxxh 3 yyh 08h zzh 10h xxh 08h yyyyh yyh
Application Object 2

LSB object length (8 bit)

xxxxh

xxh

Application Object 1

zzzzh

zzh

Application Object 3

PDO:

Appl. Obj. 2

Application Object 3 Figure 67: Principle of PDO mapping

Appl. Obj. 1

OBJECT DESCRIPTION INDEX Name Object Code Data Type Category 1600h 17FFh receive PDO mapping RECORD PDO Mapping Conditional; Mandatory for each supported PDO

9-86

APPLICATION LAYER ENTRY DESCRIPTION Sub-Index Description Entry Category Access

CANopen

CiA

0h number of mapped application objects in PDO Mandatory ro; rw if dynamic mapping is supported

PDO Mapping Value Range Default Value Sub-Index Description Entry Category

No 0: deactivated 1 64: activated (device profile dependent) 1h 40h PDO mapping for the nth application object to be mapped Conditional depends on number and size of object be mapped

Access PDO Mapping Value Range Default Value

rw No UNSIGNED32 (device profile dependent)

Object 1800h - 19FFh: Transmit PDO Communication Parameter Contains the communication parameters for the PDOs the device is able to transmit. The type of the PDO communication parameter (20h) is described in 9.5.4. A detailed description of the entries is done in the section for the Receive PDO Communication Parameter (1400h 15FFh). OBJECT DESCRIPTION INDEX Name Object Code Data Type Category 1800h - 19FFh transmit PDO parameter RECORD PDO CommPar Conditional; Mandatory for each supported PDO ENTRY DESCRIPTION Sub-Index Description Entry Category Access PDO Mapping Value Range 0h largest sub-index supported Mandatory ro No 25

9-87

APPLICATION LAYER Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value

CANopen 1h COB-ID used by PDO Mandatory ro; rw if COB-ID can be changed No UNSIGNED32 (Figure 65) Index 1800h: 180h + Node-ID, Index 1801h: 280h + Node-ID, Index 1802h: 380h + Node-ID, Index 1803h: 480h + Node-ID, Index 1804h - 18FFh: disabled

CiA

Sub-Index Description Entry Category Access

2h transmission type Mandatory ro; rw if transmission type can be changed

PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value

No UNSIGNED8 (Table 53) (device profile dependent) 3h inhibit time Optional rw No UNSIGNED16 No 4h reserved Optional rw No UNSIGNED8 No

9-88

APPLICATION LAYER Sub-Index Description Entry Category Access PDO Mapping Value Range Default Value

CANopen 5h event timer Optional (not used for RPDO) rw No 0 not used UNSIGNED16 No

CiA

Object 1A00h - 1BFFh: Transmit PDO Mapping Parameter Contains the mapping for the PDOs the device is able to transmit. The type of the PDO mapping parameter (21h) is described in 9.5.4. A detailed description of the entries is done in the section for the Receive PDO Mapping Parameter (1600h 17FFh). OBJECT DESCRIPTION INDEX Name Object Code Data Type Category 1A00h - 1BFFh transmit PDO mapping RECORD PDO Mapping Conditional; Mandatory for each supported PDO ENTRY DESCRIPTION Sub-Index Description Entry Category Access 0h number of mapped application objects in PDO Mandatory ro; rw if dynamic mapping is supported PDO Mapping Value Range Default Value Sub-Index Description Entry Category No 0: deactivated 1 64: activated (device profile dependent) 1h 40h PDO mapping for the n-th application object to be mapped Conditional; depends on number and size of objects to be mapped Access PDO Mapping Value Range Default Value rw No UNSIGNED32 (device profile dependent)

9-89

IMPLEMENTATION RECOMMENDATIONS

CANopen

CiA

10 IMPLEMENTATION RECOMMENDATIONS
When implementing the protocols, the following rules should be obeyed to guarantee interoperability. These rules deal with the following implementation aspects: Invalid COB's A COB is invalid if it has a COB-ID that is used by the specified protocols, but it contains invalid parameter values according to the protocol specification. This can only be caused by errors in the lower layers or implementation errors. Invalid COB's must be handled locally in an implementation specific way that does not fall within the scope of this specification. As far as the protocol is concerned, an invalid COB must be ignored. Time-out's Since COB's may be ignored, the response of a confirmed service may never arrive. To resolve this situation, an implementation may, after a certain amount of time, indicate this to the service user (time-out). A time-out is not a confirm of that service. A time-out indicates that the service has not completed yet. The application must deal with this situation. Time-out values are considered to be implementation specific and do not fall within the scope of this specification. However, it is recommended that an implementation provides facilities to adjust these time-out values to the requirements of the application.

10-1

Index

CANopen

CiA

11 Index
access attributes...........................................9-57 ARRAY..........................................................9-57 bit timing..........................................................7-1 communication model client server relationship.............................6-6 master slave relationship............................6-5 producer consumer relationship.................6-6 communication status initialising...................................................9-54 operational ................................................9-55 pre-operational..........................................9-55 reset application........................................9-54 reset communication.................................9-54 stopped......................................................9-55 data type BOOLEAN...................................................9-3 compound....................................................9-6 DOMAIN ......................................................9-7 INTEGERn ..................................................9-4 NIL ...............................................................9-3 OCTET_STRING ........................................9-6 REAL32 .......................................................9-5 TIME_DIFFERENCE ..................................9-7 TIME_OF_DAY ...........................................9-6 UNICODE_STRING....................................9-6 UNSIGNEDn ...............................................9-3 VISIBLE STRING........................................9-6 VOIDn..........................................................9-3 DEFSTRUCT ................................................9-57 DEFTYPE......................................................9-57 device model...................................................6-2 device profile...................................................6-3 DOMAIN........................................................9-57 dummy mapping ...........................................9-58 error control general ......................................................9-42 guarding life- .............................................................9-47 node-..........................................................9-47 inhibit time .......................................................6-5 multi device module data types ..................................................9-58 general.........................................................6-4 network initialisation......................................9-52 NULL .............................................................9-57 object dictionary ..............................................6-3 communication entries..............................9-58 data types ..................................................9-58 general structure .......................................9-56 structure.......................................................6-3 structured entries ......................................9-60 object name...................................................9-57 pre-defined connection set ...........................9-55 process data object general.........................................................9-7 transmission mode......................................9-8 triggering mode ...........................................9-8 protocol specification ......................................6-1 RECORD.......................................................9-57 reference model ..............................................6-1 service data object abort codes................................................9-26 block download .........................................9-16 block upload ..............................................9-17 download ...................................................9-12 general.......................................................9-11 upload ........................................................9-14 service objects ................................................6-1 service primitives ............................................6-1 service specification........................................6-1 service type .....................................................6-2 state diagram ................................................9-52 state transitions.............................................9-55 VAR ...............................................................9-57

11-1

Definitions

CANopen Communication Profile

CiA

Definitions
CAN CiA CMS COB COB-ID DBT Controller Area Network CAN in Automation international users and manufacturers group e.V. CAN Message Specification. One of the service elements of the CAN Application Layer in the CAN Reference Model. Communication Object. (CAN Message) A unit of transportation in a CAN Network. Data must be sent across a Network inside a COB. COB-Identifier. Identifies a COB uniquely in a Network. The identifier determines the priority of that COB in the MAC sub-layer too. Distributor. One of the service elements of the CAN Application Layer i n the CAN Reference Model. Its the responsibility of the DBT to distribute COB-ID's to the COB's that are used by CMS. Deutsches Institut fr Normung International Standardisation Organisation Layer Management. One of the service elements of the CAN Application Layer in the CAN Reference Model. It serves to configure parameters of each layer in the CAN Reference Model. Network Management. One of the service elements of the CAN Application Layer in the CAN Reference Model. It performs initialisation, configuration and error handling in a CAN network. Open Systems Interconnection Process Data Object Service Data Object

DIN ISO LMT

NMT

OSI PDO SDO

3-1

Introduction

CANopen Communication Profile

CiA

4
4.1

Introduction
CANopen Communication Reference Model
The communication concept can be described similar to the ISO-OSI Reference Model.

Device Profile A

Device Profile B

Device Profile C

Device Profile X

ISO/OSI Layer 7: CAN Appl icati on Layer (CAL) Subset, usage defined by co mmunic ation profil e NMT DBT LMT CMS

OSI Data Link Layer: CAN 2.0 A+B

OSI Physical Layer: ISO 11898

Cable

Figure 4-1: The CANopen Communication Reference Model OSI-Layer 1-7: The layered structure of the communication model is briefly described in /5/. CANopen Communication Profile: The CANopen Communication Profile comprises a concept to configure and communicate real-time-data as well as the mechanisms for synchronisation between devices. Basically the CANopen Communication Profile describes how a subset of CAN Application Layer (CAL) services is used by devices.

CANopen Device Profiles: The device profile describes the functionality of a particular device.

4-1

Introduction

CANopen Communication Profile

CiA

4.2

Standardisation Via Profiling


The two principal advantages of the profile approach to device specification are in the areas of system integration and device standardisation. If two independent device manufacturers are to design products which are to communicate with each other then each manufacturer must be provided with a specification of the other manufacturers device. This specification could take many forms if left to individual manufacturers to produce. The concept of device profiling provides a standard for producing such specifications. By adopting this approach all manufacturers will specify their devices i n a similar fashion which greatly reduces the effort involved in system integration. The other clear advantage of the profile approach to device specification is that it can be used to guide manufacturers into producing standardised devices. The advantages of standardised devices are numerous. Perhaps most importantly the idea of a standardised device de-couples a system integrator from a specific supplier. If one supplier cannot meet product demand, for example, the integrator can use devices from another supplier without having to re-configure network software. On the other hand the supplier is not forced any more to implement a private protocol for each customer. A device profile defines a standard device. This standard device specifies a basic functionality which every device within a class must exhibit. This mandatory functionality is necessary to ensure at least simple non-manufacturer-specific operation of a device is possible1. The concept of device standardisation is extended functionality defined within the standard device profiles. does not have to be implemented by all manufacturers. wishes to implement such functionality he must do so in standard device. by the notion of optional Such optional functionality However, if a manufacturer the manner defined for the

The concept of optional functionality provides a very powerful mechanism to ensure all manufacturers implementing particular functionality do so in a defined fashion2. The device profiles provide a mechanism by which manufacturers wishing to implement truly manufacturer specific functionality can do so. This is clearly necessary since it would be impossible to anticipate all possible device functionality and define this in the optional category of each device class. This approach guarantees that the standard device profiles are 'future-proof'. By defining mandatory device characteristics basic network operation is guaranteed. By defining optional device features a degree of defined flexibility can be built in. By leaving 'hooks' for manufacturer specific functionality manufacturers will not be constrained to an out-of-date standard.

For example the standard drive unit provides a 'HALT' function to stop a drive from moving. This function is defined as mandatory such that any drive unit supporting the drive profile can be halted using the same message. For example, the standard digital I/O module may define optional functionality to cater for units with up to 64 I/O channels (This is specified in the device profile). Whilst many units will not use anything like this number of I/O the definition ensures that 64-channel I/O modules developed by independent manufacturers will be largely interchangeable. 4-2

Introduction

CANopen Communication Profile

CiA

4.3

The Object Dictionary


The most important part of a device profile is the object dictionary description. The object dictionary is essentially a grouping of objects accessible via the network in an ordered pre-defined fashion. Each object within the dictionary is addressed using a 16bit index. The overall layout of the standard object dictionary is shown below. This layout closely conforms with other industrial Fieldbus concepts:

Index (hex) 0000 0001-001F 0020-003F 0040-005F 0060-007F 0080-009F 00A0-0FFF 1000-1FFF 2000-5FFF 6000-9FFF A000-FFFF

Object not used Static Data Types Complex Data Types Manufacturer Specific Data Types Device Profile Specific Static Data Types Device Profile Specific Complex Data Types Reserved for further use Communication Profile Area Manufacturer Specific Profile Area Standardised Device Profile Area Reserved for further use

Table 4-1: Object Dictionary Structure The Standard Object Dictionary may contain a maximum of 65536 entries which are addressed through a 16bit index. The Static Data Types at indices 0001h through 001Fh contain type definitions for standard data types like Boolean, integer, floating point, string, etc. These entries are included for reference only, they cannot be read or written. Complex Data Types at indices 0020h through 003Fh are pre-defined structures that are composed of standard data types and are common to all devices. Manufacturer Specific Data Types at indices 0040h through 005Fh are also structures composed of standard data types but are specific to a particular device. Device Profiles may define additional data types specific to their device type. The static data types defined by the device profile are listed at indices 0060h - 007Fh, the complex ones at indices 0080h - 009Fh. A device may optionally provide the structure of the supported complex data types (indices 0020h - 005Fh and 0080h - 009Fh) at read access to the corresponding index. Sub-index 0 then provides the number of entries at this index, and the following subindices contain the data type encoded as Unsigned16 according to table 10-4. The Communication Profile Area at indices 1000 through 1FFF contains the communication specific parameters for the CAN network. These entries are common to all devices. The Standardised Device Profile Area at indices 6000h through 9FFFh contains a ll data objects common to a class of devices that can be read or written via the network. The object dictionary for each device type has a range of mandatory entries. These entries ensure that all devices of a particular type behave in a defined manner (at least from a basic functionality viewpoint). 4-3

Introduction

CANopen Communication Profile

CiA

The object dictionary concept caters for optional device features which means a manufacturer does not have to provide certain extended functionality on his devices but if he wishes to do so he must do it in a pre-defined fashion3. By defining object dictionary entries for anticipated increased functionality in an optional category manufacturers wishing to implement enhanced functionality will a ll do so in the same way4. 4.3.1 Index and Sub-Index Usage A 16-bit index is used to address all entries within the object dictionary. In case of a simple variable this references the value of this variable directly. In case of records and arrays however, the index addresses the whole data structure. To allow individual elements of structures of data to be accessed via the network a subindex has been defined. For single object dictionary entries such as an unsigned8, Boolean, integer32 etc. the value for the sub-index is always zero. For complex object dictionary entries such as arrays or records with multiple data fields the sub-index references fields within a data-structure pointed to by the main index. For example on a single channel RS232 interface module there may exist a data-structure at index 6092h which defines the communication parameters for that module. This structure may contain fields for baud-rate, number of data bits, number of stop bits and parity type. The sub-index concept can be used to access these individual fields5 as shown below: Main Index 6092 Sub Index 0 1 2 3 4 Variable Accessed Number of Entries Baud Rate Number Of Data Bits Number Of Stop Bits Parity Data Type Unsigned8 Unsigned16 Unsigned8 Unsigned8 Unsigned8

Table 4-2: Use of Index and Sub-Index A sub-index can also be used to reference a similar data field for more than one channel. For example a digital output module may have the capability to configure individual output signals for different polarity. The object dictionary entry at index 6022h may define the polarity information. A manufacturer could define his object dictionary such that the polarity of channel 1 was set by writing data to index 6022 subindex 1. Similarly the polarity for channel 3 could be configured by writing the polarity information to index 6022 sub-index 3. This is allowed since the sub-index is meant to index elements of a data structure. Multiple channels of the same type can be viewed as an array of channels6 of the same type - which is a structure.

4 5 6

For example the mandatory part of the object dictionary for a digital output module could define how to access a minimum number of outputs (8 for example). Manufacturers wishing to implement devices with eight outputs would merely conform with the defined standard. However manufacturers wishing to make modules with a greater number of outputs would have no standard to operate within. They would be free to define the communication with the other output signals as they wished. This could lead to module incompatibility problems. Space is left in the object dictionary at indices 2000h through 5FFFh for truly manufacturer specific functionality. The fields accessed by the sub-index can be of differing data types. Channel numbering must begin at sub-index 1, be consecutive, and the entry for sub-index 0 must reflect the number of channels implemented on a device (Unsigned8). 4-4

Synchronisation by the SYNC Master CANopen Communication Profile

CiA

6
6.1

Synchronisation by the SYNC Master


Transmission of Synchronous PDO Messages
Synchronous transmission of a message means that the transmission of the message is fixed in time with respect to the transmission of the SYNC message. The synchronous message is transmitted within a given time window with respect to the SYNC transmission, and at most once for every period of the SYNC. In general the fixing of the transmission time of synchronous PDO messages coupled with the periodicity of transmission of the SYNC message guarantees that sensor devices may arrange to sample process variables and that actuator devices may apply their actuation in a co-ordinated fashion. Assuming a structure where a master device controls a number of slave devices by issuing a COMMAND message and receiving the ACTUAL messages from the slave devices. Synchronous COMMAND messages transmitted by the master device will occur in a definite time period with respect to the transmission of the SYNC message. In general the COMMAND cyclic message will be transmitted before a SYNC and the device will actuate based on this COMMAND at the next SYNC. Simple devices operating in the cyclic mode may therefore use the SYNC message as a trigger to output or actuate based upon their previous COMMAND. Depending upon its capabilities, a device may also be parameterised with the time period synchronous window length after the SYNC at which it is guaranteed that its COMMAND has arrived. It may therefore perform any processing on the COMMAND data which is required in order to actuate at the next SYNC message. The arrival of a SYNC will also prompt a device operating in the cyclic mode to sample its feedback data and transmit an ACTUAL back to the master device as soon as possible afterwards.

Communication_Cycle_Period synchronous window length SYNC Message Actual_ Messages SYNC Message Actual_ Messages

Command Messages

Command Messages

Samples taken at SYNC for ACTUAL message

Actuation based on COMMAND at next SYNC

Figure 6-1: Bus Synchronisation and Sampling/Actuation

6-1

Synchronisation by the SYNC Master CANopen Communication Profile

CiA

6.2

Optional High Resolution Synchronisation Protocol


The standard synchronisation mechanism provides for a lean implementation. The synchronisation message carries no data and is easy to generate. However, the jitter of this SYNC depends on the bit rate of the bus as even the very high priority SYNC has to wait for the current message on the bus to be transmitted before it gains bus access. Some time critical applications especially in large networks with reduced transmission rates require more accurate synchronisation; it may be necessary to synchronise the local clocks with an accuracy in the order of microseconds. This is achieved by using the optional high resolution synchronisation protocol which employs a special form of time stamp message (see Figure 6.2) to adjust the inevitable drift of the local clocks. The synchronisation master time-stamps the interrupt generated at t1 by the successful transmission of the SYNC message (this takes until t2). After that (at t4) he sends a timestamp message containing the corrected time-stamp (t1) for the SYNC transmission success indication. The slaves that have taken local time-stamps (t3) on the reception (t1) of the SYNC can now compare their corrected time-stamp (t1) with the one received in the time-stamp message from the master. The difference between these values determines the amount of time to adjust the local clock. With this protocol only the local latencies (t2-t1 on the master and t3-t1 on the slave ) are time critical. These latencies depend on local parameters (like interrupt processing times and hardware delays) on the nodes which have to be determined once. The accuracy of this determination is implementation specific, it forms the limiting factor of the synchronisation (or clock adjustment) accuracy. Note that each node only has to know its own latency time as the time-stamp message contains the corrected value t1 and not t2. The time-stamp is encoded as unsigned32 with a resolution of 1 microsecond which means that the time counter restarts every 72 minutes. It is configured by mapping the high resolution time-stamp (Object 1013h) into a PDO. It is reasonable to repeat the clock adjustment only when the maximum drift of the local clock exceeds the synchronisation accuracy. For most implementations this means that it is sufficient to add this time-stamp message to the standard SYNC once every second. This principle enables the best accuracy that can be achieved with bus-based synchronisation, especially when implemented on CAN controllers that support timestamping. Note that the accuracy is widely independent of the transmission rate. Further improvement requires separate hardware (e.g. wiring). SYNC master slave time t1 t2 t3 t4 t5 Figure 6-2: Optional High Resolution Synchronisation Protocol TIMESTAMP

6.3

Other Synchronisation

6-2

Synchronisation by the SYNC Master CANopen Communication Profile

CiA

The synchronisation mechanisms described in the preceding sections are mainly optimised for a synchronisation between a master and other devices. For special applications however, further synchronisation between (slave-) devices may be required as well. For instance, in order to allow multiple drive units to operate as an electronic gear, it may be necessary to configure one drive as the gearing master which broadcasts a master angle message to all slave drives at much shorter time intervals than the Communication Cycle. For these purposes, further synchronisation messages may be defined between any devices on the network. However, care should be taken not to increase the jitter of the SYNC when broadcast messages are to be transmitted at higher frequencies than the SYNC.

6-3

Pre-defined Communication Objects CANopen Communication Profile

CiA

Pre-defined Communication Objects


There are three pre-defined Communication Objects. The implementation of these objects is optional.

7.1
7.1.1

The SYNC Object


SYNC Usage The SYNC object is broadcasted periodically by the synchronisation device to all application devices. This SYNC object provides the basic network clock. The time period between the SYNC objects is specified by the standard parameter communication cycle period, which may be written by a configuration tool to the application devices during the boot-up process. There can be a time jitter i n transmission by the SYNC master corresponding approximately to the latency due to some other message being transmitted just before the SYNC. In order to guarantee timely access to the CAN bus the SYNC object is given a very high priority identifier10. Devices which operate synchronously may use the SYNC object to synchronise their own timing with that of the synchronisation device. The details of this synchronisation are device dependent and do not fall within the scope of this document. Devices which require a more accurate common time base may use the time stamp synchronisation mechanism described in chapter 6.2.

7.1.2

SYNC Services The SYNC object is implemented as CMS object of type "Basic Variable" with the synchronisation device acting as the client of that object. According to CMS the following services on variables are relevant: Define Variable Write Variable The following CMS variable object attributes are specified for the SYNC object: name: user type: class: priority: data type: according to the CMS naming conventions with <application-specific-name> = "SYNC000" synchronisation master device: client receiving device: server Basic Variable 0 (suggested) NIL

access type: Write_Only inhibit time: <communication period>

10

For the SYNC message identifier 128 in priority group 0 is suggested 7-1

Pre-defined Communication Objects CANopen Communication Profile

CiA

7.1.3

SYNC Object Protocols See specification of Basic Variable protocols /7/.

7.2
7.2.1

The Time Stamp Object


Time Stamp Object Usage By means of the Time-Stamp-Object a common time frame reference is provided to application devices11.

7.2.2

Time Stamp Object Services The Time-Stamp object is implemented as CMS object of type Stored Event with the transmitting device acting as the server of the event. According to CMS the following services on Stored Events are relevant: Define Event Notify Event Read Event The following CMS event object attributes are specified for the Time-Stamp object: name: user type: class: priority: data type: according to the CMS naming conventions with <application-specific-name> = "TIME000" Time stamp provider: server Time stamp consumers: clients Stored Event 1 (suggested) TIME-of-DAY12

inhibit time: application specific

7.2.3

Time Stamp Object Protocols See specification of the Stored Event protocols /7/.

11 12

For the Time Stamp message identifier 256 in priority group 1 is suggested. Additional Time Stamp messages with different data types (e.g. DATE) can be defined by mapping the appropriate data types into standard PDOs. 7-2

Pre-defined Communication Objects CANopen Communication Profile

CiA

7.3
7.3.1

The Emergency Object


Emergency Object Usage Emergency messages are triggered by the occurrence of a device internal fatal error situation and are transmitted from the concerned application device to the other devices with highest priority. This makes them suitable for interrupt type error alerts13. By means of CANopen Communication Profile defined emergency error codes (Table 7-1), the error register (Table 10-14) and device specific additional information, specified in the device profile the emergency condition is specified.

Error Code (hex) 00xx 10xx 20xx 21xx 22xx 23xx 30xx 31xx 32xx 33xx 40xx 41xx 42xx 50xx 60xx 61xx 62xx 63xx 70xx 80xx 81xx 90xx F0xx FFxx

Meaning Error Reset or No Error Generic Error Current Current, device input side Current inside the device Current, device output side Voltage Mains Voltage Voltage inside the device Output Voltage Temperature Ambient Temperature Device Temperature Device Hardware Device Software Internal Software User Software Data Set Additional Modules Monitoring Communication External Error Additional Functions Device specific

Table 7-1: Emergency Error Code

13

An Emergency Telegram may be sent only once per 'error event', i.e. the emergency messages must not be repeated. As long as no new errors occur on a device no further emergency messages must be sent. 7-3

Pre-defined Communication Objects CANopen Communication Profile

CiA

The emergency object is optional. If a device supports the emergency object, it has to support at least the two error codes 00xx and 10xx. All other error codes are optional. A device may be in one of two emergency states (Figure 7-1). Dependent on the transitions emergency objects will be transmitted. 1. After initialisation the device enters the error free state if no error is detected. No error message is sent. 2. The device detects an internal error indicated in the first three bytes of the emergency message (error code and error register). The device enters the error state. An emergency object with the appropriate error code and error register is transmitted14. The error code is filled in at the location of object 1003H (pre-defined error field). 3. One, but not all error reasons are gone. An emergency message containing error code 0000 (Error reset) may be transmitted together with the remaining errors in the error register and in the manufacturer specific error field. 4. A new error occurs on the device. The device remains in error state and transmits an emergency object with the appropriate error code. The new error code is filled in at the top of the array of error codes. If one error is repaired the appropriate error code is erased from the array. It has to be guaranteed that the error codes are sorted in a timely manner (oldest error - highest sub-index, see Object 1003H). 5. All errors are repaired. The device enters the error free state and transmits an emergency object with the error code reset error / no error'.

0 error free

1 2 error occured

Figure 7-1: Emergency State Transition Diagram

7.3.2

Emergency Object Mapping The Emergency Telegram consists of 8 bytes with the mapping as shown in Figure 7-2.

Byte

2 Error register (Object 1001H)

Content Emergency Error Code (see Table 7-1)

Manufacturer specific Error Field

Figure 7-2: Mapping Emergency Object

14

If the error is indicated only in the manufacturer specific part (last five bytes) of the emergency message the emergency message may be transmitted 7-4

Pre-defined Communication Objects CANopen Communication Profile

CiA

7.3.3

Emergency Object Services The Emergency object is implemented as a CMS object of type Stored Event with the notifying device acting as server of the event. According to CMS the following services on Stored Events are relevant: Define Event Notify Event Read Event The following CMS event object attributes are specified for the Emergency object: name:

according to the CMS naming conventions with <applicationspecific-name> = "EMCY000" notifying device: server other devices: clients Stored Event 0 or 1 suggested STRUCTURE OF UNSIGNED(16) emergency_error_code, UNSIGNED(8) error_register, ARRAY (5) of UNSIGNED(8) manufacturer_specific_error_field application specific

user type:

class: priority: data type:

inhibit time:

7.3.4

Protocols See specification of the Stored Event protocols /7/.

7-5

Network Management and Identifier Distribution

CANopen Communication Profile CiA

8
8.1

Network Management and Identifier Distribution


Services and Protocols
NMT services (/9/, /10/) provide a means for identification and monitoring of all nodes in the network. NMT requires one device in the network which fulfils the function of the NMT Master. NMT offers the following functionality groups: Module Control Services for initialisation of NMT Slaves that want to take part in the distributed application Error Control Services for supervision of the nodes and networks communication status Configuration Control Services for up- and downloading of configuration data from respectively to a module of the network. A NMT Slave represents that part of a node which is responsible for the nodes NMT functionality. A NMT Slave is uniquely identified by its Module ID or Name. Module ID (node identification number) and Module Name are configurable by LMT (/14/, /15/) services and protocols or other local means (e.g. DIP-Switch). The NMT Master can identify NMT Slaves, setting up of NMT parameters, download configuration data if necessary, allow the DBT Slave to request COB-IDs via DBT services and protocols (/11/, /12/) and enable or disable the CMS services at a certain node or simultaneously at all nodes. Error Control services are achieved principally through periodically transmitting of life guarding messages by the NMT Master. If a NMT Slave doesnt respond within a defined span of time or if the NMT Slaves communication status has changed, the NMT Master informs its NMT Master Application about that event. Also if a NMT Slave is not guarded within the nodes life time, the NMT Slave informs its local Application about that event. The node initialisation process is controlled by a NMT Master Application during the network boot-up process via NMT services according to /9/. In addition to the node states of the state diagram specified in /9/, the CANopen Communication Profile introduces the two status's "Pre-Operational" and "initialising" according to Figure 8-1. In Table 8-1 the state transitions of the NMT Slave state diagram according to the CAL specification are described in detail, in Table 8-2 the additional, profile specific transitions are described in detail.

8-1

Network Management and Identifier Distribution

CANopen Communication Profile CiA

Initia lis ation Reset A pplication (11) (1 0)

Reset Com munication

power on

Init (1 2)

(8 ) ( 6) Pr e- Op erational (0) (2) CAL Disconnec ted (3) Connecting (0 ) (4) Pr epar ing (5) (7) Pr epar ed (8 ) (6 ) (7)

O perational

( 6)

(8)

Figure 8-1: Extended NMT Node State Diagram (0) Disconnect_Remote_Node indication Disconnect_Node request Error response Delete_Node request (local service) Connect_Node request Connect_Remote_Node response Prepare_Remote_Node response Start_Remote_Node indication Stop_Remote_Node indication Enter_Pre-Operational_State indication Reset_Node indication Reset_Communication indication Initialisation finished - enter Pre-Operational automatically

(2) (3) (4) (5) (6) (7) (8) (10) (11) (12)

8-2

Network Management and Identifier Distribution

CANopen Communication Profile CiA

NMT Master

Direction of telegram

NMT Slave (0) Disconnect_Node request NMT local service request to set node state to DISCONNECTED

(0) Disconnect_Remote_Node request NMT service request to set the state of the remote node object and remote node to DISCONNECTED (0) Error confirmation NMT service confirmation informing NMT Master Application of an error (in response to Connect_Remote_Node or Prepare_Remote_Node request) (1) Add_Remote_Node request NMT local service request to create remote node object (2) Remove_Remote_Node request NMT local service request to delete remote node object

(0) Disconnect_Remote_Node indication NMT service indication to set node state to DISCONNECTED (0) Error response NMT service response forcing node to set its state to DISCONNECTED in response to Connect_Remote_Node or Prepare_Remote_Node indication from NMT Master (1) Create_Node request NMT local service request to create node object (2) Delete_Node request NMT local service request to delete node object (3) Connect_Node request NMT local service request to set node state to CONNECTING

(3) Connect_Remote_Node confirmation Confirmation to the NMT Master Application that node state is CONNECTED (in response to a NMT Master Connect_Remote_Node request)

(4) Connect_Remote_Node response NMT service response confirming node state as CONNECTING in response to a NMT Master Connect_Remote_Node indication. After successful transmission of the response the NMT slave enters the node state PREPARING (5) Prepare_Remote_Node response NMT service response confirming the end of node preparing in response to NMT Master Prepare_Remote_Node indication (6) Start_Remote_Node indication NMT service indication informing node that communication via PDOs and SDOs is enabled (7) Stop_Remote_Node indication NMT service indication informing node to disable communication

(4) Prepare_Remote_Node confirmation NMT service confirmation informing NMT Master Application about successful remote node preparing (5) Start_Remote_Node request NMT service request to enable communication via PDOs and SDOs (6) Stop_Remote_Node request NMT service request to disable communication

Table 8-1: State Transitions of the extended NMT Slave State Diagram according to the CAL specification 8-3

Network Management and Identifier Distribution

CANopen Communication Profile CiA

The right hand part of Table 8-1 describes state transitions of NMT corresponding to the state diagram of Figure 8-1.

Slaves

NMT Master (8) Enter_Pre-Operational_State request NMT service allowing NMT Master to enable SDOs (9) Prepare_Remote_Node request NMT service requesting NMT Slave to request COB-Identifiers for not allocated PDOs (10) Reset_Node request NMT service allowing NMT Master to reset node applications (11) Reset_Communication request NMT service allowing NMT Master to reset communication parameters at the slave node(s)

Direction of telegram

NMT Slave (8) Enter_Pre-Operational_State indication NMT service informing NMT Slave that SDOs are enabled (9) Prepare_Remote_Node indication NMT service informing NMT Slave to request COB-IDs for not allocated PDOs (10) Reset_Node indication NMT service informing the NMT Slave(s) to reset local application (11) Reset_Communication indication NMT service informing the NMT Slave to reset the communication parameters in the object dictionary to default values (12) Initialisation finished The NMT Slave enters this state automatically after finishing the initialisation tasks. This means that every reset request leads to the state Pre-Operational. (13, 14) Application or Communication Reset performed These state transitions are performed automatically.

Table 8-2: Profile Specific State Transitions of the extended NMT Slave State Diagram

After its initialisation, the device enters the Pre-Operational state autonomously. In this state, only communication via SDOs is operational, using the default COB-IDs derived from the module-ID. Configuration of PDOs, device parameters and also the allocation of application objects (PDO-mapping) may be performed by a configuration application. Then the extended boot-up is started by disconnecting the node (Disconnect_Node request). Alternatively, the node may be switched into the operational stage directly by sending a Start_Remote_Node request (Minimum Boot-Up). If a node is guarded via the node guarding protocol the state transferred from the slave back to the NMT Master should be 127 (see /10/) if the NMT Slave is in Pre-Operational state.

8-4

Network Management and Identifier Distribution

CANopen Communication Profile CiA

With the introduction of the "initialisation" state a complete or a partial reset of a node is possible via the network. The initialisation state is divided into three sub-states (see Figure 8-2). 1. Reset_Application: In this state the parameters of the manufacturer specific profile area and in the standardised device profile area are set to their default values. After setting of the power-on values the state Reset_Communication is entered. 2. Reset_Communication: In this state the parameters of the communication profile area are set to their power-on values. After this the state Initialising is entered. 3. Initialising: This is the first sub-state the device enters after power-on. After performing the basic node initialisation in this state the state Pre-Operational is entered automatically. Power-on values are the last stored parameters. If storing is not supported or has not been executed, the power-on values are the default values according to the CANopen communication and device profiles.

Reset Application (10) 13) (11) Reset Communication (14) power-on (12) Init

(1)

(2)

Figure 8-2: Sub-states of the initialisation state (1) (2) (10) (11) (12) (13) (14) Create_Node request Delete Node request Reset_Node indication Reset_Communication indication Initialisation finished - enter Pre-Operational automatically Application Reset performed Communication Reset performed

To control the different state transitions three additional services are introduced.

8-5

Network Management and Identifier Distribution

CANopen Communication Profile CiA

8.1.1

Enter_Pre-Operational_State Service and Protocol With this service a NMT Slave may be forced into the Pre-Operational state.

Parameter Argument Node-ID All

Request/Indication mandatory selection selection

The service will only be executed for the selected remote node objects whose state is "prepared" or "operational". Through this service the NMT Master sets the state of the selected NMT Slave(s) from "prepared" or "operational" to "Pre-Operational". In this state a node can communicate only via its SDOs. Therefore the service may also be used to switch off PDOs with a transition from "operational" to "Pre-Operational state. The service is unconfirmed and mandatory. In Figure 8-3 the protocol of the Enter_Pre-Operational_State service is shown15. NMT Master Request 0 CS 1 Node-ID COB-ID = 0 NMT Slave(s) Indication(s)

Figure 8-3: Enter_Pre-Operational_State, Reset_Node and Reset_Communication protocols

CS = 128: Enter_Pre-Operational_State Service CS = 129: Reset_Node Service CS = 130: Reset_Communication Service Node ID: Node-ID of the NMT Slave as assigned by the NMT Master in the Node connect protocol or zero. If zero, the protocol addresses all NMT Slaves.

15

Due to the introduction of the new services the reservation of command specifiers of value 128, 129 and 130 is necessary in the CAL Standard. 8-6

Network Management and Identifier Distribution

CANopen Communication Profile CiA

8.1.2

Reset_Node Service and Protocol With this service the NMT Master may force a complete reset of a distinct or of a ll nodes.

Parameter Argument Node-ID All

Request/Indication mandatory selection selection

The service will only be executed for the selected remote node objects independent of the state of the object. Through this service the NMT Master sets the state of the selected NMT Slave(s) from any state except DISCONNECTED to the "reset application" state. In this state a reset of the node application will be performed. The parameters of the entire object dictionary are set to their power-on values. The service is unconfirmed and mandatory for all devices. In Figure 8-3 the protocol of the Reset_Node-service is shown.

8.1.3

Reset_Communication Service and Protocol With this service the NMT Master may force a reset of the communication parameters of a distinct or of all nodes.

Parameter Argument Node-ID All

Request/Indication mandatory selection selection

The service will only be executed for the selected remote node objects independent of the state of the object. Through this service the NMT Master sets the state of the selected NMT Slave(s) from any state except DISCONNECTED to the "reset communication" state. In this state the parameters of the communication area in the object dictionary are set to their power-on values. The service is unconfirmed and mandatory for all devices. In Figure 8-3 the protocol of the Reset_Communication service is shown.

8-7

Network Management and Identifier Distribution

CANopen Communication Profile CiA

8.2

Network Initialisation Process (Bootup-Process)


In Figure 8-4 the general flow chart of the extended network initialisation process, controlled by a NMT Master Application or Configuration Application is shown. Configuration of device parameters, Configuration of dynamically defined PDOs, Mapping of application objects to PDOs (via Default SDO)

Execution of Disconnect_Remote_Node Service

Identification of Network Configuration and Start of Node Guarding

Distribution of COB-IDs for additional SDOs and configured PDOs of all devices

(Optional) Start transmission of SYNC Wait for synchronisation of devices

Setting of all nodes to the operational state

Figure 8-4: Flow Chart of the Extended Network Initialisation Process In step 1 the devices are in the node state Pre-Operational which is entered automatically after power-on. In this state the devices are accessible via their DefaultSDO using identifiers that have been assigned according to the Predefined Connection Set. In this step the configuration of device parameters takes place on all nodes which support parameter configuration. This is done from a Configuration Application (which can reside on the same node as the NMT Master Application or from a Configuration Tool via the Default-SDO. For devices that support these features the selection and/or configuration of PDOs, the mapping of application objects (PDO mapping), the configuration of additional SDOs and optionally the setting of COB-IDs may be performed via the Default-SDO objects.

8-8

Network Management and Identifier Distribution

CANopen Communication Profile CiA

In step 2 the Disconnect_Remote_Node service is executed. By receiving the service indication the devices enter the node state Disconnected. After entering this state (and optionally performing an additional local initialisation depending on the configured parameters) the devices have to execute the local Connect_Node service for entering the node state Connecting. During step 3 the NMT Master Application performs the identification of all nodes i n the network by repeated execution of the Connect_Remote_Node service. Within this service also the node guarding parameters are negotiated between NMT Master and NMT Slaves and node guarding is started. In step 4 the assignment of COB-IDs to the configured PDOs and additional SDOs is performed by the DBT (if COB-ID distribution shall be performed). The COB-IDs for the default-SDOs according to the Predefined Connection Set should not be changed. Step 5 is an optional step. It can be used to ensure that all nodes are synchronised by the SYNC object before entering the node state Operational in step 6. The synchronisation is done by starting the cyclic transmission of the SYNC object and waiting a sufficient span of time to allow all nodes to synchronise. With step 6 all nodes are enabled to communicate via their PDO objects. If the extended network initialisation process is not supported by a device (e.g. Minimum Capability Device, see 8.3) or if e.g. the devices have already been configured completely in a previous extended boot-up and have stored their configuration, the minimum boot-up shown in Figure 8-5 can be applied. The minimum boot-up has to be supported by all CANopen devices. Configuration of all device parameters, including communication parameters (via Default SDO)

(Optional) start transmission of SYNC, wait for synchronisation of all devices

(Optional) Start of Node Guarding

Setting of all nodes to the operational state

Figure 8-5: Flow Chart of the Minimum Network Initialisation Process Step A corresponds to step 1 of the extended network initialisation process. Step B corresponds to step 5 of the extended network initialisation process. In Step C Node guarding can be activated (if supported) using the guarding parameters configured in step A. With step D all nodes are enabled to communicate via their PDO objects.

8.3

Minimum Capability Device


8-9

Network Management and Identifier Distribution

CANopen Communication Profile CiA

To enable devices which do not support the complete DBT- and NMT Slave functionality to co-operate with full capability devices, the following minimal capabilities are required: Module-ID, Object dictionary, depending on the device functionality, One SDO, supporting the mandatory entries (read only) Support of the following services as NMT Slave: Reset_Node, Enter_PreOperational_State, Start_Remote_Node, Stop_Remote_Node, Reset_Communication Default profile ID-allocation scheme In Figure 8-6 the state diagram of a node with minimum capability is shown. Minimum capability devices enter the Pre-Operational state directly after finishing the device initialisation. During this state device parameterisation and ID-allocation via SDO (e.g. using a configuration tool) is possible. Then the nodes can be switched directly into the Operational state. By switching a device into the Prepared16 state it is forced to stop the communication altogether (except node guarding, if active). Furthermore, this state can be used to achieve certain application behaviour. The definition of this behaviour falls into the scope of device profiles. power on

Initialisation (11) (12) (10)

Pre-Operational (7) (8) Prepared (6) Operational (6) (7) (8)

Figure 8-6: State Diagram of a Minimum Capability Device (6) (7) (8) (10) (11) (12) Start_Remote_Node indication Stop_Remote_Node indication Enter_Pre-Operational_State indication Reset_Node indication Reset_Communication indication Initialisation automatically finished enter Pre-Operational

16

Note that the NMT master does not have to use the Prepared state during boot-up. Minimal Boot-Up consists of one CAN message: a broadcast Start_Remote_Node indication. 8-10

Network Management and Identifier Distribution

CANopen Communication Profile CiA

8.4

Allocation of COB-ID's and Inhibit-Times


As CAN is a communication object (COB-) based network where each communication object has an associated identifier which specifies its priority implicitly, the allocation of identifiers to the COB's is an essential issue in the system design. Inhibit-times are defined by CMS to prevent high priority messages to flood the bus to such an extent, that lower priority messages are denied bus access at all times. The inhibit-time specifies the time period during which a certain COB must not be transmitted again. The communication object identifiers (COB-ID's) and inhibit-times may be distributed to the devices either statically or dynamically. Static distribution means that the identifiers and inhibit-times are fixed by the module suppliers and may be changed by the system integrator through module specific means such as setting dip-switches, adapting firmware, etc. Dynamic distribution means that the identifiers and inhibit-times are distributed via the CAN network through standard DBT services and protocols or via SDO. The dynamic distribution is the preferred method in the CANopen Communication Profile. Some identifiers (1-7, 1740-1760dec) have been reserved by CANopen for future enhancements of the communication profile. They may still be used in applications employing dynamic distribution on all devices, but it is not recommended to use them.

8.4.1

Predefined Connection Set In order to reduce configuration effort for simple networks a mandatory default identifier allocation scheme is defined. These identifiers are available in the Pre-Operational state directly after initialisation (if no modifications have been stored) and may be modified by means of dynamic distribution. A device has to provide the corresponding identifiers only for the supported communication objects. The default profile ID-allocation scheme (Table 8-3 + 8-4) consists of a functional part, which determines the object priority and a module-ID-part, which allows to distinguish between devices of the same functionality. The ID-allocation scheme corresponds to a pre-defined master/slave connection set and allows a peer-to-peer communication between a single master device and up to 127 slave devices. It also supports the broadcasting of non-confirmed NMT-services, SYNC- and Time-Stamp-objects and node guarding. Broadcasting is indicated by a module-Id of zero. The pre-defined master/slave connection set supports one emergency object, one SDO, at maximum 2 Receive-PDOs and 2 Transmit-PDOs and the node guarding object.

Bit-Nr.: COB-Identifier

10

Function C d

Module-ID

Figure 8-7: Identifier allocation scheme for the pre-defined master/slave connection set

8-11

Network Management and Identifier Distribution

CANopen Communication Profile CiA

Table 8-3 and Table 8-4 show the supported objects and their allocated COB-IDs. object function code (binary) 0000 0001 0010 resulting COB-ID Communication Parameters at Index (1005h) CMS priority group 0 0 1

NMT SYNC TIME STAMP

0 128 256

Table 8-3: Broadcast Objects of the Pre-defined Master/Slave Connection Set object function code (binary) 0001 0011 0100 0101 0110 1011 1100 1110 resulting COB-IDs Communication Parameters at Index 1800h 1400h 1801h 1401h CMS priority group 0,1 1,2 2 2,3 3,4 6 6,7 (100Eh) -

EMERGENCY PDO1 (tx) PDO1 (rx) PDO 2 (tx) PDO2 (rx) SDO (tx) SDO (rx) Nodeguard

129 - 255 385 - 511 513 - 639 641 - 767 769 - 895 1409 - 1535 1537 - 1663 1793-1919

Table 8-4: Peer-to-Peer Objects of the Pre-defined Master/Slave Connection Set17 If devices with and without DBT capability shall operate in the same network, it is necessary to reserve the corresponding default-COB-IDs in the DBT data base by predefinitions during the boot-up process. If the default ID-allocation is overwritten by a configuration tool, the corresponding predefinitions should be deleted in the COB data base. 8.4.2 Dynamic Distribution CAN Application Layer (CAL) uses a CMS priority level model (see /11/). It describes 8 priority levels with 220 identifiers each and comprises the identifiers 1 to 1760. The remaining identifiers (0, 1761-2031) are reserved for network control by NMT, DBT and LMT. The first step in the system design is to allocate the appropriate priority levels to the various communication objects. As CANopen devices feature a default identifier allocation for a basic set of communication objects, one can start from there and modify the allocation if necessary using either SDO services or DBT (if the extended boot-up is supported). In order to guarantee a minimum jitter the synchronisation message (SYNC) has the highest priority of all messages that occur in normal operation. For transmitting emergency messages each node in the network must be able to use messages with the highest available priority. For these exceptional messages a number of identifiers in priority level 0 and 1 have been reserved. The time stamp messages have been allocated to priority level 1, with lower priority than the emergency messages . The remaining identifiers above the PDOs are reserved for other synchronisation purposes.

17

The table has to be seen from the devices point of view. 8-12

Network Management and Identifier Distribution

CANopen Communication Profile CiA

The CANopen Communication Profile describes two different PDO modes (see chapter 5). One is used for synchronous data exchange and the other one for asynchronous message transfer. To guarantee the cyclic behaviour of the system data exchange a higher priority (suggested: level 2) is allocated to the synchronous PDO's than to the asynchronous PDO's (level 3 - 5). Priority level 6 - 7 has been suggested for the SDO's. A special feature of the Network Management (NMT) is the life guarding/node guarding capability. For that purpose a range of 255 identifiers have been reserved starting at 1761.

CMS priority level 0 (Id 1 - 220) 1 (Id 221 - 440)

message / object - Synchronisation - Emergency (fault) - Emergency (fault) - Network timing (SYNC, time stamp) - other high priority sync. Messages - PDO (synchronous) - PDO (asynchronous)

2 (Id 441 - 660) 3 (Id 661 - 880) 4 (Id 881 - 1100) 5 (Id 1101 - 1320) 6 (Id 1321 - 1540) 7 (Id 1541 - 1760)

- SDO's reserved for SDO's Table 8-5: Suggested Message Priorities

8-13

Network Management and Identifier Distribution

CANopen Communication Profile CiA

8.4.3

Naming Conventions CMS Naming Conventions The CMS Naming Conventions of the CAN Application Layer define a syntax to create the names of CMS objects and COB's. The dynamic distribution of COB-ID's is based on CMS object names.

CMS Object Name Syntax:

<prof-id> <appl-spec-name> <node-ID>

<prof-id>: 3 numeric characters for a device profile number registered by the CiA18. <appl-spec-name>: The first four (1 - 4) characters should identify what part of the CANopen Communication Profile is modelled by this particular CMS object.

Abbreviation SYNC TIME EMCY SDO_ TPDO or RPDO

part of communication profile SYNC message time stamp message emergency message service data object (SDO) process data object (PDO)

The remaining three characters (5 - 7) should be interpreted as three ASCII-numbers. <node-ID> : 3 numerical characters represent the node-ID of the module where the CMS object is used. The node-ID is defined by the NMT. The CMS names can be automatically generated by using these naming conventions. This is useful if the number of used PDO's is not fixed. Names will only be generated for the needed PDO's.

18

For instance '401' is used for the I/O modules profile. 8-14

Error Handling

CANopen Communication Profile

CiA

Error Handling
All types of errors detectable by the devices in an industrial system can be grouped into the five classes shown below: Bus errors - usually electrical and wiring faults. Communications or protocol errors - for example, a specific bit in a telegram is not set as expected. Life guarding errors - life guarding telegrams have not been received by a device within a specified time-out period. Applications errors - such as accessing a device which is not available. Device failures - such as hardware failures on a device. Bus Errors - Low level communications errors are catered for implicitly by the CAN specification. Only under complete bus failure would a node be aware of such errors. The error response then would be to go 'bus-off' and attempt to achieve a 'safe' hardware state. The NMT master is aware of the devices active on the bus via the node guarding mechanism. Protocol Errors - Such errors can occur for example during domain downloads. A typical response to this kind of error would be to signal failure via the appropriate protocol (e.g. initiating the abort of a domain transfer) and ignoring the contents of the partially received information. The device would still maintain its current state of readiness i.e. remain operational. Life guarding Errors - are dependent upon what type of life guarding is supported by a device. If the device possesses full NMT life guarding the error mechanism depends on whether the NMT Master detects a time out receiving a response from the device to a life guarding telegram or whether the module itself detects a time out because no life guarding telegram has been received from the NMT Master within its defined time out period. In the first case, it should be tried to shut-down all devices in the network and then perform a warm-start. In the second case, the device would assume that the NMT Master is not operational and must indicate this to its application19. Application Errors - Such errors could occur, for example, in a Programmable Logic Controller (PLC) if an application program tried to access an output signal which did not exist. A typical response would be to indicate to the application that an error had occurred and send an emergency telegram. Device Failures - Such errors could occur, for example, in a Drive Unit when the temperature of power components exceeds a critical limit. To allow the response to such cases to be application dependent such an error would result in the transmission of an emergency telegram. A time-out period would be initiated and if the device did not get any response within the device dependent time limit the device would take its own safe action e.g. put all outputs into a default 'safe' state.

19

The definition of device reactions to life guarding errors falls in the scope of the device profile. 9-1

Error Handling

CANopen Communication Profile

CiA

9.1

Node Guarding / Life Guarding


The communication interface of a particular device is assumed to be in a certain state in order to be able to process these messages correctly. However there could occur local events on a device that force it to a different state than was assumed by the transmitter of a message. Especially, it could happen that due to an error a particular device goes to the Disconnected State and does no longer take part on the bus communication. To detect these errors with devices that do not transmit PDO's regularly, the NMT Master manages a network database where, besides other information, the expected states of all connected devices are recorded. The NMT Master regularly retrieves the actual states of all devices on the network and compares them to the states recorded i n the network database. Mismatches are indicated first locally on the NMT Master through the Network Event service. Consequently the application must take appropriate actions to ensure that all devices on the bus will go to a save state. Generally, the application will first force all devices to the Disconnected State and then perform a new boot-up sequence. Node Guarding is optional. It starts for the slave when the first remote-transmit-request for its guarding identifier is received. This may be during the node-connect phase (extended boot-up) or later. The slave uses the guard time and life-time factor from its object dictionary (either default values or modified at any stage). If guard time and life time factor are zero (default values), the NMT Slave does not guard the NMT Master (lifeguarding). If the extended boot-up is used, it is recommended that the NMT Master distributes node-guarding identifiers starting from 1793dec, as this enables him to include very simple devices in the network without readjustments. With devices which are configured to use a PDO on a cyclic basis the application may be able to detect fatal errors by means of missing telegrams. These devices do not have to support guarding services. Whether or not a device needs to be guarded can be indicated to the NMT Master during the boot-up phase of the network.

9.2

Emergency Telegram
The Life Guarding mechanism provides a means for detecting errors in the network interfaces of devices. However, it cannot detect failures within the device itself. For instance, the temperature of some power components on a device could exceed a critical limit whereas the network interface could still be in good working condition. For notification of this type of errors emergency telegrams have been introduced (see chapter 7.3).

9-2

Dictionary Structure and EntriesCANopen Communication Profile

CiA

10

Dictionary Structure and Entries


This section details the Object Dictionary structure and entries which are common to all devices. The format of the object dictionary entries is shown below: Index (hex) Object (Symbolic Name) Name Type Attrib. M/O

Table 10-1: Format of Object Dictionary Headings The complete object dictionary consists of the six columns shown above. The Index column denotes the objects position within the object dictionary. This acts as a kind of address to reference the desired data field. The sub-index is not specified here. The sub-index is used to reference data fields within a complex object such as an array or record. The Object column contains the Object Name according to the table below and is used to denote what kind of object is at that particular index within the object dictionary. The following definitions are used: Object Name NULL DOMAIN DEFTYPE Comments A dictionary entry with no data fields Large variable amount of data e.g. executable program code Denotes a type definition such as a Boolean, unsigned16, float and so on Defines a new record type e.g. the PDOMapping structure at 21 Hex A single value such as an unsigned8, Boolean, float, integer16, visible string etc. A multiple data field object where each data field is a simple variable of the SAME basic data type e.g. array of unsigned16 etc. A multiple data field object where the data fields may be any combination of simple variables Object Code 0 2 5

DEFSTRUCT VAR

6 7

ARRAY

RECORD

Table 10-2: Object Dictionary Object Definitions The name column provides a simple textual description of the function of that particular object. The type column gives information as to the type of the object 20. These include the following pre-defined types: Boolean, floating point number, Unsigned Integer, Signed Integer, visible/octett string, date, time-of-day, timedifference and domain (see /8/). It also includes the pre-defined complex data type PDOMapping and may also include others which are either manufacturer or device specific. The Attribute column defines the access rights for a particular object.
20

It is not possible to define records of records, arrays of records or records with arrays as fields of that record. In the case where an object is an array or a record the subindex is used to reference one data field within the object. Note that sub-index 0 contains the number of elements and therefore itself is not part of the array. 10-1

Dictionary Structure and EntriesCANopen Communication Profile

CiA

It can be of the following: Attribute rw wo ro const Description read and write access write only access read only access read only access, value is constant

Table 10-3: Access Attributes for Data Objects The M/O column defines whether the object is Mandatory or Optional. A mandatory object must be implemented on a device. An optional object need not be implemented on a device.

10.1

Dictionary Components
The overall layout of the object dictionary is shown in Table 4-1. Index 01h-1Fh contain the standard data types, index 20h - 22h contain predefined complex data types. The range of indices from 23-3FH is not defined yet but reserved for future standard data structures. The range of indices from 40-5FH is free for manufacturers to define custom data types. The range 60-0FFFH is reserved for possible future enhancements of the CANopen Communication Profile. The range 1000H-1FFFH contains the communication specific object dictionary entries defined by the CANopen Communication Profile. These parameters are called communication entries, their specification is common to all device types, regardless of the device profile they use. The objects in range 1000H1FFFH not specified by this communication profile are reserved for further use. The range 2000H-5FFFH is free for manufacturer specific profile definition. The range 6000H-FFFH contains the standardised device profile parameters.

10-2

Dictionary Structure and EntriesCANopen Communication Profile

CiA

10.1.1

Data Types The static data types are placed in the object dictionary for definition purposes only. However, indices in the range 1-7 can be mapped as well in order to define the appropriate space in the PDO as not being used by this device (dont care). An example mapping can be found in the appendix. The order of the data types is as follows: Index 0001 0002 0003 0004 0005 0006 0007 0008 0009 000A 000B 000C 000D 000E 000F 0010001F 0020 0021 0022 0023003F 0040005F 0060007F 0080009F Object DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE DEFTYPE Null Objects DEFSTRUCT DEFSTRUCT DEFSTRUCT Null Objects DEFTYPE DEFTYPE DEFSTRUCT Name Boolean Integer8 Integer16 Integer32 Unsigned8 Unsigned16 Unsigned32 Floating Point (Float) Visible String Octet String Date Time Of Day Time Difference Bit String Domain (reserved) PDO CommPar PDO Mapping SDO Parameter (reserved) Manufacturer Specific Data Types Device Profile Specific Standard Data Types Device Profile Specific Complex Data Types

Table 10-4: Object Dictionary Data Types The data type representations used are detailed in /8/ . Every device does not need to support all the defined data types. A device only has to support the data-types it uses with the objects in the range 1000H-9FFFH. The predefined complex data-types are placed after the standard data-types. Three types are defined at present, the PDO Communication Parameter (PDO CommPar) the PDO Mapping record and the SDO Parameter record (SDO_Par). They are placed at index 20H, 21H and 22H.

10-3

Dictionary Structure and EntriesCANopen Communication Profile

CiA

A device may optionally provide the length of the standard data types encoded as Unsigned32 at read access to the index that refers to the data type. E.g. index 000Bh (Date) contains the value 38h=56dec as the data type Date is encoded using 56 bits (see /8/). If the length is variable (e.g. 000Fh = Domain), the entry contains 0h. For the supported complex data types a device may optionally provide the structure of that data type at read access to the corresponding index. Sub-index 0 then provides the number of entries at this index (not counting sub-indices 0 and 255), and the following sub-indices contain the data type according to table 10-4 encoded as Unsigned8. The entry at Index 20h describing the structure of the PDO Communication Parameter then looks as follows (see also 10.1.2):

Subindex 0h 1h 2h 3h 4h

Value 04h 07h 05h 06h 05h

(Description) (4 subindices follow) (Unsigned32) (Unsigned8) (Unsigned16) (Unsigned8)

Standard (simple) and complex manufacturer specific data types can be distinguished by attempting to read sub-index 1h: At a complex data type the device returns a value and sub-index 0h contains the number of sub-indices that follow, at a standard data type the device aborts the domain transfer as no sub-index 1h available. In that case sub-index 0h contains the length of the simple data type in bits. Note that some entries of data type Unsigned32 have the character of a structure (e.g. PDO COB-ID entry, see Figure 10-1). If an object dictionary entry (index) contains several sub-indices, then sub-index 0 describes the number of entries (sub-indices) that follow (not counting sub-indices 0 and FFh). The number of entries is encoded as Unsigned8. Sub-index FFh (255dec) describes the structure of the entry by providing the data type and the object type of the entry. It is encoded as Unsigned32 and organised as follows: MSB bits 31-16 value reserved (value: 00 00h) encoded as 15-8 Data Type (see Table 10-4) Unsigned8 7-0 Object (see Table 10-2) Unsigned8 LSB

It is optional to support Sub-Index FFh. If it is supported throughout the object dictionary and the structure of the complex data tapes is provided as well, it enables one to upload the entire structure of the object dictionary. As Sub-index has the same structure and meaning throughout the object dictionary, it is not described at each detailed object description (Chapter 10.3).

10-4

Dictionary Structure and EntriesCANopen Communication Profile

CiA

10.1.2

PDO Communication Parameter The format of the structure is as follows: Index 0020H Sub-Index 0H 1H 2H 3H 4H Field In PDO Communication Record number of supported entries in the record COB-ID used by PDO transmission type inhibit time CMS priority group Data Type Unsigned8 Unsigned32 Unsigned8 Unsigned16 Unsigned8

Table 10-5: PDO Communication Parameter Record If the device supports the identifier distribution via DBT the value on sub-index 0H is 4 otherwise it is 2 (inhibit time not supported) or 3. The COB-ID at Index 20H, Sub-Index 1H is defined using data type Unsigned32 in order to cater for 11-bit CAN Identifiers (CAN 2.0A) as well as for 29-bit CAN identifiers (CAN 2.0B). The entry has to be interpreted as defined in Figure 10-1 and Table 10-6.

Unsigned32 MSB bits 11-bit-ID 29-bit-ID 31 0/1 0/1 30 29 28-11 0/1 0 0/1 1

LSB 10-0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11-bit Identifier 0 29-bit Identifier

Figure 10-1: Structure of PDO COB-ID entry bit number 31 (MSB) 30 29 28 - 11 10-0 (LSB) value 0 1 0 1 0 1 0 X X meaning PDO valid PDO not valid RTR allowed on this PDO no RTR allowed on this PDO 11-bit ID (CAN 2.0A) 29-bit ID (CAN 2.0B) if bit 29=0 if bit 29=1: bits 28-11 of 29-bit-COB-ID bits 10-0 of COB-ID

Table 10-6: Description of PDO COB-ID entry The PDO valid/not valid allows to select which PDOs are used in the operational stage. There may be PDOs fully configured (e.g. by default) but not used, and therefore set to "not valid". Bit 29 and 30 may be static (not changeable), e.g. due to hardware restrictions. In that case no error is signalled on the attempt to change them.

10-5

Dictionary Structure and EntriesCANopen Communication Profile

CiA

The transmission type (sub-index 2) defines the transmission character of the PDO (see section 5.2). Table 10-7 describes the usage of this entry.

transmission type

PDO transmission cycli c acycli c X X synchronou s X X - reserved X X X X X X asynchronous RTR only

0 1-240 241-251 252 253 25421 25522

Table 10-7: Description of transmission type Synchronous (transmission types 0-240 and 252) means that the transmission of the PDO shall be related to the SYNC object as described in chapter 6.1. Preferably the devices use the SYNC as a trigger to output or actuate based on the previous synchronous Receive-PDO respectively to update the data transmitted at the following synchronous Transmit-PDO. Details of this mechanism depend on the device type and are defined in the device profile if applicable. Asynchronous means that the transmission of the PDO is not related to the SYNC object. A transmission type of zero means that the message shall be transmitted synchronously with the SYNC object but not periodically. A value between 1 and 240 means that the PDO is transmitted synchronously and cyclically, the transmission type indicating the number of SYNC objects between two PDO transmissions. The transmission types 252 and 253 mean that the PDO is an event without immediate notification and is only transmitted on remote transmission request. At transmission type 252, the data is updated (but not sent) immediately after reception of the SYNC object. At transmission type 253 the data is updated at the reception of the remote transmission request (hardware and software restrictions may apply). Transmission type 254 means, the application event is manufacturer specific (manufacturer specific part of the object dictionary), transmission type 255 means, the application event is defined in the device profile. Sub-index 3H contains the inhibit time as specified in /11/. If the inhibit time feature is not supported, the entry at sub-index 0H is set to 2. Sub-index 4H contains the CMS priority group as specified in /11/ that the device requests for this PDO if DBT services are executed. Devices that do not support DBT do not need to support this entry (value at sub-index 0H is set to 3H). The value range is 0...7.

21 22

The transmission of this PDO is initiated by an event on the device. The event is manufacturer specific. The transmission of this PDO is initiated by an event on the device. This event must be defined in the device profile. 10-6

Dictionary Structure and EntriesCANopen Communication Profile

CiA

10.1.3

PDO Mapping The PDOMapping entry describes the PDO content by listing the sequence and length of the mapped object dictionary entries (see Figure 10-2).

Object dictionary xxxxh PDOMapping 0 1 2 3 yyyyh zzzzh xxxxh 3 yyh zzh xxh 8 16 8 yyyyh yyh Application Object 2 xxh Application Object 1

zzzzh

zzh

Application Object 3

PDO:

Appl. Obj. 2

Application Object 3 Figure 10-2 : Principle of PDOMapping

Appl. Obj. 1

The PDOMapping is structured as follows:

Index 0021H

Sub-Index 0H 1H 2H

Field in PDOMapping Record number of mapped objects in PDO 1st object to be mapped 2nd object to be mapped :::::::: 64th object to be mapped Table 10-8: PDO Mapping

Data Type Unsigned8 Unsigned32 Unsigned32 :::::: Unsigned32

::::: :

:::::: 40H

The structure of the entries from sub-index 1H - 40H is as follows:

Byte:

MSB index (16 bit) sub-index (8 bit)

LSB object length (8 bit)

Figure 10-3: Structure of PDO Mapping Entry

10-7

Dictionary Structure and EntriesCANopen Communication Profile

CiA

The object length is encoded as unsigned8 with a value range of 1...64. This parameter can be used to verify the overall mapping length. It is mandatory. If the change of the PDO mapping cannot be executed (e.g. the PDO length is exceeded or the SDO client attempts to map an object that cannot be mapped) the device responds with an Abort_Domain_Transfer service. Writing to sub-index 0 determines the valid number of objects that have been mapped. E.g. if 64 objects of data type Boolean in the mapping structure are to be replaced by 8 objects of data type Unsigned8, first an 8 is written to sub-index 8, thus setting valid only the first 8 objects. These can then be re-mapped without immediately exceeding the length of the PDO. If data types (Index 1-7h) are mapped they serve as dummy entries. The corresponding data in the PDO is not evaluated by the device. This optional feature is useful e.g. to transmit data to several devices using one PDO, each device only utilising a part of the PDO. A device that supports dynamic mapping of PDOs must support this during the PreOperational state. If dynamic mapping during the Operational state is supported, the SDO client is responsible for data consistency.

10.1.4

SDO Parameter In order to describe the SDOs used on a device the data type SDO parameter object is introduced. The data type has the index 22h in the object dictionary. The object is structured as follows:

Index 0022H

Sub-Index 0H 1H 2H 3H

Field in SDOParameter Record number of supported entries COB-ID client -> server COB-ID server -> client node ID of SDOs client resp. server Table 10-9: SDO Parameter Record

Data Type Unsigned8 Unsigned32 Unsigned32 Unsigned8

The number of supported entries in the SDO object record is specified at sub-index 0H. The values at 1H and 2H specify the COB-ID for this SDO. The usage of extended identifiers is possible (if DBT is not used). Subindex 3 gives the server of the SDO i n case the record describes an SDO for which the device is client and gives the client of the SDO if the record describes an SDO for which the device is server. Devices which are clients for the SDO must support the entry 3H (they must know the node id of the SDO server). If the device is the server of the SDO the sub-index 3H is optional.

Unsigned32 MSB bits 11-bit-ID 29-bit-ID 31 0/1 0/1 30 0 0 29 0 1 28-11

LSB 10-0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11-bit Identifier 0 29-bit Identifier

Figure 10-4: Structure of SDO COB-ID entry 10-8

Dictionary Structure and EntriesCANopen Communication Profile

CiA

10-9

Dictionary Structure and EntriesCANopen Communication Profile

CiA

bit number value 31 (MSB) 30 29 28 - 11 0 1 0 0 1 0 X

meaning SDO valid SDO not valid reserved (always 0) 11-bit ID (CAN 2.0A) 29-bit ID (CAN 2.0B) if bit 29=0 if bit 29=1: bits 28-11 of 29-bit-COBID bits 10-0 of COB-ID

10-0 (LSB) X

Table 10-10: Description of SDO COB-ID entry An SDO is only valid if booth SDO-valid-bits are 0. Bit 29 may be static (not changeable) e.g. due to hardware restrictions. Overview Communication Profile Object Dictionary Entries Table 10-11 gives an overview over the object dictionary entries defined by the communication profile: Index (hex) 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 100A 100B 100C 100D 100E 100F 1010 1011
23

Object (Symbolic Name) VAR VAR VAR ARRAY ARRAY VAR VAR VAR VAR VAR VAR VAR VAR VAR VAR VAR VAR VAR

Name

Type

Acc.
23

M/O

device type error register manufacturer status register pre-defined error field number of PDOs supported COB-ID SYNC-message communication cycle period synchronous window length manufacturer device name manufacturer hardware version manufacturer software version Node-ID guard time life time factor COB-ID guarding protocol number of SDOs supported store parameters restore default parameters

Unsigned32 Unsigned8 Unsigned32 Unsigned32 Unsigned32 Unsigned32 Unsigned32 Unsigned32 Vis-String Vis-String Vis-String Unsigned32 Unsigned32 Unsigned32 Unsigned32 Unsigned32 Unsigned32 Unsigned32

ro ro ro ro ro rw rw rw ro ro ro ro rw rw rw ro rw rw

M M O O O O O O O O O O O O O O O O

Access type listed here may vary for certain sub-indices. See detailed object specification. 10-10

Dictionary Structure and EntriesCANopen Communication Profile

CiA

1012 1013 1014 1015 ::::: 11FF 1200 1201 ::::: 127F 1280 1281 ::::: 12FF 1300 ::::: 13FF 1400 1401 ::::: 15FF 1600 1601 ::::: 17FF 1800 1801 ::::: 19FF

VAR VAR VAR :::::

COB-ID time stamp high resolution time stamp COB-ID Emergency reserved ::::: reserved

Unsigned32 Unsigned32 Unsigned32 :::::

rw rw rw :::::

O O O :::::

Server SDO Parameter (22H) RECORD RECORD ::::: RECORD RECORD RECORD ::::: RECORD ::::: 1 Server SDO parameter 2
nd st

SDOParameter SDOParameter ::::: SDOParameter SDOParameter SDOParameter ::::: SDOParameter :::::

ro rw ::::: rw rw rw ::::: rw :::::

O O ::::: O O O ::::: O :::::

Server SDO parameter


th

::::: 128 Server SDO parameter 1 Client SDO parameter 2


nd st

Client SDO Parameter (22H) Client SDO parameter


th

::::: 128 Server SDO parameter reserved ::::: reserved

Receive PDO Communication Parameter (20H) RECORD RECORD ::::: RECORD ARRAY ARRAY ::::: ARRAY RECORD RECORD ::::: RECORD 1 st receive PDO Parameter 2
nd

PDOCommPar PDOCommPar :::::

rw ::::: rw rw rw ::::: rw rw rw ::::: rw

M/O* M/O* ::::: M/O* M/O* M/O* ::::: M/O* M/O* M/O* :::: M/O O M/O* M/O* ::::: M/O*

receive PDO Parameter


th

::::: 512 receive PDO Parameter 1 st receive PDO mapping 2


nd

PDOCommPar PDOMapping PDOMapping ::::: PDOMapping PDOCommPar PDOCommPar ::::: PDOCommPar

Receive PDO Mapping Parameter (21H) receive PDO mapping


th

::::: 512 receive PDO mapping

Transmit PDO Communication Parameter (20H) 1st transmit PDO Parameter 2


nd

transmit PDO Parameter


th

::::: 512 transmit PDO Parameter

Transmit PDO Mapping Parameter (21H) 1A00 1A01 ::::: 1BFF ARRAY ARRAY ::::: ARRAY 1 st transmit PDO mapping 2
nd

PDOMapping PDOMapping ::::: PDOMapping

rw rw ::::: rw

transmit PDO mapping


th

::::: 512 transmit PDO mapping

* If a device supports PDOs, the according PDO communication parameter and PDO mapping entries in the object dictionary are mandatory. These may be read_only. Table 10-11: Standard Objects

10-11

Dictionary Structure and EntriesCANopen Communication Profile

CiA

10.2

Detailed Object Specification


So far, parts of the object dictionary have been illustrated in tabular form. All device profiles should contain a full object dictionary definition in this format. However this provides only an overall description of a modules capabilities. Each object dictionary entry needs to be specified precisely. Every object dictionary entry must be described in the following manner: OBJECT DESCRIPTION INDEX Name Object Code Number Of Elements Data Type Profile Index Number e.g. 6059H Name of parameter e.g. 'Frequency-Motor-Min-Max' Variable classification e.g. 8H (=Array) not counting sub-indices 0h (contains no. of elements) and FFh (contains data type), e.g. 4H = 4 elements (this field is used only if object is not a simple variable) Profile type number e.g. 7H => Integer32 Table 10-12: Format of an Object Description The Object Code must be one of those defined in Table 10-2 above. For better readability, the Object Description should contain the symbolic Object Name rather than the numeric Object Code, e.g. ARRAY instead of 8H. VALUE DESCRIPTION Sub-Index Description Object Class Access PDO Mapping number of sub-index being described (field only used for arrays & records) Description of the functionality of the entry. Optional Or Mandatory Read Only (ro) or Read/Write (rw) or Write Only (wo) Optional/Default/No - can this object be mapped to a PDO. Description: Optional: Object may be mapped into a PDO Default: Object is part of the default mapping (see device profile) No: Object must not be mapped into a PDO Value Range Mandatory Range Default Value size of data e.g. Unsigned32 (No) not applicable or range defined as a min & max. value e.g. -50 to +200 (No) not applicable or default value of an object after device initialisation Table 10-13: Object Value Description Format For simple variables the value description appears once without the sub-index field. For arrays or records the value description must be defined for each element (sub-index).

10-12

Dictionary Structure and EntriesCANopen Communication Profile

CiA

10.3

Detailed Specification of Communication Profile specific Objects


Object 1000H: Device Type Contains information about the device type. The object at index 1000H describes the type of device and its functionality. It is composed of a 16bit field which describes the device profile that is used and a second 16bit field which gives additional information about optional functionality of the device. The Additional Information parameter may be device specific. Its specification does not fall within the scope of this document, it is defined in the appropriate device profile. OBJECT DESCRIPTION INDEX Name Object Code Data Type VALUE DESCRIPTION Object Class Access PDO Mapping Value Range Mandatory Range Default Value Byte: MSB Additional Information Device Profile Number Mandatory ro No Unsigned32 No No LSB 1000H device type VAR Unsigned32

Figure 10-5: Structure of the Device Type Parameter Object 1001H: Error Register This object is an error register for the device. The device can map internal errors in this byte. OBJECT DESCRIPTION INDEX Name Object Code Data Type VALUE DESCRIPTION Object Class Access PDO Mapping Value Range Mandatory Range Default Value Mandatory ro Optional Unsigned8 No No 10-13 1001H error register VAR Unsigned8

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Bit 0 1 2 3 4 5 6 7

M/O M O O O O O O O

Meaning generic error current voltage temperature communication error (overrun, error state) device profile specific reserved manufacturer specific

Table 10-14: Structure of the Error Register If a bit is set to 1 the specified error has occurred. The only mandatory error that has to be signalled is the generic error. Object 1002H: Manufacturer Status Register This object is a common status register for manufacturer specific purposes. In this document only the size and the location of this object is defined. OBJECT DESCRIPTION INDEX Name Object Code Data Type VALUE DESCRIPTION Object Class Access PDO Mapping Value Range Mandatory Range Default Value Optional ro Optional Unsigned32 No No 1002H manufacturer status register VAR Unsigned32

10-14

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Object 1003H: Pre-defined Error Field The object at index 1003H holds the errors that have occurred on the device and have been signalled via the Emergency Object. In doing so it provides an error history. 1. The entry at sub-index 0 contains the number of actual errors that are recorded in the array starting at sub-index 1. 2. Every new error is stored at sub-index 1, the older ones move down the list. 3. Writing a 0 to sub-index 0 deletes the entire error history (empties the array) 4. The error numbers are of type Unsigned32 and are composed of a 16bit error code (see Table 7-1) and a 16bit additional error information field which may be device specific. The error code is contained in the lower 2 bytes (LSB) and the additional information is included in the upper 2 bytes (MSB). If this object is supported it must consist of two entries at least. The length entry on sub-index 0H and at least one error entry at sub-index 1H. Byte: MSB Additional Information Error code LSB

Figure 10-6: Structure of the pre-defined error field OBJECT DESCRIPTION INDEX Name Object Code Number of Elements Data Type VALUE DESCRIPTION Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value 0H number of errors Mandatory rw No Unsigned8 1 No 1H standard error field Mandatory ro No Unsigned32 No No 1003H pre-defined error field ARRAY 1(Mandatory), 2-254 (Optional) Unsigned32

Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value

10-15

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value to Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value

2H standard error field Optional ro No Unsigned32 No No

FEH standard error field Optional ro No Unsigned32 No No

Object 1004H: Number of PDOs supported Index 1004H contains information about the maximum number of PDOs supported by the device. It is distinguished between input and output PDOs and between synchronous and asynchronous transmission. Sub-index 0 describes the overall number of PDOs supported (Synchronous and Asynchronous)24. Sub-index 1 describes the number of synchronous PDOs that is supported by the device, sub-index 2 the number of asynchronous PDOs that is supported. Each of the values is of type Unsigned16. Figure 10-7 shows the structure of this entry. OBJECT DESCRIPTION INDEX Name Object Code Number of Elements Data Type 1004H number of PDOs supported ARRAY 2 Unsigned32

24

A device may support a fixed number of PDOs, each of which may either be of synchronous and asynchronous transmission type. 10-16

Dictionary Structure and EntriesCANopen Communication Profile

CiA

VALUE DESCRIPTION Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value 0H number of PDOs supported Optional ro No unsigned32 0H - 1FF01FFH No 1H number of synchronous PDOs Optional ro No unsigned32 0H - 1FF01FFH No 2H number of asynchronous PDOs Optional ro No unsigned32 0H - 1FF01FFH No

Sub-index MSB 0 1 2 No. of Receive PDOs supported No. of asynchronous Receive PDOs

LSB No. of Transmit PDOs supported No. of asynchronous Transmit PDOs

No. of synchronous Receive PDOs No. of synchronous Transmit PDOs

Figure 10-7: Structure of entry 1004H

10-17

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Object 1005H: COB-ID SYNC message Index 1005H defines the COB-ID of the Synchronisation Object (SYNC). Further, it defines whether the device consumes the SYNC or whether the device generates the SYNC. The structure of this object is shown in Figure 10-8 and Table 10-15. The default value for the SNYC COB-ID is given in chapter 7.1. OBJECT DESCRIPTION INDEX Name Object Code Data Type VALUE DESCRIPTION Object Class Access PDO Mapping Value Range Mandatory Range Default Value Unsigned32 MSB bits 11-bit-ID 29-bit-ID 31 0/1 0/1 30 29 28-11 0/1 0 0/1 1 Optional rw No Unsigned32 No 80h 1005H COB-ID SYNC message VAR Unsigned32

LSB 10-0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11-bit Identifier 0 29 -bit Identifier

Figure 10-8: Structure of SYNC COB-ID entry bit number value 31 (MSB) 30 29 28 - 11 0 1 0 1 0 1 0 X meaning Device does not consume SYNC message Device consumes SYNC message Device does not generate SYNC message Device generates SYNC message 11-bit ID (CAN 2.0A) 29-bit ID (CAN 2.0B) if bit 29=0 if bit 29=1: bits 28-11 of 29-bit-SYNC-COB-ID bits 10-0 of SYNC-COB-ID

10-0 (LSB) X

Table 10-15: Description of SYNC COB-ID entry Bit 29 may be static (not changeable) e.g. due to hardware restrictions.

10-18

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Object 1006H: Communication Cycle Period This object defines the communication cycle period in msec. 0 if not used. OBJECT DESCRIPTION INDEX Name Object Code Data Type VALUE DESCRIPTION Object Class Access PDO Mapping Value Range Mandatory Range Default Value Optional rw No Unsigned32 No 00000000h 1006H communication cycle period VAR Unsigned32

Object 1007H: Synchronous Window Length Contains the length of the time window for synchronous messages in msec. 0 if not used. OBJECT DESCRIPTION INDEX Name Object Code Data Type VALUE DESCRIPTION Object Class Access PDO Mapping Value Range Mandatory Range Default Value Optional rw No Unsigned32 No 00000000h 1007H synchronous window length VAR Unsigned32

10-19

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Object 1008H: Manufacturer Device Name Contains the manufacturer device name. OBJECT DESCRIPTION INDEX Name Object Code Data Type VALUE DESCRIPTION Object Class Access PDO Mapping Value Range Mandatory Range Default Value Optional ro No No No No 1008H manufacturer device name VAR Visible String

Object 1009H: Manufacturer Hardware Version Contains the manufacturer hardware version description. OBJECT DESCRIPTION INDEX Name Object Code Data Type VALUE DESCRIPTION Object Class Access PDO Mapping Value Range Mandatory Range Default Value Optional ro No No No No 1009H manufacturer hardware version VAR Visible String

10-20

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Object 100AH: Manufacturer Software Version Contains the manufacturer software version description. OBJECT DESCRIPTION INDEX Name Object Code Data Type VALUE DESCRIPTION Object Class Access PDO Mapping Value Range Mandatory Range Default Value Optional ro No No No No 100AH manufacturer software version VAR Visible String

Object 100BH: Node-ID The object at Index 100BH contains the Node-ID. The node ID entry has the access type "read only" as it can not be changed using SDO services. However, it is feasible to change it via LMT (see /14/), via hardware (e.g. dip-switch). OBJECT DESCRIPTION INDEX Name Object Code Data Type VALUE DESCRIPTION Object Class Access PDO Mapping Value Range Mandatory Range Default Value MSB Reserved Reserved Reserved Node -ID Optional ro No 1 - 256 1 - 127 No LSB 100BH Node-ID VAR Unsigned32

Figure 10-9: Structure of the Node-ID Parameter

10-21

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Object 100CH: Guard Time The objects at index 100CH and 100DH include the guard time in milli-seconds and the life time factor. The life time factor multiplied with the guard time gives the life time for the Node Guarding Protocol (see /10/). OBJECT DESCRIPTION INDEX Name Object Code Data Type VALUE DESCRIPTION Object Class Access PDO Mapping Value Range Mandatory Range Default Value Optional rw No Unsigned16 No 0h 100CH guard time VAR Unsigned16

Object 100DH: Life Time Factor The life time factor multiplied with the guard time gives the life time for the node guarding protocol (see /10/). OBJECT DESCRIPTION INDEX Name Object Code Data Type VALUE DESCRIPTION Object Class Access PDO Mapping Value Range Mandatory Range Default Value Optional rw No Unsigned8 No 0h 100DH life time factor VAR Unsigned8

10-22

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Object 100EH: Node Guarding Identifier The identifier used for node guarding and life guarding procedure (see chapter 9.1) OBJECT DESCRIPTION INDEX Name Object Code Data Type VALUE DESCRIPTION Object Class Access PDO Mapping Value Range Mandatory Range Default Value Unsigned32 MSB bits 11-bit-ID 29-bit-ID 31 30 29 0 1 28-11 reserved reserved Optional rw No Unsigned32 No 700h + node-ID 100EH node guarding identifier VAR Unsigned32

LSB 10-0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11-bit Identifier 0 29 -bit Identifier

Figure 10-10: Structure of the Node Guarding Identifier entry Bit 29 may be static (not changeable) e.g. due to hardware restrictions. Object 100FH: Number of SDOs Supported If a device supports more than the default SDO the number of supported SDOs is described in this object. This entry shows all available SDOs including the default SDO. The object is composed of a 16bit field which describes the number of Client SDOs and a 16bit field which describes the number of Server SDOs. OBJECT DESCRIPTION INDEX Name Object Code Data Type 100FH number of SDOs supported VAR Unsigned32

10-23

Dictionary Structure and EntriesCANopen Communication Profile

CiA

VALUE DESCRIPTION Object Class Access PDO Mapping Value Range Mandatory Range Default Value Byte: MSB number of client SDOs number of Optional ro No Unsigned32 1h-80h (server), 0-80h (client) No LSB server SDOs

Figure 10-11: Structure of the Number of SDOs entry

Object 1010H: Store parameters This Object supports the saving of parameters in non volatile memory. By read access the device provides information about its saving capabilities. Several parameter groups are distinguished: Sub-Index 0 contains the largest Sub-Index that is supported. Sub-Index 1 refers to all parameters that can be stored on the device. Sub-Index 2 refers to communication related parameters (Index 1000h - 1FFFh manufacturer specific communication parameters). Sub-Index 3 refers to application related parameters (Index 6000h manufacturer specific application parameters). Sub-Index 128 - 254 are reserved for future use. In order to avoid storage of parameters by mistake, storage is only executed when a specific signature is written to the appropriate Sub-Index. The signature is save. Signature ASCII hex MSB e 65h v 76h a 61h LSB s 73h - 9FFFh

At Sub-Index 4 - 127 manufacturers may store their choice of parameters individually.

Figure 10-12: Storage write access signature On reception of the correct signature in the appropriate Sub-Index the device stores the parameter and then confirms the SDO transmission (initiate download response). If the storing failed, the device responds with abort domain transfer, error class 6h, error code 6h (hardware fault). If a wrong signature is written, the device refuses to store and responds with abort domain transfer, error class 8h, error code 0h (other error). On read access to the appropriate Sub-Index the device provides information about its storage functionality with the following format:

10-24

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Unsigned32 MSB bits 31-2 reserved (=0)

LSB 1 0 0/1 0/1

Figure 10-13: Storage read access structure

bit number value 31-2 1 0 0 1 0 0 1

meaning reserved Device does not save parameters autonomously Device saves parameters autonomously Device does not save parameters on command Device saves parameters on command

Autonomous saving means that a device stores the storable parameters in a nonvolatile manner without user request. OBJECT DESCRIPTION INDEX Name Object Code Number of Elements Data Type VALUE DESCRIPTION Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range 0H largest supported Sub-Index Optional ro No Unsigned8 No No 1H save all parameters Optional rw No Unsigned32 (see Fig. 1012+13) No 10-25 1010H store parameters ARRAY 1H - 7FH Unsigned32

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Default Value Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value

No 2H save communication parameters Optional rw No Unsigned32 (see Fig. 1012+13) No No 3H save application parameters Optional rw No Unsigned32 (see Fig. 1012+13) No No 4H - 7FH save manufacturer defined parameters Optional rw No Unsigned32 (see Fig. 1012+13) No No

Object 1011H: Restore default parameters With this object the default values of parameters according to the communication or device profile are restored. By read access the device provides information about its capabilities to restore these values. Several parameter groups are distinguished: Sub-Index 0 contains the largest Sub-Index that is supported. Sub-Index 1 refers to all parameters that can be restored. Sub-Index 2 refers to communication related parameters (Index 1000h - 1FFFh manufacturer specific communication parameters). Sub-Index 3 refers to application related parameters (Index 6000h manufacturer specific application parameters). 10-26 - 9FFFh

Dictionary Structure and EntriesCANopen Communication Profile

CiA

At Sub-Index 4 - 127 manufacturers may restore their individual choice of parameters. Sub-Index 128 - 254 are reserved for future use. In order to avoid the restoring of default parameters by mistake, restoring is only executed when a specific signature is written to the appropriate Sub-Index. The signature is load. Signature ASCII hex MSB d 64h a 61h o 6Fh LSB l 6Ch

Figure 10-14: Restoring write access signature On reception of the correct signature in the appropriate Sub-Index the device restores the default parameters and then confirms the SDO transmission (initiate download response). If the restoring failed, the device responds with abort domain transfer, error class 6h, error code 6h (hardware fault). If a wrong signature is written, the device refuses to restore the defaults and responds with abort domain transfer, error class 8h, error code 0h (other error). The default values are set valid after the device is reset (reset node for subindex 1h 127h, reset communication for subindex 2h). If the device requires storing on command (see 1010h), the appropriate command has to be executed after the reset if the default parameters are to be stored permanently.

restore defaults reset

default values valid

(save)

On read access to the appropriate Sub-Index the device provides information about its default parameter restoring capability with the following format:

Unsigned32 MSB bits 31-1 reserved (=0)

LSB 0 0/1

Figure 10-15: Restoring default values read access structure

bit number value

meaning

10-27

Dictionary Structure and EntriesCANopen Communication Profile

CiA

31-1 0

0 0 1

reserved Device does not restore default parameters Device restores parameters

10-28

Dictionary Structure and EntriesCANopen Communication Profile

CiA

OBJECT DESCRIPTION INDEX Name Object Code Number of Elements Data Type VALUE DESCRIPTION Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value Sub-Index Description Object Class Access PDO Mapping 0H largest supported Sub-Index Optional ro No Unsigned8 No No 1H restore all default parameters Optional rw No Unsigned32 (see Fig. 1014+15) No No 2H restore communication default parameters Optional rw No Unsigned32 (see Fig. 1014+15) No No 3H restore application default parameters Optional rw No 10-29 1011H restore default parameters ARRAY 1H - 7FH Unsigned32

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Value Range Mandatory Range Default Value Sub-Index Description Object Class PDO Mapping Value Range Mandatory Range

Unsigned32 (see Fig. 1014+15) No No 4H - 7FH restore manufacturer defined default parameters Optional No Unsigned32 (see Fig. 1014+15) No

Object 1012H: COB-ID Time-stamp message Index 1012H defines the COB-ID of the Time-Stamp Object (TIME). Further, it defines whether the device consumes the TIME or whether the device generates the TIME. The structure of this object is shown in Figure 10-8 and Table 10-15, it is similar to the entry 1005h (COB-ID SYNC message). OBJECT DESCRIPTION INDEX Name Object Code Data Type VALUE DESCRIPTION Object Class Access PDO Mapping Value Range Mandatory Range Default Value Optional rw No Unsigned32 No 100h 1012H COB-ID time stamp message VAR Unsigned32

10-30

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Object 1013H: High Resolution Time Stamp This object contains a time stamp with a resolution of 1 msec. It can be mapped into a PDO in order to define a high resolution time stamp message. (Note that the data type of the standard time stamp message (TIME) is fixed). Further application specific use is encouraged. OBJECT DESCRIPTION INDEX Name Object Code Data Type VALUE DESCRIPTION Object Class Access PDO Mapping Value Range Mandatory Range Default Value Optional rw Optional Unsigned32 No 00000000h 1013H high resolution time stamp VAR Unsigned32

Object 1014H: COB-ID Emergency Message Index 1014H defines the COB-ID of the Emergency Object (EMCY). The structure of this object is shown in Figure 10-8 and Table 10-15, it is similar to the entry 1005h (COB-ID SYNC message). OBJECT DESCRIPTION INDEX Name Object Code Data Type VALUE DESCRIPTION Object Class Access PDO Mapping Value Range Mandatory Range Default Value Optional rw No Unsigned32 No 80h + node-ID 1014H COB-ID Emergency message VAR Unsigned32

10-31

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Object 1200H - 127FH: Server SDO Parameter These objects contain the parameters for the SDOs for which the device is the server. If a device handles more than one server SDO the default SDO must be located at index 1200H as the first server SDO. This entry is read only25. All additional server SDOs are invalid by default (invalid bit - see table 10-6). The description of the Client of the SDO (Sub-index 3h) is optional. It is not available for the default SDO (no Sub-index 3h at Index 1200H), as this entry is read_only. OBJECT DESCRIPTION INDEX Name Object Code Number of Elements Data Type VALUE DESCRIPTION Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value 0H number of entries Optional ro No Unsigned8 2 No 1H COB-ID Client->Server (rx) Optional Index 1200h: ro, Index 1201h-127Fh: rw No Unsigned32 (figure 10-4) No Index 1200h: 600h+Node-ID, Index 1201h-127Fh: No 1200H - 127FH Server SDO parameter RECORD 3H SDOPar

25

It must be ensured that the COB-IDs of the default SDO can not be manipulated by writing to the object dictionary. 10-32

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value

2H COB-ID Server -> Client (tx) Optional Index 1200h: ro Index 1201-127Fh: rw No Unsigned32 (figure 10-4) No Index 1200h: 580h+Node-ID, Index 1201h-127Fh: No 3H node ID of the SDO client Optional rw No Unsigned8 No No

Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value

Object 1280H - 12FFH: Client SDO Parameter These objects contain the parameters for the SDOs for which the device is the client. If the entry is supported, all sub-indices must be available. OBJECT DESCRIPTION INDEX Name Object Code Number of Elements Data Type VALUE DESCRIPTION Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value 0H number of entries Optional ro No Unsigned8 3 3 1280H - 12FFH Client SDO parameter RECORD 3H SDOPar

10-33

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value

1H COB-ID Client->Server (tx) Optional rw No Unsigned32 (figure 10-4) No No 2H COB-ID Server -> Client (rx) Optional rw No Unsigned32 (figure 10-4) No No 3H node ID of the SDO server Optional rw No Unsigned8 No No

10-34

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Object 1400H - 15FFH: Receive PDO Communication Parameter Contains the communication parameters for the PDOs the device is able to receive. OBJECT DESCRIPTION INDEX Name Object Code Number of Elements Data Type VALUE DESCRIPTION Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value 0H number of entries Optional ro No Unsigned8 2-4 1H COB-ID used by PDO Optional rw No Unsigned32 (Figure 10-6) No Index 1400h: 200h + Node-ID, Index 1401h: 300h + Node-ID, Index 1402h - 15FFh: No 2H transmission type Optional rw No Unsigned8 (Table 10-7) No (Device Profile dependent) 1400H - 15FFH receive PDO parameter RECORD 2 (Mandatory), 3-4 (Optional) PDOCommPar

Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value

10-35

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value

3H inhibit time Optional rw No Unsigned16 No No 4H CMS priority group Optional rw No Unsigned8 0-7 No

Object 1600H - 17FFH: Receive PDO Mapping Parameter Contains the mapping for the PDOs the device is able to receive. OBJECT DESCRIPTION INDEX Name Object Code Number of Elements Data Type VALUE DESCRIPTION Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value 0H number of mapped application objects in PDO Optional rw No Unsigned32 1 - 64 (Device Profile dependent) 1600H - 17FFH receive PDO mapping RECORD 1H-64H PDOMapping

10-36

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Sub-Index Description

1H - 40H PDO mapping for the nth application object to be mapped Optional rw No Unsigned32 No (Device Profile dependent)

Object Class Access PDO Mapping Value Range Mandatory Range Default Value

Object 1800H - 19FFH: Transmit PDO Communication Parameter Contains the communication parameters for the PDOs the device is able to transmit. OBJECT DESCRIPTION INDEX Name Object Code Number of Elements Data Type VALUE DESCRIPTION Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value 0H number of entries Optional ro No Unsigned8 2-4 1H COB-ID used by PDO Optional rw No Unsigned32 (Figure 10-6) No Index 1800h: 180h + Node-ID, Index 1801h: 280h + Node-ID, Index 1802h - 18FFh: No 1800H - 19FFH transmit PDO parameter RECORD 2 (Mandatory), 3-4 (Optional) PDOCommPar

10-37

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value Sub-Index Description Object Class Access PDO Mapping Value Range Mandatory Range Default Value

2H transmission type Optional rw No Unsigned8 (Table 10-7) No (Device Profile dependent) 3H inhibit time Optional rw No Unsigned16 No No 4H CMS priority group Optional rw No Unsigned8 0-7 No

10-38

Dictionary Structure and EntriesCANopen Communication Profile

CiA

Object 1A00H - 1BFFH: Transmit PDO Mapping Parameter Contains the mapping for the PDOs the device is able to transmit. OBJECT DESCRIPTION INDEX Name Object Code Number of Elements Data Type VALUE DESCRIPTION See Value Description of objects 1600H - 17FFH. 1A00H - 1BFFH transmit PDO mapping RECORD 1H-64H PDOMapping

10-39

Physical Layer

CANopen Communication Profile

CiA

11

Physical Layer
The physical medium for CANopen devices is a differentially driven two-wire bus line with common return according to ISO 11898 /2/.

11.1

Physical medium Specification


See /4/.

11.2

Transceiver
See /2/. The maximum rating for VCAN_H and VCAN_L is +16V. Galvanic isolation between bus nodes is optional.

11.3

Bit Rates, Bit Timing


Every module has to support a bit rate of 20 kbit/s. The recommended bit rates and corresponding bit timing recommendations are listed in table 11-1. Bit rate Bus length 1 Mbit/s 25 m 800 kbit/s 50 m 500 kbit/s 100 m 250 kbit/s 250 m (2) 125 kbit/s 500 m (2) 50 kbit/s 1000 m (3) 20 kbit/s 2500 m (3) 10 kbit/s 5000 m (3)
(1)

Nominal bit time tb 1 ms 1.25 ms 2 ms 4 ms 8 ms 20 ms 50 ms 100 ms

Number of Length of time quanta time per bit quantum tq 8 10 16 16 16 16 16 16 125 ns 125 ns 125 ns 250 ns 500 ns 1.25 ms 3.125 ms 6.25 ms

Location of sample point 6 tq


(750 ns)

8 tq
(1 ms)

14 tq
(1.75 ms)

14 tq
(3.5 ms)

14 tq
(7 ms)

14 tq
(17.5 ms)

14 tq
(43.75 ms)

14 tq
(87.5 ms)

Table 11-1: Recommended Bit Timing Settings Oscillator frequency Sampling mode Synchronisation mode Synchronisation jump width Phase Segment 2 16 MHz +/-0.1% (1000 ppm) Single sampling Recessive to dominant edges only 1 * tq 2 * tq SAM = 0 SYNC = 0 SJW = 0 TSEG2 = 1

11-1

Physical Layer

CANopen Communication Profile

CiA

Note 1: Rounded bus length estimation (worst case) on basis 5 ns/m propagation delay and a total effective ECU-internal (Elec. Control Unit) in-out delay as follows: 1M-800 kbit/s: 210ns 500 - 250 kbit/s: 300 ns (includes 2 * 40 ns for optocouplers) 124 kbit/s: 450 ns (includes 2 * 100 ns for optocouplers) 50 - 10 kbit/s: 1.5 tq; Effective delay = delay recessive to dominant plus dominant to recessive divided by two. Note 2: For bus length greater than about 200 m the use of optocouplers is recommended. If optocouplers are placed between CAN controller and transceiver this affects the maximum bus length depending upon the propagation delay of the optocouplers i.e. -4m per 10 ns propagation delay of employed optocoupler type. Note 3: For bus length greater than about 1 km bridge or repeater devices may be needed. A module shall support as many of the recommended bit rates as possible. It is not required, that a module has to support all recommended bit rates.

11.4

External Power Supply


The recommended output voltage at the optional external power supply is +18VDC < V+ < +30VDC in order to enable the use of standard industrial power supplies (24VDC).

11.5
11.5.1

Bus Connector
9-pin D-Sub Connector

male
CAN_GND CAN_L (CAN_SHLD)

female
5 9 4 3 8 2 7 6 1

2 6

3 7 8

4 9

(GND) CAN_V + CAN_H

It is recommended to use a 9-pin D-Sub connector (DIN 41652 or corresponding international standard) with the pinning according to CiA DS 102 /4/. For convenience the pinning is repeated here:

11-2

Physical Layer

CANopen Communication Profile

CiA

Pin 1 2 3 4 5 6 7 8 9

Signal CAN_L CAN_GND (CAN_SHLD) (GND) CAN_H (CAN_V+)

Description Reserved CAN_L bus line (dominant low) CAN Ground Reserved Optional CAN Shield Optional Ground CAN_H bus line (dominant high) Reserved Optional CAN external positive supply (dedicated for supply of transceiver and optocouplers, if galvanic isolation of the bus node applies)

If 9-pin D-Sub connector is supported, a male connector meeting the above specification has to be provided by the bus node. Within the modules, pin 3 and pin 6 have to be interconnected. Inside of such modules providing two bus connections, and inside the T-connectors, all the pins (including the reserved ones) have to be connected. The intention is, that there shall be no interruption of any of the wires i n the bus cable, assuming a future specification of the use of the reserved pins. By using the pin V+ for supplying transceivers in case of galvanic isolation, the necessity of an extra local power isolation (e.g. DC/DC-converter) is avoided. If an error line is needed within a system, then pin 8 shall be used for this purpose. 11.5.2 5-pin Mini Style Connector

male 4

3 2

f emale 3 2 4

If 5-pin Mini Style Connectors are used the following pinning applies:

Pin 1 2

Signal (CAN_SHLD) (CAN_V+)

Description Optional CAN Shield Optional CAN external positive supply (dedicated for supply of transceiver and optocouplers, if galvanic isolation of the bus node applies) Ground / 0V / VCAN_H bus line (dominant high) CAN_L bus line (dominant low)

3 4 5

CAN_GND CAN_H CAN_L

The bus node provides the male pins of the connector. 11.5.3 Open Style Connector

11-3

Physical Layer

CANopen Communication Profile

CiA

female

male 3 4

5 3 1 2

If Open Style Connectors are used the following pinning is recommended:

Pin 1 2 3 4 5

Signal CAN_GND CAN_L (CAN_SHLD) CAN_H (CAN_V+)

Description Ground / 0 V / VCAN_L bus line (dominant low) Optional CAN Shield CAN_H bus line (dominant high) Optional CAN external positive supply (dedicated for supply of transceiver and optocouplers, if galvanic isolation of the bus node applies)

4-pin Open Style Connectors either use pins 1-4 (Version A) or pins 2-5 (Version B). 3pin Open Style Connectors use pins 2-4. The bus node provides the male pins of the connector.

11.5.4

Multipole Connector
10 1 10 9 1

If (5 x 2) multipole connectors are used (e.g. inside EMI protected housings) the following pinning is recommended, as it supports direct connection of the flat cables to 9-pin D-sub connectors:

11-4

Physical Layer

CANopen Communication Profile

CiA

Pin 1 2 3 4 5 6 7 8 9 10

Signal reserved (GND) CAN_L CAN_H CAN_GND reserved reserved (CAN_V+) reserved reserved

Description Optional Ground CAN_L bus line (dominant low) CAN_H bus line (dominant high) CAN Ground

Optional CAN external positive supply

11.5.5

Other Connectors If different connectors are used, the pins have to be named (either in accompanying manual or directly on the device) using the following terminology: the

Signal description CAN_L bus line (dominant low) CAN_H bus line (dominant high) CAN Ground Optional CAN Shield Optional CAN external positive supply Optional Ground

notation CAN_L or CANlow or CANCAN_H or CANhigh or CAN+ CAN_GND or CANGND or Ground or GND CAN_SHLD or CANSHIELD or Shield or SHLD CAN_V+ or CANV+ or V+ or UC or UCAN OPT_GND or GNDopt or V- or 0V

11-5

APPENDIX

CANopen Communication Profile

CiA

12
12.1

APPENDIX
Example PDOMapping:
Consider a device which has the following object dictionary entries: Index 6060 6091 6092 60AE 60D0 Sub-Index 0 1 2 3 Object Name variable_1 variable_2 variable_3 variable_4 rec_elem_0 rec_elem_1 rec_elem_2 rec_elem_3 Data Type Unsigned16 Unsigned32 Unsigned32 Unsigned16 Unsigned8 Unsigned8 Unsigned8 Unsigned8

Table A.1: Example of Device Profile Description If we wish to configure the receive PDO defined on index 1600h to have the following structure: Byte 0 1 2 3 4 5 6 7

Not Used rec_elem_2 variable_4 variable_2

Figure A.1: Desired Input PDO Configuration Then we would have to write the following values to the corresponding PDOMapping structure at index 1600h in the object dictionary:

Sub-Index (hex) 0 1 2 3

Value (hex) 3 60 91 00 20

Comment Number of objects in input = 3 First object mapped is at index 6091.0 (32 bit length)

60 AE 00 10 Second object mapped is at index 60AE.0 (16 bit length) 60 D0 02 08 Third object mapped is at index 60D0.2 (8 bit length) Table A.2: Mapping of receive PDO

12-1

APPENDIX

CANopen Communication Profile

CiA

If we want this PDO to be reveived synchronously every communication cycle with the COB-ID 300 we have to write the following values in the communication parameter located at 1400H. Sub-Index (hex) 0 1 2 3 4 Value (hex) 4 12C 1 0 0 Comment number of supported entries COB-ID = 300 transmission type = 1 (cyclic, synchronous) no inhibit time no priority group (ID is distributed statically)

Table A.3: Communication parameters for receive PDO If we wish to configure the transmit PDO defined at index 1A00h to have the following structure: Byte 0 1 2 3 4 5 6 7

Not Used variable_3 variable_1 Figure A.2: Desired transmit PDO Configuration Then we would have to write the following values to the corresponding PDOMapping structure at index 1A00h in the object dictionary: Sub-Index (hex) 0 1 2 Value (hex) Comment 2 60 60 00 10 60 92 00 20 Number of objects in transmit PDO = 2 First object mapped is at index 6060.0 (16 bit length) Second object mapped is at index 6092.0 (32 bit length)

Table A.4: Mapping of transmit PDO If we want this PDO to be transmitted asynchronously on an device specific event specified in the device profile with the COB-ID 400 we have to write the following values in the communication parameter located at 1800H. Sub-Index (hex) 0 1 2 3 4 Value (hex) 4 190 FF 0 0 Comment number of supported entries COB-ID = 400 transmission type = 255 (asynchronous, profile specific) no inhibit time no priority group (ID is distributed statically)

Table A.5: Communication parameters for transmit PDO

12-2

APPENDIX

CANopen Communication Profile

CiA

12.2

Example for Emergency Message


A Temperature Error is signaled as follows (if detailed error source supported): Error Code: 40xx (xx = additional information, specified by the device profile) Bit Content Emergency Message: 7 0 6 0 5 0 4 0 3 1 2 0 1 0 0 = 09H 1

Error Register:

xx 40 09 yy yy yy yy yy

(yy = manufacturer specific)

12.3

Example for Naming Conventions


A device needs identifiers for two synchronous PDO (COMMAND and ACTUAL) and two asynchronous PDO's (device = server). The table lists the COB names used by the device in order to request the identifiers via DBT. The device's node-ID is 1. In xxx the device profile number used for this particular device is coded (e.g. 401 for I/O device profile).

COB name xxxSYNC000001X xxxSDO_001001C xxxSDO_001001S xxxRPDO001001X xxxTPDO001001X xxxRPDO002001X xxxTPDO002001X xxxEMCY000001X

Communication Parameter at Index 1005h (COB-ID only)

PDOMapping at Index 1600H (1st receive PDO) 1A00H (1st transmit PDO) 1601H (2nd receive PDO) 1A01H (2nd transmit PDO) -

1400h (1st receive PDO) 1800h (1st transmit PDO) 1401h (2nd receive PDO) 1801h (2nd transmit PDO) -

12.4
12.4.1

Example for Device Profile: Object 6C05H of Analogue I/O Device


Object 6C05H Writes the value to the output channel 'n' (unconverted). Value is 32 bits wide or less. OBJECT DESCRIPTION INDEX Name Object Code Number Of Elements Object Class PDO Mapping 6C05H Write_Analogue_Output_32 RECORD 0H(Mandatory) 1H-20H(Optional) Mandatory 0H(Mandatory) 1H-20H(Optional)

12-3

APPENDIX

CANopen Communication Profile

CiA

VALUE DESCRIPTION Sub-Index Description Data Type Length Object Class PDO Mapping Value Range Mandatory Range Sub-Index Description Data Type Length Object Class PDO Mapping Value Range Mandatory Range Sub-Index Description Data Type Length Object Class PDO Mapping Value Range Mandatory Range to Sub-Index Description Data Type Length Object Class PDO Mapping Value Range Mandatory Range 20H Output_20H Unsigned32 2 Optional Possible Unsigned32 NO 0H Number_Analogue_Outputs Unsigned8 1 Mandatory NO 0H -20H NO 1H Output_1H Unsigned32 2 Optional Possible Unsigned32 NO 2H Output_2H Unsigned32 2 Optional Possible Unsigned32 NO

12-4

APPENDIX

CANopen Communication Profile

CiA

12.5
12.5.1

Electronic Data Sheet Specification


Introduction In order to give the user of a CANopen device more support the devices description should be available in a standardised way. This gives the opportunity to create standardised tools for: configuration of CANopen devices, designing networks with CANopen devices, managing project information on different platforms. Therefore two types of files are introduced to define a CANopen device with electronically means. The files are ASCII-coded and it is recommended to use the ANSI character set.

12.5.1.1 Electronic Data Sheets (EDS) and Device Configuration Files (DCF) An EDS can be used to describe the: Communication functionality and objects as defined in the CANopen CAL-based Communication Profile DS-301, Device specific objects as defined in the device profiles DS-4XX. The EDS is the template for a device XY of the vendor UV. The DCF describes the incarnation of a device not only with the objects but also with the values of the objects. Furthermore a value for the baudrate of a device and for the module-id are added.

EDS

DCF

device

1000 kBit/s ID = 2

Electronic Data Sheet - serves as template for different configurations for one device type

250 kBit/s ID = 55

20 kBit/s ID = 110

\\ROBOSERV\TEXTE\CIA\PROFILE\CANOPEN\DS301\SUGGEST\EDSTRUC

12-5

APPENDIX

CANopen Communication Profile

CiA

12.5.2

Structure of an EDS (Electronic Data Sheet) An EDS should be supplied by the vendor of a particular device. If a vendor has no EDS available for his CANopen devices a default EDS can be used. The default EDS comprises all entries of a device profile for a particular device class. An EDS can be divided into three parts: informations regarding the EDS file (creation time, version etc.), general device information (name, serial number, hardware revision etc.), object dictionary with default values.

12.5.2.1 File Information Information regarding file description, creation date and time modification date and time version management can be found in the section FileInfo. The following keywords are used: FileName FileVersion FileRevision Description CreationTime CreationDate CreatedBy ModificationTime hh:mm(AM|PM)), ModificationDate yy), ModifiedBy Example: [FileInfo] FileName=vendor1.eds FileVersion=1 FileRevision=2 Description=EDS for simple I/O-device CreationTime=09:45AM CreationDate=05-15-95 CreatedBy=Zaphod Beeblebrox ModificationTime=11:30PM ModificationDate=08-21-95 ModifiedBy=Zaphod Beeblebrox file name (according to DOS restrictions), actual file version (Unsigned8), actual file revision (Unsigned8), file description (255 characters), file creation time (characters in format hh:mm(AM|PM)), date of file creation (characters in format mm-dd-yy), name or description of file creator (255 characters), time of last modification (characters in format

- date of last file modification (characters in format mm-dd- name or description of the modification (255 characters).

12-6

APPENDIX

CANopen Communication Profile

CiA

12.5.2.2 General Device Information The device specific information vendor name, vendor code, device name, device code, version information, LMT-information (parts of the LMT-address), device abilities. can be found in the section DeviceInfo. The following keywords are VendorName VendorNumber ProductName ProductNumber ProductVersion ProductRevision OrderCode LMT_ManufacturerName LMT_ProductName BaudRate_10 BaudRate_20 BaudRate_50 BaudRate_100 BaudRate_125 BaudRate_250 BaudRate_500 BaudRate_800 BaudRate_1000 SimpleBootUpMaster SimpleBootUpSlave ExtendedBootUpMaster ExtendedBootUpSlave Granularity - simple boot-up master functionality (Boolean, 0 = not supported, 1 = supported), - simple boot-up slave functionality (Boolean, 0 = not supported, 1 = supported), - extended boot-up master functionality (Boolean, 0 = not supported, 1 = supported), - simple boot-up slave functionality (Boolean, 0 = not supported, 1 = supported), - This value gives you the granularity allowed for the mapping on this device - most of the existing devices supports a granularity of 8 (Unsigned8; 0 - mapping not modifiable, 1-64 granularity) used: - vendor name (255 characters) - vendor code (Unsigned32) - product name (255 characters) - product number (Unsigned32) - product version (Unsigned8) - product revision (Unsigned8) - order code for this product (255 characters) - manufacturer name part of LMT-address (7 characters) - product name part of LMT-address (7 characters) - supported baud rates (Boolean, 0 = not supported, 1 = supported)

12-7

APPENDIX

CANopen Communication Profile

CiA

Example: [DeviceInfo] VendorName=Nepp Ltd. VendorNumber=156678 ProductName=E/A 64 ProductNumber=45570 ProductVersion=4 ProductRevision=1 OrderCode=BUY ME - 177/65/0815 LMT_ManufacturerName=NEPPLTD LMT_ProductName=E/AXY64 BaudRate_50=1 BaudRate_250=1 BaudRate_500=1 BaudRate_1000=1 SimpleBootUpSlave=1 ExtendedBootUpMaster=0 SimpleBootUpMaster=0 ExtendedBootUpSlave=0

12.5.2.3 Object Dictionary In 1. 2. 3. this section of the EDS the following information can be found: which object of the object dictionary is supported, limit values for parameters, default values.

The description of the objects take place in four separate sections corresponding to: data types, mandatory objects, optional objects, manufacturer specific objects. 12.5.2.3.1 Data type section The section StandardDataTypes lists all standard data types available on the device. Data types are listed according to their index (table 11.1-1 in DS301). Additional the complex standard data types PDO Communication Parameter Record and PDO Mapping Record are known. The entries follow this scheme: <data type index>={0|1}

12-8

APPENDIX

CANopen Communication Profile

CiA

Example: [StandardDataTypes] 0x0001=1 0x0002=1 0x0003=1 0x0004=1 0x0005=1 0x0006=1 0x0007=1 0x0008=0 0x0009=1 0x000A=0 0x000B=0 0x000C=0 0x000D=0 0x000E=0 0x000F=0 0x0020=1 0x0021=1 0x0022=0

12.5.2.3.2 Mapping of dummy entries Sometimes it is required to leave holes in the mapping of a device. This means that e.g. a device only evaluates the last two data bytes of a PDO of 8 bytes length. The first six bytes should be ignored (perhaps they are evaluated by another device). In this case the mapping of this device must be created by using dummy entries for these first six bytes. The indices from the data type area of the object dictionary are used for this purpose. The user of a device has to know what data type can be used for creating dummy entries and what not (indeed only the length of the dummy object is important). The section DummyUsage is used scheme: for describing dummies. The entries follow this

Dummy<data type index (without 0x-prefix)>={0|1} Example: [DummyUsage] Dummy0001=0 Dummy0002=1 Dummy0002=1 Dummy0003=1 Dummy0004=1 Dummy0005=1 Dummy0006=1 Dummy0007=1

This means that the device will tolerate the mapping of the data types Integer8/16/32 and Unsigned8/16/32.

12-9

APPENDIX

CANopen Communication Profile

CiA

12.5.2.3.3 Object sections The section MandatoryObjects describes the mandatory objects of the object dictionary. There exists only the two entries DeviceType and ErrorRegister. In the section MandatoryObjects the following entries are possible: SupportedObjects - number of entries in the section (Unsigned16) The entries are numbered beginning with number 1. This way the last entry gives the number of available entries. In these sections the entries have the same values for all devices because there are no optional entries. 1=0x1000 2=0x1001 The entries of the particular objects of the object dictionary are all constructed following the same scheme. The section name is constructed according to the following: [<Index>(sub<Sub-Index>)] using the hexadecimal values for Index and Sub-index without the leading 0x. In a section the following SubNumber ParameterName ObjectType DataType LowLimit HighLimit AccessType keywords may exist: number of sub-indices available at this index (Unsigned8) parameter name (255 characters) This is the object code (DS301 table 11-2). This is the index of the data type of the object in the object dictionary (DS301 table 11.1-1). Lowest limit of object value (only if applicable). Upper limit of object value (only if applicable). Access type for this object (String ro - read only, wo - write only, rw - read/write, rwr - read/write on process input, rww - read/write on process output, const - constant value, ) default value for this object, - default value for this object (Boolean, 0 = not mappable, 1 = mappable).

DefaultValue PDOMapping

It is not necessary to use all keywords in every section. case 1: An object can be accessed directly by an index. There are no sub-indices for this object

Used keywords: [1000] SubNumber=0 ParameterName=Device Type ObjectType=0x7 DataType=0x0007 AccessType=ro DefaultValue= PDOMapping=0 Case 2: Parts of an object can be accessed via sub-indices. The entry in the EDS can be realised like the following:

12-10

APPENDIX

CANopen Communication Profile

CiA

[1003] SubNumber=2 ParameterName=Pre-defined Error Field The sub-index entries are defined in this manner: [1003sub0] ParameterName=Number of Errors ObjectType=0x7 DataType=0x0005 AccessType=ro DefaultValue=0x1 PDOMapping=0 [1003sub1] ParameterName=Standard Error Field ObjectType=0x7 DataType=0x0007 AccessType=ro DefaultValue=0x0 PDOMapping=0

Example - mandatory section: ;----------------------------------[MandatoryObjects] SupportedObjects=0x02 1=0x1000 2=0x1001 [1000] SubNumber=0 ParameterName=Device Type ObjectType=0x7 DataType=0x0007 AccessType=ro DefaultValue= PDOMapping=0 [1001] SubNumber=0 ParameterName=Error Register ObjectType=0x7 DataType=0x0005 AccessType=ro DefaultValue=0x0 PDOMapping=1

12-11

APPENDIX

CANopen Communication Profile

CiA

The section OptionalObjects describes the optional objects supported by the device. ;----------------------------------[OptionalObjects] SupportedObjects=0x7 1=0x1003 2=0x1004 3=0x1005 4=0x1008 5=0x1009 6=0x100A 7=0x100B [1003] SubNumber=2 ParameterName=Pre-defined Error Field [1003sub0] ParameterName=Number of Errors ObjectType=0x7 DataType=0x0005 AccessType=ro DefaultValue= PDOMapping=0 [1003sub1] ParameterName=Standard Error Field ObjectType=0x7 DataType=0x0007 AccessType=ro DefaultValue= PDOMapping=0 ; value for object 1006 (communication cycle period) ; no sub-index available [1006] ParameterName=Communication Cycle Period ObjectType=0x7 DataType=0x0007 LowLimit=1000 HighLimit=100000 AccessType=rw DefaultValue=20000 PDOMapping=0 :

12-12

APPENDIX

CANopen Communication Profile

CiA

The section ManufacturerObjects describes the manufacturer specific entries in the object dictionary. ;----------------------------------[ManufacturerObjects] SupportedObjects=0

12.5.2.3.4 Object Links In order to ease the implementation of a configuration tool it is possible to group related objects together via the keyword ObjectLinks. An object link has the following structure: [<index>ObjectLinks] ObjectLinks=<number of 1=<index of 1st linked 2=<index of 2nd linked 3=<index of 3rd linked 4=<index of 4th linked 5=<index of 5th linked : Example: ; assuming we describe closed loop ; this is the object factor [5800ObjectLinks] ObjectLinks=0x3 ; gain 1=0x5801 ; zero 2=0x5802 ; pole 3=0x5803

available links> object> object> object> object> object>

12-13

APPENDIX

CANopen Communication Profile

CiA

12.5.2.4 Comments Comments can be added to the EDS by using the Comments section. This section has only entries determining the line number and the line contents. Lines - number of commentlines (Unsigned16) Line<line number> - one line of comment (character 255) Example: [Comments] Lines=3 Line1=|-------------| Line2=| Dont panic | Line3=|-------------|

12.5.3

Structure of a DCF (Device Configuration File) The device configuration file comprises all objects for a configured device. The device configuration file has the same structure as the EDS for this device. There are some additional entries in order to describe e configured device.

12.5.3.1 Additional Entries 12.5.3.1.1 File Information Section LastEDS - file name of the EDS file used as template for this DCF

12.5.3.1.2 Object Sections ParameterValue - object value (as defined by ObjectType and DataType) Example: ; value for object 1006 (communication cycle period) [1006] SubNumber=0 ParameterName=Communication Cycle Period ObjectType=0x7 DataType=0x0007 LowLimit=1000 HighLimit=100000 DefaultValue=20000 AccessType=ro ParameterValue=15000 PDOMapping=0 If the ObjectType is Domain (0x2) the value of the object can be stored in a file. UploadFile: DownloadFile: if a read access is performed for this object, the data are stored in this file (character 255) if a write access is performed for this object, the data to be written can be taken from this file (character 255)

12-14

APPENDIX

CANopen Communication Profile

CiA

Example: ; manufacturer specific object 5600 (downloadable program) [5600] SubNumber=0 ParameterName=Real Good Program (RGP) ObjectType=0x2 DataType=0x000F AccessType=wo DownloadFile=C:\FAST\PROGRAMS\FIRST.HEX ; manufacturer specific object 5700 (core dump) [5700] SubNumber=0 ParameterName=Core Dump (CD) ObjectType=0x2 DataType=0x000F AccessType=ro UploadFile=C:\FAST\DEBUG\DUMPALL.HEX

12.5.3.1.3 Device Commissioning There is an additional section in the DCF named DeviceComissioning: NodeID - devices address (Unsigned8) NodeName - node name part of NMT-address (7 characters) Baudrate - devices baudrate (Unsigned16) NetNumber - number of the network (Unsigned32) NetworkName - name of the network (character 255) LMT_SerialNumber - serial number part of LMT-address (14 characters [0-9]) Example: [DeviceComissioning] NodeID=2 NodeName=DEVICE2 Baudrate=1000 NetNumber=42 NetworkName=very important subnet in a big network LMT_SerialNumber=33678909231354

12-15

CAN in Automation e. V.

CANopen
Communication Profile for Industrial Systems Based on CAL

CiA Draft Standard 301

Revision 3.0 Date: 30.10.96

Table of Contents

CANopen Communication Profile Members Only Edition

CiA

History
Date
Oct 96

Changes
Document completely revised; Summary of major changes: Object Dictionary structure extended (downwards compatible) Mapping of Emergency Telegram clarified Boot-Up procedure clarified Minimum capability device enhanced Default Identifiers for Node guarding added Transmission types enhanced PDO Mapping clarified Communication Parameters of supported PDOs made mandatory SDO parameters included in Object Dictionary Storing/Restoring of parameters clarified / Objects added Object Dictionary structure accessible Chapter Physical Layer included Electronic Data Sheet specification included

Table of Contents

CANopen Communication Profile Members Only Edition

CiA

Table of Contents
1 SCOPE..................................................................................................................1-1 2 REFERENCES.......................................................................................................2-1 3 DEFINITIONS........................................................................................................3-1 4 INTRODUCTION...................................................................................................4-1
4.1 CANopen Communication Reference Model ...................................................4-1 4.2 Standardisation Via Profiling............................................................................4-2 4.3 The Object Dictionary ......................................................................................4-3 4.3.1 Index and Sub-Index Usage ......................................................................4-4

5 COMMUNICATION MODEL................................................................................5-1
5.1 The Service Data Object..................................................................................5-2 5.1.1 SDO usage................................................................................................5-2 5.1.2 Services....................................................................................................5-2 5.1.3 Protocols...................................................................................................5-3 5.2 The Process Data Object..................................................................................5-5 5.2.1 PDO Usage ...............................................................................................5-5 5.2.1.1 Transmission Modes..........................................................................5-5 5.2.1.2 Triggering Modes..............................................................................5-6 5.2.2 PDO Services............................................................................................5-7 5.2.3 PDO Protocol............................................................................................5-7

6 SYNCHRONISATION BY THE SYNC MASTER................................................6-1


6.1 Transmission of Synchronous PDO Messages ...................................................6-1 6.2 Optional High Resolution Synchronisation Protocol.........................................6-2 6.3 Other Synchronisation......................................................................................6-2

7 PRE-DEFINED COMMUNICATION OBJECTS..................................................7-1


7.1 The SYNC Object.............................................................................................7-1 7.1.1 SYNC Usage .............................................................................................7-1 7.1.2 SYNC Services..........................................................................................7-1 7.1.3 SYNC Object Protocols.............................................................................7-2 7.2 The Time Stamp Object ..................................................................................7-2 7.2.1 Time Stamp Object Usage .......................................................................7-2 7.2.2 Time Stamp Object Services....................................................................7-2 7.2.3 Time Stamp Object Protocols ..................................................................7-2 7.3 The Emergency Object....................................................................................7-3 7.3.1 Emergency Object Usage.........................................................................7-3 7.3.2 Emergency Object Mapping.....................................................................7-4 7.3.3 Emergency Object Services .....................................................................7-5 ii

Table of Contents

CANopen Communication Profile Members Only Edition

CiA

7.3.4 Protocols...................................................................................................7-5

8 NETWORK MANAGEMENT AND IDENTIFIER DISTRIBUTION......................8-1


8.1 Services and Protocols.....................................................................................8-1 8.1.1 Enter_Pre-Operational_State Service and Protocol .................................8-6 8.1.2 Reset_Node Service and Protocol ............................................................8-7 8.1.3 Reset_Communication Service and Protocol ...........................................8-7 8.2 Network Initialisation Process (Bootup-Process) ................................................8-8 8.3 Minimum Capability Device .............................................................................8-9 8.4 Allocation of COB-ID's and Inhibit-Times .......................................................8-11 8.4.1 Predefined Connection Set ....................................................................8-11 8.4.2 Dynamic Distribution...............................................................................8-12 8.4.3 Naming Conventions...............................................................................8-14

9 ERROR HANDLING..............................................................................................9-1
9.1 Node Guarding / Life Guarding ........................................................................9-2 9.2 Emergency Telegram.......................................................................................9-2

10 DICTIONARY STRUCTURE AND ENTRIES................................................. 10-1


10.1 Dictionary Components ................................................................................10-2 10.1.1 Data Types............................................................................................10-3 10.1.2 PDO Communication Parameter ..........................................................10-5 10.1.3 PDO Mapping.......................................................................................10-7 10.1.4 SDO Parameter.....................................................................................10-8 10.2 Detailed Object Specification....................................................................10-12 10.3 Detailed Specification of Communication Profile specific Objects ...........10-13

11 PHYSICAL LAYER.......................................................................................... 11-1


11.1 Physical medium Specification ...................................................................11-1 11.2 Transceiver...................................................................................................11-1 11.3 Bit Rates, Bit Timing ....................................................................................11-1 11.4 External Power Supply .................................................................................11-2 11.5 Bus Connector..............................................................................................11-2 11.5.1 9-pin D-Sub Connector .........................................................................11-2 11.5.2 5-pin Mini Style Connector...................................................................11-3 11.5.3 Open Style Connector ..........................................................................11-3 11.5.4 Multipole Connector.............................................................................11-4 11.5.5 Other Connectors..................................................................................11-5

12 APPENDIX....................................................................................................... 12-1
12.1 Example PDOMapping:................................................................................12-1 12.2 Example for Emergency Message ................................................................12-3 12.3 Example for Naming Conventions ................................................................12-3

iii

Table of Contents

CANopen Communication Profile Members Only Edition

CiA

12.4 Example for Device Profile: Object 6C05H of Analogue I/O Device ............12-3 12.4.1 Object 6C05H.......................................................................................12-3 12.5 Electronic Data Sheet Specification............................................................12-5 12.5.1 Introduction ..........................................................................................12-5 12.5.1.1 Electronic Data Sheets (EDS) and Device Configuration Files (DCF)12-5 12.5.2 Structure of an EDS (Electronic Data Sheet)........................................12-6 12.5.2.1 File Information ............................................................................12-6 12.5.2.2 General Device Information..........................................................12-7 12.5.2.3 Object Dictionary..........................................................................12-8 12.5.2.3.1 Data type section ..................................................................12-8 12.5.2.3.2 Mapping of dummy entries....................................................12-9 12.5.2.3.3 Object sections ...................................................................12-10 12.5.2.3.4 Object Links ........................................................................12-13 12.5.2.4 Comments...................................................................................12-14 12.5.3 Structure of a DCF (Device Configuration File) ...................................12-14 12.5.3.1 Additional Entries .......................................................................12-14 12.5.3.1.1 File Information Section .....................................................12-14 12.5.3.1.2 Object Sections ..................................................................12-14 12.5.3.1.3 Device Commissioning........................................................12-15

iv

Scope

CANopen Communication Profile Members Only Edition

CiA

Scope
Devices which have to communicate can be found in nearly every automated system. Unfortunately there is no standardised product definition with respect to the control techniques of functional elements. Therefore, each system integrator of automated systems creates his own standards. The resulting control and information flow concepts differ between each integrator and in most cases the employed control devices are not even compatible. This document contains the description of the CANopen Communication Profile for industrial applications using CAN as their installation bus. It is based on the CAN Application Layer (CAL) (see /4, .., 16/) specification from the CAN in Automation international users and manufacturers group (CiA e.V.). The CANopen Communication Profile forms the interface between the CAN Application Layer and the CANopen Device Profiles. It includes the real-time communication model and the protocols which are common to all devices in the network. Device Profiles, on the other hand, are a common means to describe device specific functionality. An introduction to CANopen Device Profiles is given in this document as well, however, the specification of full device profiles does not fall within the scope of this document.

1-1

References

CANopen Communication Profile

CiA

References
/1/: ISO 7498, 1984, Information Processing Interconnection - Basic Reference Model Systems Open Systems

/2/:

ISO 11898, 1993, Road Vehicles, Interchange of Digital Controller Area Network (CAN) for high-speed Communication

Information -

/3/: /4/: /5/: /6/: /7/: /8/: /9/: /10/: /11/: /12/: /13/: /14/: /15/:

Robert Bosch GmbH, CAN Specification 2.0 Part A+B, September 1991 CiA DS-102, CAN Physical Layer for Industrial Applications, April 1994 CiA DS-201, CAN Reference Model, February 1996 CiA DS-202/1, CMS Service Specification, February 1996 CiA DS-202/2, CMS Protocol Specification, February 1996 CiA DS-202/3, CMS Data Types and Encoding Rules, February 1996 CiA DS-203/1, NMT Service Specification, February 1996 CiA DS-203/2, NMT Protocol Specification, February 1996 CiA DS-204/1, DBT Service Specification, February 1996 CiA DS-204/2, DBT Protocol Specification, February 1996 CiA DS-207, Application Layer Naming Specification, February 1996 CiA DS-205/1, LMT Service Specification, February 1996 CiA DS-205/2, LMT Protocol Specification, February 1996

2-1

You might also like