Hex 43x pdo map en

In CANopen, a PDO is not restricted to a fixed COB-ID — it can be set freely. This means you can make several machines share the same RPDO COB-ID to achieve one-to-many control. However, the default RPDO COB-ID cannot meet this need. Therefore you must adjust not only the mapping of every controlled motor but also the RPDO COB-ID.

Sounds a bit abstract?

Take velocity control with a torque limit as an example. Each motor needs two objects: 6072h (Max Torque) and 60FFh (Target Velocity). That is six bytes per motor. With four motors in total, we need 24 bytes.

The four motors have CANopen IDs 0x01, 0x02, 0x03, and 0x04. Each motor controls its own 6072h (Max Torque) and 60FFh (Target Velocity). Here we need to pick one COB-ID to serve as the shared RPDO1 COB-ID for all motors.

Here we choose the TPDO1 COB-ID of node 0x10 (i.e. 0x190). You may pick any CAN-ID, as long as it does not conflict with another node. We recommend using the master's TPDO1, 2, 3, or 4.

From the sending program's point of view, the order of all 24 bytes is 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)

So each motor has two active objects; the remaining bytes are just padding. Assuming we put 6072h first, the mapping for motor 1 should look like this:

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

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.