eBook - CANOpen

CAN in Automation e. V.

CANopenApplication Layer and Communication Profile

CiA Draft Standard 301

Version 4.0

Date: 16.6.1999

History CANopen CiA

ii

History

Date Changes

June 1999 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-207specified) 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

CONTENTS CANopen CiA

iii

CONTENTS

CONTENTS ................................................................................................................................... III

1 TABLES ............................................................................................................................1-1

2 FIGURES ..........................................................................................................................2-1

3 SCOPE..............................................................................................................................3-1

4 REFERENCES..................................................................................................................4-1

4.1 Normative references ..................................................................................................4-1

4.2 Informative references.................................................................................................4-1

5 DEFINITIONS AND ABBREVIATIONS ......................................................................5-1

5.1 Abbreviations ...............................................................................................................5-1

6 MODELING.......................................................................................................................6-1

6.1 Reference Model .........................................................................................................6-1

6.2 Device Model ..............................................................................................................6-2

6.2.1 General ..............................................................................................................6-2

6.2.2 The Object Dictionary .......................................................................................6-3

6.3 Communication Model................................................................................................6-4

6.3.1 Master/Slave relationship .................................................................................6-5

6.3.2 Client/Server relationship..................................................................................6-6

6.3.3 Producer/Consumer relationship - Pull/Push model .......................................6-6

7 PHYSICAL LAYER ........................................................................................................7-1

7.1 Transceiver ..................................................................................................................7-1

7.2 Bit rates and timing......................................................................................................7-1

8 DATA LINK LAYER .....................................................................................................8-1

8.1 CAN Frame Type.........................................................................................................8-1

9 APPLICATION LAYER..................................................................................................9-1

9.1 Data Types and Encoding Rules ................................................................................9-1

9.1.1 General Description of Data Types and Encoding Rules................................9-1

9.1.2 Data Type Definitions........................................................................................9-1

CONTENTS CANopen CiA

iv

9.1.3 Bit Sequences ...................................................................................................9-2

9.1.4 Basic Data Types..............................................................................................9-3

9.1.5 Compound Data Types.....................................................................................9-6

9.1.6 Extended Data Types .......................................................................................9-6

9.2 Communication Objects ..............................................................................................9-7

9.2.1 Process Data Object (PDO) .............................................................................9-7

9.2.2 Service Data Object (SDO) ............................................................................9-11

9.2.3 Synchronisation Object (SYNC).....................................................................9-36

9.2.4 Time Stamp Object (TIME).............................................................................9-37

9.2.5 Emergency Object (EMCY) ............................................................................9-38

9.2.6 Network Management Objects .......................................................................9-41

9.3 Synchronisation of the SYNC Consumer .................................................................9-49

9.3.1 Transmission of Synchronous PDO Messages.............................................9-49

9.3.2 Optional High Resolution Synchronisation Protocol......................................9-50

9.4 Network Initialisation and System Boot-Up ..............................................................9-52

9.4.1 Initialisation Procedure ...................................................................................9-52

9.4.2 NMT State Machine ........................................................................................9-52

9.4.3 Pre-Defined Connection Set...........................................................................9-55

9.5 Object Dictionary .......................................................................................................9-56

9.5.1 General Structure of the Object Dictionary ....................................................9-56

9.5.2 Dictionary Components ..................................................................................9-58

9.5.3 Data Type Entry Specification ........................................................................9-58

9.5.4 Specification of Predefined Complex Data Types .........................................9-60

9.6 Communication Profile Specification........................................................................9-61

9.6.1 Detailed Object Specification..........................................................................9-61

9.6.2 Overview Object Dictionary Entries for Communication ...............................9-62

9.6.3 Detailed Specification of Communication Profile specific Objects................9-64

10 IMPLEMENTATION RECOMMENDATIONS .............................................................10-1

11 INDEX..............................................................................................................................11-1

TABLES CANopen CiA

1-1

1 TABLESTable 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

TABLES CANopen CiA

1-2

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

FIGURES CANopen CiA

2-1

2 FIGURESFigure 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

FIGURES CANopen CiA

2-2

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

SCOPE CANopen CiA

3-1

3 SCOPEThis 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.

REFERENCES CANopen CiA

4-1

4 REFERENCES

4.1 Normative references

prEN 50325-1: 199X ISO 11898 (CAN)-based Controller-device interfacesPart 1: General requirements

ISO 7498-1: 1994 Information technology - Open Systems Interconnection - Basic ReferenceModel: The Basic Model

ISO 8859: 1998 Information technology - 8-bit single-byte coded graphic character sets

ISO 11898: 1993 Road vehicles - Interchange of digital information - Controller area network(CAN) for high-speed communication

ISO 646: 1991 Information technology - ISO 7-bit coded character set for informationinterchange

4.2 Informative references

IEEE 754: 1985 Standard for binary floating-point arithmetic

DEFINITIONS AND ABBREVIATIONS CANopen CiA

5-1

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 CANNetwork inside a COB. There are 2048 different COB's in a CAN network. A COB can contain at most8 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 thatgives 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 Modelthat 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 ReferenceModel 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 ReferenceModel. 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 Modelthat specifies the bit representation, timing and synchronisation.

PMA:Physical Medium Attachment. One of the sub-layers of the Physical Layer in the CAN ReferenceModel that specifies the functional circuitry for bus line transmission/reception and may provide meansfor failure detection.

RPDO:Receive PDO.

DEFINITIONS AND ABBREVIATIONS CANopen CiA

5-2

SDO:Service Data Object.

SSDO:Server SDO.

SYNC:Synchronisation Object.

TPDO:Transmit PDO.

MODELING CANopen CiA

6-1

6 MODELINGCAN-based networks use the following reference model, device model, and communication model.

6.1 Reference Model

Figure 1: Reference Model

The communication concept can be described similar to the ISO-OSI Reference Model (left side offigure).Application Layer:

The Application Layer comprises a concept to configure and communicate real-time-data as well asthe mechanisms for synchronization between devices. The functionality the application layer offers toan application is logically divided over different service objects in the application layer. A service objectoffers a specific functionality and all the related services. These services are described in the ServiceSpecification of that service object.Applications interact by invoking services of a service object in the application layer. To realize theseservices, this object exchanges data via the CAN Network with (a) peer service object(s) via aprotocol. 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 arefour 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 eventdetected by the application layer or indicate that a service is requested

Application(1)

Application

Presentation

Session

Transport

Network

Datalink

Physical

(2)

(2)

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

LLC

MAC

PLS

PMA

MDI

Application Process


6-2

· a response is issued by the application to the application layer to respond to a previous receivedindication

· a confirmation is issued by the application layer to the application to report the result of apreviously issued request.

Application Layer Service Types

Application X

request

Local Service

Application X

indication

Provider InitiatedService

Application Xindication

Unconfirmed Service

Application Y, Z, ..

indication

indication

Application Xindication

Confirmed Service

Application Y

responseconfirmation

request

Figure 2: Service Types

A service type defines the primitives that are exchanged between the application layer and the co-operating 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 serviceobject(s).

· An unconfirmed service involves one or more peer service objects. The application issues arequest to its local service object. This request is transferred to the peer service object(s) thateach 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 toits local service object. This request is transferred to the peer service object that passes it to theother application as an indication. The other application issues a response that is transferred tothe 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 theservice provider) detects an event not solicited by a requested service. This event is thenindicated to the application.

Unconfirmed and confirmed services are collectively called remote services.

6.2 Device Model

6.2.1 General

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 statemachine used on this device.

· Application Ð The application comprises the functionality of the device with respect to theinteraction with the process environment.


6-3

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

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 Dictionaryis essentially a grouping of objects accessible via the network in an ordered pre-defined fashion. Eachobject 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 withother industrial serial bus system concepts:

Table 1: Object Dictionary Structure

Index (hex) Object

0000 not used

0001-001F Static Data Types

0020-003F Complex Data Types

0040-005F Manufacturer Specific Complex Data Types

0060-007F Device Profile Specific Static Data Types

0080-009F Device Profile Specific Complex Data Types

00A0-0FFF Reserved for further use

1000-1FFF Communication Profile Area

2000-5FFF Manufacturer Specific Profile Area

6000-9FFF Standardised Device Profile Area

A000-FFFF Reserved for further use

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

ApplicationObjectDictionaryCommunication

State machine

Comm.object

Comm.object

Comm.object

Comm.object

Applicationobject

Entry 1

Entry 2

Entry n

:

Applicationobject

Applicationobject

Applicationobject

ProcessBus system


6-4

The Static Data Types at indices 0001h through 001Fh contain type definitions for standard data typeslike 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 ofstandard data types and are common to all devices.Manufacturer Specific Complex Data Types at indices 0040h through 005Fh are structures composedof 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 typesdefined 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 thenumber of entries at this index, and the following sub-indices contain the data type encoded asUNSIGNED16 according to Table 38.The Communication Profile Area at indices 1000h through 1FFFh contains the communication specificparameters for the CAN network. These entries are common to all devices.The standardised device profile area at indices 6000h through 9FFFh contains all data objectscommon to a class of devices that can be read or written via the network. The device profiles may useentries from 6000h to 9FFFh to describe the device parameters and the device functionality. Withinthis range up to 8 different devices can be described. In such a case the devices are denominatedMultiple 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 profileentries 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 device 1





9000h to 97FFh device 69800h 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 of8 segments is supported.The Object Dictionary concept caters for optional device features which means a manufacturer doesnot have to provide certain extended functionality on his devices but if he wishes to do so he must doit in a pre-defined fashion.Space is left in the Object Dictionary at indices 2000h through 5FFFh for truly manufacturer-specificfunctionality.

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 variablethe index references the value of this variable directly. In case of records and arrays however, theindex addresses the whole data structure.To allow individual elements of structures of data to be accessed via the network a sub-index isdefined. 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 orrecords with multiple data fields the sub-index references fields within a data-structure pointed to bythe 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 theavailable 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 andactuation is possible. The synchronous transmission of messages is supported by pre-definedcommunication objects (Sync message, time stamp message). Synchronous messages aretransmitted with respect to a pre-defined synchronization message, asynchronous message may betransmitted at any time.


6-5

Due to the event character of the underlying communication mechanism it is possible to define inhibittimes for the communication. To guarantee that no starvation on the network occurs for data objectswith low priorities, data objects can be assigned an inhibit time. The inhibit-time of a data objectdefines the minimum time that has to elapse between two consecutive invocations of a transmissionservice 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 theaddressed slave(s) respond(s) if the protocol requires this behavior.

Figure 4: Unconfirmed Master Slave Communication

Figure 5: Confirmed Master Slave Communication

data

Master Slaves

request indication

indication

indication

data

Master Slave

confirmation response

Remote Transmit Request

indicationrequest


6-6

6.3.2 Client/Server relationship

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 theserver answers the request.

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). Thepush model is characterized by an unconfirmed service requested by the producer. The pull model ischaracterized by a confirmed service requested by the consumer.

Figure 7: Push model

Figure 8: Pull model

data

Producer Consumers

request indication

indication

indication

data

Client Server

confirmation response

indicationrequest

data

data

Producer Consumers

response confirmation


requestindication

indication

request

indication

request

PHYSICAL LAYER CANopen CiA

7-1

7 PHYSICAL LAYERThe physical medium for devices is a differentially driven two-wire bus line with common returnaccording 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 atransceiver that is capable of sustaining mis-connection of any of the wires of the connector includingthe optional V+ voltages of up to 30V.

7.2 Bit rates and timing

The recommended bit rates and corresponding bit timing recommendations(4) are listed in Table 2.One of these bit rates has to be supported.

Table 2: Recommended Bit Timing Settings

Bit rate

Bus length (1)

Nominalbit time

tb

Number oftime quanta

per bit

Length oftime

quantum tq

Location ofsamplepoint

1 Mbit/s25 m

1 ms 8 125 ns 6 tq(750 ns)

800 kbit/s50 m

1,25 ms 10 125 ns 8 tq(1 ms)

500 kbit/s100 m

2 ms 16 125 ns 14 tq(1,75 ms)

250 kbit/s250 m (2)

4 ms 16 250 ns 14 tq(3,5 ms)

125 kbit/s500 m (2)

8 ms 16 500 ns 14 tq(7 ms)

50 kbit/s1000 m (3)

20 ms 16 1,25 ms 14 tq(17,5 ms)

20 kbit/s2500 m (3)

50 ms 16 3,125 ms 14 tq(43,75 ms)

10 kbit/s5000 m (3)

100 ms 16 6,25 ms 14 tq(87,5 ms)

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

Note 1: Rounded bus length estimation (worst case) on basis 5 ns/m propagation delayand 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 plusdominant to recessive divided by two.

Note 2: For bus length greater than about 200 m the use of optocouplers isrecommended. If optocouplers are placed between CAN controller andtransceiver this affects the maximum bus length depending upon the propagationdelay of the optocouplers i.e. -4m per 10 ns propagation delay of employedoptocoupler type.

Note 3: For bus length greater than about 1 km bridge or repeater devices may beneeded.

PHYSICAL LAYER CANopen CiA

7-2

Note 4 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 therecommended sample point.

DATA LINK LAYER CANopen CiA

8-1

8 DATA LINK LAYERThe 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 tosupport the CAN Extended Frame with 29-bit Identifier Field.However, as certain applications may require the usage of the extended frame with 29-bit IdentifierField the network can be operated in this mode as well if it is supported by all nodes.

APPLICATION LAYER CANopen CiA

9-1

9 APPLICATION LAYER

9.1 Data Types and Encoding Rules

9.1.1 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 itsmeaning have to be known by the producer and consumer(s). This specification models this by theconcept of data types.The encoding rules define the representation of values of data types and the CAN network transfersyntax for the representations. Values are represented as bit sequences. Bit sequences aretransferred in sequences of octets (bytes). For numerical data types the encoding is little endian styleas shown in Figure 9.Applications often require data types beyond the basic data types. Using the compound data typemechanism the list of available data types can be extended. Some general extended data types aredefined as ÒVisible StringÓ or ÒTime of DayÓ for example (see 9.1.6.2 and 9.1.6.4). The compound datatypes are a means to implement user defined ÒDEFTYPESÓ in the terminology of this specification andnot Ò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 areassigned to data types in their type definitions. The syntax of data and data type definitions is asfollows (see EN 61131-3).

data_definition ::= type_name data_name

type_definition ::= constructor type_name

constructor ::= compound_constructor |

basic_constructor

compound_constructor ::= array_constructor |

structure_constructor

array_constructor ::= ÔARRAYÕ Ô[Ô length Ô]Õ ÔOFÕ type_name

structure_constructor ::= ÔSTRUCTÕ ÔOFÕ component_list

component_list ::= component { Ô,Õ component }

component ::= type_name component_name

basic_constructor ::= ÔBOOLEANÕ |ÔVOIDÕ bit_size |ÔINTEGERÕ bit_size |ÔUNSIGNEDÕ bit_size |ÔREAL32Õ |ÔREAL64Õ |ÔNILÕ

bit_size ::= Ô1Õ | Ô2Õ | <...> | Ô64Õ

length ::= positive_integer

data_name ::= symbolic_name

type_name ::= symbolic_name

component_name ::= symbolic_name

symbolic_name ::= letter { [ Ô_Õ ] ( letter | digit ) }

positive_integer ::= ( Ô1Õ | Ô2Õ | <...> | Ô9Õ ) { digit }

letter ::= ÔAÕ | ÔBÕ | <...> | ÔZÕ | ÔaÕ | ÔbÕ | <...> | ÔzÕ

digit ::= Ô0Õ | Ô1Õ | <...> | Ô9Õ


9-2

Recursive definitions are not allowed.The data type defined by type_definition is called basic (res.~compound) when the constructor isbasic_constructor (res. compound_constructor).

9.1.3 Bit Sequences

9.1.3.1 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 sequenceb 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-1is 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-1the bit sequence

Øb = Øb0 Øb1 ... Øbn-1Here Ø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, denotedab, is

ab = a0 ... am-1 b0 ... bn-1Example: (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. Hereand in the following hexadecimal notation is used for octets. Let b = b0...bn-1 be a bit sequence withn<64. Denote k a non-negative integer such that 8(k - 1) < n < 8k. Then b is transferred in k octetsassembled 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 asfollows across the CAN network:

b7, b6, ..., b0, b15, ..., b8, ...


9-3

octet number 1. 2. k.

b7 .. b0 b15 .. b8 b8k Ð1 .. b8k -8

Figure 9: Transfer Syntax for Bit Sequences

Example:

Bit 9 ... Bit 0

10 0001 1100

2h 1h Ch

= 21Ch

The bit sequence b = b0 .. b9 = 0011 1000 01 represents an UNSIGNED10 with the value21Ch and is transferred in two octets:First 1Ch and then 02h.

9.1.4 Basic Data Types

For basic data types Òtype_nameÓ equals the literal string of the associated constructor (akasymbolic_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 asbit 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 oftype VOIDn is undefined. The bits in the sequence of data of type VOIDn must either be specifiedexplicitly or else marked "do not care".Data of type VOIDn is useful for reserved fields and for aligning components of compound values onoctet 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 sequenceb = 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 octetsacross the bus, first 0Ah and then 01h.


9-4

The following UNSIGNEDn data types are transferred as shown below:

octet number 1. 2. 3. 4. 5. 6. 7. 8.

UNSIGNED8 b7..b0

UNSIGNED16 b7..b0 b15..b8

UNSIGNED24 b7..b0 b15..b8 b23..b16

UNSIGNED32 b7..b0 b15..b8 b23..b16 b31..b24

UNSIGNED40 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32

UNSIGNED48 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40

UNSIGNED56 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40 b55..b48

UNSIGNED64 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40 b55..b48 b63..b56

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-1is assigned the value

INTEGERn(b) = bn-2 2n-2 + ...+ b1 21 + b0 20 if bn-1 = 0and, performing two's complement arithmetic,

INTEGERn(b) = - INTEGERn(b) - 1 if bn-1 = 1Note 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 octetsacross the bus, first F6h and then FEh.

The following INTEGERn data types are transfered as shown below:

octet number 1. 2. 3. 4. 5. 6. 7. 8.

INTEGER8 b7..b0

INTEGER16 b7..b0 b15..b8

INTEGER24 b7..b0 b15..b8 b23..b16

INTEGER32 b7..b0 b15..b8 b23..b16 b31..b24

INTEGER40 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32

INTEGER48 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40

INTEGER56 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40 b55..b48

INTEGER64 b7..b0 b15..b8 b23..b16 b31..b24 b39..b32 b47..b40 b55..b48 b63..b56

Figure 11: Transfer syntax for data type INTEGERn


9-5

9.1.4.6 Floating-Point Numbers

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 followsthe 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 followsthe 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-a-number). The bit sequence b = b0 É b31is assigned the value (finite non-zero number)

REAL32(b) = (-1)S 2E - 127 (1 + F)HereS = 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 E Fb31 b30 .. b23 b22 .. b00 100 0000 1 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 1. 2. 3. 4.

REAL32 00h 00h C8h 40h

b7..b0 b15..b8 b23..b16 b31..b24

Figure 12: Transfer syntax of data type REAL32


9-6

9.1.5 Compound Data Types

Type definitions of compound data types expand to a unique list of type definitions involving only basicdata types. Correspondingly, data of compound type «type_name« are ordered lists of component datanamed «component_name_i« of basic type «basic_type_i«.Compound data types constructors are ARRAY and STRUCT OF.

STRUCT OF basic_type_1 component_name_1, basic_type_2 component_name_2, É É basic_type_N component_name_Ntype_name

ARRAY [ length ] OF basic_type type_name

The bit sequence representing data of compound type is obtained by concatenating the bit sequencesrepresenting the component data.Assume that the components «component_name_i« are represented by their bit sequences

b(i), for i = 1,É,NThen the compound data is represented by the concatenated sequence

b0(1) .. bn-1(1) .. bn-1(N).Example:Consider the data typeSTRUCT OF

INTEGER10 x,UNSIGNED5 u

NewData

Assume x = - 423 = 259h and u = 30 = 1Eh. Let b(x) and b(u) denote the bit sequencesrepresenting the values of x and u, respectively. Then:b(x) = b0(x) .. b9(x) = 1001101001b(u) = b0(u) .. b4(u) = 01111b(xu) = b(x) b(u) = b0(xu) .. b14(xu) = 1001101001 01111The 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 thefollowing 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 typeVISIBLE_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 VISIBLE_STRINGlengthThere is no 0h necessary to terminate the string.

9.1.6.3 Unicode String

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 encodingrules that TIME_OF_DAY is represented as bit sequence of length 48.


9-7

Component ms is the time in milliseconds after midnight. Component days is the number of days sinceJanuary 1, 1984.

STRUCT OFUNSIGNED28 ms,VOID4 reserved,UNSIGNED16 days

TIME_OF_DAY

9.1.6.5 Time Difference

The data type TIME_DIFFERENCE represents a time difference. It follows from the definition and theencoding 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 numbermilliseconds. Component days is the number of days.

STRUCT OFUNSIGNED28 ms,VOID4 reserved,UNSIGNED16 days

TIME_DIFFERENCE

9.1.6.6 Domain

Domains can be used to transfer an arbitrary large block of data from a client to a server and vv. Thecontents 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 thatis defined for that service. The primitives that are defined for a particular service determine the servicetype (e.g. unconfirmed, confirmed, etc.). How to interpret the tabular form and what service types existis 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 ofPDOs is performed with no protocol overhead.The PDOs correspond to entries in the device Object Dictionary and provide the interface to theapplication objects. Data type and mapping of application objects into a PDO is determined by acorresponding default PDO mapping structure within the Device Object Dictionary. If variable PDO-mapping is supported the number of PDOs and the mapping of application objects into a PDO may betransmitted to a device during the device configuration process (see Initialisation Procedure) byapplying 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 thedevice profile.There are two kinds of use for PDOs. The first is data transmission and the second data reception. It isdistinguished in Transmit-PDOs (TPDOs) and Receive-PDOs (RPDOs). Devices supporting TPDOsare PDO producer and devices which are able to receive PDOs are called PDO consumer. PDOs aredescribed by the PDO communication parameter (20h) and the PDO mapping parameter (21h). Thestructure of these data types are explained in 9.5.4. The PDO communication parameter describes thecommunication capabilities of the PDO. The PDO mapping parameter contains information about thecontents of the PDOs (device variables). The indices of the corresponding Object Dictionary entriesare 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-8

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

For each PDO the pair of communication and mapping parameter is mandatory. The entriesmentioned 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 asynchronisation 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 SYNCobject. The principle of synchronous transmission is described in more detail in 9.3.

SYNC SYNCSYNCSynchronous

Asynchronous

time

SynchronousPDOs

Length

PDOs

Object Window Object Object

Figure 13: Synchronous and Asynchronous Transmission

The transmission type parameter of a PDO specifies the transmission mode as well as the triggeringmode.For synchronous TPDOs the transmission type also specifies the transmission rate in form of a factorbased on the basic SYNC-object transmission period. A transmission type of 0 means that themessage shall be transmitted after occurrence of the SYNC but acyclic (not periodically), only if anevent occurred before the SYNC. A transmission type of 1 means that the message is transmitted withevery SYNC object. A transmission type of n means that the message is transmitted with every n-thSYNC 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 applicationwith the occurrence of the following SYNC, independent of the transmission rate specified by thetransmission 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 synchronousPDOs this is the expiration of the specified transmission period, synchronised by the reception ofthe SYNC object.

For acyclically transmitted synchronous PDOs and asynchronous PDOs the triggering of amessage transmission is a device-specific event specified in the device profile.

· Timer DrivenMessage transmission is either triggered by the occurrence of a device-specific event or if aspecified time has elapsed without occurrence of an event.


9-9

· Remotely requestedThe transmission of an asynchronous PDO is initiated on receipt of a remote request initiated byany 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: PDO number [1..512] for every user type on the local device- user type: one of the values {consumer, producer}- data type: according to the PDO mapping- inhibit-time: n*100 ms, n >> 0

9.2.1.3.1 Write PDO

For the Write PDO service the push model is valid. There are zero or more consumers of a PDO. APDO has exactly one producer.Through this service the producer of a PDO sends the data of the mapped application objects to theconsumer(s).

Table 3: Write PDO

Parameter Request / Indication

Argument PDO Number Data

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 PDOhas exactly one producer.Through this service the consumer of a PDO requests the producer to supply the data of the mappedapplication objects. The service is confirmed. The remote result parameter will confirm the value.

Table 4: Read PDO

Parameter Request / Indication Response / Confirm

Argument PDO Number

Remote Result Data

Mandatory mandatory

Mandatory mandatory


9-10

9.2.1.4 PDO Protocol

9.2.1.4.1 Write PDO Protocol

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

Figure 14: Write PDO Protocol

Process-Data: up to L bytes of application data according to the PDO mappingIf L exceeds the number of bytes ÔnÕ defined by the actual PDO mapping length only the first ÔnÕ bytesare used by the consumer. If L is less than ÔnÕ the data of the received PDO is not processed and anEmergency 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 remotetransmission request frame (RTR) to the network. At the reception of the RTR frame the PDOproducer for the requested PDO transmits the PDO. At all PDO consumers for this PDO the receptionis indicated. There can be 0..n PDO consumers. The read service is optional and depends on thehardware capabilities. Figure 15 shows the Read PDO Protocol.

Figure 15: Read PDO Protocol

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

Process Data

PDO Producer PDO Consumers

response confirmation

0 L (0 £ L £ 8)

Read PDO


requestIndication

Process Data

PDO Producer PDO Consumers

RequestIndication

Indication

Indication0 L (0 £ L £ 8)

Write PDO


9-11

9.2.2 Service Data Object (SDO)

With Service Data Objects (SDOs) the access to entries of a device Object Dictionary is provided. Asthese entries may contain data of arbitrary size and data type SDOs can be used to transfer multipledata 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 isto 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 isan initialisation phase where client and server prepare themselves for transferring the segments. ForSDOs, it is also possible to transfer a data set of up to four bytes during the initialisation phase. Thismechanism is called an expedited transfer.Optionally a SDO can be transferred as a sequence of blocks where each block is a sequence of up to127 segments containing a sequence number and the data. Prior to transferring the blocks there is aninitialisation phase where client and server can prepare themselves for transferring the blocks andnegotiating the number of segments in one block. After transferring the blocks there is a finalisationphase where client and server can optionally verify the correctness of the previous data transfer bycomparing checksums derived from the data set. This transfer type mentioned above is called a blocktransfer 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 blocktransfer because of the implied protocol overhead. In these cases a support for a fallback to thesegmented or expedited transfer in initialisation phase can be implemented. As the assumption of theminimal data set size for which a block transfer outperforms the other transfer types depends onvarious 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 eachblock.After block download the server indicates the client the last successfully received segment of thisblock transfer by acknowledging this segment sequence number. Doing this the server implicitlyacknowledges all segments preceding this segment. The client has to start the following block transferwith the retransmission of all not acknowledged data. Additionally the server has to indicate thenumber of segments per block for the next block transfer.After block upload the client indicates the server the last successfully received segment of this blocktransfer by acknowledging this segment sequence number. Doing this the client implicitlyacknowledges all segments preceding this segment. The server has to start the following blocktransfer with the retransmission of all not acknowledged data. Additionally the client has to indicate thenumber 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 accessedObject Dictionary is the server of the SDO. Both the client or the server can take the initiative to abortthe transfer of a SDO.By means of a SDO a peer-to-peer communication channel between two devices is established. Adevice 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 datatype is explained in 9.5.4. The SDO communication parameter describes the communicationcapabilities of the Server-SDOs and Client-SDOs (CSDO). The indices of the corresponding ObjectDictionary 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 thecommunication parameters can be omitted. The entries mentioned above are described in 9.5 (ObjectDictionary).

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-12

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

- transfer 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- data type: 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 beresponsible for transferring the SDO as a sequence of segments.Expetited transfer has to be supported. Segmented transfer has to be supported if objects larger than4 Bytes are supported. Optionally the following SDO services for doing a block transfer with higher busutilisation 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 beresponsible 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 BlockUploadÕ can be implemented to increase transfer performance for data which size does not justifiesusing 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 ObjectDictionary). The data, the multiplexor (index and sub-index) of the data set that has been downloadedand 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 therequest. 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 DownloadSDO Segment services (data length > 4 bytes).


