Electrical – CANopen transmission to multiple IDs at the same time

canmicrocontrollerrobotics

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.

Best Answer

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.

Related Solutions

Electronic – arduino – Single wire CAN // Saab 9-3 I-Bus // GMLAN

Most small microcontrollers (like those used on the Arduino) won't be fast enough to implement CAN in software. That's why the CAN Shield uses the MCP2515 CAN controller IC.

I recommend one of two options:

Connect an MCP2515 chip to your Arduino, and use the AU5790 CAN transceiver. Either do this on a breadboard or design a PCB.
Use the Arduino CAN shield, but solder some jumper wires from the TXD, RXD, and GND lines over to another board with an AU5790 on it.
Download the schematic and PCB designs for the Arduino CAN shield, and adjust the design to accept the AU5790 instead of the MCP2551.

Unfortunately, the AU5790 doesn't seem to be pin-compatible with the MCP2551. It nearly is, which is a shame.

Electronic – How to deal with signed int overflows

Clearing up some misunderstandings will probably help.

First, your data is a 16-bit value. There's no "overflows" and "actual data" -- the 16 bits are just divided into two 8-bit pieces (bytes). To get the right binary value, you need to concatenate the bytes. In C, you can do it by starting with unsigned values and using bitwise operators, like this:

uint16_t highbyte, lowbyte, data; 
highbyte = get_can_byte();   //Do whatever you normally do to get the bytes
lowbyte = get_can_byte();

data = highbyte<<8 | lowbyte;

Now you have the correct 16-bit value. If you want the result to be signed, you can simply cast the value to a signed type:

int16_t signed_data;

signed_data = (int16_t)(highbyte<<8 | lowbyte);

To answer your specific questions:

Overflows produce the same binary values regardless of whether your variable is signed or unsigned. For example, 0x7fff + 1 == 0x8000. Whether you interpret 0x8000 as 32768 or -32768 depends on the data type. (Note that signed integer overflow is technically undefined in the C standard -- this is what your CPU will do.)

As I said, it all depends on the data type:

uint16_t ui = 0xffff;    //65535
int16_t   i = 0xffff;    //   -1

What you're describing sounds reasonable for a high-precision measurement. A change of +1 or -1 in your upper byte represents only 1/256 of your total steering range. The low byte will be extremely sensitive to the exact angle.

Note that it's best to convert to a signed value as late as possible, and to do it with an explicit cast. Things like bitwise operators can behave differently or produce undefined behavior when used on signed values. In general, whenever you're doing bit manipulation, use unsigned values.

Best Answer

Related Solutions

Electronic – arduino – Single wire CAN // Saab 9-3 I-Bus // GMLAN

Electronic – How to deal with signed int overflows

Related Topic