CANopen 15-Nov-2005

CANopen
high-level protocol for CAN-bus
H. Boterenbrood

NIKHEF, Amsterdam
November 15, 2005

Version 3.1

Contents
1 INTRODUCTION ......................................................................................................................................... 2

2 CAL................................................................................................................................................................. 2

3 CANOPEN ..................................................................................................................................................... 3
3.1 CANOPEN OBJECT DICTIONARY .............................................................................................................. 3
3.2 CANOPEN COMMUNICATION .................................................................................................................... 5
3.3 CANOPEN PREDEFINED CONNECTION SET ............................................................................................... 7
3.4 CANOPEN IDENTIFIER DISTRIBUTION ....................................................................................................... 8
3.5 CANOPEN BOOT-UP PROCESS ................................................................................................................... 9
3.6 DETAILS OF CANOPEN MESSAGE SYNTAX .............................................................................................. 10
3.6.1 NMT Module Control ................................................................................................................... 10
3.6.2 NMT Node Guarding.................................................................................................................... 10
3.6.3 NMT Boot-up ................................................................................................................................ 10
3.6.4 PDO ............................................................................................................................................... 11
3.6.5 SDO ............................................................................................................................................... 11
3.6.6 Emergency Object ......................................................................................................................... 14
4 SUMMARY.................................................................................................................................................. 16

5 EXAMPLE OF A CANOPEN OBJECT DICTIONARY FOR DEVICES WITH CS5525 ADCS....... 17

5.1 INTRODUCTION ....................................................................................................................................... 17
5.2 ADC READ-OUT ..................................................................................................................................... 17
5.3 ADC CONFIGURATION AND CALIBRATION ............................................................................................. 18
5.4 THE OBJECT DICTIONARY ...................................................................................................................... 18
5.5 EMERGENCY OBJECTS ............................................................................................................................ 22
REFERENCES .................................................................................................................................................... 23

1
CANopen 15-Nov-2005

Version History
Version Date Comments
1.x 1998 First draft versions
2.0 1999 Change of title; change in chapter numbering; addition of CAN message syntax
details
2.0a 7 April 1999 Corrected error in table 7 and 8 captions
3.0 20 March 2000 Several additions in accordance with CiA DS301 CANopen Communication Pro-
file Version 4.0 (update from 3.0)
3.1 15 Nov 2005 Some additions to description of SDO.

CANopen standard is based and subsequently

1 Introduction CANopen itself and the profiles that define it.

The relation between OSI network model, CAN-

Fieldbus networks from the OSI network model bus standards and CANopen profiles is illustrated in
point-of-view usually only have the layers 1 (Physi- Figure 1.
cal Layer), 2 (Datalink Layer) and 7 (Application
Layer) implemented. The intermediate layers are
not needed because a fieldbus network usually con- Device Profile Device Profile Device Profile
sists of a single network segment only (no need for CiA DSP-401 CiA DSP-404 CiA DSP-xxx
Transport and Network Layer, layer 3 and 4) and OSI Layer 7
has no notion of 'sessions' (layer 5) or a need for Application Communication Profile CiA DS-301
different internal data 'presentation' (layer 6). Layer

The CAN (Controller Area Network) fieldbus de-

fines only the layers 1 and 2 (ISO11898); in prac- OSI Layer 2
CAN Controller
CAN 2.0A
Chip
tice these are completely handled by the CAN Data Link
hardware, significantly reducing the implementa- Layer
tion effort for developers of the fieldbus node
firmware.

However, a high level protocol is necessary in or- + - ISO 11898

der to define how the CAN message frame's 11-bit OSI Layer 1 + -
Physical Layer
identifier and 8 data bytes are used. Building CAN-
based industrial automation systems guaranteeing
interoperability and interchangeability of devices of
different manufacturers requires a standardized ap- Cable
plication layer and 'profiles', standardizing the
communication system, the device functionality and
the system administration: Figure 1. Schematic overview of CAN and
CANopen standards in the OSI net-
♦ The application layer provides a set of services work model.
and protocols useful to every device on the net-
work imaginable.
2 CAL
♦ The communication profile provides the means
to configure devices and communication data One of the existing higher layer communication
and defines how data is communicated between protocols for CAN-based networks –developed by
devices. Philips Medical Systems– is CAL (CAN Applica-
tion Layer). It was adopted by the independent
♦ Device profiles add device-specific behaviour CAN users and manufacturer group CAN in
for (classes of) devices (e.g. digital I/O, analog Automation (CiA), developed further and pub-
I/O, motion controllers, encoders, etc.). lished in a series of standards [1].

The following sections describe the CAL applica-

tion layer for CAN networks on which the

2
CANopen 15-Nov-2005

CAN Application Layer (CAL)

CAL provides 4 application layer service elements:
COB-ID Usage
1. CMS (CAN-based Message Specification): 0 NMT start/stop services
offers objects of type Variable, Event and Do- 1 - 220 CMS objects priority 0
main to design and specify how the functional- 221 - 440 CMS objects priority 1
ity of a device (a node) can be accessed through 441 - 660 CMS objects priority 2
its CAN interface (e.g. how to up- or download 661 - 880 CMS objects priority 3
a set of data ('domain') exceeding the 8 bytes 881 - 1100 CMS objects priority 4
maximum data content of a CAN-message, in- 1101 - 1320 CMS objects priority 5
cluding an 'abort transfer' feature). 1321 - 1540 CMS objects priority 6
CMS derives from MMS (Manufacturing Mes- 1541 - 1760 CMS objects priority 7
sage Specification), which is an OSI application 1761 - 2015 NMT Node Guarding
layer protocol designed for the remote control 2016 - 2031 NMT, LMT, DBT services
and monitoring of industrial devices.
Table 1. COB-ID (11-bit CAN-identifier) map-
2. NMT (Network ManagemenT): ping to CAL services and objects.
offers services to support network management,
e.g. to initialize, start or stop nodes, detect node
failures; this service is implemented according 3 CANopen
to a master-slave concept (there is one NMT
master). CAL provides all network management services
and message protocols, but it does not define the
3. DBT (DistriBuTor): contents of the CMS objects or the kind of objects
offers a dynamic distribution of CAN identifiers being communicated (it defines how, not what).
(officially called COB-ID, Communication Ob- This is where CANopen enters the picture.
ject Identifier) to the nodes on the network; this
service is implemented according to a master- CANopen is built on top of CAL, using a subset of
slave concept (there is one DBT master). CAL services and communication protocols; it pro-
vides an implementation of a distributed control
4. LMT (Layer ManagemenT): system using the services and protocols of CAL.
offers the ability to change layer parameters e.g. It does this in such a way that nodes can range
change the NMT-address of a node, from simple to complex in their functionality with-
or change bit-timing and baud-rate of the CAN- out compromising the interoperability between the
interface. nodes in the network.

CMS defines 8 priority levels in its messages, Central concept in CANopen is the Device Object
each having 220 COB-IDs, occupying COB-IDs 1 Dictionary (OD), a concept used in other fieldbus
to 1760; the remaining identifiers (0, 1761-2031) systems as well (Profibus, Interbus-S).
are reserved for NMT, DBT and LMT. See Table 1. Note that the Object Dictionary concept is not
In a CAN-network the lower the value of the part of CAL, it is an implementation aspect of
COB-ID, the higher the priority of the correspond- CANopen.
ing message on the network is.
In the following sections we will first present the
Note that this standard assumes CAN2.0A (CAN Object Dictionary, and only then the CANopen
Standard Message Frame) having an 11-bit identi- communication mechanisms.
fier, allowing a range of [0, 2047], but which -for
historical reasons- is limited to [0, 2031]. However
using CAN2.0B (CAN Extended Message Frame)
3.1 CANopen Object Dictionary
with 29-bit identifier doesn't change the picture: the
11-bits range in the table maps to the 11 most sig-
nificant bits of the 29-bits COB-ID and the COB- The CANopen Object Dictionary (OD) is an or-
ID ranges in the table will just become (much) lar- dered grouping of objects; each object is addressed
ger. using a 16-bit index. To allow individual elements
of structures of data to be accessed an 8-bit sub-
index has been defined as well. The general layout
of the CANopen OD is shown in Table 2.
Don't be confused by all the 'data types' located in
the OD at indices below 0FFF; they're there mainly