9-13

Table 5: SDO Download


Argument SDO Number Data Size Multiplexor

Remote Result Success Failure Reason

Mandatory mandatory mandatory optional

mandatory

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 theserver. 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 theserver. In case of an expedited download, the data of the data set identified by the multiplexor andsize is indicated to the server.

Table 6: Initiate SDO Download


Argument SDO Number Size Multiplexor Transfer type Normal Expedited Data

Remote Result Success

Mandatory mandatory optional mandatory mandatory selection selection mandatory

Mandatory mandatory

The service is confirmed. The remote result parameter will indicate the success of the request. In caseof a failure, an Abort SDO Transfer request has to be executed. In the case of a successful expediteddownload of a multiplexed DOMAIN, this service concludes the download of the data set identified bymultiplexor.

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. Thesegment data and optionally its size are indicated to the server. The continue parameter indicates theserver whether there are still more segments to be downloaded or that this was the last segment to bedownloaded.


9-14

Table 7: Download SDO Segment


Argument SDO number Data Size Continue More Last


Mandatory mandatory mandatory optional mandatory selection selection

Mandatory mandatory

The service is confirmed. The remote result parameter will indicate the success of the request. In caseof a failure, an Abort SDO transfer request must be executed. In case of success, the server hasaccepted the segment data and is ready to accept the next segment. There can be at most oneDownload SDO Segment service outstanding for a SDO transfer.A successful Initiate SDO Download service with segmented transfer type must have been executedprior 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 sub-index) 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 SDOSegment services (data length > 4 bytes).

Table 8: SDO Upload


Argument SDO number Multiplexor

Remote Result Success Data SizeFailure

Reason


Mandatory selection mandatory optional selection optional

The service is confirmed. The remote result parameter will indicate the success or failure of therequest. In case of a failure, optionally the reason is confirmed. In case of success, the data and itssize (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 theserver.The service is confirmed. The remote result parameter will indicate the success of the request. In caseof 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 successfulexpedited upload, this service concludes the upload of the data set identified by multiplexor and thecorresponding data is confirmed.


9-15

Table 9: Initiate SDO Upload


Argument SDO number Multiplexor

Remote Result Success SizeMultiplexor Transfer type Normal Expedited Data


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 orthat this was the last segment to be uploaded. There can be at most one Upload SDO Segmentservice outstanding for a SDO.The service is confirmed. The remote result parameter will indicate the success of the request. In caseof a failure, an Abort SDO Transfer request must be executed. In case of success, the segment dataand optionally its size are confirmed.A successful Initiate SDO Upload service with segmented transfer type must have been executed priorto this service.

Table 10: Upload SDO Segment


Argument SDO number

Remote Result Success Data Size Continue More Last

Mandatory mandatory

Mandatory mandatory mandatory optional mandatory selection selection

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 isindicated. The service is unconfirmed. The service may be executed at any time by both the client andthe server of a SDO. If the client of a SDO has a confirmed service outstanding, the indication of theabort is taken to be the confirmation of that service.

Table 11: Abort SDO Transfer

Parameter Request / Indication

Argument SDO number Multiplexor Reason

Mandatory mandatory mandatory mandatory


9-16

9.2.2.1.8 SDO Block Download

Through this service the client of SDO downloads data to the server of SDO (owner of the ObjectDictionary) using the block download protocol. The data, the multiplexor (index and sub-index) of thedata 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 therequest. In case of a failure, optionally the reason is confirmed.

Table 12: SDO Block Download


Argument SDO Number Data Size Multiplexor

Remote Result Success Failure Reason

Mandatory mandatory mandatory optional mandatory

Mandatory selection selection optional

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) toprepare for downloading data to the server.The multiplexor of the data set whose download is initiated and optionally the size of the downloadeddata in bytes are indicated to the server.The client as well as the server indicating their ability and/or demand to verify the complete transferwith a checksum in End SDO Block Download.

Table 13: Initiate SDO Block Download


Argument SDO Number Size CRC ability yes no Multiplexor

Remote Result Success CRC ability yes no Blksize

Mandatory mandatory optional mandatory selection selection mandatory

Mandatory mandatory mandatory selection selection mandatory

The service is confirmed. The Remote Result parameter will indicate the success of the request, thenumber of segments per block the server of SDO is able to receive and its ability and/or demand toverify the complete transfer with a checksum. In case of a failure, an Abort SDO Transfer request mustbe 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 blockdata is indicated to the server by a sequence of segments. Each segment consists of the data and asequence number starting with 1 which is increased for each segment by 1 up to blksize. Theparameter blksize is negotiated between server and client in the ÔInitiate Block DownloadÕ protocol andcan be changed by the server with each confirmation for a block transfer. The continue parameter


9-17

indicates the server whether to stay in the ÔDownload BlockÕ phase or to change in the ÔEnd DownloadBlockÕ phase.

Table 14: Download SDO Block


Argument SDO Number Data Continue More Last

Remote Result Success Ackseq Blksize

Mandatory mandatory mandatory mandatory selection selection


The service is confirmed. The Remote Result parameter will indicate the success of the request. Incase of a success the ackseq parameter indicates the sequence number of the last segment theserver has received successfully. If this number does not correspond with the sequence number of thelast segment sent by the client during this block transfer the client has to retransmit all segmentsdiscarded by the server with the next block transfer. In case of a fatal failure, an Abort SDO Transferrequest must be executed. In case of success, the server has accepted all acknowledged segmentdata and is ready to accept the next block. There can be at most one Download SDO Block serviceoutstanding 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 theserver.If the server as well as the client have indicated their ability and demand to check the completetransfer with a checksum in ÔInitiate SDO Block DownloadÕ this checksum is indicated to the server bythe client. The server also has to generate a checksum which has to be compared with the onegenerated by the client.

Table 15: End SDO Block Download


Argument SDO Number Valid_data Ckecksum


Mandatory mandatory mandatory mandatory if negotiated in initiate

Mandatory mandatory

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 thedata 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 ObjectDictionary) using the SDO block upload protocol. The data, the multiplexor (index and sub-index) ofthe 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 therequest. In case of a failure, optionally the reason is confirmed. In case of a success, the data andoptionally its size is confirmed.


9-18

Table 16: SDO Block Upload


Argument SDO Number Multiplexor

Remote Result Success Data Size Failure Reason


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) toprepare for uploading data to the client.The multiplexor of the data set whose upload is initiated and the number of segments the client of theSDO 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 beuploaded is less or equal this value the server can optionally conclude this data transfer with the ÔSDOUpload 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 transferwith a checksum in End SDO Block UploadOptionally the size of the uploaded data in bytes are indicated to the client.

Table 17: Initiate SDO Block Upload


Argument SDO Number Blksize CRC ability Yes No Multiplexor Threshold

Remote Result Success CRC ability Yes No Size

Mandatory mandatory mandatory mandatory selection selection mandatory mandatory

Mandatory mandatory mandatory selection selection optional

The service is confirmed. In case of a failure, an Abort SDO Transfer request must be executed. Incase 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 withthe SDO block upload protocol. In this case the Remote Result parameter and the further protocol isdescribed 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. Theblock data is indicated to the client by a sequence of segments. Each segment consists of thesegment data and a sequence number starting with 1 which is increased for each segment by 1 up toblksize. 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 continueparameter indicates the client whether to stay in the ÔUpload BlockÕ phase or to change in the ÔEndUpload BlockÕ phase.


9-19

Table 18: Upload SDO Block


Argument SDO Number Data Continue More Last

Remote Result Success Ackseq Blksize

Mandatory mandatory mandatory mandatory selection selection


The service is confirmed. The Remote Result parameter will indicate the success of the request. Incase of a success the ackseq parameter indicates the sequence number of the last segment the clienthas received successfully. If this number does not correspond with the sequence number of the lastsegment sent by the server during this block transfer the server has to retransmit all segmentsdiscarded by the client with the next block transfer. In case of a fatal failure, an Abort SDO Transferrequest must be executed. In case of success, the client has accepted all acknowledged segmentdata and is ready to accept the next block. There can be at most one Upload Block serviceoutstanding 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 theclient.If the server as well as the client have indicated their ability and demand to check the completetransfer with a checksum during ÔInitiate SDO Block UploadÕ this checksum is indicated to the client bythe server. The client also has to generate a checksum which has to be compared with the onegenerated by the server.

Table 19: End SDO Block Upload


Argument SDO Number Valid_data Checksum


Mandatory mandatory mandatory mandatory if negotiated in initiate

Mandatory mandatory

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 thedata set. In case of a failure, an Abort SDO Transfer request must be executed.


9-20

9.2.2.2 SDO Protocols

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 SDOTransfer) 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 SDOBlock Download, Download SDO Segment, Upload SDO Segment, End SDO Upload and End SDOBlock Download) and one unconfirmed service (Abort SDO Block Transfer) are defined for ServiceData Objects doing the optional block transfer.

9.2.2.2.1 Download SDO Protocol

Figure 16: Download SDO Protocol

This protocol is used to implement the SDO Download service. SDOs are downloaded as a sequenceof 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 downloadsequence.

· a Download SDO Segment response/confirm with the c-bit set to 1, indicating the successfulcompletion of a normal download sequence.

· an Abort SDO Transfer request/indication, indicating the unsuccessful completion of the downloadsequence.

· a new Initiate Domain Download request/indication, indicating the unsuccessful completion of thedownload 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 lastsegment has to be ignored. If such an error is reported to the application, the application may decideto abort the download.

Server

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

Initiate SDO Download (e=0)



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

Client SDO Download (normal) Server

Initiate SDO Download (e=1)

Client SDO Download (expedited)


9-21

9.2.2.2.2 Initiate SDO Download Protocol

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

Figure 17: Initiate SDO Download Protocol

· ccs: client command specifier1: initiate download request

· scs: server command specifier3: 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 notcontain data. Bytes [8-n, 7] do not contain data.

· e: transfer type0: normal transfer1: expedited transfer

· s: size indicator0: data set size is not indicated1: 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 referencedby 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

Client Server

confirm response

Initiate SDO Download

indicationrequest

7..5

ccs=1

4

X

0

s

m d

0 1 4 8

0 1 4 8

3..2

n

1

e

7..5

scs=3

4..0

X

m reserved


9-22

9.2.2.2.3 Download SDO Segment Protocol

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

Figure 18: Download SDO Segment Protocol

· ccs: client command specifier0: download segment request

· scs: server command specifier1: download segment response

· seg-data: at most 7 bytes of segment data to be downloaded. The encoding depends on the typeof 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] donot 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 downloaded1: no more segments to be downloaded

· t: toggle bit. This bit must alternate for each subsequent segment that is downloaded. The firstsegment will have the toggle-bit set to 0. The toggle bit will be equal for the request and theresponse message.

· X: not used, always 0· reserved: reserved for further use, always 0

Client Server

confirm response

Download SDO Segment

indicationrequest

7..5

ccs=0

4

t

0

c

seg-data

0 1

0 1 8

3..1

n

3..0

X

7..5

scs=1

4

t

reserved

8


9-23

9.2.2.2.4 Upload SDO Protocol

Figure 19: Upload SDO Protocol

This protocol is used to implement the SDO Upload service. SDO are uploaded as a sequence of zeroor more Upload SDO Segment services preceded by an Initiate SDO Upload service. The sequence isterminated by:

· an Initiate SDO Upload response/confirm with the e-bit set to 1, indicating the successfulcompletion of an expedited upload sequence.

· an Upload SDO Segment response/confirm with the c-bit set to 1, indicating the successfulcompletion of a normal upload sequence.

· an Abort SDO Transfer request/indication, indicating the unsuccessful completion of the uploadsequence.

· a new Initiate SDO Upload request/indication, indicating the unsuccessful completion of theupload 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 lastsegment has to be ignored. If such an error is reported to the application, the application may decideto abort the upload.

Server

Initiate SDO Upload (e=0)

Client SDO Upload (normal)

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



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

Client Server

Initiate SDO Upload (e=1)

SDO Upload (expedited)


9-24

9.2.2.2.5 Initiate SDO Upload Protocol

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

Figure 20: Initiate SDO Upload Protocol

· ccs: client command specifier2: initiate upload request

· scs: server command specifier2: 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 notcontain data. Bytes [8-n, 7] do not contain segment data.

· e: transfer type0: normal transfer1: expedited transfer


· 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 referencedby 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

Client Server

confirm response

Initiate SDO Upload

indicationrequest

0 1

3..2

n

7..5ccs=2

4

X

d

8

7..5scs=2

m reserved

0 1 8

4..0

X

4

4

m0

s

1

e


9-25

9.2.2.2.6 Upload SDO Segment Protocol

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

Figure 21: Upload SDO Segment Protocol

· ccs: client command specifier3: upload segment request

· scs: server command specifier0: upload segment response

· t: toggle bit. This bit must alternate for each subsequent segment that is uploaded. The firstsegment will have the toggle-bit set to 0. The toggle bit will be equal for the request and theresponse message.

· c: indicates whether there are still more segments to be uploaded.0: more segments to be uploaded1: no more segments to be uploaded

· seg-data: at most 7 bytes of segment data to be uploaded. The encoding depends on the type ofthe 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] donot contain segment data. n = 0 if no segment size is indicated.

· X: not used, always 0· reserved: reserved for further use, always 0

Client Server

confirm response

Upload SDO Segment

indicationrequest

0 1

3..1

n

7..5

scs=0

seg-data

8

0 1 8

0

c

4

t

7..5

ccs=3

reserved3..0

X

4

t


9-26

9.2.2.2.7 Abort SDO Transfer Protocol

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

Figure 22: Abort SDO Transfer Protocol

· cs: command specifier4: 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 Description

0503 0000h Toggle bit not alternated.

0504 0000h SDO protocol timed out.

0504 0001h Client/server command specifier not valid or unknown.

0504 0002h Invalid block size (block mode only).

0504 0003h Invalid sequence number (block mode only).

0504 0004h CRC error (block mode only).

0504 0005h Out of memory.

0601 0000h Unsupported access to an object.

0601 0001h Attempt to read a write only object.

0601 0002h Attempt to write a read only object.

0602 0000h Object does not exist in the object dictionary.

0604 0041h Object cannot be mapped to the PDO.

0604 0042h The number and length of the objects to be mapped would exceed PDO

length.

0604 0043h General parameter incompatibility reason.

0604 0047h General internal incompatibility in the device.

0606 0000h Access failed due to an hardware error.

0607 0010h Data type does not match, length of service parameter does not match

0607 0012h Data type does not match, length of service parameter too high

0607 0013h Data type does not match, length of service parameter too low

0609 0011h Sub-index does not exist.

Client/Server Abort SDO Transfer

indicationrequest

0 1 8

7..5cs=4

d4..0

X

m

Server/Client

4


9-27

0609 0030h Value range of parameter exceeded (only for write access).

0609 0031h Value of parameter written too high.

0609 0032h Value of parameter written too low.

0609 0036h Maximum value is less than minimum value.

0800 0000h general error

0800 0020h Data cannot be transferred or stored to the application.

0800 0021h Data cannot be transferred or stored to the application because of local

control.

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-28

9.2.2.2.8 SDO Block Download Protocol

Figure 23: SDO Block Download Protocol

This protocol is used to implement a SDO Block Download service. SDOs are downloaded as asequence of Download SDO Block services preceded by an Initiate SDO Block Download service. TheSDO 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 thedownload sequence.

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

Server

Download Block

Initiate Block Download

Download Block (normal)

Download Block (normal)

Download Block (last)

End Block Download

Client SDO_Block_Download

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

Server

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

Confirm block

Client

Download_Block (normal)


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

Server


Confirm block

Client

Download_Block (last)



9-29

9.2.2.2.9 Initiate SDO Block Download Protocol

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

Figure 24: Initiate SDO Block Download Protocol

· ccs: client command specifier6: block download

· scs: server command specifier5: block download


· cs: client subcommand0: initiate download request

· ss: server subcommand0: initiate download response

· cc: client CRC supportcc = 0: Client does not support generating CRC on data

cc = 1: Client supports generating CRC on data

· sc: server CRC supportsc = 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

Client Server

confirm response

Initiate Block Download

indicationrequest

7..5

ccs=64..3

X

0

cs=0

m size

0 1 4 5 8

0 1 4 8

1

s

7..5

scs=5

4..3

X

blksizem reserved2

sc

1..0

ss=0

2

cc


9-30

9.2.2.2.10 Download SDO Block Segment Protocol

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 downloaded1: 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 blockdownload. If ackseq is set to 0 the server indicates the client that the segment with the sequencenumber 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 blockdownload with 0 < blksize < 128.

· X: not used, always 0

· reserved: reserved for further use, always 0

Client Server

confirm response

Download Block Segment

indicatiorequest

8c

7..1

seqno

seg-data

7..5

scs=5

4..2

X

blksizeackseq reserved

0 1 2 3 8

0 1 8

1..0

ss=2


9-31

9.2.2.2.11 End SDO Block Download Protocol

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

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 forgenerating the CRC is described in 9.2.2.2.16. CRC is only valid if in Initiate Block Download ccand sc are set to 1 otherwise CRC has to be set to 0.



Client Server

confirm response

End Block Download

indicationrequest

7..5

ccs=6

4..2

n

reserved

7..5

scs=5

4..2

X

reserved

0 1 8

0 1 8

1

X

crc

3

1..0

ss=1

0

cs=1


9-32

9.2.2.2.12 Upload SDO Block Protocol

Figure 27: Upload SDO Block Protocol

This protocol is used to implement a SDO Block Upload service which starts with the Initiate SDOBlock Upload service. The client can indicate a threshold value to the server which is the minimumvalue in bytes to increase transfer performance using the SDO Block Upload protocol instead of theSDO Upload protocol. If the data set size is less or equal this value the server can continue with thenormal or expedited transfer of the SDO Block Upload protocol.Otherwise SDOs are uploaded as a sequence of Upload SDO Block services. The SDO Upload Blocksequence 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 clientas well as server have indicated the ability to generate a CRC during the Initiate SDO Block Uploadservice the client has to generate the CRC on the received data. If this CRC differs from the CRCgenerated by the server the client has to indicate this with an ÔAbort SDO TransferÕ indication.

Fallback to SDO Upload Protocol

Server

Initiate Block Upload (Phase I) (pst != 0)

Client SDO_Block_Upload (fallback)

Initiate Block Upload (Phase II)

Server

Initiate Block Upload (Phase I)

Upload Block (normal)

Upload Block (normal)

Upload Block (last)

End Block Upload

Client SDO_Block_Upload (normal)

Client

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

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

Confirm block

Upload_Block (normal)


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


Confirm block

ClientUpload_Block (last)


Server Server


9-33

9.2.2.2.13 Initiate SDO Block Upload Protocol

This protocol is used to implement the Initiate SDO Block Upload service. If the value of the ProtocolSwitch Threshold parameter indicated by the client in the first request is less or equal the data set sizeto be uploaded the server can continue with the SDO Upload Protocol as described in 9.2.2.2.4.

Figure 28: Initiate SDO Block Upload Protocol

· ccs: client command specifier5: block upload

· scs: server command specifier6: block upload

· cs: client subcommand0: initiate upload request3: start upload

· ss: server subcommand0: 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 supportsc = 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 protocolpst = 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 servercan optionally switch to the ÔSDO Upload ProtocolÕ by transmitting the server responseof the ÔSDO Upload ProtocolÕ as described in 9.2.2.2.4.


· size: upload size in bytes

s = 0: size is reserved for further use, always 0s = 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.



ServerClient

confirm response

Initiate Block Upload

0 1 4 8

7..5

scs=6

4..3

X

sizem1

s

indicationrequest

7..5

ccs=5

4..2

X

1..0

cs=0

m X

0 1 4 8

blk-size

5

0

ss=0

indicationrequest

7..5

ccs=5

4..2

X

1..0

cs=3

reserved

0 1 8

2

cc

2

cs

pst

6


9-34

9.2.2.2.14 Upload SDO Block Segment Protocol

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

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 uploaded1: 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 blockupload. If ackseq is set to 0 the client indicates the server that the segment with the sequencenumber 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 blockupload with 0 < blksize < 128.



Client Server

response confirm

Upload Block

requestindicatio

8

c

7..1

seqno

seg-data

0 1 8

7..5

ccs=6

4..2

X

blksizeackseq reserved

2 30 1 8

1..0

cs=2


9-35

9.2.2.2.15 End SDO Block Upload Protocol

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

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 forgenerating the CRC is described in 9.2.2.2.16. CRC is only valid if in Initiate Block Upload cc andsc are set to 1 otherwise crc has to be set to 0.



9.2.2.2.16 CRC calculation algorithm to verify SDO Block Transfer

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

Client Server

response confirm

End SDO Block Upload

requestindication

7..5

scs=6

4..2

n

reserved

7..5

ccs=5

4..3

X

reserved

0 1 8

0 1 8crc

3

0

cs=1

1..0

ss=1


9-36

9.2.3 Synchronisation Object (SYNC)

The Synchronisation Object is broadcasted periodically by the SYNC producer. This SYNC providesthe basic network clock. The time period between the SYNCs is specified by the standard parametercommunication cycle period (see Object 1006h: Communication Cycle Period), which may bewritten by a configuration tool to the application devices during the boot-up process. There can be atime jitter in transmission by the SYNC producer corresponding approximately to the latency due tosome 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 owntiming with that of the Synchronisation Object producer. The details of this synchronisation are devicedependent and do not fall within the scope of this document. Devices which require a more accuratecommon 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 serviceis 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

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.

SYNC Producer SYNC consumer(s)

requestIndication

Indication

Indication

L = 0

Write SYNC


9-37

9.2.4 Time Stamp Object (TIME)

By means of the Time Stamp Object a common time frame reference is provided to devices. Itcontains a value of the type TIME_OF_DAY. The Identifier of the TIME Object is located at ObjectIndex 1012h.

9.2.4.1 TIME Services

The Time Stamp Object transmission follows the producer/consumer push model as described in6.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

Figure 32: TIME Protocol

· Time Stamp: 6 bytes of the Time Stamp Object

