Sorry, this entry is only available in German.
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.