Welcome to Ars-Informatica
Recent projects and articles:
Service Data Objects (SDO)
Each CANOPEN node not only implements its own Object Dictionary,
it also implements a server that handles read and write requests to its Object Dictionary.
An SDO establishes a peer-to-peer communication channel between two devices.
In addition, the SDO protocol enables to transfer any amount of data in a segmented way.
Therefore the SDO protocol is mainly used in order to communicate configuration data.
An SDO connection between two devices is established by configuring the related SDO server resp. client channel.
CANOPEN uses unique message identifiers – one message ID is only used for one purpose in an entire CANOPEN network.
A CANOPEN device may support up to 128 SDO server channels and up to 128 SDO client channels.
Each supported SDO channel may be configured by writing the valid communication object identifiers (COB-IDs)
to the related SDO parameter set. The SDO parameters cover two mandatory COB-IDs (server-to-client and client-to-server).
Beside further functionality, these COB-ID entries indicate the CAN-Identifiers, which are used for the request
respectively response direction. For the client channel the SDO parameter set also provides the node-ID of the related server.
As a further example consider the following network
The figure shows the message identifiers that are used by default.
The message identifier that is used to send a request to a specific node is calculated
by adding the Node ID of that node (1-127) to a base address of 600h.
Thus addresses 601h to 67Fh are used to provide 127 channels from one client to up to 127 servers.
The message identifier that is used to send a response from each node back to the client who sent
the request is calculated by adding the Node ID of the node (1-127) to a base address of 580h.
Thus addresses 581h to 5FFh are used to provide 127 channels from as many as 127 servers back to the client.
The default scheme used for assigning the message identifiers only allows one client to be on the network:
no two devices have the right to send SDO requests to the same node at the same time.
This is a design issue based on the fact that only one node (a configuration tool or some sort of
master responsible for configuration) in the system needs the power
to access each and every Object Dictionary entry in each and every node.
SDO message contents
There are 3 mechanisms for SDO transfer:
- Expedited transfer: used for data objects up to 4 bytes in length;
- Segmented transfer: for objects with length greater than 4 bytes.
- Block transfer (optional): optimized method to transfer large data amounts.
The basic structure of an SDO is:
- ccs is the client command specifier of the SDO transfer, this is 0 for SDO segment download, 1 for initiating download, 2 for initiating upload,
3 for SDO segment upload and 4 for aborting an SDO transfer
- n is the number of bytes in the data part of the message which do not contain data, only valid if e and s are set
- e, if set, indicates an expedited transfer , i.e. all data exchanged are contained within the message.
If this bit is cleared then the message is a segmented transfer where the data does not fit into one message and multiple messages are used.
- s, if set, indicates that the data size is specified in n (if e is set) or in the data part of the message
- index is the object directory index of the data to be accessed
- subindex is the subindex of the object directory variable
- data contains the data to be uploaded in the case of an expedited transfer (e is set), or the size of the data to be uploaded (s is set, e is not set)
All numerical data types consisting of multiple bytes are transferred in CANOPEN in the "Little Endian" format (the lower significant bytes come first).
Examples of SDO communication can be found here:
SDO usage limitations
The communication channels offered by SDOs allow a master or configuration tool to get access to all the Object Dictionary entries in a node, even process data.
However, this is not an efficient communication model for sending process data since it requires polling.
If the exchanged data is between two nodes it is far more overhead.
CANOPEN is primarily intended to run on CAN and one of the characteristics of CAN bus is that each nodes may transmit their data whenever
they want to (and not be required to wait for another node to poll them).
CANOPEN Process Data Objects (PDOs) achieve this goal.
CANopen is a communication protocol and device profile specification for embedded systems used in automation.