Time Stamp

TIME Producer TIME Consumer

requestIndication

Indication

Indication0 L = 6

Write TIME


9-38

9.2.5 Emergency Object (EMCY)

9.2.5.1 Emergency Object Usage

Emergency objects are triggered by the occurrence of a device internal error situation and aretransmitted from an emergency producer on the device. Emergency objects are suitable for interrupttype error alerts. An emergency object is transmitted only once per 'error event'. As long as no newerrors 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 theemergency 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 fallinto the scope of this specification.

Table 21: Emergency Error Codes

Error Code (hex) Meaning

00xx Error Reset or No Error

10xx Generic Error

20xx Current

21xx Current, device input side

22xx Current inside the device

23xx Current, device output side

30xx Voltage

31xx Mains Voltage

32xx Voltage inside the device

33xx Output Voltage

40xx Temperature

41xx Ambient Temperature

42xx Device Temperature

50xx Device Hardware

60xx Device Software

61xx Internal Software

62xx User Software

63xx Data Set

70xx Additional Modules

80xx Monitoring

81xx Communication

8110 CAN Overrun (Objects lost)

8120 CAN in Error Passive Mode

8130 Life Guard Error or Heartbeat Error

8140 recovered from bus off

82xx Protocol Error

8210 PDO not processed due to length error

8220 PDO length exceeded

90xx External Error

F0xx Additional Functions

FFxx Device specific


9-39

The emergency object is optional. If a device supports the emergency object, it has to support at leastthe 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 emergencyobjects will be transmitted. Links between the error state machine and the NMT state machine aredefined 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 emergencymessage (error code and error register). The device enters the error state. Anemergency object with the appropriate error code and error register is transmitted. Theerror 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 code0000 (Error reset) may be transmitted together with the remaining errors in the errorregister and in the manufacturer specific error field.

3. A new error occurs on the device. The device remains in error state and transmits anemergency object with the appropriate error code. The new error code is filled in at thetop of the array of error codes (1003H). It has to be guaranteed that the error codes aresorted 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 anemergency object with the error code Ôreset error / no error'.

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 ObjectData.

Byte 0 1 2 3 4 5 6 7

Content Emergency ErrorCode

(see Table 21)

Errorregister(Object1001H)

Manufacturer specific Error Field

Figure 34: Emergency Object Data

error free

error occurred

0

2

14

3


9-40

9.2.5.3 Emergency Object Services

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: Application specific

9.2.5.4 Emergency Object Protocol

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

Figure 35: Emergency Object Protocol

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

Emergency Object Data

EMCY Producer EMCY Consumer

RequestIndication

Indication

Indication

0 8

Write EMCY


9-41

9.2.6 Network Management Objects

The Network Management (NMT) is node oriented and follows a master-slave structure. NMT objectsare 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 thenetwork 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 NMT Services

9.2.6.1.1 Module Control Services

Through Module Control Services, the NMT master controls the state of the NMT slaves. The stateattribute is one of the values {STOPPED, PRE-OPERATIONAL, OPERATIONAL, INITIALISING}. TheModule Control Services can be performed with a certain node or with all nodes simultaneously. TheNMT master controls its own NMT state machine via local services, which are implementationdependent. The Module Control Services except Start Remote Node can be initiated by the localapplication.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 Indication/Request

Argument Node_ID All

Mandatory selection selection

The service is unconfirmed and mandatory. After completion of the service, the state of the selectedremote 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 Request/Indication

Argument Node _ID All


The service is unconfirmed and mandatory. After completion of the service, the state of the selectedremote nodes will be STOPPED.Enter Pre-Operational

Through this service the NMT Master sets the state of the selected NMT Slave(s) to "PRE-OPERATIONAL".

Table 24: Enter Pre-Operational


Argument Node-ID All


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


9-42

Reset Node

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




The service is unconfirmed and mandatory for all devices. After completion of the service, the state ofthe 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 remotenodes will be RESET COMMUNICATION.

Table 26: Reset Communication




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 errorsdoes not fall into the scope of this specification.Error Control services are achieved principally through periodically transmitting of messages by adevice. There exist two possibilities to perform Error Control.The guarding is achieved through transmitting guarding requests (Node guarding protocol) by theNMT Master. If a NMT Slave has not responded within a defined span of time (node life time) or if theNMT SlaveÕs communication status has changed, the NMT Master informs its NMT Master Applicationabout that event.If Life guarding (NMT slave guarded NMT master) is supported, the slave uses the guard time and life-time factor from its Object Dictionary to determine the node life time. If the NMT Slave is not guardedwithin its life time, the NMT Slave informs its local Application about that event. If guard time and lifetime 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 isreceived. This may be during the boot-up phase or later.The heartbeat mechanism for a device is established through cyclically transmitting a message by aheartbeat producer. One or more devices in the network are aware of this heartbeat message. If theheartbeat cycle fails for the heartbeat producer the local application on the heartbeat consumer will beinformed 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 erroroccurred or has been resolved for the remote node identified by Node_ID.


9-43

Table 27: Node Guarding Event

Parameter Indication

Argument Node_ID State Occurred Resolved

Mandatory mandatory mandatory selection selection

The service is provider initiated and optional.Life Guarding Event

Through this service, the NMT service provider on an NMT Slave indicates that a remote erroroccurred or has been resolved.

Table 28: Life Guarding Event


Argument State Occurred Resolved

Mandatory mandatory selection selection

The service is provider initiated and optional.Heartbeat Event

Through this service, the Heartbeat consumer indicates that a heartbeat error occurred or has beenresolved for the node identified by Node_ID.

Table 29: Heartbeat Event


Argument Node_ID State Occurred Resolved

Mandatory mandatory mandatory selection selection

The service is consumer initiated and optional.

9.2.6.1.3 Bootup Service

Bootup Event

Through this service, the NMT slave indicates that a local state transition occurred from the stateINITIALISING to the state PRE-OPERATIONAL.

Table 30: Bootup Event


Argument None

Mandatory

The service is provider initiated and mandatory.


9-44

9.2.6.2 NMT Protocols

9.2.6.2.1 Module Control Protocols

Start Remote Node Protocol

This protocol is used to implement the 'Start Remote Node' service.

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 ConnectProtocol, 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.

Figure 37: Stop Remote Node Protocol


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.

CS=1 Node-ID

0 1

COB-ID = 0

NMT Slave(s)

Indication(s)

NMT Master

Request

request

2

indication

indication

indication

Start Remote Node

CS=2 Node-ID

0 1

COB-ID = 0

NMT Slave(s)

Indication(s)

NMT Master

Request

request

2

indication

indication

indication

Stop Remote Node


9-45

Enter Pre-Operational Protocol

The protocol is used to implement the 'Enter_Pre-Operational' service.

Figure 38: Enter Pre-Operational Protocol


128: enter PRE-OPERATIONALNode-ID: the Node-ID of the NMT Slave as assigned by the NMT Master in the Node Connect


Reset Node Protocol

The protocol is used to implement the 'Reset Node' service.

Figure 39: Reset Node Protocol

cs: NMT command specifier

129: Reset_NodeNode-ID: the Node-ID of the NMT Slave as assigned by the NMT Master in the Node Connect


CS=128 Node-ID

0 1

COB-ID = 0

NMT Slave(s)

Indication(s)

NMT Master

Request

request

2

indication

indication

indication

Enter Pre-Operational

CS=129 Node-ID

0 1

COB-ID = 0

NMT Slave(s)

Indication(s)

NMT Master

Request

request

2

indication

indication

indication

Reset Node


9-46

Reset Communication Protocol

The protocol is used to implement the 'Reset Communication' service.

Figure 40: Reset Communication Protocol

cs: NMT command specifier

130: Reset_CommunicationNode-ID: the Node-ID of the NMT Slave as assigned by the NMT Master in the Node Connect


CS=130 Node-ID

0 1

COB-ID = 0

NMT Slave(s)

Indication(s)

NMT Master

Request

request

2

indication

indication

indication

Reset Communication


9-47

9.2.6.2.2 Error Control Protocols

Node Guarding Protocol

This protocol is used to detect remote errors in the network. Each NMT Slave uses one remote COBfor the Node Guarding Protocol. This protocol implements the provider initiated Error Control services.

Figure 41: Node Guarding Protocol

s: the state of the NMT Slave

4: STOPPED5: OPERATIONAL127: PRE-OPERATIONAL

t: toggle bit. The value of this bit must alternate between two consecutive responses from the NMTSlave. 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 ispassed (no other change of state resets the toggle bit). If a response is received with the samevalue of the toggle-bit as in the preceding response then the new response is handled as if it wasnot received.

The NMT Master polls each NMT Slave at regular time intervals. This time-interval is called the guardtime and may be different for each NMT Slave. The response of the NMT Slave contains the state ofthat NMT Slave. The node life time is given by the guard time multiplied by the life time factor. Thenode life time can be different for each NMT Slave. If the NMT Slave has not been polled during its lifetime, 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 havedisappeared, it will be indicated that the remote error has been resolved through the 'Node GuardingEvent' and 'Life Guarding Event' services.

COB-ID = 1792 + Node-ID

Node/Life Guarding

7t

0 1

NMT Slave

Indication(s)

NMT Master

Requestrequest indication

6...0s

Remote transmit request

confirm response

7t

0 1request indication

6...0s

Remote transmit request

confirm response


indication indication

Node Guarding Event* Life Guarding Event*

NodeGuardtime

*if guarding error

NodeLife

Time


9-48

For the guard time, the life time factor and the COB-ID of the Node Guarding Protocol there aredefault values specified at the appropriate Object Dictionary entries.

Heartbeat Protocol

The Heartbeat Protocol defines an Error Control Service without need for remote frames. A HeartbeatProducer transmits a Heartbeat message cyclically. One or more Heartbeat Consumer receive theindication. 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 begenerated.

Figure 42: Heartbeat Protocol

· r: reserved (always 0)· s: the state of the Heartbeat producer

0: BOOTUP4: STOPPED5: OPERATIONAL127: PRE-OPERATIONAL

If the Heartbeat Producer Time is configured on a device the Heartbeat Protocol begins immediately. Ifa device starts with a value for the Heartbeat Producer Time unequal to 0 the Heartbeat Protocolstarts on the state transition from INITIALISING to PRE-OPERATIONAL. In this case the BootupMessage is regarded as first heartbeat message. It is not allowed for one device to use both errorcontrol mechanisms Guarding Protocol and Heartbeat Protocol at the same time. If the heartbeatproducer time is unequal 0 the heartbeat protocol is used.


Write Heartbeat

HeartbeatConsumer

HeartbeatProducer

s

0 1

request indication

indicationindication

s

0 1

request indication

indicationindication

HeartbeatProducerTime

HeartbeatConsumerTime

HeartbeatConsumerTime

Heartbeat Event


9-49

9.2.6.2.3 Bootup Protocol

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

Figure 43: Bootup Protocol

One data byte is transmitted with value 0.

9.3 Synchronisation of the SYNC Consumer

9.3.1 Transmission of Synchronous PDO Messages

Synchronous transmission of a message means that the transmission of the message is fixed in timewith respect to the transmission of the SYNC message. The synchronous message is transmittedwithin a given time window with respect to the SYNC transmission, and at most once for every periodof the SYNC.In general the fixing of the transmission time of synchronous PDO messages coupled with theperiodicity of transmission of the SYNC message guarantees that devices may arrange to sampleprocess 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 ofa SYNC message controls the moment when the application will interact with the process environmentaccording to the contents of a synchronous PDO. The synchronous mechanism is intended fortransferring 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 SYNCconsuming device will actuate based on this synchronous PDO at the next SYNC message. Thereception of a SYNC will also prompt a device operating in the cyclic mode to sample its feedbackdata 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 periodsynchronous window length after the SYNC at which it is guaranteed that its commanded value hasarrived. It may therefore perform any processing on the commanded value which is required in orderto actuate at the next SYNC message.

Bootup Event


0

0 1NMT SlaveNMT Master

indication request


9-50

communication cycle period

SYNCMessage

SYNCMessage

Actuation based on objects mapped in lastreceived synchronous RPDO at next SYNC

Synchronous window length

Actuate onobjects mappedin last receivedsynchronousRPDO

Actuate onobjects mappedin last receivedsynchronousRPDO

objects mapped insynchronous RPDO

objects mapped insynchronous RPDO

Figure 44: Bus Synchronisation and Actuation

communication cycle period

SYNCMessage

SYNCMessageobject mapped

in synchronousTPDO

object mappedin synchronousTPDO

Samples immediately taken at SYNCfor objects mapped in synchronous TPDO

synchronous window length

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 thisSYNC depends on the bit rate of the bus as even the very high priority SYNC has to wait for thecurrent message on the bus to be transmitted before it gains bus access.Some time critical applications especially in large networks with reduced transmission rates requiremore accurate synchronisation; it may be necessary to synchronise the local clocks with an accuracyin the order of microseconds. This is achieved by using the optional high resolution synchronisationprotocol which employs a special form of time stamp message (see Figure 46) to adjust the inevitabledrift of the local clocks.The SYNC producer time-stamps the interrupt generated at t1 by the successful transmission of theSYNC message (this takes until t2). After that (at t4) he sends a time-stamp message containing thecorrected time-stamp (t1) for the SYNC transmission success indication. The SYNC consumer thathave taken local time-stamps (t3) on the reception (t1) of the SYNC can now compare their correctedtime-stamp (t1) with the one received in the time-stamp message from the SYNC producer. Thedifference between these values determines the amount of time to adjust the local clock. With thisprotocol only the local latencies (t2-t1 on the SYNC producer and t3-t1 on the SYNC consumer ) aretime critical. These latencies depend on local parameters (like interrupt processing times andhardware delays) on the nodes which have to be determined once. The accuracy of this determination


9-51

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 messagecontains the corrected value t1 and not t2.The time-stamp is encoded as UNSIGNED32 with a resolution of 1 microsecond which means that thetime counter restarts every 72 minutes. It is configured by mapping the high resolution time-stamp intoa PDO.It is reasonable to repeat the clock adjustment only when the maximum drift of the local clock exceedsthe synchronisation accuracy. For most implementations this means that it is sufficient to add thistime-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 accuracyis widely independent of the transmission rate. Further improvement requires separate hardware (e.g.wiring).

master

slave

timet1 t2 t3 t4 t5

SYNC TIMESTAMP

Figure 46: Optional High Resolution Synchronisation Protocol


9-52

9.4 Network Initialisation and System Boot-Up

9.4.1 Initialisation Procedure

In Figure 47 the general flow chart of the network initialisation process, controlled by a NMT MasterApplication or Configuration Application is shown.

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 afterpower-on. In this state the devices are accessible via their Default-SDO using identifiers that havebeen assigned according to the Predefined Connection Set. In this step the configuration of deviceparameters 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 forthe 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 andoptionally 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 applicationand communication parameters.If the application requires the synchronisation of all or some nodes in the network, the appropriatemechanisms can be initiated in the optional Step B. It can be used to ensure that all nodes aresynchronised by the SYNC object before entering the node state OPERATIONAL in step D. The firsttransmission 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 instep A.With step D all nodes are enabled to communicate via their PDO objects.

9.4.2 NMT State Machine

9.4.2.1 Overview

In Figure 48 the state diagram of a device is shown. Devices enter the PRE-OPERATIONAL statedirectly 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 switcheddirectly into the OPERATIONAL state.The NMT state machine determines the behaviour of the Communication function unit (see 6.2). Thecoupling of the application state machine to the NMT state machine is device dependent and falls intothe scope of device profiles.

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 tothe operational state

A

B

C

D


9-53

Minimal Boot-Up consists of one CAN telegram: a broadcast Start_Remote_Node message.

Figure 48: State Diagram of a Device

Table 31: Trigger for State Transition

(1) At Power on the initialisation state is entered autonomously

(2) Initialisation finished - enter PRE-OPERATIONAL automatically

(3),(6) Start_Remote_Node indication

(4),(7) Enter_PRE-OPERATIONAL_State indication

(5),(8) Stop_Remote_Node indication

(9),(10),(11) Reset_Node indication

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

Initialisation

Pre-Operational

Operational

Stopped

(14)

(9)

(2)

(3)

(4)

(7)

(5)

(8)

(6)

Power on or Hardware Reset

(13)

(12)

(10)

(11)

(1)


9-54

9.4.2.2 States

9.4.2.2.1 Initialisation

The ãinitialisationÒ state is divided into three sub-states (see Figure 49) in order to enable a completeor 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-onvalues the state Reset_Communication is entered autonomously.

2. Reset_Communication: In this state the parameters of the communication profile area are set totheir 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. Afterfinishing the basic node initialisation the device executes the write boot-up object service andenters the state PRE-OPERATIONAL autonomously.

Power-on values are the last stored parameters. If storing is not supported or has not been executedor if the reset was preceded by a restore_default command (object 1011H), the power-on values arethe default values according to the communication and device profile specifications.

(2) Initialisation finished - enter PRE-OPERATIONAL automatically

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

(9),(10)(11) Reset_Node indication

(15) Application Reset performed

(16) Communication Reset performed

Figure 49: Structure of the Initialisation state

power-on orhardware reset

(12)

(10)

(2)

(15)

(16)

Initialisation

ResetCommunication

Initialising

ResetApplication

(9)

(11)

(13)

(14)


9-55

9.4.2.2.2 Pre-Operational

In the PRE-OPERATIONAL state, communication via SDOs is possible. PDO communication is notallowed. 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_Noderequest.

9.4.2.2.3 Operational

In the OPERATIONAL state all communication objects are active. Object Dictionary Access via SDO ispossible. Implementation aspects or the application state machine however may require to limit theaccess to certain objects whilst being operational, e.g. an object may contain the application programwhich 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 (exceptnode guarding and heartbeat, if active). Furthermore, this state can be used to achieve certainapplication 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 onthe listed communication objects may only be executed if the devices involved in the communicationare in the appropriate communication states.

Table 32: States and Communication Objects

INITIALISING PRE-OPERATIONAL OPERATIONAL STOPPED

PDO X

SDO X X

Synchronisation Object X X

Time Stamp Object X X

Emergency Object X X

Boot-Up Object X

