(Deutsch) CANopen Netzwerkmanagement – NMT

Sorry, this entry is only available in Deutsch.

Using SDO clients in CANopen Master devices

In general a CANopen Master device may have up to 127 different SDO clients that can be configured in any way to communicate with various SDO servers spread over multiple devices in the network. To establish an SDO connection between two devices 2 different CAN-IDs are used and they need to be configured at both the SDO clients and inside the SDO servers. Anyway, most SDO devices only come with 1 SDO server using the CAN-IDs according to the Pre-Defined Connection Set. In this case the configuration is only required on the SDO clients’ side. Two different ways of using SDO clients are most common.

One SDO Client used for all slaves

In this way the SDO Client (e.g. inside the CANopen Master) only has 1 SDO client and therefore only 1 SDO Client object 0x1280 in the object dictionary:

which contains the following data in the sub indices:

The values of the subindices 1 ..3 have to be reconfigured (internally) each time the SDO client shall be used to communicate with another device. So only 1 SDO transfer at a time is possible from this CANopen Master.

1 SDO Client for each slave

The other approach is using a dedicated SDO Client for each SDO server (in a CANopen slave). The most useful approach would be to assign the 1st SDO client to node 1, the 2nd SDO client to node 2 and the 127th SDO client to node 127.
For this way the object dictionary of the CANopen Master device requires 127 SDO client objects.

According to the predefined connection set all these SDO clients are disabled at start-up and needs to be configured e.g. by the application at startup accordingly. So the 1st SDO clients would use the CAN-IDs 0x601 and 0x581 to communicate with node 1 and the 100th SDO client (configured at object 0x12e3) would use the CAN-IDs 0x6e4 and 0x5e4 to communicate with node 100. Using this approach up to 127 SDO transfers in parallel are possible.

Fixed network with a subset of slaves

If the network consists only of a few slave nodes for example 10, 32 and 64 it is also possible to implement only the 10th, 32th and 64th SDO client in the CANopen master devices.

CANopen Emergency Message

Sorry, this entry is only available in Deutsch.

USDO – Universal Service Data Object

The Universal Service Data Object

The USDO Service in CANopen-FD is the replacement for the SDO service in CANopen.
Transfering configuration and diagnostic data is the primary purpose of this protocoll.
By using CAN-FD the telegrams can reach a length of up to 64 data byte.
Due to the longer telegrams and the higher data bit-rates up to 5 Mbit/s, significant faster data transfer is being provided.
You can find a short Demonstartion about the speed advantages of CANopen-FD over classic CANopen here.
The transmission can be done by using the expedited, segmented or bulk protocol.
Data can be transmitted either in unicast or broadcast mode.
For transfers between networks transfers a own remote service is also provided.

USDO Unicast

As SDO did before, USDO allows the direct connection from one client to exactly one server.
Furthermore it can handle multiple sessions between the client and the server at the same time.
Besides that, multiple clients can access the object directory of the server simultaneously, access to the same object at the same time has to be rejected..
In case of to many requests at once, the server can reject them by sending „USDO Server Busy“.

USDO Broadcast

Additionally USDO supports broadcast connections from one client to all available servers.
If on of the servers rejects the connection, for example because it has too many active connections pending, it sends informs the client by use of an unicast aborts.

USDO Remote Service

The remote service allows to send telegrams to other, not directly attached CAN networks, by using a transparent CANopen-FD router.
In the first segment additional protocol data is being transmitted.
For example source- and destination network as well as source- and destination node ID.

USDO Expedited Protokoll Type

The expedited transfer is a confirmed transmission with a maximum of 56 Byte of data.
The other 8 byte are used for protocol data like destination address, index or subindex.
Frame Example: Unicast Expedited Upload with 56 Byte of data:

USDO Segmented Protocol Type

The segmented transfer is a confirmed transmission, with a maximum of about 4.29 Gigabyte of definable data length, or undefined length by streaming.
If requested the segmented transfer has to be done, although expedited transfer would be more sufficient.
In the first segment, protocol data like destination address, data type or data length are transmitted.
The transmission of the application data begins with the second segment.
Every segment is confirmed from the counterpart.
Frame Example: Unicast Segmented Upload with 64 Byte of data:

USDO Bulk Protocol Type

As the equivalent to the block transfer in CANopen, the bulk transfer in CANopen-FD is a confirmed transmission, with a maximum of about 4.29 Gigabyte of definable data length, or undefined length by streaming.
As with the segmented transfer, the first segment contains protocol data like destination address, session ID or the gap between two segments which is defined by the server.
Starting from the second segment, the transmission of the application data begins.
Unlike with segmented transfer in bulk transfer only the first and the last segment is being confirmed.

Frame Example: Unicast Bulk Download with 172 Byte of data:

USDO Stream

Segmented and bulk transfer both support transmission of data with undefined data length as stream.
Therefore the data length of the transmission is set to value 0xFFFFFFFF.
The transmission is kept alive as long as either the USDO client finishes it or the server is sending an abort.

CANopen FD – the sucessor of CANopen

Sorry, this entry is only available in Deutsch.