CANopen moves data in two very different ways, and the split matters for anyone integrating it. Process Data Objects, or PDOs, are fast, lightweight messages that carry real-time values without confirmation, ideal for cyclically or event-driven exchange of live data. Service Data Objects, or SDOs, are slower, confirmed transfers that can reach any entry in a node's object dictionary, which makes them the tool for configuration and occasional access. A PDO is limited to eight bytes and is mapped in advance; an SDO can move larger amounts but with more overhead. Knowing which to use decides whether a gateway is polling live values or setting a node up.
CANopen PDO vs SDO in one line: A CANopen PDO (Process Data Object) is a fast, unconfirmed message that carries up to eight bytes of real-time process data, sent cyclically or on an event. A CANopen SDO (Service Data Object) is a slower, confirmed transfer that can read or write any object-dictionary entry, used for configuration and occasional access. PDOs are for live values; SDOs are for setting a node up and reaching individual parameters.
Process Data Objects are built for speed. A PDO is a single message carrying up to eight bytes of application data, sent without any acknowledgement, which is what makes it fast and efficient. PDOs are used for the values that need to flow continuously during operation: sensor readings, actuator commands, status words and the like. They can be triggered cyclically on a timer, on an event when a value changes, or in response to a request, so the data keeps up with the process without the overhead of a confirmed exchange.
The eight-byte limit is a defining constraint, and it is why PDO mapping exists. Because a PDO has only eight bytes to work with, an engineer configures which object-dictionary entries are packed into those bytes, and in what order, so that the most useful values ride together in one message. This mapping is set up in advance, during configuration, and it is what turns a raw eight-byte PDO into a meaningful bundle of, say, a couple of measurements and a status word. Once mapped, the PDO efficiently delivers exactly those values every time it is sent.
Each PDO is identified on the bus by a COB-ID, a communication object identifier that determines the message's identity and priority. The COB-IDs for a node's PDOs are configured so that producers and consumers agree on which message carries which mapped data. This arrangement lets a controller or gateway recognise an incoming PDO purely from its identifier and immediately interpret its bytes according to the agreed mapping, with no addressing overhead inside the message itself, which is a big part of why PDOs are so lightweight.
Service Data Objects take the opposite approach, trading speed for reach and reliability. An SDO is a confirmed transfer: the requester asks to read or write a specific object-dictionary entry, and the node replies, so both sides know the operation succeeded or failed. This handshaking makes SDOs slower and heavier than PDOs, but it also makes them dependable for the kind of access where getting it right matters more than getting it fast. An SDO can also move data larger than eight bytes by splitting it across multiple messages, so it is not bound by the PDO size limit.
The great strength of an SDO is that it can reach any entry in the object dictionary, addressed by its index and subindex. Where a PDO is limited to the handful of values that were mapped into it ahead of time, an SDO can pick out any single parameter on demand, whether or not it was ever part of a PDO. That makes SDOs the natural mechanism for configuration: setting communication parameters, adjusting device-specific settings, or reading a value that is only needed occasionally rather than continuously.
This is why SDOs and PDOs are complementary rather than competing. During commissioning, a tool uses SDOs to write all the settings a node needs, including the PDO mappings and COB-IDs themselves, effectively using SDOs to configure how the PDOs will behave. Then during operation, the fast PDOs carry the live data while SDOs stay available for the occasional deeper read or write. The two together give CANopen both the real-time performance of unconfirmed process data and the thorough, reliable access of confirmed parameter transfers.
For a monitoring gateway feeding a cloud SCADA system, the PDO-versus-SDO distinction maps neatly onto two different jobs. To bring live operational values upward, the gateway generally wants the fast, low-overhead flow of PDOs, since those are the messages already carrying the real-time measurements and status the nodes produce during normal running. Consuming the mapped PDO data lets the gateway keep dashboards current without loading the bus with a stream of individual confirmed requests.
SDOs come into play for the values and settings that are not part of the regular PDO flow. If an operator wants a parameter that no PDO carries, or the gateway needs to read a node's configuration or occasionally write a setting, an SDO is the right tool because it can address any object dictionary entry directly. The trade-off is that SDO access is heavier, so it is used sparingly for these on-demand or setup tasks rather than as the backbone of live monitoring.
A well-designed integration with a platform like Merobix therefore uses each mechanism for what it is good at: PDOs to stream the continuously changing process values that populate live trends and alarms, and SDOs to reach configuration or occasional parameters when needed. Understanding this split helps an integrator plan a gateway that keeps the fast data path efficient while still being able to reach anything in a node's object dictionary, so the cloud view is both timely for live values and complete when a deeper read is required.
A PDO is a fast, unconfirmed message carrying up to eight bytes of real-time process data, sent cyclically or on an event. An SDO is a slower, confirmed transfer that can read or write any object-dictionary entry, used for configuration and occasional access. PDOs are for live values; SDOs are for setup and individual parameter access.
Because a PDO carries only eight bytes, PDO mapping is the configuration that decides which object-dictionary entries are packed into those bytes and in what order. It is set up in advance so a single PDO delivers a useful bundle of values, such as a couple of measurements and a status word, efficiently every time it is sent.
Generally PDOs, because they carry the real-time process data efficiently with no per-message addressing overhead, keeping live dashboards current. SDOs are reserved for values not carried in any PDO and for reading or writing configuration, since their confirmed access is heavier and better suited to occasional, on-demand use.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.