2
\$\begingroup\$

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

\$\endgroup\$
2
  • 1
    \$\begingroup\$ 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? \$\endgroup\$
    – Peter Mortensen
    Commented Oct 8, 2018 at 18:08
  • 1
    \$\begingroup\$ 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). \$\endgroup\$
    – Peter Mortensen
    Commented Oct 8, 2018 at 18:11

1 Answer 1

Reset to default
3
\$\begingroup\$

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
\$\endgroup\$
5
  • \$\begingroup\$ "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. \$\endgroup\$
    – Joe
    Commented Oct 8, 2018 at 8:16
  • \$\begingroup\$ 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 ? \$\endgroup\$
    – Joe
    Commented Oct 8, 2018 at 8:20
  • 1
    \$\begingroup\$ @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). \$\endgroup\$
    – Peter Mortensen
    Commented Oct 8, 2018 at 17:41
  • \$\begingroup\$ 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. \$\endgroup\$
    – Joe
    Commented Oct 8, 2018 at 19:50
  • \$\begingroup\$ 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. \$\endgroup\$
    – Joe
    Commented Oct 8, 2018 at 19:59

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.