CANopen addressing scheme?

Question

TL:DR Using CANopen, don't see CANopen IDs on the bus.

I'm very confused. I have a semi-functional CANopen network set up between a PLC and a motor controller. Those two items are the only two nodes on the bus.

I say semi-functional because only some of the features work. The sync message is going out from the PLC who is the bus master. This is verified by the motor controller, that will fault if the sync message goes missing like when unplugging the CAN bus.

Information seems to only move on the bus via TPDOA and RPDOA. The motor controller accepts data on CAN ID 0x201 RPDOA. The motor controller transmits data on CAN ID 0x181 TPDOA. This aligns with the CANopen standard.

I'm trying to move other data from the motor controller to the PLC vis TPDOB, TPDOC, and TPDOD. The addresses should be 0x281, 0x381, and 0x481 respectively. This is not functional and the PLC does not receive anything. This also aligns with the CANopen standard.

To try and figure out what's wrong I sniffed the CAN network. The sniffing was done With an Arduino and a CAN shield with an MCP2515. The MCP2515 uses an 8MHz cristal and the bus is running at 500k. The problem is that when looking at just the IDs I don't see anything that I was expecting. The two most common IDs are 0x269 and 0x4A9. These don't match any CANopen IDs. There are some other IDs that I'm also seeing but far less frequently 0x26A, 0x4AA, 0x262, and so on.

To make sure that what I'm seeing is not some artifact I've poured over the library that I'm using. I did not find any faults with the way the IDs are detected and presented. I also looked at how the library configures the CAN bus baud rate. I did not entirely agree with their implementation and tweaked it. Unfortunately, even with the tweak, all I see is the aforementioned IDs.

The thing I have yet to try is to filter out the two most common IDs to make sure that they are not somehow obscuring the other IDs because the buffers of the MCP2515 may be overloaded. It only has two buffers and I don't think the Arduino can read them fast enough.

Are there any reasons why the actual CAN IDs look funny? Am I misinterpreting the CANopen ID standard or is there some other coding in play?

Answer 1

CANopen isn't "plug & play". The identifiers - CANopen calls them COBID - that you mention are indeed as per the standard (DS-401 etc) but they are just the default settings. Factory settings if you will. For each TPDO/RPDO pair, you need to configure the COBID so that sender and receiver are looking for the same ID. You might also potentially have to configure size (DLC), PDO mapping and PDO communication parameters.

The reason why you see some strange COBID on the bus is likely because someone has already done the above configuration. This is done by SDO access to the Object Dictionary and can either be done one single time from a PC or similar, followed by a write to the CANopen save object. Or it can be done at system start-up, when one node sends out various SDO messages when node to be configured is still pre-operational. In case of the latter, you should observe lots of CAN identifiers for SDO around >0x500 during start-up.

CANopen is ridiculously flexible so there's a lot of degrees of freedom here.

---

This is verified by the motor controller, that will fault if the sync message goes missing like when unplugging the CAN bus.

If there's just 2 nodes then that's not what happens. The CANopen sync message is a higher layer concept. Rather, the remaining node fails to get acknowledge bits in the low-level CAN frame set by a listening node. If this happens enough times, the node will rapidly go into error modes, eventually ending up "error passive" and completely disconnected from the bus. This is guaranteed by the CAN hardware and data link layers and has nothing to do with CANopen.