Process Data Objects - CANopen - How do they work?

Question

I'm searching for information about PDO and the protocol CiA 301 V4.2.0 at topic 7.2.2.5.1 does not exactly show how PDO's work. Every PDO contains 8 bytes of data.

I know that there are 4 different PDO's.

PDO TX 1 - COB ID = 0x180 + Node ID
PDO RX 1 - COB ID = 0x200 + Node ID
PDO TX 2 - COB ID = 0x280 + Node ID
PDO RX 2 - COB ID = 0x300 + Node ID
PDO TX 3 - COB ID = 0x380 + Node ID
PDO RX 3 - COB ID = 0x400 + Node ID
PDO TX 4 - COB ID = 0x480 + Node ID
PDO RX 4 - COB ID = 0x500 + Node ID

I know that there are 4 different methods to call for the PDO service. The frist method is executed when for example a variable changes. The second method is when remote frame is transmitted from the consumer to the producer. Please, let me know what remote frame is. The third method is when the producer got a SYNC request from the consumer. The fourth method is when the producer it self send to the consumers on a fixed time event.

This is what I know about the PDO's. So here is my questions:

Question 1:

The PDO communiation parameters for both transmit and receive can be stored inside the Object Dictionary. For changing those, I need to use SDO - Service Data Objects.

I know what sub idex 02h means. It select which type of method the node is going to use to produce or receive the PDO message.

But what does sub inde 01h mean? I'm looking at the documention and it only says this. Does this mean I can checkmark if the PDO of that specific node should be active or not? Which node ID should I place there?

Question 2:

If I want to send data from a producer to a consumer with the PDO1 channel. I first need to select wich type of transmission type. Assume that I select this transmision type. For every 240 SYNC message from the consumer to the producer, send a PDO message to the consumers?

Question 3:

Each PDO contains 8 bytes of data. When I got a PDO message with the COB ID = 0x200 + 0x2 from the node 0x2, should I save the 8 bytes of data into the Object Dictionary? If yes, where?

Question 4:

What should I use PDO RX and PDO TX for, if there is only one way communication? I mean, the consumers sends a request to the producer e.g via SYNC message. SYNC service is not PDO. Then when the producer have got e.g X SYNC's, then the producer sends out a PDO message to the consumers. Why use RX and TX here? Why not only use TX?

Summation:

1. What does COB ID mean in sub index 01h for the communication objects? What should I write there for both TX and RX communication objects of PDO?
2. SYNC is a method for the consumers to count until the producer is going to send 8 bytes of data to the consumers?
3. When a consumer got the PDO message of 8 bytes, then it going to store that into the Object Dictionary? If yes, which index and sub index?
4. Why use RX when the producer only using TX when it sends PDO's to the consumers?

Answer 1

Every PDO contains 8 bytes of data.

In general, they can contain up to 8 bytes of data, but they don't have to. PDOs are the only messages in CANopen that can have a smaller DLC than 8.

I know that there are 4 different PDO's.

Depends on Device Profile. If you are using something like for example CiA 401 generic I/O module, then it has a certain amount of standardized PDOs. But a manufacturer can add more - they just won't be enabled from start.

Please, let me know what remote frame is

A remote request frame (RTR). This is a concept of the underlaying CAN data link layer, which you need to know before you can work with CANopen.

But what does sub index 01h mean?

The "valid" bit can be used to enable/disable a supported PDO. You have to set this one when the node is in pre-operational mode, you can't set it in operational mode.

The RTR bit is what it says, enable/disable RTR requests for this PDO by an external node.

In case of the standardized PDOs like those you listed, they are enabled by default and accept RTR by default. Manufacturer-specific PDOs like I mentioned above are not enabled by default.

Assume that I select this transmision type. For every 240 SYNC message from the consumer to the producer, send a PDO message to the consumers?

Yes.

Each PDO contains 8 bytes of data. When I got a PDO message with the COB ID = 0x200 + 0x2 from the node 0x2, should I save the 8 bytes of data into the Object Dictionary? If yes, where?

