CAN bus reverse-engineering

Question

I am struggling with CAN bus reverse-engineering. It might be a silly question, but it irritates me.

Enter image description here

These are traffics that arise from pressing buttons A and B which is lifting up the 1. Axis of the robot at the end.

Pressing down button A changes the value "09" in 181h node and button B changes the value "C8" in 281h.

If I am not wrong, I have to feed RPDOs to replicate the lifting up action instead of sending the messages "0A 00 09 00 00 00 00 FF" to 181h and "00 00 00 C8 6F BD 00 FF" to 281h. So basically I resent the messages from RPDOs back to RPDOs.

Enter image description here

Is there anything wrong until now? (It must be...otherwise it would have worked.)

As you can see from the above screenshot I manullay sent the messages by pressing each line with the space bar. And it seems like that between my Tx messages lots of Rx messages show up. Is this maybe the reason why the robot shows no reaction?

Enter image description here

UPDATE:

The TPDO message "0A 00 09 00 00 00 00 FF" that arises from the pressing down button A gets ignored because whenever I write a TPDO message 0A 00 09 00 00 00 00 FF, it gets overwritten with its default value 0A 00 0A 00 00 00 00 FF so fast that my message is like "not arrived" at all.

The transmission type of TPDO is currently asynchronous with event timer of 50 ms. This leads that my TPDO somehow overwritten with default value 0A 00 0A every 50 ms. How do I handle this problem? I thought this asynchronous transmission type with 50 ms means that the TPDO has to be checked every 50 ms and if there was a change -> transmission. But where does this 0A 00 0A 00 00 00 00 FF default value come from then?

Another question: I thought the whole time that I have to write the RPDOs value back to RPDO to replicate the action. But it seems like that only from pressing down the button A the RPDOs does not change at all. Then how can I replicate the pressing button A action at all?

UPDATE 2: The bit rate is 125 kbit/s. I am using CANopen so that I can control the robot with my computer, instead of using the remote controller. The robot that I am using is Brokk 170. Below you can find an Excel file where the recorded CAN messages are. Those CAN messages arose when I powered up the robot using the robot controller.

I transmitted the messages until the message with number 107, since the value 0A 00 0A 00 00 00 00 FF indicates that the robot is now powered up. But somehow the transmitted sequence does not power up the robot. Now I am trying to find a way to block the messages from the remote controller.

https://drive.google.com/open?id=1Du4J27KykzrTtCquFt29uMa_qhpZP4Ov

• Peter Mortensen: Can you provide more information about the system (by editing the question)? E.g. bit rate on the CAN bus and how many devices are on the CAN bus. What is the CAN bus used for? - is it only to communicate to/from the robot or are individual joints on the CAN bus? Is there some kind of central controller that is on the CAN bus? Following where the CAN bus cables are connected might give some clue. What is the manufacturer and model name/number of the robot?
• Peter Mortensen: Can you provide a full CAN bus log file, over the entire time this is going on (where you are not sending out messages, but operate the robot with the buttons)? An external place is required (say, by a direct URL (public) on Dropbox) due to the size. Later, when we have narrowed down this problem we can post a reduced version in this question).

Answer 1

This looks like CANopen traffic (RPDO is also mentioned in the question). 0x80 is SYNC, and it seems it is send at regular intervals (about every 26 ms, 38-39 Hz). And some device responds to the SYNC messages by sending out messages with ID 0x181 and 0x281. But that is just a guess at this point.

It could also be that the content of ID 0x181 and 0x281 are set points to a servo (thus the same device sends out 0x80, 0x181, and 0x281) and that the feedback position is contained in the 0x301 messages.

It should be possible to correlate physical positions of the robot with the messages. A set point is (probably) set immediately and the actual positions are lacking behind.

Note: 181h is not a node, and you are not sending messages to it. 181h is a CAN message ID. As it is likely CANopen, 0x181 is the message "PDO1, transmit" for the device with ID 1. Note that it is not always clear if the device ID indicates what device sends it or if the device is the destination.

Type Function code: Device ID range:
 Binary Decimal ID in Hex Decimal
 CAN ID
--------------------------------------------------------------------
NMT 0000 0 No 0 - 0 0 - 0
SYNC 0001 1 No 0x80 - 0x80 128 - 128
Emergency 0001 1 Yes 0x81 - 0xFF 129 - 255
Time stamp 0010 2 No 0x100 - 0x100 256 - 256
PDO1, transmit 0011 3 Yes 0x181 - 0x1FF 385 - 511
PDO1, receive 0100 4 Yes 0x201 - 0x27F 513 - 639
PDO2, transmit 0101 5 Yes 0x281 - 0x2FF 641 - 767
PDO2, receive 0110 6 Yes 0x301 - 0x37F 769 - 895
PDO3, transmit 0111 7 Yes 0x381 - 0x3FF 897 - 1023
PDO3, receive 1000 8 Yes 0x401 - 0x47F 1025 - 1151
PDO4, transmit 1001 9 Yes 0x481 - 0x4FF 1153 - 1279
PDO4, receive 1010 10 Yes 0x501 - 0x57F 1281 - 1407
SDO, transmit 1011 11 Yes 0x581 - 0x5FF 1409 - 1535
SDO, receive 1100 12 Yes 0x601 - 0x67F 1537 - 1663
NMT error ctrl 1110 14 Yes 0x701 - 0x77F 1793 - 1919

• Joe: "It should be possible to correlate physical positions of the robot with the messages" Yes, this is what I am trying to achieve. Your guess that 0x281 is a set point to a servo sounds reasonable since the value is only changing when I actually try to change the physical position. 0x181 might be something else since it changes its value when I turn up the motor and pressing other buttons which do not correlate with physical position of the robot.
• Joe: So now back to the question, now I sent the messages in a certain intervall (50ms )over and over again. But the robot is not moving at all and there is this warning that the bus is now busy. It is as if something blocks that the robot is moved by messages. Any idea how to handle, debugg or analyze such a case ?
• Peter Mortensen: @Joe: It is not a good idea to have two devices send a CAN message with the same CAN ID. This will result in CAN frame errors. The frequency of these CAN frame errors will depend on a lot of factors, including the bus load. As the CAN frame errors happens during transmit it only takes 16-32 CAN frame errors before both devices go into the bus off state. Some devices very stubbornly refuses to come out of busoff unless power cycled (I think this is misinterpretation of the CAN standard, but that is another story).
• Joe: I think I found the reason why my message gets ignored all the time. There is a remote controller for the robot. The robot brokk170 that I am using is designed to be controlled with this remote controller. So I have to turn on the robot via the remote controller. And this remote controller was sending his value to the robot. This was the reason why my messages gets overwritten the whole time.
• Joe: So I see two options here : 1) I find a way that the messages from the remote controller gets ignored by the robot. 2) I turn on the robot using the remote controller and capture the CAN message. For the first option I do not have any clue how to do it (although it would be more "elegant" way than the other). For the second option, I captured the sequence of the messages. Then I typed each CAN message manually and transmitted, but somehow the robot gets not started.