Network ManagementObjects

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 allocationscheme is defined. These identifiers are available in the PRE-OPERATIONAL state directly afterinitialisation (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 providethe corresponding identifiers only for the supported communication objects.The default profile ID-allocation scheme (Table 33 and Table 34) consists of a functional part, whichdetermines the object priority and a Node-ID-part, which allows to distinguish between devices of thesame functionality. This allows a peer-to-peer communication between a single master device and up


9-56

to 127 slave devices. It also supports the broadcasting of non-confirmed NMT-objects, SYNC- andTIME-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 Receive-PDOs (RPDO) and 4 Transmit-PDOs (TPDO) and the NMT objects.

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 function code(binary)

resulting COB-ID Communication Parametersat Index

NMT 0000 0 -SYNC 0001 128 (80h) 1005h, 1006h, 1007hTIME STAMP 0010 256 (100h) 1012h, 1013h

Table 34: Peer-to-Peer Objects of the Pre-defined Connection Set

object function code(binary)

Resulting COB-IDs Communication Parametersat Index

EMERGENCY 0001 129 (81h) Ð 255 (FFh) 1014h, 1015hPDO1 (tx) 0011 385 (181h) Ð 511 (1FFh) 1800hPDO1 (rx) 0100 513 (201h) Ð 639 (27Fh) 1400hPDO2 (tx) 0101 641 (281h) Ð 767 (2FFh) 1801hPDO2 (rx) 0110 769 (301h) Ð 895 (37Fh) 1401hPDO3 (tx) 0111 897 (381h) Ð 1023 (3FFh) 1802hPDO3 (rx) 1000 1025 (401h) Ð 1151 (47Fh) 1402hPDO4 (tx) 1001 1153 (481h) Ð 1279 (4FFh) 1803hPDO4 (rx) 1010 1281 (501h) Ð 1407 (57Fh) 1403hSDO (tx) 1011 1409 (581h) Ð 1535 (5FFh) 1200hSDO (rx) 1100 1537 (601h) Ð 1663 (67Fh) 1200hNMT ErrorControl

1110 1793 (701h) Ð 1919 (77Fh) 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 ifextended CAN frames are present in the network.

9.5 Object Dictionary

9.5.1 General Structure of the Object Dictionary

This section details the Object Dictionary structure and entries which are common to all devices. Theformat 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 denotesthe objects position within the Object Dictionary. This acts as a kind of address to reference thedesired data field. The sub-index is not specified here. The sub-index is used to reference data fieldswithin a complex object such as an array or record.

Function Code Node-ID

Bit-No.:COB-Identifier

10 0


9-57

The Object column contains the Object Name according to Table 36 below and is used to denotewhat kind of object is at that particular index within the Object Dictionary. The following definitions areused:

Table 36: Object Dictionary Object Definitions

Object Name Comments Object Code

NULL A dictionary entry with no data fields 0

DOMAIN Large variable amount of data e.g.executable program code

2

DEFTYPE Denotes a type definition such as aBoolean, UNSIGNED16, float and soon

5

DEFSTRUCT Defines a new record type e.g. thePDOMapping structure at 21h

6

VAR A single value such as anUNSIGNED8, Boolean, float,Integer16, visible string etc.

7

ARRAY A multiple data field object whereeach data field is a simple variable ofthe SAME basic data type e.g. arrayof UNSIGNED16 etc. Sub-index 0 isof UNSIGNED8 and therefore not partof the ARRAY data

8

RECORD A multiple data field object where thedata fields may be any combination ofsimple variables. Sub-index 0 is ofUNSIGNED8 and therefore not part ofthe RECORD data

9

The name column provides a simple textual description of the function of that particular object. Thetype column gives information as to the type of the object. These include the following pre-definedtypes: BOOLEAN, floating point number, UNSIGNED Integer, Signed Integer, visible/octet string, time-of-day, time-difference and DOMAIN (see 9.1). It also includes the pre-defined complex data typePDOMapping and may also include others which are either manufacturer or device specific. It is notpossible 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 fieldwithin 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 Description

rw read and write access

wo write only access

ro read only access

Const 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 beimplemented on a device. An optional object needs not to be implemented on a device. The support ofcertain objects or features however may require the implementation of related objects. In this case, therelations are described in the detailed object specification.


9-58

9.5.2 Dictionary Components

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 datatypes. The range of indices from 24h - 3Fh is not defined yet but reserved for future standard datastructures.The range of indices from 40h - 5Fh is free for manufacturers to define own complex data types. Therange 60h - 7Fh contains device profile specific standard data types. From 80h Ð 9Fh device profilespecific complex data types are defined. The range A0h Ð 25Fh is reserved for the data typedefinitions for Multiple Device Modules similar to the entries 60h Ð 9Fh. The entries form 360h Ð FFFhare reserved for possible future enhancements . The range 1000h - 1FFFh contains thecommunication 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 thisdocument are reserved for further use. The range 2000h - 5FFFh is free for manufacturer specificprofile 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, indicesin the range 0001h - 0007h can be mapped as well in order to define the appropriate space in theRPDO 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 Object Name

0001 DEFTYPE BOOLEAN

0002 DEFTYPE INTEGER8



0005 DEFTYPE UNSIGNED8



0008 DEFTYPE REAL32

0009 DEFTYPE VISIBLE_STRING

000A DEFTYPE OCTET_STRING

000B DEFTYPE UNICODE_STRING

000C DEFTYPE TIME_OF_DAY

000D DEFTYPE TIME_DIFFERENCE

000E DEFTYPE BIT_STRING

000F DEFTYPE DOMAIN


0011 DEFTYPE REAL64






0017 reserved



9-59


001A DEFTYPE UNSIGNED56

001B DEFTYPE UNSIGNED64

001C-001F reserved

0020 DEFSTRUCT PDO_COMMUNICATION_PARAMETER

0021 DEFSTRUCT PDO_MAPPING

0022 DEFSTRUCT SDO_PARAMETER

0023 DEFSTRUCT IDENTITY

0024-003F reserved

0040-005F DEFSTRUCT Manufacturer Specific Complex Data Types

0060-007F DEFTYPE Device Profile (0) Specific Standard Data Types

0080-009F DEFSTRUCT Device Profile (0) Specific Complex Data Types

00A0-00BF DEFTYPE Device Profile 1 Specific Standard Data Types

00C0-00DF DEFSTRUCT Device Profile 1 Specific Complex Data Types

00E0-00FF DEFTYPE Device Profile 2 Specific Standard Data Types

0100-011F DEFSTRUCT Device Profile 2 Specific Complex Data Types

0120-013F DEFTYPE Device Profile 3 Specific Standard Data Types




01A0-01BF DEFTYPE Device Profile 5 Specific Standard Data Types

01C0-01DF DEFSTRUCT Device Profile 5 Specific Complex Data Types

01E0-01FF DEFTYPE Device Profile 6 Specific Standard Data Types




The data type representations used are detailed in 9.1. Every device does not need to support all thedefined data types. A device only has to support the data types it uses with the objects in the range1000h - 9FFFh.The predefined complex data-types are placed after the standard data-types. Four types are definedat present, the PDO CommPar record (PDO_COMMUNICATION_PARAMETER), the PDO Mappingrecord (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 forup to 7 additional virtual devices.A device may optionally provide the length of the standard data types encoded as UNSIGNED32 atread access to the index that refers to the data type. E.g. index 000Ch (Time of Day) contains thevalue 30h=48dec as the data type ãTime of DayÒ is encoded using a bit sequence of 48 bit. If thelength 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 typeat read access to the corresponding data type index. Sub-index 0 then provides the number of entriesat this index not counting sub-indices 0 and 255 and the following sub-indices contain the data typeaccording to Table 38 encoded as UNSIGNED8. The entry at Index 20h describing the structure ofthe PDO Communication Parameter then looks as follows (see also objects 1400h Ð 15FFh):


9-60

Table 39: complex data type example

Subindex Value (Description)

0h 04h (4 sub indices follow)

1h 07h (UNSIGNED32)

2h 05h (UNSIGNED8)

3h 06h (UNSIGNED16)

4h 05h (UNSIGNED8)

Standard (simple) and complex manufacturer specific data types can be distinguished by attempting toread sub-index 1h: At a complex data type the device returns a value and sub-index 0h contains thenumber of sub-indices that follow, at a standard data type the device aborts the SDO transfer as nosub-index 1h available.Note that some entries of data type UNSIGNED32 have the character of a structure (e.g. PDO COB-ID 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 thehighest 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 ofthe entry. It is encoded as UNSIGNED32 and organised as follows:

MSB LSB

Bits 31-16 15-8 7-0

Value Reserved (value: 00 00h) Data Type

(see Table 38)

Object

(see Table 36)

Encodedas

- UNSIGNED8 UNSIGNED8

Figure 51: structure sub-index FFh

It is optional to support sub-index FFh. If it is supported throughout the Object Dictionary and thestructure of the complex data types is provided as well, it enables one to upload the entire structure ofthe 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 thesetypes.

9.5.4.1 PDO Communication Paramter Record Specification

Table 40: PDO Communication Parameter Record

Index Sub-Index Field in PDO Communication Parameter Record Data Type

0020h 0h number of supported entries in the record UNSIGNED8

1h COB-ID UNSIGNED32

2h transmission type UNSIGNED8

3h inhibit time UNSIGNED16

4h reserved UNSIGNED8

5h event timer UNSIGNED16


9-61

9.5.4.2 PDO Mapping Parameter Record Specification

Table 41: PDO Mapping Parameter Record

Index Sub-Index Field in PDO Parameter Mapping Record Data Type

0021h 0h number of mapped objects in PDO UNSIGNED8

1h 1st object to be mapped UNSIGNED32

2h 2nd object to be mapped UNSIGNED32

: : : : : : : : : : : : : : : : : : : : : : : : :

40h 64th object to be mapped UNSIGNED32

9.5.4.3 SDO Parameter Record Specification

Table 42: SDO Parameter Record

Index Sub-Index Field in SDO Parameter Record Data Type

0022h 0h number of supported entries UNSIGNED8

1h COB-ID client -> server UNSIGNED32

2h COB-ID server -> client UNSIGNED32

3h node ID of SDOÕs client resp. server UNSIGNED8

9.5.4.4 Identity Record Specification

Table 43: Identity Record

Index Sub-Index Field in Identity Record Data Type

0023h 0h number of supported entries UNSIGNED8

1h Vendor-ID UNSIGNED32

2h Product code UNSIGNED32

3h Revision number UNSIGNED32

4h Serial number UNSIGNED32

9.6 Communication Profile Specification

9.6.1 Detailed Object Specification

The structure of the Object Dictionary entries is described in the following manner: All device, interfaceand application profiles based on this communication profile have to follow this structure.

Table 44: Format of an Object Description

OBJECT DESCRIPTION

INDEX Profile Index Number

Name Name of parameter

Object Code Variable classification

Data Type Data type classification

Category Optional or Mandatory

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


9-62

Table 45: Object Value Description Format

ENTRY DESCRIPTION

Sub-Index Number of sub-indices being described (field only used for Arrays,Records and Structures)

Description Descriptive name of the Sub-Index (field only used for Arrays,Records and Structures)

Data Type Data type classification (field only used for Records and Structures)

Entry Category Specifies if the Entry is Optional or Mandatory or Conditional incase the Object is present

Access Read Only (ro) or Read/Write (rw) or Write Only (wo) or Const. InOPERATIONAL state the Access to Object Dictionary Entries maybe limited, e.g set to ro.

PDO Mapping 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 range of possible values, or name of data type for full range

Default Value No: not defined by this specification

Value: default value of an object after device initialisation

For simple variables the value description appears once without the sub-index field and entrycategory. 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 gives an overview over the Object Dictionary entries defined by the communication profile:

Table 46: Standard Objects

Index

(hex)

Object

(SymbolicName)

Name Type Acc.1 M/O

1000 VAR device type UNSIGNED32 ro M

1001 VAR error register UNSIGNED8 ro M

1002 VAR manufacturer status register UNSIGNED32 ro O

1003 ARRAY pre-defined error field UNSIGNED32 ro O

1004 reserved for compatibility reasons

1005 VAR COB-ID SYNC UNSIGNED32 rw O

1006 VAR communication cycle period UNSIGNED32 rw O

1007 VAR synchronous window length UNSIGNED32 rw O

1008 VAR manufacturer device name Vis-String const O

1009 VAR manufacturer hardware version Vis-String const O

100A VAR manufacturer software version Vis-String const O

100B reserved for compatibility reasons

100C VAR guard time UNSIGNED16 rw O

100D VAR life time factor UNSIGNED8 rw O

100E reserved for compatibility reasons

100F reserved for compatibility reasons

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


9-63

1010 ARRAY store parameters UNSIGNED32 rw O

1011 ARRAY restore default parameters UNSIGNED32 rw O

1012 VAR COB-ID TIME UNSIGNED32 rw O

1013 VAR high resolution time stamp UNSIGNED32 rw O

1014 VAR COB-ID EMCY UNSIGNED32 rw O

1015 VAR Inhibit Time EMCY UNSIGNED16 rw O

1016 ARRAY Consumer heartbeat time UNSIGNED32 rw O

1017 VAR Producer heartbeat time UNSIGNED16 rw O

1018 RECORD Identity Object Identity (23h) ro M

1019 reserved

::::: ::::: ::::: ::::: ::::: :::::

11FF reserved

Server SDO Parameter

1200 RECORD 1st Server SDO parameter SDO Parameter (22h) ro O

1201 RECORD 2nd Server SDO parameter SDO Parameter (22h) rw M/O**

::::: ::::: ::::: ::::: ::::: :::::

127F RECORD 128th Server SDO parameter SDO Parameter (22h) rw M/O**

Client SDO Parameter

1280 RECORD 1st Client SDO parameter SDO Parameter (22h) rw M/O**

1281 RECORD 2nd Client SDO parameter SDO Parameter (22h) rw M/O**

::::: ::::: ::::: ::::: ::::: :::::

12FF RECORD 128th Client SDO parameter SDO Parameter (22h) rw M/O**

1300 reserved

::::: ::::: ::::: ::::: ::::: :::::

13FF reserved

Receive PDO Communication Parameter

1400 RECORD 1st receive PDO Parameter PDO CommPar (20h) rw M/O*

1401 RECORD 2nd receive PDO Parameter PDO CommPar (20h) M/O*

::::: ::::: ::::: ::::: ::::: :::::

15FF RECORD 512th receive PDO Parameter PDO CommPar (20h) rw M/O*

Receive PDO Mapping Parameter

1600 RECORD 1st receive PDO mapping PDO Mapping (21h) rw M/O*

1601 RECORD 2nd receive PDO mapping PDO Mapping (21h) rw M/O*

::::: ::::: ::::: ::::: ::::: :::::

17FF RECORD 512th receive PDO mapping PDO Mapping (21h) rw M/O*

Transmit PDO Communication Parameter

1800 RECORD 1st transmit PDO Parameter PDO CommPar (20h) rw M/O*

1801 RECORD 2nd transmit PDO Parameter PDO CommPar (20h) rw M/O*

::::: ::::: ::::: ::::: ::::: ::::

19FF RECORD 512th transmit PDO Parameter PDO CommPar (20h) rw M/O*

Transmit PDO Mapping Parameter

1A00 RECORD 1st transmit PDO mapping PDO Mapping (21h) rw M/O*

1A01 RECORD 2nd transmit PDO mapping PDO Mapping (21h) rw M/O*

::::: ::::: ::::: ::::: ::::: :::::

1BFF RECORD 512th transmit PDO mapping PDO Mapping (21h) rw M/O*

* If a device supports PDOs, the according PDO communication parameter and PDO mapping entriesin 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-64

9.6.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 deviceand its functionality. It is composed of a 16-bit field which describes the device profile that is used anda second 16-bit field which gives additional information about optional functionality of the device. TheAdditional Information parameter is device profile specific. Its specification does not fall within thescope of this document, it is defined in the appropriate device profile. For multiple device modules theAdditional Information parameter contains FFFFh and the device profile number referenced by object1000h is the device profile of the first device in the Object Dictionary. All other devices of a multipledevice 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 1000h

Name device type

Object Code VAR

Data Type UNSIGNED32

Category Mandatory

ENTRY DESCRIPTION

Access ro

PDO Mapping No

Value Range UNSIGNED32

Default Value No

Byte: MSB LSB

Additional Information Device Profile Number

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. Thisentry is mandatory for all devices. It is a part of an Emergency object.

OBJECT DESCRIPTION

INDEX 1001h

Name error register

Object Code VAR

Data Type UNSIGNED8

Category Mandatory

ENTRY DESCRIPTION

Access ro

PDO Mapping Optional


Default Value No


9-65

Table 47: Structure of the Error Register

Bit M/O Meaning

0 M generic error

1 O current

2 O voltage

3 O temperature

4 O communication error (overrun, error state)

5 O device profile specific

6 O Reserved (always 0)

7 O manufacturer specific

If a bit is set to 1 the specified error has occurred. The only mandatory error that has to be signalled isthe 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 thesize and the location of this object is defined.

OBJECT DESCRIPTION

INDEX 1002h

Name manufacturer status register

Object Code VAR


Category Optional

ENTRY DESCRIPTION

Access ro



Default Value No

Object 1003h: Pre-defined Error Field

The object at index 1003h holds the errors that have occurred on the device and have been signaledvia 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 errorcode and a 16 bit additional error information field which is manufacturer specific. The error code iscontained 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 LSB

Additional Information Error code

Figure 53: Structure of the pre-defined error field


9-66

OBJECT DESCRIPTION

INDEX 1003h

Name pre-defined error field

Object Code ARRAY


Category Optional

ENTRY DESCRIPTION

Sub-Index 0h

Description number of errors

Entry Category Mandatory

Access rw

PDO Mapping No

Value Range 0 - 254

Default Value 0

Sub-Index 1h

Description standard error field


Access ro

PDO Mapping No


Default Value No

Sub-Index 2h - FEh

Description standard error field

Entry Category Optional

Access ro

PDO Mapping No


Default Value No

Object 1005h: COB-ID SYNC message

Index 1005h defines the COB-ID of the Synchronisation Object (SYNC). Further, it defines whetherthe device generates the SYNC. The structure of this object is shown in Figure 54 and Table 48.

UNSIGNED32

MSB LSB

bits 31 30 29 28-11 10-0

11-bit-ID X 0/1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11-bit Identifier

29-bit-ID X 0/1 1 29 -bit Identifier

Figure 54: Structure of SYNC COB-ID entry


9-67

Table 48: Description of SYNC COB-ID entry

bit number value meaning

31 (MSB) X do not care

30 0 Device does not generate SYNC message

1 Device generates SYNC message

29 0 11-bit ID (CAN 2.0A)

1 29-bit ID (CAN 2.0B)

28 Ð 11 0 if bit 29=0

X if bit 29=1: bits 28-11 of 29-bit-SYNC-COB-ID

10-0 (LSB) X 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, anattempt to set bit 30 is responded with an abort message (abort code: 0609Ê0030h). Devicessupporting the standard CAN frame type only either ignore attempts to change bit 29 or respond withan abort message (abort code: 0609Ê0030h). The first transmission of SYNC object starts within 1sync cycle after setting Bit 30 to 1.OBJECT DESCRIPTION

INDEX 1005h

Name COB-ID SYNC

Object Code VAR


Category Conditional;

Mandatory, if PDOcommunication on asynchronous base is supported

ENTRY DESCRIPTION

Access rw

PDO Mapping No


Default Value 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 0if not used. If the communication cycle period on sync producer is changed to a new value unequal 0the transmission of sync object resumes within 1 sync cycle of the new value.

OBJECT DESCRIPTION

INDEX 1006h

Name communication cycle period

Object Code VAR



Mandatory for Sync producers


9-68

ENTRY DESCRIPTION

Access rw

PDO Mapping No


Default Value 0

Object 1007h: Synchronous Window Length

Contains the length of the time window for synchronous PDOs in ms. It is 0 if not used.

OBJECT DESCRIPTION

INDEX 1007h

Name synchronous window length

Object Code VAR


Category Optional

ENTRY DESCRIPTION

Access rw

PDO Mapping No


Default Value 0

Object 1008h: Manufacturer Device Name

Contains the manufacturer device name.

OBJECT DESCRIPTION

INDEX 1008h

Name manufacturer device name

Object Code VAR

Data Type Visible String

Category Optional

ENTRY DESCRIPTION

Access const

PDO Mapping No

Value Range No

Default Value No

Object 1009h: Manufacturer Hardware Version

Contains the manufacturer hardware version description.

OBJECT DESCRIPTION

INDEX 1009h

Name manufacturer hardware version

Object Code VAR


Category Optional


9-69

ENTRY DESCRIPTION

Access const

PDO Mapping No

Value Range No

Default Value No

Object 100Ah: Manufacturer Software Version

Contains the manufacturer software version description.

OBJECT DESCRIPTION

INDEX 100Ah

Name manufacturer software version

Object Code VAR


Category Optional

ENTRY DESCRIPTION

Access const

PDO Mapping No

Value Range No

Default Value No

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 is0 if not used.

OBJECT DESCRIPTION

INDEX 100Ch

Name guard time

Object Code VAR



Mandatory, if heartbeat is notsupported

ENTRY DESCRIPTION

Access rw;

ro, if life guarding is not supported

PDO Mapping No


Default Value 0


9-70

Object 100Dh: Life Time Factor

The life time factor multiplied with the guard time gives the life time for the node guarding protocol. It is0 if not used.

OBJECT DESCRIPTION

INDEX 100Dh

Name life time factor

Object Code VAR

Data Type UNSIGNED8


Mandatory, if heartbeat is notsupported

ENTRY DESCRIPTION

Access rw;

ro, if life guarding is not supported

PDO Mapping No


Default Value 0

Object 1010h: Store parameters

This object supports the saving of parameters in non volatile memory. By read access the deviceprovides 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 specificcommunication parameters).Sub-Index 3 refers to application related parameters (Index 6000h - 9FFFh manufacturer specificapplication 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 signatureis written to the appropriate Sub-Index. The signature is ãsaveÒ.

Signature MSB LSB

ISO 8859(ÒASCIIÓ)

e v a s

hex 65h 76h 61h 73h

Figure 55: Storage write access signature

On reception of the correct signature in the appropriate sub-index the device stores the parameter andthen confirms the SDO transmission (initiate download response). If the storing failed, the deviceresponds with an Abort SDO Transfer (abort code: 0606Ê0000h).If a wrong signature is written, the device refuses to store and responds with Abort SDO Transfer(abort code: 0800Ê002xh).On read access to the appropriate Sub-Index the device provides information about its storagefunctionality with the following format:

UNSIGNED32

MSB LSB

bits 31-2 1 0

reserved (=0) 0/1 0/1

Figure 56: Storage read access structure


9-71

Table 49: Structure of read access


31-2 0 reserved (=0)

1 0 Device does not save parameters autonomously

1 Device saves parameters autonomously

0 0 Device does not save parameters on command

1 Device saves parameters on command

Autonomous saving means that a device stores the storable parameters in a non-volatile mannerwithout user request.

OBJECT DESCRIPTION

INDEX 1010h

Name store parameters

Object Code ARRAY


Category Optional

ENTRY DESCRIPTION

Sub-Index 0h

Description largest subindex supported


Access ro

PDO Mapping No

Value Range 1h Ð 7Fh

Default Value No

Sub-Index 1h

Description save all parameters


Access rw

PDO Mapping No

Value Range UNSIGNED32 (Figure 55)

Default Value No

Sub-Index 2h

Description save communication parameters


Access rw

PDO Mapping No


Default Value No


9-72

Sub-Index 3h

Description save application parameters


Access rw

PDO Mapping No


Default Value No

Sub-Index 4h - 7Fh

Description save manufacturer definedparameters


Access rw

PDO Mapping No


Default Value No

Object 1011h: Restore default parameters

With this object the default values of parameters according to the communication or device profile arerestored. 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 specificcommunication parameters).Sub-Index 3 refers to application related parameters (Index 6000h - 9FFFh manufacturer specificapplication 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 aspecific signature is written to the appropriate sub-index. The signature is ãloadÒ.

Signature MSB LSB

ASCII d a o lhex 64h 61h 6Fh 6Ch

Figure 57: Restoring write access signature

On reception of the correct signature in the appropriate sub-index the device restores the defaultparameters and then confirms the SDO transmission (initiate download response). If the restoringfailed, the device responds with an Abort SDO Transfer (abort code: 0606Ê0000h). If a wrong signatureis written, the device refuses to restore the defaults and responds with an Abort SDO Transfer (abortcode: 0800Ê002xh).The default values are set valid after the device is reset (reset node for sub-index 1h Ð 7Fh, resetcommunication for sub-index 2h) or power cycled. If the device requires storing on command (seeObjectÊ1010h), the appropriate command has to be executed after the reset if the default parametersare to be stored permanently.


9-73

Figure 58: restore procedure

On read access to the appropriate sub-index the device provides information about its defaultparameter restoring capability with the following format:

UNSIGNED32

MSB LSB

bits 31-1 0

reserved (=0) 0/1

Figure 59: Restoring default values read access structure

Table 50: Structure of restore read access


31-1 0 reserved (=0)

0 0 Device does not restore default parameters

1 Device restores parameters

OBJECT DESCRIPTION

INDEX 1011h

Name restore default parameters

Object Code ARRAY


Category Optional

ENTRY DESCRIPTION

Sub-Index 0h

Description largest subindex supported


Access ro

PDO Mapping No


Default Value No

restore default

reset / power cycle

default values valid

save


9-74

Sub-Index 1h

Description restore all default parameters


Access rw

PDO Mapping No


Default Value No

Sub-Index 2h

Description restore communication defaultparameters


Access rw

PDO Mapping No


Default Value No

Sub-Index 3h

Description restore application defaultparameters


Access rw

PDO Mapping No


Default Value No

Sub-Index 4h - 7Fh

Description restore manufacturer defineddefault parameters


PDO Mapping No


Object 1012h: COB-ID Time Stamp Object

Index 1012h defines the COB-ID of the Time-Stamp Object (TIME). Further, it defines whether thedevice consumes the TIME or whether the device generates the TIME. The structure of this object isshown in Figure 60 and Table 51.

UNSIGNED32

MSB LSB

bits 31 30 29 28-11 10-0

11-bit-ID 0/1 0/1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11-bit Identifier

29-bit-ID 0/1 0/1 1 29 -bit Identifier

Figure 60: Structure of TIME COB-ID entry


9-75

Table 51: Description of TIME COB-ID entry


31 (MSB) 0 Device does not consume TIME message

1 Device consumes TIME message

30 0 Device does not produce TIME message

1 Device produces TIME message

29 0 11-bit ID (CAN 2.0A)


28 Ð 11 0 if bit 29=0

X if bit 29=1: bits 28-11 of 29-bit-TIME-COB-ID

10-0 (LSB) X 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, anattempt to set bit 30 is responded with an abort message (abort code: 0609Ê0030h). Devicessupporting the standard CAN frame type only, an attempt to set bit 29 is responded with an abortmessage (abort code: 0609Ê0030h).

OBJECT DESCRIPTION

INDEX 1012h

Name COB-ID time stamp message

Object Code VAR


Category Optional

ENTRY DESCRIPTION

Access rw

PDO Mapping No


Default Value 100h

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 inorder to define a high resolution time stamp message. (Note that the data type of the standard timestamp message (TIME) is fixed). Further application specific use is encouraged.OBJECT DESCRIPTION

INDEX 1013h

Name high resolution time stamp

Object Code VAR


Category Optional

ENTRY DESCRIPTION

Access rw



Default Value 0


9-76

Object 1014h: COB-ID Emergency Object

Index 1014h defines the COB-ID of the Emergency Object (EMCY). The structure of this object isshown in Figure 61.

UNSIGNED32

MSB LSB

bits 31 30 29 28-11 10-0

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

29-bit-ID reserved (=0) 1 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 anabort message (abort code: 0609Ê0030h).

OBJECT DESCRIPTION

INDEX 1014h

Name COB-ID Emergency message

Object Code VAR



Mandatory, if Emergency issupported

ENTRY DESCRIPTION

Access rw

PDO Mapping No


Default Value 80h + Node-ID

Object 1015h: Inhibit Time EMCY

The inhibit time for the EMCY message can be adjusted via this entry. If this entry exists it must bewritable in the object dictionary. The time has to be a multiple of 100msOBJECT DESCRIPTION

INDEX 1015h

Name Inhibit Time EMCY

Object Code VAR


Category Optional

ENTRY DESCRIPTION

Access rw

PDO Mapping No


Default Value 0

Object 1016h: Consumer Heartbeat Time

The consumer heartbeat time defines the expected heartbeat cycle time and thus has to be higherthan the corresponding producer heartbeat time configured on the device producing this heartbeat.


9-77

Monitoring starts after the reception of the first heartbeat. If the consumer heartbeat time is 0 thecorresponding entry is not used. The time has to be a multiple of 1ms.

UNSIGNED32

MSB LSB

Bits 31-24 23-16 15-0

Value reserved (value: 00h) Node-ID heartbeat time

Encoded as - UNSIGNED8 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 thedevice aborts the SDO download with abort code 0604Ê0043hOBJECT DESCRIPTION

INDEX 1016h

Name Consumer Heartbeat Time

Object Code ARRAY


Category Optional

ENTRY DESCRIPTION

Sub-Index 0h

Description number entries


Access ro

PDO Mapping No

Value Range 1 Ð 127

Default Value No

Sub-Index 1h

Description Consumer Heartbeat Time


Access rw

PDO Mapping No


Default Value 0

Sub-Index 2h Ð 7Fh

Description Consumer Heartbeat Time


Access rw

PDO Mapping No


Default Value No


9-78

Object 1017h: Producer Heartbeat Time

The producer hartbeat time defines the cycle time of the heartbeat. The producer heartbeat time is 0 ifit not used. The time has to be a multiple of 1ms.OBJECT DESCRIPTION

INDEX 1017h

Name Producer Heartbeat Time

Object Code VAR



Mandatory if guarding notsupported

ENTRY DESCRIPTION

Access rw

PDO Mapping No


Default Value 0

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 aminor revision number. The major revision number identifies a specific CANopen behaviour. If theCANopen functionality is expanded, the major revision has to be incremented. The minor revisionnumber identifies different versions with the same CANopen behaviour.

31 16 15 0

major revision number minor revision numberMSB LSB

Figure 63: Structure of Revision number

The manufacturer-specific Serial number (sub-index 4h) identifies a specific device.

OBJECT DESCRIPTION

INDEX 1018h

Name Identity Object

Object Code RECORD

Data Type Identity

Category Mandatory

ENTRY DESCRIPTION

Sub-Index 0h

Description number of entries


Access ro

PDO Mapping No

Value Range 1 .. 4

Default Value No


9-79

Sub-Index 1h

Description Vendor ID


Access ro

PDO Mapping No


Default Value No

Sub-Index 2h

Description Product code


Access ro

PDO Mapping No


Default Value No

Sub-Index 3h

Description Revision number


Access ro

PDO Mapping No


Default Value No

Sub-Index 4h

Description Serial number


Access ro

PDO Mapping No


Default Value No

Object 1200h - 127Fh: Server SDO Parameter

In order to describe the SDOs used on a device the data type SDO Parameter is introduced. The datatype 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 at1h and 2h specify the COB-ID for this SDO. Sub-index 3 gives the server of the SDO in case therecord describes an SDO for which the device is client and gives the client of the SDO if the recorddescribes an SDO for which the device is server.

UNSIGNED32

MSB LSB

bits 31 30 29 28-11 10-0

11-bit-ID 0/1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11-bit Identifier

29-bit-ID 0/1 0 1 29-bit Identifier

Figure 64: Structure of SDO COB-ID entry


9-80

Table 52: Description of SDO COB-ID entry

bit number value Meaning

31 (MSB) 0 SDO valid

1 SDO not valid

30 0 reserved (always 0)

29 0 11-bit ID (CAN 2.0A)


28 - 11 0 if bit 29=0

X if bit 29=1: bits 28-11 of 29-bit-COB-ID

10-0 (LSB) X bits 10-0 of COB-ID

An SDO is only valid if both SDO-valid-bits are 0. Devices supporting the standard CAN frame typeonly, an attempt to set bit 29 is responded with an abort message (abort code: 0609Ê0030h).These objects contain the parameters for the SDOs for which the device is the server. If a devicehandles more than one server SDO the default SDO must be located at index 1200h as the first serverSDO. This entry is read only2. All additional server SDOs are invalid by default (invalid bit - see Table52), 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 defaultSDO (no Sub-index 3h at Index 1200h), as this entry is read only.

OBJECT DESCRIPTION

INDEX 1200h - 127Fh

Name Server SDO parameter

Object Code RECORD

Data Type SDO Parameter

Category Conditional

Index 1200h: Optional

Index 1201h - 127Fh: Mandatory foreach additionally supportedserver SDO

ENTRY DESCRIPTION

Sub-Index 0h



Access ro

PDO Mapping No

Value Range Index 1200h: 2

Index 1201h Ð 127F: 2 - 3

Default Value No

2 It must be ensured that the COB-IDs of the default SDO can not be manipulated by writing to the

Object Dictionary.


9-81

Sub-Index 1h

Description COB-ID Client->Server (rx)


Access Index 1200h: ro,

Index 1201h-127Fh: rw

PDO Mapping No

Value Range UNSIGNED32 (Table 52)

Default Value Index 1200h: 600h+Node-ID,

Index 1201h-127Fh: No

Sub-Index 2h

Description COB-ID Server -> Client (tx)


Access Index 1200h: ro

Index 1201-127Fh: rw

PDO Mapping No




Sub-Index 3h

Description node ID of the SDO client


Access rw

PDO Mapping No


Default Value No

Object 1280h - 12FFh: Client SDO Parameter

These objects contain the parameters for the SDOs for which the device is the client. If the entry issupported, all sub-indices must be available. Starting at index 1280h and subsequent indicies.Theentries are described at the Server SDO Parameter.

OBJECT DESCRIPTION

INDEX 1280h - 12FFh

Name Client SDO parameter

Object Code RECORD

Data Type SDO Parameter


Mandatory for each supportedclient SDO


9-82

ENTRY DESCRIPTION

Sub-Index 0h



Access ro

PDO Mapping No

Value Range 3

Default Value 3

Sub-Index 1h

Description COB-ID Client->Server (tx)


Access rw

PDO Mapping No


Default Value No

Sub-Index 2h

Description COB-ID Server -> Client (rx)


Access rw

PDO Mapping No


Default Value No

Sub-Index 3h

Description node ID of the SDO server


Access rw

PDO Mapping No


Default Value No

Object 1400h - 15FFh: Receive PDO Communication Parameter

Contains the communication parameters for the PDOs the device is able to receive. The type of thePDO communication parameter (20h) is described in 9.5.4. The sub-index 0h contains the number ofvalid entries within the communication record. Its value is at least 2. If inhibit time supported the valueis 3. At sub-index 1h resides the COB-ID of the PDO. This entry has been defined as UNSIGNED32 inorder 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-83

UNSIGNED32

MSB LSB

bits 31 30 29 28-11 10-0

11-bit-ID 0/1 0/1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 11-bit Identifier

29-bit-ID 0/1 0/1 1 29-bit Identifier

Figure 65: Structure of PDO COB-ID entry

Table 53: Description of PDO COB-ID entry


31 (MSB) 0 PDO valid

1 PDO not valid

30 0 RTR allowed on this PDO

1 no RTR allowed on this PDO

29 0 11-bit ID (CAN 2.0A)


28 Ð 11 0 if bit 29=0



The PDO valid/not valid allows to select which PDOs are used in the operational state. There may bePDOs fully configured (e.g. by default) but not used, and therefore set to "not valid" (disabled). Thefeature is necessary for devices supporting more than 4ÊRPDOs or 4 TPDOs, because each devicehas only default identifiers for the first four RPDOs/TPDOs. Devices supporting the standard CANframe type only or do not support Remote Frames, an attempt to set bit 29 to 1 or bit 30 to 0 isresponded with an abort message (abort code: 0609Ê0030h).The transmission type (sub-index 2) defines the transmission/reception character of the PDO (see9.2.1.1). Table 54 describes the usage of this entry. On an attempt to change the value of thetransmission type to a value that is not supported by the device an abort message (abort code:0609Ê0030h) is generated.

Table 54: Description of transmission type

transmission type PDO transmission

cyclic acyclic synchronous asynchronous RTR only

0 X X

1-240 X X

241-251 - reserved -

252 X X

253 X X

254 X

255 X

Synchronous (transmission types 0-240 and 252) means that the transmission of the PDO shall berelated to the SYNC object as described in 9.3. Preferably the devices use the SYNC as a trigger tooutput or actuate based on the previous synchronous Receive PDO respectively to update the datatransmitted at the following synchronous Transmit PDO. Details of this mechanism depend on thedevice 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 theSYNC object but not periodically.A value between 1 and 240 means that the PDO is transferred synchronously and cyclically, thetransmission type indicating the number of SYNC which are necessary to trigger PDOtransmissions/receptions.


9-84

The transmission types 252 and 253 mean that the PDO is only transmitted on remote transmissionrequest. At transmission type 252, the data is updated (but not sent) immediately after reception of theSYNC object. At transmission type 253 the data is updated at the reception of the remote transmissionrequest (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 (manufacturerspecific part of the Object Dictionary), transmission type 255 means, the application event is defined inthe 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. Thevalue 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 leadsto 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 asmutiple of 1 ms of the entry in sub-index 5h of the TPDO. This event will cause the transmission of thisTPDO 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 theRPDO.

OBJECT DESCRIPTION

INDEX 1400h - 15FFh

Name receive PDO parameter

Object Code RECORD

Data Type PDO CommPar


Mandatory for each supportedPDO

ENTRY DESCRIPTION

Sub-Index 0h

Description largest sub-index supported


Access ro

PDO Mapping No

Value Range 2 Ð 5

Sub-Index 1h

Description COB-ID used by PDO


Access ro;

rw if variable COB-ID issupported

PDO Mapping No


Default Value Index 1400h: 200h + Node-ID,

Index 1401h: 300h + Node-ID,



Index 1404h Ð 15FFh: disabled


9-85

Sub-Index 2h

Description transmission type


Access ro;

rw if variable transmission type issupported

PDO Mapping No


Default Value (Device Profile dependent)

Sub-Index 3h

Description inhibit time

(not used for RPDO)


Access rw

PDO Mapping No


Default Value No

Sub-Index 4h

Description compatibility entry


Access rw

PDO Mapping No


Default Value No

Sub-Index 5h

Description event timer


Access rw

PDO Mapping No

Value Range 0 Ð not used

UNSIGNED16

Default Value 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 mappingparameter (21h) is described in 9.5.4. The sub-index 0h contains the number of valid entries within themapping record. This number of entries is also the number of the application variables which shall betransmitted/received with the corresponding PDO. The sub-indices from 1h to number of entriescontain the information about the mapped application variables. These entries describe the PDOcontents by their index, sub-index and length (Figure 66). All three values are hexadecimal coded. Thelength entry contains the length of the object in bit (1..40h). This parameter can be used to verify theoverall mapping length. It is mandatory.


9-86

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

Byte: MSB LSB

index (16 bit) sub-index (8 bit) object length (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 SDOclient attempts to map an object that cannot be mapped) the device responds with an Abort SDOTransfer Service.Subindex 0 determines the valid number of objects that have been mapped. For changing the PDOmapping first subindex 0 must be set to 0 (mapping is deactivated). Then the objects can beremapped. When a new object is mapped by wrinting a subindex between 1 and 64, the device maycheck whether the object specified by index /subindex exists. If the object does not exist or the objectcannot be mapped, the SDO transfer must be aborted with the Abort SDO Transfer Service with oneof the abort codes 0602Ê0000h or 0604Ê0041h.After all objects are mapped subindex 0 is set to the valid number of mapped objects. When subindex0 is set to a value >0 the device may validate the new PDO mapping before transmitting the responseof the SDO service. If an error is detected the device has to transmit the Abort SDO Transfer Servicewith one of the abort codes 0602Ê0000h, 0604Ê0041h or 0604Ê0042h.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 thePDO is not evaluated by the device. This optional feature is useful e.g. to transmit data to severaldevices using one PDO, each device only utilising a part of the PDO. It is not possible to create adummy mapping for a TPDO.A device that supports dynamic mapping of PDOs must support this during the state PRE-OPERATIONAL state. If dynamic mapping during the state OPERATIONAL is supported, the SDOclient is responsible for data consistency.

PDO: Appl. Obj. 2 Application Object 3 Appl. Obj. 1

Figure 67: Principle of PDO mapping

OBJECT DESCRIPTION

INDEX 1600h Ð 17FFh

Name receive PDO mapping

Object Code RECORD

Data Type PDO Mapping



Object Dictionary

xxxxh xxh Application Object 1

yyyyh yyh Application Object 2

zzzzh zzh Application Object 3

PDO Mapping

0 31 yyyyh yyh 08h

2 zzzzh zzh 10h

3 xxxxh xxh 08h


9-87

ENTRY DESCRIPTION

Sub-Index 0h

Description number of mapped applicationobjects in PDO


Access ro;

rw if dynamic mapping issupported

PDO Mapping No

Value Range 0: deactivated

1 Ð 64: activated

Default Value (device profile dependent)

Sub-Index 1h Ð 40h

Description PDO mapping for the nthapplication object to be mapped

Entry Category Conditional

depends on number and size ofobject be mapped

Access rw

PDO Mapping No



Object 1800h - 19FFh: Transmit PDO Communication Parameter

Contains the communication parameters for the PDOs the device is able to transmit. The type of thePDO communication parameter (20h) is described in 9.5.4. A detailed description of the entries isdone in the section for the Receive PDO Communication Parameter (1400h Ð 15FFh).

OBJECT DESCRIPTION

INDEX 1800h - 19FFh

Name transmit PDO parameter

Object Code RECORD

Data Type PDO CommPar



ENTRY DESCRIPTION

Sub-Index 0h

Description largest sub-index supported


Access ro

PDO Mapping No

Value Range 2 Ð 5


9-88

Sub-Index 1h



Access ro;

rw if COB-ID can be changed

PDO Mapping No






Index 1804h - 18FFh: disabled

Sub-Index 2h



Access ro;

rw if transmission type can bechanged

PDO Mapping No



Sub-Index 3h



Access rw

PDO Mapping No


Default Value No

Sub-Index 4h

Description reserved


Access rw

PDO Mapping No


Default Value No


9-89

Sub-Index 5h

Description event timer

Entry Category Optional (not used for RPDO)

Access rw

PDO Mapping No

Value Range 0 Ð not used

UNSIGNED16

Default Value No

Object 1A00h - 1BFFh: Transmit PDO Mapping Parameter

Contains the mapping for the PDOs the device is able to transmit. The type of the PDO mappingparameter (21h) is described in 9.5.4. A detailed description of the entries is done in the section for theReceive PDO Mapping Parameter (1600h Ð 17FFh).

OBJECT DESCRIPTION

INDEX 1A00h - 1BFFh

Name transmit PDO mapping

Object Code RECORD

Data Type PDO Mapping



ENTRY DESCRIPTION

Sub-Index 0h



Access ro;

rw if dynamic mapping issupported

PDO Mapping No

Value Range 0: deactivated

1 Ð 64: activated


Sub-Index 1h Ð 40h

Description PDO mapping for the n-thapplication object to be mapped

Entry Category Conditional;

depends on number and size ofobjects to be mapped

Access rw

PDO Mapping No



IMPLEMENTATION RECOMMENDATIONS CANopen CiA

10-1

10 IMPLEMENTATION RECOMMENDATIONSWhen 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 invalidparameter values according to the protocol specification. This can only be caused by errors in thelower layers or implementation errors. Invalid COB's must be handled locally in an implementationspecific way that does not fall within the scope of this specification. As far as the protocol isconcerned, 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 thissituation, 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 notcompleted yet. The application must deal with this situation. Time-out values are considered to beimplementation specific and do not fall within the scope of this specification. However, it isrecommended that an implementation provides facilities to adjust these time-out values to therequirements of the application.

Index CANopen CiA

11-1

11 Indexaccess 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

Definitions CANopen Communication Profile CiA

3-1

3 Definitions

CAN Controller Area Network

CiA CAN in Automation international users and manufacturers group e.V.

CMS CAN Message Specification. One of the service elements of the CANApplication Layer in the CAN Reference Model.

COB Communication Object. (CAN Message) A unit of transportation in a CANNetwork. Data must be sent across a Network inside a COB.

COB-ID COB-Identifier. Identifies a COB uniquely in a Network. The identifierdetermines the priority of that COB in the MAC sub-layer too.

DBT Distributor. One of the service elements of the CAN Application Layer inthe CAN Reference Model. Its the responsibility of the DBT to distributeCOB-ID's to the COB's that are used by CMS.

DIN Deutsches Institut f�r Normung

ISO International Standardisation Organisation

LMT Layer Management. One of the service elements of the CAN ApplicationLayer in the CAN Reference Model. It serves to configure parameters ofeach layer in the CAN Reference Model.

NMT Network Management. One of the service elements of the CAN ApplicationLayer in the CAN Reference Model. It performs initialisation, configurationand error handling in a CAN network.

OSI Open Systems Interconnection

PDO Process Data Object

SDO Service Data Object

Introduction CANopen Communication Profile CiA

4-1

4 Introduction

4.1 CANopen Communication Reference Model

The communication concept can be described similar to the ISO-OSI ReferenceModel.

DeviceProfile

A

DeviceProfile

B

DeviceProfile

C

NMT DBT CMS

OSI Data Link Layer: CAN 2.0 A+B

OSI Physical Layer: ISO 11898

Cable

LMT

DeviceProfile

X

ISO/OSI Layer 7: CAN Appl ication Layer (CAL)Subset, usage defined by communic at ion profile

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 andcommunicate real-time-data as well as the mechanisms for synchronisation betweendevices. Basically the CANopen Communication Profile describes how a subset of CANApplication Layer (CAL) services is used by devices.

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


4-2

4.2 Standardisation Via Profiling

The two principal advantages of the profile approach to device specification are in theareas of system integration and device standardisation. If two independent devicemanufacturers are to design products which are to communicate with each other theneach manufacturer must be provided with a specification of the other manufacturersdevice. This specification could take many forms if left to individual manufacturers toproduce. The concept of device profiling provides a standard for producing suchspecifications. By adopting this approach all manufacturers will specify their devices ina 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 canbe used to guide manufacturers into producing standardised devices. The advantagesof standardised devices are numerous. Perhaps most importantly the idea of astandardised device de-couples a system integrator from a specific supplier. If onesupplier cannot meet product demand, for example, the integrator can use devicesfrom another supplier without having to re-configure network software. On the otherhand the supplier is not forced any more to implement a private protocol for eachcustomer.

A device profile defines a standard device. This standard device specifies a basicfunctionality which every device within a class must exhibit. This mandatoryfunctionality is necessary to ensure at least simple non-manufacturer-specific operationof a device is possible1.

The concept of device standardisation is extended by the notion of optionalfunctionality defined within the standard device profiles. Such optional functionalitydoes not have to be implemented by all manufacturers. However, if a manufacturerwishes to implement such functionality he must do so in the manner defined for thestandard device.

The concept of optional functionality provides a very powerful mechanism to ensureall manufacturers implementing particular functionality do so in a defined fashion2.

The device profiles provide a mechanism by which manufacturers wishing toimplement truly manufacturer specific functionality can do so. This is clearly necessarysince it would be impossible to anticipate all possible device functionality and definethis in the optional category of each device class. This approach guarantees that thestandard 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. Byleaving 'hooks' for manufacturer specific functionality manufacturers will not beconstrained to an out-of-date standard.

1 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 supportingthe drive profile can be halted using the same message.

2 For example, the standard digital I/O module may define optional functionality tocater 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 definitionensures that 64-channel I/O modules developed by independent manufacturerswill be largely interchangeable.


4-3

4.3 The Object Dictionary

The most important part of a device profile is the object dictionary description. Theobject dictionary is essentially a grouping of objects accessible via the network in anordered 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 closelyconforms with other industrial Fieldbus concepts:

Index(hex)

Object

0000 not used

0001-001F Static Data Types

0020-003F Complex Data Types

0040-005F Manufacturer Specific Data Types

0060-007F Device Profile Specific Static Data Types

0080-009F Device Profile Specific Complex DataTypes

00A0-0FFF Reserved for further use

1000-1FFF Communication Profile Area

2000-5FFF Manufacturer Specific Profile Area

6000-9FFF Standardised Device Profile Area

A000-FFFF Reserved for further use

Table 4-1: Object Dictionary Structure

The Standard Object Dictionary may contain a maximum of 65536 entries which areaddressed through a 16bit index.

The Static Data Types at indices 0001h through 001Fh contain type definitions forstandard data types like Boolean, integer, floating point, string, etc. These entries areincluded for reference only, they cannot be read or written.

Complex Data Types at indices 0020h through 003Fh are pre-defined structures thatare composed of standard data types and are common to all devices.

Manufacturer Specific Data Types at indices 0040h through 005Fh are also structurescomposed of standard data types but are specific to a particular device.

Device Profiles may define additional data types specific to their device type. Thestatic data types defined by the device profile are listed at indices 0060h - 007Fh, thecomplex 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 10-4.

The Communication Profile Area at indices 1000 through 1FFF contains thecommunication specific parameters for the CAN network. These entries are common toall devices.

The Standardised Device Profile Area at indices 6000h through 9FFFh contains al ldata 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. Theseentries ensure that all devices of a particular type behave in a defined manner (at leastfrom a basic functionality viewpoint).


4-4

The object dictionary concept caters for optional device features which means amanufacturer does not have to provide certain extended functionality on his devicesbut 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 anoptional category manufacturers wishing to implement enhanced functionality will a l ldo 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 asimple variable this references the value of this variable directly. In case of records andarrays 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 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 objectdictionary entries such as arrays or records with multiple data fields the sub-indexreferences fields within a data-structure pointed to by the main index. For example ona single channel RS232 interface module there may exist a data-structure at index6092h which defines the communication parameters for that module. This structuremay contain fields for baud-rate, number of data bits, number of stop bits and paritytype. The sub-index concept can be used to access these individual fields5 as shownbelow:

Main Index Sub Index Variable Accessed Data Type

6092 0 Number of Entries Unsigned8

1 Baud Rate Unsigned16

2 Number Of Data Bits Unsigned8

3 Number Of Stop Bits Unsigned8

4 Parity 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 onechannel. For example a digital output module may have the capability to configureindividual output signals for different polarity. The object dictionary entry at index6022h may define the polarity information. A manufacturer could define his objectdictionary such that the polarity of channel 1 was set by writing data to index 6022 sub-index 1. Similarly the polarity for channel 3 could be configured by writing the polarityinformation to index 6022 sub-index 3. This is allowed since the sub-index is meant toindex elements of a data structure. Multiple channels of the same type can be viewedas an array of channels6 of the same type - which is a structure.

3 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 merelyconform with the defined standard. However manufacturers wishing to makemodules with a greater number of outputs would have no standard to operatewithin. They would be free to define the communication with the other outputsignals as they wished. This could lead to module incompatibility problems.

4 Space is left in the object dictionary at indices 2000h through 5FFFh for trulymanufacturer specific functionality.

5 The fields accessed by the sub-index can be of differing data types.6 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).

Synchronisation by the SYNC Master CANopen Communication Profile CiA

6-1

6 Synchronisation by the SYNC Master

6.1 Transmission of Synchronous PDO Messages

Synchronous transmission of a message means that the transmission of the message isfixed in time with respect to the transmission of the SYNC message. The synchronousmessage is transmitted within a given time window with respect to the SYNCtransmission, and at most once for every period of the SYNC.

In general the fixing of the transmission time of synchronous PDO messages coupledwith the periodicity of transmission of the SYNC message guarantees that sensordevices may arrange to sample process variables and that actuator devices may applytheir actuation in a co-ordinated fashion.

Assuming a structure where a master device controls a number of slave devices byissuing a COMMAND message and receiving the ACTUAL messages from the slavedevices. Synchronous COMMAND messages transmitted by the master device willoccur 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 thedevice will actuate based on this COMMAND at the next SYNC. Simple devicesoperating in the cyclic mode may therefore use the SYNC message as a trigger tooutput or actuate based upon their previous COMMAND.

Depending upon its capabilities, a device may also be parameterised with the timeperiod synchronous window length after the SYNC at which it is guaranteed that itsCOMMAND has arrived. It may therefore perform any processing on the COMMANDdata 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 tosample its feedback data and transmit an ACTUAL back to the master device as soonas possible afterwards.

Communication_Cycle_Period

SYNCMessage

Messages MessagesMessagesCommandMessages

SYNCMessage

CommandActual_ Actual_

Actuation based onCOMMAND at next SYNC

Samples taken at SYNCfor ACTUAL message

synchronous window length

Figure 6-1: Bus Synchronisation and Sampling/Actuation


6-2

6.2 Optional High Resolution Synchronisation Protocol

The standard synchronisation mechanism provides for a lean implementation. Thesynchronisation message carries no data and is easy to generate. However, the jitter ofthis SYNC depends on the bit rate of the bus as even the very high priority SYNC has towait 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 transmissionrates require more accurate synchronisation; it may be necessary to synchronise thelocal clocks with an accuracy in the order of microseconds. This is achieved by usingthe optional high resolution synchronisation protocol which employs a special form oftime 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 successfultransmission 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 transmissionsuccess 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 onereceived in the time-stamp message from the master. The difference between thesevalues determines the amount of time to adjust the local clock. With this protocol onlythe local latencies (t2-t1 on the master and t3-t1 on the slave ) are time critical. Theselatencies depend on local parameters (like interrupt processing times and hardwaredelays) on the nodes which have to be determined once. The accuracy of thisdetermination is implementation specific, it forms the limiting factor of thesynchronisation (or clock adjustment) accuracy. Note that each node only has to knowits own latency time as the time-stamp message contains the corrected value t1 andnot t2.

The time-stamp is encoded as unsigned32 with a resolution of 1 microsecond whichmeans that the time counter restarts every 72 minutes. It is configured by mapping thehigh resolution time-stamp (Object 1013h) into a PDO.

It is reasonable to repeat the clock adjustment only when the maximum drift of thelocal clock exceeds the synchronisation accuracy. For most implementations thismeans that it is sufficient to add this time-stamp message to the standard SYNC onceevery second.

This principle enables the best accuracy that can be achieved with bus-basedsynchronisation, 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).

master

slave

timet1 t2 t3 t4 t5

SYNC TIMESTAMP

Figure 6-2: Optional High Resolution Synchronisation Protocol

6.3 Other Synchronisation


6-3

The synchronisation mechanisms described in the preceding sections are mainlyoptimised for a synchronisation between a master and other devices. For specialapplications however, further synchronisation between (slave-) devices may be requiredas well. For instance, in order to allow multiple drive units to operate as an electronicgear, it may be necessary to configure one drive as the gearing master whichbroadcasts a master angle message to all slave drives at much shorter time intervalsthan the Communication Cycle. For these purposes, further synchronisation messagesmay be defined between any devices on the network. However, care should be takennot to increase the jitter of the SYNC when broadcast messages are to be transmitted athigher frequencies than the SYNC.

Pre-defined Communication Objects CANopen Communication Profile CiA

7-1

7 Pre-defined Communication ObjectsThere are three pre-defined Communication Objects. The implementation of theseobjects is optional.

7.1 The SYNC Object

7.1.1 SYNC Usage

The SYNC object is broadcasted periodically by the synchronisation device to al lapplication devices. This SYNC object provides the basic network clock. The timeperiod between the SYNC objects is specified by the standard parametercommunication cycle period, which may be written by a configuration tool to theapplication devices during the boot-up process. There can be a time jitter intransmission by the SYNC master corresponding approximately to the latency due tosome other message being transmitted just before the SYNC.

In order to guarantee timely access to the CAN bus the SYNC object is given a veryhigh priority identifier10. Devices which operate synchronously may use the SYNCobject to synchronise their own timing with that of the synchronisation device. Thedetails of this synchronisation are device dependent and do not fall within the scope ofthis document. Devices which require a more accurate common time base may usethe 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 thesynchronisation 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: according to the CMS naming conventions with<application-specific-name> = "SYNC000"

· user type: synchronisation master device: clientreceiving device: server

· class: Basic Variable

· priority: 0 (suggested)

· data type: NIL

· access type: Write_Only

· inhibit time: <communication period>

10 For the SYNC message identifier 128 in priority group 0 is suggested


7-2

7.1.3 SYNC Object Protocols

See specification of Basic Variable protocols /7/.

7.2 The Time Stamp Object

7.2.1 Time Stamp Object Usage

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

7.2.2 Time Stamp Object Services

The Time-Stamp object is implemented as CMS object of type Stored Event with thetransmitting 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: according to the CMS naming conventions with<application-specific-name> = "TIME000"

· user type: Time stamp provider: serverTime stamp consumers: clients

· class: Stored Event

· priority: 1 (suggested)

· data type: TIME-of-DAY12

· inhibit time: application specific

7.2.3 Time Stamp Object Protocols

See specification of the Stored Event protocols /7/.

11 For the Time Stamp message identifier 256 in priority group 1 is suggested.12 Additional Time Stamp messages with different data types (e.g. DATE) can be

defined by mapping the appropriate data types into standard PDOs.


7-3

7.3 The Emergency Object

7.3.1 Emergency Object Usage

Emergency messages are triggered by the occurrence of a device internal fatal errorsituation and are transmitted from the concerned application device to the otherdevices with highest priority. This makes them suitable for interrupt type error alerts13.

By means of CANopen Communication Profile defined emergency error codes (Table7-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) Meaning

00xx Error Reset or No Error

10xx Generic Error

20xx Current

21xx Current, device input side

22xx Current inside the device

23xx Current, device output side

30xx Voltage

31xx Mains Voltage

32xx Voltage inside the device

33xx Output Voltage

40xx Temperature

41xx Ambient Temperature

42xx Device Temperature

50xx Device Hardware

60xx Device Software

61xx Internal Software

62xx User Software

63xx Data Set

70xx Additional Modules

80xx Monitoring

81xx Communication

90xx External Error

F0xx Additional Functions

FFxx Device specific

Table 7-1: Emergency Error Code

13 An Emergency Telegram may be sent only once per 'error event', i.e. the emergencymessages must not be repeated. As long as no new errors occur on a device no furtheremergency messages must be sent.


7-4

The emergency object is optional. If a device supports the emergency object, it has tosupport 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 thetransitions emergency objects will be transmitted.

1. After initialisation the device enters the error free state if no error is detected. Noerror message is sent.

2. The device detects an internal error indicated in the first three bytes of theemergency message (error code and error register). The device enters the error state.An emergency object with the appropriate error code and error register istransmitted14. The error code is filled in at the location of object 1003H (pre-definederror field).

3. One, but not all error reasons are gone. An emergency message containing errorcode 0000 (Error reset) may be transmitted together with the remaining errors in theerror register and in the manufacturer specific error field.

4. A new error occurs on the device. The device remains in error state and transmits anemergency object with the appropriate error code. The new error code is filled in atthe top of the array of error codes. If one error is repaired the appropriate error codeis erased from the array. It has to be guaranteed that the error codes are sorted in atimely manner (oldest error - highest sub-index, see Object 1003H).

5. All errors are repaired. The device enters the error free state and transmits anemergency object with the error code Ôreset error / no error'.

0

1

2

3

4

error free

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 0 1 2 3 4 5 6 7

Content Emergency ErrorCode

(see Table 7-1)

Errorregister(Object1001H)

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-5

7.3.3 Emergency Object Services

The Emergency object is implemented as a CMS object of type Stored Event with thenotifying 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 <application-specific-name> = "EMCY000"

· user type: notifying device: server

other devices: clients

· class: Stored Event

· priority: 0 or 1 suggested

· data type: STRUCTURE OF UNSIGNED(16) emergency_error_code,UNSIGNED(8) error_register, ARRAY (5) of UNSIGNED(8)manufacturer_specific_error_field

· inhibit time: application specific

7.3.4 Protocols

See specification of the Stored Event protocols /7/.

Network Management and Identifier Distribution CANopen Communication Profile CiA

8-1

8 Network Management and Identifier Distribution

8.1 Services and Protocols

NMT services (/9/, /10/) provide a means for identification and monitoring of all nodesin the network. NMT requires one device in the network which fulfils the function of theNMT Master. NMT offers the following functionality groups:

· Module Control Services for initialisation of NMT Slaves that want to take part in thedistributed application

·

· Error Control Services for supervision of the nodes and networks communicationstatus

·

· Configuration Control Services for up- and downloading of configuration data fromrespectively to a module of the network.

A NMT Slave represents that part of a node which is responsible for the nodeÕs NMTfunctionality. 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, downloadconfiguration data if necessary, allow the DBT Slave to request COB-IDs via DBTservices and protocols (/11/, /12/) and enable or disable the CMS services at a certainnode or simultaneously at all nodes.

Error Control services are achieved principally through periodically transmitting of lifeguarding messages by the NMT Master. If a NMT Slave doesnÕt respond within adefined span of time or if the NMT SlaveÕs communication status has changed, theNMT Master informs its NMT Master Application about that event. Also if a NMT Slaveis not guarded within the nodeÕs life time, the NMT Slave informs its local Applicationabout that event.

The node initialisation process is controlled by a NMT Master Application during thenetwork boot-up process via NMT services according to /9/.

In addition to the node states of the state diagram specified in /9/, the CANopenCommunication 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 statediagram according to the CAL specification are described in detail, in Table 8-2 theadditional, profile specific transitions are described in detail.


8-2

Reset Com munication

Init

Pre-Operational

Disconnec ted

Operational

Initia lisation

power on

(10)

(11)

(12)

(0) (2)

(8)

(6)

(7)

(8)

(3)

(4)

(5)

(6) (7)

(6) (8)

CAL

Connecting

Prepar ing

Prepared

Reset A pplication

(0)

Figure 8-1: Extended NMT Node State Diagram

(0) Disconnect_Remote_Node indicationDisconnect_Node requestError response

(2) Delete_Node request (local service)(3) Connect_Node request(4) Connect_Remote_Node response(5) Prepare_Remote_Node response(6) Start_Remote_Node indication(7) Stop_Remote_Node indication(8) Enter_Pre-Operational_State indication(10) Reset_Node indication(11) Reset_Communication indication(12) Initialisation finished - enter Pre-Operational automatically


8-3

NMT Master

Directionof

telegramNMT Slave

(0) Disconnect_Node request

NMT local service request to setnode state to DISCONNECTED

(0) Disconnect_Remote_Noderequest

NMT service request to set the stateof the remote node object andremote node to DISCONNECTED

(0) Disconnect_Remote_Nodeindication

NMT service indication to set nodestate to DISCONNECTED

(0) Error confirmation

NMT service confirmationinforming NMT Master Applicationof an error (in response toConnect_Remote_Node orPrepare_Remote_Node request)

(0) Error response

NMT service response forcing nodeto set its state to DISCONNECTEDin response toConnect_Remote_Node orPrepare_Remote_Node indicationfrom NMT Master

(1) Add_Remote_Node request

NMT local service request to createremote node object

(1) Create_Node request

NMT local service request to createnode object

(2) Remove_Remote_Node request

NMT local service request to deleteremote node object

(2) Delete_Node request

NMT local service request to deletenode object

(3) Connect_Node request

NMT local service request to setnode state to CONNECTING

(3) Connect_Remote_Nodeconfirmation

Confirmation to the NMT MasterApplication that node state isCONNECTED (in response to aNMT MasterConnect_Remote_Node request)

(4) Connect_Remote_Noderesponse

NMT service response confirmingnode state as CONNECTING inresponse to a NMT MasterConnect_Remote_Node indication.After successful transmission of theresponse the NMT slave enters thenode state PREPARING

(4) Prepare_Remote_Nodeconfirmation

NMT service confirmationinforming NMT Master Applicationabout successful remote nodepreparing

(5) Prepare_Remote_Noderesponse

NMT service response confirmingthe end of node preparing inresponse to NMT MasterPrepare_Remote_Node indication

(5) Start_Remote_Node request

NMT service request to enablecommunication via PDOs andSDOs

(6) Start_Remote_Node indication

NMT service indication informingnode that communication via PDOsand SDOs is enabled

(6) Stop_Remote_Node request

NMT service request to disablecommunication

(7) Stop_Remote_Node indication

NMT service indication informingnode to disable communication

Table 8-1: State Transitions of the extended NMT Slave State Diagram according totheCAL specification


8-4

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

NMT Master

Directionoftelegram

NMT Slave

(8) Enter_Pre-Operational_Staterequest

NMT service allowing NMT Masterto enable SDOs

(8) Enter_Pre-Operational_Stateindication

NMT service informing NMT Slavethat SDOs are enabled

(9) Prepare_Remote_Node request

NMT service requesting NMT Slaveto request

COB-Identifiers for not allocatedPDOs

(9) Prepare_Remote_Nodeindication

NMT service informing NMT Slaveto request

COB-IDs for not allocated PDOs

(10) Reset_Node request

NMT service allowing NMT Masterto reset node applications

(10) Reset_Node indication

NMT service informing the NMTSlave(s) to reset local application

(11) Reset_Communicationrequest

NMT service allowing NMT Masterto reset communication parametersat the slave node(s)

(11) Reset_Communicationindication

NMT service informing the NMTSlave to reset the communicationparameters in the object dictionaryto default values

(12) Initialisation finished

The NMT Slave enters this stateautomatically after finishing theinitialisation tasks. This means thatevery reset request leads to thestate Pre-Operational.

(13, 14) Application orCommunication Reset performed

These state transitions areperformed automatically.

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

After its initialisation, the device enters the ãPre-OperationalÒ state autonomously. Inthis state, only communication via SDOs is operational, using the default COB-IDsderived from the module-ID. Configuration of PDOs, device parameters and also theallocation of application objects (PDO-mapping) may be performed by a configurationapplication.

Then the extended boot-up is started by disconnecting the node (Disconnect_Noderequest). Alternatively, the node may be switched into the operational stage directly bysending a Start_Remote_Node request (Minimum Boot-Up).

If a node is guarded via the node guarding protocol the state transferred from the slaveback to the NMT Master should be 127 (see /10/) if the NMT Slave is in Pre-Operationalstate.


8-5

With the introduction of the "initialisation" state a complete or a partial reset of a nodeis possible via the network. The ãinitialisationÒ state is divided into three sub-states (seeFigure 8-2).

1. Reset_Application: In this state the parameters of the manufacturer specific profilearea and in the standardised device profile area are set to their default values. Aftersetting of the power-on values the state Reset_Communication is entered.

2. Reset_Communication: In this state the parameters of the communication profilearea 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. Afterperforming the basic node initialisation in this state the state Pre-Operational isentered automatically.

Power-on values are the last stored parameters. If storing is not supported or has notbeen executed, the power-on values are the default values according to the CANopencommunication and device profiles.

Figure 8-2: Sub-states of the initialisation state

(1) Create_Node request

(2) Delete Node request


(11) Reset_Communication indication

(12) Initialisation finished - enter Pre-Operational automatically

(13) Application Reset performed

(14) Communication Reset performed

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

power-on

(11)

(10)

ResetApplication

ResetCommunication

(12)

13)

Init

(14)

(1) (2)


8-6

8.1.1 Enter_Pre-Operational_State Service and Protocol

With this service a NMT Slave may be forced into the Pre-Operational state.


Argument

Node-ID

All

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 theselected NMT Slave(s) from "prepared" or "operational" to "Pre-Operational". In thisstate a node can communicate only via its SDOs. Therefore the service may also beused 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.

Figure 8-3: Enter_Pre-Operational_State, Reset_Nodeand Reset_Communication protocols

· CS = 128: Enter_Pre-Operational_State ServiceCS = 129: Reset_Node ServiceCS = 130: Reset_Communication Service

· Node ID: Node-ID of the NMT Slave as assigned by the NMT Master in the Nodeconnect 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.

CS Node-ID

0 1

COB-ID = 0

NMT Slave(s)

Indication(s)

NMT Master

Request


8-7

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 l lnodes.


Argument

Node-ID

All

mandatory

selection

selection

The service will only be executed for the selected remote node objects independent ofthe state of the object. Through this service the NMT Master sets the state of theselected NMT Slave(s) from any state except DISCONNECTED to the "resetapplication" state. In this state a reset of the node application will be performed. Theparameters of the entire object dictionary are set to their power-on values.


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 parametersof a distinct or of all nodes.


Argument

Node-ID

All

mandatory

selection

selection

The service will only be executed for the selected remote node objects independent ofthe state of the object. Through this service the NMT Master sets the state of theselected NMT Slave(s) from any state except DISCONNECTED to the "resetcommunication" state. In this state the parameters of the communication area in theobject dictionary are set to their power-on values.


In Figure 8-3 the protocol of the Reset_Communication service is shown.


8-8

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.

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 enteredautomatically after power-on. In this state the devices are accessible via their Default-SDO using identifiers that have been assigned according to the Predefined ConnectionSet. In this step the configuration of device parameters takes place on all nodes whichsupport parameter configuration.

This is done from a Configuration Application (which can reside on the same node asthe NMT Master Application or from a Configuration Tool via the Default-SDO. Fordevices that support these features the selection and/or configuration of PDOs, themapping of application objects (PDO mapping), the configuration of additional SDOsand optionally the setting of COB-IDs may be performed via the Default-SDO objects.

Configuration of device parameters,Configuration of dynamically defined PDOs,

Mapping of application objects to PDOs(via Default SDO)

Execution ofDisconnect_Remote_Node Service

Identification of Network Configuration and Start of Node Guarding

Distribution of COB-IDs foradditional SDOs and configured PDOs

of all devices

(Optional)Start transmission of SYNC

Wait for synchronisation of devices


1

2

3

4

5

6


8-9

In step 2 the Disconnect_Remote_Node service is executed. By receiving the serviceindication the devices enter the node state Disconnected. After entering this state (andoptionally performing an additional local initialisation depending on the configuredparameters) the devices have to execute the local Connect_Node service for enteringthe node state Connecting.

During step 3 the NMT Master Application performs the identification of all nodes inthe network by repeated execution of the Connect_Remote_Node service. Within thisservice also the node guarding parameters are negotiated between NMT Master andNMT Slaves and node guarding is started.

In step 4 the assignment of COB-IDs to the configured PDOs and additional SDOs isperformed by the DBT (if COB-ID distribution shall be performed). The COB-IDs for thedefault-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 bythe SYNC object before entering the node state Operational in step 6. Thesynchronisation is done by starting the cyclic transmission of the SYNC object andwaiting 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 beenconfigured completely in a previous extended boot-up and have stored theirconfiguration, the minimum boot-up shown in Figure 8-5 can be applied.

The minimum boot-up has to be supported by all CANopen devices.

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 parametersconfigured in step A.

With step D all nodes are enabled to communicate via their PDO objects.

8.3 Minimum Capability Device

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


A

B

C

D


8-10

To enable devices which do not support the complete DBT- and NMT Slavefunctionality to co-operate with full capability devices, the following minimalcapabilities 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_Pre-Operational_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. Minimumcapability devices enter the Pre-Operational state directly after finishing the deviceinitialisation. 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 intothe Operational state. By switching a device into the Prepared16 state it is forced tostop the communication altogether (except node guarding, if active). Furthermore, thisstate can be used to achieve certain application behaviour. The definition of thisbehaviour falls into the scope of device profiles.

Pre-Operational

Operational

Initialisation

power on

(10)(11) (12)

(6)(7)

Prepared

(7)

(6)

(8)

(8)

Figure 8-6: State Diagram of a Minimum Capability Device

(6) Start_Remote_Node indication

(7) Stop_Remote_Node indication

(8) Enter_Pre-Operational_State indication


(11) Reset_Communication indication

(12) Initialisation finished - enter Pre-Operationalautomatically

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_Nodeindication.


8-11

8.4 Allocation of COB-ID's and Inhibit-Times

As CAN is a communication object (COB-) based network where each communicationobject has an associated identifier which specifies its priority implicitly, the allocationof identifiers to the COB's is an essential issue in the system design. Inhibit-times aredefined 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-timespecifies 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 distributedto the devices either statically or dynamically.

Static distribution means that the identifiers and inhibit-times are fixed by the modulesuppliers and may be changed by the system integrator through module specific meanssuch as setting dip-switches, adapting firmware, etc.

Dynamic distribution means that the identifiers and inhibit-times are distributed via theCAN network through standard DBT services and protocols or via SDO. The dynamicdistribution is the preferred method in the CANopen Communication Profile.

Some identifiers (1-7, 1740-1760dec) have been reserved by CANopen for futureenhancements of the communication profile. They may still be used in applicationsemploying 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 identifierallocation scheme is defined. These identifiers are available in the Pre-Operationalstate directly after initialisation (if no modifications have been stored) and may bemodified by means of dynamic distribution. A device has to provide the correspondingidentifiers 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 distinguishbetween devices of the same functionality. The ID-allocation scheme corresponds to apre-defined master/slave connection set and allows a peer-to-peer communicationbetween a single master device and up to 127 slave devices. It also supports thebroadcasting of non-confirmed NMT-services, SYNC- and Time-Stamp-objects andnode guarding. Broadcasting is indicated by a module-Id of zero.

The pre-defined master/slave connection set supports one emergency object, oneSDO, at maximum 2 Receive-PDOs and 2 Transmit-PDOs and the node guardingobject.

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

FunctionC d

Module-ID

Bit-Nr.:COB-Identifier

10 0


8-12

Table 8-3 and Table 8-4 show the supported objects and their allocated COB-IDs.

object functioncode (binary)

resulting COB-ID CommunicationParameters at

Index

CMSprioritygroup

NMT 0000 0 - 0

SYNC 0001 128 (1005h) 0

TIME STAMP 0010 256 - 1

Table 8-3: Broadcast Objects of the Pre-defined Master/Slave Connection Set

object functioncode (binary)

resulting COB-IDs CommunicationParameters at

Index

CMSprioritygroup

EMERGENCY 0001 129 - 255 - 0 , 1

PDO1 (tx) 0011 385 - 511 1800h 1 , 2

PDO1 (rx) 0100 513 - 639 1400h 2

PDO 2 (tx) 0101 641 - 767 1801h 2 , 3

PDO2 (rx) 0110 769 - 895 1401h 3 , 4

SDO (tx) 1011 1409 - 1535 6

SDO (rx) 1100 1537 - 1663 6 , 7

Nodeguard 1110 1793-1919 (100Eh) -

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 isnecessary to reserve the corresponding default-COB-IDs in the DBT data base bypredefinitions during the boot-up process. If the default ID-allocation is overwritten by aconfiguration tool, the corresponding predefinitions should be deleted in the COB database.

8.4.2 Dynamic Distribution

CAN Application Layer (CAL) uses a CMS priority level model (see /11/). It describes 8priority levels with 220 identifiers each and comprises the identifiers 1 to 1760. Theremaining identifiers (0, 1761-2031) are reserved for network control by NMT, DBT andLMT.

The first step in the system design is to allocate the appropriate priority levels to thevarious communication objects. As CANopen devices feature a default identifierallocation for a basic set of communication objects, one can start from there andmodify the allocation if necessary using either SDO services or DBT (if the extendedboot-up is supported).

In order to guarantee a minimum jitter the synchronisation message (SYNC) has thehighest priority of all messages that occur in normal operation.

For transmitting emergency messages each node in the network must be able to usemessages with the highest available priority. For these exceptional messages a numberof identifiers in priority level 0 and 1 have been reserved.

The time stamp messages have been allocated to priority level 1, with lower prioritythan the emergency messages . The remaining identifiers above the PDOs are reservedfor other synchronisation purposes.

17 The table has to be seen from the devices point of view.


8-13

The CANopen Communication Profile describes two different PDO modes (see chapter5). One is used for synchronous data exchange and the other one for asynchronousmessage transfer. To guarantee the cyclic behaviour of the system data exchange ahigher priority (suggested: level 2) is allocated to the synchronous PDO's than to theasynchronous 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 guardingcapability. For that purpose a range of 255 identifiers have been reserved starting at1761.

CMS priority level message / object

0 (Id 1 - 220) - Synchronisation

- Emergency (fault)

1 (Id 221 - 440) - Emergency (fault)

- Network timing (SYNC, time stamp)

- other high priority sync. Messages

2 (Id 441 - 660) - PDO (synchronous)

3 (Id 661 - 880)

4 (Id 881 - 1100)

5 (Id 1101 - 1320)

- PDO (asynchronous)

6 (Id 1321 - 1540) - SDO's

7 (Id 1541 - 1760) reserved for SDO's

Table 8-5: Suggested Message Priorities


8-14

8.4.3 Naming Conventions

CMS Naming Conventions

The CMS Naming Conventions of the CAN Application Layer define a syntax to createthe names of CMS objects and COB's. The dynamic distribution of COB-ID's is basedon 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 CANopenCommunication Profile is modelled by this particular CMS object.

Abbreviation part of communication profile

SYNC SYNC message

TIME time stamp message

EMCY emergency message

SDO_ service data object (SDO)

TPDO or RPDO 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 isused. 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 forthe needed PDO's.

18 For instance '401' is used for the I/O modulesÕ profile.

Error Handling CANopen Communication Profile CiA

9-1

9 Error HandlingAll types of errors detectable by the devices in an industrial system can be grouped intothe five classes shown below:

· Bus errors - usually electrical and wiring faults.

· Communications or protocol errors - for example, a specific bit in a telegram is notset as expected.

· Life guarding errors - life guarding telegrams have not been received by a devicewithin 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 CANspecification. 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 nodeguarding mechanism.

Protocol Errors - Such errors can occur for example during domain downloads. Atypical response to this kind of error would be to signal failure via the appropriateprotocol (e.g. initiating the abort of a domain transfer) and ignoring the contents of thepartially received information. The device would still maintain its current state ofreadiness i.e. remain operational.

Life guarding Errors - are dependent upon what type of life guarding is supported by adevice. If the device possesses full NMT life guarding the error mechanism depends onwhether the NMT Master detects a time out receiving a response from the device to alife guarding telegram or whether the module itself detects a time out because no lifeguarding telegram has been received from the NMT Master within its defined time outperiod. In the first case, it should be tried to shut-down all devices in the network andthen perform a warm-start. In the second case, the device would assume that the NMTMaster is not operational and must indicate this to its application19.

Application Errors - Such errors could occur, for example, in a Programmable LogicController (PLC) if an application program tried to access an output signal which didnot exist. A typical response would be to indicate to the application that an error hadoccurred and send an emergency telegram.

Device Failures - Such errors could occur, for example, in a Drive Unit when thetemperature of power components exceeds a critical limit. To allow the response tosuch cases to be application dependent such an error would result in the transmissionof an emergency telegram. A time-out period would be initiated and if the device didnot get any response within the device dependent time limit the device would take itsown 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.

Error Handling CANopen Communication Profile CiA

9-2

9.1 Node Guarding / Life Guarding

The communication interface of a particular device is assumed to be in a certain statein order to be able to process these messages correctly. However there could occurlocal events on a device that force it to a different state than was assumed by thetransmitter of a message. Especially, it could happen that due to an error a particulardevice goes to the Disconnected State and does no longer take part on the buscommunication.

To detect these errors with devices that do not transmit PDO's regularly, the NMTMaster manages a network database where, besides other information, the expectedstates of all connected devices are recorded. The NMT Master regularly retrieves theactual states of all devices on the network and compares them to the states recorded inthe network database. Mismatches are indicated first locally on the NMT Masterthrough the Network Event service. Consequently the application must takeappropriate 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 andthen perform a new boot-up sequence.

Node Guarding is optional. It starts for the slave when the first remote-transmit-requestfor 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 itsobject dictionary (either default values or modified at any stage). If guard time and lifetime 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 distributesnode-guarding identifiers starting from 1793dec, as this enables him to include verysimple devices in the network without readjustments.

With devices which are configured to use a PDO on a cyclic basis the application maybe able to detect fatal errors by means of missing telegrams. These devices do nothave to support guarding services. Whether or not a device needs to be guarded canbe 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 networkinterfaces of devices. However, it cannot detect failures within the device itself. Forinstance, the temperature of some power components on a device could exceed acritical limit whereas the network interface could still be in good working condition. Fornotification of this type of errors emergency telegrams have been introduced (seechapter 7.3).

Dictionary Structure and EntriesCANopen Communication Profile CiA

10-1

10 Dictionary Structure and EntriesThis section details the Object Dictionary structure and entries which are common toall 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 Indexcolumn denotes the objects position within the object dictionary. This acts as a kind ofaddress to reference the desired data field. The sub-index is not specified here. Thesub-index is used to reference data fields within a complex object such as an array orrecord.

The Object column contains the Object Name according to the table below and isused to denote what kind of object is at that particular index within the objectdictionary. The following definitions are used:

Object Name Comments ObjectCode

NULL A dictionary entry with no datafields

0

DOMAIN Large variable amount of data e.g.executable program code

2

DEFTYPE Denotes a type definition such as aBoolean, unsigned16, float and soon

5

DEFSTRUCT Defines a new record type e.g. thePDOMapping structure at 21 Hex

6

VAR A single value such as anunsigned8, Boolean, float,integer16, visible string etc.

7

ARRAY A multiple data field object whereeach data field is a simple variableof the SAME basic data type e.g.array of unsigned16 etc.

8

RECORD A multiple data field object wherethe data fields may be anycombination of simple variables

9

Table 10-2: Object Dictionary Object Definitions

The name column provides a simple textual description of the function of thatparticular 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, time-difference and domain (see /8/). It also includes the pre-defined complex data typePDOMapping and may also include others which are either manufacturer or devicespecific. 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 sub-index is used to reference one data field within the object. Note that sub-index 0contains the number of elements and therefore itself is not part of the array.


10-2

It can be of the following:

Attribute Description

rw read and write access

wo write only access

ro read only access

const read only access, value isconstant

Table 10-3: Access Attributes for Data Objects

The M/O column defines whether the object is Mandatory or Optional. A mandatoryobject must be implemented on a device. An optional object need not beimplemented 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 predefinedcomplex data types. The range of indices from 23-3FH is not defined yet but reservedfor 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 CANopenCommunication Profile. The range 1000H-1FFFH contains the communicationspecific object dictionary entries defined by the CANopen Communication Profile.

These parameters are called communication entries, their specification is common toall device types, regardless of the device profile they use. The objects in range 1000H-1FFFH not specified by this communication profile are reserved for further use. Therange 2000H-5FFFH is free for manufacturer specific profile definition.

The range 6000H-FFFH contains the standardised device profile parameters.


10-3

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 theappropriate space in the PDO as not being used by this device (donÕt care). Anexample mapping can be found in the appendix.

The order of the data types is as follows:

Index Object Name

0001 DEFTYPE Boolean

0002 DEFTYPE Integer8



0005 DEFTYPE Unsigned8



0008 DEFTYPE Floating Point (Float)

0009 DEFTYPE Visible String

000A DEFTYPE Octet String

000B DEFTYPE Date

000C DEFTYPE Time Of Day

000D DEFTYPE Time Difference

000E DEFTYPE Bit String

000F DEFTYPE Domain

0010-001F

Null Objects (reserved)

0020 DEFSTRUCT PDO CommPar

0021 DEFSTRUCT PDO Mapping

0022 DEFSTRUCT SDO Parameter

0023-003F

Null Objects (reserved)

0040-005F

DEFTYPE Manufacturer Specific Data Types

0060-007F

DEFTYPE Device Profile Specific Standard DataTypes

0080-009F

DEFSTRUCT Device Profile Specific Complex DataTypes

Table 10-4: Object Dictionary Data Types

The data type representations used are detailed in /8/ . Every device does not need tosupport all the defined data types. A device only has to support the data-types it useswith the objects in the range 1000H-9FFFH.

The predefined complex data-types are placed after the standard data-types. Threetypes are defined at present, the PDO Communication Parameter (PDO CommPar) thePDO Mapping record and the SDO Parameter record (SDO_Par). They are placed atindex 20H, 21H and 22H.


10-4

A device may optionally provide the length of the standard data types encoded asUnsigned32 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 ofthat data type at read access to the corresponding index. Sub-index 0 then providesthe number of entries at this index (not counting sub-indices 0 and 255), and thefollowing sub-indices contain the data type according to table 10-4 encoded asUnsigned8. The entry at Index 20h describing the structure of the PDOCommunication Parameter then looks as follows (see also 10.1.2):

Subindex Value (Description)

0h 04h (4 subindices follow)

1h 07h (Unsigned32)

2h 05h (Unsigned8)

3h 06h (Unsigned16)

4h 05h (Unsigned8)

Standard (simple) and complex manufacturer specific data types can be distinguishedby attempting to read sub-index 1h: At a complex data type the device returns a valueand sub-index 0h contains the number of sub-indices that follow, at a standard datatype the device aborts the domain transfer as no sub-index 1h available. In that casesub-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 0describes the number of entries (sub-indices) that follow (not counting sub-indices 0and FFh). The number of entries is encoded as Unsigned8.

Sub-index FFh (255dec) describes the structure of the entry by providing the data typeand the object type of the entry. It is encoded as Unsigned32 and organised as follows:

MSB LSB

bits 31-16 15-8 7-0

value reserved (value: 00 00h) Data Type

(see Table 10-4)

Object

(see Table 10-2)

encodedas

- Unsigned8 Unsigned8

It is optional to support Sub-Index FFh. If it is supported throughout the objectdictionary and the structure of the complex data tapes is provided as well, it enablesone to upload the entire structure of the object dictionary.

As Sub-index has the same structure and meaning throughout the object dictionary, i tis not described at each detailed object description (Chapter 10.3).


10-5

10.1.2 PDO Communication Parameter

The format of the structure is as follows:

Index Sub-Index Field In PDO Communication Record Data Type

0020H 0H number of supported entries in the record Unsigned8

1H COB-ID used by PDO Unsigned32

2H transmission type Unsigned8

3H inhibit time Unsigned16

4H CMS priority group Unsigned8

Table 10-5: PDO Communication Parameter Record

If the device supports the identifier distribution via DBT the value on sub-index 0H is 4otherwise it is 2 (inhibit time not supported) or 3. The COB-ID at Index 20H, Sub-Index1H 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 beinterpreted as defined in Figure 10-1 and Table 10-6.

Unsigned32

MSB LSB

bits 31 30 29 28-11 10-0

11-bit-ID 0/1 0/1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00

11-bit Identifier

29-bit-ID 0/1 0/1 1 29-bit Identifier

Figure 10-1: Structure of PDO COB-ID entry


31 (MSB) 0 PDO valid

1 PDO not valid

30 0 RTR allowed on this PDO

1 no RTR allowed on this PDO

29 0 11-bit ID (CAN 2.0A)


28 - 11 0 if bit 29=0



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 hardwarerestrictions. In that case no error is signalled on the attempt to change them.


10-6

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

transmission type PDO transmission

cycl ic

acyclic

synchronous

asynchronous RTR only

0 X X

1-240 X X

241-251 - reserved -

252 X X

253 X X

25421 X

25522 X

Table 10-7: Description of transmission type

Synchronous (transmission types 0-240 and 252) means that the transmission of thePDO shall be related to the SYNC object as described in chapter 6.1. Preferably thedevices use the SYNC as a trigger to output or actuate based on the previoussynchronous Receive-PDO respectively to update the data transmitted at the followingsynchronous Transmit-PDO. Details of this mechanism depend on the device type andare defined in the device profile if applicable.

Asynchronous means that the transmission of the PDO is not related to the SYNCobject.

A transmission type of zero means that the message shall be transmitted synchronouslywith the SYNC object but not periodically.

A value between 1 and 240 means that the PDO is transmitted synchronously andcyclically, the transmission type indicating the number of SYNC objects between twoPDO transmissions.

The transmission types 252 and 253 mean that the PDO is an event without immediatenotification and is only transmitted on remote transmission request. At transmission type252, 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 remotetransmission 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, theapplication event is defined in the device profile.

Sub-index 3H contains the inhibit time as specified in /11/. If the inhibit time feature isnot 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 devicerequests for this PDO if DBT services are executed. Devices that do not support DBT donot need to support this entry (value at sub-index 0H is set to 3H). The value range is0...7.

21 The transmission of this PDO is initiated by an event on the device. The event is

manufacturer specific.22 The transmission of this PDO is initiated by an event on the device. This event

must be defined in the device profile.


10-7

10.1.3 PDO Mapping

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

Figure 10-2 : Principle of PDOMapping

The PDOMapping is structured as follows:

Index Sub-Index Field in PDOMapping Record Data Type

0021H 0H number of mapped objects in PDO Unsigned8

1H 1st object to be mapped Unsigned32

2H 2nd object to be mapped Unsigned32

: : : : ::

: : : : : : : : : : : : : : : : : : : :

40H 64th object to be mapped Unsigned32

Table 10-8: PDO Mapping

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

Byte: MSB LSB

index (16 bit) sub-index (8 bit) object length (8bit)

Figure 10-3: Structure of PDO Mapping Entry

Object dictionary

xxxxh xxh Application Object1

yyyyh yyh Application Object2

zzzzh zzh Application Object3

PDOMapping

0 31 yyyyh yyh 8

2 zzzzh zzh 16

3 xxxxh xxh 8

PDO: Appl. Obj. 2 Application Object 3 Appl. Obj. 1


10-8

The object length is encoded as unsigned8 with a value range of 1...64. Thisparameter 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 isexceeded or the SDO client attempts to map an object that cannot be mapped) thedevice 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 by8 objects of data type Unsigned8, first an ã8Ò is written to sub-index 8, thus setting validonly the first 8 objects. These can then be re-mapped without immediately exceedingthe length of the PDO.

If data types (Index 1-7h) are mapped they serve as ãdummy entriesÒ. Thecorresponding data in the PDO is not evaluated by the device. This optional feature isuseful e.g. to transmit data to several devices using one PDO, each device onlyutilising a part of the PDO.

A device that supports dynamic mapping of PDOs must support this during the Pre-Operational state. If dynamic mapping during the Operational state is supported, theSDO 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 isintroduced. The data type has the index 22h in the object dictionary. The object isstructured as follows:

Index Sub-Index Field in SDOParameter Record Data Type

0022H 0H number of supported entries Unsigned8

1H COB-ID client -> server Unsigned32

2H COB-ID server -> client Unsigned32

3H node ID of SDOÕs client resp. server Unsigned8

Table 10-9: SDO Parameter Record

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 extendedidentifiers is possible (if DBT is not used). Subindex 3 gives the server of the SDO incase the record describes an SDO for which the device is client and gives the client ofthe 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 thenode id of the SDO server). If the device is the server of the SDO the sub-index 3H isoptional.

