CANopen PDO Mapping: TPDO, RPDO and Transmission Types

A PDO is eight bytes of raw process data with no protocol overhead — no index, no sub-index, no length field, nothing that tells you what is inside. The bytes arrive and the consumer is expected to already know what they mean.

That agreement is the PDO mapping. It lives in the object dictionary on both sides, it is written once during configuration, and if the two sides disagree by a single byte, the data still arrives and is still wrong.

This guide covers how the mapping is built, how to change it on a live device, and how the transmission type, inhibit time, and event timer decide when the frame actually goes out. Verified against CiA 301.

Every PDO is two records, not one

Each PDO needs a matched pair of object dictionary records. Miss one and the PDO does not work.

The ranges line up: RPDO1 uses 1400h and 1600h, RPDO2 uses 1401h and 1601h, and so on. TPDO1 uses 1800h and 1A00h. The offset from the base index is the PDO number minus one — obvious once you have seen it, and a constant source of off-by-one errors when you are reading a vendor manual at 2 a.m.

Direction is named from the device’s point of view, not the master’s:

• TPDO — the device transmits. The device is the producer. Inputs, status words, measured values.
• RPDO — the device receives. The device is the consumer. Outputs, control words, setpoints.

So a drive’s control word lands in an RPDO, and its status word comes back in a TPDO. A master that thinks in terms of its own direction will wire the whole thing backwards.

PDOs follow a producer/consumer model, not request/response. One producer transmits, zero or more consumers listen, and nobody acknowledges anything. That is why PDO traffic is fast, and also why nothing tells you when a consumer has stopped listening.

Reading a mapping entry

Each mapping entry is a single 32-bit value. Sub-index 0 of the mapping record holds the number of entries in use; sub-indexes 01h upward hold the entries themselves, in transmission order.

The length field is the one that catches people. It is bits, not bytes. A 16-bit integer is 10h, not 02h.

Take a real entry from a CiA 402 drive:

1A00h sub 01h = 60410010h

  6041h  →  index      →  Statusword
  00h    →  sub-index  →  the object itself, not an array element
  10h    →  length     →  16 bits

Add a second entry and the picture fills out:

1A00h sub 00h = 02h          two objects mapped
1A00h sub 01h = 60410010h    Statusword, 16 bits
1A00h sub 02h = 60640020h    Position actual value, 32 bits

The PDO is now six bytes long: two bytes of status word, then four bytes of position, little-endian, in that order. No padding, no separator. A consumer that expected position first reads garbage that looks plausible enough to pass a quick glance.

Total mapped length cannot exceed 64 bits on classic CAN, because a classic CAN frame carries at most eight data bytes. That is the hard ceiling on a single PDO — and the reason a device that needs to publish a dozen values needs several PDOs, each with its own CAN-ID and its own slot in the bus budget.

Bit-level mapping and dummy entries

Objects shorter than a byte can be packed. Eight one-bit digital inputs mapped as eight entries of length 01h occupy one byte, in order. This is normal for I/O modules and it is why the mapping record allows up to 64 entries.

There is also a padding trick worth knowing. Mapping an entry whose index points at a data type definition (0001h to 0007h — BOOLEAN, INTEGER8, and so on) with sub-index 00h creates a dummy: space is reserved in the frame but the received bytes are discarded. It is used in RPDOs so several devices can consume different slices of the same broadcast frame, each one dummying out the parts belonging to someone else. One transmitter, one CAN-ID, several consumers each picking their own bytes.

Default mapping vs variable mapping

Most devices ship with a default mapping already loaded — for a CiA 402 drive, typically control word in RPDO1 and status word in TPDO1. If the defaults carry what you need, the whole topic disappears: set the node-ID, go operational, done.

Variable mapping is the ability to change it. Support is not universal. Three levels exist in the field:

• Static — the mapping is fixed in firmware. Sub-index 0 is read-only. What you see is what you get.
• Selectable — a small set of predefined mappings, chosen through a manufacturer-specific object.
• Variable — full read/write access to the mapping records. Any mappable object, any order.

Check the EDS file before you plan a configuration. Each object in the EDS carries a PDOMapping flag, and an object with PDOMapping=0 will be rejected no matter how the device is configured. Diagnostic counters, serial numbers, and most communication parameters fall in that group.

The remap procedure

You cannot rewrite a mapping while the PDO is live. The device will refuse, and correctly so — a half-written mapping would put a frame of undefined content on the bus.

The sequence below is the safe one. Every step is an SDO write.

1. Disable the PDO. Set bit 31 of the COB-ID in the communication record (1800h sub 01h for TPDO1) to 1. The PDO is now marked invalid and stops transmitting.

2. Zero the mapping count. Write 0 to sub-index 00h of the mapping record (1A00h sub 00h). This unlocks the entries.

