|
|
About CANopen |
Device Configuration via SDOs |
Specific communication objects, so-called "service data objects" (SDOs) are used for direct access to CANopen devices. With these "service data objects", object dictionary entries can be read and written, where communication always takes place as a logical 1:1 connection (peer-to-peer) between two nodes (e.g. a configuring node and a node to be configured) . As the data transfer is carried out via such a connection as an acknowledged service, this means that two CAN messages per connection are required: 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") of the node. The two network nodes involved are referred to as
SDO client and/or SDO server; here the server id the one that provides or accepts the data via its object dictionary and the client is the one that requests (reads) or transfers (writes) the data. There is a logical connection between the two partners, which is also referred to as an "SDO channel". The initiative for an SDO transfer always originates from the client. As an SDO transfer is acknowledged, every request must be answered, even if the device is not able to provide meaningful data or the request itself was already erroneous. Such a negative response is called "abort". In such a response, in addition to the 4-byte long error code (abort code), which specifies the cause of the abort, the address of the object dictionary entry to which the unsuccessful SDO transfer referred, is also transmitted. As already mentioned, an SDO transfer always runs as a request-response sequence according to a separate protocol, which is specified in the first data byte of the service data object. Therefore the message identifier specifies the SDO itself and the first data byte of the SDO specifies the specific protocol. For this reason the first data byte is also referred to as the protocol or command byte. An SDO-message is always eight bytes long, bits of the data field that are not required must be set to 0.
Data fields of any length or byte sequences can be transmitted with an object dictionary access. For this reason, the length of the information that can be transmitted via the SDO protocol is theoretically unlimited. The SDO protocol runs in two phases: In the initialization phase an object dictionary entry is addressed and the length of the data to be transferred is indicated. In the second phase the utility data are then transmitted in segments (each of seven bytes).
Accordingly, DS-301 distinguishes between four different SDO services: Initiate SDO Upload, Upload SDO Segment, Initiate SDO Download and Download SDO Segment.
As very often only a few utility data bytes are to be transmitted, the SDO transfer can be shortened and up to a maximum of four bytes transmitted already in the initialization phase. This is referred to as an "expedited SDO transfer".
The message for the Initiate SDO Download service, with which a write access to an object dictionary entry of a CANopen node occurs at the same time, is structured as follows:
| Command byte |
OD main-index |
OD sub-index |
Data (max. 4 bytes) |
|
The SDO server responds with protocol byte 0x60:
| Command byte 0x60 |
OD main-index |
OD sub-index |
Empty (4 byte) |
|
In the bit-coded command byte the service is coded with three bits (command specifier). Another bit specifies whether an expedited or a non-expedited transfer is to be carried out. A further bit indicates whether the size of the data to be transmitted is specified in the last four bytes of the communication object; however, this bit is only used for non-expedited transfers.
With an expedited transfer, on the other hand, the user data are transmitted directly within these last four bytes. Two further bits of the protocol byte specify how many of these bytes are actually assigned (transmission of only one byte of user data is also possible). The user data must therefore be positioned left-justified in the data field of the SDO object.
Generally it is to be noted that in CANopen data are transmitted according to the "Little Endian" rule and therefore according to the form for corresponding INTEL processors. This means that the low value byte is transmitted first. This makes it slightly more difficult for a human to follow a monitored SDO protocol sequence but in the end this is a matter of habituation. Counting up the bits of the protocol byte described so far, there are seven bits. The eighth bit is reserved.
An SDO download to the OD entry [1017], with which the heartbeat interval of a heartbeat producer is to be set to 4 seconds (in ms as an UNSIGNED16 value, i.e. 0x0F A0), therefore appears as follows:
The node (SDO server) then acknowledges successful completion with the message
With the Initiate SDO Upload service, with which an object dictionary entry of a CANopen node is read out, the same division of the data field is valid, only here request and response telegrams are reversed to a certain extent. Here is the command byte of the client request 0x40:
| Command byte (0x40) |
OD Main Index |
OD Sub Index |
Empty (4 bytes) |
|
The SDO server responds with:
| Command byte |
OD Main Index |
OD Sub Index |
Data (4 bytes) |
|
The SDO server must always respond to the typical request to read out the device manufacturer (vendor ID; found under subindex 1 of the identity object [1018]), as this OD-entry is mandatory. In the case at hand, the device is of course from IXXAT (vendor no.: 00 00 00 04). The SDO response message is therefore as follows:
If no "expedited transfer" is used, the four data bytes of the Initiate SDO services can be used to specify the length (in bytes) of the user data to be transmitted. The actual transmission then occurs with the Download SDO Segment or Upload SDO Segment service. 7 bytes of user data per segment can be transmitted. The command byte of these services contains the three bits of the service-ID (command specifier), one toggle bit and four unused bits, except for the last segment. In order to also safely transfer user data that are not multiples of the segment size seven, the number of unused bytes (a value between 6 and 0) is coded in three bits of the last SDO segment. Finally, the command bytes LSB marks the end of data transmission. The segment order is monitored by the toggle bit, where both SDO request and SDO response messages are toggled. The commented sequence of a non-expedited segmented SDO upload is illustrated in the following:
40 08 10 00 00 00 00 00 // Initiate req: Read Device Name [1008]
41 08 10 00 1A 00 00 00 // Initiate resp: Fine. It's 26 bytes long
60 00 00 00 00 00 00 00 // Upload segment req, Toggle = 0
00 54 69 6E 79 20 4E 6F // Upload segment resp, Toggle = 0
70 00 00 00 00 00 00 00 // Upload segment req, Toggle = 1
10 64 65 20 2D 20 4D 65 // Upload segment resp, Toggle = 1
60 00 00 00 00 00 00 00 // Upload segment req, Toggle = 0
00 67 61 20 44 6F 6D 61 // Upload segment resp, Toggle = 0
70 00 00 00 00 00 00 00 // Upload segment req, Toggle = 1
15 69 6E 73 20 21 00 00 // Last segment, 2 bytes free, Toggle = 1
With version 4 of the CANopen specification DS-301, a new, considerably more effective but also more complicated SDO mode has been introduced, the so-called SDO block transfer. In contrast to the segment transfer described above, here the segments are no longer acknowledged individually, but are put together in blocks, which are each transferred in one go. The partner then only acknowledges the block. From a user data size of 29 bytes on, the block transfer is better in terms of the protocol overhead. With block transfer, the protocol byte numbers the individual segments of each block, so that a maximum of 127 segments per block are possible. The transmission is boxed in by an initialization phase, in which the block sizes and utility data size of both partners are made consistent with each other, and by a termination phase, in which the CRC check sum over the entire transfer, provided that the communication partners agreet on it during initialisation, is committed. However, SDO block transfer is currently only supported by a few devices.
The SDO read access to object dictionary entry [1008], device name, as a block transfer looks like this:
A4 08 10 00 21 00 00 00 // Initiate req: Read [1008], Blocksize 33, CRC supported
C2 08 10 00 1A 00 00 00 // Initiate resp: It's 26 bytes long, no CRC
A3 00 00 00 00 00 00 00 // Initiate block req: Let's go
01 54 69 6E 79 20 4E 6F // Upload block resp, 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 resp, Segment = 3
84 69 6E 73 20 21 00 00 // Last segment, Segment = 4
A2 04 21 00 00 00 00 00 // Upload block req: 4 segments received, Blocksize 33
C9 00 00 00 00 00 00 00 // End resp: 2 bytes free
A1 00 00 00 00 00 00 00 // End req: Thank you
An important SDO service is the "Abort SDO Transfer" (command byte: 0x80). It consists of exactly one CAN message, which can be transmitted at any time by either of the two partners instead of the regular SDO protocol message and leads to immediate termination of the SDO transmission. The most common situation is the SDO-Abort as a response to an Initiate SDO request if the addressed object dictionary entry does not exist. The structure of the Abort SDO message is:
| 0x80 |
OD main-index |
OD sub-index |
Abort code |
|
The data field of this SDO service contains the cause of the error (abort code) as a dword. The CANopen specification lists all defined abort codes. There are approx. 30 in total. The use of own abort codes or non-defined codes is not permitted. The most important abort codes are:
0x05030000 Toggle bit not alternated
0x05040001 Invalid SDO Command specifier
0x0601000x Unsupported access to an object
0x06010002 Attempt to write a read only object
0x06020000 Object does not exist in the object dictionary
0x0607001x Data type does not match
0x06090011 Subindex does not exist
0x08000000 General error
Every device must support at least one server SDO channel. Further SDO channels can be set up via object dictionary entries. The OD entries [1201] to [127F] with the pre-defined record SDO parameter are reserved for the definition of server SDO channels.
|
 | |
|