CANopen transmission to multiple IDs at the same time

Question

I am asking myself, whether it is possible that I simultaneously send multiple signals to my robot via CANopen.

---

Edit:

I am trying to build a CANopen connection with my robot. I can turn the motor up by sending a message (8A 00 0A 00 00 00 00 FB) to ID 181h. Now, I am trying to control the movement of the robot via CANopen. However, it does not repond at all.

Here is what I did:

I first move the robot with my control module. Since I have to press down two buttons at the same time to move the robot, I checked how the data values of each IDs changed for each button press.

For example, when I press down the button A, the data value of ID 181h changed like 00 00 00 00 00 00 00 FB -> 00 00 00 FE 00 00 00 FB. When I press down the button B, the data value of ID 301h changed like 00 00 00 00 00 00 00 FB -> 00 00 00 00 32 00 00 FB.

So now I tried to move the robot via the CAN connection as the one in the picture. I first wrote "00 00 00 FE 00 00 00 FB" to ID 181h and after that I wrote "00 00 00 00 32 00 00 FB" to ID 301h.

However, there isn't any response at whatsoever. Am I missing something?

---

EDIT:

Pressing button A changes the value of 181h to 0A 00 09 00 00 00 00 FB and pressing down button B changes 281h to 00 00 00 FA 6F BD 00 FB. So I sent those messages to the TPDOs 181h and 281h, respectively. However, still no response.

Answer 1

In order to succeed with this project, you need to know both how CANopen works and how the specific device works. For example, if you are able to read Object Dictionary item 1000h, it will reveal which device profile the robot is using.

All data in CANopen is sent through PDOs (process data objects). Messages coming out of a CANopen node are called TPDO (transmit PDO) and messages coming in to a node are called RPDO (receive PDO). This does of course mean that one node's TPDO must be another node's RPDO.

Some insights on reverse-engineering CANopen:

• 181h is the standard CAN id for the first TPDO of node 1.
• 301h is the standard CAN id for the second RPDO of node 1.

This is in accordance to for example the most common device profile DS401 "generic I/O module", but may match other device profiles too.

Notably though, it is unlikely that 181 and 301 have similar functionality. I would expect one of them to be incoming data and the other to be outgoing data.

If this is device profile DS401, then 181h will be digital data going in one direction, while 301h will be analog data going in the other direction. It is unlikely that these 2 correspond to 2 different buttons (digital). In device profiles like DS401, it is specified how data should be stored. In a generic CANopen application, this isn't specified, but data could be mapped into PDOs in custom ways.

Thus what you describe doesn't seem to make any sense. It is also unclear why these two PDOs have value 0xFB in the end. This is also some kind of data - checksums are handled by hardware.

Answer 2

In order to control any CANOpen device you should first study the object dictionary of the device. In the dictionary you'll find Service and Process Data objects, which are essentially addressable locations for configuration data, status, control commands etc.

So, instead of trying to figure out what CAN messages to send and how to send them, you should learn how CANOpen works first, find communication objects that you need to access and then send messages in CANOpen format to perform the functions that you need.

Most likely these won't be messages "button A pressed" or "button B pressed", but rather something like "Node NNN Change object 0x6063 to value XXXX", which will be interpreted as "set new speed for left motor".

There are many communication profiles used in robotics, like CiA 402 (CANopen drives and motion control profile). You robot might support one of them.

If you do not know the object dictionary of your specific CANOpen device and do not even know if it supports one of the standard device profiles than there is very little you can do.

From your question it seems you have some kind of remote control device and you attempting to reverse-engineer the communication. This could be tedious process, since some CANOpen commands require several back-and-forth CAN messages to do something. My only advice in this situation would be to try and get the datasheet from the manufacturer.

Answer 3

This is, in a sense, trivial and can be done with (I think) any CANBus implementation, but it's not done at the CANopen level.

In general, any CANBus controller on the market, such as the venerable SJA1000, will allow the implementation of an "acceptance mask". This will essentially cause the interface to treat some bits of the address field as don't-cares. Setting, for instance, the last 3 bits of the mask to don't-care will cause the device to respond to a block of 8 addresses. Just as a reference point, the SJA1000 has four independent acceptance masks. So you can set up as many as four address blocks of varying sizes for each unit to respond to. See, for instance, the SJA1000 app note.

So, the work you need to do is configure your units to take advantage of the interface capabilities. Once that's done, you simply transmit an ID to one address block for individual messages, and to another for group messages.

Answer 4

CAN (and I think CANopen as well) can only transmit one ID at a time.

But there are some solutions based on what you need:

1. Send a single ID that is received by multiple CAN devices (robot parts). I think this is what you need.
2. If you need to act on a response which is a combination of different devices (where the buttons come from), than use separate CAN message (ID)s to set a mode, and if all modes (buttons) are active, act on it by the robot part(s) that need to respond.

In case 2, e.g. if you have button A, B and C that needs to be pressed to perform an action D, you can define:

BUTTON_A_PRESSED_ID, sent by the part that has button A
BUTTON_B_PRESSED_ID, sent by the part that has button B
BUTTON_C_PRESSED_ID, sent by the part that has button C

The part that should act on it, receives these messages, sets 3 flags, and if all 3 are valid/received, action D is performed and the flags are reset.

Update

See comment Maple below... the above only works if the receiver code can be changed, which seems not to be so.