3. Write the entries. Write each 32-bit mapping value to sub-indexes 01h, 02h, and so on, in the order you want the bytes to appear.

4. Restore the count. Write the number of entries to sub-index 00h. The device validates the whole mapping at this point — this is where a bad entry gets rejected, not at step 3.

5. Set the transmission type and timing. Sub-index 02h for the transmission type, 03h and 05h for inhibit time and event timer.

6. Re-enable the PDO. Clear bit 31 of the COB-ID.

7. Store, if you want it to survive. Write the signature 65766173h — ASCII “save”, little-endian — to 1010h sub 01h. Skip this and everything you just did disappears on the next power cycle. Many commissioning sessions have ended with a working machine and an unsaved configuration.

Two notes on state. Configuration is normally done in NMT pre-operational, where SDOs work and PDOs do not exist. Some stacks accept a remap in operational state provided the PDO itself is disabled first, but a device is within its rights to refuse. Pre-operational is the safe default.

And the node-ID: if the COB-ID is derived from the node-ID (the usual case), it can only be changed while the PDO is disabled.

Transmission type: when the frame goes out

Sub-index 02h of the communication record is a single byte, and it changes the character of the whole PDO.

A few things follow from this table that are not obvious.

RPDOs care less than you think. For a receiving PDO, the only real distinction is synchronous or not. With 1–240, incoming data is buffered and applied when the next SYNC arrives, no matter what the number is — the count only sets the transmit rate on the producer side. With 254 or 255, data is applied the moment the frame lands.

254 and 255 usually behave identically. The difference is only where the triggering event is defined: manufacturer’s documentation for 254, device profile for 255. Plenty of devices treat them the same. Read the manual rather than assuming a difference exists.

Type 0 is the useful oddity. Change-of-state data, but delivered inside the synchronous window. The frame goes out only when something happened, and it goes out aligned with SYNC so the master can process a coherent snapshot. Good for alarms and digital inputs on an otherwise synchronous machine.

RTR types are legacy. Remote frames do not exist in CAN FD, and CiA discourages their use in general. Types 252 and 253 appear in old equipment and in device manuals; treat them as something to recognize rather than something to design with.

For synchronous operation to mean anything, a SYNC producer has to exist on the bus. A device set to type 1 with nobody sending SYNC transmits nothing at all, silently, and looks identical to a dead node. If a drive’s TPDO is missing and the electrical side checks out, look for SYNC before you look at the drive.

Inhibit time and event timer

Event-driven PDOs need brakes. A 32-bit analog input mapped to a type-255 TPDO on a noisy signal will transmit on every least-significant-bit flicker and can saturate a segment on its own.

Two parameters control this, and they use different units. This trips up almost everyone once.

Inhibit time sets a floor on the interval. It is a transmit filter: the first change goes out immediately, and anything arriving inside the inhibit window waits. It does not slow down the reaction to a fresh event, only to the ones piling up right behind it.

Event timer sets a ceiling. If nothing changes, the PDO is transmitted anyway when the timer expires. That gives the master a heartbeat on the data itself, so a stalled value can be told apart from a stalled device.

Used together they bound the interval on both sides. A TPDO with inhibit time 100 (10 ms) and event timer 1000 (1 s) transmits at most every 10 ms and at least once per second — regardless of how the signal behaves.

Both parameters apply only to transmission types 254 and 255. Set them on a synchronous PDO and they are ignored. And on an RPDO, sub-index 05h changes meaning entirely: it becomes a deadline monitor, an expected-arrival timeout that raises an error if the frame does not turn up in time. Same sub-index, opposite job.

Sub-index 06h, the SYNC start value, appears on TPDOs only. Set to 0 the SYNC counter is ignored. Set to a value in 1–240, the device waits until it sees a SYNC message carrying that counter value before beginning its cycle — which is how you stagger a group of synchronous TPDOs across different SYNC ticks instead of having them all fire on the same one.

The COB-ID word

Sub-index 01h holds a 32-bit word, and only the bottom eleven bits are the CAN identifier. The top bits are control flags.

Bit 31 is inverted relative to intuition: zero means the PDO is in use. A COB-ID of 80000182h is not an error. It is TPDO1 on CAN-ID 182h, disabled.

This bit is also the reason a device with more than four TPDOs ships with most of them disabled. The predefined connection set only assigns default identifiers to the first four PDOs in each direction. The rest exist in the object dictionary, fully formed, but marked invalid until someone assigns them an identifier.

The default identifiers are worth committing to memory, because they let you read a bus trace without a decoder:

Node 5’s TPDO1 is 185h. An unexpected 205h on the bus is somebody’s RPDO1 for node 5 — which means somebody is writing to that node, and it is worth knowing who.

