USDO services

CiA 1301 specifies several USDO services. The main purpose of all these services is to read from and to write data to the CANopen FD object dictionary. The USDO client has always the initiative sending an USDO read or write request. In opposite to the SDO communication in classic CANopen, the USDO client provides in its protocol the destination information. Therefore, the USDO protocols supports broadcast, multicast, and unicast addressing. This means that all CANopen FD nodes can communicate via USDO with each other CANopen FD node. USDO services are intended for configuration and diagnostic tasks. Of course, process data can be transferred, as well.

CANopen FD distinguishes between USDO local services and USDO remote services. The USDO local services are used to communicate in the very same network segment. This is indicated in the USDO protocol by means of the network-ID. The USDO remote services are intended for communication with CANopen FD devices in another segment with another network-ID.

USDO services are always confirmed. Read requests are confirmed by the USDO data received from the USDO server. Write requests are confirmed by means of USDO server segments indicating that the data is stored in the CANopen FD object dictionary. The USDO client needs to support an internal USDO client response timeout. The USDO client response timeout indicates the duration, in which the USDO client expects all responses to his request. The USDO client does not consider responses that are received after elapsing of the timeout-time.

There are specified USDO expedited and segmented services. The expedited ones are mapped to just one packet, because the payload can carry all application data. The USDO segmented services are mapped to multiple USDO protocol packets. They are used to up- or download large amounts of data. Each packet is confirmed, which eats some bandwidth. Therefore, CANopen FD specifies also so-called USDO bulk services. In these services not every packet is confirmed, but a group of packets.

In case that the USDO service cannot be handled correctly, either the USDO server or the USDO client sends an USDO abort message. The USDO abort message provides a 4-byte abort codes giving the user information about the reason.

USDO services provide a pre-configured broad-, multi-, and unicast communication, which unburden the system designer from assigning CAN-IDs. This means, it is possible to run a network application only using USDO services. Of course, Heartbeat services and EMCY services are needed, too.

The current USDO service specification allows multiple SDO sessions. Therefore, the USDO protocol contains a session-ID. New is also the data type indication.

In the next edition of CiA 1301, it is planned to support transmitting multiple object dictionary entries by means of one single USDO service. This could be used, for example, for PDO mapping or communication parameters or any other selection of multiple object dictionary entries.

USDO protocol examples

USDO messages have a protocol overhead of different length depending on the related USDO service. This overhead contains, for example, the kind of service (command specifier) and the 24-bit address of the object dictionary parameter to be written or to be read (index and sub-index). The protocol details are specified in CiA 1301. The shown table provides the command specifiers of the defined USDO protocols for local and remote network accesses.

Code (local) Code (remote) Protocol name
01h 81h Download expedited request
02h 82h Download segmented initial request
03h 83h Download segmented intermediate request (segment)
04h 84h Download segmented last request (end)
05h 85h Reserved for future use by CiA
06h 86h Download bulk transfer initial request
07h 87h Download bulk transfer segmented
08h 88h Download bulk transfer final
09h to 10h 89h to 90h Reserved for future use by CiA
11h 91h Upload request
12h 92h Reserved for future use by CiA
13h 93h Upload segmented intermediate request (segment)
14h to 20h 94h to A0h Reserved for future use by CiA
21h A1h Download expedited response
22h A2h Download segmented initial response
23h A3h Download segmented intermediate response (segment)
24h A4h Download segmented last response (end)
25h A5h Reserved for future use by CiA
26h A6h Download bulk transfer initial response
27h A7h Reserved for compatibility reasons
28h A8h Download bulk transfer final response
29h to 30h A9h to B0h Reserved for future use by CiA
31h B1h Upload expedited response
32h B2h Upload segmented initial response
33h B3h Upload segmented intermediate response (segment)
34h B4h Upload segmented last response (end)
35h to 7Eh B5h to FEh Reserved for future use by CiA
7Fh FFh USDO abort service

USDO command specifiers

In general, there are protocols for not segmented USDO messages. Those do not need more than the 64-byte payload provided by the CAN FD data link layer. If the USDO service needs more payload, the CANopen FD protocol stack segments the data to be transmitted and the CANopen FD protocol stack of the receiving nodes re-assemble them.

Figure 1 shows a not segmented local unicast USDO protocol sequence:

USDO upload expedited unicast protocol sequence

Figure 1:USDO upload expedited unicast protocol sequence

Figure 2 provides the USDO local download bulk transfer broadcast protocol sequence:

 USDO local download bulk transfer broadcast protocol sequence

Figure 2: USDO local download bulk transfer broadcast protocol sequence