Unsigned32

MSB LSB

bits 31 30 29 28-11 10-0

11-bit-ID 0/1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00

11-bit Identifier

29-bit-ID 0/1 0 1 29-bit Identifier

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


10-9


10-10


31 (MSB) 0 SDO valid

1 SDO not valid

30 0 reserved (always 0)

29 0 11-bit ID (CAN 2.0A)


28 - 11 0 if bit 29=0



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 (notchangeable) 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 thecommunication profile:

Index

(hex)

Object

(SymbolicName)

Name Type Acc.23

M/O

1000 VAR device type Unsigned32 ro M

1001 VAR error register Unsigned8 ro M

1002 VAR manufacturer status register Unsigned32 ro O

1003 ARRAY pre-defined error field Unsigned32 ro O

1004 ARRAY number of PDOs supported Unsigned32 ro O

1005 VAR COB-ID SYNC-message Unsigned32 rw O

1006 VAR communication cycle period Unsigned32 rw O

1007 VAR synchronous window length Unsigned32 rw O

1008 VAR manufacturer device name Vis-String ro O

1009 VAR manufacturer hardwareversion

Vis-String ro O

100A VAR manufacturer software version Vis-String ro O

100B VAR Node-ID Unsigned32 ro O

100C VAR guard time Unsigned32 rw O

