SDO services

CiA 301 specifies several SDO services. The main purpose of all these SDO services is to read and to write data to one dedicated CANopen object dictionary address. The SDO client has always the initiative sending an SDO read or write request to the desired SDO server. Therefore, SDO services are always confirmed. Read requests are confirmed by the SDO data received from the SDO server. Write requests are confirmed by means of SDO server messages indicating that the SDO data is stored in the CANopen object dictionary.

In case that the SDO service cannot be handled correctly, either the SDO server or the SDO client may send an SDO abort message. The SDO abort message provides a 4-byte abort codes giving the user information about the reason. It is not very helpful to provide an abort code reporting just a general error. Therefore, CiA 301 specifies for some cases, which abort code needs to be used.

SDO messages have a 4-byte SDO protocol overhead containing the kind of service, the 24-bit address of the object dictionary parameter to be written or to be read. There also some bits in specific SDO protocol control bits. There is, for example, a toggle-bit indicating that the CAN data link layer has not duplicated the transmitted message transmitted.

Some SDO services allow reading or writing data with any length. Because the CAN data frames provide just an 8-byte payload (data field), the related SDO transport layer protocol segments the SDO data on the sender side and reassembling them on the receiver side. Each CAN data frame sent by the SDO client is confirmed by the SDO server by means of a CAN data frame.

There are two options to indicate the length of the data to be transferred: the size or an end indication (last segment) both provided in the SDO protocol overhead. In order to reduce the busload, there are SDO block services specified, which do not confirm each segment but a block of segments. The block size, number of segments, is configurable.

All SDO services are mapped to CAN data frames with an 8-byte length. If the SDO data is less than 4 byte, no segmentation is needed. If this length of the SDO data exceeds 4 byte, one of the appropriate SDO transport protocols is used. In the initial CAN frame, the SDO protocol overhead is four bytes. In the following CAN frames just one byte is used for protocol data. The remaining seven bytes contain SDO data. If the SDO data is not entirely used, this is indicated in the SDO protocol.

For each peer-to-peer SDO channel, client/server relation, two CAN-IDs are needed: one for the client-to-server request and the other for the server-to-client confirmation. Theoretically, all CANopen devices can communicate with all other network nodes by means of SDO services. However, this would require many CAN-IDs. A full-meshed bidirectional SDO communication for all 127 possible nodes needs more than 500 CAN-IDs.

Originally, SDO services are intended to configure or to diagnose a CANopen device. But SDO services also can be used to transmit process data. The system designer should consider that SDO services increase the busload.


SDO protocol examples

There are several SDO protocols specified in CiA 301. In the 1-byte command specifier (CS) of the SDO client, SDO server, and the SDO abort message, three bits are used to indicate the used protocol. In case of a SDO read service to the heartbeat producer time (index 101716 and sub-index 0016) the SDO client sends the following 8-byte value in the CAN data field:

Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
CS:
4316
Index:
17 1016
Sub-Index:
0016
(Parameter) data:
00 00 00 0016
LSB MSB

The SDO server responds with the following 8-byte value in its SDO server message indicating that the heartbeat producer time is 4000 ms:

Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
CS:
??16
Index:
17 1016
Sub-Index:
0016
(Parameter) data:
A0 0F 00 0016
LSB MSB

In case of a SDO write service to the same parameter configuring the heartbeat producer time to 2000 ms, the SDO client sends the following 8-byte value in the CAN data field:

Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
CS:
2B16
Index:
17 1016
Sub-Index:
0016
(Parameter) data:
D0 0F 00 0016
LSB MSB

The SDO server confirms the SDO write request with the following 8-byte value in its SDO server message:

Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
CS:
6016
Index:
17 1016
Sub-Index:
0016
(Parameter) data:
D0 0F 00 0016
LSB MSB

The SDO abort message uses always the CS value of 8016 independent of the source (SDO client or SDO server). This followed by the index and sub-index as well as the 4-byte abort code.