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


Enter image description here

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?


Enter image description here

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.

  • \$\begingroup\$ Are you asking how to write a program to communicate with CANopen? \$\endgroup\$
    – Jeroen3
    Oct 3, 2018 at 12:07
  • \$\begingroup\$ I am asking whether it is possible at all. Or do I have to have two CANopen to send two messages at the same time ? \$\endgroup\$
    – Joe
    Oct 3, 2018 at 12:11
  • \$\begingroup\$ What exactly does "at the same time" mean to you? You can certainly send more than one bit or byte in a given message, but at the physical level, you're only getting one bit at a time. \$\endgroup\$
    – Dave Tweed
    Oct 3, 2018 at 12:21

4 Answers 4


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.

  • \$\begingroup\$ Just added another screenshot. I had the exact number of IDs not in my head, so I made those numbers on my own. But in the added screenshot the numbers are real. So the problem was that I sent those messages arisen from button pressing to TPDOs (181h and 281h) ? Should I have sent those messages to the correspond RPDOs (201h and 301h) ? \$\endgroup\$
    – Joe
    Oct 4, 2018 at 11:22
  • \$\begingroup\$ Nope, sending to RPDOs is a dumb idea. \$\endgroup\$
    – Joe
    Oct 4, 2018 at 12:06
  • \$\begingroup\$ @Joe What you should do, if no documentation is available, is to read the device's various object dictionary entries like the mentioned 1000h. They can provide information of what kind of data there is. For this you need to send SDOs. Coding and bit-banging SDO traffic manually is possible, but quite painful. There's tools that do all the hard work for you, such as this one. But really, stumbling about blindly while trying to communicate with an unknown CAN device never works well. \$\endgroup\$
    – Lundin
    Oct 4, 2018 at 12:34
  • \$\begingroup\$ I figured out that the CAN device modell is a CiA 301. The problem that the robot does not move to my message datas still remains open. Turning on and off the motor works just fine. I even can blink the monitor on my remote controller via CAN bus, but it just doesnt want to move. Do you have any idea or tipp in such a situation ? \$\endgroup\$
    – Joe
    Oct 4, 2018 at 15:36
  • \$\begingroup\$ @Joe CiA 301 means CANopen... it is the main CANopen standard. Available here: can-cia.org/standardization/specifications Some study might be in order. \$\endgroup\$
    – Lundin
    Oct 4, 2018 at 17:02

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.

  • \$\begingroup\$ Thanks for the answer. Unfortunately the manufacturer does not have this datasheet and they asked me to build a CANopen communication. They only have a remote control device, as you assumed. That is the reason why I tried to find out the message arising from "pressing buttons" to reuse this messages afterwards. \$\endgroup\$
    – Joe
    Oct 3, 2018 at 19:59
  • \$\begingroup\$ I am confused. Are you trying to communicate with existing robot that has CANOpen interface, or are you trying to add CANOpen interface to the robot? \$\endgroup\$
    – Maple
    Oct 3, 2018 at 20:03
  • \$\begingroup\$ The robot which I am using does not have any CANOpen interface. So the robot must be controlled with the remote controller. But the CAN bus is integrated in the electrical circuit of the robot. So I am trying to write a programm so that I can communicate with my robot via CANOpen. \$\endgroup\$
    – Joe
    Oct 3, 2018 at 20:09
  • \$\begingroup\$ Sorry, this does not make any sense to me. If robot does not have CANOpen interface then how can you communicate with it using CANOpen? If robot already has CAN bus then it should have some kind of interface, and that is the only interface you can use. Unless you also change robot firmware and implement CANOpen support in it. But that is also impossible without lots and lots of manufacturer's documentation. \$\endgroup\$
    – Maple
    Oct 3, 2018 at 20:34
  • 1
    \$\begingroup\$ I would stay away from the company that does not have the documentation for their own product. Anyway, if you want to reverse-engineer the communication you need to catch all the traffic that happens when you press and release each button and also when both pressed simultaneously, if there is any. Then you can try to send exactly the same commands in same order and hope that it would be enough. In your experiments you describe one set of messages that you capture on a bus but then you are sending different messages and asking why they don't work. \$\endgroup\$
    – Maple
    Oct 3, 2018 at 21:28

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.


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.


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

  • \$\begingroup\$ Maybe I have to describe more in detail what I am trying to do : As you described correctly, button A and B have be pressed together to perform an Action D. So I tried to read the CAN bus so that I can figure out what happens when I press those buttons. ID 1 changed to 10 when I pressed A and ID 2 changed to 100 when I pressed B. So I came to the conclusion that I have to send 10 to ID 1 and 100 to ID 2 to perform the action C from my PC. \$\endgroup\$
    – Joe
    Oct 3, 2018 at 12:29
  • \$\begingroup\$ Even if I define flags for multiple pressings at the end I can only send message to ONE ID which is not enough in my case, right ? \$\endgroup\$
    – Joe
    Oct 3, 2018 at 12:31
  • \$\begingroup\$ In CAN you don't send a message to a specific device, you send 'messages' which are broadcasted. Devices can set a filter though. You should make a differences of CAN IDs and CAN devices. An ID is a message (type), a device is something that can send or receive messages (with one message ID). \$\endgroup\$ Oct 3, 2018 at 12:42
  • \$\begingroup\$ It depends what you mean with 'together' ... do you mean that both buttons (from two different devices) should be pressed down at the same time? Or the button press down times of button A and B should be within a certain time? Or the depressing of the buttons? 'Simultaneously' is a too broad term now. \$\endgroup\$ Oct 3, 2018 at 12:44
  • 1
    \$\begingroup\$ @MichelKeijzers That is not how CANOpen works at all. You do not "change the code in the receiver". The CANOpen devices expose communication objects that you can read/modify using can messages. The only way to do this properly is to read the manual for the device you want to control, something that OP is clearly unwilling to do \$\endgroup\$
    – Maple
    Oct 3, 2018 at 19:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.