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:
Figure 1:USDO upload expedited unicast protocol sequence
Figure 2 provides the USDO local download bulk transfer broadcast protocol sequence:
Figure 2: USDO local download bulk transfer broadcast protocol sequence
