Multiple CANOpen SDO requests "in the air" at once

Question

In CANOpen, expedited SDO requests and responses include the index and sub-index of the request. All CANOpen master implementations that I've looked at require only one SDO per device be sent at once, for example:

Client: Initiate Upload Request, index = 0x1000, subindex = 0x00
=== Client waits
Server: Initiate Upload Response, index = 0x1000, subindex = 0x00, 4 bytes, data=XXX

Client: Initiate Upload Request, index = 0x1001, subindex = 0x00
=== Client waits
Server: Initiate Upload Response, index = 0x1001, subindex = 0x00, 4 bytes, data=XXX

It's theoretically possible for multiple SDOs to be sent before the response to the first SDO is received as long as an expedited transfer is used, for example:

Client: Initiate Upload Request, index = 0x1000, subindex = 0x00
Client: Initiate Upload Request, index = 0x1001, subindex = 0x00
=== Client waits
Server: Initiate Upload Response, index = 0x1001, subindex = 0x00, 4 bytes, data=XXXX
Server: Initiate Upload Response, index = 0x1001, subindex = 0x00, 4 bytes, data=XXXX

Is this behavior allowed under the standard or must only one SDO request be "in the air" at once? Can I count on this behavior from devices acting as an SDO server?

Answer 1

In practice, it seems like it would be possible. If allowed in a conforming CANopen implementation, well that's another story.

CANopen specifies several types of allowed communication models (CiA 301 4.4) and SDO uses the Client/Server model (CiA 301 4.4.3):

4.4.3 Client/server protocol
This is a communication protocol used between a single client and a single server. A client issues a request (upload/download) thus triggering the server to perform a certain task. After finishing the task the server answers the request. Figure 8 defines the client/server communication protocol.

This is a "ping pong" model - every request has to be replied to. For example 7.2.4.3.2 (SDO downloads) mentions:

... The sequence is terminated by:

An SDO download initiate request/indication with the e-bit set to 1 followed by an SDO download initiate response/confirm, indicating the successful completion of an expedited download sequence. /--/
If in the download of two consecutive segments the toggle bit does not alter, the content of the last segment shall be ignored. If such an error is reported to the application, the application may decide to abort the download.

My take on this is that every download/upload request has to replied on by a handshake, which is done by setting the relevant bit flag as mentioned in the quote above, "e-bit" in case of expedited transfer. I don't find anything in the document that explicitly states what will happen if two requests (to the same node) are started at once, but given the above I'd say that doing so is non-conforming.

If you have several SDO objects available for the same node, then that might be another story. If you want a more authoritative answer than this, I'd contact the CAN in Automation test center: https://www.can-cia.org/services/test-center/.