DS301v4.01
© CAN in Automation e. V.
CANopen
Application Layer and Communication Profile
CiA Draft Standard 301
Version 4.01
Date: 1 June 2000
HISTORY
CANopen
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-207
specified) and extended
· Boot Up Message specified
· Optional Heartbeat specified
· Additional Emergency error codes specified
· Additional SDO abort codes specified
· Timer-driven PDO transmission specified
· PDO Communication parameter enhanced
· PDO Mapping procedure clarified
· SDO Block transfer specified
· Pre-defined Identifier set extended
June 2000
·
correction of some typing errors
·
clearification of some descriptions
·
Appendix:
·
Device configuration
·
OS command and prompt
·
Multiplexed PDOs
·
Modular CANopen devices
·
Error behaviour
ii
CiA
CONTENTS
CANopen
CONTENTS
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
6
Abbreviations .......................................................................................................... 5-1
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
7
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
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
9
CAN Frame Type.................................................................................................... 8-1
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
9.1.3
Bit Sequences .................................................................................................. 9-2
iii
CiA
CONTENTS
CANopen
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
ANNEX A (NORMATIVE).............................................................................................. 11-1
11.1
Additional object dictionary entries ...................................................................... 11-2
11.2
Device configuration ............................................................................................. 11-3
11.2.1
Boot-up configuration process ...................................................................... 11-3
iv
CiA
CONTENTS
11.2.2
11.3
EDS storage................................................................................................... 11-3
OS command and prompt .................................................................................... 11-5
11.3.1
OS command ................................................................................................. 11-5
11.3.2
OS debugger interface .................................................................................. 11-6
11.3.3
OS prompt ...................................................................................................... 11-6
11.4
Multiplexed PDOs ................................................................................................. 11-8
11.4.1
MPDO Protocol .............................................................................................. 11-8
11.4.2
Object dictionary entries ................................................................................ 11-9
11.4.3
Implementing MPDOs.................................................................................. 11-11
11.4.4
Groups, security and network configuration tools ...................................... 11-11
11.4.5
Indication of MPDO capability in the EDS .................................................. 11-11
11.5
Additional functionality for modular CANopen devices ..................................... 11-12
11.5.1
Background .................................................................................................. 11-12
11.5.2
Modular Devices .......................................................................................... 11-12
11.6
12
CANopen
Additional communication objects...................................................................... 11-13
11.6.1
Emergency consumer object....................................................................... 11-13
11.6.2
Error behaviour object ................................................................................. 11-14
INDEX ............................................................................................................................. 12-1
v
CiA
TABLES
CANopen
CiA
1 TABLES
Table 1: Object Dictionary Structure .......................................................................................................... 6-3
Table 2: Recommended Bit Timing Settings ............................................................................................. 7-1
Table 3: Write PDO ..................................................................................................................................... 9-9
Table 4: Read PDO..................................................................................................................................... 9-9
Table 5: SDO Download ........................................................................................................................... 9-13
Table 6: Initiate SDO Download ............................................................................................................... 9-13
Table 7: Download SDO Segment ........................................................................................................... 9-14
Table 8: SDO Upload................................................................................................................................ 9-14
Table 9: Initiate SDO Upload................................................................................................... ................. 9-15
Table 10: Upload SDO Segment................................................................................................... ........... 9-15
Table 11: Abort SDO Transfer.................................................................................................................. 9-15
Table 12: SDO Block Download............................................................................................................... 9-16
Table 13: Initiate SDO Block Download................................................................................................... 9-16
Table 14: Download SDO Block............................................................................................................... 9-17
Table 15: End SDO Block Download ....................................................................................................... 9-17
Table 16: SDO Block Upload.................................................................................................................... 9-18
Table 17: Initiate SDO Block Upload........................................................................................................ 9-18
Table 18: Upload SDO Block.................................................................................................................... 9-19
Table 19: End SDO Block Upload ............................................................................................................ 9-19
Table 20: SDO abort codes ...................................................................................................................... 9-26
Table 21: Emergency Error Codes........................................................................................................... 9-38
Table 22: Start Remote Node................................................................................................................... 9-41
Table 23: Stop Remote Node ................................................................................................................... 9-41
Table 24: Enter Pre-Operational .............................................................................................................. 9-41
Table 25: Reset Node ............................................................................................................................... 9-42
Table 26: Reset Communication .............................................................................................................. 9-42
Table 27: Node Guarding Event............................................................................................................... 9-43
Table 28: Life Guarding Event.................................................................................................................. 9-43
Table 29: Heartbeat Event........................................................................................................................ 9-43
Table 30: Bootup Event ............................................................................................................................ 9-43
Table 31: Trigger for State Transition ...................................................................................................... 9-53
Table 32: States and Communication Objects ........................................................................................ 9-55
Table 33: Broadcast Objects of the Pre-defined Connection Set ........................................................... 9-56
Table 34: Peer-to-Peer Objects of the Pre-defined Connection Set ...................................................... 9-56
Table 35: Format of Object Dictionary Headings..................................................................................... 9-56
Table 36: Object Dictionary Object Definitions ........................................................................................ 9-57
Table 37: Access Attributes for Data Objects .......................................................................................... 9-57
Table 38: Object Dictionary Data Types .................................................................................................. 9-58
Table 39: complex data type example ..................................................................................................... 9-60
Table 40: PDO Communication Parameter Record ................................................................................ 9-60
1-1
TABLES
CANopen
CiA
Table 41: PDO Mapping Parameter Record............................................................................................ 9-61
Table 42: SDO Parameter Record ........................................................................................................... 9-61
Table 43: Identity Record.......................................................................................................................... 9-61
Table 44: Format of an Object Description .............................................................................................. 9-61
Table 45: Object Value Description Format............................................................................................. 9-62
Table 46: Standard Objects...................................................................................................................... 9-62
Table 47: Structure of the Error Register ................................................................................................. 9-65
Table 48: Description of SYNC COB-ID entry ......................................................................................... 9-67
Table 49: Structure of read access .......................................................................................................... 9-71
Table 50: Structure of restore read access.............................................................................................. 9-73
Table 51: Description of TIME COB-ID entry........................................................................................... 9-75
Table 52: Description of EMCY COB-ID entry......................................................................................... 9-76
Table 53: Description of SDO COB-ID entry ........................................................................................... 9-80
Table 54: Description of PDO COB-ID entry ........................................................................................... 9-83
Table 55: Description of transmission type.............................................................................................. 9-84
1-2
FIGURES
CANopen
CiA
2 FIGURES
Figure 1: Reference Model ......................................................................................................................... 6-1
Figure 2: Service Types.............................................................................................................................. 6-2
Figure 3: Device Model ............................................................................................................................... 6-3
Figure 4: Unconfirmed Master Slave Communication............................................................................... 6-5
Figure 5: Confirmed Master Slave Communication................................................................................... 6-5
Figure 6: Client/Server Communication ..................................................................................................... 6-6
Figure 7: Push model.................................................................................................................................. 6-6
Figure 8: Pull model .................................................................................................................................... 6-6
Figure 9: Transfer Syntax for Bit Sequences............................................................................................. 9-3
Figure 10: Transfer syntax for data type UNSIGNEDn ............................................................................. 9-4
Figure 11: Transfer syntax for data type INTEGERn ................................................................................ 9-4
Figure 12: Transfer syntax of data type REAL32 ...................................................................................... 9-5
Figure 13: Synchronous and Asynchronous Transmission....................................................................... 9-8
Figure 14: Write PDO Protocol ................................................................................................................. 9-10
Figure 15: Read PDO Protocol................................................................................................................. 9-10
Figure 16: Download SDO Protocol ......................................................................................................... 9-20
Figure 17: Initiate SDO Download Protocol ............................................................................................. 9-21
Figure 18: Download SDO Segment Protocol ......................................................................................... 9-22
Figure 19: Upload SDO Protocol.............................................................................................................. 9-23
Figure 20: Initiate SDO Upload Protocol.................................................................................................. 9-24
Figure 21: Upload SDO Segment Protocol.............................................................................................. 9-25
Figure 22: Abort SDO Transfer Protocol.................................................................................................. 9-26
Figure 23: SDO Block Download Protocol............................................................................................... 9-28
Figure 24: Initiate SDO Block Download Protocol................................................................................... 9-29
Figure 25: Download SDO Block Segment.............................................................................................. 9-30
Figure 26: End SDO Block Download Protocol ....................................................................................... 9-31
Figure 27: Upload SDO Block Protocol.................................................................................................... 9-32
Figure 28: Initiate SDO Block Upload Protocol........................................................................................ 9-33
Figure 29: Upload SDO Block Segment Protocol.................................................................................... 9-34
Figure 30: End SDO Block Upload Protocol ............................................................................................ 9-35
Figure 31: SYNC Protocol ........................................................................................................................ 9-36
Figure 32: TIME Protocol.......................................................................................................................... 9-37
Figure 33: Emergency State Transition Diagram .................................................................................... 9-39
Figure 34: Emergency Object Data.......................................................................................................... 9-39
Figure 35: Emergency Object Protocol .................................................................................................... 9-40
Figure 36: Start Remote Node Protocol................................................................................................... 9-44
Figure 37: Stop Remote Node Protocol ................................................................................................... 9-44
Figure 38: Enter Pre-Operational Protocol .............................................................................................. 9-45
Figure 39: Reset Node Protocol ............................................................................................................... 9-45
Figure 40: Reset Communication Protocol .............................................................................................. 9-46
2-1
FIGURES
CANopen
CiA
Figure 41: Node Guarding Protocol ......................................................................................................... 9-47
Figure 42: Heartbeat Protocol .................................................................................................................. 9-48
Figure 43: Bootup Protocol ....................................................................................................................... 9-49
Figure 44: Bus Synchronisation and Actuation........................................................................................ 9-50
Figure 45: Bus Synchronisation and Sampling........................................................................................ 9-50
Figure 46: Optional High Resolution Synchronisation Protocol .............................................................. 9-51
Figure 47: Flow Chart of the Network Initialisation Process ................................................................... 9-52
Figure 48: State Diagram of a Device ...................................................................................................... 9-53
Figure 49: Structure of the Initialisation state .......................................................................................... 9-54
Figure 50: Identifier allocation scheme for the pre-defined connection set............................................ 9-56
Figure 51: structure sub-index FFh .......................................................................................................... 9-60
Figure 52: Structure of the Device Type Parameter................................................................................ 9-64
Figure 53: Structure of the pre-defined error field ................................................................................... 9-65
Figure 54: Structure of SYNC COB-ID entry ........................................................................................... 9-66
Figure 55: Storage write access signature .............................................................................................. 9-70
Figure 56: Storage read access structure................................................................................................ 9-70
Figure 57: Restoring write access signature............................................................................................ 9-72
Figure 58: restore procedure .................................................................................................................... 9-73
Figure 59: Restoring default values read access structure..................................................................... 9-73
Figure 60: Structure of TIME COB-ID entry............................................................................................. 9-74
Figure 61: Structure of the EMCY Identifier entry.................................................................................... 9-76
Figure 62: Structure of Consumer Heartbeat Time entry........................................................................ 9-77
Figure 63: Structure of Revision number ................................................................................................. 9-79
Figure 64: Structure of SDO COB-ID entry.............................................................................................. 9-80
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-87
2-2
SCOPE
CANopen
3 SCOPE
This Part of prEN 50325 specifies the following particular requirements for CANopen:
(1) Requirements for interfaces between controllers and switching elements;
(2) Normal service conditions for devices;
(3) Constructional and performance requirements.
3-1
CiA
REFERENCES
CANopen
4 REFERENCES
4.1
Normative references
EN 50325-1: 1999
Industrial communications subsystem based on ISO 11898 (CAN) for
controller-device interfaces
Part 1: General requirements
EN 61131-3: 1993
Programmable controllers
Part 3: Programming languages
ISO 7498-1: 1994
Information technology - Open Systems Interconnection - Basic Reference
Model: 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 information
interchange
4.2
Informative references
IEEE 754: 1985
Standard for binary floating-point arithmetic
4-1
CiA
DEFINITIONS AND ABBREVIATIONS
CANopen
CiA
5 DEFINITIONS AND ABBREVIATIONS
5.1
Abbreviations
ARQ:
Automatic Repeat Request.
CAN:
Controller Area Network is an internally standardized serial bus system..
COB:
Communication Object. A unit of transportation in a CAN network. Data must be sent across a CAN
Network inside a COB. There are 2048 different COB's in a CAN network. A COB can contain at most
8 bytes of data.
COB-ID:
Each COB is uniquely identified in a CAN network by a number called the COB Identifier (COB-ID).
The COB-ID determines the priority of that COB for the MAC sub-layer.
Remote COB:
A COB whose transmission can be requested by another device.
CRC:
Cyclic Redundancy Check.
CSDO:
Client SDO.
LLC:
Logical Link Control. One of the sub-layers of the Data Link Layer in the CAN Reference Model that
gives the user an interface that is independent from the underlying MAC layer.
MAC:
Medium Access Control. One of the sub-layers of the Data Link Layer in the CAN Reference Model
that controls who gets access to the medium to send a message.
MDI:
Medium Dependent Interface. One of the sub-layers of the Physical Layer in the CAN Reference
Model that specifies the mechanical and electrical interface between the medium and a module.
NMT:
Network Management. One of the service elements of the application layer in the CAN Reference
Model. The NMT serves to configure, initialise, and handle errors in a CAN network.
OSI:
Open Systems Interconnection.
PDO:
Process Data Object.
PLS:
Physical Layer Signalling. One of the sub-layers of the Physical Layer in the CAN Reference Model
that specifies the bit representation, timing and synchronisation.
PMA:
Physical Medium Attachment. One of the sub-layers of the Physical Layer in the CAN Reference
Model that specifies the functional circuitry for bus line transmission/reception and may provide means
for failure detection.
RPDO:
Receive PDO.
5-1
DEFINITIONS AND ABBREVIATIONS
CANopen
SDO:
Service Data Object.
SSDO:
Server SDO.
SYNC:
Synchronisation Object.
TPDO:
Transmit PDO.
5-2
CiA
MODELING
CANopen
CiA
6 MODELING
CAN-based networks use the following reference model, device model, and communication model.
6.1
Reference Model
Application Process
Application
Application
(1)
Presentation
Session
Transport
Network
LLC
Datalink
MAC
PLS
PMA
MDI
Physical
·
·
(2)
(2)
specified in this document
specified in ISO 11898
Figure 1: Reference Model
The communication concept can be described similar to the ISO-OSI Reference Model (left side of
figure).
Application Layer:
The Application Layer comprises a concept to configure and communicate real-time-data as well as
the mechanisms for synchronization between devices. The functionality the application layer offers to
an application is logically divided over different service objects in the application layer. A service object
offers a specific functionality and all the related services. These services are described in the Service
Specification of that service object.
Applications interact by invoking services of a service object in the application layer. To realize these
services, this object exchanges data via the CAN Network with (a) peer service object(s) via a
protocol. This protocol is described in the Protocol Specification of that service object.
Service Primitives:
Service primitives are the means by which the application and the application layer interact. There are
four different primitives:
· a request is issued by the application to the application layer to request a service
·
an indication is issued by the application layer to the application to report an internal event
detected by the application layer or indicate that a service is requested
6-1
MODELING
CANopen
CiA
·
a response is issued by the application to the application layer to respond to a previous received
indication
·
a confirmation is issued by the application layer to the application to report the result of a
previously issued request.
Application Layer Service Types
Application X
Application X
request
indication
Local Service
Application X
Provider Initiated
Service
Application Y, Z, ..
indication
Application X
Application Y
request
indication
confirmation
response
indication
indication
Unconfirmed Service
Confirmed Service
Figure 2: Service Types
A service type defines the primitives that are exchanged between the application layer and the cooperating applications for a particular service of a service object.
· A local service involves only the local service object. The application issues a request to its local
service object that executes the requested service without communicating with (a) peer service
object(s).
·
An unconfirmed service involves one or more peer service objects. The application issues a
request to its local service object. This request is transferred to the peer service object(s) that
each pass it to their application as an indication. The result is not confirmed back.
·
A confirmed service can involve only one peer service object. The application issues a request to
its local service object. This request is transferred to the peer service object that passes it to the
other application as an indication. The other application issues a response that is transferred to
the originating service object that passes it as a confirmation to the requesting application.
·
A provider initiated service involves only the local service object. The service object (being the
service provider) detects an event not solicited by a requested service. This event is then
indicated to the application.
Unconfirmed and confirmed services are collectively called remote services.
6.2
6.2.1
Device Model
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 state
machine used on this device.
· Application Ð The application comprises the functionality of the device with respect to the
interaction with the process environment.
6-2
MODELING
CANopen
CiA
Thus the Object Dictionary serves as an interface between the communication and the application.
The complete description of a deviceÕs application with respect to the data items in the Object
Dictionary is named device profile.
Object
Dictionary
Communication
Application
State machine
Application
object
Entry 1
Comm.
object
Entry 2
Comm.
object
Application
object
:
Comm.
object
Application
object
Entry n
Comm.
object
Application
object
Bus system
Process
Figure 3: Device Model
6.2.2
The Object Dictionary
The most important part of a device profile is the Object Dictionary description. The Object Dictionary
is essentially a grouping of objects accessible via the network in an ordered pre-defined fashion. Each
object within the dictionary is addressed using a 16-bit index.
The overall layout of the standard Object Dictionary is shown below. This layout closely conforms with
other industrial serial bus system concepts:
Table 1: Object Dictionary Structure
Index (hex)
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-bit
index.
6-3
MODELING
CANopen
CiA
The Static Data Types at indices 0001h through 001Fh contain type definitions for standard data types
like BOOLEAN, INTEGER, floating point, string, etc. These entries are included for reference only,
they cannot be read or written.
Complex Data Types at indices 0020h through 003Fh are pre-defined structures that are composed of
standard data types and are common to all devices.
Manufacturer Specific Complex Data Types at indices 0040h through 005Fh are structures composed
of standard data types but are specific to a particular device.
Device Profiles may define additional data types specific to their device type. The static data types
defined by the device profile are listed at indices 0060h - 007Fh, the complex ones at indices 0080h 009Fh.
A device may optionally provide the structure of the supported complex data types (indices 0020h 005Fh and 0080h - 009Fh) at read access to the corresponding index. Sub-index 0 then provides the
number of entries at this index, and the following sub-indices contain the data type encoded as
UNSIGNED16 according to Table 38.
The Communication Profile Area at indices 1000h through 1FFFh contains the communication specific
parameters for the CAN network. These entries are common to all devices.
The standardised device profile area at indices 6000h through 9FFFh contains all data objects
common to a class of devices that can be read or written via the network. The device profiles may use
entries from 6000h to 9FFFh to describe the device parameters and the device functionality. Within
this range up to 8 different devices can be described. In such a case the devices are denominated
Multiple Device Modules. Multiple Device Modules are composed of up to 8 device profile segments.
By this feature it is possible to build devices with multiple functionality. The different device profile
entries are shifted with 800h.
For Multiple Device Modules the object range 6000h to 67FFh is shifted as follows:
6000h to 67FFh
device 0
6800h to 6FFFh
device 1
7000h to 77FFh
device 2
7800h to 7FFFh
device 3
8000h to 87FFh
device 4
8800h to 8FFFh
device 5
9000h to 97FFh
device 6
9800h to 9FFFh
device 7
The PDO distribution shall be used for every segment of a Multiple Device Module with an offset of 64,
e.g. the first PDO of the second segment gets the number 65. In this way a system with a maximum of
8 segments is supported.
The Object Dictionary concept caters for optional device features which means a manufacturer does
not have to provide certain extended functionality on his devices but if he wishes to do so he must do
it in a pre-defined fashion.
Space is left in the Object Dictionary at indices 2000h through 5FFFh for truly manufacturer-specific
functionality.
6.2.2.1
Index and Sub-Index Usage
A 16-bit index is used to address all entries within the Object Dictionary. In case of a simple variable
the index references the value of this variable directly. In case of records and arrays however, the
index addresses the whole data structure.
To allow individual elements of structures of data to be accessed via the network a sub-index is
defined. For single Object Dictionary entries such as an UNSIGNED8, BOOLEAN, INTEGER32 etc.
the value for the sub-index is always zero. For complex Object Dictionary entries such as arrays or
records with multiple data fields the sub-index references fields within a data-structure pointed to by
the main index. The fields accessed by the sub-index can be of differing data types.
6.3
Communication Model
The communication model specifies the different communication objects and services and the
available modes of message transmission triggering.
The communication model supports the transmission of synchronous and asynchronous messages.
By means of synchronous message transmission a network wide coordinated data acquisition and
actuation is possible. The synchronous transmission of messages is supported by pre-defined
communication objects (Sync message, time stamp message). Synchronous messages are
transmitted with respect to a pre-defined synchronization message, asynchronous message may be
transmitted at any time.
6-4
MODELING
CANopen
CiA
Due to the event character of the underlying communication mechanism it is possible to define inhibit
times for the communication. To guarantee that no starvation on the network occurs for data objects
with low priorities, data objects can be assigned an inhibit time. The inhibit-time of a data object
defines the minimum time that has to elapse between two consecutive invocations of a transmission
service for that data object. Inhibit-times can be assigned by the application.
With respect to their functionality, three types of communication relationships are distinguished
· Master/Slave relationship (Figure 4 and Figure 5)
· Client/Server relationship (Figure 6)
· Producer/Consumer relationship (Figure 7 and Figure 8)
6.3.1
Master/Slave relationship
At any time there is exactly one device in the network serving as a master for a specific functionality.
All other devices in the network are considered as slaves. The master issues a request and the
addressed slave(s) respond(s) if the protocol requires this behavior.
Master
Slaves
indication
request
indication
data
indication
Figure 4: Unconfirmed Master Slave Communication
Master
Slave
indication
request
Remote Transmit Request
confirmation
response
data
Figure 5: Confirmed Master Slave Communication
6-5
MODELING
6.3.2
CANopen
CiA
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 the
server answers the request.
Client
Server
request
indication
data
confirmation
response
data
Figure 6: Client/Server Communication
6.3.3
Producer/Consumer relationship - Pull/Push model
The producer/consumer relationship model involves a producer and zero or more consumer(s). The
push model is characterized by an unconfirmed service requested by the producer. The pull model is
characterized by a confirmed service requested by the consumer.
Producer
Consumers
indication
request
indication
data
indication
Figure 7: Push model
Producer
Consumers
indication
request
Remote Transmit Request
request
request
response
confirmation
data
indication
indication
Figure 8: Pull model
6-6
PHYSICAL LAYER
CANopen
CiA
7 PHYSICAL LAYER
The physical medium for devices is a differentially driven two-wire bus line with common return
according to high-speed transmission specification in ISO 11898.
7.1
Transceiver
Using the high-speed transceiver according to ISO 11898 the maximum rating for VCAN_H and VCAN_L
shall be +16V. Galvanic isolation between bus nodes is optional. It is recommended to use a
transceiver that is capable of sustaining mis-connection of any of the wires of the connector including
the optional V+ voltages of up to 30V.
7.2
Bit rates and timing
The recommended bit rates and corresponding bit timing recommendations
One of these bit rates has to be supported.
(4)
are listed in Table 2.
Table 2: Recommended Bit Timing Settings
Bit rate
(1)
Bus length
1 Mbit/s
25 m
800 kbit/s
50 m
500 kbit/s
100 m
250 kbit/s
(2)
250 m
125 kbit/s
(2)
500 m
50 kbit/s
(3)
1000 m
20 kbit/s
(3)
2500 m
10 kbit/s
(3)
5000 m
Nominal
bit time
tb
1 ms
Number of
time quanta
per bit
8
Length of
time
quantum tq
125 ns
(750 ns)
1,25 ms
10
125 ns
2 ms
16
125 ns
4 ms
16
250 ns
8 ms
16
500 ns
20 ms
16
1,25 ms
50 ms
16
3,125 ms
100 ms
16
6,25 ms
The table entries are an example based on the follow acceptance:
Oscillator frequency
16 MHz +/-0.1% (1000 ppm)
Sampling mode
Single sampling
Synchronisation mode
Recessive to dominant edges only
Synchronisation jump width
1 * tq
Phase Segment 2
2 * tq
Note 1:
Note 2:
Note 3:
Location of
sample
point
6 tq
8 tq
(1 ms)
14 tq
(1,75 ms)
14 tq
(3,5 ms)
14 tq
(7 ms)
14 tq
(17,5 ms)
14 tq
(43,75 ms)
14 tq
(87,5 ms)
SAM = 0
SYNC = 0
SJW = 0
TSEG2 = 1
Rounded bus length estimation (worst case) on basis 5 ns/m propagation delay
and a total effective device internal in-out delay as follows:
1M - 800 kbit/s:
210 ns
500 - 250 kbit/s:
300 ns (includes 2 * 40 ns for optocouplers)
125 kbit/s:
450 ns (includes 2 * 100 ns for optocouplers)
50 - 10 kbit/s:
1,5 tq; Effective delay = delay recessive to dominant plus
dominant to recessive divided by two.
For bus length greater than about 200 m the use of optocouplers is
recommended. If optocouplers are placed between CAN controller and
transceiver this affects the maximum bus length depending upon the propagation
delay of the optocouplers i.e. -4m per 10 ns propagation delay of employed
optocoupler type.
For bus length greater than about 1 km bridge or repeater devices may be
needed.
7-1
PHYSICAL LAYER
Note 4
CANopen
The bit timings in the table are calculated for an oscillator frequency of 16 MHz.
If another oscillator is used the number of time quanta may be different.
Nevertheless the location of the sample point shall be as near as possible at the
recommended sample point.
7-2
CiA
DATA LINK LAYER
CANopen
CiA
8 DATA LINK LAYER
The described networks are based on a data link layer and its sub-layers according to ISO 11898.
8.1
CAN Frame Type
This specification is based on the CAN Standard Frames with 11-bit Identifier Field. It is not required to
support the CAN Extended Frame with 29-bit Identifier Field.
However, as certain applications may require the usage of the extended frame with 29-bit Identifier
Field the network can be operated in this mode as well if it is supported by all nodes.
8-1
APPLICATION LAYER
CANopen
CiA
9 APPLICATION LAYER
9.1
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 its
meaning have to be known by the producer and consumer(s). This specification models this by the
concept of data types.
The encoding rules define the representation of values of data types and the CAN network transfer
syntax for the representations. Values are represented as bit sequences. Bit sequences are
transferred in sequences of octets (bytes). For numerical data types the encoding is little endian style
as shown in Figure 9.
Applications often require data types beyond the basic data types. Using the compound data type
mechanism the list of available data types can be extended. Some general extended data types are
defined as ÒVisible StringÓ or ÒTime of DayÓ for example (see 9.1.6.2 and 9.1.6.4). The compound data
types are a means to implement user defined ÒDEFTYPESÓ in the terminology of this specification and
not ÒDEFSTRUCTSÓ (see Table 36: Object Dictionary Object Definitions).
9.1.2
Data Type Definitions
A data type determines a relation between values and encoding for data of that type. Names are
assigned to data types in their type definitions. The syntax of data and data type definitions is as
follows (see EN 61131-3).
data_definition
::= type_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-1
APPLICATION LAYER
CANopen
CiA
Recursive definitions are not allowed.
The data type defined by type_definition is called basic (res.~compound) when the constructor is
basic_constructor (res. compound_constructor).
9.1.3
9.1.3.1
Bit Sequences
Definition of Bit Sequences
A bit can take the values 0 or 1. A bit sequence b is an ordered set of 0 or more bits. If a bit sequence
b contains more than 0 bits, they are denoted as bj, j > 0. Let b0, ..., bn-1 be bits, n a positive integer.
Then
b = b0 b1 ... bn-1
is called a bit sequence of length |b| = n. The empty bit sequence of length 0 is denoted e.
Examples: 10110100, 1, 101, etc. are bit sequences.
The inversion operator (Ø) on bit sequences assigns to a bit sequence
b = b0 b1 ... bn-1
the bit sequence
Øb = Øb0 Øb1 ... Øbn-1
Here Ø0 = 1 and Ø1 = 0 on bits.
The basic operation on bit sequences is concatenation.
Let a = a0 ... am-1 and b = b0 ... bn-1 be bit sequences. Then the concatenation of a and b, denoted
ab, is
ab = a0 ... am-1 b0 ... bn-1
Example: (10)(111) = 10111 is the concatenation of 10 and 111.
The following holds for arbitrary bit sequences a and b:
|ab| = |a| + |b|
and
ea = ae = a
9.1.3.2
Transfer Syntax for Bit Sequences
For transmission across a CAN network a bit sequence is reordered into a sequence of octets. Here
and in the following hexadecimal notation is used for octets. Let b = b0...bn-1 be a bit sequence with
n<64. Denote k a non-negative integer such that 8(k - 1) < n < 8k. Then b is transferred in k octets
assembled as shown in Figure 9. The bits bi, i > n of the highest numbered octet are do not care bits.
Octet 1 is transmitted first and octet k is transmitted last. Hence the bit sequence is transferred as
follows across the CAN network:
b7, b6, ..., b0, b15, ..., b8, ...
9-2
APPLICATION LAYER
CANopen
octet number
CiA
1.
2.
k.
b7 .. b0
b15 .. b8
b8k Ð1 .. b8k -8
Figure 9: Transfer Syntax for Bit Sequences
Example:
Bit 9
...
10
0001
2h
1h
Bit 0
1100
Ch
= 21Ch
The bit sequence b = b0 .. b9 = 0011 1000 01 represents an UNSIGNED10 with the value
21Ch and is transferred in two octets:
First 1Ch and then 02h.
9.1.4
Basic Data Types
For basic data types Òtype_nameÓ equals the literal string of the associated constructor (aka
symbolic_name), e.g.,
BOOLEAN BOOLEAN
is the type definition for the BOOLEAN data type.
9.1.4.1
NIL
Data of basic data type NIL is represented by e.
9.1.4.2
Boolean
Data of basic data type BOOLEAN attains the values TRUE or FALSE. The values are represented as
bit sequences of length 1. The value TRUE (res. FALSE) is represented by the bit sequence 1 (res. 0).
9.1.4.3
Void
Data of basic data type VOIDn is represented as bit sequences of length n bit. The value of data of
type VOIDn is undefined. The bits in the sequence of data of type VOIDn must either be specified
explicitly or else marked "do not care".
Data of type VOIDn is useful for reserved fields and for aligning components of compound values on
octet boundaries.
9.1.4.4
Unsigned Integer
Data of basic data type UNSIGNEDn has values in the non-negative integers. The value range is 0, ...,
2n-1. The data is represented as bit sequences of length n. The bit sequence
b = b0 ...bn-1
is assigned the value
UNSIGNEDn(b) = bn-1 2n-1+ ...+ b1 21 + b0 20
Note that the bit sequence starts on the left with the least significant bit.
Example: The value 266 = 10Ah with data type UNSIGNED16 is transferred in two octets
across the bus, first 0Ah and then 01h.
9-3
APPLICATION LAYER
CANopen
CiA
The following UNSIGNEDn data types are transferred as shown below:
octet number
1.
2.
3.
4.
5.
6.
7.
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
8.
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-1
is assigned the value
INTEGERn(b) = bn-2 2n-2 + ...+ b1 21 + b0 20 if bn-1 = 0
and, performing two's complement arithmetic,
INTEGERn(b) = - INTEGERn(^b) - 1
if bn-1 = 1
Note that the bit sequence starts on the left with the least significant bit.
Example: The value Ð266 = FEF6h with data type INTEGER16 is transfered in two octets
across the bus, first F6h and then FEh.
The following INTEGERn data types are transfered as shown below:
octet number
1.
2.
3.
4.
5.
6.
7.
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
Figure 11: Transfer syntax for data type INTEGERn
9-4
8.
b63..b56
APPLICATION LAYER
9.1.4.6
CANopen
CiA
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 follows
the IEEE 754-1985 Standard for single precision floating-point.
The data type REAL64 is represented as bit sequence of length 64. The encoding of values follows
the IEEE 754-1985 Standard for double precision floating-point numbers.
A bit sequence of length 32 either has a value (finite non-zero real number, +0, + _) or is NaN (not-anumber). The bit sequence
b = b0 É b31
is assigned the value (finite non-zero number)
REAL32(b) = (-1)S 2E - 127 (1 + F)
Here
S = b31 is the sign.
E = b30 27 + É+ b23 20, 0 < E < 255, is the un-biased exponent.
F = 2-23 (b22 222 + É+ b1 21 + b0 20) is the fractional part of the number.
E = 0 is used to represent + 0. E = 255 is used to represent infinities and NaN's.
Note that the bit sequence starts on the left with the least significant bit.
Example:
6.25 = 2E -127 (1 + F) with
E =129 =27 +20 and
F = 2-1 +2-4 = 2 -23(222+219) hence the number is represented as:
S
b31
0
E
b30 .. b23
100 0000 1
F
b22 .. b0
100 1000 0000 0000 0000 0000
6.25 = b0 .. b31 = 0000 0000 0000 0000 0001 0011 0000 0010
It is transferred in the following order:
octet number
REAL32
1.
2.
3.
4.
00h
00h
C8h
40h
b7..b0
b15..b8
b23..b16
b31..b24
Figure 12: Transfer syntax of data type REAL32
9-5
APPLICATION LAYER
9.1.5
CANopen
CiA
Compound Data Types
Type definitions of compound data types expand to a unique list of type definitions involving only basic
data types. Correspondingly, data of compound type «type_name« are ordered lists of component data
named «component_name_i« of basic type «basic_type_i«.
Compound data types constructors are ARRAY and STRUCT OF.
STRUCT OF
basic_type_1
basic_type_2
É
basic_type_N
component_name_1,
component_name_2,
É
component_name_N
type_name
ARRAY [ length ] OF basic_type type_name
The bit sequence representing data of compound type is obtained by concatenating the bit sequences
representing the component data.
Assume that the components «component_name_i« are represented by their bit sequences
b(i), for i = 1,É,N
Then the compound data is represented by the concatenated sequence
b0(1) .. bn-1(1) .. bn-1(N).
Example:
Consider the data type
STRUCT OF
INTEGER10
x,
UNSIGNED5
u
NewData
Assume x = - 423 = 259h and u = 30 = 1Eh. Let b(x) and b(u) denote the bit sequences
representing the values of x and u, respectively. Then:
b(x)
= b0(x) .. b9(x)
= 1001101001
b(u)
= b0(u) .. b4(u)
= 01111
b(xu) = b(x) b(u)
= b0(xu) .. b14(xu) = 1001101001 01111
The value of the structure is transferred with two octets, first 59h and then 7Ah.
9.1.6
Extended Data Types
The extended data types consist of the basic data types and the compound data types defined in the
following subsections.
9.1.6.1
Octet String
The data type OCTET_STRINGlength is defined below; length is the length of the octet string.
ARRAY [ length ] OF UNSIGNED8 OCTET_STRINGlength
9.1.6.2
Visible String
The data type VISIBLE_STRINGlength is defined below. The admissible values of data of type
VISIBLE_CHAR are 0h and the range from 20h to 7Eh. The data are interpreted as ISO 646-1973(E)
7-bit coded characters. length is the length of the visible string.
UNSIGNED8
VISIBLE_CHAR
ARRAY [ length ] OF VISIBLE_CHAR
There is no 0h necessary to terminate the string.
9.1.6.3
VISIBLE_STRINGlength
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 encoding
rules that TIME_OF_DAY is represented as bit sequence of length 48.
9-6
APPLICATION LAYER
CANopen
CiA
Component ms is the time in milliseconds after midnight. Component days is the number of days since
January 1, 1984.
STRUCT OF
UNSIGNED28
VOID4
UNSIGNED16
ms,
reserved,
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 the
encoding rules that TIME_DIFFERENCE is represented as bit sequence of length 48.
Time differences are sums of numbers of days and milliseconds. Component ms is the number
milliseconds. Component days is the number of days.
STRUCT OF
UNSIGNED28
VOID4
UNSIGNED16
ms,
reserved,
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. The
contents of a data block is application specific and does not fall within the scope of this document.
9.2
Communication Objects
The communication objects are described by the services and protocols.
All services are described in a tabular form that contains the parameters of each service primitive that
is defined for that service. The primitives that are defined for a particular service determine the service
type (e.g. unconfirmed, confirmed, etc.). How to interpret the tabular form and what service types exist
is defined in 6.3 (Communication Model).
All services assume that no failures occur in the Data Link and Physical Layer of the CAN network.
These failures are resolved by the application and fall not in the scope of this document.
9.2.1
Process Data Object (PDO)
The real-time data transfer is performed by means of "Process Data Objects (PDO)". The transfer of
PDOs is performed with no protocol overhead.
The PDOs correspond to entries in the device Object Dictionary and provide the interface to the
application objects. Data type and mapping of application objects into a PDO is determined by a
corresponding default PDO mapping structure within the Device Object Dictionary. If variable PDOmapping is supported the number of PDOs and the mapping of application objects into a PDO may be
transmitted to a device during the device configuration process (see Initialisation Procedure) by
applying the SDO services to the corresponding entries of the Object Dictionary.
Number and length of PDOs of a device is application specific and have to be specified within the
device profile.
There are two kinds of use for PDOs. The first is data transmission and the second data reception. It is
distinguished in Transmit-PDOs (TPDOs) and Receive-PDOs (RPDOs). Devices supporting TPDOs
are PDO producer and devices which are able to receive PDOs are called PDO consumer. PDOs are
described by the PDO communication parameter (20h) and the PDO mapping parameter (21h). The
structure of these data types are explained in 9.5.4. The PDO communication parameter describes the
communication capabilities of the PDO. The PDO mapping parameter contains information about the
contents of the PDOs (device variables). The indices of the corresponding Object Dictionary entries
are computed by the following formulas:
·
RPDO communication parameter index = 1400h + RPDO-number -1
·
TPDO communication parameter index = 1800h + TPDO-number -1
·
RPDO mapping parameter index = 1600h + RPDO-number -1
9-7
APPLICATION LAYER
·
CANopen
CiA
TPDO mapping parameter index = 1A00h + TPDO-number -1
For each PDO the pair of communication and mapping parameter is mandatory. The entries
mentioned above are described in 9.5 (Object Dictionary).
9.2.1.1
Transmission Modes
The following PDO transmission modes are distinguished:
· Synchronous Transmission
· Asynchronous Transmission
In order to synchronise devices a synchronisation object (SYNC object) is transmitted periodically by a
synchronisation application. The SYNC object is represented by a pre-defined communication object
(see 9.2.3). In Figure 13 the principle of synchronous and asynchronous transmission is shown.
Synchronous PDOs are transmitted within a pre-defined time-window immediately after the SYNC
object. The principle of synchronous transmission is described in more detail in 9.3.
SYNC
Object
Synchronous
Window
Length
SYNC
Object
SYNC
Object
time
Synchronous
PDOs
Asynchronous
PDOs
Figure 13: Synchronous and Asynchronous Transmission
The transmission type parameter of a PDO specifies the transmission mode as well as the triggering
mode.
For synchronous TPDOs the transmission type also specifies the transmission rate in form of a factor
based on the basic SYNC-object transmission period. A transmission type of 0 means that the
message shall be transmitted after occurrence of the SYNC but acyclic (not periodically), only if an
event occurred before the SYNC. A transmission type of 1 means that the message is transmitted with
every SYNC object. A transmission type of n means that the message is transmitted with every n-th
SYNC object. Asynchronous TPDOs are transmitted without any relation to a SYNC.
The data of synchronous RPDOs received after the occurrence of a SYNC is passed to the application
with the occurrence of the following SYNC, independent of the transmission rate specified by the
transmission type. The data of asynchronous RPDOs is passed directly to the application.
9.2.1.2
Triggering Modes
Three message triggering modes are distinguished:
· Event Driven
Message transmission is triggered by the occurrence of an object specific event. For synchronous
PDOs this is the expiration of the specified transmission period, synchronised by the reception of
the SYNC object.
For acyclically transmitted synchronous PDOs and asynchronous PDOs the triggering of a
message transmission is a device-specific event specified in the device profile.
· Timer Driven
Message transmission is either triggered by the occurrence of a device-specific event or if a
specified time has elapsed without occurrence of an event.
9-8
APPLICATION LAYER
CANopen
CiA
· Remotely requested
The transmission of an asynchronous PDO is initiated on receipt of a remote request initiated by
any other device (PDO consumer).
9.2.1.3
PDO Services
PDO transmission follows the producer/consumer relationship as described in 6.3.3.
Attributes:
- PDO number:
- user type:
- data type:
- inhibit-time:
9.2.1.3.1
PDO number [1..512] for every user type on the local device
one of the values {consumer, producer}
according to the PDO mapping
n*100 ms, n >> 0
Write PDO
For the Write PDO service the push model is valid. There are zero or more consumers of a PDO. A
PDO has exactly one producer.
Through this service the producer of a PDO sends the data of the mapped application objects to the
consumer(s).
Table 3: Write PDO
9.2.1.3.2
Parameter
Request / Indication
Argument
PDO Number
Data
Mandatory
mandatory
mandatory
Read PDO
For the Read PDO service the pull model is valid. There are one or more consumers of a PDO. A PDO
has exactly one producer.
Through this service the consumer of a PDO requests the producer to supply the data of the mapped
application objects. The service is confirmed. The remote result parameter will confirm the value.
Table 4: Read PDO
Parameter
Request / Indication
Argument
PDO Number
Mandatory
mandatory
Remote Result
Data
Response / Confirm
Mandatory
mandatory
9-9
APPLICATION LAYER
CANopen
9.2.1.4
PDO Protocol
9.2.1.4.1
Write PDO Protocol
CiA
The service for a PDO write request is unconfirmed. The PDO producer sends the process data within
a PDO to the network. There can be 0..n PDO consumers. At the PDO consumer(s) the reception of a
valid PDO is indicated. Figure 14 shows the Write PDO Protocol.
PDO Producer
PDO Consumers
Write PDO
L (0 £ L £ 8)
0
Request
Indication
Indication
Indication
Process Data
Figure 14: Write PDO Protocol
Process-Data: up to L bytes of application data according to the PDO mapping
If L exceeds the number of bytes ÔnÕ defined by the actual PDO mapping length only the first ÔnÕ bytes
are used by the consumer. If L is less than ÔnÕ the data of the received PDO is not processed and an
Emergency message with error code 8210h has to be produced if Emergency is supported.
9.2.1.4.2
Read PDO Protocol
The service for a PDO read request is confirmed. One or more PDO consumer transmit a remote
transmission request frame (RTR) to the network. At the reception of the RTR frame the PDO
producer for the requested PDO transmits the PDO. At all PDO consumers for this PDO the reception
is indicated. There can be 0..n PDO consumers. The read service is optional and depends on the
hardware capabilities. Figure 15 shows the Read PDO Protocol.
PDO Producer
PDO Consumers
Read PDO
Indication
request
Remote Transmit Request
L (0 £ L £ 8)
0
response
Process Data
confirmation
Figure 15: Read PDO Protocol
Process-Data: up to L bytes of application data according to the PDO mapping
If L exceeds the number of bytes ÔnÕ defined by the actual PDO mapping length only the first ÔnÕ bytes
are used by the consumer. If L is less than ÔnÕ the data of the received PDO is not processed and an
Emergency message with error code 8210h has to be produced if Emergency is supported.
9-10
APPLICATION LAYER
9.2.2
CANopen
CiA
Service Data Object (SDO)
With Service Data Objects (SDOs) the access to entries of a device Object Dictionary is provided. As
these entries may contain data of arbitrary size and data type SDOs can be used to transfer multiple
data sets (each containing an arbitrary large block of data) from a client to a server and vice versa.
The client can control via a multiplexor (index and sub-index of the Object Dictionary) which data set is
to be transferred. The contents of the data set are defined within the Object Dictionary.
Basically a SDO is transferred as a sequence of segments. Prior to transferring the segments there is
an initialisation phase where client and server prepare themselves for transferring the segments. For
SDOs, it is also possible to transfer a data set of up to four bytes during the initialisation phase. This
mechanism is called an expedited transfer.
Optionally a SDO can be transferred as a sequence of blocks where each block is a sequence of up to
127 segments containing a sequence number and the data. Prior to transferring the blocks there is an
initialisation phase where client and server can prepare themselves for transferring the blocks and
negotiating the number of segments in one block. After transferring the blocks there is a finalisation
phase where client and server can optionally verify the correctness of the previous data transfer by
comparing checksums derived from the data set. This transfer type mentioned above is called a block
transfer which is faster than the segmented transfer for a large set of data.
In SDO Block Upload it is possible that the size of the data set does not justify the use of a block
transfer because of the implied protocol overhead. In these cases a support for a fallback to the
segmented or expedited transfer in initialisation phase can be implemented. As the assumption of the
minimal data set size for which a block transfer outperforms the other transfer types depends on
various parameters the client indicates this threshold value in bytes to the server in initialisation phase.
For the block transfer a Go-Back-n ARQ (Automatic Repeat Request) scheme is used to confirm each
block.
After block download the server indicates the client the last successfully received segment of this
block transfer by acknowledging this segment sequence number. Doing this the server implicitly
acknowledges all segments preceding this segment. The client has to start the following block transfer
with the retransmission of all not acknowledged data. Additionally the server has to indicate the
number of segments per block for the next block transfer.
After block upload the client indicates the server the last successfully received segment of this block
transfer by acknowledging this segment sequence number. Doing this the client implicitly
acknowledges all segments preceding this segment. The server has to start the following block
transfer with the retransmission of all not acknowledged data. Additionally the client has to indicate the
number of segments per block for the next block transfer.
For all transfer types it is the client that takes the initiative for a transfer. The owner of the accessed
Object Dictionary is the server of the SDO. Both the client or the server can take the initiative to abort
the transfer of a SDO.
By means of a SDO a peer-to-peer communication channel between two devices is established. A
device may support more than one SDO. One supported Server-SDO (SSDO) is the default case
(Default SDO).
SDOs are described by the SDO communication parameter record (22h).The structure of this data
type is explained in 9.5.4. The SDO communication parameter describes the communication
capabilities of the Server-SDOs and Client-SDOs (CSDO). The indices of the corresponding Object
Dictionary entries are computed by the following formulas:
·
SSDO communication parameter index = 1200h + SSDO-number -1
·
CSDO communication parameter index = 1280h + CSDO-number -1
For each SDO the communication parameters are mandatory. If only one SSDO exists the
communication parameters can be omitted. The entries mentioned above are described in 9.5 (Object
Dictionary).
9.2.2.1
SDO Services
The model for the SDO communication is the Client/Server model as described in 0.
Attributes:
- SDO number:
SDO number [1..128] for every user type on the local device
- user type:
one of the values {client, server}
- mux data type multiplexor containing index and sub-index of type
STRUCTURE OF UNSIGNED (16) , UNSIGNED (8) ,
with index specifying an entry of the device Object
9-11
APPLICATION LAYER
CANopen
CiA
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 be
responsible for transferring the SDO as a sequence of segments.
Expetited transfer has to be supported. Segmented transfer has to be supported if objects larger than
4 Bytes are supported. Optionally the following SDO services for doing a block transfer with higher bus
utilisation and performance for a large data set size can be implemented:
· SDO Block Download, which can be split up into
- Initiate Block Download
- Download Block
- End Block Download
·
SDO Block Upload, which can be split up into
- Initiate Block Upload
- Upload Block
- End Block Upload
When using the SDO block download and upload services, the communication software will be
responsible for transferring the data as a sequence of blocks.
In SDO Block Upload Protocol a support for a switch to SDO Upload Protocol in ÔInitiate SDO Block
UploadÕ can be implemented to increase transfer performance for data which size does not justifies
using the protocol overhead of the ÔSDO Block UploadÕ protocol.
For aborting a SDO block transfer the Abort SDO Transfer Service is used.
9.2.2.1.1
SDO Download
Through this service the client of a SDO downloads data to the server (owner of the Object
Dictionary). The data, the multiplexor (index and sub-index) of the data set that has been downloaded
and its size (only optionally for segmented transfer) are indicated to the server.
The service is confirmed. The remote result parameter will indicate the success or failure of the
request. In case of a failure, optionally the reason is confirmed.
The SDO download consists of at least the Initiate SDO Download service and optional of Download
SDO Segment services (data length > 4 bytes).
9-12
APPLICATION LAYER
CANopen
CiA
Table 5: SDO Download
Parameter
Request / Indication
Argument
SDO Number
Data
Size
Multiplexor
Mandatory
mandatory
mandatory
optional
mandatory
Mandatory
selection
selection
optional
Remote Result
Success
Failure
Reason
9.2.2.1.2
Response / Confirm
Initiate SDO Download
Through this service the client of SDO requests the server to prepare for downloading data to the
server. Optionally the size of the data to be downloaded is indicated to the server.
The multiplexor of the data set whose download is initiated and the transfer type are indicated to the
server. In case of an expedited download, the data of the data set identified by the multiplexor and
size is indicated to the server.
Table 6: Initiate SDO Download
Parameter
Request / Indication
Argument
SDO Number
Size
Multiplexor
Transfer type
Normal
Expedited
Data
Mandatory
mandatory
optional
mandatory
mandatory
selection
selection
mandatory
Response / Confirm
Mandatory
mandatory
Remote Result
Success
The service is confirmed. The remote result parameter will indicate the success of the request. In case
of a failure, an Abort SDO Transfer request has to be executed. In the case of a successful expedited
download of a multiplexed DOMAIN, this service concludes the download of the data set identified by
multiplexor.
9.2.2.1.3
Download SDO Segment
Through this service the client of a SDO supplies the data of the next segment to the server. The
segment data and optionally its size are indicated to the server. The continue parameter indicates the
server whether there are still more segments to be downloaded or that this was the last segment to be
downloaded.
9-13
APPLICATION LAYER
CANopen
CiA
Table 7: Download SDO Segment
Parameter
Request / Indication
Argument
SDO number
Data
Size
Continue
More
Last
Mandatory
mandatory
mandatory
optional
mandatory
selection
selection
Response / Confirm
Mandatory
mandatory
Remote Result
Success
The service is confirmed. The remote result parameter will indicate the success of the request. In case
of a failure, an Abort SDO transfer request must be executed. In case of success, the server has
accepted the segment data and is ready to accept the next segment. There can be at most one
Download SDO Segment service outstanding for a SDO transfer.
A successful Initiate SDO Download service with segmented transfer type must have been executed
prior to this service.
9.2.2.1.4
SDO Upload
Through this service the client of a SDO uploads data from the server. The multiplexor (index and subindex) of the data set that has to be uploaded is indicated to the server.
The SDO upload consists of at least the Initiate SDO Upload service and optional of Upload SDO
Segment services (data length > 4 bytes).
Table 8: SDO Upload
Parameter
Request / Indication
Argument
SDO number
Multiplexor
Mandatory
mandatory
mandatory
Response / Confirm
Mandatory
selection
mandatory
optional
selection
optional
Remote Result
Success
Data
Size
Failure
Reason
The service is confirmed. The remote result parameter will indicate the success or failure of the
request. In case of a failure, optionally the reason is confirmed. In case of success, the data and its
size (optionally for segmented transfer) are confirmed.
9.2.2.1.5
Initiate SDO Upload
Through this service the client of a SDO requests the server to prepare for uploading data to the client.
The multiplexor (index and sub-index) of the data set whose upload is initiated is indicated to the
server.
The service is confirmed. The remote result parameter will indicate the success of the request. In case
of a failure, an Abort SDO Transfer request has to be executed. In the case of success, the size
(optionally for segmented transfer) of the data to be uploaded is confirmed. In case of successful
expedited upload, this service concludes the upload of the data set identified by multiplexor and the
corresponding data is confirmed.
9-14
APPLICATION LAYER
CANopen
CiA
Table 9: Initiate SDO Upload
Parameter
Request / Indication
Argument
SDO number
Multiplexor
Mandatory
mandatory
mandatory
Mandatory
mandatory
optional
mandatory
mandatory
selection
selection
mandatory
Remote Result
Success
Size
Multiplexor
Transfer type
Normal
Expedited
Data
9.2.2.1.6
Response / Confirm
Upload SDO Segment
Through this service the client of a SDO requests the server to supply the data of the next segment.
The continue parameter indicates the client whether there are still more segments to be uploaded or
that this was the last segment to be uploaded. There can be at most one Upload SDO Segment
service outstanding for a SDO.
The service is confirmed. The remote result parameter will indicate the success of the request. In case
of a failure, an Abort SDO Transfer request must be executed. In case of success, the segment data
and optionally its size are confirmed.
A successful Initiate SDO Upload service with segmented transfer type must have been executed prior
to this service.
Table 10: Upload SDO Segment
Parameter
Request / Indication
Argument
SDO number
Mandatory
mandatory
Mandatory
mandatory
mandatory
optional
mandatory
selection
selection
Remote Result
Success
Data
Size
Continue
More
Last
9.2.2.1.7
Response / Confirm
Abort SDO Transfer
This service aborts the up- or download of a SDO referenced by is number. Optionally the reason is
indicated. The service is unconfirmed. The service may be executed at any time by both the client and
the server of a SDO. If the client of a SDO has a confirmed service outstanding, the indication of the
abort is taken to be the confirmation of that service.
Table 11: Abort SDO Transfer
Parameter
Request / Indication
Argument
SDO number
Multiplexor
Reason
Mandatory
mandatory
mandatory
mandatory
9-15
APPLICATION LAYER
9.2.2.1.8
CANopen
CiA
SDO Block Download
Through this service the client of SDO downloads data to the server of SDO (owner of the Object
Dictionary) using the block download protocol. The data, the multiplexor (index and sub-index) of the
data set that has been downloaded and optionally its size are indicated to the server.
The service is confirmed. The remote result parameter will indicate the success or failure of the
request. In case of a failure, optionally the reason is confirmed.
Table 12: SDO Block Download
Parameter
Request / Indication
Argument
SDO Number
Data
Size
Multiplexor
Mandatory
mandatory
mandatory
optional
mandatory
Mandatory
selection
selection
optional
Remote Result
Success
Failure
Reason
9.2.2.1.9
Response / Confirm
Initiate SDO Block Download
Through this service the client of SDO requests the server of SDO (owner of the Object Dictionary) to
prepare for downloading data to the server.
The multiplexor of the data set whose download is initiated and optionally the size of the downloaded
data in bytes are indicated to the server.
The client as well as the server indicating their ability and/or demand to verify the complete transfer
with a checksum in End SDO Block Download.
Table 13: Initiate SDO Block Download
Parameter
Request / Indication
Argument
SDO Number
Size
CRC ability
yes
no
Multiplexor
Mandatory
mandatory
optional
mandatory
selection
selection
mandatory
Response / Confirm
Mandatory
mandatory
mandatory
selection
selection
mandatory
Remote Result
Success
CRC ability
yes
no
Blksize
The service is confirmed. The Remote Result parameter will indicate the success of the request, the
number of segments per block the server of SDO is able to receive and its ability and/or demand to
verify the complete transfer with a checksum. In case of a failure, an Abort SDO Transfer request must
be executed.
9.2.2.1.10
Download SDO Block
By this service the client of SDO supplies the data of the next block to the server of SDO. The block
data is indicated to the server by a sequence of segments. Each segment consists of the data and a
sequence number starting with 1 which is increased for each segment by 1 up to blksize. The
parameter blksize is negotiated between server and client in the ÔInitiate Block DownloadÕ protocol and
can be changed by the server with each confirmation for a block transfer. The continue parameter
9-16
APPLICATION LAYER
CANopen
CiA
indicates the server whether to stay in the ÔDownload BlockÕ phase or to change in the ÔEnd Download
BlockÕ phase.
Table 14: Download SDO Block
Parameter
Request / Indication
Argument
SDO Number
Data
Continue
More
Last
Mandatory
mandatory
mandatory
mandatory
selection
selection
Response / Confirm
Mandatory
mandatory
mandatory
mandatory
Remote Result
Success
Ackseq
Blksize
The service is confirmed. The Remote Result parameter will indicate the success of the request. In
case of a success the ackseq parameter indicates the sequence number of the last segment the
server has received successfully. If this number does not correspond with the sequence number of the
last segment sent by the client during this block transfer the client has to retransmit all segments
discarded by the server with the next block transfer. In case of a fatal failure, an Abort SDO Transfer
request must be executed. In case of success, the server has accepted all acknowledged segment
data and is ready to accept the next block. There can be at most one Download SDO Block service
outstanding for a SDO transfer.
A successful 'Initiate SDO Block Download' service must have been executed prior to this service.
9.2.2.1.11
End SDO Block Download
Through this service the SDO Block Download is concluded.
The number of bytes not containing valid data in the last transmitted segments is indicated to the
server.
If the server as well as the client have indicated their ability and demand to check the complete
transfer with a checksum in ÔInitiate SDO Block DownloadÕ this checksum is indicated to the server by
the client. The server also has to generate a checksum which has to be compared with the one
generated by the client.
Table 15: End SDO Block Download
Parameter
Request / Indication
Argument
SDO Number
Valid_data
Ckecksum
Mandatory
mandatory
mandatory
mandatory if negotiated
in initiate
Response / Confirm
Mandatory
mandatory
Remote Result
Success
The service is confirmed. The Remote Result parameter will indicate the success of the request
(matching checksums between client and server if negotiated) and concludes the download of the
data set . In case of a failure, an Abort SDO Transfer request must be executed.
9.2.2.1.12
SDO Block Upload
Through this service the client of SDO uploads data from the server of SDO (owner of the Object
Dictionary) using the SDO block upload protocol. The data, the multiplexor (index and sub-index) of
the data set that has to be uploaded and optionally its size are indicated to the server.
The service is confirmed. The Remote Result parameter will indicate the success or failure of the
request. In case of a failure, optionally the reason is confirmed. In case of a success, the data and
optionally its size is confirmed.
9-17
APPLICATION LAYER
CANopen
CiA
Table 16: SDO Block Upload
Parameter
Request / Indication
Argument
SDO Number
Multiplexor
Mandatory
mandatory
mandatory
Mandatory
selection
mandatory
optional
selection
optional
Remote Result
Success
Data
Size
Failure
Reason
9.2.2.1.13
Response / Confirm
Initiate SDO Block Upload
Through this service the client of SDO requests the server of SDO (owner of the Object Dictionary) to
prepare for uploading data to the client.
The multiplexor of the data set whose upload is initiated and the number of segments the client of the
SDO is able to receive are indicated to the server.
A protocol switch threshold value is indicated to the server. If the number of bytes that has to be
uploaded is less or equal this value the server can optionally conclude this data transfer with the ÔSDO
Upload ProtocolÕ as described in 9.2.2.1.4.
The client as well as the server indicating their ability and/or demand to verify the complete transfer
with a checksum in End SDO Block Upload
Optionally the size of the uploaded data in bytes are indicated to the client.
Table 17: Initiate SDO Block Upload
Parameter
Request / Indication
Argument
SDO Number
Blksize
CRC ability
Yes
No
Multiplexor
Threshold
Mandatory
mandatory
mandatory
mandatory
selection
selection
mandatory
mandatory
Response / Confirm
Mandatory
mandatory
mandatory
selection
selection
optional
Remote Result
Success
CRC ability
Yes
No
Size
The service is confirmed. In case of a failure, an Abort SDO Transfer request must be executed. In
case of success the size of the data in bytes to be uploaded is optionally indicated to the client.
If the size of the data that has to be uploaded is less or equal threshold the server can continue with
the SDO block upload protocol. In this case the Remote Result parameter and the further protocol is
described in 9.2.2.2.14.
9.2.2.1.14
Upload SDO Block
Through this service the client of SDO uploads the data of the next block from the server of SDO. The
block data is indicated to the client by a sequence of segments. Each segment consists of the
segment data and a sequence number starting with 1 which is increased for each segment by 1 up to
blksize. The parameter blksize is negotiated between server and client in the ÔInitiate Block UploadÕ
protocol and can be changed by the client with each confirmation for a block transfer. The continue
parameter indicates the client whether to stay in the ÔUpload BlockÕ phase or to change in the ÔEnd
Upload BlockÕ phase.
9-18
APPLICATION LAYER
CANopen
CiA
Table 18: Upload SDO Block
Parameter
Request / Indication
Argument
SDO Number
Data
Continue
More
Last
Mandatory
mandatory
mandatory
mandatory
selection
selection
Response / Confirm
Mandatory
mandatory
mandatory
mandatory
Remote Result
Success
Ackseq
Blksize
The service is confirmed. The Remote Result parameter will indicate the success of the request. In
case of a success the ackseq parameter indicates the sequence number of the last segment the client
has received successfully. If this number does not correspond with the sequence number of the last
segment sent by the server during this block transfer the server has to retransmit all segments
discarded by the client with the next block transfer. In case of a fatal failure, an Abort SDO Transfer
request must be executed. In case of success, the client has accepted all acknowledged segment
data and is ready to accept the next block. There can be at most one Upload Block service
outstanding for a SDO transfer.
A successful 'Initiate SDO Block Upload' service must have been executed prior to this service.
9.2.2.1.15
End SDO Block Upload
Through this service the SDO Block Upload is concluded.
The number of bytes not containing valid data in the last transmitted segments is indicated to the
client.
If the server as well as the client have indicated their ability and demand to check the complete
transfer with a checksum during ÔInitiate SDO Block UploadÕ this checksum is indicated to the client by
the server. The client also has to generate a checksum which has to be compared with the one
generated by the server.
Table 19: End SDO Block Upload
Parameter
Request / Indication
Argument
SDO Number
Valid_data
Checksum
Mandatory
mandatory
mandatory
mandatory if negotiated
in initiate
Response / Confirm
Mandatory
mandatory
Remote Result
Success
The service is confirmed. The Remote Result parameter will indicate the success of the request
(matching checksums between client and server if demanded) and concludes the download of the
data set. In case of a failure, an Abort SDO Transfer request must be executed.
9-19
APPLICATION LAYER
9.2.2.2
CANopen
CiA
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 SDO
Transfer) are defined for Service Data Objects doing the standard segmented/expedited transfer.
Eight confirmed services (SDO Block Download, SDO Block Upload, Initiate SDO Upload, Initiate SDO
Block Download, Download SDO Segment, Upload SDO Segment, End SDO Upload and End SDO
Block Download) and one unconfirmed service (Abort SDO Block Transfer) are defined for Service
Data Objects doing the optional block transfer.
9.2.2.2.1
Client
Download SDO Protocol
SDO Download (normal)
Initiate SDO Download
Server
Client
(e=0)
SDO Download (expedited)
Initiate SDO Download
Server
(e=1)
Download SDO Segment (t=0, c=0)
Download SDO Segment (t=1, c=0)
Download SDO Segment (t=0, c=0)
Download SDO Segment (t=?, c=1)
Figure 16: Download SDO Protocol
This protocol is used to implement the SDO Download service. SDOs are downloaded as a sequence
of zero or more Download SDO Segment services preceded by an Initiate SDO Download service.
The sequence is terminated by:
· an Initiate SDO Download request/indication with the e-bit set to 1 followed by an Initiate SDO
Download response/confirm, indicating the successful completion of an expedited download
sequence.
· a Download SDO Segment response/confirm with the c-bit set to 1, indicating the successful
completion of a normal download sequence.
· an Abort SDO Transfer request/indication, indicating the unsuccessful completion of the download
sequence.
· a new Initiate Domain Download request/indication, indicating the unsuccessful completion of the
download sequence and the start of a new download sequence.
If in the download of two consecutive segments the toggle bit does not alter, the contents of the last
segment has to be ignored. If such an error is reported to the application, the application may decide
to abort the download.
9-20
APPLICATION LAYER
9.2.2.2.2
CANopen
CiA
Initiate SDO Download Protocol
This protocol is used to implement the Initiate SDO Download service for SDOs.
Initiate SDO Download
Client
0
1
7..5
ccs=1
4
X
3..2
n
1
e
Server
4
8
m
0
s
d
indication
request
0
confirm
1
7..5
scs=3
4..0
X
4
m
8
reserved
response
Figure 17: Initiate SDO Download Protocol
·
·
·
·
·
·
·
·
·
ccs: client command specifier
1:
initiate download request
scs: server command specifier
3:
initiate download response
n: Only valid if e = 1 and s = 1, otherwise 0. If valid it indicates the number of bytes in d that do not
contain data. Bytes [8-n, 7] do not contain data.
e: transfer type
0:
normal transfer
1:
expedited transfer
s: size indicator
0:
data set size is not indicated
1:
data set size is indicated
m: multiplexor. It represents the index/sub-index of the data to be transfer by the SDO.
d: data
e = 0, s = 0:
d is reserved for further use.
e = 0, s = 1:
d contains the number of bytes to be downloaded.
Byte 4 contains the lsb and byte 7 contains the msb.
e = 1, s = 1:
d contains the data of length 4-n to be downloaded,
the encoding depends on the type of the data referenced
by index and sub-index
e = 1, s = 0:
d contains unspecified number of bytes to be downloaded
X: not used, always 0
reserved: reserved for further use, always 0
9-21
APPLICATION LAYER
9.2.2.2.3
CANopen
CiA
Download SDO Segment Protocol
This protocol is used to implement the Download SDO Segment service.
Download SDO Segment
Client
0
Server
1
7..5
ccs=0
4
t
3..1
n
8
seg-data
0
c
indication
request
0
confirm
1
7..5
scs=1
4
t
8
reserved
3..0
X
response
Figure 18: Download SDO Segment Protocol
·
·
·
·
·
·
·
·
ccs: client command specifier
0:
download segment request
scs: server command specifier
1:
download segment response
seg-data: at most 7 bytes of segment data to be downloaded. The encoding depends on the type
of the data referenced by index and sub-index
n: indicates the number of bytes in seg-data that do not contain segment data. Bytes [8-n, 7] do
not contain segment data. n = 0 if no segment size is indicated.
c: indicates whether there are still more segments to be downloaded.
0
more segments to be downloaded
1:
no more segments to be downloaded
t: toggle bit. This bit must alternate for each subsequent segment that is downloaded. The first
segment will have the toggle-bit set to 0. The toggle bit will be equal for the request and the
response message.
X: not used, always 0
reserved: reserved for further use, always 0
9-22
APPLICATION LAYER
9.2.2.2.4
Initiate SDO Upload
CiA
Upload SDO Protocol
SDO Upload (normal)
Client
CANopen
Server
Client
(e=0)
SDO Upload (expedited)
Initiate SDO Upload
Server
(e=1)
Upload SDO Segment (t=0, c=0)
Upload SDO Segment (t=1, c=0)
Upload SDO Segment (t=0, c=0)
Upload SDO Segment (t=?, c=1)
Figure 19: Upload SDO Protocol
This protocol is used to implement the SDO Upload service. SDO are uploaded as a sequence of zero
or more Upload SDO Segment services preceded by an Initiate SDO Upload service. The sequence is
terminated by:
·
an Initiate SDO Upload response/confirm with the e-bit set to 1, indicating the successful
completion of an expedited upload sequence.
· an Upload SDO Segment response/confirm with the c-bit set to 1, indicating the successful
completion of a normal upload sequence.
· an Abort SDO Transfer request/indication, indicating the unsuccessful completion of the upload
sequence.
· a new Initiate SDO Upload request/indication, indicating the unsuccessful completion of the
upload sequence and the start of a new sequence.
If in the upload of two consecutive segments the toggle bit does not alter, the contents of the last
segment has to be ignored. If such an error is reported to the application, the application may decide
to abort the upload.
9-23
APPLICATION LAYER
9.2.2.2.5
CANopen
CiA
Initiate SDO Upload Protocol
This protocol is used to implement the Initiate SDO Upload service.
Initiate SDO Upload
Client
0
7..5
ccs=2
request
confirm
1
8
4
m
4..0
X
reserved
indication
0
1
7..5
scs=2
4
X
3..2
n
Server
1
e
4
m
0
s
8
d
response
Figure 20: Initiate SDO Upload Protocol
·
·
·
·
·
·
·
·
·
ccs: client command specifier
2:
initiate upload request
scs: server command specifier
2:
initiate upload response
n: Only valid if e = 1 and s = 1, otherwise 0. If valid it indicates the number of bytes in d that do not
contain data. Bytes [8-n, 7] do not contain segment data.
e: transfer type
0:
normal transfer
1:
expedited transfer
s: size indicator
0:
data set size is not indicated
1:
data set size is indicated
m: multiplexor. It represents the index/sub-index of the data to be transfer by the SDO.
d: data
e = 0, s = 0:
d is reserved for further use.
e = 0, s = 1:
d contains the number of bytes to be uploaded.
Byte 4 contains the lsb and byte 7 contains the msb.
e = 1, s = 1:
d contains the data of length 4-n to be uploaded,
the encoding depends on the type of the data referenced
by index and sub-index
e = 1, s = 0:
d contains unspecified number of bytes to be uploaded.
X: not used, always 0
reserved: reserved for further use , always 0
9-24
APPLICATION LAYER
9.2.2.2.6
CANopen
CiA
Upload SDO Segment Protocol
This protocol is used to implement the Upload SDO Segment service.
Upload SDO Segment
Client
0
confirm
1
7..5
ccs=3
request
Server
4
t
8
reserved
3..0
X
indication
0
1
7..5
scs=0
4
t
3..1
n
8
seg-data
0
c
response
Figure 21: Upload SDO Segment Protocol
·
·
·
·
·
·
·
·
ccs: client command specifier
3:
upload segment request
scs: server command specifier
0:
upload segment response
t: toggle bit. This bit must alternate for each subsequent segment that is uploaded. The first
segment will have the toggle-bit set to 0. The toggle bit will be equal for the request and the
response message.
c: indicates whether there are still more segments to be uploaded.
0:
more segments to be uploaded
1:
no more segments to be uploaded
seg-data: at most 7 bytes of segment data to be uploaded. The encoding depends on the type of
the data referenced by index and sub-index
n: indicates the number of bytes in seg-data that do not contain segment data. Bytes [8-n, 7] do
not contain segment data. n = 0 if no segment size is indicated.
X: not used, always 0
reserved: reserved for further use, always 0
9-25
APPLICATION LAYER
9.2.2.2.7
CANopen
CiA
Abort SDO Transfer Protocol
This protocol is used to implement the Abort SDO Transfer Service.
Client/Server
Server/Client
Abort SDO Transfer
0
1
7..5
cs=4
4..0
X
4
m
8
d
indication
request
Figure 22: Abort SDO Transfer Protocol
·
·
·
·
cs: command specifier
4:
abort transfer request
X: not used, always 0
m: multiplexor. It represents index and sub-index of the SDO.
d: contains a 4 byte abort code about the reason for the abort.
The abort code is encoded as UNSIGNED32 value.
Table 20: SDO abort codes
Abort code
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.
9-26
APPLICATION LAYER
CANopen
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-27
CiA
APPLICATION LAYER
9.2.2.2.8
CANopen
CiA
SDO Block Download Protocol
SDO_Block_Download
Client
Server
Initiate Block Download
Download Block
Download Block (normal)
Download Block (normal)
Download Block (last)
End Block Download
Download_Block (normal)
Client
Download_Block (last)
Server
Client
Server
Download segment 0 (c=0, seqno = 0)
Download segment 0 (c=0, seqno = 0)
Download segment 1 (c=0, seqno = 1)
Download segment 1 (c=0, seqno = 1)
Download segment n (c=0, seqno = n)
Download segment n (c=1, seqno = n)
Confirm block
Confirm block
Figure 23: SDO Block Download Protocol
This protocol is used to implement a SDO Block Download service. SDOs are downloaded as a
sequence of Download SDO Block services preceded by an Initiate SDO Block Download service. The
SDO Download Block sequence is terminated by:
· a downloaded segment within a block with the c-bit set to 1, indicating the completion of the block
download sequence.
·
an 'Abort SDO Transfer' request/indication, indicating the unsuccessful completion of the
download sequence.
The whole ÔSDO Block DownloadÕ service is terminated with the End SDO Block Download service. If
client as well as server have indicated the ability to generate a CRC during the Initiate SDO Block
Download service the server has to generate the CRC on the received data. If this CRC differs from
the CRC generated by the client the server has to indicate this with an ÔAbort SDO TransferÕ indication.
9-28
APPLICATION LAYER
9.2.2.2.9
CANopen
CiA
Initiate SDO Block Download Protocol
This protocol is used to implement the Initiate SDO Block Download service.
Initiate Block Download
Client
0
1
7..5
ccs=6
request
4..3
X
2
cc
1
s
4..3
X
2
sc
1..0
ss=0
size
indication
1
7..5
scs=5
8
4
m
0
cs=0
0
confirm
Server
4
m
5
blksize
8
reserved
response
Figure 24: Initiate SDO Block Download Protocol
·
·
·
ccs: client command specifier
6:
block download
scs: server command specifier
5:
block download
s: size indicator
0:
data set size is not indicated
1:
data set size is indicated
·
cs: client subcommand
0:
initiate download request
·
ss: server subcommand
0:
initiate download response
·
cc: client CRC support
cc = 0:
Client does not support generating CRC on data
cc = 1:
·
sc: server CRC support
sc = 0:
Server does not support generating CRC on data
sc = 1:
·
·
Client supports generating CRC on data
Server supports generating CRC on data
m: multiplexor. It represents the index/sub-index of the data to be transfer by the SDO.
size: download size in bytes
s = 0:
size is reserved for further use, always 0
s = 1:
size contains the number of bytes to be downloaded
Byte 4 contains the lsb and byte 7 the msb
·
·
·
blksize: Number of segments per block with 0 < blksize < 128.
X: not used, always 0
reserved: reserved for further use, always 0
9-29
APPLICATION LAYER
9.2.2.2.10
CANopen
CiA
Download SDO Block Segment Protocol
This protocol is used to implement the Block Download service.
Download Block Segment
Client
0
Server
1
8
c
8
seg-data
7..1
seqno
indication
request
confirm
0
1
7..5
scs=5
4..2
X
1..0
ss=2
2
ackseq
3
blksize
8
response
reserved
Figure 25: Download SDO Block Segment
·
scs: server command specifier
·
5:
block download
ss: server subcommand
·
2:
block download response
c: indicates whether there are still more segments to be downloaded
·
0: more segments to be downloaded
1: no more segments to be downloaded, enter End SDO block download phase
seqno: sequence number of segment 0 < seqno < 128.
·
seg-data: at most 7 bytes of segment data to be downloaded.
·
ackseq: sequence number of last segment that was received successfully during the last block
download. If ackseq is set to 0 the server indicates the client that the segment with the sequence
number 1 was not received correctly and all segments have to be retransmitted by the client.
·
·
blksize: Number of segments per block that has to be used by client for the following block
download with 0 < blksize < 128.
X: not used, always 0
·
reserved: reserved for further use, always 0
9-30
APPLICATION LAYER
9.2.2.2.11
CANopen
CiA
End SDO Block Download Protocol
This protocol is used to implement the End SDO Block Download service.
End Block Download
Client
0
1
7..5
ccs=6
4..2
n
1
X
0
cs=1
Server
3
crc
8
reserved
indication
request
confirm
0
8
1
7..5
scs=5
4..2
X
1..0
ss=1
response
reserved
Figure 26: End SDO Block Download Protocol
·
ccs: client command specifier
·
6:
block download
scs: server command specifier
·
5:
block download
cs: client subcommand
·
1:
end block download request
ss: server subcommand
·
1:
end block download response
n: indicates the number of bytes in the last segment of the last block that do not contain data.
Bytes [8-n, 7] do not contain segment data.
·
crc: 16 bit Cyclic Redundancy Checksum (CRC) for the whole data set. The algorithm for
generating the CRC is described in 9.2.2.2.16. CRC is only valid if in Initiate Block Download cc
and sc are set to 1 otherwise CRC has to be set to 0.
·
X: not used, always 0
·
reserved: reserved for further use, always 0
9-31
APPLICATION LAYER
9.2.2.2.12
Client
CANopen
CiA
Upload SDO Block Protocol
SDO_Block_Upload (normal)
Server
Client SDO_Block_Upload (fallback)
Initiate Block Upload (Phase I)
Initiate Block Upload (Phase I) (pst != 0)
Initiate Block Upload (Phase II)
Fallback to SDO Upload Protocol
Server
Upload Block (normal)
Upload Block (normal)
Upload Block (last)
End Block Upload
Client
Upload_Block (normal)
Server
Upload_Block (last)
Client
Upload segment 0 (c=0, seqno = 0)
Upload segment 0 (c=0, seqno = 0)
Upload segment 1 (c=0, seqno = 1)
Upload segment 1 (c=0, seqno = 1)
Upload segment n (c=0, seqno = n)
Upload segment n (c=1, seqno = n)
Confirm block
Confirm block
Server
Figure 27: Upload SDO Block Protocol
This protocol is used to implement a SDO Block Upload service which starts with the Initiate SDO
Block Upload service. The client can indicate a threshold value to the server which is the minimum
value in bytes to increase transfer performance using the SDO Block Upload protocol instead of the
SDO Upload protocol. If the data set size is less or equal this value the server can continue with the
normal or expedited transfer of the SDO Block Upload protocol.
Otherwise SDOs are uploaded as a sequence of Upload SDO Block services. The SDO Upload Block
sequence is terminated by:
¥ an uploaded segment within a block with the c-bit set to 1, indicating the completion of the block
upload sequence.
¥ an Abort SDO Transfer request/indication, indicating the unsuccessful completion of the uploaded
sequence.
The whole ÔSDO Block UploadÕ service is terminated with the ÔEnd SDO Block UploadÕ service. If client
as well as server have indicated the ability to generate a CRC during the Initiate SDO Block Upload
service the client has to generate the CRC on the received data. If this CRC differs from the CRC
generated by the server the client has to indicate this with an ÔAbort SDO TransferÕ indication.
9-32
APPLICATION LAYER
9.2.2.2.13
CANopen
CiA
Initiate SDO Block Upload Protocol
This protocol is used to implement the Initiate SDO Block Upload service. If the value of the Protocol
Switch Threshold parameter indicated by the client in the first request is less or equal the data set size
to be uploaded the server can continue with the SDO Upload Protocol as described in 9.2.2.2.4.
Initiate Block Upload
Client
0
1
7..5
ccs=5
request
4..2
X
2
cc
4
5
m
1..0
cs=0
blksize
1
7..5
scs=6
4..3
X
7..5
ccs=5
4..2
X
2
sc
0
1
s
6
pst
8
X
indication
0
confirm
Server
4
m
0
ss=0
8
1
1..0
cs=3
response
size
8
reserved
indication
request
Figure 28: Initiate SDO Block Upload Protocol
·
·
·
·
·
·
ccs: client command specifier
5:
block upload
scs: server command specifier
6:
block upload
cs: client subcommand
0:
initiate upload request
3:
start upload
ss: server subcommand
0:
initiate upload response
m: multiplexor. It represents the index/sub-index of the data to be transfer by the SDO.
cc: client CRC support
cc = 0:
Client does not support generating CRC on data
cc = 1:
·
sc: server CRC support
sc = 0:
Server does not support generating CRC on data
sc = 1:
·
Client supports generating CRC on data
Server supports generating CRC on data
pst: Protocol Switch Threshold in bytes to change the SDO transfer protocol
pst = 0: Change of transfer protocol not allowed.
pst > 0:
·
·
If the size of the data in bytes that has to be uploaded is less or equal pst the server
can optionally switch to the ÔSDO Upload ProtocolÕ by transmitting the server response
of the ÔSDO Upload ProtocolÕ as described in 9.2.2.2.4.
s: size indicator
0:
data set size is not indicated
1:
data set size is indicated
size: upload size in bytes
s = 0:
s = 1:
·
size is reserved for further use, always 0
size contains the number of bytes to be downloaded
Byte 4 contains the lsb and byte 7 the msb
blksize: Number of segments per block with 0 < blksize < 128.
·
X: not used, always 0
·
reserved: reserved for further use, always 0
9-33
APPLICATION LAYER
9.2.2.2.14
CANopen
CiA
Upload SDO Block Segment Protocol
This protocol is used to implement the SDO Block Upload service.
Figure 29: Upload SDO Block Segment Protocol
Upload Block
Client
0
Server
1
8
c
8
seg-data
7..1
seqno
request
indication
response
0
1
7..5
ccs=5
4..2
X
1..0
cs=2
2
ackseq
3
blksize
8
reserved
confirm
·
ccs: client command specifier
·
5:
block upload
cs: client subcommand
·
2:
block upload response
c: indicates whether there are still more segments to be downloaded
·
0:
more segments to be uploaded
1:
no more segments to be uploaded, enter ÔEnd block uploadÕ phase
seqno: sequence number of segment 0 < seqno < 128.
·
seg-data: at most 7 bytes of segment data to be uploaded.
·
ackseq: sequence number of last segment that was received successfully during the last block
upload. If ackseq is set to 0 the client indicates the server that the segment with the sequence
number 1 was not received correctly and all segments have to be retransmitted by the server.
·
blksize: Number of segments per block that has to be used by server for the following block
upload with 0 < blksize < 128.
·
X: not used, always 0
·
reserved: reserved for further use, always 0
9-34
APPLICATION LAYER
9.2.2.2.15
CANopen
CiA
End SDO Block Upload Protocol
This protocol is used to implement the End SDO Block Upload service.
End SDO Block Upload
Client
0
1
7..5
scs=6
4..2
n
7..5
ccs=5
4..2
X
Server
3
crc
1..0
ss=1
8
reserved
request
indication
response
1
0
1
X
8
reserved
0
cs=1
confirm
Figure 30: End SDO Block Upload Protocol
·
ccs: client command specifier
·
5:
block upload
scs: server command specifier
·
6:
block upload
cs: client subcommand
·
1:
end block upload request
ss: server subcommand
·
1:
end block upload response
n: indicates the number of bytes in the last segment of the last block that do not contain data.
Bytes [8-n, 7] do not contain segment data.
·
crc: 16 bit Cyclic Redundancy Checksum (CRC) for the whole data set. The algorithm for
generating the CRC is described in 9.2.2.2.16. CRC is only valid if in Initiate Block Upload cc and
sc are set to 1 otherwise crc has to be set to 0.
·
X: not used, always 0
·
reserved: reserved for further use, always 0
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 cyclic
redundancy checksum (CRC) which is exchanged and verified during End SDO Block
Download/Upload protocol. The check polynominal has the formula x^16Ê+Êx^15Ê+Êx^5Ê+Ê1.
9-35
APPLICATION LAYER
9.2.3
CANopen
CiA
Synchronisation Object (SYNC)
The Synchronisation Object is broadcasted periodically by the SYNC producer. This SYNC provides
the basic network clock. The time period between the SYNCs is specified by the standard parameter
communication cycle period (see Object 1006h: Communication Cycle Period), which may be
written by a configuration tool to the application devices during the boot-up process. There can be a
time jitter in transmission by the SYNC producer corresponding approximately to the latency due to
some other message being transmitted just before the SYNC.
In order to guarantee timely access to the CAN bus the SYNC is given a very high priority identifier
(1005h). Devices which operate synchronously may use the SYNC object to synchronise their own
timing with that of the Synchronisation Object producer. The details of this synchronisation are device
dependent and do not fall within the scope of this document. Devices which require a more accurate
common time base may use the high resolution synchronisation mechanism described in 9.3.2.
9.2.3.1
SYNC Services
The SYNC transmission follows the producer/consumer push model as described in 6.3.3. The service
is unconfirmed.
Attributes:
- user type:
one of the values {consumer, producer}
- data type:
nil
9.2.3.2
SYNC Protocol
One unconfirmed service (Write SYNC) is defined.
Write SYNC
SYNC Producer
SYNC consumer(s)
Write SYNC
Indication
Indication
request
L=0
Figure 31: SYNC Protocol
· The SYNC does not carry any data (L=0).
The Identifier of the SYNC object is located at Object Index 1005h.
9-36
Indication
APPLICATION LAYER
9.2.4
CANopen
CiA
Time Stamp Object (TIME)
By means of the Time Stamp Object a common time frame reference is provided to devices. It
contains a value of the type TIME_OF_DAY. The Identifier of the TIME Object is located at Object
Index 1012h.
9.2.4.1
TIME Services
The Time Stamp Object transmission follows the producer/consumer push model as described in
6.3.3. The service is unconfirmed.
Attributes:
- user type:
one of the values {consumer, producer}
- data type:
TIME_OF_DAY
9.2.4.2
TIME Protocol
One unconfirmed service (Write TIME) is defined.
Write TIME
TIME Producer
0
request
L=6
Time Stamp
Figure 32: TIME Protocol
·
TIME Consumer
Write TIME
Time Stamp: 6 bytes of the Time Stamp Object
9-37
Indication
Indication
Indication
APPLICATION LAYER
9.2.5
9.2.5.1
CANopen
CiA
Emergency Object (EMCY)
Emergency Object Usage
Emergency objects are triggered by the occurrence of a device internal error situation and are
transmitted from an emergency producer on the device. Emergency objects are suitable for interrupt
type error alerts. An emergency object is transmitted only once per 'error event'. As long as no new
errors occur on a device no further emergency objects must be transmitted.
The emergency object may be received by zero or more emergency consumers. The reaction on the
emergency consumer(s) is not specified and does not fall in the scope of this document.
By means of this specification emergency error codes (Table 21) and the error register (
Table 47) are specified. Device specific additional information and the emergency condition do not fall
into the scope of this specification.
Table 21: Emergency Error Codes
Error Code (hex)
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
8150
Transmit COB-ID
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-38
APPLICATION LAYER
CANopen
CiA
The emergency object is optional. If a device supports the emergency object, it has to support at least
the two error codes 00xx and 10xx. All other error codes are optional.
A device may be in one of two emergency states (Figure 33). Dependent on the transitions emergency
objects will be transmitted. Links between the error state machine and the NMT state machine are
defined in the device profiles.
0. After initialization the device enters the error free state if no error is detected. No error
message is sent.
1. The device detects an internal error indicated in the first three bytes of the emergency
message (error code and error register). The device enters the error state. An
emergency object with the appropriate error code and error register is transmitted. The
error code is filled in at the location of object 1003H (pre-defined error field).
2. One, but not all error reasons are gone. An emergency message containing error code
0000 (Error reset) may be transmitted together with the remaining errors in the error
register and in the manufacturer specific error field.
3. A new error occurs on the device. The device remains in error state and transmits an
emergency object with the appropriate error code. The new error code is filled in at the
top of the array of error codes (1003H). It has to be guaranteed that the error codes are
sorted in a timely manner (oldest error - highest sub-index, see Object 1003H).
4. All errors are repaired. The device enters the error free state and transmits an
emergency object with the error code Ôreset error / no error'.
0
error free
4
1
2
3
error occurred
Figure 33: Emergency State Transition Diagram
9.2.5.2
Emergency Object Data
The Emergency Telegram consists of 8 bytes with the data as shown in Figure 34: Emergency Object
Data.
Byte
Content
0
1
Emergency Error
Code
(see Table 21)
2
3
Error
register
(Object
1001H)
4
6
Manufacturer specific Error Field
Figure 34: Emergency Object Data
9-39
5
7
APPLICATION LAYER
9.2.5.3
CANopen
CiA
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:
9.2.5.4
Application specific
Emergency Object Protocol
One unconfirmed service (Write EMCY) is defined.
Write EMCY
EMCY Producer
EMCY Consumer
Write EMCY
Indication
0
Request
8
Emergency Object Data
Indication
Indication
Figure 35: Emergency Object Protocol
Is is not allowed to request an Emergency Object by a remote transmission request (RTR).
9-40
APPLICATION LAYER
9.2.6
CANopen
CiA
Network Management Objects
The Network Management (NMT) is node oriented and follows a master-slave structure. NMT objects
are used for executing NMT services. Through NMT services, nodes are initialised, started, monitored,
resetted or stopped. All nodes are regarded as NMT slaves. An NMT Slave is uniquely identified in the
network by its Node-ID, a value in the range of [1..127].
NMT requires that one device in the network fulfils the function of the NMT Master.
9.2.6.1
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 state
attribute is one of the values {STOPPED, PRE-OPERATIONAL, OPERATIONAL, INITIALISING}. The
Module Control Services can be performed with a certain node or with all nodes simultaneously. The
NMT master controls its own NMT state machine via local services, which are implementation
dependent. The Module Control Services except Start Remote Node can be initiated by the local
application.
Start Remote Node
Through this service the NMT Master sets the state of the selected NMT Slaves to OPERATIONAL.
Table 22: Start Remote Node
Parameter
Indication/Request
Argument
Node-ID
All
Mandatory
selection
selection
The service is unconfirmed and mandatory. After completion of the service, the state of the selected
remote nodes will be OPERATIONAL.
Stop Remote Node
Through this service the NMT Master sets the state of the selected NMT Slaves to STOPPED.
Table 23: Stop Remote Node
Parameter
Request/Indication
Argument
Node-ID
All
Mandatory
selection
selection
The service is unconfirmed and mandatory. After completion of the service, the state of the selected
remote nodes will be STOPPED.
Enter Pre-Operational
Through this service the NMT Master sets the state of the selected NMT Slave(s) to "PREOPERATIONAL".
Table 24: Enter Pre-Operational
Parameter
Request/Indication
Argument
Node-ID
All
Mandatory
selection
selection
The service is unconfirmed and mandatory for all devices. After completion of the service, the state of
the selected remote nodes will be PRE-OPERATIONAL.
9-41
APPLICATION LAYER
CANopen
CiA
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
Parameter
Request/Indication
Argument
Node-ID
All
Mandatory
selection
selection
The service is unconfirmed and mandatory for all devices. After completion of the service, the state of
the selected remote nodes will be RESET APPLICATION.
Reset Communication
Through this service the NMT Master sets the state of the selected NMT Slave(s) from any state to the
"reset communication" sub-state. After completion of the service, the state of the selected remote
nodes will be RESET COMMUNICATION.
Table 26: Reset Communication
Parameter
Request/Indication
Argument
Node-ID
All
Mandatory
selection
selection
The service is unconfirmed and mandatory for all devices.
9.2.6.1.2
Error Control Services
Through Error control services the NMT detects failures in a CAN-based Network.
Local errors in a node may e.g. lead to a reset or change of state. The definition of these local errors
does not fall into the scope of this specification.
Error Control services are achieved principally through periodically transmitting of messages by a
device. There exist two possibilities to perform Error Control.
The guarding is achieved through transmitting guarding requests (Node guarding protocol) by the
NMT Master. If a NMT Slave has not responded within a defined span of time (node life time) or if the
NMT SlaveÕs communication status has changed, the NMT Master informs its NMT Master Application
about that event.
If Life guarding (NMT slave guarded NMT master) is supported, the slave uses the guard time and lifetime factor from its Object Dictionary to determine the node life time. If the NMT Slave is not guarded
within its life time, the NMT Slave informs its local Application about that event. If guard time and life
time factor are 0 (default values), the NMT Slave does not guard the NMT Master.
Guarding starts for the slave when the first remote-transmit-request for its guarding identifier is
received. This may be during the boot-up phase or later.
The heartbeat mechanism for a device is established through cyclically transmitting a message by a
heartbeat producer. One or more devices in the network are aware of this heartbeat message. If the
heartbeat cycle fails for the heartbeat producer the local application on the heartbeat consumer will be
informed about that event.
The implementation of either guarding or heartbeat is mandatory.
Node Guarding Event
Through this service, the NMT service provider on the NMT Master indicates that a remote error
occurred or has been resolved for the remote node identified by Node-ID.
9-42
APPLICATION LAYER
CANopen
Table 27: Node Guarding Event
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 error
occurred or has been resolved.
Table 28: Life Guarding Event
Parameter
Indication
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 been
resolved for the node identified by Node-ID.
Table 29: Heartbeat Event
Parameter
Indication
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 state
INITIALISING to the state PRE-OPERATIONAL.
Table 30: Bootup Event
Parameter
Indication
Argument
None
Mandatory
The service is provider initiated and mandatory.
9-43
CiA
APPLICATION LAYER
CANopen
9.2.6.2
NMT Protocols
9.2.6.2.1
Module Control Protocols
CiA
Start Remote Node Protocol
This protocol is used to implement the 'Start Remote Node' service.
NMT Master
NMT Slave(s)
Start Remote Node
0
CS=1
Request
request
1
2
Node-ID
Indication(s)
indication
indication
indication
COB-ID = 0
Figure 36: Start Remote Node Protocol
·
cs: NMT command specifier
1:
·
start
Node-ID: the Node-ID of the NMT Slave as assigned by the NMT Master in the Node Connect
Protocol, or 0. If 0, the protocol addresses all NMT Slaves.
Stop Remote Node Protocol
This protocol is used to implement the 'Stop Remote Node' service.
NMT Master
NMT Slave(s)
Stop Remote Node
Request
request
0
CS=2
1
2
Node-ID
Indication(s)
COB-ID = 0
indication
indication
indication
Figure 37: Stop Remote Node Protocol
·
cs: NMT command specifier
·
2:
stop
Node-ID: the Node-ID of the NMT Slave as assigned by the NMT Master in the Node Connect
Protocol, or 0. If 0, the protocol addresses all NMT Slaves.
9-44
APPLICATION LAYER
CANopen
CiA
Enter Pre-Operational Protocol
The protocol is used to implement the 'Enter_Pre-Operational' service.
NMT Master
NMT Slave(s)
Enter Pre-Operational
0
1
2
CS=128 Node-ID
Request
request
Indication(s)
indication
indication
indication
COB-ID = 0
Figure 38: Enter Pre-Operational Protocol
·
cs: NMT command specifier
128: enter PRE-OPERATIONAL
Node-ID: the Node-ID of the NMT Slave as assigned by the NMT Master in the Node Connect
Protocol, or 0. If 0, the protocol addresses all NMT Slaves.
Reset Node Protocol
The protocol is used to implement the 'Reset Node' service.
NMT Master
NMT Slave(s)
Reset Node
Request
request
0
1
2
CS=129 Node-ID
Indication(s)
COB-ID = 0
indication
indication
indication
Figure 39: Reset Node Protocol
cs: NMT command specifier
129: Reset_Node
Node-ID: the Node-ID of the NMT Slave as assigned by the NMT Master in the Node Connect
Protocol, or 0. If 0, the protocol addresses all NMT Slaves.
9-45
APPLICATION LAYER
CANopen
CiA
Reset Communication Protocol
The protocol is used to implement the 'Reset Communication' service.
NMT Master
NMT Slave(s)
Reset Communication
Request
request
0
1
2
CS=130 Node-ID
Indication(s)
COB-ID = 0
indication
indication
indication
Figure 40: Reset Communication Protocol
cs: NMT command specifier
130: Reset_Communication
Node-ID: the Node-ID of the NMT Slave as assigned by the NMT Master in the Node Connect
Protocol, or 0. If 0, the protocol addresses all NMT Slaves.
9-46
APPLICATION LAYER
9.2.6.2.2
CANopen
CiA
Error Control Protocols
Node Guarding Protocol
This protocol is used to detect remote errors in the network. Each NMT Slave uses one remote COB
for the Node Guarding Protocol. This protocol implements the provider initiated Error Control services.
Node/Life Guarding
NMT Master
COB-ID = 1792 + Node-ID
Remote transmit request
request
NMT Slave
indication
0
1
7
t
confirm
6...0
s
response
Node
Guard
time
COB-ID = 1792 + Node-ID
Remote transmit request
Node
Life
Time
request
indication
0
confirm
1
7
t
6...0
s
Node Guarding Event*
response
Life Guarding Event*
indication
indication
*if guarding error
Figure 41: Node Guarding Protocol
s: the state of the NMT Slave
4:
STOPPED
5:
OPERATIONAL
127: PRE-OPERATIONAL
t: toggle bit. The value of this bit must alternate between two consecutive responses from the NMT
Slave. The value of the toggle-bit of the first response after the Guarding Protocol becomes active,
is 0. The Toggle Bit in the guarding protocol is only resetted to 0 when reset_communication is
passed (no other change of state resets the toggle bit). If a response is received with the same
value of the toggle-bit as in the preceding response then the new response is handled as if it was
not received.
The NMT Master polls each NMT Slave at regular time intervals. This time-interval is called the guard
time and may be different for each NMT Slave. The response of the NMT Slave contains the state of
that NMT Slave. The node life time is given by the guard time multiplied by the life time factor. The
node life time can be different for each NMT Slave. If the NMT Slave has not been polled during its life
time, a remote node error is indicated through the 'Life Guarding Event' service.
A remote node error is indicated through the 'Node guarding event' service if
· The remote transmit request is not confirmed within the node life time
· The reported NMT slave state does not match the expected state
If it has been indicated that a remote error has occurred and the errors in the guarding protocol have
disappeared, it will be indicated that the remote error has been resolved through the 'Node Guarding
Event' and 'Life Guarding Event' services.
9-47
APPLICATION LAYER
CANopen
CiA
For the guard time, and the life time factor there are default values specified at the appropriate Object
Dictionary entries.
Heartbeat Protocol
The Heartbeat Protocol defines an Error Control Service without need for remote frames. A Heartbeat
Producer transmits a Heartbeat message cyclically. One or more Heartbeat Consumer receive the
indication. The relationship between producer and consumer is configurable via the object dictionary.
The Heartbeat Consumer guards the reception of the Heartbeat within the Heartbeat Consumer Time.
If the Heartbeat is not received within the Heartbeat Consumer Time a Heartbeat Event will be
generated.
Write Heartbeat
COB-ID = 1792 + Node-ID
Heartbeat
Producer
0
1
7
r
request
6 .. 0
s
indication
indication
indication
Heartbeat
Producer
Time
0
request
Heartbeat
Consumer
1
7
r
6 .. 0
s
Heartbeat
Consumer
Time
indication
indication
indication
Heartbeat
Consumer
Time
Heartbeat Event
Figure 42: Heartbeat Protocol
r: reserved (always 0)
s: the state of the Heartbeat producer
0:
BOOTUP
4:
STOPPED
5:
OPERATIONAL
127: PRE-OPERATIONAL
If the Heartbeat Producer Time is configured on a device the Heartbeat Protocol begins immediately. If
a device starts with a value for the Heartbeat Producer Time unequal to 0 the Heartbeat Protocol
starts on the state transition from INITIALISING to PRE-OPERATIONAL. In this case the Bootup
Message is regarded as first heartbeat message. It is not allowed for one device to use both error
control mechanisms Guarding Protocol and Heartbeat Protocol at the same time. If the heartbeat
producer time is unequal 0 the heartbeat protocol is used.
9-48
APPLICATION LAYER
9.2.6.2.3
CANopen
CiA
Bootup Protocol
This protocol is used to signal that a NMT slave has entered the node state PRE-OPERATIONAL after
the state INITIALISING. The protocol uses the same identifier as the error control protocols.
Bootup Event
NMT Master
COB-ID = 1792 + Node-ID
0
NMT Slave
1
0
indication
Heartbeat
Consumer(s)
request
indication(s)
Figure 43: Bootup Protocol
One data byte is transmitted with value 0.
9.3
9.3.1
Synchronisation of the SYNC Consumer
Transmission of Synchronous PDO Messages
Synchronous transmission of a message means that the transmission of the message is fixed in time
with respect to the transmission of the SYNC message. The synchronous message is transmitted
within a given time window with respect to the SYNC transmission, and at most once for every period
of the SYNC.
In general the fixing of the transmission time of synchronous PDO messages coupled with the
periodicity of transmission of the SYNC message guarantees that devices may arrange to sample
process variables from a process environment and apply their actuation in a co-ordinated fashion.
A device consuming SYNC messages will provide synchronous PDO messages too. The reception of
a SYNC message controls the moment when the application will interact with the process environment
according to the contents of a synchronous PDO. The synchronous mechanism is intended for
transferring commanded values and actual values on a fixed timely base.
In general a synchronous PDO with a commanded value will be received before a SYNC. The SYNC
consuming device will actuate based on this synchronous PDO at the next SYNC message. The
reception of a SYNC will also prompt a device operating in the cyclic mode to sample its feedback
data and transmit a synchronous PDO with an actual value as soon as possible afterwards.
Depending upon its capabilities, a device may also be parameterised with the time period
synchronous window length after the SYNC at which it is guaranteed that its commanded value has
arrived. It may therefore perform any processing on the commanded value which is required in order
to actuate at the next SYNC message.
9-49
APPLICATION LAYER
CANopen
CiA
communication cycle period
Synchronous window length
SYNC
Message
SYNC
Message
objects mapped in
Actuate on
synchronous RPDO
objects mapped
in last received
synchronous
RPDO
objects mapped in
Actuate on
synchronous RPDO
objects mapped
in last received
synchronous
RPDO
Actuation based on objects mapped in last
received synchronous RPDO at next SYNC
Figure 44: Bus Synchronisation and Actuation
communication cycle period
synchronous window length
SYNC
Message object mapped
in synchronous
TPDO
SYNC
Message object mapped
in synchronous
TPDO
Samples immediately taken at SYNC
for objects mapped in synchronous TPDO
Figure 45: Bus Synchronisation and Sampling
9.3.2
Optional High Resolution Synchronisation Protocol
The synchronisation message carries no data and is easy to generate. However, the jitter of this
SYNC depends on the bit rate of the bus as even the very high priority SYNC has to wait for the
current message on the bus to be transmitted before it gains bus access.
Some time critical applications especially in large networks with reduced transmission rates require
more accurate synchronisation; it may be necessary to synchronise the local clocks with an accuracy
in the order of microseconds. This is achieved by using the optional high resolution synchronisation
protocol which employs a special form of time stamp message (see Figure 46) to adjust the inevitable
drift of the local clocks.
The SYNC producer time-stamps the interrupt generated at t1 by the successful transmission of the
SYNC message (this takes until t2). After that (at t4) he sends a time-stamp message containing the
corrected time-stamp (t1) for the SYNC transmission success indication. The SYNC consumer that
have taken local time-stamps (t3) on the reception (t1) of the SYNC can now compare their corrected
time-stamp (t1) with the one received in the time-stamp message from the SYNC producer. The
difference between these values determines the amount of time to adjust the local clock. With this
protocol only the local latencies (t2-t1 on the SYNC producer and t3-t1 on the SYNC consumer ) are
time critical. These latencies depend on local parameters (like interrupt processing times and
hardware delays) on the nodes which have to be determined once. The accuracy of this determination
9-50
APPLICATION LAYER
CANopen
CiA
is implementation specific, it forms the limiting factor of the synchronisation (or clock adjustment)
accuracy. Note that each node only has to know its own latency time as the time-stamp message
contains the corrected value t1 and not t2.
The time-stamp is encoded as UNSIGNED32 with a resolution of 1 microsecond which means that the
time counter restarts every 72 minutes. It is configured by mapping the high resolution time-stamp into
a PDO.
It is reasonable to repeat the clock adjustment only when the maximum drift of the local clock exceeds
the synchronisation accuracy. For most implementations this means that it is sufficient to add this
time-stamp message to the standard SYNC once every second.
This principle enables the best accuracy that can be achieved with bus-based synchronisation,
especially when implemented on CAN controllers that support time-stamping. Note that the accuracy
is widely independent of the transmission rate. Further improvement requires separate hardware (e.g.
wiring).
SYNC
TIMESTAMP
master
slave
time
t1 t2 t3
t4
t5
Figure 46: Optional High Resolution Synchronisation Protocol
9-51
APPLICATION LAYER
9.4
CANopen
CiA
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 Master
Application or Configuration Application is shown.
Configuration of all device parameters,
including communication parameters
(via Default SDO)
A
(Optional)
start transmission of SYNC, wait for
synchronisation of all devices
B
(Optional)
Start of Node Guarding
C
Setting of all nodes to
the operational state
D
Figure 47: Flow Chart of the Network Initialisation Process
In step A the devices are in the node state PRE-OPERATIONAL which is entered automatically after
power-on. In this state the devices are accessible via their Default-SDO using identifiers that have
been assigned according to the Predefined Connection Set. In this step the configuration of device
parameters takes place on all nodes which support parameter configuration.
This is done from a Configuration Application or Tool which resides on the node that is the client for
the default SDOs. For devices that support these features the selection and/or configuration of PDOs,
the mapping of application objects (PDO mapping), the configuration of additional SDOs and
optionally the setting of COB-IDs may be performed via the Default-SDO objects.
In many cases a configuration is not even necessary as default values are defined for all application
and communication parameters.
If the application requires the synchronisation of all or some nodes in the network, the appropriate
mechanisms can be initiated in the optional Step B. It can be used to ensure that all nodes are
synchronised by the SYNC object before entering the node state OPERATIONAL in step D. The first
transmission of SYNC object starts within 1 sync cycle after entering the PRE-OPERATIONAL state.
In Step C Node guarding can be activated (if supported) using the guarding parameters configured in
step A.
With step D all nodes are enabled to communicate via their PDO objects.
9.4.2
9.4.2.1
NMT State Machine
Overview
In Figure 48 the state diagram of a device is shown. Devices enter the PRE-OPERATIONAL state
directly after finishing the device initialisation. During this state device parameterisation and IDallocation via SDO (e.g. using a configuration tool) is possible. Then the nodes can be switched
directly into the OPERATIONAL state.
The NMT state machine determines the behaviour of the Communication function unit (see 6.2). The
coupling of the application state machine to the NMT state machine is device dependent and falls into
the scope of device profiles.
9-52
APPLICATION LAYER
CANopen
CiA
Minimal Boot-Up consists of one CAN telegram: a broadcast Start_Remote_Node message.
Figure 48: State Diagram of a Device
Power on or Hardware Reset
(1)
Initialisation
(2)
(11)
(14)
Pre-Operational
(7)
(13)
(4)
(3)
(10)
(5)
Stopped
(6)
(12)
(8)
(9)
Operational
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
9-53
APPLICATION LAYER
CANopen
9.4.2.2
States
9.4.2.2.1
Initialisation
CiA
The ãinitialisationÒ state is divided into three sub-states (see Figure 49) in order to enable a complete
or partial reset of a node.
1. Reset_Application: In this state the parameters of the manufacturer specific profile area and of
the standardised device profile area are set to their power-on values. After setting of the power-on
values the state Reset_Communication is entered autonomously.
2. Reset_Communication: In this state the parameters of the communication profile area are set to
their power-on values. After this the state Initialising is entered autonomously.
3. Initialising: This is the first sub-state the device enters after power-on or hardware reset. After
finishing the basic node initialisation the device executes the write boot-up object service and
enters the state PRE-OPERATIONAL autonomously.
Power-on values are the last stored parameters. If storing is not supported or has not been executed
or if the reset was preceded by a restore_default command (object 1011H), the power-on values are
the default values according to the communication and device profile specifications.
Reset
Application
(15)
Initialisation
Reset
Communication
(16)
(11)
Initialising
(14)
(10)
(13)
(12)
(9)
power-on or
hardware reset
(2)
(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
9-54
APPLICATION LAYER
9.4.2.2.2
CANopen
CiA
Pre-Operational
In the PRE-OPERATIONAL state, communication via SDOs is possible. PDOs do not exist, so PDO
communication is not allowed. Configuration of PDOs, device parameters and also the allocation of
application objects (PDO-mapping) may be performed by a configuration application.
The node may be switched into the operational state directly by sending a Start_Remote_Node
request.
9.4.2.2.3
Operational
In the OPERATIONAL state all communication objects are active. Transitioning to OPERATIONAL
creates all PDOs; the constructor uses the parameters as described in the Object Dictionary. Object
Dictionary Access via SDO is possible. Implementation aspects or the application state machine
however may require to limit the access to certain objects whilst being operational, e.g. an object may
contain the application program which cannot be changed during execution.
9.4.2.2.4
Stopped
By switching a device into the Stopped state it is forced to stop the communication altogether (except
node guarding and heartbeat, if active). Furthermore, this state can be used to achieve certain
application behaviour. The definition of this behaviour falls into the scope of device profiles.
9.4.2.3
States and Communication Object Relation
Table 32 shows the relation between communication states and communication objects. Services on
the listed communication objects may only be executed if the devices involved in the communication
are in the appropriate communication states.
Table 32: States and Communication Objects
INITIALISING
PRE-OPERATIONAL
PDO
OPERATIONAL
X
SDO
X
X
Synchronisation Object
X
X
Time Stamp Object
X
X
Emergency Object
X
X
X
X
Boot-Up Object
X
Network Management
Objects
9.4.2.4
STOPPED
X
State Transitions
State transitions are caused by
· reception of an NMT object used for module control services
· hardware reset
· Module Control Services locally initiated by application events, defined by device profiles
9.4.3
Pre-Defined Connection Set
In order to reduce configuration effort for simple networks a mandatory default identifier allocation
scheme is defined. These identifiers are available in the PRE-OPERATIONAL state directly after
initialisation (if no modifications have been stored). The objects SYNC, TIME STAMP, EMERGENCY
and PDOs may be deleted and re-created with new identifiers by means of dynamic distribution. A
device has to provide the corresponding identifiers only for the supported communication objects.
The default profile ID-allocation scheme (Table 33 and Table 34) consists of a functional part, which
determines the object priority and a Node-ID-part, which allows to distinguish between devices of the
same functionality. This allows a peer-to-peer communication between a single master device and up
9-55
APPLICATION LAYER
CANopen
CiA
to 127 slave devices. It also supports the broadcasting of non-confirmed NMT-objects, SYNC- and
TIME-STAMP-objects. Broadcasting is indicated by a Node-ID of zero.
The pre-defined connection set supports one emergency object, one SDO, at maximum 4 ReceivePDOs (RPDO) and 4 Transmit-PDOs (TPDO) and the NMT objects.
10
Bit-No.:
COB-Identifier
0
Function Code
Node-ID
Figure 50: Identifier allocation scheme for the pre-defined connection set
Table 33 and Table 34 show the supported objects and their allocated COB-IDs.
Table 33: Broadcast Objects of the Pre-defined Connection Set
object
NMT
SYNC
TIME STAMP
function code
(binary)
0000
0001
0010
resulting COB-ID
0
128 (80h)
256 (100h)
Communication Parameters
at Index
1005h, 1006h, 1007h
1012h, 1013h
Table 34: Peer-to-Peer Objects of the Pre-defined Connection Set
object
EMERGENCY
PDO1 (tx)
PDO1 (rx)
PDO2 (tx)
PDO2 (rx)
PDO3 (tx)
PDO3 (rx)
PDO4 (tx)
PDO4 (rx)
SDO (tx)
SDO (rx)
NMT Error
Control
function code
(binary)
0001
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1110
Resulting COB-IDs
129 (81h) Ð 255 (FFh)
385 (181h) Ð 511 (1FFh)
513 (201h) Ð 639 (27Fh)
641 (281h) Ð 767 (2FFh)
769 (301h) Ð 895 (37Fh)
897 (381h) Ð 1023 (3FFh)
1025 (401h) Ð 1151 (47Fh)
1153 (481h) Ð 1279 (4FFh)
1281 (501h) Ð 1407 (57Fh)
1409 (581h) Ð 1535 (5FFh)
1537 (601h) Ð 1663 (67Fh)
1793 (701h) Ð 1919 (77Fh)
Communication Parameters
at Index
1014h, 1015h
1800h
1400h
1801h
1401h
1802h
1402h
1803h
1403h
1200h
1200h
1016h, 1017h
Table 34 has to be seen from the devices point of view.
The pre-defined connection set always applies to the standard CAN frame with 11-bit Identifier, even if
extended CAN frames are present in the network.
9.5
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. The
format of the Object Dictionary entries is shown in Table 35 below:
Table 35: Format of Object Dictionary Headings
Index
Object
(hex)
(Symbolic Name)
Name
Type
Attrib.
M/O
The complete Object Dictionary consists of the six columns shown above. The Index column denotes
the objects position within the Object Dictionary. This acts as a kind of address to reference the
desired data field. The sub-index is not specified here. The sub-index is used to reference data fields
within a complex object such as an array or record.
9-56
APPLICATION LAYER
CANopen
CiA
The Object column contains the Object Name according to Table 36 below and is used to denote
what kind of object is at that particular index within the Object Dictionary. The following definitions are
used:
Table 36: Object Dictionary Object Definitions
Object Name
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 a
Boolean, UNSIGNED16, float and so
on
5
DEFSTRUCT
Defines a new record type e.g. the
PDOMapping structure at 21h
6
VAR
A single value such
UNSIGNED8,
Boolean,
Integer16, visible string etc.
an
float,
7
ARRAY
A multiple data field object where
each data field is a simple variable of
the SAME basic data type e.g. array
of UNSIGNED16 etc. Sub-index 0 is
of UNSIGNED8 and therefore not part
of the ARRAY data
8
RECORD
A multiple data field object where the
data fields may be any combination of
simple variables. Sub-index 0 is of
UNSIGNED8 and therefore not part of
the RECORD data
9
as
The name column provides a simple textual description of the function of that particular object. The
type column gives information as to the type of the object. These include the following pre-defined
types: BOOLEAN, floating point number, UNSIGNED Integer, Signed Integer, visible/octet string, timeof-day, time-difference and DOMAIN (see 9.1). It also includes the pre-defined complex data type
PDOMapping and may also include others which are either manufacturer or device specific. It is not
possible to define records of records, arrays of records or records with arrays as fields of that record.
In the case where an object is an array or a record the sub-index is used to reference one data field
within the object.
The Attribute column defines the access rights for a particular object. The view point is from the bus
into the device.
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 be
implemented on a device. An optional object needs not to be implemented on a device. The support of
certain objects or features however may require the implementation of related objects. In this case, the
relations are described in the detailed object specification.
9-57
APPLICATION LAYER
9.5.2
CANopen
CiA
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 data
types. The range of indices from 24h - 3Fh is not defined yet but reserved for future standard data
structures.
The range of indices from 40h - 5Fh is free for manufacturers to define own complex data types. The
range 60h - 7Fh contains device profile specific standard data types. From 80h Ð 9Fh device profile
specific complex data types are defined. The range A0h Ð 25Fh is reserved for the data type
definitions for Multiple Device Modules similar to the entries 60h Ð 9Fh. The entries form 360h Ð FFFh
are reserved for possible future enhancements . The range 1000h - 1FFFh contains the
communication specific Object Dictionary entries.
These parameters are called communication entries, their specification is common to all device types,
regardless of the device profile they use. The objects in range 1000h - 1FFFh not specified by this
document are reserved for further use. The range 2000h - 5FFFh is free for manufacturer specific
profile definition.
The range 6000h - 9FFFh contains the standardised device profile parameters. The range A000h FFFFh is reserved for future use.
9.5.3
Data Type Entry Specification
The static data types are placed in the Object Dictionary for definition purposes only. However, indices
in the range 0001h - 0007h can be mapped as well in order to define the appropriate space in the
RPDO as not being used by this device (do not care). The indices 0009h - 000Bh, 000Fh can not be
mapped in a PDO.
The order of the data types is as follows:
Table 38: Object Dictionary Data Types
Index
Object
Name
0001
DEFTYPE
BOOLEAN
0002
DEFTYPE
INTEGER8
0003
DEFTYPE
INTEGER16
0004
DEFTYPE
INTEGER32
0005
DEFTYPE
UNSIGNED8
0006
DEFTYPE
UNSIGNED16
0007
DEFTYPE
UNSIGNED32
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
reserved
000F
DEFTYPE
DOMAIN
0010
DEFTYPE
INTEGER24
0011
DEFTYPE
REAL64
0012
DEFTYPE
INTEGER40
0013
DEFTYPE
INTEGER48
0014
DEFTYPE
INTEGER56
0015
DEFTYPE
INTEGER64
0016
DEFTYPE
UNSIGNED24
0017
reserved
9-58
APPLICATION LAYER
CANopen
0018
DEFTYPE
UNSIGNED40
0019
DEFTYPE
UNSIGNED48
001A
DEFTYPE
UNSIGNED56
001B
DEFTYPE
UNSIGNED64
001C-001F
CiA
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
0140-015F
DEFSTRUCT
Device Profile 3 Specific Complex Data Types
0160-017F
DEFTYPE
Device Profile 4 Specific Standard Data Types
0180-019F
DEFSTRUCT
Device Profile 4 Specific Complex 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
0200-021F
DEFSTRUCT
Device Profile 6 Specific Complex Data Types
0220-023F
DEFTYPE
Device Profile 7 Specific Standard Data Types
0240-025F
DEFSTRUCT
Device Profile 7 Specific Complex Data Types
The data type representations used are detailed in 9.1. Every device does not need to support all the
defined data types. A device only has to support the data types it uses with the objects in the range
1000h - 9FFFh.
The predefined complex data-types are placed after the standard data-types. Four types are defined
at present, the PDO CommPar record (PDO_COMMUNICATION_PARAMETER), the PDO Mapping
record (PDO_MAPPING), the SDO Parameter record (SDO_PARAMETER) and the Identity record
(IDENTITY). They are placed at index 20h, 21h, 22h and 23h.
For devices or device profiles that provide Multiple Device Modules like multiple axis controllers e.g.
the DEFTYPE / DEFSTRUCT mechanism is enhanced for each virtual device with an offset of 40h for
up to 7 additional virtual devices.
A device may optionally provide the length of the standard data types encoded as UNSIGNED32 at
read access to the index that refers to the data type. E.g. index 000Ch (Time of Day) contains the
value 30h=48dec as the data type ãTime of DayÒ is encoded using a bit sequence of 48 bit. If the
length is variable (e.g. 000Fh = Domain), the entry contains 0h.
For the supported complex data types a device may optionally provide the structure of that data type
at read access to the corresponding data type index. Sub-index 0 then provides the number of entries
at this index not counting sub-indices 0 and 255 and the following sub-indices contain the data type
according to Table 38 encoded as UNSIGNED8. The entry at Index 20h describing the structure of
the PDO Communication Parameter then looks as follows (see also objects 1400h Ð 15FFh):
9-59
APPLICATION LAYER
CANopen
CiA
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 to
read sub-index 1h: At a complex data type the device returns a value and sub-index 0h contains the
number of sub-indices that follow, at a standard data type the device aborts the SDO transfer as no
sub-index 1h available.
Note that some entries of data type UNSIGNED32 have the character of a structure (e.g. PDO COBID entry, see Figure 65).
9.5.3.1
Organisation of structured Object Dictionary Entries
If an Object Dictionary entry (index) contains several sub-indices, then sub-index 0 describes the
highest available sub-index that follows, not considering FFh. This entry is encoded as UNSIGNED8.
Sub-index FFh describes the structure of the entry by providing the data type and the object type of
the entry. It is encoded as UNSIGNED32 and organised as follows:
MSB
LSB
Bits 31-16
Value Reserved (value: 00 00h)
Encoded as
15-8
7-0
Data Type
Object
(see Table 38)
(see Table 36)
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 the
structure of the complex data types is provided as well, it enables one to upload the entire structure of
the Object Dictionary.
9.5.4
Specification of Predefined Complex Data Types
This section describes the structure of the predefined complex data types used for communication.
The value range and the meaning is explained at the detailed description of the objects using these
types.
9.5.4.1
PDO Communication Paramter Record Specification
Table 40: PDO Communication Parameter Record
Index
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-60
APPLICATION LAYER
9.5.4.2
CANopen
CiA
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
::: ::
nd
2h
2
::::::
::::::::
40h
object to be mapped
UNSIGNED32
::::::
th
64 object to be mapped
UNSIGNED32
9.5.4.3
9.5.4.4
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.5
Identity Record Specification
Table 43: Identity Record
9.6
9.6.1
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
Communication Profile Specification
Detailed Object Specification
The structure of the Object Dictionary entries is described in the following manner: All device, interface
and application profiles based on this communication profile have to follow this structure.
Table 44: Format of an Object Description
OBJECT DESCRIPTION
INDEX
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 better
readability, the Object Description additionally contains the symbolic Object Name.
9-61
APPLICATION LAYER
CANopen
CiA
Table 45: Object Value Description Format
ENTRY DESCRIPTION
Sub-Index
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 in
case the Object is present
Access
Read Only (ro) or Read/Write (rw) or Write Only (wo) or Const. In
OPERATIONAL state the Access to Object Dictionary Entries may
be limited, e.g set to ro.
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 entry
category. For complex data types the value description must be defined for each element (sub-index).
9.6.2
Overview Object Dictionary Entries for Communication
Table 46 gives an overview over the Object Dictionary entries defined by the communication profile:
Table 46: Standard Objects
Name
Type
Acc.1
M/O
VAR
device type
UNSIGNED32
ro
M
VAR
error register
UNSIGNED8
ro
M
1002
VAR
manufacturer status register
UNSIGNED32
ro
O
1003
ARRAY
pre-defined error field
UNSIGNED32
ro
O
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
UNSIGNED16
rw
O
UNSIGNED8
rw
O
Index
Object
(hex)
(Symbolic
Name)
1000
1001
1004
reserved for compatibility reasons
100B
1
reserved for compatibility reasons
100C
VAR
guard time
100D
VAR
life time factor
100E
reserved for compatibility reasons
100F
reserved for compatibility reasons
Access type listed here may vary for certain sub-indices. See detailed object specification.
9-62
APPLICATION LAYER
CANopen
CiA
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
:::::
:::::
:::::
SDO Parameter (22h)
ro
O
SDO Parameter (22h)
rw
M/O**
:::::
:::::
:::::
SDO Parameter (22h)
rw
M/O**
SDO Parameter (22h)
rw
M/O**
SDO Parameter (22h)
rw
M/O**
:::::
:::::
:::::
SDO Parameter (22h)
rw
M/O**
:::::
:::::
:::::
rw
M/O*
1019
:::::
reserved
:::::
11FF
:::::
reserved
Server SDO Parameter
st
1200
RECORD
1 Server SDO parameter
1201
RECORD
2
:::::
:::::
:::::
nd
Server SDO parameter
th
127F
RECORD
128 Server SDO parameter
1280
RECORD
1 Client SDO parameter
Client SDO Parameter
st
nd
1281
RECORD
2
:::::
:::::
:::::
12FF
RECORD
1300
:::::
Client SDO parameter
th
128 Client SDO parameter
reserved
:::::
13FF
:::::
reserved
Receive PDO Communication Parameter
st
1400
RECORD
1 receive PDO Parameter
1401
RECORD
2
:::::
:::::
:::::
nd
receive PDO Parameter
th
15FF
RECORD
512 receive PDO Parameter
1600
RECORD
1 receive PDO mapping
PDO CommPar (20h)
PDO CommPar (20h)
M/O*
:::::
:::::
:::::
PDO CommPar (20h)
rw
M/O*
PDO Mapping (21h)
rw
M/O*
PDO Mapping (21h)
rw
M/O*
:::::
:::::
:::::
PDO Mapping (21h)
rw
M/O*
PDO CommPar (20h)
rw
M/O*
PDO CommPar (20h)
rw
M/O*
:::::
:::::
::::
PDO CommPar (20h)
rw
M/O*
PDO Mapping (21h)
rw
M/O*
PDO Mapping (21h)
rw
M/O*
:::::
:::::
:::::
PDO Mapping (21h)
rw
M/O*
Receive PDO Mapping Parameter
st
nd
1601
RECORD
2
:::::
:::::
:::::
receive PDO mapping
th
17FF
RECORD
512 receive PDO mapping
1800
RECORD
1 transmit PDO Parameter
Transmit PDO Communication Parameter
st
nd
1801
RECORD
2
:::::
:::::
:::::
transmit PDO Parameter
th
19FF
RECORD
512 transmit PDO Parameter
1A00
RECORD
1 transmit PDO mapping
Transmit PDO Mapping Parameter
st
nd
1A01
RECORD
2
:::::
:::::
:::::
1BFF
RECORD
transmit PDO mapping
th
512 transmit PDO mapping
* If a device supports PDOs, the according PDO communication parameter and PDO mapping entries
in the Object Dictionary are mandatory. These may be read_only.
** If a device supports SDOs, the according SDO parameters in the Object Dictionary are mandatory.
9-63
APPLICATION LAYER
9.6.3
CANopen
CiA
Detailed Specification of Communication Profile specific Objects
Object 1000h: Device Type
Contains information about the device type. The object at index 1000h describes the type of device
and its functionality. It is composed of a 16-bit field which describes the device profile that is used and
a second 16-bit field which gives additional information about optional functionality of the device. The
Additional Information parameter is device profile specific. Its specification does not fall within the
scope of this document, it is defined in the appropriate device profile. The value 0000h indicates a
device that does not follow a standardised device profile. For multiple device modules the Additional
Information parameter contains FFFFh and the device profile number referenced by object 1000h is
the device profile of the first device in the Object Dictionary. All other devices of a multiple device
module identify their profiles at objects 67FFh + xÊ*Ê800h with x = internal number of the device (0 Ð 7).
These entries describe the device type of the preceding device.
OBJECT DESCRIPTION
INDEX
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. This
entry 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
Value Range
UNSIGNED8
Default Value
No
9-64
APPLICATION LAYER
CANopen
CiA
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 is
the generic error. The generic error is signaled at any error situation.
Object 1002h: Manufacturer Status Register
This object is a common status register for manufacturer specific purposes. In this document only the
size and the location of this object is defined.
OBJECT DESCRIPTION
INDEX
1002h
Name
manufacturer status register
Object Code
VAR
Data Type
UNSIGNED32
Category
Optional
ENTRY DESCRIPTION
Access
ro
PDO Mapping
Optional
Value Range
UNSIGNED32
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 signaled
via the Emergency Object. In doing so it provides an error history.
1. The entry at sub-index 0 contains the number of actual errors that are recorded in the array starting
at sub-index 1.
2. Every new error is stored at sub-index 1, the older ones move down the list.
3. Writing a ã0Ò to sub-index 0 deletes the entire error history (empties the array). Values higher than
0 are not allowed to write. This have to lead to an abort message (error code: 0609 0030h).
4. The error numbers are of type UNSIGNED32 (see Table 7-18) and are composed of a 16 bit error
code and a 16 bit additional error information field which is manufacturer specific. The error code is
contained in the lower 2 bytes (LSB) and the additional information is included in the upper 2 bytes
(MSB). If this object is supported it must consist of two entries at least. The length entry on subindex 0h and at least one error entry at sub-index 1H.
Byte:
MSB
LSB
Additional Information
Error code
Figure 53: Structure of the pre-defined error field
9-65
APPLICATION LAYER
CANopen
CiA
OBJECT DESCRIPTION
INDEX
1003h
Name
pre-defined error field
Object Code
ARRAY
Data Type
UNSIGNED32
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
Entry Category
Optional
Access
ro
PDO Mapping
No
Value Range
UNSIGNED32
Default Value
No
Sub-Index
2h - FEh
Description
standard error field
Entry Category
Optional
Access
ro
PDO Mapping
No
Value Range
UNSIGNED32
Default Value
No
Object 1005h: COB-ID SYNC message
Index 1005h defines the COB-ID of the Synchronisation Object (SYNC). Further, it defines whether
the device generates the SYNC. The structure of this object is shown in Figure 54 and Table 48.
UNSIGNED32
MSB
LSB
bits
31
30
11-bit-ID
X
29-bit-ID
X
29
28-11
10-0
0/1 0
000000000000000000
11-bit Identifier
0/1 1
29 -bit Identifier
Figure 54: Structure of SYNC COB-ID entry
9-66
APPLICATION LAYER
CANopen
CiA
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
0
11-bit ID (CAN 2.0A)
1
29-bit ID (CAN 2.0B)
0
if bit 29=0
X
if bit 29=1: bits 28-11 of 29-bit-SYNC-COB-ID
X
bits 10-0 of SYNC-COB-ID
29
28 Ð 11
10-0 (LSB)
Bits 29, 30 may be static (not changeable). If a device is not able to generate SYNC messages, an
attempt to set bit 30 is responded with an abort message (abort code: 0609Ê0030h). Devices
supporting the standard CAN frame type only either ignore attempts to change bit 29 or respond with
an abort message (abort code: 0609Ê0030h). The first transmission of SYNC object starts within 1
sync cycle after setting Bit 30 to 1. It is not allowed to change Bit 0-29, while the objects exists
(BitÊ30=1).
OBJECT DESCRIPTION
INDEX
1005h
Name
COB-ID SYNC
Object Code
VAR
Data Type
UNSIGNED32
Category
Conditional;
Mandatory, if PDO
communication on a
synchronous base is supported
ENTRY DESCRIPTION
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32
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 0
if not used. If the communication cycle period on sync producer is changed to a new value unequal 0
the transmission of sync object resumes within 1 sync cycle of the new value.
OBJECT DESCRIPTION
INDEX
1006h
Name
communication cycle period
Object Code
VAR
Data Type
UNSIGNED32
Category
Conditional;
Mandatory for Sync producers
9-67
APPLICATION LAYER
CANopen
ENTRY DESCRIPTION
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32
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
Data Type
UNSIGNED32
Category
Optional
ENTRY DESCRIPTION
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32
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
Data Type
Visible String
Category
Optional
9-68
CiA
APPLICATION LAYER
CANopen
CiA
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
Data Type
Visible String
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 is
0 if not used.
OBJECT DESCRIPTION
INDEX
100Ch
Name
guard time
Object Code
VAR
Data Type
UNSIGNED16
Category
Conditional;
Mandatory, if heartbeat is not
supported
ENTRY DESCRIPTION
Access
rw;
ro, if life guarding is not supported
PDO Mapping
No
Value Range
UNSIGNED16
Default Value
0
9-69
APPLICATION LAYER
CANopen
CiA
Object 100Dh: Life Time Factor
The life time factor multiplied with the guard time gives the life time for the node guarding protocol. It is
0 if not used.
OBJECT DESCRIPTION
INDEX
100Dh
Name
life time factor
Object Code
VAR
Data Type
UNSIGNED8
Category
Conditional;
Mandatory, if heartbeat is not
supported
ENTRY DESCRIPTION
Access
rw;
ro, if life guarding is not supported
PDO Mapping
No
Value Range
UNSIGNED8
Default Value
0
Object 1010h: Store parameters
This object supports the saving of parameters in non volatile memory. By read access the device
provides information about its saving capabilities. Several parameter groups are distinguished:
Sub-Index 0 contains the largest Sub-Index that is supported.
Sub-Index 1 refers to all parameters that can be stored on the device.
Sub-Index 2 refers to communication related parameters (Index 1000h - 1FFFh manufacturer specific
communication parameters).
Sub-Index 3 refers to application related parameters (Index 6000h - 9FFFh manufacturer specific
application parameters).
At Sub-Index 4 - 127 manufacturers may store their choice of parameters individually.
Sub-Index 128 - 254 are reserved for future use.
In order to avoid storage of parameters by mistake, storage is only executed when a specific signature
is written to the appropriate Sub-Index. The signature is ãsaveÒ.
Signature
ISO 8859
(ÒASCIIÓ)
hex
MSB
LSB
e
v
a
s
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 and
then confirms the SDO transmission (initiate download response). If the storing failed, the device
responds 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 storage
functionality with the following format:
UNSIGNED32
bits
MSB
LSB
31-2
1
reserved (=0)
0/1 0/1
Figure 56: Storage read access structure
9-70
0
APPLICATION LAYER
CANopen
Table 49: Structure of read access
bit number
value
meaning
31-2
0
reserved (=0)
1
0
Device does not save parameters autonomously
1
Device saves parameters autonomously
0
Device does not save parameters on command
1
Device saves parameters on command
0
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
Data Type
UNSIGNED32
Category
Optional
ENTRY DESCRIPTION
Sub-Index
0h
Description
largest subindex supported
Entry Category
Mandatory
Access
ro
PDO Mapping
No
Value Range
1h Ð 7Fh
Default Value
No
Sub-Index
1h
Description
save all parameters
Entry Category
Mandatory
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32
(Figure 55 for write access;
Figure 56 for read access)
Default Value
No
Sub-Index
2h
Description
save communication parameters
Entry Category
Optional
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32
(Figure 55 for write access;
Figure 56 for read access)
Default Value
No
9-71
CiA
APPLICATION LAYER
CANopen
CiA
Sub-Index
3h
Description
save application parameters
Entry Category
Optional
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32
(Figure 55 for write access;
Figure 56 for read access)
Default Value
No
Sub-Index
4h - 7Fh
Description
save manufacturer defined
parameters
Entry Category
Optional
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32
(Figure 55 for write access;
Figure 56 for read access)
Default Value
No
Object 1011h: Restore default parameters
With this object the default values of parameters according to the communication or device profile are
restored. By read access the device provides information about its capabilities to restore these values.
Several parameter groups are distinguished:
Sub-Index 0 contains the largest Sub-Index that is supported.
Sub-Index 1 refers to all parameters that can be restored.
Sub-Index 2 refers to communication related parameters (Index 1000h - 1FFFh manufacturer specific
communication parameters).
Sub-Index 3 refers to application related parameters (Index 6000h - 9FFFh manufacturer specific
application parameters).
At Sub-Index 4 - 127 manufacturers may restore their individual choice of parameters.
Sub-Index 128 - 254 are reserved for future use.
In order to avoid the restoring of default parameters by mistake, restoring is only executed when a
specific signature is written to the appropriate sub-index. The signature is ãloadÒ.
Signature
ASCII
hex
MSB
d
64h
LSB
a
61h
o
6Fh
l
6Ch
Figure 57: Restoring write access signature
On reception of the correct signature in the appropriate sub-index the device restores the default
parameters and then confirms the SDO transmission (initiate download response). If the restoring
failed, the device responds with an Abort SDO Transfer (abort code: 0606Ê0000h). If a wrong signature
is written, the device refuses to restore the defaults and responds with an Abort SDO Transfer (abort
code: 0800Ê002xh).
The default values are set valid after the device is reset (reset node for sub-index 1h Ð 7Fh, reset
communication for sub-index 2h) or power cycled.
9-72
APPLICATION LAYER
CANopen
CiA
restore default
reset / power cycle
default values valid
Figure 58: restore procedure
On read access to the appropriate sub-index the device provides information about its default
parameter restoring capability with the following format:
UNSIGNED32
MSB
bits
LSB
31-1
0
reserved (=0)
0/1
Figure 59: Restoring default values read access structure
Table 50: Structure of restore read access
bit number
value
meaning
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
Data Type
UNSIGNED32
Category
Optional
ENTRY DESCRIPTION
Sub-Index
0h
Description
largest subindex supported
Entry Category
Mandatory
Access
ro
PDO Mapping
No
Value Range
1h Ð 7Fh
Default Value
No
9-73
APPLICATION LAYER
CANopen
CiA
Sub-Index
1h
Description
restore all default parameters
Entry Category
Mandatory
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32 (Figure 57)
Default Value
No
Sub-Index
2h
Description
restore communication default
parameters
Entry Category
Optional
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32 (Figure 57)
Default Value
No
Sub-Index
3h
Description
restore application default
parameters
Entry Category
Optional
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32 (Figure 57)
Default Value
No
Sub-Index
4h - 7Fh
Description
restore manufacturer
default parameters
Entry Category
Optional
PDO Mapping
No
Value Range
UNSIGNED32 (Figure 57)
defined
Object 1012h: COB-ID Time Stamp Object
Index 1012h defines the COB-ID of the Time-Stamp Object (TIME). Further, it defines whether the
device consumes the TIME or whether the device generates the TIME. The structure of this object is
shown in Figure 60 and Table 51.
UNSIGNED32
MSB
LSB
bits
31
30
11-bit-ID
0/1
29-bit-ID
0/1
29
28-11
10-0
0/1 0
000000000000000000
11-bit Identifier
0/1 1
29 -bit Identifier
Figure 60: Structure of TIME COB-ID entry
9-74
APPLICATION LAYER
CANopen
CiA
Table 51: Description of TIME COB-ID entry
bit number
value
meaning
31 (MSB)
0
Device does not consume TIME message
1
Device consumes TIME message
0
Device does not produce TIME message
1
Device produces TIME message
0
11-bit ID (CAN 2.0A)
1
29-bit ID (CAN 2.0B)
0
if bit 29=0
X
if bit 29=1: bits 28-11 of 29-bit-TIME-COB-ID
X
bits 10-0 of TIME-COB-ID
30
29
28 Ð 11
10-0 (LSB)
Bits 29, 30 may be static (not changeable). If a device is not able to generate TIME messages, an
attempt to set bit 30 is responded with an abort message (abort code: 0609Ê0030h). Devices
supporting the standard CAN frame type only, an attempt to set bit 29 is responded with an abort
message (abort code: 0609Ê0030h). It is not allowed to change Bits 0-29, while the object exists
(BitÊ30=1).
OBJECT DESCRIPTION
INDEX
1012h
Name
COB-ID time stamp message
Object Code
VAR
Data Type
UNSIGNED32
Category
Optional
ENTRY DESCRIPTION
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32
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 in
order to define a high resolution time stamp message. (Note that the data type of the standard time
stamp message (TIME) is fixed). Further application specific use is encouraged.
OBJECT DESCRIPTION
INDEX
1013h
Name
high resolution time stamp
Object Code
VAR
Data Type
UNSIGNED32
Category
Optional
ENTRY DESCRIPTION
Access
rw
PDO Mapping
Optional
Value Range
UNSIGNED32
Default Value
0
9-75
APPLICATION LAYER
CANopen
CiA
Object 1014h: COB-ID Emergency Object
Index 1014h defines the COB-ID of the Emergency Object (EMCY). The structure of this object is
shown in Figure 61.
UNSIGNED32
MSB
bits
31
LSB
30
29
28-11
10-0
11-bit-ID 0/1
0
0
000000000000000000
11-bit Identifier
29-bit-ID 0/1
0
1
29 -bit Identifier
Figure 61: Structure of the EMCY Identifier entry
Table 52: Description of EMCY COB-ID entry
bit number
value
Meaning
31 (MSB)
0
EMCY exists / is valid
1
EMCY does not exist / is not valid
30
0
reserved (always 0)
29
0
11-bit ID (CAN 2.0A)
1
29-bit ID (CAN 2.0B)
28 - 11
10-0 (LSB)
0
if bit 29=0
X
if bit 29=1: bits 28-11 of 29-bit-COB-ID
X
bits 10-0 of COB-ID
Devices supporting the standard CAN frame type only, an attempt to set bit 29 is responded with an
abort message (abort code: 0609Ê0030h). It is not allowed to change Bits 0-29, while the object exists
(Bit 31=0).
OBJECT DESCRIPTION
INDEX
1014h
Name
COB-ID Emergency message
Object Code
VAR
Data Type
UNSIGNED32
Category
Conditional;
Mandatory, if Emergency is
supported
ENTRY DESCRIPTION
Access
ro;
optional rw
PDO Mapping
No
Value Range
UNSIGNED32
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 be
writable in the object dictionary. The time has to be a multiple of 100ms.
9-76
APPLICATION LAYER
CANopen
CiA
OBJECT DESCRIPTION
INDEX
1015h
Name
Inhibit Time EMCY
Object Code
VAR
Data Type
UNSIGNED16
Category
Optional
ENTRY DESCRIPTION
Access
rw
PDO Mapping
No
Value Range
UNSIGNED16
Default Value
0
Object 1016h: Consumer Heartbeat Time
The consumer heartbeat time defines the expected heartbeat cycle time and thus has to be higher
than the corresponding producer heartbeat time configured on the device producing this heartbeat.
Monitoring starts after the reception of the first heartbeat. If the consumer heartbeat time is 0 the
corresponding entry is not used. The time has to be a multiple of 1ms.
UNSIGNED32
MSB
Bits 31-24
Value reserved (value: 00h)
Encoded as
-
LSB
23-16
15-0
Node-ID
heartbeat time
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 the
device aborts the SDO download with abort code 0604Ê0043h
OBJECT DESCRIPTION
INDEX
1016h
Name
Consumer Heartbeat Time
Object Code
ARRAY
Data Type
UNSIGNED32
Category
Optional
ENTRY DESCRIPTION
Sub-Index
0h
Description
number entries
Entry Category
Mandatory
Access
ro
PDO Mapping
No
Value Range
1 Ð 127
Default Value
No
9-77
APPLICATION LAYER
CANopen
Sub-Index
1h
Description
Entry Category
Consumer Heartbeat Time
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32 (Figure 62)
Default Value
0
Sub-Index
2h Ð 7Fh
Description
Entry Category
Consumer Heartbeat Time
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32 (Figure 62)
Default Value
No
CiA
Mandatory
Optional
Object 1017h: Producer Heartbeat Time
The producer hartbeat time defines the cycle time of the heartbeat. The producer heartbeat time is 0 if
it not used. The time has to be a multiple of 1ms.
OBJECT DESCRIPTION
INDEX
1017h
Name
Producer Heartbeat Time
Object Code
VAR
Data Type
UNSIGNED16
Category
Conditional;
Mandatory if guarding not
supported
ENTRY DESCRIPTION
Access
rw
PDO Mapping
No
Value Range
UNSIGNED16
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 a
minor revision number. The major revision number identifies a specific CANopen behaviour. If the
CANopen functionality is expanded, the major revision has to be incremented. The minor revision
number identifies different versions with the same CANopen behaviour.
9-78
APPLICATION LAYER
CANopen
31
CiA
16 15
major revision number
0
minor revision number
MSB
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
Entry Category
Mandatory
Access
ro
PDO Mapping
No
Value Range
1 .. 4
Default Value
No
Sub-Index
1h
Description
Vendor ID
Entry Category
Mandatory
Access
ro
PDO Mapping
No
Value Range
UNSIGNED32
Default Value
No
Sub-Index
2h
Description
Product code
Entry Category
Optional
Access
ro
PDO Mapping
No
Value Range
UNSIGNED32
Default Value
No
Sub-Index
3h
Description
Revision number
Entry Category
Optional
Access
ro
PDO Mapping
No
Value Range
UNSIGNED32
Default Value
No
9-79
APPLICATION LAYER
CANopen
Sub-Index
4h
Description
Serial number
Entry Category
Optional
Access
ro
PDO Mapping
No
Value Range
UNSIGNED32
Default Value
No
CiA
Object 1200h - 127Fh: Server SDO Parameter
In order to describe the SDOs used on a device the data type SDO Parameter is introduced. The data
type has the index 22h in the Object Dictionary. The structure is described in 9.5.4.
The number of supported entries in the SDO object record is specified at sub-index 0h. The values at
1h and 2h specify the COB-ID for this SDO. Sub-index 3 gives the server of the SDO in case the
record describes an SDO for which the device is client and gives the client of the SDO if the record
describes an SDO for which the device is server.
UNSIGNED32
MSB
LSB
bits
31
30
29
28-11
10-0
11-bit-ID
0/1
0
0
000000000000000000
11-bit Identifier
29-bit-ID
0/1
0
1
29-bit Identifier
Figure 64: Structure of SDO COB-ID entry
Table 53: Description of SDO COB-ID entry
bit number
value
Meaning
31 (MSB)
0
SDO exists / is valid
1
SDO does not exist / is not valid
30
0
reserved (always 0)
29
0
11-bit ID (CAN 2.0A)
1
29-bit ID (CAN 2.0B)
0
if bit 29=0
X
if bit 29=1: bits 28-11 of 29-bit-COB-ID
X
bits 10-0 of COB-ID
28 - 11
10-0 (LSB)
An SDO is only valid if both SDO-valid-bits are 0. Devices supporting the standard CAN frame type
only, an attempt to set bit 29 is responded with an abort message (abort code: 0609Ê0030h).
These objects contain the parameters for the SDOs for which the device is the server. If a device
handles more than one server SDO the default SDO must be located at index 1200h as the first server
SDO. This entry is read only2. All additional server SDOs are invalid by default (invalid bit - see Table
53), there description is located at subsequent indicies. It is not allowed to change the COB-ID while
the SDO exists.
The description of the Client of the SDO (sub-index 3h) is optional. It is not available for the default
SDO (no Sub-index 3h at Index 1200h), as this entry is read only.
2
It must be ensured that the COB-IDs of the default SDO can not be manipulated by writing to the
Object Dictionary.
9-80
APPLICATION LAYER
CANopen
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 for
each additionally supported
server SDO
ENTRY DESCRIPTION
Sub-Index
0h
Description
number of entries
Entry Category
Mandatory
Access
ro
PDO Mapping
No
Value Range
Index 1200h: 2
Index 1201h Ð 127F: 2 - 3
Default Value
No
Sub-Index
1h
Description
COB-ID Client->Server (rx)
Entry Category
Mandatory
Access
Index 1200h: ro,
Index 1201h-127Fh: rw
PDO Mapping
No
Value Range
UNSIGNED32 (Table 53)
Default Value
Index 1200h: 600h+Node-ID,
Index 1201h-127Fh: No
Sub-Index
2h
Description
COB-ID Server -> Client (tx)
Entry Category
Mandatory
Access
Index 1200h: ro
Index 1201-127Fh: rw
PDO Mapping
No
Value Range
UNSIGNED32 (Table 53)
Default Value
Index 1200h: 580h+Node-ID,
Index 1201h-127Fh: No
9-81
CiA
APPLICATION LAYER
CANopen
Sub-Index
3h
Description
Node-ID of the SDO client
Entry Category
Optional
Access
rw
PDO Mapping
No
Value Range
1h Ð 7Fh
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 is
supported, all sub-indices must be available. Starting at index 1280h and subsequent indicies.The
entries are described at the Server SDO Parameter.
OBJECT DESCRIPTION
INDEX
1280h - 12FFh
Name
Client SDO parameter
Object Code
RECORD
Data Type
SDO Parameter
Category
Conditional;
Mandatory for each supported
client SDO
ENTRY DESCRIPTION
Sub-Index
0h
Description
number of entries
Entry Category
Mandatory
Access
ro
PDO Mapping
No
Value Range
3
Default Value
3
Sub-Index
1h
Description
COB-ID Client->Server (tx)
Entry Category
Mandatory
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32 (Table 53)
Default Value
No
Sub-Index
2h
Description
COB-ID Server -> Client (rx)
Entry Category
Mandatory
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32 (Table 53)
Default Value
No
9-82
CiA
APPLICATION LAYER
CANopen
CiA
Sub-Index
3h
Description
Node-ID of the SDO server
Entry Category
Mandatory
Access
rw
PDO Mapping
No
Value Range
1h Ð 7Fh
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 the
PDO communication parameter (20h) is described in 9.5.4. The sub-index 0h contains the number of
valid entries within the communication record. Its value is at least 2. If inhibit time supported the value
is 3. At sub-index 1h resides the COB-ID of the PDO. This entry has been defined as UNSIGNED32 in
order to cater for 11-bit CAN Identifiers (CAN 2.0A) as well as for 29-bit CAN identifiers (CAN 2.0B).
The entry has to be interpreted as defined in Figure 65 and Table 54.
UNSIGNED32
MSB
LSB
bits
31
30
11-bit-ID
0/1
29-bit-ID
0/1
29
28-11
10-0
0/1 0
000000000000000000
11-bit Identifier
0/1 1
29-bit Identifier
Figure 65: Structure of PDO COB-ID entry
Table 54: Description of PDO COB-ID entry
bit number
value
meaning
31 (MSB)
0
PDO exists / is valid
1
PDO does not exist / is not valid
0
RTR allowed on this PDO
1
no RTR allowed on this PDO
0
11-bit ID (CAN 2.0A)
1
29-bit ID (CAN 2.0B)
0
if bit 29=0
X
if bit 29=1: bits 28-11 of 29-bit-COB-ID
X
bits 10-0 of COB-ID
30
29
28 Ð 11
10-0 (LSB)
The PDO valid/not valid allows to select which PDOs are used in the operational state. There
may be PDOs fully configured (e.g. by default) but not used, and therefore set to "not valid"
(deleted). The feature is necessary for devices supporting more than 4ÊRPDOs or 4 TPDOs,
because each device has only default identifiers for the first four RPDOs/TPDOs. Devices
supporting the standard CAN frame type only or do not support Remote Frames, an attempt to
set bit 29 to 1 or bit 30 to 0 is responded with an abort message (abort code: 0609Ê0030h).
It is not allowed to change bit 0-29 while the PDO exists (Bit 31=0).
The transmission type (sub-index 2) defines the transmission/reception character of the PDO (see
9.2.1.1). Table 55 describes the usage of this entry. On an attempt to change the value of the
transmission type to a value that is not supported by the device an abort message (abort code:
0609Ê0030h) is generated.
9-83
APPLICATION LAYER
CANopen
CiA
Table 55: Description of transmission type
transmission type
PDO transmission
cyclic
0
1-240
acyclic
synchronous
X
X
X
asynchronous
RTR only
X
241-251
- reserved -
252
X
X
253
X
254
X
255
X
X
Synchronous (transmission types 0-240 and 252) means that the transmission of the PDO shall be
related to the SYNC object as described in 9.3. Preferably the devices use the SYNC as a trigger to
output or actuate based on the previous synchronous Receive PDO respectively to update the data
transmitted at the following synchronous Transmit PDO. Details of this mechanism depend on the
device type and are defined in the device profile if applicable.
Asynchronous means that the transmission of the PDO is not related to the SYNC object.
A transmission type of zero means that the message shall be transmitted synchronously with the
SYNC object but not periodically.
A value between 1 and 240 means that the PDO is transferred synchronously and cyclically. The
transmission type indicating the number of SYNC which are necessary to trigger PDO transmissions.
Receive PDOs are always triggered by the following SYNC upon receiption of data independent of the
transmission types 0 - 240.
The transmission types 252 and 253 mean that the PDO is only transmitted on remote transmission
request. At transmission type 252, the data is updated (but not sent) immediately after reception of the
SYNC object. At transmission type 253 the data is updated at the reception of the remote transmission
request (hardware and software restrictions may apply). These value are only possible for TPDOs.
For TPDOs transmission type 254 means, the application event is manufacturer specific (manufacturer
specific part of the Object Dictionary), transmission type 255 means, the application event is defined in
the device profile. RPDOs with that type trigger the update of the mapped data with the reception.
Sub-index 3h contains the inhibit time. This time is a minimum interval for PDO transmission. The
value is defined as multiple of 100ms. It is not allowed to change the value while the PDO exists (Bit 31
of sub-index 1 is 0).
Sub-index 4h is reserved. It does not have to be implemented, in this case read or write access leads
to Abort SDO Transfer (abort code: 0609 0011h).
In mode 254/255 additionally an event time can be used for TPDO. If an event timer exists for a TPDO
(value not equal to 0) the elapsed timer is considered to be an event. The event timer elapses as
multiple of 1 ms of the entry in sub-index 5h of the TPDO. This event will cause the transmission of
this TPDO in addition to otherwise defined events. The occurence of the events set the timer.
Independent of the transmission type the RPDO event timer is used recognize the expiration of the
RPDO.
OBJECT DESCRIPTION
INDEX
1400h - 15FFh
Name
receive PDO parameter
Object Code
RECORD
Data Type
PDO CommPar
Category
Conditional;
Mandatory for each supported
PDO
9-84
APPLICATION LAYER
CANopen
ENTRY DESCRIPTION
Sub-Index
0h
Description
largest sub-index supported
Entry Category
Mandatory
Access
ro
PDO Mapping
No
Value Range
2Ð5
Sub-Index
1h
Description
COB-ID used by PDO
Entry Category
Mandatory
Access
ro;
rw if variable COB-ID is
supported
PDO Mapping
No
Value Range
UNSIGNED32 (Table 54)
Default Value
Index 1400h: 200h + Node-ID,
Index 1401h: 300h + Node-ID,
Index 1402h: 400h + Node-ID,
Index 1403h: 500h + Node-ID,
Index 1404h Ð 15FFh: disabled
Sub-Index
2h
Description
transmission type
Entry Category
Mandatory
Access
ro;
rw if variable transmission type is
supported
PDO Mapping
No
Value Range
UNSIGNED8 (Table 55)
Default Value
(Device Profile dependent)
Sub-Index
3h
Description
inhibit time
(not used for RPDO)
Entry Category
Optional
Access
rw
PDO Mapping
No
Value Range
UNSIGNED16
Default Value
No
9-85
CiA
APPLICATION LAYER
CANopen
CiA
Sub-Index
4h
Description
compatibility entry
Entry Category
Optional
Access
rw
PDO Mapping
No
Value Range
UNSIGNED8
Default Value
No
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 1600h - 17FFh: Receive PDO Mapping Parameter
Contains the mapping for the PDOs the device is able to receive. The type of the PDO mapping
parameter (21h) is described in 9.5.4. The sub-index 0h contains the number of valid entries within the
mapping record. This number of entries is also the number of the application variables which shall be
transmitted/received with the corresponding PDO. The sub-indices from 1h to number of entries
contain the information about the mapped application variables. These entries describe the PDO
contents by their index, sub-index and length (Figure 66). All three values are hexadecimal coded. The
length entry contains the length of the object in bit (1..40h). This parameter can be used to verify the
overall mapping length. It is mandatory.
The structure of the entries from sub-index 1h Ð 40h is as follows:
Byte:
MSB
index (16 bit)
LSB
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 SDO
client attempts to map an object that cannot be mapped) the device responds with an Abort SDO
Transfer Service.
Subindex 0 determines the valid number of objects that have been mapped. For changing the PDO
mapping first the PDO has to be deleted, the sub-index 0 must be set to 0 (mapping is deactivated).
Then the objects can be remapped. When a new object is mapped by wrinting a subindex between 1
and 64, the device may check whether the object specified by index / sub-index exists. If the object
does not exist or the object cannot be mapped, the SDO transfer must be aborted with the Abort SDO
Transfer Service with one of the abort codes 0602Ê0000h or 0604Ê0041h.
After all objects are mapped subindex 0 is set to the valid number of mapped objects. Finally the PDO
will be created by writing to its communication parameter COB-ID. When subindex 0 is set to a value
>0 the device may validate the new PDO mapping before transmitting the response of the SDO
service. If an error is detected the device has to transmit the Abort SDO Transfer Service with one of
the abort codes 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 the
PDO is not evaluated by the device. This optional feature is useful e.g. to transmit data to several
devices using one PDO, each device only utilising a part of the PDO. It is not possible to create a
dummy mapping for a TPDO.
9-86
APPLICATION LAYER
CANopen
CiA
A device that supports dynamic mapping of PDOs must support this during the state PREOPERATIONAL state. If dynamic mapping during the state OPERATIONAL is supported, the SDO
client is responsible for data consistency.
Object Dictionary
PDO Mapping
0
1
yyyyh
3
yyh 08h
2
zzzzh
zzh 10h
3
xxxxh
xxh 08h
PDO:
Appl. Obj. 2
xxxxh
xxh
Application Object 1
yyyyh
yyh
Application Object 2
zzzzh
zzh
Application Object 3
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
Category
Conditional;
Mandatory for each supported
PDO
ENTRY DESCRIPTION
Sub-Index
0h
Description
number of mapped application
objects in PDO
Entry Category
Mandatory
Access
ro;
rw if dynamic mapping is
supported
PDO Mapping
No
Value Range
0: deactivated
1 Ð 64: activated
Default Value
(device profile dependent)
9-87
APPLICATION LAYER
CANopen
Sub-Index
1h Ð 40h
Description
PDO mapping for the nth
application object to be mapped
Entry Category
Conditional
depends on number and size of
object be mapped
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32
Default Value
(device profile dependent)
Object 1800h - 19FFh: Transmit PDO Communication Parameter
Contains the communication parameters for the PDOs the device is able to transmit. The type of the
PDO communication parameter (20h) is described in 9.5.4. A detailed description of the entries is
done in the section for the Receive PDO Communication Parameter (1400h Ð 15FFh).
OBJECT DESCRIPTION
INDEX
1800h - 19FFh
Name
transmit PDO parameter
Object Code
RECORD
Data Type
PDO CommPar
Category
Conditional;
Mandatory for each supported
PDO
ENTRY DESCRIPTION
Sub-Index
0h
Description
largest sub-index supported
Entry Category
Mandatory
Access
ro
PDO Mapping
No
Value Range
2Ð5
Sub-Index
1h
Description
COB-ID used by PDO
Entry Category
Mandatory
Access
ro;
rw if COB-ID can be configured
PDO Mapping
No
Value Range
UNSIGNED32 (Figure 65)
Default Value
Index 1800h: 180h + Node-ID,
Index 1801h: 280h + Node-ID,
Index 1802h: 380h + Node-ID,
Index 1803h: 480h + Node-ID,
Index 1804h - 18FFh: disabled
9-88
CiA
APPLICATION LAYER
CANopen
Sub-Index
2h
Description
transmission type
Entry Category
Mandatory
Access
ro;
CiA
rw if transmission type can be
changed
PDO Mapping
No
Value Range
UNSIGNED8 (Table 54)
Default Value
(device profile dependent)
Sub-Index
3h
Description
inhibit time
Entry Category
Optional
Access
rw
PDO Mapping
No
Value Range
UNSIGNED16
Default Value
No
Sub-Index
4h
Description
reserved
Entry Category
Optional
Access
rw
PDO Mapping
No
Value Range
UNSIGNED8
Default Value
No
Sub-Index
5h
Description
event timer
Entry Category
Optional
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 mapping
parameter (21h) is described in 9.5.4. A detailed description of the entries is done in the section for the
Receive PDO Mapping Parameter (1600h Ð 17FFh).
9-89
APPLICATION LAYER
CANopen
OBJECT DESCRIPTION
INDEX
1A00h - 1BFFh
Name
transmit PDO mapping
Object Code
RECORD
Data Type
PDO Mapping
Category
Conditional;
Mandatory for each supported
PDO
ENTRY DESCRIPTION
Sub-Index
0h
Description
number of mapped application
objects in PDO
Entry Category
Mandatory
Access
ro;
rw if dynamic mapping is
supported
PDO Mapping
No
Value Range
0: deactivated
1 Ð 64: activated
Default Value
(device profile dependent)
Sub-Index
1h Ð 40h
Description
PDO mapping for the n-th
application object to be mapped
Entry Category
Conditional;
depends on number and size of
objects to be mapped
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32
Default Value
(device profile dependent)
9-90
CiA
IMPLEMENTATION RECOMMENDATIONS
CANopen
CiA
10 IMPLEMENTATION RECOMMENDATIONS
When implementing the protocols, the following rules should be obeyed to guarantee interoperability.
These rules deal with the following implementation aspects:
Invalid COB's
A COB is invalid if it has a COB-ID that is used by the specified protocols, but it contains invalid
parameter values according to the protocol specification. This can only be caused by errors in the
lower layers or implementation errors. Invalid COB's must be handled locally in an implementation
specific way that does not fall within the scope of this specification. As far as the protocol is
concerned, an invalid COB must be ignored.
Time-out's
Since COB's may be ignored, the response of a confirmed service may never arrive. To resolve this
situation, an implementation may, after a certain amount of time, indicate this to the service user
(time-out). A time-out is not a confirm of that service. A time-out indicates that the service has not
completed yet. The application must deal with this situation. Time-out values are considered to be
implementation specific and do not fall within the scope of this specification. However, it is
recommended that an implementation provides facilities to adjust these time-out values to the
requirements of the application.
10-1
Annex A (normative)
CANopen
CiA
11 Annex A (normative)
Additional functionality for CANopen NMT slaves
Version 2.0
Date: 22 May 2000
In this normative annex, there is described the functionality for CANopen NMT slave devices that was
originally specified in CiA DSP-302 Framework for programmable CANopen devices.
11-1
Annex A (normative)
CANopen
CiA
11.1 Additional object dictionary entries
Additional records
Index
Name
24h
Debugger Par
25h
Command Par
Additional communication objects
Index
Object
Name
Type
Attr.
M/O
1020h
ARRAY
Verify Configuration
Unsigned32
rw
O
1021h
VAR
Store EDS
Domain
rw
O
1022h
VAR
Storage Format
Unsigned8
rw
O
1023h
RECORD
OS Command
Command Par
rw
O
1024h
VAR
OS Command Mode
Unsigned8
wo
O
1025h
RECORD
OS Debugger Interface
Debugger Par
rw
O
1026h
ARRAY
OS Prompt
Unsigned8
rw
O
1027h
ARRAY
Module list
Unsigned16
ro
M/O*
1028h
ARRAY
Emergency Consumer
Unsigned32
rw
O
1029h
ARRAY
Error Behaviour
Unsigned8
rw
O
*Mandatory for modular devices; otherwise optional.
Multiplexor PDO related objects
Index
Object
Name
Type
Attr.
M/O
1FA0h1FCFh
ARRAY
Object Scanner List
Unsigned32
rw
O
Object Dispatching List
Unsigned64
rw
O
1FD0h- ARRAY
1FFFh
11-2
Annex A (normative)
CANopen
CiA
11.2 Device configuration
11.2.1 Boot-up configuration process
The parameter in object 1010h for saving the configuration of a slave is not sufficient for a CANopen
Manager to determine, if the slave has recovered its last configuration after the reset, and can be
immediately put to the state Operational. To allow a CANopen Manager to determine whether a slave
needs to be reconfigured, the following optional object should be used:
Object 1020h: Verify Configuration
If a device supports the saving of parameters in non-volatile memory, a network configuration tool or a
CANopen manager can use this object to verify the configuration after a devices reset and to check if
a reconfiguration is necessary. The configuration tool shall store the date and time in that object and
shall store the same values in the DCF. Now the configuration tool lets the device save its
configuration by writing to index 1010h Sub-Index 1h the signature "save". After a reset the device
shall restore the last configuration and the signature automatically or by request. If any other
command changes boot-up configuration values, the device shall reset the object Verify Configuration
to 0.
The Configuration Manager compares signature and configuration with the value from the DCF and
decides if a reconfiguration is necessary or not.
Index
Object
Name
Type
Attr.
M/O
1020h
ARRAY
Verify Configuration
Unsigned32
rw
O
The sub-objects for the Verify Configuration Object are:
Index
Sub-Index
Field in Configuration Verify
Data Type
1020h
0h
Number of supported entries
Unsigned8
1h
Configuration date
Unsigned32
2h
Configuration time
Unsigned32
Configuration date shall contain the number of days since January 1,1984. Configuration time shall be
the number of ms after midnight.
Application hint: The usage of this object allows a significant speed-up of the boot-up process. If it is
used, the system integrator has to consider that a user may change a configuration value and
afterwards activate the command store configuration 1010h without changing the value of 1020h. So
the system integrator has to ensure a 100% consequent usage of this feature.
11.2.2 EDS storage
For some devices it may be possible to store the EDS. This has some advantages:
· The manufacturer does not have the problem of distributing the EDS via disks
· Management of different EDS versions for different software versions is less error prone, if they are
stored together
· The complete network settings may be stored in the network. This makes the task of analysing or
reconfiguring a network easier for tools and more transparent for the users.
The EDS may be stored in the following object:
Index
Object
Name
Type
Attr.
M/O
1021h
VAR
Store EDS
domain
rw
O
1022h
VAR
Storage Format
Unsigned8
rw
O
The filename does not need to be stored since every EDS contains its own filename.
Object 1F22h (see CiA DSP-302) describes the format of the storage. This allows the usage of
compressed formats.
11-3
Annex A (normative)
CANopen
Value
Format
0
ASCII, not compressed
1-255
reserved
CiA
The device may always store the file compressed internally. The object describes the external
behaviour.
11-4
Annex A (normative)
CANopen
CiA
11.3 OS command and prompt
Many operating systems of programmable devices support a console prompt. Commands may be
entered by the user with a keyboard or any other user input device (e.g. PC-based software with
mouse commands). In order to permit remote configuration and remote debugging of such a node, the
objects "OS Command/Debugger Interface" are defined in the object dictionary. The commands are
specific by the manufacturer. Two types of command usage are very common. For many PLCs, the
command interpreter expects a binary data stream, the command and additional binary data such as a
CRC etc. Another concept is the single character or line driven method.
Refer also to the program download description in CiA DSP-302.
11.3.1 OS command
The OS Command object may be used as a command driven interface to programmable devices. The
contents of the command may be ASCII or binary and are completely manufacturer specific. The host
system puts the command into the object OS command, which shall be of the type Command Par:
Index
Sub-Index
Field in OS Command
Data Type
25h
0h
Number of supported entries
Unsigned8
1h
Command
Octet String
2h
Status
Unsigned8
0: Last Command completed, no errors, no reply.
1: Last Command completed, no errors, reply
there.
2: Last Command completed, error, no reply.
3: Last Command completed, error, reply there.
4..254: undefined, reserved.
255: Command is executing.
03h
Reply
Octet String
Index
Object
Name
Type
Attr.
M/O
1023h
RECORD
OS Command
Command Par
rw
O
If a device implement this function, these entries are mandatory, additional entries are vendor specific.
A new command may be entered, if Status is in the range 0..3: The command and all parameters shall
be transmitted in one block to Sub-Index 1h. The execution of the command shall start immediately
after the completion of the transfer. The host polls Sub-Index 2h, until it is 0 ..3. It may then transfer
the reply, if Status is 1 or 3. The device shall return the same reply, if Reply is requested more then
one time, or may change Status from 1 to 0 or 3 to 2, if it can not buffer the reply.
11-5
Annex A (normative)
CANopen
The following object dictionary entry controls the operational mode of the OS command:
CiA
Index
Object
Name
Type
Attr.
M/O
1024h
VAR
OS command mode
Unsigned8
wo
O
0: Execute the next command immediately
1: Buffer the next command
2: Execute the commands in the buffer
3: Abort the current command and all
commands in the buffer
4..255: Manufacturer specific
It is intended that the OS command object dictionary entry is the most recent entry in a queue and that
this object controls the execution of this queue of commands.
11.3.2 OS debugger interface
The OS Debugger Interface object is the binary command interface to the debugger agents of the
programmable devices. The contents of the commands are manufacturer specific. This object enables
the user to connect with a remote debugger. It has the type Debugger Par:
Index
Sub-Index
Field in OS Debugger Interface
Data Type
24h
0h
Number of supported entries
Unsigned8
1h
Command
Octet String
2h
Status
Unsigned8
0: Last Command completed, no errors.
1: Last Command completed, error.
255: Command still executing.
03h
Reply
Octet String
Index
Object
Name
Type
Attr.
M/O
1025h
RECORD
OS Debugger Interface
Debugger Par
rw
O
If a device implement this function, the entries 00h-03h are mandatory, additional entries are vendor
specific. For command sequence, see OS Command Section.
11.3.3 OS prompt
The OS Prompt object is a character driven command interface to programmable devices. The
contents of the commands are manufacturer specific. This object enables the user to have remote
keyboard control.
Index
Object
Name
Type
Attr.
M/O
1026h
ARRAY
OS Prompt
Unsigned8
rw
O
11-6
Annex A (normative)
Value description:
CANopen
Sub-Index
0h
Description
largest supported Sub-Index
Access
ro
PDO Mapping
No
Value Range
Unsigned8
Mandatory Range
2-3
Default Value
2 or 3
Sub-Index
1h
Description
StdIn
Access
wo
PDO Mapping
Yes
Value Range
Unsigned8
Mandatory Range
No
Default Value
No
Sub-Index
2h
Description
StdOut
Access
ro
PDO Mapping
Yes
Value Range
Unsigned8
Mandatory Range
No
Default Value
No
Sub-Index
3h
Description
StdErr
Access
ro
PDO Mapping
Yes
Value Range
Unsigned8
Mandatory Range
No
Default Value
No
CiA
Sub-Index 1h StdIn can be used to transmit single characters to the device by SDO or PDO. Each
new character is appended to the internal input queue. Answers of the device are output on Sub-Index
2h StdOut. This object can be mapped to an event-driven PDO or polled by SDO. Sub-Index 3h StdErr
can be used for error output. This object can be mapped to an event-driven PDO or polled by SDO.
The application is responsible for handling queue overruns.
11-7
Annex A (normative)
CANopen
CiA
11.4 Multiplexed PDOs
11.4.1 MPDO Protocol
This protocol is used to implement MPDO services. The MPDO producer sends data and the
multiplexor indicating the source or destination address.
MPDO
producer
0
7
f
1..3
6..0
addr
MPDO
consumer
4..8
m
d
ÔdÕ shall contain the data to be transferred. The value always shall be filled up to 32 bit.3
ÔmÕ shall contain the multiplexor (Index and Sub-Index) of the variable in the object dictionary.
The MSB ÔfÕ of the first byte shall be a format flag, and ÔaddrÕ shall be an address field, which
may be used in the following combinations:
f
addr
usage
0
0
reserved
0
1-127
Source addressing. addr is a single producerÕs Node ID.
Multiplexor is index and sub-index of the object dictionary of
the producer.
1
0
Destination addressing. The consumer is a group.
1
1-127
Destination addressing. addr is a single consumerÕs Node
ID. Multiplexor is index and sub-index of the object
dictionary of the consumer.
11.4.1.1 Destination Address Mode (DAM)
The addr and the m field of the MPDO refers to the consumer. This allows access to the consumerÕs
Object Dictionary in an SDO-like manner. With addr = 0 , it allows multicasting and broadcasting, to
write into the Object Dictionaries of more than one node simultaneously, without having a PDO for
each single object.
Initiating a DAM-MPDO is application-dependent, like it is for SDOs.
11.4.1.2 Source Address Mode (SAM)
The addr and the m field of the MPDO refers to the producer. Only one producer MPDO of this type is
allowed for each node.
Transmission type has to be 254 or 255.
The producer uses an Object Scanner List in order to know, which objects are to send.
The consumer uses an Object Dispatcher List as a Ôcross referenceÕ.
3
The restriction about using 32-bit transfers only will not present problems in practice since all of the
participating devices know the data types (and sizes) of their related objects.
11-8
Annex A (normative)
11.4.2 Object dictionary entries
CANopen
CiA
11.4.2.1 PDO Mapping Record
The meaning of Sub-Index 0 (number of mapped objects is extended. The valid range for nonmultiplexed PDOs is 0 to 64. A value of 255 indicates a DAM-MPDO, a value of 254 indicates an
SAM-MPDO.
For SAM, the further entries in the MR are donÕt care.
For DAM the first object describes the local object (there can be mapped only one object into an
MPDO).
Index
Object
Name
Type
16XXh1AXXh
0h
Number of mapped objects
in the PDO:
Unsigned8
0 .. 64: Valid range for
number of mapped objects
254: formatted as SAMMPDO
255: formatted as DAMMPDO
This leaves open the possibility for further alternative PDO formats.
11.4.2.2 Object Dispatching List
The consumer of an SAM-MPDO uses the Object Dispatching List as a cross reference between the
remote object of the producer and local object dictionary.
Index
Object
Name
Type
Attr.
M/O
1FD0h1FFFh
ARRAY
Object Dispatching List
Unsigned64
rw
O
Value description:
Sub-Index
0h
Description
largest supported Sub-Index
Access
ro
PDO Mapping
No
Value Range
Unsigned8
Mandatory Range
No
Default Value
No
Sub-Index
1h-FEh
Description
Dispatch_n (n=Sub-Index)
Access
rw
PDO Mapping
No
Value Range
Unsigned64
Mandatory Range
No
Default Value
No
11-9
Annex A (normative)
The fields shall have the following structure:
Unsigned64
MSB
56-63
40-55
Block
Local Index
Size
bits
field
CANopen
CiA
32-39
16-31
Local Sub- Sender Index
Index
8-15
Sender
SubIndex
LSB
0-7
Sender
Node ID
Each table entry describes how the data of a received MPDO is transferred to the local Object
Dictionary. If the flag field is 0 and the producer Node ID, the producer Index and producer Sub-Index
fit to the entry, then the data shall be written to the local object addressed by the values Local Index
and Local Sub-Index of that entry.
The parameter Block Size allows the description of consecutive sub-indexes to be used. Example: if
sub-index 1-9 of the sender shall be mapped to sub-index 11-19 of the receiver, this range is defined
by
Sender Sub-Index = 1
Local Sub-Index = 11
Block Size
=9
Entries that are not configured shall have the value 0.
11.4.2.3 Object Scanner List
The producer of an SAM-MPDO uses the Object Scanner List to configure, which objects shall be
transmitted. The transmission type is given by the corresponding field of the used PDO.
Index
Object
Name
Type
Attr.
M/O
1FA0h1FCFh
ARRAY
Object Scanner List
Unsigned32
rw
O
Value description:
Sub-Index
0h
Description
largest supported Sub-Index
Access
ro
PDO Mapping
No
Value Range
Unsigned8
Mandatory Range
No
Default Value
No
Sub-Index
1h-FEh
Description
Scan_n (n=Sub-Index)
Access
rw
PDO Mapping
No
Value Range
Unsigned32
Mandatory Range
No
Default Value
No
11-10
Annex A (normative)
The fields have the following structure:
bits
field
Unsigned32
MSB
24-31
Block Size
CANopen
CiA
LSB
8-23
Index
0-7
Sub-Index
Each table entry describes an object that can be sent via the MPDO. It is possible to describe
consecutive sub-indexes by setting the parameter Block Size to the number of sub-indexes.
Entries that are not configured shall have the value 0.
11.4.3 Implementing MPDOs
MPDO Producer Ð If a node has specified one or more MPDO to be transmitted the following
implementation rules apply:
·
If it is an SAM-MPDO, the Object Scanner List together with the transmission type is used to
determine, which object to send (there shall be only one SAM-MPDO to be transmitted).
·
If it is a DAM-MPDO, the local object may be specified in the Mapping Parameter Set object as
usual. The Destination Object and Node ID may be specified application specific.
MPDO Consumer Ð If a node receives an MPDO (which is known by the Mapping Parameter Set
object) the following implementation rules apply:
·
If it is an DAM-MPDO, it writes the received data to the specified Object Dictionary entry.
·
If it is a SAM-MPDO, it has to use the Object Dispatching List as a Ôcross referenceÕ.
11.4.4 Groups, security and network configuration tools
A described group messaging scheme is highly efficient using only one DAM-MPDO per group. A
node, which is the consumer of a group needs only to receive the MPDO for that group. There is no
limit to the number of groups except that imposed by the number of free COB-IDs for PDOs.
There is no attempt, at the CANopen level, to guard against the misuse of a PDO used for group
messaging purposes.
11.4.5 Indication of MPDO capability in the EDS
For a transparent usage by configuration tools, it is required to have the knowledge, if a device
supports the group mechanism. This shall be marked in the EDS in section DeviceInfo with the
boolean entry GroupMessaging.
11-11
Annex A (normative)
CANopen
CiA
11.5 Additional functionality for modular CANopen devices
11.5.1 Background
The actual EDS specification allows the description of modular devices. With this it is possible to
perform the Conformance Test for those devices without the need of writing a pseudo EDS with the
concretely attached modules. Furthermore it is possible to describe those devices for the purpose of
project planning or configuration in manufacturer independent software tools.
In practical work one problem is arising: A common task is the scanning of a network with displaying
the results as a set of DCF files. For this purpose the scanning software will implement some
algorithms to scan the objects of a device and automatically assign the corresponding EDS, then readout the object contents and create the DCF. With modular devices this is not always possible.
Assume a bus coupler device and three available module types: Module Type A has 8 digital outputs,
Module Type B has 8 digital inputs and Module Type C has a combination of 8 Inputs and 8 Outputs.
Assume a configuration software scans such a device and detects that it consists of 8 digital inputs
and 8 digital outputs. Then it cannot decide, if this combination is built up by attaching one Module
Type C or by attaching one Module A and one Module B.
This inconsistency will cause trouble at the users side. This will cause explanation effort by module
manufacturers and tool providers. The user will get a feeling, that CANopen is so complicated. To
avoid this a small extension of the bus couplers object dictionary will solve that problem.
The idea is that the bus coupler contains an object that contains a list of the attached modules. A tool
scanning that device can read-out that list and then has a consistent knowledge about the concretely
attached modules.
11.5.2 Modular Devices
A common method to provide modular devices is the usage of a bus coupler that allows to connect
several combinations of modules. Object 1027h Module List describes the concretely attached
modules.
Index
Object
Name
Type
Attr.
M/O
1027h
ARRAY
Module List
Unsigned16
ro
Mandatory for modular
devices, otherwise optional
The sub-objects for the Verify Configuration Object are:
Index
Sub-Index
Field in Configuration Verify
Data Type
1027h
0h
Number of connected modules
Unsigned8
1h
Module 1
Unsigned16
...
...
N
Module N
Unsigned16
The consecutive sub-indexes (1 £ N £ 254) describe the corresponding modules in the order they are
attached. Each entry contains a number that identifies the module. For this the number must be
unique within all module types that can be attached to this bus coupler device type.
In the EDS (refer to DSP-306) object 1027h appears in the SubExtension list of each module. The
entry DefaultValue shall contain the identification number.
11-12
Annex A (normative)
CANopen
CiA
11.6 Additional communication objects
11.6.1 Emergency consumer object
This objects defines the Emergency COB-IDs that an NMT slave device is consuming. The structure of
the object is as follows:
UNSIGNED32
MSB
bits
31
LSB
30
29
28-11
10-0
11-bit Identifier
11-bit-ID 0/1
0
0
000000000000000000
29-bit-ID 0/1
0
1
29 -bit Identifier
bit number
value
Meaning
31 (MSB)
0
EMCY exists / is valid
1
EMCY does not exist / is not valid
30
0
reserved (always 0)
29
0
11-bit ID (CAN 2.0A)
1
29-bit ID (CAN 2.0B)
0
if bit 29=0
X
if bit 29=1: bits 28-11 of 29-bit-COB-ID
X
bits 10-0 of COB-ID
28 - 11
10-0 (LSB)
Devices supporting the standard CAN frame type only, an attempt to set bit 29 is responded with an
abort message (abort code: 0609Ê0030h). It is not allowed to change Bits 0-29, while the object is
existing (Bit 31=0).
The Sub-Index referes to the related Node-ID.
OBJECT DESCRIPTION
INDEX
1028h
Name
Emergency Consumer
Object Code
ARRAY
Data Type
UNSIGNED32
Category
Optional
ENTRY DESCRIPTION
Sub-Index
0h
Description
No. of Emergency Consumer
Entry Category
Mandatory
Access
ro
PDO Mapping
No
Value Range
1 Ð 127
Default Value
No
11-13
Annex A (normative)
11.6.2
CANopen
Sub-Index
1h
Description
Entry Category
Emergency Consumer 1
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32
Default Value
No
Sub-Index
2h Ð 7Fh
Description
Entry Category
Emergency Consumer 2 to 127
Access
rw
PDO Mapping
No
Value Range
UNSIGNED32
Default Value
No
CiA
Mandatory
Optional
Error behaviour object
If a serious device failure is detected in Operational State, the module shall enter by default
autonomously the pre-operational state. If object 1028h (Error Behaviour) is implemented, the device
can be configured to enter alternatively the stopped state or remain in the current state in case of a
device failure. Device failures shall include the following communication errors:
· Bus-off conditions of the CAN interface
· Life guarding event with the state ÔoccurredÕ
· Heartbeat event with state ÔoccurredÕ
Serious device errors also can be caused by device internal failures.
The value of the Error Classes is as follows:
0 = pre-operational (only if current state is operational)
1 = no state change
2 = stopped
3 .. 127 = reserved
OBJECT DESCRIPTION
INDEX
1029h
Name
Error Behaviour
Object Code
ARRAY
Data Type
UNSIGNED8
Category
Optional
ENTRY DESCRIPTION
Sub-Index
0h
Description
No. of Error Classes
Entry Category
Mandatory
Access
ro
PDO Mapping
No
Value Range
1h to FEh
Default Value
No
11-14
Annex A (normative)
CANopen
Sub-Index
1h
Description
Entry Category
Communication Error
Access
rw
PDO Mapping
No
Value Range
UNSIGNED8
Default Value
0
Sub-Index
2h to FEh
Description
Device profile or manufacturer
specific Error
Entry Category
Optional
Access
rw
PDO Mapping
No
Value Range
UNSIGNED8
Default Value
No
Mandatory
11-15
CiA
Index
CANopen
CiA
12 Index
access attributes .......................................... 9-57
life-............................................................. 9-47
ARRAY ......................................................... 9-57
node- ......................................................... 9-47
bit timing ......................................................... 7-1
inhibit time....................................................... 6-5
communication model
multi device module
client server relationship ............................ 6-6
data types.................................................. 9-58
master slave relationship ........................... 6-5
general ........................................................ 6-4
producer consumer relationship ................ 6-6
network initialisation ..................................... 9-52
communication status
NULL ............................................................. 9-57
initialising .................................................. 9-54
object dictionary.............................................. 6-3
operational ................................................ 9-55
communication entries ............................. 9-58
pre-operational ......................................... 9-55
data types.................................................. 9-58
reset application ....................................... 9-54
general structure....................................... 9-56
reset communication ................................ 9-54
structure ...................................................... 6-3
stopped ..................................................... 9-55
structured entries ...................................... 9-60
data type
object name .................................................. 9-57
BOOLEAN .................................................. 9-3
pre-defined connection set........................... 9-55
compound ................................................... 9-6
process data object
DOMAIN...................................................... 9-7
general ........................................................ 9-7
INTEGERn.................................................. 9-4
transmission mode ..................................... 9-8
NIL............................................................... 9-3
triggering mode........................................... 9-8
OCTET_STRING........................................ 9-6
protocol specification...................................... 6-1
REAL32....................................................... 9-5
RECORD ...................................................... 9-57
TIME_DIFFERENCE.................................. 9-7
reference model.............................................. 6-1
TIME_OF_DAY........................................... 9-6
service data object
UNICODE_STRING ................................... 9-6
abort codes ............................................... 9-26
UNSIGNEDn............................................... 9-3
block download ......................................... 9-16
VISIBLE STRING ....................................... 9-6
block upload.............................................. 9-17
VOIDn ......................................................... 9-3
download................................................... 9-12
DEFSTRUCT................................................ 9-57
general ...................................................... 9-11
DEFTYPE ..................................................... 9-57
upload........................................................ 9-14
device model .................................................. 6-2
service objects................................................ 6-1
device profile .................................................. 6-3
service primitives ............................................ 6-1
DOMAIN ....................................................... 9-57
service specification ....................................... 6-1
dummy mapping........................................... 9-58
service type..................................................... 6-2
error control
state diagram ................................................ 9-52
general ...................................................... 9-42
guarding
state transitions ............................................ 9-55
VAR............................................................... 9-57
12-1
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement