CANopen Device Configuration via SDOs

Service Data Objects (SDOs)

Specific communication objects, known as ‘Service Data Objects’ (SDOs) are used for direct access to CANopen devices. These “Service Data Objects” enable Object Directory entries to be read and written, with communication always taking place as a one-to-one (peer-to-peer) connection between two nodes (for example, a configuration node and a node being configured). Data transfer takes place with acknowledgement of receipt, which means that two CAN messages are required per connection: one message for the request to the network node (SDO request or “Client SDO”) and a second for the response (SDO response or “Server SDO”) from the node.

CANopen Client SDO request followed by a Server SDO response

The two network nodes involved are referred to as SDO client and/or SDO server. In this context, the server ID is the one that provides or accepts data via the Object Directory, whilst the client is the one that requests (reads) or provides (writes) data. There is a logical connection between the two nodes, which is also referred to as an “SDO Channel”. The initiative for an SDO transfer always comes from the client. Every SDO transfer is acknowledged with a confirmation of receipt, even if the device is unable to provide meaningful data in response, or if the original transfer was faulty. Such a negative response is called “Abort” (aborted). In such a response, in addition to the 4-byte error code (“Abort Code”), the address of the Object Director to which the failed SDO transfer referred is also sent.
As already mentioned, an SDO transfer always takes the form of a request/response sequence in accordance with a separate protocol, which is specified in the first data byte of the Service Data Object. To this end, the message ID (CAN-ID) identifies the SDO itself, and the first data byte of this SDO specifies the particular protocol. For this reason, this first data byte in an SDO is also referred to as the protocol or command byte.
An SDO message always contains eight data bytes; any bits within these bytes that are not required must be set to 0. It is possible to send data fields of any length, or consecutive byte sequences, to an Object Directory item. Consequently, the amount of information that can be sent via the SDO protocol is, in theory, unlimited. The SDO protocol is carried out in two phases: in the initialisation phase, an Object Directory item is addressed and the length of the data to be transferred is reported. In the second phase, the actual information is sent in segments (each seven bytes in size). Accordingly, DS-301 distinguishes between four different SDO services: Initiate SDO upload (=Start), Upload SDO Segment, Initiate SDO Download (=Start) and Download SDO Segment.

Accelerated SDO transfer

As often only a few bytes of data need to be transmitted, the SDO transfer can be shortened and up to four bytes of data can already be sent during the initialisation phase. This is referred to as an “Expedited SDO Transfer " (=expedited SDO transfer). The message “Initiate SDO Download” to start the download – which simultaneously grants write access to an Object Directory item of a CANopen node – has the following format:

The SDO server responds with command byte 0x60:

In the bit-encoded command byte, the SDO service is encoded using three bits (Command Specifier). Another bit indicates whether an expedited or non-expedited transfer (Expedited SDO Transfer) is to be carried out. A subsequent bit indicates whether the size of the information to be exchanged is specified in the last four bytes of this object; however, this bit is only used for non-expedited transfers. In the case of an expedited transfer, the actual information is sent directly in the last four bytes. Two other bits of the command byte indicate how many of these bytes are actually used. This means that the transfer of just a single data byte is also possible.
The data bytes must be placed left-aligned within the data field of the SDO object. In general, it should be noted that in CANopen, data is transmitted according to the ‘Little Endian’ rule, also known as the Intel format. This means that data consisting of multiple data bytes is transmitted with the least significant byte (LSB) first and the most significant byte (MSB) last. This makes it slightly more difficult for a human to follow a monitored SDO stream, as we read from high (MSB) to low (LSB), but ultimately this is simply a matter of getting used to it.
The first 7 bits of the command byte have been discussed above; the eighth bit is reserved. As an example, an SDO download to the Object Directory item [1017], which is used to configure the heartbeat interval of a heartbeat generator, must be set to 4 seconds. This value is expressed in ms, i.e. 0x0FA0 (400). This CANopen message looks as follows:

The destination node (SDO server) confirms successful completion with the message:

When starting an ‘SDO Upload service’, which allows an Object Directory item to be read, the same message format applies. However, in this case, the data flow (and data fields) is, of course, reversed to a certain extent. Here, the command byte of the client request is 0x40:

The SDO server responds with:

For example, the SDO server must always respond to a request to read the device’s unique manufacturer ID (Vendor ID; sub-index 1 of object [1018]), as this OD entry is mandatory. In this example, the device from manufacturer IXXAT (Vendor-ID = 00 00 00 04) reports the following Vendor-ID:

Standard transfer

If no ‘accelerated SDO transfer’ is used, the four data bytes of the ‘Initiate SDO’ message can be used to specify the length (in bytes) of the actual data. The actual transfer then takes place using the “Download SDO Segment” or “Upload SDO Segment” messages. Such messages consist of a command message, and 7 data bytes per segment can be transferred. The command byte of these services contains three bits of the service ID (command specification), a toggle bit and four unused bits, except in the final segment. As the final segment does not need to be entirely filled with data, the number of data bytes used (between 6 and 0) is encoded in three bits of the final SDO segment message. Finally, the ‘bytes LSB’ command marks the end of the data transfer.
The segment order is controlled via the toggle bit, which is switched for each SDO request/SDO response message pair. The sequence of a non-accelerated segmented SDO upload is illustrated in the following example:

40 08 10 00 00 00 00 00   // Start request: Read Device Name [1008]
41 08 10 00 1A 00 00 00   // Start reply: Fine. It is 26 bytes long
60 00 00 00 00 00 00 00   // Upload segment request, Toggle = 0
00 54 69 6E 79 20 6F 4E   // Upload response segment, Toggle = 0
70 00 00 00 00 00 00 00   // Upload request segment, Toggle = 1
10 64 65 20 2D 20 4D 65   // Upload response segment, Toggle = 1
60 00 00 00 00 00 00 00   // Upload segment req, Switch = 0
00 67 61 20 44 6F 6D 61   // Upload segment resp, Switch = 0
70 00 00 00 00 00 00 00   // Upload request segment, Toggle = 1
15 69 6E 73 20 21 00 00   // Final segment, 2 bytes available, Toggle = 1

Version 4 of the CANopen DS-301 specification introduced a new, considerably more effective but also more complex SDO mode, known as SDO Block Transfer. Unlike the segment transfer described above, an acknowledgement is no longer sent for each segment; instead, these are grouped into blocks that are transmitted in a single batch. The receiving end then sends only one acknowledgement for the entire block. If the actual data size exceeds 29 bytes, this Block Transfer is more efficient in terms of protocol overhead.
In Block Transfer, the command byte numbers the individual segments of each block, so that a single block can contain up to 127 segments. The transmission consists of an initialisation phase, during which the block size and the number of information bytes are exchanged, and a final phase, in which a checksum (CRC) is calculated for the entire transfer, if this was agreed during initialisation. As not all devices comply with DS-301 v4, it is advisable to check whether Block Transfer is supported. An SDO read access to Object Directory item [1008], retrieving the so-called device name, looks as follows in Block Transfer:

A4 08 10 00 21 00 00 00   // Start request: Read [1008], block size 33, CRC supported
C2 08 10 00 1A 00 00 00   // Start reply: It is 26 bytes long, no CRC
A3 00 00 00 00 00 00 00   // Start block request: Let’s go
01 54 69 6E 79 20 6F 4E   // Upload block response, Segment = 1
02 64 65 20 2D 20 4D 65   // Upload block resp, Segment = 2
03 67 61 20 44 6F 6D 61   // Upload block, Segment = 3
84 69 6E 73 20 21 00 00   // Last segment, Segment = 4
A2 04 21 00 00 00 00 00   // Upload block request: 4 segments received, block size 33
C9 00 00 00 00 00 00 00   // End of response: 2 bytes available
A1 00 00 00 00 00 00 00   // End of request: Thank you

Abort

An important SDO service is the ‘Abort SDO Transfer’ (command 0x80). It consists of exactly one CAN message and can be sent at any time by either partner. This takes place in place of a normal SDO protocol message and results in the immediate termination of the SDO transmission. The most common situation is the SDO Abort as a response to a rejected SDO request if the addressed Object Directory item does not exist. The structure of the Abort SDO message is:

The data field of this SDO contains the cause of the error (Abort code). The CANopen specification contains a list of all defined Abort codes. There are approximately 30 in total. The use of custom Abort Codes or undefined codes is not permitted. The most important codes are:

SDO channels

Each device must support at least one server SDO channel. Additional SDO channels can be configured via the Object Directory. The OD entries [1201] to [127F] with the predefined SDO file parameters are reserved for the definition of the server SDO channels.