3
CANopen 15-Nov-2005

for definition purposes only. The relevant range of a whether the object is 'read only' or 'write only' or
node's OD lies between 1000 and 9FFF. 'read/write', etc.

For every node in the network there exists an OD. The description of a device's communication
The OD contains all parameters describing the de- functionality and objects and its device-specific
vice and its network behaviour. objects and their default values is proviced in the
The OD of a node mainly exists in the form of a form of an Electronic Data Sheet (EDS), an ASCII
database described in the EDS (see below) or on file with a strictly defined syntax.
paper. It is not necesssarily possible to 'interrogate' A description of the object configuration of an
a node via the CAN-bus about all its parameters in individual device is called a Device Configuration
its OD. It is sufficient if the node behaves exactly File (DCF) and has the same structure as an EDS.
according to its OD description on paper. The node Both file types are defined in the CANopen specifi-
itself only needs to be able to present at least all cation.
mandatory OD entries (as dictated by CANopen; The profiles define which OD objects are manda-
these are actually very few), and optionally any tory and which are optional; the number of manda-
other entries that form part of the configurable tory objects is kept to a minimum allowing lean
functionality of the node. implementations.
Optional features –in the communication part as
CANopen is defined in the form of documents de- well as the device-specific part– can be added as
scribing profiles. required to extend a CANopen device's functional-
ity.
There is the communication profile [2] describ- If more features are required than are present in
ing the general form of the OD and the objects in the profile, there is plenty of space in the profile
the OD's Communication Profile Area, the commu- available for the addition of manufacturer-specific
nication parameters; it also describes the CANopen functionality.
communication objects (see next section); this pro-
file applies to all CANopen devices. So the part of the OD describing the communica-
Then there are the various device profiles (e.g. tion parameters is the same for all CANopen de-
[3]) defining for a particular type of devices the OD vices (i.e. object placing in the OD is the same, not
objects; there are now about 5 different device pro- necessarily the value of the object…), the device-
files and several more are under development. specific part of the OD is different for different
A profile describes for each OD object its func- (classes of) devices.
tion, its name, its index and sub-index, its data type,
whether the object is mandatory or optional,

CANopen Object Dictionary

Index Object
0000 not used
0001 - 001F Static Data Types (standard data types, e.g. Boolean, Integer16)
0020 - 003F Complex Data Types (predefined structures composed of standard
data types, e.g. PDOCommPar, SDOParameter)
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
1000 - 1FFF Communication Profile Area
(e.g. Device Type, Error Register, Number of PDOs supported)
2000 - 5FFF Manufacturer Specific Profile Area
6000 - 9FFF Standardised Device Profile Area (e.g. "DSP-401 Device Profile for
I/0 Modules" [3]: Read State 8 Input Lines, etc.)
A000 - FFFF reserved
Table 2. General CANopen Object Dictionary structure ('Index' in hexadecimal notation).
The terms 'PDO' and 'SDO' denote CANopen communication objects, described in the next section.

4
CANopen 15-Nov-2005

Trans- Condition to trigger PDO

(B=both needed, O=one or both) PDO
Mission
Transmission
Type
SYNC* RTR* Event*
0 B - B Sync, acyclic
1-240 O - - Sync, cyclic
241-251 - - - reserved
252 B B - Sync, after RTR
253 - O - Async, after RTR
254 - O O Async, manufacturer specific event
255 - O O Async, device profile specific event
*SYNC= SYNC-object received.
*RTR = Remote Transmission Request received (= a 'Remote Frame' CAN-message).
*Event = e.g. 'Change-of-Value' or timer-interrupt.

Table 3. Definition of PDO transmission types in CANopen; for types 1 to 240 the number indicates
the number of SYNC objects between two PDO transmissions.
¾ An SDO is implemented as a CMS object of
3.2 CANopen communication type 'Multiplexed Domain' according to
CAL, thus permitting transfer of data of any
length (as data is split up over several CAN
Now that we have presented the concept of the
messages if necessary, which is when data
Object Dictionary we now will look at the messages
occupies more than 4 bytes).
that are communicated in CANopen networks, their
The protocol is of the 'confirmed service'
content and their function, in other words: the
type: a reply is generated for every CAN
CANopen communication model (see [2]).
message (one SDO requires 2 CAN-
identifiers). The SDO request and reply mes-
NB: be sure to make the distinction between OD sage always contain 8 bytes (the number of
objects (objects in the Object Dictionary) – non-significant bytes is shown as part of the
characterized by their OD index and sub-index, as first byte, which carries protocol informa-
described in the previous section– and communica- tion), thus communication via an SDO has a
tion objects or messages, characterized by their considerable overhead.
COB-ID or CAN-identifier, described in this sec-
tion. 3. Process Data Object (PDO):
¾ Is used to transfer real-time data; data is
The CANopen communication model defines four transferred from one (and only one) pro-
types of messages (communication objects): ducer to one or more consumers. Data trans-
fer is limited to 1 to 8 bytes (for example:
1. Administrative message: one PDO can transfer at maximum 64 digital
¾ Layer management, network management I/O values, or 4 16-bit analogue inputs).
and identifier distribution services: i.e ini- It has no protocol overhead. The data con-
tialisation, configuration and supervision of tent of a PDO is defined through its CAN-
the network (the latter aspect includes identifier only and this content is assumed
'node/life guarding': see below). known to sender as well as receiver(s) of the
¾ Services and protocols are according to the PDO.
LMT, NMT and DBT service elements of ¾ Each PDO is described by 2 objects in the
CAL. These services are all based on a Mas- Object Dictionary:
ter-Slave concept: in a CAN-network there ♦ PDO Communication Parameter: con-
is only one LMT-, NMT- or DBT-master tains which COB-ID is used by the PDO,
and one or more slaves. the transmission type, inhibit time and
timer period (see below for more details).
2. Service Data Object (SDO): ♦ PDO Mapping Parameter: contains a list
¾ An SDO provides a client access to entries of objects from the Object Dictionary
(objects) of a device OD (the device is the that are mapped into the PDO, including
server) using the object's OD index and sub- their size in bits (the producer as well as
index, contained in the first few bytes of the the consumers of a PDO have to know
CAN-message. the mapping to be able to interpret the
contents of a PDO).

5
CANopen 15-Nov-2005

¾ Contents of the PDO message is predefined

