CANopen is a communcation protocol based on CAN. It has been developed and is maintained by the CAN in Automation e.V. and has been standardized internationally an European specification EN 50325-4. It defines a set of communication services to access process data and configuration data in CAN networks.
The CANopen Bootup Message is sent by a CANopen device when it starts. This is done to indicate to all other devices in the network that it is ready to communicate by other CANopen services. Although it may sound simple, there are preconditions that need to be met before a bootup message can be sent. The CAN-ID of the bootup messages depends on the CANopen node-ID of the device. That is why the device must have a valid node-ID between 1 and 127 in order to transmit a bootup message. Therefore, devices without a defined node-ID or without any switches to set the node-ID must use a dynamic Node-ID configuration by Layer Setting Services (LSS).
CAN-ID and CAN data
Anyway, we only discuss the case with a valid node-ID for now.
The CAN-ID of a bootup message is 0x700 + node-ID. That means that the CAN-IDs are located in the range between 0x701 and 0x77f. Each CANopen bootup message has a length of 1 byte. The value of this one byte is always 0x00. The same CAN-ID but different data are used by CANopen Heartbeat or Node Guarding messages. Continue reading “CANopen Bootup Message”
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.
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.
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“.
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:
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.