SICK DL100 Pro CANopen - Communication Objects; Cob-ID

PDO
SDO
Guarding
Emergency
LSS
TimeStamp
Sync
NMT
000h
280h
180h
100h
200h
380h
300h
080h
400h
480h
500h
580h
600h
680h
700h
780h
7FFh
Figure 25: CAN ID and priorities
10.3.8 Communication objects
With CANopen, the entire data transport is handled via communication objects (COBs).
There are different communication objects like for process data (PDO), service data
(SDO), network management (NMT), synchronization (Sync), error (EMCY) etc. Within
these objects, the COB ID is used as identifier.
10.3.9 COB-ID
The COB ID (Communication Object Identifier) is composed of the CAN ID and addi‐
tional control bits. The COB ID defines under which CAN ID a communication object is
transmitted. The meaning of the control bits depends on the respective communication
object. For a process data object (PDO), for example, this can be used to determine
whether it exists at all. The COB ID is stored as an object in the object directory.
The term COB ID is often also used for the individual CAN identifier of the COB. It
determines the priority of processing a communication object.
The following table shows an example of the COB ID of a process data object (PDO).
Table 31: Structure of the TPDO COB ID
MSB LSB
31 30 29 28 11 10 0
Valid RTR Frame 00000h 11-bit CAN ID
29-bit CAN ID
MSB LSB
Table 32: Description of the individual bits within the COB ID
Bits Value Description
Valid Whether PDO exists/valid
1b PDO does not exist/is not valid
RTR 0b RTR allowed in this PDO
1b No RTR allowed in this PDO
CANOPEN INTERFACE 10
8015418/19HA/2022-12-15 | SICK O P E R A T I N G I N S T R U C T I O N S | DL100 Pro CANopen
57
Subject to change without notice