CANopen - explanation of TPDO and RPDO

Question

I am working on a project that uses the CANopen protocol. I have a problem with understanding the use of TPDO and RPDO. In some articles, RPDO is described as a request calling TPDO from another node, and in others as a contract to handle the received TPDO. The free canopen-stack and CanOpenNode libraries use the second approach to RPDO, it is not possible to send an RPDO 'request'. But I am not able to understand why TPDO and RPDO, according to the recommendations of the standard, have different COB-IDs (CAN message identifier). The COB-ID for TPDO1 has the range 0x181-0x1FF (0x180 + node_id) and the RPDO1 range is 0x201-0x27F (0x200 + node_id).

Example:

Node_1 - node id = 1 TPDO1 (COB ID = 0x181)

Node_2 - node_id = 2 RPDO1 (COB_ID = 0x201)

In the example above, I am unable to receive the data because the COB-IDs are not equal. To receive TPDO1 from Node_1 it is necessary to configure RPDO1 in Node_2 to COB-ID equal to TPDO1 Node_1. My conclusions are that e.g. TPDO1 address (0x181) is RPDO1 for another node with id different from 1. Am I correct? So why are there two address pools, TPDO and RPDO. Or did these libraries apply their implementation of this case?

ANSWER TO @Lundin:

Answer 1

But I am not able to understand why TPDO and RPDO, according to the recommendations of the standard

These are just standardized default COBID. Like there exists default PDO mapping and communication settings. They have to be set to something out of the box.

In the example above, I am unable to receive the data because the COB-IDs are not equal.

CANopen is not "plug & play". One node's TPDO has to be "routed" to another node's RPDO. Just like you say, you have to change the COBID somewhere or the nodes won't be able to communicate. Every CANopen bus needs a design plan: what nodes will there be, what should they send, how should they send it and how often, etc.

I'm not sure exactly what was the design rationale for the default PDO COBID (other than that they have fairly high CAN arbitration priority), but since all nodes have different COBID you wouldn't get "plug & play" no matter.

And keep in mind that CAN communication is not necessarily point-to-point! It is just as often one node communicating with several others.

It's quite convenient to have them at default locations. Imagine a likely scenario where is 1 "smart" PLC node and 10 "dumb" actuator/sensor nodes. You could then configure the "dumb" nodes to node id 1 to 10, then have the PLC listen to COBID 181h, 182h, etc. You'll only need to change COBIDs at at one place, in the PLC. And it's easy to expand and add more nodes. If there was one address pool, you might have been forced to change COBID at both sides.

Now if all of the nodes in that example were both actuators and sensors at once, and each node had the same COBID for TPDO and RPDO, that would be quite a mess. You'd get collisions - keep in mind that data isn't part of the CAN arbitration, so multiple nodes sending the same COBID but with different payload at the same time leads to error frames. That's the only time when there is an actual packet collision on a CAN bus.

Answer 2

The documentation is correct. You can't have two nodes on the bus with the same COB-ID's. RPDO sends message to the COB-ID of the TPDO. That way the TPDO can receive it. The TPDO replies by sending a message addressed to the COB-ID of the RPDO so the RPDO can receive it. The addresses are fixed according to the Profile you are using. If you want to make your own profile you can make the COB-ID's whatever you want. But the downside is that any node on the bus following another standard profile won't work with your bus. So pick a profile and stick to it. That way every node on the bus knows how to handle messages.