Each PDO is just a "box" where you map data stored elsewhere. In case dynamic PDO mapping is supported, you can even change which data that is stored where on the fly. For the standardized PDOs they have mapping parameters stored at default locations such as 0x1A00 for TPDOs. In case of static PDO mapping (which is in my experience the most common), then the mapping parameter are read-only.

These mapping parameters in turn point at the actual data store, which is also standardized at addresses such 0x6000, 0x6200 etc. I'd advise to look at CiA 401 generic I/O module for examples. Basically you can have something like a digital on/off stored at 0x6000:01, which is mapped into TPDO1 (0x180+node id) through the mapping parameter 0x1A00.

This also means that you can actually access the "raw" data at address 0x6000 with SDO access as well.

What should I use PDO RX and PDO TX for

One node's TPDO is another node's RPDO. So if you have a TPDO 0x181 which is sent out after receiving SYNC, the node which is interested in that data has to change one of the RPDO COBID to 0x181. The COBID listed by CANopen are just the default settings. You have to pair nodes together manually, by changing COBID (and optionally mapping parameters etc).

Answer 2

EDIT: I'd like to point the audience to Lundin's response - clearly more precise, better informed and delivered with authority :-) Glad to have learned some interesting details. I'm leaving the rest of my message "as is", in spite of some b.s.

Standard low-level CAN works like this:

• at the bus level, there are no apriori masters vs slaves
• anyone can transmit anything he wants
• anyone who has received the message should give an ACK
• feel free to use the bus in a producer-consumer fashion if you will
• the CAN ID indicates "the sort of data" being provided - need not necessarily mean / encode a node address, more like a "multicast group" or a TCP/UDP well-known port number, but possibly "to the world at large".

CANopen, on top of CAN, adds further rules:

• there is a single bus master to rule the slaves (i.e., there is a distinction between a master and a slave) and there are node addresses, but, the transfers are not "request-response" fashion (Modbus style). Rather, the slaves can also talk to each other. Or rather, each slave speaks or listens as configured (as configured by the master).
• to implement routine process data transfers, CANopen has the PDO's. I understand that TPDO's are "a node's TX", RPDO's are "a node's RX" (i.e. not from the bus master's perspective, somebody correct me if I'm wrong.)
• multiple nodes can probably listen (RPDO) to a single slave transmitting (TPDO).
• the slaves come equipped with an object dictionary. Via the object dictionary, the PDO's get configured.
• to access the slaves' object dictionaries, CANopen has SDO's. This is a master/slave request/response protocol - originally intended to configure the PDO's in a particular slave, but some vendors (ab)use them for payload transfers too...
• RTR is a mechanism for the master to solicit the transmission (TPDO) from a particular slave node (as we have node addresses). So this is closest to a "request-response" traffic pattern, in terms of the PDO's.
• SYNC is a message optionally transferred by the master, which essentially means "whatever it is that you guys are configured to do, now's the time". If a slave is configured to transmit something, that's what he should do. The original meaning of the message apparently is "tick tock, I'm the clock on this bus" = it's intended for time sync, and it is supposed to be transmitted periodically.

To answer your questions:

1. the COB ID inside an object dictionary entry (sub-index 01) likely means the "local offset of this PDO" within a node (i.e. not including the node ID). It allows you to customize the local offset of a particular data object.

2. SYNC is one way of triggering PDO transfers. Originally it is just a periodic time sync message. I can imagine scenarios where slave nodes transmit every N-th sync, or use the SYNC to align their timebase but actually trigger their transmissions shifted in time (as a way of avoiding the transmission priority arbitration) etc.

