BCM-MS, BCM-LS
Different CANopen protocol services are available depending on the sensor state:
Com. Object
Initializing
Pre-Operational
Operational
Stopped
PDO
X
SDO
X
X
Synch
X
X
BootUp
X
NMT
X
X
X
Tab. 21:
Available CANopen services in various sensor states
4.2.2.3 Service Data Object (SDO)
Service Data Objects enable write and read access to the sensor’s object directory. Each SDO is acknowledged and transmission
only takes place between two consumers, a so-called Client/Server model.
The sensor can only serve as server, so only responds to SDO messages and does not send requests to other consumers by itself.
The SDO messages from the sensor to the client have the ID 0x580. When requests are sent from the client to the sensor
(server), 0x600 is expected as the ID in the SDO message.
The standard protocol for SDO transfers requires 4 byte to encode the send direction, data type, the index and the subindex. This
leaves 4 byte of the 8 byte of a CAN array for the data content. For objects with data contents greater than 4 byte there are two
other protocols for so-called fragmented or segmented SDO transfer.
Message
Message
(Sensor)
(Control unit)
Fig. 11: SDO Client/Server relationship
SDOs are intended to configure the sensor by accessing the object directory, request rarely used data or configuration values or
download large data volumes. SDO properties at a glance:
– All data in the object directory can be accessed
– Confirmed transmission
– Client/Server relationship during communication
The control data and payload of a non-segmented SDO standard message are spread across the CAN message as shown in the
table below. The payload of an SDO message is up to 4 byte. The control data of an SDO message (cmd, index, subindex) is used
to determine the access direction to the object directory and if applicable the transmitted data type. For detailed specifications
of the SDO protocol, please refer to "CiA Draft Standard 301".
27
Bühler Technologies GmbH
BE150104 ◦ 03/2021
