Hex 43x pdo map en
In CANopen, a PDO COB-ID can be configured as needed. By assigning the same RPDO COB-ID to several motors, the host can update each motor's target values with one CAN-FD frame. This requires changing both the RPDO COB-ID and the RPDO mapping on every controlled motor.
Sounds a bit abstract?
Take velocity control with a torque limit as an example. Each motor uses 6072h (Max Torque, 2 bytes) and 60FFh (Target Velocity, 4 bytes), for 6 bytes per motor. Four motors therefore require 24 bytes, which fit in one CAN-FD frame.
Assume the four motors have CANopen IDs 0x01, 0x02, 0x03, and 0x04. Choose an unused COB-ID and configure RPDO1 on all four motors to receive that COB-ID.
This example uses 0x190. It is conventionally the TPDO1 COB-ID of node 0x10, but here it is simply the CAN-ID on which the host sends the shared control frame. The important requirement is that it must not conflict with any other frame on the bus.
The 24-byte payload is arranged as follows:
The 4-byte padding object is 3000h 03h; the 2-byte padding object is 3000h 02h.
Motor 1 Max Torque (2 Bytes) | Motor 1 Target Velocity (4 Bytes) | Motor 2 Max Torque (2 Bytes) | Motor 2 Target Velocity (4 Bytes) | Motor 3 Max Torque (2 Bytes) | Motor 3 Target Velocity (4 Bytes) | Motor 4 Max Torque (2 Bytes) | Motor 4 Target Velocity (4 Bytes)
| Byte offset | Contents |
|---|---|
| 0–1 | Motor 1: 6072h |
| 2–5 | Motor 1: 60FFh |
| 6–7 | Motor 2: 6072h |
| 8–11 | Motor 2: 60FFh |
| 12–13 | Motor 3: 6072h |
| 14–17 | Motor 3: 60FFh |
| 18–19 | Motor 4: 6072h |
| 20–23 | Motor 4: 60FFh |
Each motor maps only its own 6-byte slot to active objects and maps the other 18 bytes to the 3000h padding objects. All four motors receive the same frame, but each motor updates only its own targets.
Motor 1 uses the following mapping:
Max Torque 6072h | Target Velocity 60FFh | 4-byte padding | 4-byte padding | 4-byte padding | 4-byte padding | 2-byte padding
For motor 2, its RPDO mapping should look like this:
4-byte padding | 2-byte padding | Max Torque 6072h | Target Velocity 60FFh | 4-byte padding | 4-byte padding | 4-byte padding
For motor 3, its RPDO mapping should look like this:
4-byte padding | 4-byte padding | 4-byte padding | Max Torque 6072h | Target Velocity 60FFh | 4-byte padding | 2-byte padding
For motor 4, its RPDO mapping should look like this:
4-byte padding | 4-byte padding | 4-byte padding | 4-byte padding | 2-byte padding | Max Torque 6072h | Target Velocity 60FFh
For example, setting every motor's max torque to 800 (80% of peak torque) and target velocity to 1.0 rev/s produces this 6-byte group for each motor:
20 03 is the little-endian Uint16 representation of 800, and 00 00 80 3F is the little-endian Float32 representation of 1.0. Repeating the group four times produces one 24-byte CAN-FD frame that updates all four motors.
Saving the PDO mapping
The PDO mapping can be saved so you don't have to reconfigure it on every power-up. See object 1010h for details. Once saved, on each boot you only need to send the NMT command to start controlling right away.
About the padding objects
You don't have to stick to this exact layout — thanks to the flexibility of PDOs, you can arrange things freely. Suppose the target velocity actually needs to change at a higher frequency while the max torque does not; then you can put all the max-torque objects into RPDO2, sending the target velocity at a high rate and the max torque at a low rate.
You also don't have to force all motors into the same control mode: some motors can run in velocity control mode while others use MIT control mode. As long as the mapping is correct, it works.
About configuration automation and persistence
Remember that canopend essentially just sends some CAN messages, so you can fully automate the PDO configuration process. For the exact format of the SDO protocol, please refer directly to the many tutorials available online.
Also, unless these settings are saved via object 1010h, they revert to their default configuration after every power-up. If you are sure you won't change these settings, simply save via object 1010h to make the configuration persistent. On subsequent boots there is no need to reconfigure — you only need to send the NMT command, select the mode, and manipulate the control word.