(or is configured at network start-up): 4. Predefined messages or Special Function Ob-
mapping of application objects into a PDO is jects:
described in the devices' OD (producer as well ¾ Synchronization (SYNC)
as consumer(s)) by the PDO Mapping Parame- ♦ Used to synchronize tasks network-wide
ter, and is configurable using SDO messages if (particularly relevant for drive applica-
'variable PDO mapping' is supported by the de- tions): actual values of inputs are stored
vice(s) (producer and consumers). quasi-simultaneously network-wide and
¾ A PDO can have a number of transmission subsequently transmitted (if required),
modes: output values are updated according to
♦ synchronous (synchronization by receipt messages received after the previous
of a SYNC object, see next message SYNC.
type): ♦ Master-slave concept: SYNC master is-
‰ acyclic (synchronized with respect to sues the periodic SYNC object, SYNC
SYNC message but not periodical): slaves carry out their synchronous tasks
ƒ transmission is 'pre-triggered' by a on reception.
remote transmission request from ♦ Transmission of a synchronous PDO is
another device, within a given time window with respect
ƒ transmission is 'pre-triggered' by to the transmission of the SYNC mes-
the occurrence of an object- sage.
(device-)specific event specified ♦ Implemented as a CMS object of type
in the device profile. 'Basic Variable'.
‰ cyclic: transmission is triggered peri- ♦ CANopen suggests a COB-ID in the
odically after every 1, 2 or up to 240 highest priority group to ensure a regular
SYNC messages. synchronization signal; to keep the mes-
♦ asynchronous: sage as short as possible no data bytes
‰ transmission is triggered by a remote are transferred.
transmission request (by a CAN Re-
mote Frame) from another device, ¾ Time Stamp
‰ transmission is triggered by the oc- ♦ Provides application devices a common
currence of an object (device) spe- time frame reference.
cific event specified in the device ♦ Implemented as a CMS object of type
profile (e.g. an input-change-of-value 'Stored Event'.
or a timer event).
Table 3 gives an overview of the different ¾ Emergency
PDO transmission modes as defined by the ♦ Is triggered by the occurrence of a device
transmission type, part of the PDO Commu- internal error.
nication Parameter object and defined as an
♦ Implemented as a CMS object of type
unsigned 8-bit integer.
'Stored Event'.
¾ A PDO can be assigned an inhibit time, de-
fining the minimum time between two con-
¾ Node/Life Guarding
secutive PDO transmissions, to prevent
♦ Master-slave concept.
'starvation' on the network. Inhibit time is a
♦ The NMT master monitors the state of
part of the PDO Communication Parameter
the nodes: this is called node guarding.
object and is defined as an unsigned 16-bit
♦ Nodes optionally monitor the state of the
integer in units of 100 μs.
NMT master: this is called life guarding;
¾ A PDO can be assigned an event timer pe-
it starts on the NMT slave after it has re-
riod where PDO transmission is triggered
ceived the first Node Guard message
periodically when a specified time has
from the NMT master.
elapsed (without the occurrence an alterna-
tive trigger); it is defined as an unsigned 16- ♦ Detects errors in the network interfaces
bit integer in units of 1 ms. of the devices, not failures in the device
¾ A PDO is implemented as a CMS object of itself: these are reported by means of the
type 'Stored-Event' according to CAL, mean- Emergency.
ing that the data is transferred with no proto- ♦ Implemented according to the NMT node
col overhead and that the message is not guarding protocol:
confirmed (one PDO requires one CAN- a Remote Transmission Request from the
identifier); NMT master to a particular node triggers
a maximum of 8 bytes (64 bits) of data can a reply containing the node's state.
be transferred.

6
CANopen 15-Nov-2005

CANopen device

Communication Object Application:

CAN Interface: Dictionary: I/O

PDOs Data Types, Application

SDOs, Communication Program,
Special Function Objects, Device Profile
Objects, Application Implementation
NMT Objects Objects

Figure 2. Schematic relationship between CAN-bus communication, Object Dictionary and applica-
tion software on a CANopen device.
¾ Boot-up responding identifiers only for the supported com-
♦ Master-slave concept. munication objects.
♦ By sending this message the NMT slave
indicates to the NMT master that is has The allocation scheme is based on the division of
transitioned from state Initialising to the 11-bit CAN-identifier into a 4-bit function code
state Preoperational (see section 3.5). part and a 7-bit node-identifier (Node-ID) part as
shown in Figure 3.
So two of the above-mentioned types of commu- ← Bit number
nication objects are meant for data transfer. They 10 9 8 7 6 5 4 3 2 1 0
implement two different mechanisms of data trans-
fer:
♦ SDO is used for (large,) low-priority data trans- Function Code Node-ID
fer between devices, typically used for configur-
ing the devices on a CANopen network.
♦ PDO is used for fast data transfer of 8 bytes of Figure 3. Structure of the 11-bit CAN-identifier
data or less without protocol overhead (the in the CANopen Predefined Master /
meaning of the data content has been defined Slave Connection Set.
beforehand).
The Node-ID is defined by the system integrator,
A CANopen device has to support a number of the for example by setting DIP switches on the device.
network management services (administrative mes- The Node-ID has to be in the range from 1 to 127
sages) and needs a minimum of one SDO. Each (0 (zero) not allowed).
CANopen device that produces or consumes proc-
ess data should have at least one PDO. All other The predefined connection set defines 4 Receive
communication objects are optional. PDOs, 4 Transmit PDOs, 1 SDO (occupying 2
CAN-identifiers), 1 Emergency Object and 1 Node-
For more details about the various CANopen Error-Control Identifier.
communication objects see [2]. See also section 3.6. It also supports the broadcasting of non-
confirmed NMT-Module-Control services, SYNC-
The relation between CAN communication, the and Time Stamp-objects.
Object Dictionary and application software on a
CANopen device is schematically illustrated in The resulting CAN-identifier allocation scheme is
Figure 2. shown in Table 4.

3.3 CANopen Predefined Connec- The identifier distribution corresponds to a mas-

ter/slave connection set because all peer-to-peer
tion Set identifiers are different so that in fact only a master
device that knows all connected Node-IDs can
In order to reduce configuration effort for simple communicate to each individual connected slave
networks a mandatory default CAN-identifier allo- node (up to 127 nodes) in a peer-to-peer fashion.
cation scheme is defined. These identifiers are Two connected slaves would not be able to com-
available in the Pre-Operational state (see section municate because they don't know eachother's
3.5 CANopen boot-up) immediately following ini- Node-ID.
tialisation and may be modified by means of dy-
namic distribution. A device has to provide the cor-

7
CANopen 15-Nov-2005

Broadcast objects of the CANopen Predefined Master/Slave Connection Set

Function code Communication
Object COB-ID
(ID-bits 10-7) parameters at OD index
NMT Module Control 0000 000h –
SYNC 0001 080h 1005h, 1006h, 1007h
TIME STAMP 0010 100h 1012h, 1013h

Peer-to-Peer objects of the CANopen Predefined Master/Slave Connection Set

Function code Communication

Object COB-ID *
(ID-bits 10-7) parameters at OD index
EMERGENCY 0001 081h - 0FFh 1024h, 1015h
PDO 1 (transmit) 0011 181h - 1FFh 1800h
PDO 1 (receive) 0100 201h - 27Fh 1400h
PDO 2 (transmit) 0101 281h - 2FFh 1801h
PDO 2 (receive) 0110 301h - 37Fh 1401h
PDO 3 (transmit) 0111 381h - 3FFh 1802h
PDO 3 (receive) 1000 401h - 47Fh 1402h
PDO 4 (transmit) 1001 481h - 4FFh 1803h
PDO 4 (receive) 1010 501h - 57Fh 1403h
SDO (transmit/server) 1011 581h - 5FFh 1200h
SDO (receive/client) 1100 601h - 67Fh 1200h
NMT Error Control 1110 701h - 77Fh 1016h, 1017h

Table 4. Assignment of CAN-identifiers in the CANopen Predefined Master/Slave Connection Set.

("PDO/SDO transmit/receive" is from the (slave) CAN-node point of view). NMT Error Con-
trol includes Node Guarding, Heartbeat and Boot-up protocols.