If you have a trace and want the fields broken out without doing the arithmetic, the CANopen message decoder takes raw candump or PCAN output and splits out the function code, node-ID, and payload.

Sizing the bus before you map

Mapping decisions are bus load decisions. A rough frame budget takes thirty seconds and prevents a class of problem that is very unpleasant to diagnose later.

A classic CAN data frame with an 11-bit identifier and eight data bytes is 111 bits including the interframe space. Bit stuffing adds up to about 24 more in the worst case, so budget roughly 135 bits.

Keep steady-state load below about 30%. CAN degrades gracefully at moderate load and badly at high load: arbitration is priority-based, so a saturated bus does not slow down uniformly, it starves the high-numbered identifiers while the low-numbered ones stay fine. The symptom is one device that seems to work perfectly and another, on the same bus, that intermittently misses data.

Worked example. Ten drives, each with one synchronous TPDO of eight bytes at every SYNC, SYNC period 10 ms, bus at 500 kbit/s:

10 TPDOs + 1 SYNC frame per cycle
≈ 10 × 270 µs + 50 µs  ≈  2.75 ms per 10 ms cycle
≈ 27.5% load — before any SDO traffic, emergencies, or heartbeats

That is already at the practical limit. Adding a second TPDO per drive pushes it past 50%, and the answer is not to shorten SYNC — it is to move to 1 Mbit/s, cut the mapped payload, or run some TPDOs on every second SYNC using transmission type 2.

That last option is the one people forget. Not everything needs to arrive at the same rate. Position feedback might genuinely need every cycle; temperature does not.

What goes wrong in the field

Mapping failures announce themselves through SDO abort codes. The common ones:

Beyond the aborts, four failure patterns cover most of what you meet on site.

Data arrives, values are nonsense. The two sides disagree on the mapping. Count the bytes: master’s expected total against the device’s sub-index 0 entries. A length field written in bytes instead of bits produces exactly this, and the frame length gives it away — a PDO you expected to be six bytes shows up as two.

Nothing transmits, device is otherwise healthy. Check three things in order: is the node in operational state, is bit 31 of the COB-ID clear, and — for synchronous types — is anyone producing SYNC.

Works on the bench, fails on the machine. Bus load. The bench had two nodes; the machine has fifteen. Look at the identifier of what is failing and check whether it is losing arbitration.

Works until power cycle. 1010h was never written. The mapping was correct and never stored.

Two nodes with the same PDO identifier. Duplicate node-IDs, usually from a DIP switch nobody rechecked after a spare was swapped in. Two devices transmit on the same CAN-ID, both believe they own it, and the resulting traffic is a mixture of both. The bus stays electrically healthy, which is what makes it confusing.

FAQ

What is the difference between TPDO and RPDO?

Direction, from the device’s perspective. A TPDO is transmitted by the device — inputs, status, measured values. An RPDO is received by it — outputs, control words, setpoints. A master’s RPDO connects to a slave’s TPDO, so the naming inverts depending on which end of the link you are reading.

How many objects can be mapped into one PDO?

As many as fit in 64 bits on classic CAN. That is one 64-bit object, or eight bytes, or 64 single-bit objects, or any combination up to the limit. The mapping record supports up to 64 entries for exactly that reason.

Why does my PDO transmit nothing?

Most often one of three causes: the node is not in NMT operational state, bit 31 of the COB-ID is set (marking the PDO invalid), or the transmission type is synchronous and no SYNC producer exists on the bus. All three produce total silence rather than an error message.

Do I have to be in pre-operational state to remap?

That is the safe answer and what most stacks expect. Some devices allow remapping in operational state provided the PDO is disabled through bit 31 of the COB-ID first, but this is optional behavior — a device that refuses is not misbehaving.

What units are inhibit time and event timer?

Inhibit time is in multiples of 100 µs, event timer in multiples of 1 ms. A value of 100 means 10 ms for the inhibit time and 100 ms for the event timer. Mixing them up is the single most common timing error in CANopen configuration.

Why is my mapping lost after a power cycle?

It was never saved. Write the signature 65766173h to 1010h sub 01h after configuration, then confirm the write succeeded. Some devices restrict saving to particular states or need a reset afterward for the stored values to take effect.

Can I map any object into a PDO?

No. Each object carries a mapping flag, visible in the EDS file as PDOMapping. Objects with the flag clear — most communication parameters, diagnostic counters, identity data — are rejected with abort code 06040041h. Check the EDS before planning, not after.

What is transmission type 0 for?

Change-of-state data delivered on the synchronous grid. The PDO is transmitted only when an event has occurred, but it waits for the next SYNC to go out. Useful for digital inputs and alarms on a machine that is otherwise running synchronously, since it keeps event data inside the same coherent snapshot as everything else.