100D VAR life time factor Unsigned32 rw O

100E VAR COB-ID guarding protocol Unsigned32 rw O

100F VAR number of SDOs supported Unsigned32 ro O

1010 VAR store parameters Unsigned32 rw O

1011 VAR restore default parameters Unsigned32 rw O

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

specification.


10-11

1012 VAR COB-ID time stamp Unsigned32 rw O

1013 VAR high resolution time stamp Unsigned32 rw O

1014 VAR COB-ID Emergency Unsigned32 rw O

1015 reserved

::::: ::::: ::::: ::::: ::::: :::::

11FF reserved

Server SDO Parameter (22H)

1200 RECORD 1st Server SDO parameter SDOParameter ro O

1201 RECORD 2nd Server SDO parameter SDOParameter rw O

::::: ::::: ::::: ::::: ::::: :::::

127F RECORD 128th Server SDO parameter SDOParameter rw O

Client SDO Parameter (22H)

1280 RECORD 1st Client SDO parameter SDOParameter rw O

1281 RECORD 2nd Client SDO parameter SDOParameter rw O

::::: ::::: ::::: ::::: ::::: :::::

12FF RECORD 128th Server SDO parameter SDOParameter rw O

1300 reserved

::::: ::::: ::::: ::::: ::::: :::::

