Author: Torsten Gedenk

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:
SDO Client Object
which contains the following data in the sub indices:

SDO Client Subindices
SDO Client Subindices

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.

SDO Client objects
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.

EnergyBus Implementation Hints

Some implementation hints for EnergyBus in light-electric vehicles such as e-bikes:

All components

    • Differ between Sleep and Deep Sleep. The typical EnergyBus low power mode is called ‘Sleep’ and means, that the devices are powered by the auxiliary voltage and can wakeup on receiving CAN messages.
    • Implement real Sleep/Wake-Up handling. The EnergyBus Controller (EBC) command the network wide Sleep. The typical Display (HMI) power button send (only) a sleep request to the EBC.

EnergyBus Controller

    • Create a system design with the maximum components. The EBC must support this maximal network.
    • Provide non-volatile memory on EnergyBus Controller (EBC) hardware

It is recommended to have some non-volatile memory (EEPROM, EEPROM emulation, …) on the EBC hardware to store identity information of the connection components. This will increase the start-up of the network inside the vehicle significantly.

    • Detect connection of an EnergyBus service tool in the EBC

An EnergyBus service tool according to the CiA 454 specification reports itself by sending heartbeat of the node-ID 125. The EBC should recognize this and should e.g. prevent the Motor Controller (MCU) from powering. The bike shouldn’t move when a service tool is connected or do SDO transfers.

All ‘slave’ components: battery, display, manufacturer-specific devices, …

    • Use dynamic node-Ids as required by the specification CiA 454

The EnergyBus specification CiA 454 requires the use of dynamic node-IDs assigned by the EBC at startup. Using fixed node-IDs might work in the beginning with some other devices, but it will cause compatibility problems in the long term.

    • Support a dynamic instance offset

Using a dynamic instance offset (write-able object 0x6000:xx), the EBC can assign a different global instance number to the device and thus multiple devices of the same type, will be supported. It always only starts with 1 battery or 1 HMI, but mostly there will be more in the future.

Bootloader

According to the EnergyBus specification the usage of a boot-loader to update the firmware in the field is recommended. In addition to that it is recommended to implement some checks in the bootloader that it does not start a wrong application but with valid CRC, that has been flashed by accident.