This button brings you to the IXXAT WebpageThis is where you are at the moment IXXAT - Products, Services and Training for CAN, CANopen, DeviceNet, CAL, FlexRay, LIN, Embedded TCP/IP
Introduction &
Network Structure
Device Configuration (SDO)
Process Data Exchange (PDO)
Management (NMT)
Guarding & Heartbeat
Connection Set
Layer Setting
Services (LSS)
Device and
Application Profiles
of CANopen
Protocol Stacks
Tools / Interfaces
Seminars / Training
Contact / Imprint



Bridges & GW
PC Interfaces
Protocol Software
PLC Expansion
CANopen Solutions - Basics, Profiles, Protocol Stacks, Tools, Articles ...

CANopen Basics - Predefined Connection Set

Predefined use of message identifiers
(Predefined Connection Set) for simple system structures

In order to reduce the amount of configuration required with simple network structures (1: n communication relationships between a control device and several lower order devices), CANopen supports a predefined allocation of message identifiers (Predefined Connection Set). This set of predefined identifiers supports one emergency message per node, synchronization and time stamp messages, one SDO-connection per device, the NMT-messages for node control and node monitoring and up to 4 transmit and 4 receive PDOs per device.
In a CANopen network it is possible to differentiate between a maximum of 127 nodes. These nodes share the 11-bit identifier space.
First a differentiation is made between network- and device-related functions. One CAN identifier is reserved for each of the network-related functions (e.g. NMT node control), one identifier per device is required for each device-related functionality (e.g. emergency messages, PDOs), since it must be possible to differentiate between the same functions on different devices. More important functions are assigned a higher priority COB-ID. For future extensions and for historical reasons, some message identifiers are not assigned. It is thus possible to operate systems with a higher order control node and up to 127 slave nodes without reconfiguration.
The following diagram shows the resulting partitioning of the CAN identifier space:
NMT  000h
Sync  080h
TimeStamp  100h

The following table shows the identifier allocation of the Predefined Connection Set:
COB-ID(s) hexSlave nodes
NMT node control000Receive only
Sync080Receive only
Emergency080 + NodeIDTransmit
TimeStamp100Receive only
PDO180 + NodeID
200 + NodeID
280 + NodeID
300 + NodeID
380 + NodeID
400 + NodeID
480 + NodeID
500 + NodeID
1. Transmit PDO
1. Receive PDO
2. Transmit PDO
2. Receive PDO
3. Transmit PDO
3. Receive PDO
4. Transmit PDO
4. Receive PDO
SDO580 + NodeID
600 + NodeID
NMT node monitoring (node guarding/heartbeat)700 + NodeIDTransmit

SDOs and PDOs are always used in pairs (i.e. to transmit and to receive), where the rule is that the node on the lower (and therefore higher priority) COB-ID transmits and on the higher (i.e. lower priority) COB-ID receives.
With the Predefined Connection Set it is possible to operate systems with a higher order control node and up to 127 slave nodes without reconfiguration. Here the higher order control node, e.g. for the transmission of process data to the node with the node-ID 5 can use PDOs with the COB-IDs 0x205, 0x305, 0x405 and 0x505; it receives process data from this node via PDOs with the COB-Ids 0x185, 0x285, 0x385 and 0x485. A control node can therefore exchange up to 32 bytes of process input and 32 bytes of process output data with a slave node by default. In our example, the control node can access the object dictionary of node no. 5 with a SDO request with the COB-ID 0x605 and receives the corresponding SDO response under COB-ID 0x585.
For more complex network structures, e.g. a structure with n: m communication relationships or if the predefined number of PDOs per device is not sufficient, the predefined identifier allocation must be altered by reconfiguring the identifier allocation (PDO parameter). For this, the use of a configuration tool is recommended.