13FF reserved

Receive PDO Communication Parameter (20H)

1400 RECORD 1st receive PDO Parameter PDOCommPar rw M/O*

1401 RECORD 2nd receive PDO Parameter PDOCommPar M/O*

::::: ::::: ::::: ::::: ::::: :::::

15FF RECORD 512th receive PDO Parameter PDOCommPar rw M/O*

Receive PDO Mapping Parameter (21H)

1600 ARRAY 1st receive PDO mapping PDOMapping rw M/O*

1601 ARRAY 2nd receive PDO mapping PDOMapping rw M/O*

::::: ::::: ::::: ::::: ::::: :::::

17FF ARRAY 512th receive PDO mapping PDOMapping rw M/O*

Transmit PDO Communication Parameter (20H)

1800 RECORD 1st transmit PDO Parameter PDOCommPar rw M/O*

1801 RECORD 2nd transmit PDO Parameter PDOCommPar rw M/O*

::::: ::::: ::::: ::::: ::::: ::::

19FF RECORD 512th transmit PDO Parameter PDOCommPar rw M/OO

Transmit PDO Mapping Parameter (21H)

1A00 ARRAY 1st transmit PDO mapping PDOMapping rw M/O*

1A01 ARRAY 2nd transmit PDO mapping PDOMapping rw M/O*

::::: ::::: ::::: ::::: ::::: :::::

1BFF ARRAY 512th transmit PDO mapping PDOMapping rw M/O*

* If a device supports PDOs, the according PDO communication parameter and PDOmapping entries in the object dictionary are mandatory. These may be read_only.

Table 10-11: Standard Objects


10-12

10.2 Detailed Object Specification

So far, parts of the object dictionary have been illustrated in tabular form. All deviceprofiles should contain a full object dictionary definition in this format. However thisprovides only an overall description of a moduleÕs capabilities. Each object dictionaryentry needs to be specified precisely.

Every object dictionary entry must be described in the following manner:

OBJECT DESCRIPTION

INDEX Profile Index Number e.g. 6059H

Name Name of parameter e.g. 'Frequency-Motor-Min-Max'

Object Code Variable classification e.g. 8H (=Array)

Number OfElements

not counting sub-indices 0h (contains no. of elements) andFFh (contains data type), e.g. 4H = 4 elements (this field isused only if object is not a simple variable)

Data Type 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 betterreadability, the Object Description should contain the symbolic Object Name ratherthan the numeric Object Code, e.g. ARRAY instead of 8H.

VALUE DESCRIPTION

Sub-Index number of sub-index being described (field only used for arrays& records)

Description Description of the functionality of the entry.

Object Class Optional Or Mandatory

Access Read Only (ro) or Read/Write (rw) or Write Only (wo)

PDO Mapping 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 deviceprofile)

No: Object must not be mapped into a PDO

Value Range size of data e.g. Unsigned32

MandatoryRange

(No) not applicable or range defined as a min & max. valuee.g. -50 to +200

Default Value (No) not applicable or default value of an object after deviceinitialisation

Table 10-13: Object Value Description Format

For simple variables the value description appears once without the sub-index field. Forarrays or records the value description must be defined for each element (sub-index).


10-13

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 thetype of device and its functionality. It is composed of a 16bit field which describes thedevice profile that is used and a second 16bit field which gives additional informationabout optional functionality of the device. The Additional Information parameter maybe device specific. Its specification does not fall within the scope of this document, i tis defined in the appropriate device profile.

OBJECT DESCRIPTION

INDEX 1000H

Name device type

Object Code VAR

Data Type Unsigned32

VALUE DESCRIPTION

Object Class Mandatory

Access ro

PDO Mapping No

Value Range Unsigned32

Mandatory Range No

Default Value No

Byte: MSB LSB

Additional Information Device Profile Number

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 thisbyte.

OBJECT DESCRIPTION

INDEX 1001H

Name error register

Object Code VAR

Data Type Unsigned8

VALUE DESCRIPTION


Access ro



Mandatory Range No

Default Value No


10-14

Bit M/O Meaning

0 M generic error

1 O current

2 O voltage

3 O temperature

4 O communication error (overrun, error state)

5 O device profile specific

6 O reserved

7 O 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 tobe signalled is the generic error.

Object 1002H: Manufacturer Status Register

This object is a common status register for manufacturer specific purposes. In thisdocument only the size and the location of this object is defined.

OBJECT DESCRIPTION

INDEX 1002H

Name manufacturer status register

Object Code VAR


VALUE DESCRIPTION

Object Class Optional

Access ro



Mandatory Range No

Default Value No


10-15

Object 1003H: Pre-defined Error Field

The object at index 1003H holds the errors that have occurred on the device and havebeen 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 inthe 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 devicespecific. The error code is contained in the lower 2 bytes (LSB) and the additionalinformation is included in the upper 2 bytes (MSB). If this object is supported it mustconsist of two entries at least. The length entry on sub-index 0H and at least oneerror entry at sub-index 1H.

Byte: MSB LSB

Additional Information Error code

Figure 10-6: Structure of the pre-defined error field

OBJECT DESCRIPTION

INDEX 1003H

Name pre-defined error field

Object Code ARRAY

Number of Elements 1(Mandatory), 2-254 (Optional)


VALUE DESCRIPTION

Sub-Index 0H

Description number of errorsObject Class MandatoryAccess rwPDO Mapping NoValue Range Unsigned8Mandatory Range 1Default Value No

Sub-Index 1H

Description standard error fieldObject Class MandatoryAccess roPDO Mapping NoValue Range Unsigned32Mandatory Range NoDefault Value No


10-16

Sub-Index 2H

Description standard error fieldObject Class OptionalAccess roPDO Mapping NoValue Range Unsigned32Mandatory Range NoDefault Value No

to

Sub-Index FEH

Description standard error fieldObject Class OptionalAccess roPDO Mapping NoValue Range Unsigned32Mandatory Range NoDefault Value No

Object 1004H: Number of PDOs supported

Index 1004H contains information about the maximum number of PDOs supported bythe device. It is distinguished between input and output PDOs and betweensynchronous and asynchronous transmission. Sub-index 0 describes the overall numberof PDOs supported (Synchronous and Asynchronous)24. Sub-index 1 describes thenumber of synchronous PDOs that is supported by the device, sub-index 2 the numberof 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 1004H

Name number of PDOs supported

Object Code ARRAY

Number of Elements 2


24 A device may support a fixed number of PDOs, each of which may either be of

synchronous and asynchronous transmission type.


10-17

VALUE DESCRIPTION

Sub-Index 0H

Description number of PDOs supported


Access ro

PDO Mapping No

Value Range unsigned32

Mandatory Range 0H - 1FF01FFH

Default Value No

Sub-Index 1H

Description number of synchronous PDOs


Access ro

PDO Mapping No



Default Value No

Sub-Index 2H

Description number of asynchronous PDOs


Access ro

PDO Mapping No



Default Value No

Sub-index MSB LSB

0 No. of Receive PDOs supported No. of Transmit PDOs supported

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

2 No. of asynchronous ReceivePDOs

No. of asynchronous Transmit PDOs

Figure 10-7: Structure of entry 1004H


10-18

Object 1005H: COB-ID SYNC message

Index 1005H defines the COB-ID of the Synchronisation Object (SYNC). Further, i tdefines whether the device consumes the SYNC or whether the device generates theSYNC. The structure of this object is shown in Figure 10-8 and Table 10-15. Thedefault value for the SNYC COB-ID is given in chapter 7.1.

OBJECT DESCRIPTION

INDEX 1005H

Name COB-ID SYNC message

Object Code VAR


VALUE DESCRIPTION


Access rw

PDO Mapping No


Mandatory Range No

Default Value 80h

Unsigned32

MSB LSB

bits 31 30 29 28-11 10-0

11-bit-ID 0/1 0/1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00

11-bit Identifier

29-bit-ID 0/1 0/1 1 29 -bit Identifier

Figure 10-8: Structure of SYNC COB-ID entry


31 (MSB) 0 Device does not consume SYNC message

1 Device consumes SYNC message

30 0 Device does not generate SYNC message

1 Device generates SYNC message

29 0 11-bit ID (CAN 2.0A)


28 - 11 0 if bit 29=0

X if bit 29=1: bits 28-11 of 29-bit-SYNC-COB-ID

10-0 (LSB) X bits 10-0 of SYNC-COB-ID

Table 10-15: Description of SYNC COB-ID entry

Bit 29 may be static (not changeable) e.g. due to hardware restrictions.


10-19

Object 1006H: Communication Cycle Period

This object defines the communication cycle period in msec. 0 if not used.

OBJECT DESCRIPTION

INDEX 1006H

Name communication cycle period

Object Code VAR


VALUE DESCRIPTION


Access rw

PDO Mapping No


Mandatory Range No

Default Value 00Õ00Õ00Õ00h

Object 1007H: Synchronous Window Length

Contains the length of the time window for synchronous messages in msec. 0 if notused.

OBJECT DESCRIPTION

INDEX 1007H

Name synchronous window length

Object Code VAR


VALUE DESCRIPTION


Access rw

PDO Mapping No


Mandatory Range No



10-20

Object 1008H: Manufacturer Device Name

Contains the manufacturer device name.

OBJECT DESCRIPTION

INDEX 1008H

Name manufacturer device name

Object Code VAR


VALUE DESCRIPTION


Access ro

PDO Mapping No

Value Range No

Mandatory Range No

Default Value No

Object 1009H: Manufacturer Hardware Version

Contains the manufacturer hardware version description.

OBJECT DESCRIPTION

INDEX 1009H

Name manufacturer hardware version

Object Code VAR


VALUE DESCRIPTION


Access ro

PDO Mapping No

Value Range No

Mandatory Range No

Default Value No


10-21

Object 100AH: Manufacturer Software Version

Contains the manufacturer software version description.

OBJECT DESCRIPTION

INDEX 100AH

Name manufacturer software version

Object Code VAR


VALUE DESCRIPTION


Access ro

PDO Mapping No

Value Range No

Mandatory Range No

Default Value No

Object 100BH: Node-ID

The object at Index 100BH contains the Node-ID. The node ID entry has the accesstype "read only" as it can not be changed using SDO services. However, it is feasible tochange it via LMT (see /14/), via hardware (e.g. dip-switch).

OBJECT DESCRIPTION

INDEX 100BH

Name Node-ID

Object Code VAR


VALUE DESCRIPTION


Access ro

PDO Mapping No

Value Range 1 - 256

Mandatory Range 1 - 127

Default Value No

MSB LSB

Reserved Reserved Reserved Node -ID

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


10-22

Object 100CH: Guard Time

The objects at index 100CH and 100DH include the guard time in milli-seconds andthe life time factor. The life time factor multiplied with the guard time gives the lifetime for the Node Guarding Protocol (see /10/).

OBJECT DESCRIPTION

INDEX 100CH

Name guard time

Object Code VAR


VALUE DESCRIPTION


Access rw

PDO Mapping No


Mandatory Range No

Default Value 0h

Object 100DH: Life Time Factor

The life time factor multiplied with the guard time gives the life time for the nodeguarding protocol (see /10/).

OBJECT DESCRIPTION

INDEX 100DH

Name life time factor

Object Code VAR

Data Type Unsigned8

VALUE DESCRIPTION


Access rw

PDO Mapping No


Mandatory Range No

Default Value 0h


10-23

Object 100EH: Node Guarding Identifier

The identifier used for node guarding and life guarding procedure (see chapter 9.1)

OBJECT DESCRIPTION

INDEX 100EH

Name node guarding identifier

Object Code VAR


VALUE DESCRIPTION


Access rw

PDO Mapping No


Mandatory Range No

Default Value 700h + node-ID

Unsigned32

MSB LSB

bits 31 30 29 28-11 10-0

11-bit-ID reserved 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00

11-bit Identifier

29-bit-ID reserved 1 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 isdescribed in this object. This entry shows all available SDOs including the defaultSDO. The object is composed of a 16bit field which describes the number of ClientSDOs and a 16bit field which describes the number of Server SDOs.

OBJECT DESCRIPTION

INDEX 100FH

Name number of SDOs supported

Object Code VAR



10-24

VALUE DESCRIPTION


Access ro

PDO Mapping No


Mandatory Range 1h-80h (server), 0-80h (client)

Default Value No

Byte: MSB LSB

number of client SDOs number of 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 accessthe device provides information about its saving capabilities. Several parameter groupsare 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 - 1FFFhmanufacturer specific communication parameters).

Sub-Index 3 refers to application related parameters (Index 6000h - 9FFFhmanufacturer 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 aspecific signature is written to the appropriate Sub-Index. The signature is ãsaveÒ.

Signature MSB LSBASCII e v a shex 65h 76h 61h 73h

Figure 10-12: Storage write access signature

On reception of the correct signature in the appropriate Sub-Index the device storesthe parameter and then confirms the SDO transmission (initiate download response). Ifthe storing failed, the device responds with abort domain transfer, error class 6h, errorcode 6h (hardware fault).

If a wrong signature is written, the device refuses to store and responds with abortdomain transfer, error class 8h, error code 0h (other error).

On read access to the appropriate Sub-Index the device provides information about itsstorage functionality with the following format:


10-25

Unsigned32

MSB LSB

bits 31-2 1 0

reserved (=0) 0/1 0/1

Figure 10-13: Storage read access structure


31-2 0 reserved

1 0 Device does not save parametersautonomously

1 Device saves parameters autonomously

0 0 Device does not save parameters on command

1 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 1010H

Name store parameters

Object Code ARRAY

Number of Elements 1H - 7FH


VALUE DESCRIPTION

Sub-Index 0H

Description largest supported Sub-Index


Access ro

PDO Mapping No


Mandatory Range No

Default Value No

Sub-Index 1H

Description save all parameters


Access rw

PDO Mapping No

Value Range Unsigned32 (see Fig. 10-12+13)

Mandatory Range No


10-26

Default Value No

Sub-Index 2H

Description save communicationparameters


Access rw

PDO Mapping No


Mandatory Range No

Default Value No

Sub-Index 3H

Description save application parameters


Access rw

PDO Mapping No


Mandatory Range No

Default Value No

Sub-Index 4H - 7FH

Description save manufacturer definedparameters


Access rw

PDO Mapping No


Mandatory Range No

Default Value No

Object 1011H: Restore default parameters

With this object the default values of parameters according to the communication ordevice profile are restored. By read access the device provides information about itscapabilities 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 - 1FFFhmanufacturer specific communication parameters).

