1

I'm pretty new to canbus and CANopen and can't seem to wrap my head around PDOs. I understand that a PDO must be defined and agreed upon ahead of time, and that multiple OD entries can be packed into a single PDO. What I'm not understanding is how only 4 PDOs could possibly be useful when a node can presumably have dozens of unique data it wants to be able to send.

An example to illustrate what I'm struggling with:

Say I have a network with 4 nodes. Each node is an environmental sensor that wants to broadcast temperature, humidity, air pressure, and ambient light (all 32 bit values). I can pack this data into 2 PDOs (let's call them PDO1 and PDO2. From what I understand these devices could send this data using COB ID 0x181-0x184 and 0x281-0x284 for PDO1 and PDO2 respectively with the bottom 7 bits indicating which device sent the data. Anyone receiving this data could look up the PDO definition to understand how to interpret the data and use the 7 LSB to know who sent it.

Hopefully so far so good.

Now let's say I want to add 2 more, unique devices- call it a power management device and an IMU- each with their own two, unique PDOs. At this point I have a total of 6 unique PDOs I want to be able to send and from my understanding this is not possible.

Again I'm not experienced with can but this contrived network seems extremely basic to me, yet it cannot be supported. Is CANopen just not meant to support many different types of devices or unique data? I can easily imagine even a single device wanting to send more than 4 PDO worth of data.

Note: I have seen reference to being able to support up to 512 PDOs so I suspect I'm missing something fundamental but I'm not sure what it is.

Otus
  • 167
  • 5
  • I think you are mixing up the general requirements of CANopen (the communications protocols) with one of the standardized _Device Profiles_ also part of CANopen. For example the Device Profile for "generic GPIO unit" defines a number of default PDOs. But even in such applications you can add more custom ones - the requirement (from Cia 401 "generic I/O) is just that they aren't enabled out of the box. – Lundin May 02 '23 at 09:55

1 Answers1

4

What I'm not understanding is how only 4 PDOs could possibly be useful when a node can presumably have dozens of unique data it wants to be able to send.

You're not limited to only 4 PDOs. The CANopen standard defines 4 default RPDOs and TPDOs.

The default PDO communication parameters are:

  • RPDO1: object 0x1400
    • default CAN-ID: 0x200 + NodeID
  • RPDO2: object 0x1401
    • default CAN-ID: 0x300 + NodeID
  • RPDO3: object 0x1402
    • default CAN-ID: 0x400 + NodeID
  • RPDO4: object 0x1403
    • default CAN-ID: 0x500 + NodeID
  • TPDO1: object 0x1800
    • default CAN-ID: 0x180 + NodeID
  • TPDO2: object 0x1801
    • default CAN-ID: 0x280 + NodeID
  • TPDO3: object 0x1802
    • default CAN-ID: 0x380 + NodeID
  • TPDO4: object 0x1803
    • default CAN-ID: 0x480 + NodeID

Apart from these default PDOs, you can implement up to 512 RPDOs and 512 TPDOs per device. The ranges 0x1404..0x15FF and 0x1804..0x19FF are reserved for manufacturer specific RPDOs and TPDOs, respectively.

From what I understand these devices could send this data using COB ID 0x181-0x184 and 0x281-0x284 for PDO1 and PDO2 respectively

The COB-IDs 0x181..0x184 are the default TPDO1 CAN-IDs for nodes 1 to 4. And COB-IDs 0x281..0x284 are the default TPDO2 CAN-IDs for nodes 1 to 4.

An important thing to note: you're not limited to use the default CAN-ID scheme (eg. 0x180 + NodeID for TPDO1, etc.). You may configure any CAN-ID in the range 0x180 .. 0x57F for any RPDO or TPDO.

Another thing to note: you can map any TPDO to any RPDO of multiple CANopen devices. If a device doesn't need all data mapped into the specific TPDO, it can configure RPDO dummy mappings to ignore certain parts of said TPDO.

EDIT 1

Going back to the environmental sensor. Let's say I've now defined two custom TPDOs for the data that I want these sensors to be able to share. How do I differentiate between PDOs I receive from different devices?

PDOs are differentiated by their CAN-ID. You can map a TPDO of one device to an RPDO of multiple other devices. You just have to make sure the RPDO COB-IDs match the TPDO COB-ID.

As an example, let's assume you've configured a TPDO with a COB-ID of 0x181. You can now configure multiple other CANopen devices to have an RPDO COB-ID of 0x181. This means said TPDO will be mapped to all other devices having an RPDO configured to have the same COB-ID as the TPDO.

Do I need to manually reserve N addresses between each PDO to allow for the node ID of each node to be added? In that case, the more nodes I have, the fewer PDOs I can represent? Is that correct? For example, with a full bus of 127 devices, only 8 PDOs (4 default + 4 custom) could be supported by all of them?

You have a total number of 512 RPDOs and 512 TPDOs per device. But overall the PDO COB-ID range spans 0x180..0x57F, which means there is a system-wide number of 1024 PDOs. These have to be shared among all 127 devices. Theoretically, if two devices use up 512 TPDOs each, there won't be any TPDOs left for subsequent devices.

If the 1024 TPDOs containing 8 bytes each isn't sufficient, you might want to consider upgrading your CAN bus to CAN FD.

EDIT 2

Just to be abundantly sure- if I have a device that I want to transmit 16 x 64-bit values using PDO, this would require 16 PDO addresses. Now if I wanted to deploy many of these devices on the same network, I would be limited to supporting (512/16=) 32 devices. Is that correct?

First of all, I had to correct a mistake above. Per device you can configure up to 512 TPDOs and 512 RPDOs. But system-wide you have 1024 TPDOs and 1024 RPDOs (range: 0x180..0x57F) available.

If each device uses 16 transmit PDOs (16 x 64-bit), you could support up to (1024/16=) 64 devices.

The question is, do you really need to transmit all 16x 64-bit values using PDO, or is it possible to partially use the SDO protocol?

It seems like a lot of careful planning is required to define the OD and PDO mapping for each device to ensure none overlap and that the host is mapping each to an RPDO. Can you recommend any resources to learn about how this is done?

If it's really this straightforward, so that each device uses 16 TPDOs, I'd keep it simple and assign COB-IDs 0x180..0x18F to node 1, 0x190..0x19F to node 2, ... 0x570..0x57F to node 64. The RPDOs have to be configured appropriately, to whichever devices needs the TPDOs.

For questions regarding the CANopen application layer and communication profile, I always consult CiA 301.

Velvel
  • 3,591
  • 3
  • 12
  • 30
  • 1
    Other things to think about is the total bus loading, and the transmission types of the PDOs -- if you have data that seldom changes, or only want to look for changes, you can adjust the transmission type of the PDO accordingly to save on bus load. As the data amount you want to send increases, you may have to increase bus speed and mess with the transmission types to get it all to fit. – Krunal Desai Apr 28 '23 at 11:45
  • @KrunalDesai Yes, you could fill a whole chapter on CANopen PDO communication. – Velvel Apr 28 '23 at 12:05
  • Thanks, that helps a bit but also raises some other questions. Going back to the environmental sensor. Let's say I've now defined two custom TPDOs for the data that I want these sensors to be able to share. How do I differentiate between PDOs I receive from different devices? Do I need to manually reserve N addresses between each PDO to allow for the node ID of each node to be added? In that case, the more nodes I have, the fewer PDOs I can represent? Is that correct? For example, with a full bus of 127 devices, only 8 PDOs (4 default + 4 custom) could be supported by all of them? – Otus Apr 28 '23 at 15:58
  • Thanks, that helps. Just to be abundantly sure- if I have a device that I want to transmit 16 x 64-bit values using PDO, this would require 16 PDO addresses. Now if I wanted to deploy many of these devices on the same network, I would be limited to supporting (512/16=) 32 devices. Is that correct? It seems like a lot of careful planning is required to define the OD and PDO mapping for each device to ensure none overlap and that the host is mapping each to an RPDO. Can you recommend any resources to learn about how this is done? – Otus May 02 '23 at 01:02
  • @Otus "It seems like a lot of careful planning is required" This is always the case with CAN bus, CANopen is no exception. It's often used a hard real-time system and as such you need to have full control of whatever is sent on the bus and when. In case on CANopen specifically, you'll want to put most of the adaptation in one single "smart node" (often the one also acting as NMT master such as a PLC), and then configure up all "dumb" slaves using SDO access during boot-up. That way you only have to set the node id on the slave and then it's ready to go. – Lundin May 02 '23 at 10:02