Comparing the identifier mapping of the default next section), using the (predefined) SDO to
CANopen set in Table 4 to the mapping of CAL in write new values to the appropriate locations
Table 1 clearly shows how CANopen objects with in the node's Object Dictionary.
specific defined functions map to the general CMS
objects of CAL, illustrating how CANopen imple- ¾ using the CAL DBT (DistriBuTor) services:
ments a system using the more general CAL facili- nodes or slaves connected to a CANopen net-
ties. work are initially identified by their configured
Node-ID. The Node-ID may be configured by
3.4 CANopen identifier distribution setting DIPswitches on the device or by use of
CAL Layer Management services (LMT).
When the network initializes and boots the
The allocation of CAN-identifiers (or COB-IDs)
network master initially establishes a dialog
in CANopen can take place in 3 different ways:
with each connected slave by means of a 'Con-
nect_Remote_Node' telegram (a CAL NMT
¾ using the Predefined Master/Slave Connection
service). Once this dialog has been established
Set (see previous section):
the CAN identifiers for communication of
allocation of identifiers is default, so no con-
SDOs and PDOs are allocated to the node us-
figuration is needed; configuration of PDO
ing CAL Distribution services (DBT); it re-
data contents (socalled PDO mapping) is pos-
quires the node to support extended boot-up
sible if the node supports it.
(see next section).
¾ modifying the PDO identifiers after power-up
(when the node is in Pre-Operational state; see

*
The COB-ID range covers the allowed Node-ID range from 1 to 127.

8
CANopen 15-Nov-2005

3.5 CANopen boot-up process The CAN-message carrying this NMT service
consists of the CAN-header (with COB-ID=0) and
two data bytes, 1 byte containing the requested ser-
In the network initialisation process CANopen
vice ('NMT command specifier') and the second
supports a socalled extended boot-up as well as a
byte the Node-ID, or zero which addresses all nodes
socalled minimum boot-up process.
simultaneously.
Extended boot-up is optional, minimum boot-up
has to be supported by all CANopen devices or
There is one node the CAN-network that acts as
nodes; both types of nodes can exist side-by-side on
the NMT-master. It issues the NMT messages and
the same network.
controls the node initialization process.
A node has to support the extended boot-up proc-
CANopen devices supporting only the minimum
ess if the identifier distribution is by means of CAL
boot-up are also called minimum capability devices.
DBT services (see previous section).
Minimum capability devices enter the Pre-
Operational state automatically after finishing the
Both initialisation processes can be represented
device initialization. In this state device parameteri-
by a device or node state-transition diagram as
zation and COB-ID-allocation via SDO is possible.
shown in Figure 4 for a minimum boot-up node.
By switching a device into the Prepared state it is
The extended boot-up state diagram has a few more
forced to stop communication altogether, except
states between the Pre-Operational and the Opera-
NMT services, and node guarding, if supported and
tional state.
active. ('Stopped' would be a better name to de-
scribe this state).
NMT services are used to bring all or selected
nodes into various operating states at any time.

Power-on

Initialising
(f)

5 6 4

Pre-Operational
(a, b, c, d) 3
1 2
Stopped
1 (a, b)
3
2
Operational
(a, b, c, d, e)

Figure 4. State transition diagram for a CANopen minimum boot-up node. The letters in brackets
show which communication object types are allowed inside the different states:
a. NMT, b. Node Guard, c. SDO, d. Emergency, e. PDO, f. Boot-up

State transitions (1-5: initiated by NMT services) and the NMT command specifier (in brackets):
1: Start_Remote_Node (0x01)
2: Stop_Remote_Node (0x02)
3: Enter_Pre-Operational_State (0x80)
4: Reset_Node (0x81)
5: Reset_Communication (0x82)
6: Device initialisation finished,
enter Pre-Operational state automatically, send Boot-up message

9
CANopen 15-Nov-2005

3.6 Details of CANopen Value State

message syntax 0 Initialising
1 Disconnected *
2 Connecting *
In the following sections the COB-IDs used are
3 Preparing *
as defined in the CANopen Predefined Connection
4 Stopped
Set.
5 Operational
127 Pre-operational
3.6.1 NMT Module Control
Only the NMT-Master issues NMT Module Con- States marked with * are present only in nodes
trol messages. All slaves must support the NMT that support extended boot-up (see previous sec-
Module Control services. There is no response to an tion). Note that state 0 never occurs in a Node
NMT Module Control message. The NMT message Guard reply because a node does not respond to
has the following format: Node Guard messages when in this state.
NMT-Master ⇒ NMT-Slave(s)
Alternatively a node can be configured to produce
COB-ID Byte 0 Byte 1 a periodical so-called Heartbeat message:
0x000 CS Node-ID
HEARTBEAT Producer ⇒ Consumer(s)
With Node-ID=0 (zero) all connected NMT COB-ID Byte 0
slaves are addressed. CS is the Command Specifier, 0x700 + Node_ID state
which can have the following values (also see
Figure 4): with state any of the following:
state Meaning
Command 0 Boot-up
NMT Service
Specifier 4 Stopped
1 Start Remote Node 5 Operational
2 Stop Remote Node 127 Pre-operational
128 Enter Pre-operational State
129 Reset Node When a node with a Heartbeat boots up its Boot-
130 Reset Communication up message (see next section) is its first Hearbeat
message. The Heartbeat consumer typically is the
NMT-master which should have a time-out for each
3.6.2 NMT Node Guarding node with a Heartbeat and takes appropriate action
Using Node Guarding the NMT-Master can check if a time-out occurs.
on the current state of individual nodes, which is
especially useful when these nodes are not polled A node is not allowed to support both Node
for data on a regular basis. Guarding and Heartbeat protocols at the same time.
The NMT-Master sends a CAN remote frame (no
data bytes) as follows:
3.6.3 NMT Boot-up
NMT-Master ⇒ NMT-Slave
An NMT-Slave issues the Boot-up message to in-
COB-ID dicate to the NMT-Master that it has entered the
0x700 + Node_ID state Pre-operational from state Initialising:

The NMT-Slave replies with the following mes- NMT-Master ⇐ NMT-Slave

sage: COB-ID Byte 0
NMT-Master ⇐ NMT-Slave 0x700 + Node_ID 0

COB-ID Byte 0
0x700 + Node_ID bit 7: toggle, bit 6-0: state

The data byte contains a toggle bit (bit 7) that

should alternate between '0' and '1' for every Node
Guard request (first time = 0).
Bits 0 to 6 denote the node's state which can be
one of the following (compare to Figure 4):

10
CANopen 15-Nov-2005

3.6.5 SDO
The Service Data Object (SDO) is used to access
3.6.4 PDO the Object Dictionary of a device. The requester of
As an example lets assume the mapping of the the OD access is called the Client and the CANopen
second transmit-PDO is as follows (in CANopen device, whose OD is accessed and services the re-
described by Object Dictionary entry 0x1A01): quest, is called the Server. The Client CAN-
message as well as the reply Server CAN-message
always contain 8 bytes (although not all bytes nec-
Object 0x1A01: 2nd transmit PDO mapping
essarily contain meaningful data). A Client request
Subindex Value Meaning is always confirmed by a reply from the Server.
0 2 2 objects are mapped There are 2 mechanisms for SDO transfer:
into the PDO ♦ Expedited transfer: used for data objects up to
1 0x60000208 Object 0x6000, subin- 4 bytes in length.
dex 0x02, consisting of ♦ Segmented transfer: for objects with length > 4
8 bits bytes.
2 0x64010110 Object 0x6401, subin-
dex 0x01, consisting of The basic structure of an SDO is:
16 bits Client ⇒ Server / Server ⇒ Client
In the definitions of the CANopen Device Profile Byte 0 Byte 1-2 Byte 3 Byte 4-7
for I/O modules (CiA DSP-401, [3]) Object 0x6000 SDO
Object Object
sub 0x02 is the second set of 8 bits of digital inputs Command **
Index Subindex
on the node and Object 0x6401 sub 0x01 is the first Specifier
16-bit analog input on the node. (** up to 4 bytes data (expedited transfer)
or a 4 bytes byte-counter (segmented transfer)
This PDO, if it is sent (triggered by a change of or parameters regarding block transfer
input, a timer interrupt, a remote transmission re- (new SDO transfer mechanism, see below))
quest, etc., in accordance with the PDO's transmis- or
sion type (see Table 3), to be found in Object Client ⇒ Server / Server ⇒ Client
0x1801 subindex 2) thus consists of a CAN- Byte 0 Byte 1-7
message with 3 data bytes and looks like this: SDO up to 7 bytes of data
PDO-producer ⇒ PDO-consumer(s) Command (segmented transfer)
Specifier
COB-ID Byte 0 Byte 1 Byte 2
0x280 + 8-bits LSB 16-bit MSB 16-bit
The SDO Command Specifier contains the follow-
Node_ID digital in analog in analog in
ing information:
By changing the contents of Object 0x1A01 the ♦ download / upload
contents of the PDO can be changed (if the node ♦ request / response
supports this (so-called variable PDO mapping)). ♦ segmented / expedited transfer
♦ number of data bytes in this CAN-frame
Note that in CANopen multi-byte parameters are ♦ alternating toggle bit for each subsequent seg-
always sent LSB first (so-called little endian). ment

There can never be more than 8 bytes of data in There are 5 request/response protocols imple-
total mapped to a particular PDO. mented in SDO: Initiate Domain Download,
Download Domain Segment, Initiate Domain
In [5] a so-called multiplexor PDO (MPDO) is Upload, Upload Domain Segment and Abort
defined, enabling a single PDO to be used for trans- Domain Transfer.
ferring a large number of variables by including in
its message bytes the source or destination node-id
and Object Dictionary index and subindex.
If for example a node has 64 16-bit analog chan-
nels it would otherwise need 16 different transmit-
PDOs to send its data if such a mechanism would
not be available.

11
CANopen 15-Nov-2005

In the latest version of the CANopen communica- Initiate Domain Upload (Cmd Specifier)
tion profile a new SDO transfer mechanism is in- Bit 7 6 5 4 3 2 1 0
troduced:
Client⇒ 0 1 0 – – – – –
♦ Block transfer: in which multiple segments are
confirmed by only 1 confirm message (from ⇐Server 0 1 0 – n e s
Server in case of download, from Client in case
of upload) in order to increase bus throughput n, e, s: as for Initiate Domain Download.
for objects with length > 4 bytes, with associ- Server/Client bytes 1+2 contain the Object Index
ated protocols: Initiate Block Download, and byte 3 the Object Subindex.
Download Block Segment, End Block Client bytes 4 to 7 are reserved and set to 0.
Download, Initiate Block Upload, Upload
Block Segment and End Block Upload. Upload Domain Segment (Cmd Specifier)
Bit 7 6 5 4 3 2 1 0
'Download' means writing to the Object Diction- Client⇒ 0 1 1 t – – – –
ary and 'Upload' means reading from the Object ⇐Server 0 0 0 t n c
Dictionary.
n, c, t: as for Download Domain Segment.
The SDO Command Specifier (first data byte of an Client bytes 1 to 7 are reserved and set to 0.
SDO CAN-message) syntax and details for each of Server bytes 1 to 7 contain up to 7 bytes of data.
these protocols is shown in the tables below ("–"
stands for: don't care, should be zero).
SDO Client or Server can abort an SDO transfer by
Initiate Domain Download (Cmd Specifier) sending a message with the following SDO Com-
Bit 7 6 5 4 3 2 1 0 mand Specifier:
Client⇒ 0 0 1 – n e s
⇐Server 0 1 1 – – – – – Abort Domain Transfer (Cmd Specifier)
Bit 7 6 5 4 3 2 1 0
n valid if e=1 and s=1, otherwise 0; indicates the C⇒/⇐ S 1 0 0 – – – – –
number of bytes that do not contain data (bytes
4 to 7-n contain data). In case of an Abort Domain Transfer, data bytes 1
e 0 = normal transfer, 1 = expedited transfer. and 2 contain the Object index, byte 3 the Object
s size indicator, 0 = data set size not indicated, 1= sub-index and data bytes 4 to 7 contains a 32-bit
data set size indicated. abort code describing the reason of the abort.
e=0, s=0 data bytes reserved for further use by Table 7 lists a number of abort codes and descrip-
CiA tions as described in [2].
e=0, s=1 data bytes contain byte-counter, byte 4:
LSB, byte 7: MSB
e=1 data bytes contain data to be down- Initiate Block Download (Cmd Specifier)
loaded.
Server/Client bytes 1+2 contain the Object Index Bit 7 6 5 4 3 2 1 0
and byte 3 the Object Subindex. Client⇒ 1 1 0 – – cc s 0
Server bytes 4 to 7 are reserved and set to 0. ⇐Server 1 0 1 – – sc – 0

Download Domain Segment (Cmd Specifier) cc client CRC support on data, 0 = no, 1 = yes.
sc server CRC support on data, 0 = no, 1 = yes.
Bit 7 6 5 4 3 2 1 0
s size indicator, 0 = data set size not indicated,
Client⇒ 0 0 0 t n c 1= data set size indicated.
⇐Server 0 0 1 t – – – – s=0 data bytes reserved for further use by CiA
s=1 data bytes contain byte-counter, byte 4: LSB,
n indicates the number of bytes that do not contain byte 7: MSB
data (bytes 8-n to 7 do not contain data); zero if Server byte 4 contains blksize, the number of seg-
no segment size is indicated. ments per block, with 0<blksize<128.
c 0 = more segments to be downloaded, 1 = last
segment.
t toggle bit, must alternate for each subsequent
segment (first time = 0; equal for request / re-
sponse).
Client bytes 1 to 7 contain up to 7 bytes of data.
Server bytes 1 to 7 are reserved and set to 0.

12
CANopen 15-Nov-2005

Download Block Segment (Cmd Specifier) Download Block Segment (Cmd Specifier)
Bit 7 6 5 4 3 2 1 0 Bit 7 6 5 4 3 2 1 0
Client⇒ c 0 ⇐Server c 0
Client⇒ c 1 ⇐Server c 1
…etc… c seqno …etc… c seqno
⇐Server 1 0 1 – – – 1 0 Client⇒ 1 1 0 – – – 1 0

c : more segments to download, 0=yes, 1=no. c : more segments to upload, 0 = yes, 1 = no.
seqno : sequence number of segment, 0<seqno<128. seqno : sequence number of segment, 0<seqno<128.
Client data bytes contain at most 7 bytes of seg- Server data bytes contain at most 7 bytes of
ment data to be downloaded. segment data to be downloaded.
Server byte 1 contains the sequence number of Client byte 1 contains the sequence number of
the last segment that received successfully; if set to the last segment that received successfully; if set to
0 it indicates that the segment with sequence num- 0 it indicates that the segment with sequence num-
ber 1 was not received correctly and all segments ber 1 was not received correctly and all segments
have to be retransmitted. have to be retransmitted.
Server byte 2 contains blksize, the number of Client byte 2 contains blksize, the number of
segments per block that the client has to use for the segments per block that the Server has to use for the
next block download, with 0<blksize<128. next block upload, with 0<blksize<128.

End Block Download (Cmd Specifier) End Block Upload (Cmd Specifier)
Bit 7 6 5 4 3 2 1 0 Bit 7 6 5 4 3 2 1 0
Client⇒ 1 1 0 n – 1 ⇐Server 1 1 0 n – 1
⇐Server 1 0 1 – – – – 1 Client⇒ 1 0 1 – – – – 1

n : indicates the number of bytes in the last seg- n : indicates the number of bytes in the last seg-
ment of the last block that do not contain data ment of the last block that do not contain data
(bytes 8-n to 7 do not contain data). (bytes 8-n to 7 do not contain data).
Client bytes 1+2 contain the 16-bit CRC for the Server bytes 1+2 contain the 16-bit CRC for the
whole data set; the CRC is only valid if in Initiate whole data set; the CRC is only valid if in Initiate
Block Download cc and sc were both set to 1. Block Upload cc and sc were both set to 1.

Initiate Block Upload (Cmd Specifier)

Bit 7 6 5 4 3 2 1 0
Client⇒ 1 0 1 – – cc 0 0
⇐Server 1 1 0 – – sc s 0
Client⇒ 1 0 1 – – – 1 1

cc : client CRC support on data, 0 = no, 1 = yes.

sc : server CRC support on data, 0 = no, 1 = yes.
s : size indicator, 0 = data set size not indicated,
1= data set size indicated.
s=0 : data bytes reserved for further use by CiA
s=1 : data bytes contain byte-counter, byte 4: LSB,
byte 7: MSB
Client byte 4 contains blksize, the number of
segments per block, with 0<blksize<128.
Client byte 5 contains pst, Protocol Switch
Threshold in bytes to change the SDO transfer pro-
tocol, 0 = change of transfer protocol not allowed, 1
= if the size of the data in bytes that has to be up-
loaded is less or equal pst the Server can optionally
switch to Upload Domain protocol by responding
with the Initiate Domain Upload protocol.

13
CANopen 15-Nov-2005

Following below are a few examples to demon- A list of hexadecimal Emergency Error Codes is
strate the use of the SDO to access a node's Object shown in Table 5. The 'xx' part of the codes in this
Dictionary. list is defined by the appropriate device profile.

With the following SDO messages value 0x3FE is Emergency Meaning

written to Object Dictionary index 0x1801 sub- Error Code
index 3, of a node with Node-ID=2, using the Initi- 00xx Error Reset or No Error
ate Domain Download protocol with expedited 10xx Generic Error
transfer (2 bytes of data): 20xx Current
Client ⇒ Server (node #2) 21xx current, device input side
Byte 22xx current, inside the device
COB-ID
0 1 2 3 4 5 6-7 23xx current, device output side
602 2B 01 18 03 FE 03 – 30xx Voltage
Client ⇐ Server (node #2) 31xx mains voltage
32xx voltage inside the device
582 60 01 18 03 – – –
33xx output voltage
40xx Temperature
With the following SDO messages the same Ob-
ject Dictionary index 0x1801 sub-index 3 is read 41xx ambient temperature
back from the node, using the Initiate Domain Up- 42xx device temperature
load protocol where the server replies with an ex- 50xx Device hardware
pedited transfer (2 bytes of data): 60xx Device software
61xx internal software
62xx user software
Client ⇒ Server (node #2)
63xx data set
Byte
COB-ID 70xx Additional modules
0 1 2 3 4 5 6-7
80xx Monitoring
602 40 01 18 03 – – –
81xx Communication
Client ⇐ Server (node #2) 8110 CAN overrun
582 4B 01 18 03 FE 03 – 8120 Error Passive
8130 Life Guard Error or
Heartbeat Error
8140 Recovered from Bus-Off
3.6.6 Emergency Object 82xx Protocol Error
Emergency messages are triggered by the occur- 8210 PDO not processed
rence of a device internal (fatal) error situation and due to length error
are transmitted from the concerned application de- 8220 Length exceeded
vice to the other devices with the highest priority. 90xx External error
They can be used for interrupt type error alerts. F0xx Additional functions
FFxx Device specific
An Emergency messages consists of 8 bytes and
Table 5. Emergency Error Codes (hexadeci-
has the following format:
mal; 'xx' is device-profile dependent
Emergency-sender ⇒ Emergency-receiver(s) part).
COB-ID Byte 0-1 Byte 2 Byte 3-7
0x080 + Emergency Error Manufac-
Node_ID Error Code Register turer specific
(Object error field
0x1001)

14
CANopen 15-Nov-2005

The Error Register is contained in a device's Ob- Bit Error type

ject Dictionary (index 0x1001). The device can map
internal errors in this status byte, offering a quick 0 generic
overview of errors currently present. The meaning 1 current
of the bits is shown in Table 6. 2 voltage
3 temperature
The Manufacturer specific error field may con- 4 communication
tain any other device-dependent additional informa- 5 device profile specific
tion about the error. 6 reserved (=0)
7 manufacturer specific
Table 6. Bit definition of the 8-bit Error Regis-
ter (Object 0x1001 in the CANopen
Object Dictionary).

Abort Code Description

0503 0000 Toggle bit not alternated
0504 0000 SDO protocol timed out
0504 0001 Client/Server command specifier not valid or unknown
0504 0002 Invalid block size (Block Transfer mode only)
0504 0003 Invalid sequence number (Block Transfer mode only)
0503 0004 CRC error (Block Transfer mode only)
0503 0005 Out of memory
0601 0000 Unsupported access to an object
0601 0001 Attempt to read a write-only object
0601 0002 Attempt to write a read-only object
0602 0000 Object does not exist in the Object Dictionary
0604 0041 Object can not be mapped to the PDO
0604 0042 The number and length of the objects to be mapped would exceed PDO length
0604 0043 General parameter incompatibility reason
0604 0047 General internal incompatibility in the device
0606 0000 Object access failed due to a hardware error
0606 0010 Data type does not match, lengh of service parameter does not match
0606 0012 Data type does not match, lengh of service parameter is too high
0606 0013 Data type does not match, lengh of service parameter is too low
0609 0011 Sub-index does not exist
0609 0030 Value range of parameter exceeded (only for write access)
0609 0031 Value of parameter written too high
0609 0032 Value of parameter written too low
0609 0036 Maximum value is less than minimum value
0800 0000 General error
0800 0020 Data can not be transferred or stored to the application
0800 0021 Data can not be transferred or stored to the application because of local control
0800 0022 Data can not be transferred or stored to the application because of the present device
state
0800 0023 Object Dictionary dynamic generation fails or no Object Dictionary is present (e.g. OD
is generated from file and generation fails because of a file error)
Table 7. SDO Abort Domain Transfer: descriptions of hexadecimal abort codes (in byte 4-7). Byte 7 indi-
cates an ‘error class’ for which the following values are defined: 5 = Service, 6 = Access and 8 =
Other. Byte 6 indicates an ‘error code’ for which the following values are defined: 1 = Access, 2
= Non-existent, 3 = Inconsistent parameter, 4 = Illegal parameter, 6 = Hardware, 7 = Type con-
flict, 9 = Attribute.

15
CANopen 15-Nov-2005

The following 3 levels of compatibility can be

4 Summary distinguished (in increasing order of compatibility):

¾ Conformance:
In summary the CANopen standard for communi- the device can be connected to a CANopen
cation on CAN-bus based networks has the follow- network without disturbing the communica-
ing features: tion of the other devices: application layer
compatibility.
¾ Standardized description of device functional- ¾ Interoperability:
ity be means of a Device Object Dictionary. the device can exchange data with other nodes
¾ Standardized description of a device and its in the network: communication profile com-
configuration in the form of ASCII files: Elec- patibility.
tronic Data Sheet (EDS) and Device Configu- ¾ Interchangeability:
ration File (DCF). the device can substitute another one: device
¾ Data exchange and system administration profile compatibility.
based on CAL CMS.
¾ Standardized system boot-up and node guard- A CANopen device requires at least (minimum
ing based on CAL NMT. capability device):
¾ Definition of system-wide synchronous opera-
tions. ¾ a node-id,
¾ Definition of node-specific emergency mes- ¾ an object dictionary (contents depending on
sages. the device functionality),
¾ one SDO supporting the mandatory OD en-
By conforming to the guidelines contained in the tries (read-only),
CANopen communication profile and the appropri- ¾ support of the following NMT slave services:
ate CANopen device profile two independent manu- Reset_Node, Enter_Preoperational_State,
facturers can produce standardised devices, which Start_Remote_Node, Stop_Remote_Node, Re-
can be incorporated seemlessly into the same set_Communication,
CANopen CAN network. ¾ default profile ID-allocation.

16
CANopen 15-Nov-2005

(Another option would be to introduce one mul-

5 Example of a CANopen Ob- tiplexor per connected ADC and assign a PDO for
each ADC; a reason to do something like this could
ject Dictionary for Devices be the fact that all ADCs can in fact perform a con-
with CS5525 ADCs version simultaneously, so that in principle new
data is always available from every individual
ADC).
5.1 Introduction
The transmission of the PDO(s) with their con-
The CS5525 ADC ([4]) is a highly integraded tents of ADC value(s) can be triggered in different
A/D converter containing an instrumentation ampli- ways, e.g. at regular intervals using an on-board
fier, a programmable gain amplifier, a digital filter timer, or after the transmission of a SYNC object or
with programmable output update rate, calibration RTR (Remote Transmission Request) by the 'master'
circuitry and 4 output latch pins which can be used network-node, or by a combination of both events,
to control an external multiplexer to select any of as shown earlier. The way a PDO transmission is
up to 16 inputs. triggered should either be fixed (and documented in
the application documentation) or configurable via
In the case of the CRYSTAL-CAN ([7]) and the appropriate PDO Communication Parameter
SPICAN ([8]) hardware, there even can be 8, 16 or object in the node's Object Dictionary (this object
32 inputs to every ADC and up to 24 ADCs per contains among other things an 'inhibit time' with
CAN-node (for a total maximum number of 192 which the on-board timer interval could be set).
input channels).
One should realise that a conversion on this type
The CANopen Device Profile for I/O Modules of ADC can take quite a long time (conversion rate
(CiA DSP-401, [3]) is thus the natural starting point ranges from ca. 220 Hz down to around as low as 4
for designing an Object Dictionary for our applica- Hz), so that if a PDO is requested by SYNC or by
tions. The programmability of several ADC features RTR (CAN Remote Frame) and the conversion is
requires us (if we want to be able to use them) to started only then, the requester will have to wait for
include some custom objects in the library. This is the result for a longer time.
not a problem since there is room for manufacturer An option is to let the module continuously scan
specific extensions in the profile. its input channels, store the values locally and when
The large number of inputs per CAN node makes a PDO is requested send the last conversion value
us want something called 'multiplexed PDOs', of the appropriate input channel immediately. The
found in another device profile, the CANopen De- frequency of scanning the input channels of an
vice Profile for Measuring Devices and Closed- ADC could be matched to the above mentioned
loop Controllers (CiA DSP-404, [4]). Although this 'inhibit time'.
is not an officially approved mechanism, if we NB: in this way the frequency is connected to a
would not have it, we would need many different PDO, so if only one PDO per node is used all the
PDOs per node to monitor all analogue inputs in an node's ADCs will be scanned with the same fre-
efficient way (as mentioned earlier). quency.
Note: this mechanism has been superseded by an
approved multiplexor PDO mechanism, as de- It is also possible to initiate a conversion of a par-
scribed in [5]. ticular channel and get the result using an SDO.
This is done by reading the appropriate analog input
channel from the node's Object Dictionary (using an
5.2 ADC Read-out SDO message), which we will choose to map under
OD-index 6404H with 'channel number' as the sub-
index. These are the indices according to DSP-401
If the user has the choice of multiple ADCs per
for reading manufacturer specific analog input (we
node and the number of (multiplexed) channels per
require only 24-bit: 16-bit (or 20-bit if the CS5526
ADC is variable it has to be decided how to number
ADC is used) data plus 4-bit status).
all the input channels present on a node. It has been
Reading the inputs from the OD by means of SDO,
decided to reserve per ADC the maximum number
by the way, is a slow way of reading out the ADCs,
of channels an ADC can have (=32) and only per-
creating a lot of overhead on the CAN-bus.
mit to read the valid channels. This means there
will be gaps in the numbering of channels from one
ADC to the next, but that should not pose a prob-
lem. So if a node has three ADCs with 10 multi-
plexed input channels each they would number 1 to
10, 32 to 42 and 64 to 74.

17
CANopen 15-Nov-2005

™ input channel number in case of system off-

set calibration
5.3 ADC Configuration and Cali- ™ gain (full-scale) calibration type (system
bration oself)
™ input channel number in case of system gain
calibration
To enable configuration (e.g. number of inputs, ™ offset (offset register content after calibra-
input voltage range, etc) and calibration of individ- tion)
ual ADCs we have introduced a number of objects: ™ gain (gain register content after calibration)
an ADC-configuration object, an ADC-calibration-
configuration object and an ADC-reset-and- In some applications with CS5525 ADCs, these
calibrate object; one each of these objects should objects might be completely predefined and un-
be present for every ADC connected to the node. changeable; therefore they need not be readable
The objects are specific to our applications so we OD-objects on the node; it would be sufficient
will place them in the Manufacturer Specific Profile when the application documentation lists the ob-
Area (OD-index 2000H to 5FFF). jects and their values.
The ADC-reset-and-calibrate objects serve to
generate a reset and a calibration sequence on the
corresponding ADC, when written to. The ADC-
calibration-configuration object determines the pa-
5.4 The Object Dictionary
rameters of the calibration sequence (see [4]).
The following tables show in detail an Object
The ADC-configuration object contains (see [4] for Dictionary (OD) for a device with multiple CS5525
details): ADCs each with multiple analogue input channels.
Note that the OD described here is shown purely
™ the number of input channels multiplexed to as an example and has not been implemented as
this ADC such.
™ the offset register contents
™ the gain register contents There are three tables: one for each of the follow-
™ the conversion word rate ing OD parts: a communication, a device-profile
™ the input voltage range and a device-specific (manufacturer-specific) part.
™ unipolar or bipolar measurement mode
™ power save mode The column 'Attr' shows the access rights attrib-
ute of an object: RO=read-only (value can change),
The ADC-calibration-configuration object contains RW=read-or-write, WO=write-only.
(see [4] for details):
This OD is based on the CiA device profile for
™ conversion word rate during calibration I/O modules DSP-401 ([3]) and borrows some stuff
™ offset (zero-scale) calibration type (system from DSP-404 ([4], superseded now…). The ana-
or self) logue inputs are mapped onto the second transmit
PDO as in DSP-401.

18
CANopen 15-Nov-2005

Communication Profile Area

Index Sub Name Data/ Attr Default Comment
(hex) Index Object (hex)

1000 - Device type U32 RO 00040191 Meaning: DSP-401, analogue

inputs on device
1001 - Error register U8 RO 0 Error bits according to DS-301
(error status overview)
1002 - Manufacturer status reg * U32 RO 0 ADC errors/timeouts, etc.
1003 Predefined error field Array Contains list of recent errors
1004 #PDOs supported Array
0 Total #PDOs supported U32 RO 00000001 0 receive, 1 transmit PDO
1 #PDOs sync U32 RO 00000000 PDO after SYNC
2 #PDOs async U32 RO 00000001 PDO after RTR or 'event'

1008 - Manufacturer device name VisStr RO "xxxx" E.g. "CCTS" (Crystal-Can with
Temperature Sensors"
1009 - Manufacturer hardware VisStr RO "xxxx" 4-byte ASCII string
version
100A - Manufacturer software VisStr RO "xx.x" A version number as a 4-byte
version ASCII string, e.g, " 1.0"
100B - Node identifier U32 RO

100F - #SDOs supported U32 RO 00000001 0 client, 1 server SDO

1801 2nd transmit PDO parame- Record Data type = PDOCommPar

ters
0 Number of entries U8 RO 3
1 COB-ID used by PDO U32 RO 280+ According to CANopen Prede-
Node-ID fined Connection Set
2 Transmission type ♣ U8 RW FD 253 decimal
3 Inhibit time ♣ U16 RW 1000 If >0 node scans inputs with cor-
(in units of 100 μs) responding frequency (per ADC)
Limitation:
0.2 Hz <= frequency <= 25 Hz
(50000 >= inhibit time >= 400)

1A01 2nd transmit PDO mapping Record Data type = PDOMapping

0 Number of entries U8 RO 2
1 Multiplexor 1 U32 RO 6F100108 OD-index 6F10, sub-index 1:
Multiplexor 1 (see DSP-404);
Size = 8 bits
2 24-bit analogue input U32 RO 6404FD18 OD-index 6404, sub-index 253:
Analogue input, via multiplexor;
Size = 24 bits
Table 8. Communication Profile Area of the CANopen Object Dictionary for a device with CS5525 ADCs.

*
See text for the layout of the Manufacturer Status Register.
♣
if inhibit time = 0: transmission type 254,253 => one ADC conversion and PDO transmission after an RTR
transmission type 1 => one ADC conversion and PDO transmission after a SYNC
if inhibit time > 0: transmission type 254 => scan ADC(s), a PDO transmission after every conversion
transmission type 253 => scan ADC(s), one PDO transmission after an RTR
transmission type 1 => scan ADC(s), one PDO transmission after each SYNC

19
CANopen 15-Nov-2005

The status of every CS5525 ADC channel can be

read from the conversion status, which is part of the
channel read-out value. Other types of errors we log
in the Manufacturer Status Register (Object Dic-
tionary index 0x1002), a 32-bit object, thus provid-
ing 4 bits per ADC if we allow a maximum of 8
ADCs per node:

Bits 31-28 27-24 23-20 19-16 15-12 11-8 7-4 3-0

ADC #7 #6 #5 #4 #3 #2 #1 #0

We propose the following definition of bits:

Bit 3 Bit 2 Bit 1 Bit 0

(not used) Calibration error: Conversion error: Reset error:
- error during calibra- - timeout waiting for - reset bit not set
tion procedure conversion-ready and/or
- error in default register
contents

In case digital inputs are present objects 1800H Possible extensions to the device profile part of
(1st transmit PDO communication parameters) and the OD could be made –for example– in connection
1A00H (1st transmit PDO mapping) should be with analogue input limit and interrupt settings, for
added to the communication part of the Object Dic- which the DSP-401 device profile provides several
tionary. OD-entries. When these capabilities are present the
In case digital outputs are present objects 1400H node can monitor inputs and only send a message
(1st receive PDO communication parameters) and e.g. when certain limits are exceeded or when an
1600H (1st receive PDO mapping) should be added input changes more rapidly then a certain set limit.
to the communication part of the Object Dictionary;
all according to DSP-401.

Standardised Device Profile Area

Index Sub Name Data/ Attr Default Comment
(hex) Index Object (hex)

6404 Read analogue input Record

Manufacturer-specific
0 Number of entries U8 RO Variable, depending on hardware
Configuration
1 Input 1 I24 RO 1st analog input (24-bit)
2 Input 2 I24 RO 2nd " " "
… … … … …
192 Input 192 I24 RO 192th " " "
252 Multiplexor number U8 RO 1 Defines which mux in the OD is
used; but in this profile we won't
define the mux itself (DSP-404)
253 Input via multiplexor I24 RO Read input #<mux1> (DSP-404)
Table 9. Standardised Device Profile Area of the CANopen Object Dictionary for a device with CS5525
ADCs (providing 192 input channels, sufficient for six 32-channel ADCs).

20
CANopen 15-Nov-2005

Manufacturer-specific Profile Area

Index Sub Name Data/ Attr Default Comment
(hex) Index Object (hex)

2A00 ADC-configuration 1 Record

ADC#0
0 Number of entries U8 RO 7
1 Number of input channels U8 RW In the range [0,32]
2 Conversion Word Rate U8 RW 0 3-bit code 2
3 Input Voltage Range U8 RW 0 3-bit code 3
4 Unipolar/Bipolar U8 RW 0 0 = bipolar, 1 = unipolar
Measurement Mode
5 Power Save Mode U8 RW 0 1 = power save
6 Offset Register U32 RW CS5525 Offset Register
7 Gain Register U32 RW CS5525 Gain Register
2A01 ADC-configuration Record
ADC#1
… … …
2A07 ADC-configuration Record Max. 8 ADCs can be connected
ADC#7 to CRYSTAL-CAN / SPICAN

2B00 ADC-calibration- Record

configuration ADC#0
0 Number of entries U8 RO 7
1 Conversion word rate dur- U8 RO 0 3-bit code 2
ing calibration (always set to 15.02 Hz)
2 Offset calibration type U8 RW 3-bit code 4
3 Offset calib input channel U8 RW In the range [0,31]
4 Gain calibration type U8 RW 3-bit code 4
5 Gain calib input channel U8 RW In the range [0,31]
6 Offset value U32 RO 24-bits significant
7 Gain value U32 RO 24-bits significant
2B01 ADC-calibration- Record
configuration ADC#1
… … …
2B07 ADC-calibration- Record Max. 8 ADCs can be connected
configuration ADC#7 to CRYSTAL-CAN / SPICAN

2C00 - ADC-reset-and-calibrate 1 U8 WO n Reset ADC#n (0<=n<=7) and

perform a calibration sequence

2D00 - ADC-reset 1 U8 WO n Reset ADC#n (0<=n<=7)

Table 10. Manufacturer-specific Profile Area of the CANopen Object Dictionary for a device with CS5525-
ADCs.

1
write access allowed only when ADC-input scanning not active (PDO inhibit time = 0)
2
000: 15.02 Hz, 001: 30.06 Hz, 010: 60.01 Hz, 011: 123.18 Hz,
100: 168.9 Hz, 101: 202.27 Hz, 110: 3.76 Hz, 111: 7.51 Hz
3
000: 100 mV, 001: 55 mV, 010: 25 mV, 011: 1 V, 100: 5 V
4
001: offset self-calibration, 010: gain self-calibration,
101: offset system-calibration, 110: gain system-calibration

21
CANopen 15-Nov-2005

5.5 Emergency Objects The Emergency Error Codes are defined by the
Communication Profile [2] and the DSP-401 De-
vice Profile [3]; the Error Register bits are defined
Table 11 lists the contents of the Emergency Ob-
by DSP-401 [3]. See section 3.6.6.
ject message for different types of internal device
errors. This is a preliminary list of the error mes-
sages defined and implemented sofar.

Error Emergency Error Register

Manufacturer-specific Error Field
Description Error Code (Object 1001H) (byte 3-7)
(byte 0-1) (byte 2)

Watchdog reset 0x6000 0x01 Byte 3,4,5,6: Manufacturer Device Name

(Object Dictionary index 0x1008)
Byte 7: 0

CAN-controller 0x8100 0x10 Byte 3: 1

overrun: Byte 4: counter (modulo 256)
message lost Byte 5: CANSTA (CAN-controller status register)
Byte 6,7: 0
CAN-controller 0x8100 0x10 Byte 3: 2
error: Byte 4: counter (modulo 256)
communication Byte 5: CANSTA (CAN-controller status register)
error Byte 6,7: 0
Local CAN 0x8100 0x10 Byte 3: 3
message buffer Byte 4: counter (modulo 256)
overflow: Byte 5: CANSTA (CAN-controller status register)
message lost Byte 6,7: 0

ADC: 0xFF00 0x80 Byte 3: 1

conversion Byte 4: ADC number (0..7)
timeout Byte 5,6,7: 0
ADC: 0xFF00 0x80 Byte 3: 2
reset failed Byte 4: ADC number (0..7)
Byte 5,6,7: 0
ADC: 0xFF00 0x80 Byte 3: 3
offset calibra- Byte 4: ADC number (0..7)
tion failed Byte 5,6,7: 0
ADC: 0xFF00 0x80 Byte 3: 4
gain calibration Byte 4: ADC number (0..7)
failed Byte 5,6,7: 0

Table 11. Emergency Objects for a CS5525-ADC CANopen device.

22
CANopen 15-Nov-2005

References

[1] CAN-in-Automation,
CAL, CAN Application Layer for Industrial Applications,
CiA Draft Standard DS-201 to DS-207, Version 1.1, Feb 1996.

[2] CAN-in-Automation,
CANopen, CAL-based Communication Profile for Industrial Systems,
CiA DS-301, Version 4.0, June 16 1999.

[3] CAN-in-Automation,
CANopen Device Profile for I/O Modules,
CiA DSP-401, Version 1.4, Dec 1996.

[4] CAN-in-Automation,
CANopen Device Profile for Measuring Devices and Closed-Loop Controllers,
CiA DSP-404, Revision 1.11, Nov 27 1997.

[5] CAN-in-Automation,
Framework for Programmable CANopen Devices,
CiA DSP-302, Version 2.0, Nov 27 1998.

[6] CS5525/CS5526 16-bit / 20-bit multi-range ADC with 4-bit latch,

data sheet, Crystal Semiconductor Corporation, Sep 1996.

[7] H.Boterenbrood,
Crystal-CAN, a CAN-bus node for monitoring multiple distributed analog signals
(prototypes for B-field and Temperature monitoring in ATLAS),
Version 1.4, NIKHEF internal documentation, Oct 24 1997

[8] H.Boterenbrood,
SPICAN CANopen I/O-system (for analog inputs), user documentation,
Version 2.1, NIKHEF internal documentation, Jan 14 2000

23