3. I believe that within a node, the local storage for PDO payload data is left up to the implementor of the node firmware. It may certainly be internally interlinked/referenced with the "object dictionary" data metastructures, or it can be some fixed allocation, or it can belong to the application-specific (proprietary) data processing engine in the node's firmware = whatever it is that the CANopen node does for a living :-) Remember: PDO's are for the bread and butter. SDO's and the Object Dictionary are there to configure the PDO's (addressing offsets and other properties, as you have noticed). Local PDO payload data storage isn't a standard part of the Data Dictionary.

4. the sense and purpose of distinguishing RPDOs vs. TPDOs: clearly these refer to the "direction" of the data flow. Apparently, withing CANopen, from the perspective of a particular bus node, a particular PDO can either serve for TX to the bus, or for RX from the bus. Not both at the same time (unlike other technologies, where you can "write" a particular datapoint and then read the value back). The bus master can use the slaves' object dictionaries (by means of SDO) to "splice" their TPDO's and RPDO's to interconnect data flows between the nodes.

I've seen partial implementations of CANopen-like CAN nodes that e.g. use PDO-style addressing, but do not have an Object Dictionary. I've also seen nodes where payload traffic is implemented by SDO's. I've seen nodes that do not support SYNC or RTR. Note that a node can transmit a TPDO based on custom criteria, principally "at its own discretion" - as required by the application, ot as programmed "out of band". I've seen a CANopen master interface for a PLC, where the PDO transfers flow "seamlessly" into the PLC's process data memory space (table of datapoints = there's your payload storage), and SDO transfers can be triggered explicitly by the PLC's program (via function blocks)...

You have my thumbs up for asking all the right questions :-) It never hurts to become fluent in the native principal concepts of a particuar bus technology... if only there weren't so many different fieldbus technologies out there :-)

Answer 3

Disclaimer: I have tried and partially succeeded developing & implementing a CANopen stack on a STM32, but apart from some initial test, I've never properly test it on field or on a real product. It has been some years, so my memories may be inaccurate.

What does COB ID mean in sub index 01h for the communication objects? What should I write there for both TX and RX communication objects of PDO?

COB-ID represents the hard CAN identifier on the wire. For transmitters, well, this is the ID they use when emitting PDOs on the bus, where each PDO has its own distinct COB-ID. For receivers, these are the CAN IDs they look for on the bus. CAN controllers can filter out the messages they are not interested in. So, a typical implementation configures its hardware filters according to RPDO COB-IDs (and of course SDO & other messages), then process RPDOs according to their COB-IDs.

SYNC is a method for the consumers to count until the producer is going to send 8 bytes of data to the consumers?

For producers (TPDO), SYNC serves as a "sample inputs" command. As the SYNC is broadcast to all nodes, all producers can sample their inputs at the same time. Then they all try to send their TPDOs. The produced data will have some delays before they arrive their destination, but they all belong to the same time instant. Some producers may need to sample & send their TPDOs less often, so they do so on every nth SYNC.

For consumers (RPDO), SYNC serves as a "update outputs" command. RPDOs may arrive on different times, but all the outputs on the system/bus will be updated when the SYNC arrives (after the RPDOs). If I remember correctly, SYNC counter isn't used for RPDOs, but I may be wrong.

When a consumer got the PDO message of 8 bytes, then it going to store that into the Object Dictionary? If yes, which index and sub index?

There are some PDO Mapping Parameters on object dictionary (OD). It's some kind of table where it lists RPDO COB-IDs and index-subindex pairs associated with 8 bytes that RPDO contains. On some simpler devices, these are hard-coded. On others, these can be configured using SDO transfers.

Why use RX when the producer only using TX when it sends PDO's to the consumers?

The PDO - COB-ID table you mentioned is just a default one to prevent collisions on a bus with maximum number of nodes and each using 4 TPDO & 4 RPDO. But, there can be less nodes in the bus, some nodes may need more or less PDOs. The unused COB-IDs can be assigned for different purposes, for example as a PDO TX 5. Actually, you are not required to follow that numbering scheme and may assign COB-IDs as you see fit. Just remember that there can be only one transmitter on the bus for a given COB-ID.