Sub-Index 3 refers to application related parameters (Index 6000h - 9FFFhmanufacturer specific application parameters).


10-27

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 onlyexecuted when a specific signature is written to the appropriate Sub-Index. Thesignature is ãloadÒ.

Signature MSB LSBASCII d a o lhex 64h 61h 6Fh 6Ch

Figure 10-14: Restoring write access signature

On reception of the correct signature in the appropriate Sub-Index the device restoresthe default parameters and then confirms the SDO transmission (initiate downloadresponse). If the restoring failed, the device responds with abort domain transfer, errorclass 6h, error code 6h (hardware fault). If a wrong signature is written, the devicerefuses 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 oncommand (see 1010h), the appropriate command has to be executed after the reset i fthe 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 itsdefault parameter restoring capability with the following format:

Unsigned32

MSB LSB

bits 31-1 0

reserved (=0) 0/1

Figure 10-15: Restoring default values read access structure



10-28

31-1 0 reserved

0 0 Device does not restore default parameters

1 Device restores parameters


10-29

OBJECT DESCRIPTION

INDEX 1011H

Name restore default parameters

Object Code ARRAY

Number of Elements 1H - 7FH


VALUE DESCRIPTION

Sub-Index 0H

Description largest supported Sub-Index


Access ro

PDO Mapping No


Mandatory Range No

Default Value No

Sub-Index 1H

Description restore all default parameters


Access rw

PDO Mapping No


Mandatory Range No

Default Value No

Sub-Index 2H

Description restore communication defaultparameters


Access rw

PDO Mapping No


Mandatory Range No

Default Value No

Sub-Index 3H

Description restore application defaultparameters


Access rw

PDO Mapping No


10-30


Mandatory Range No

Default Value No

Sub-Index 4H - 7FH

Description restore manufacturer defineddefault parameters


PDO Mapping No


Mandatory Range No

Object 1012H: COB-ID Time-stamp message

Index 1012H defines the COB-ID of the Time-Stamp Object (TIME). Further, it defineswhether 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 theentry 1005h (COB-ID SYNC message).

OBJECT DESCRIPTION

INDEX 1012H

Name COB-ID time stamp message

Object Code VAR


VALUE DESCRIPTION


Access rw

PDO Mapping No


Mandatory Range No

Default Value 100h


10-31

Object 1013H: High Resolution Time Stamp

This object contains a time stamp with a resolution of 1 msec. It can be mapped into aPDO in order to define a high resolution time stamp message. (Note that the data typeof the standard time stamp message (TIME) is fixed). Further application specific use isencouraged.

OBJECT DESCRIPTION

INDEX 1013H

Name high resolution time stamp

Object Code VAR


VALUE DESCRIPTION


Access rw



Mandatory Range No


Object 1014H: COB-ID Emergency Message

Index 1014H defines the COB-ID of the Emergency Object (EMCY). The structure ofthis 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 1014H

Name COB-ID Emergency message

Object Code VAR


VALUE DESCRIPTION


Access rw

PDO Mapping No


Mandatory Range No

Default Value 80h + node-ID


10-32

Object 1200H - 127FH: Server SDO Parameter

These objects contain the parameters for the SDOs for which the device is the server. Ifa device handles more than one server SDO the default SDO must be located at index1200H as the first server SDO. This entry is read only25. All additional server SDOs areinvalid by default (invalid bit - see table 10-6).

The description of the Client of the SDO (Sub-index 3h) is optional. It is not availablefor the default SDO (no Sub-index 3h at Index 1200H), as this entry is read_only.

OBJECT DESCRIPTION

INDEX 1200H - 127FH

Name Server SDO parameter

Object Code RECORD

Number of Elements 3H

Data Type SDOPar

VALUE DESCRIPTION

Sub-Index 0H



Access ro

PDO Mapping No


Mandatory Range 2

Default Value No

Sub-Index 1H

Description COB-ID Client->Server (rx)


Access Index 1200h: ro,

Index 1201h-127Fh: rw

PDO Mapping No

Value Range Unsigned32 (figure 10-4)

Mandatory Range No



25 It must be ensured that the COB-IDs of the default SDO can not be manipulated by

writing to the object dictionary.


10-33

Sub-Index 2H

Description COB-ID Server -> Client (tx)


Access Index 1200h: ro

Index 1201-127Fh: rw

PDO Mapping No


Mandatory Range No



Sub-Index 3H

Description node ID of the SDO client


Access rw

PDO Mapping No


Mandatory Range No

Default Value No

Object 1280H - 12FFH: Client SDO ParameterThese objects contain the parameters for the SDOs for which the device is the client. Ifthe entry is supported, all sub-indices must be available.

OBJECT DESCRIPTION

INDEX 1280H - 12FFH

Name Client SDO parameter

Object Code RECORD

Number of Elements 3H

Data Type SDOPar

VALUE DESCRIPTION

Sub-Index 0H



Access ro

PDO Mapping No


Mandatory Range 3

Default Value 3


10-34

Sub-Index 1H

Description COB-ID Client->Server (tx)


Access rw

PDO Mapping No


Mandatory Range No

Default Value No

Sub-Index 2H

Description COB-ID Server -> Client (rx)


Access rw

PDO Mapping No


Mandatory Range No

Default Value No

Sub-Index 3H

Description node ID of the SDO server


Access rw

PDO Mapping No


Mandatory Range No

Default Value No


10-35

Object 1400H - 15FFH: Receive PDO Communication Parameter

Contains the communication parameters for the PDOs the device is able to receive.

OBJECT DESCRIPTION

INDEX 1400H - 15FFH

Name receive PDO parameter

Object Code RECORD

Number of Elements 2 (Mandatory), 3-4 (Optional)

Data Type PDOCommPar

VALUE DESCRIPTION

Sub-Index 0H



Access ro

PDO Mapping No



Sub-Index 1H



Access rw

PDO Mapping No

Value Range Unsigned32 (Figure 10-6)

Mandatory Range No



Index 1402h - 15FFh: No

Sub-Index 2H



Access rw

PDO Mapping No

Value Range Unsigned8 (Table 10-7)

Mandatory Range No



10-36

Sub-Index 3H



Access rw

PDO Mapping No


Mandatory Range No

Default Value No

Sub-Index 4H

Description CMS priority group


Access rw

PDO Mapping No



Default Value No

Object 1600H - 17FFH: Receive PDO Mapping Parameter

Contains the mapping for the PDOs the device is able to receive.

OBJECT DESCRIPTION

INDEX 1600H - 17FFH

Name receive PDO mapping

Object Code RECORD

Number of Elements 1H-64H

Data Type PDOMapping

VALUE DESCRIPTION

Sub-Index 0H



Access rw

PDO Mapping No





10-37

Sub-Index 1H - 40H

Description PDO mapping for the nthapplication object to bemapped


Access rw

PDO Mapping No


Mandatory Range No


Object 1800H - 19FFH: Transmit PDO Communication Parameter

Contains the communication parameters for the PDOs the device is able to transmit.

OBJECT DESCRIPTION

INDEX 1800H - 19FFH

Name transmit PDO parameter

Object Code RECORD

Number of Elements 2 (Mandatory), 3-4 (Optional)

Data Type PDOCommPar

VALUE DESCRIPTION

Sub-Index 0H



Access ro

PDO Mapping No



Sub-Index 1H



Access rw

PDO Mapping No

Value Range Unsigned32 (Figure 10-6)

Mandatory Range No



Index 1802h - 18FFh: No


10-38

Sub-Index 2H



Access rw

PDO Mapping No

Value Range Unsigned8 (Table 10-7)

Mandatory Range No


Sub-Index 3H



Access rw

PDO Mapping No


Mandatory Range No

Default Value No

Sub-Index 4H

Description CMS priority group


Access rw

PDO Mapping No



Default Value No


10-39

Object 1A00H - 1BFFH: Transmit PDO Mapping Parameter

Contains the mapping for the PDOs the device is able to transmit.

OBJECT DESCRIPTION

INDEX 1A00H - 1BFFH

Name transmit PDO mapping

Object Code RECORD

Number of Elements 1H-64H

Data Type PDOMapping

VALUE DESCRIPTION

See Value Description of objects 1600H - 17FFH.

Physical Layer CANopen Communication Profile CiA

11-1

11 Physical LayerThe physical medium for CANopen devices is a differentially driven two-wire bus l inewith 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 betweenbus 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 andcorresponding bit timing recommendations are listed in table 11-1.

Bit rate

Bus length (1)

Nominal

bit time

tb

Number of

time quanta

per bit

Length of

time

quantum tq

Location of

sample

point

1 Mbit/s

25 m

1 ms 8 125 ns 6 tq

(750 ns)

800 kbit/s

50 m

1.25 ms 10 125 ns 8 tq

(1 ms)

500 kbit/s

100 m

2 ms 16 125 ns 14 tq

(1.75 ms)

250 kbit/s

250 m (2)

4 ms 16 250 ns 14 tq

(3.5 ms)

125 kbit/s

500 m (2)

8 ms 16 500 ns 14 tq

(7 ms)

50 kbit/s

1000 m (3)

20 ms 16 1.25 ms 14 tq

(17.5 ms)

20 kbit/s

2500 m (3)

50 ms 16 3.125 ms 14 tq

(43.75 ms)

10 kbit/s

5000 m (3)

100 ms 16 6.25 ms 14 tq

(87.5 ms)

Table 11-1: Recommended Bit Timing Settings

Oscillator frequency 16 MHz +/-0.1% (1000 ppm)

Sampling mode Single sampling SAM = 0

Synchronisation mode Recessive to dominant edges only SYNC = 0

Synchronisation jump width 1 * tq SJW = 0

Phase Segment 2 2 * tq TSEG2 = 1


11-2

Note 1: Rounded bus length estimation (worst case) on basis 5 ns/m propagationdelay and a total effective ECU-internal (Elec. Control Unit) in-out delayas 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 recessivedivided

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 andtransceiver this affects the maximum bus length depending upon thepropagation delay of the optocouplers i.e. -4m per 10 ns propagationdelay of employed optocoupler type.

Note 3: For bus length greater than about 1 km bridge or repeater devices maybe needed.

A module shall support as many of the recommended bit rates as possible. It is notrequired, 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 Bus Connector

11.5.1 9-pin D-Sub Connector

CAN_GND

CAN_H

CAN_L

(GND) CAN_V+

(CAN_SHLD)

54321

9876

male

12345

6789

female

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


11-3

Pin Signal Description

1 - Reserved

2 CAN_L CAN_L bus line (dominant low)

3 CAN_GND CAN Ground

4 - Reserved

5 (CAN_SHLD) Optional CAN Shield

6 (GND) Optional Ground

7 CAN_H CAN_H bus line (dominant high)

8 - Reserved

9 (CAN_V+) Optional CAN external positive supply (dedicated forsupply of transceiver and optocouplers, if galvanicisolation of the bus node applies)

If 9-pin D-Sub connector is supported, a male connector meeting the abovespecification has to be provided by the bus node. Within the modules, pin 3 and pin 6have to be interconnected. Inside of such modules providing two bus connections, andinside the T-connectors, all the pins (including the reserved ones) have to beconnected. The intention is, that there shall be no interruption of any of the wires inthe 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, thenecessity 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

1

2

3

4

5

female

1

2

3

4

5

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




3 CAN_GND Ground / 0V / V-



The bus node provides the male pins of the connector.

11.5.3 Open Style Connector


11-4

1 2 3 4 5

1 2 3 4 5

female

male

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


1 CAN_GND Ground / 0 V / V-





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

11.5.4 Multipole Connector

1

2

10

9

1

10

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


11-5


1 reserved

2 (GND) Optional Ground



5 CAN_GND CAN Ground

6 reserved

7 reserved

8 (CAN_V+) Optional CAN external positive supply

9 reserved

10 reserved

11.5.5 Other Connectors

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

Signal description notation

CAN_L bus line (dominant low) CAN_L or CANlow or CAN-

CAN_H bus line (dominant high) CAN_H or CANhigh or CAN+

CAN Ground CAN_GND or CANGND or Ground or GND

Optional CAN Shield CAN_SHLD or CANSHIELD or Shield or SHLD

Optional CAN external positivesupply

CAN_V+ or CANV+ or V+ or UC or UCAN

Optional Ground OPT_GND or GNDopt or V- or 0V

APPENDIX CANopen Communication Profile CiA

12-1

12 APPENDIX

12.1 Example PDOMapping:

Consider a device which has the following object dictionary entries:

Index Sub-Index Object Name Data Type

6060 - variable_1 Unsigned16



60AE - variable_4 Unsigned16

60D0 0 rec_elem_0 Unsigned8

1 rec_elem_1 Unsigned8



Table A.1: Example of Device Profile Description

If we wish to configure the receive PDO defined on index 1600h to have the followingstructure:

Figure A.1: Desired Input PDO Configuration

Then we would have to write the following values to the corresponding PDOMappingstructure at index 1600h in the object dictionary:

Sub-Index(hex)

Value (hex) Comment

0 3 Number of objects in input = 3

1 60 91 00 20 First object mapped is at index 6091.0 (32 bit length)

2 60 AE 00 10 Second object mapped is at index 60AE.0 (16 bitlength)

3 60 D0 02 08 Third object mapped is at index 60D0.2 (8 bit length)

Table A.2: Mapping of receive PDO

0 1 2 3 4 5 6 7

Not Usedrec_elem_2variable_4variable_2

Byte


12-2

If we want this PDO to be reveived synchronously every communication cycle with theCOB-ID 300 we have to write the following values in the communication parameterlocated at 1400H.

Sub-Index(hex)

Value (hex) Comment

0 4 number of supported entries

1 12C COB-ID = 300

2 1 transmission type = 1 (cyclic, synchronous)

3 0 no inhibit time

4 0 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 followingstructure:

0 1 2 3 4 5 6 7

Not Usedvariable_3variable_1

Byte

Figure A.2: Desired transmit PDO Configuration

Then we would have to write the following values to the corresponding PDOMappingstructure at index 1A00h in the object dictionary:

Sub-Index(hex)

Value (hex) Comment

0 2 Number of objects in transmit PDO = 2

1 60 60 0010

First object mapped is at index 6060.0 (16 bit length)

2 60 92 0020

Second object mapped is at index 6092.0 (32 bitlength)

Table A.4: Mapping of transmit PDO

If we want this PDO to be transmitted asynchronously on an device specific eventspecified in the device profile with the COB-ID 400 we have to write the followingvalues in the communication parameter located at 1800H.

Sub-Index(hex)

Value (hex) Comment

0 4 number of supported entries

1 190 COB-ID = 400

2 FF transmission type = 255 (asynchronous, profilespecific)

3 0 no inhibit time

4 0 no priority group (ID is distributed statically)

Table A.5: Communication parameters for transmit PDO


12-3

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)

Error Register: Bit 7 6 5 4 3 2 1 0 = 09H

Content 0 0 0 0 1 0 0 1

Emergency Message: 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 twoasynchronous PDO's (device = server). The table lists the COB names used by thedevice in order to request the identifiers via DBT. The device's node-ID is 1. In ãxxxÒ thedevice profile number used for this particular device is coded (e.g. 401 for I/O deviceprofile).

COB name Communication Parameter atIndex

PDOMapping at Index

xxxSYNC000001X 1005h (COB-ID only) -

xxxSDO_001001C -

xxxSDO_001001S -

xxxRPDO001001X 1400h (1st receive PDO) 1600H (1st receive PDO)

xxxTPDO001001X 1800h (1st transmit PDO) 1A00H (1st transmit PDO)

xxxRPDO002001X 1401h (2nd receive PDO) 1601H (2nd receive PDO)

xxxTPDO002001X 1801h (2nd transmit PDO) 1A01H (2nd transmit PDO)

xxxEMCY000001X - -

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

12.4.1 Object 6C05H

Writes the value to the output channel 'n' (unconverted). Value is 32 bits wide or less.

OBJECT DESCRIPTION

INDEX 6C05H

Name Write_Analogue_Output_32

Object Code RECORD

Number OfElements

0H(Mandatory) 1H-20H(Optional)


PDO Mapping 0H(Mandatory) 1H-20H(Optional)


12-4

VALUE DESCRIPTION

Sub-Index 0H

Description Number_Analogue_Outputs

Data Type Unsigned8

Length 1


PDO Mapping NO

Value Range 0H -20H

Mandatory Range NO

Sub-Index 1H

Description Output_1H


Length 2


PDO Mapping Possible


Mandatory Range NO

Sub-Index 2H



Length 2




Mandatory Range NO

to

Sub-Index 20H



Length 2




Mandatory Range NO


12-5

12.5 Electronic Data Sheet Specification

12.5.1 Introduction

In order to give the user of a CANopen device more support the deviceÕs descriptionshould be available in a standardised way. This gives the opportunity to createstandardised 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 withelectronically means. The files are ASCII-coded and it is recommended to use theANSI 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 theincarnation 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.

Electronic Data Sheet - serves as template for

different configu-

rations for one device

type

20 kBit/sID = 110

250 kBit/sID = 55

1000 kBit/sID = 2

EDS DCF device

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


12-6

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 noEDS available for his CANopen devices a default EDS can be used. The default EDScomprises 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 - file name (according to DOS restrictions),

FileVersion - actual file version (Unsigned8),

FileRevision - actual file revision (Unsigned8),

Description - file description (255 characters),

CreationTime - file creation time (characters in format ãhh:mm(AM|PM)Ò),

CreationDate - date of file creation (characters in format ãmm-dd-yyÒ),

CreatedBy - name or description of file creator (255 characters),

ModificationTime - time of last modification (characters in formatãhh:mm(AM|PM)Ò),ModificationDate - date of last file modification (characters in format ãmm-dd-yyÒ),ModifiedBy - name or description of the modification (255 characters).

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


12-7

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 used:VendorName - vendor name (255 characters)

VendorNumber - vendor code (Unsigned32)

ProductName - product name (255 characters)

ProductNumber - product number (Unsigned32)

ProductVersion - product version (Unsigned8)

ProductRevision - product revision (Unsigned8)

OrderCode - order code for this product (255 characters)

LMT_ManufacturerName - manufacturer name part of LMT-address (7 characters)

LMT_ProductName - product name part of LMT-address (7 characters)

BaudRate_10 - supported baud rates (Boolean, 0 = not supported, 1 =supported)

BaudRate_20

BaudRate_50

BaudRate_100

BaudRate_125

BaudRate_250

BaudRate_500

BaudRate_800

BaudRate_1000

SimpleBootUpMaster - simple boot-up master functionality (Boolean, 0 = notsupported, 1 = supported),

SimpleBootUpSlave - simple boot-up slave functionality (Boolean, 0 = notsupported, 1 = supported),

ExtendedBootUpMaster - extended boot-up master functionality (Boolean, 0 = notsupported, 1 = supported),

ExtendedBootUpSlave - simple boot-up slave functionality (Boolean, 0 = notsupported, 1 = supported),

Granularity - This value gives you the granularity allowed for themapping on this device - most of the existing devicessupports a granularity of 8 (Unsigned8; 0 - mapping notmodifiable, 1-64 granularity)


12-8

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 this section of the EDS the following information can be found:1. which object of the object dictionary is supported,

2. limit values for parameters,

3. 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 thecomplex standard data types PDO Communication Parameter Record and PDOMapping Record are known.

The entries follow this scheme:

<data type index>={0|1}


12-9

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 thate.g. a device only evaluates the last two data bytes of a PDO of 8 bytes length. The firstsix bytes should be ignored (perhaps they are evaluated by another device). In this casethe mapping of this device must be created by using dummy entries for these first sixbytes.

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 dummyentries and what not (indeed only the length of the dummy object is important).

The section DummyUsage is used for describing dummies. The entries follow thisscheme:

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/32and Unsigned8/16/32.


12-10

12.5.2.3.3 Object sections

The section MandatoryObjects describes the mandatory objects of the objectdictionary. There exists only the two entries DeviceType and ErrorRegister. In thesection 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 thenumber of available entries. In these sections the entries have the same values for al ldevices because there are no optional entries.

1=0x1000

2=0x1001

The entries of the particular objects of the object dictionary are all constructedfollowing the same scheme. The section name is constructed according to thefollowing:

[<Index>(sub<Sub-Index>)]

using the hexadecimal values for Index and Sub-index without the leading ã0xÒ.

In a section the following keywords may exist:SubNumber - number of sub-indices available at this index (Unsigned8)

ParameterName - parameter name (255 characters)

ObjectType - This is the object code (DS301 table 11-2).

DataType - This is the index of the data type of the object in the objectdictionary (DS301 table 11.1-1).

LowLimit - Lowest limit of object value (only if applicable).

HighLimit - Upper limit of object value (only if applicable).

AccessType - Access type for this object (String ãroÒ - read only, ãwoÒ - writeonly, ãrwÒ - read/write, ãrwrÒ - read/write on process input, ãrwwÒ- read/write on process output, ãconstÒ - constant value, )

DefaultValue - default value for this object,

PDOMapping - default value for this object (Boolean, 0 = not mappable, 1= mappable).

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-indicesfor 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 EDScan be realised like the following:


12-11

[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-12

The section OptionalObjects describes the optional objects supported by thedevice.

;-----------------------------------

[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-13

The section ManufacturerObjects describes the manufacturer specific entries in theobject 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 grouprelated objects together via the keyword ObjectLinks.

An object link has the following structure:

[<index>ObjectLinks]

ObjectLinks=<number of available links>

1=<index of 1st linked object>

2=<index of 2nd linked object>

3=<index of 3rd linked object>

4=<index of 4th linked object>

5=<index of 5th linked object>

:

Example:

; assuming we describe closed loop

; this is the object ãfactorÒ

[5800ObjectLinks]

ObjectLinks=0x3

; gain

1=0x5801

; zero

2=0x5802

; pole

3=0x5803


12-14

12.5.2.4 Comments

Comments can be added to the EDS by using the Comments section. This section hasonly 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=| DonÕt panic |

Line3=|-------------|

12.5.3 Structure of a DCF (Device Configuration File)

The device configuration file comprises all objects for a configured device. Thedevice configuration file has the same structure as the EDS for this device. There aresome 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: if a read access is performed for this object, the data are stored inthis file (character 255)

DownloadFile: if a write access is performed for this object, the data to be writtencan be taken from this file (character 255)


12-15

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 - deviceÕs address (Unsigned8)

NodeName - node name part of NMT-address (7 characters)

Baudrate - deviceÕs 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

CAN in Automation e. V.

CANopenCommunication Profilefor Industrial Systems

Based on CAL

CiA Draft Standard 301

Revision 3.0

Date: 30.10.96

Table of Contents CANopen Communication Profile CiAMembers Only Edition

i

History

Date Changes

Oct 96 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 mademandatory

· 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


i i

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


i i i

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


iv

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

Scope CANopen Communication Profile CiAMembers Only Edition

1-1

1 ScopeDevices which have to communicate can be found in nearly every automated system.Unfortunately there is no standardised product definition with respect to the controltechniques of functional elements. Therefore, each system integrator of automatedsystems creates his own standards.

The resulting control and information flow concepts differ between each integrator andin most cases the employed control devices are not even compatible.

This document contains the description of the CANopen Communication Profile forindustrial applications using CAN as their installation bus. It is based on the CANApplication Layer (CAL) (see /4, .., 16/) specification from the CAN in Automationinternational users and manufacturers group (CiA e.V.).

The CANopen Communication Profile forms the interface between the CANApplication Layer and the CANopen Device Profiles. It includes the real-timecommunication model and the protocols which are common to all devices in thenetwork. Device Profiles, on the other hand, are a common means to describe devicespecific 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.

References CANopen Communication Profile CiA

2-1

2 References

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

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

/3/: Robert Bosch GmbH, CAN Specification 2.0 Part A+B, September 1991

/4/: CiA DS-102, CAN Physical Layer for Industrial Applications, April 1994

/5/: CiA DS-201, CAN Reference Model, February 1996

/6/: CiA DS-202/1, CMS Service Specification, February 1996

/7/: CiA DS-202/2, CMS Protocol Specification, February 1996

/8/: CiA DS-202/3, CMS Data Types and Encoding Rules, February 1996

/9/: CiA DS-203/1, NMT Service Specification, February 1996

/10/: CiA DS-203/2, NMT Protocol Specification, February 1996

/11/: CiA DS-204/1, DBT Service Specification, February 1996

/12/: CiA DS-204/2, DBT Protocol Specification, February 1996

/13/: CiA DS-207, Application Layer Naming Specification, February 1996

/14/: CiA DS-205/1, LMT Service Specification, February 1996

/15/: CiA DS-205/2, LMT Protocol Specification, February 1996

eBook - CANOpen

Documents

Transcript of eBook - CANOpen