EtherCAT PDO Size Calculator

This free EtherCAT PDO size calculator totals the cyclic process data on your EtherCAT network before you check it against a cycle time. Group your slaves — drives and servos, remote I/O, and everything else — enter how many of each you have and the combined receive and transmit PDO bytes per device, and it returns the total payload, the RxPDO/TxPDO split, the payload serialization time at 100 Mbit/s, and the payload bandwidth at your cycle time. It's for controls engineers mapping a new EtherCAT segment, adding slaves to an existing line, or feeding a real byte total into a cycle-time budget. No account, no spreadsheet — the formula is shown below.

▤

Add common EtherCAT device groups and estimate total cyclic RxPDO and TxPDO data.

Groups devices for quick planning and treats the entered bytes as total cyclic RxPDO + TxPDO payload per device. The RxPDO percentage splits that payload directionally. Serialization shows payload-only wire time at 100 Mbit/s and excludes Ethernet/EtherCAT framing and slave propagation.

The formula

The calculator builds the network's cyclic payload from the bottom up — device groups first, directions second, wire numbers last:

Total cyclic payload (bytes per cycle)
  B_total = (N_drive × B_drive) + (N_IO × B_IO) + (N_other × B_other)
  (each B is that device's combined RxPDO + TxPDO bytes per cycle)

Directional split
  B_Rx = B_total × (S_Rx ÷ 100)
  B_Tx = B_total − B_Rx

Payload serialization at 100 Mbit/s
  T_ser = B_total × 0.08 µs per byte

Payload rate at the selected cycle
  R = B_total × 8 × (1,000,000 ÷ T_cycle) ÷ 1,000,000      Mbit/s

Variable	Meaning	Where it comes from
N_drive, N_IO, N_other	How many slaves in each group: drives/servos, remote I/O devices, other slaves	Your network design
B_drive, B_IO, B_other	Combined cyclic RxPDO + TxPDO bytes per device in that group — both directions added together	Each slave's PDO mapping in the configurator (or its ESI defaults); the number one device exchanges every cycle
S_Rx	Share of the total payload that is RxPDO, in percent	Your mappings; 50% (an even split) is the calculator's starting point
T_cycle	The cycle time the payload repeats at, in µs	Your application requirement; the same target you use in the EtherCAT Cycle Time calculator
B_total	Total cyclic PDO payload, in bytes per cycle	The sum this calculator builds — and the main input to the EtherCAT Cycle Time calculator
T_ser	Payload serialization time — how long the payload alone occupies the wire at 100 Mbit/s	B_total × 0.08 µs
R	Payload rate — the payload expressed as bandwidth at the selected cycle	B_total × 8 bits, repeated at the cycle rate

Why the constants: at 100 Mbit/s a single bit takes 0.01 µs on the wire, so one byte takes 0.08 µs — serialization scales with total bytes only, not with slave count or topology. And the rate is just the payload re-expressed per second: the same 536 bytes are 4.29 Mbit/s of payload at a 1 ms cycle and 17.15 Mbit/s at 250 µs, because the identical payload is being sent four times as often. Both figures are payload-only by design — Ethernet/EtherCAT frame overhead, slave forwarding delay, and cable propagation are deliberately excluded here and priced in by the EtherCAT Cycle Time calculator, which is where B_total goes next.

What each input means

Every field below is exactly as it appears in the live calculator (labels and defaults verified in source). The byte fields take the device's combined RxPDO + TxPDO total — if a datasheet or configurator lists the directions separately, add them before entering.

Input	Unit	Default	What breaks if you get it wrong
Drives / servos (qty)	count	6	The drive group usually dominates the payload. A wrong count scales the largest per-device figure on the page
Rx + Tx bytes / drive	bytes per cycle	64	The classic error: entering the per-direction size (e.g. 32 B each way) instead of the combined 64 B halves the drive total. Include every mapped object — control/status words, targets, actual values, and any safety (FSoE) bytes the mapping carries
Remote I/O devices (qty)	count	4	Count couplers/stations as the devices they are on the network, with their terminals' data totalled into the bytes field — not each terminal as its own device with its own overhead guess
Rx + Tx bytes / I/O device	bytes per cycle	32	Analogue channels add up fast (2 bytes per channel per direction is typical before status bytes). Counting only the inputs and forgetting the output channels understates the device
Other slaves (qty)	count	2	The catch-all group: encoders, gateways, measurement and safety slaves that aren't drives or remote I/O. Leaving a gateway out drops its whole mapped payload, not just a header
Rx + Tx bytes / other slave	bytes per cycle	12	Small per device, but gateways can map far more than 12 B. Use the mapping, not the default, for anything protocol-converting
Share that is RxPDO (%)	% (0–100)	50	Only affects the split, never the total, serialization, or rate. A wrong share doesn't break the sizing — but it will mislead anyone using the split figures directionally (see FAQ 2 for which direction is which)
Cycle time (µs)	µs (min 1)	1000	Only affects the payload rate, not the byte total. Quoting a bandwidth without its cycle time is meaningless — the same payload is 4× the rate at 250 µs that it is at 1 ms

Worked example

Scenario: a packaging machine's EtherCAT segment — six servo drives, four remote I/O stations, and two other slaves (an encoder interface and a gateway). The inputs below are the calculator's own starting values, so you can reproduce this example exactly by opening the calculator and pressing "Calculate PDO load" without changing anything.

Inputs (the calculator's defaults):

Drives / servos: 6, at 64 Rx + Tx bytes each
Remote I/O devices: 4, at 32 Rx + Tx bytes each
Other slaves: 2, at 12 Rx + Tx bytes each
Share that is RxPDO: 50%
Cycle time: 1000 µs (1 ms)

Step by step:

Drives: 6 × 64 = 384 B
Remote I/O: 4 × 32 = 128 B
Other slaves: 2 × 12 = 24 B
Total cyclic PDO payload: 384 + 128 + 24 = 536 B
Directional split at 50%: RxPDO = 536 × 0.50 = 268 B, TxPDO = 536 − 268 = 268 B
Payload serialization: 536 × 0.08 = 42.88 µs (the result panel shows this as 42.9 µs)
Payload rate: 536 × 8 × (1,000,000 ÷ 1000) ÷ 1,000,000 = 4.288 Mbit/s (shown as 4.29 Mbit/s)

The calculator's verdict for these inputs reads: "Use the total cyclic payload as an input to the EtherCAT Cycle Time calculator, then add real frame, slave, cable, master, and application timing."

What the example shows: the drives are 384 of the 536 bytes — 72% of the payload — so this network's data budget is set in the drive mappings, not the I/O. Two sensitivities worth knowing. First, the cycle time changes the rate but not the wire time per trip: the same 536 B payload at a 250 µs cycle is 17.15 Mbit/s of payload (four times the 1 ms figure), while serialization stays 42.9 µs per cycle. Second, per-device bytes are the strong lever on the total: doubling the drive mapping to 128 B per drive takes the total to 920 B, serialization to 73.6 µs, and the 1 ms payload rate to 7.36 Mbit/s. Either way, 536 B sits comfortably inside a single Ethernet frame — the point where that stops being true is covered in FAQ 5.

What the result tells you

The result panel shows four figures (labels as displayed by the live calculator), followed by a one-line verdict:

Total cyclic PDO payload — the sum of every group's quantity × bytes, in bytes per cycle. This is the headline number: it is the process-data total the EtherCAT Cycle Time calculator asks for, and the figure to sanity-check against your configurator's own process-data size if it reports one.
RxPDO / TxPDO split — the total divided by the share you entered, shown as "Rx B / Tx B". It changes nothing else on the panel; its job is directional visibility — how much of the payload flows master→slave (RxPDO) versus slave→master (TxPDO). If the split surprises you, the share input or your direction convention is off, not the total.
Payload serialization @ 100 Mbit/s — total bytes × 0.08 µs: how long the payload alone spends on the wire each cycle. It deliberately excludes frame overhead, slave forwarding, and cable propagation — the calculator's assumptions say so — so treat it as the floor of the communication time, never the whole of it.
Payload rate at selected cycle — the payload expressed as bandwidth: total × 8 bits, repeated at the cycle rate. Useful for judging how much of the 100 Mbit/s link the cyclic payload itself claims (4.29 Mbit/s in the example — about 4% of the link) and for spotting how fast that claim grows as the cycle shortens.
The verdict line — points at the correct next step: "Use the total cyclic payload as an input to the EtherCAT Cycle Time calculator, then add real frame, slave, cable, master, and application timing." A payload total is not a cycle-time answer; it's the input the cycle-time budget is built from.

Common mistakes

Entering per-direction bytes into a combined field. The bytes fields are labelled "Rx + Tx bytes" — they want both directions added. If a drive maps 32 B of RxPDO and 32 B of TxPDO, the entry is 64, not 32 (which halves the group total) and not 128 (which double-counts it).
Losing slaves at the group boundaries. Gateways, safety slaves, and encoder modules get mentally filed under "not really I/O" and left out — but every mapped byte crosses the wire every cycle. If a device has a PDO mapping, it belongs in a group; when in doubt, it goes in "Other slaves" with its real byte count.
Reading the payload rate as total network load. The Mbit/s figure is payload only, exactly as the calculator's assumptions state: no Ethernet/EtherCAT framing, no interframe gaps, no acyclic mailbox traffic, no other segments' data. It answers "how much cyclic payload am I moving?", not "how busy is the wire?"
Treating serialization as the cycle budget. 42.9 µs of payload serialization is not a 42.9 µs communication time. Frame overhead (the Cycle Time calculator prices it at ≈ 5 µs per frame plus the same 0.08 µs/byte), per-slave forwarding delay, and cable propagation all add on top — which is why the verdict sends you to the Cycle Time calculator instead of declaring the cycle feasible.
Quoting bandwidth without the cycle time. Payload rate scales inversely with the cycle: halve the cycle and the same payload doubles its rate. A "4.29 Mbit/s network" and a "17.15 Mbit/s network" can be the identical machine at 1 ms and 250 µs. Always state the pair together.

FAQ

How do I calculate the total PDO size of an EtherCAT network?

Add up, for every slave, the cyclic process data it exchanges each cycle — its RxPDO bytes plus its TxPDO bytes — and total across the network. This calculator groups the arithmetic: drives × bytes per drive, plus I/O devices × bytes per device, plus other slaves × bytes per slave. The per-device figures come from each slave's PDO mapping in your configurator (or the ESI file's default mapping). The total is the number the EtherCAT Cycle Time calculator needs as its process-data input.

What is the difference between RxPDO and TxPDO?

Direction is named from the slave's point of view. RxPDO is data the slave receives — commands and setpoints the master sends, such as a controlword and target position. TxPDO is data the slave transmits — feedback the master reads, such as a statusword and actual position. The naming trips people up because from the master's perspective it reads backwards. This calculator asks for the two added together per device, then splits the total by the RxPDO share you enter.

How much bandwidth does my EtherCAT process data use?

The payload rate is total bytes × 8 bits, repeated at the cycle rate: 536 bytes at a 1 ms cycle is 4.288 Mbit/s of payload; the same payload at 250 µs is 17.15 Mbit/s. That's payload only — it excludes Ethernet and EtherCAT frame overhead, interframe gaps, and acyclic traffic such as mailbox/SDO exchanges — so the wire itself is busier than this figure. Use it to judge the cyclic payload's claim on the 100 Mbit/s link, not as a total network load.

Does PDO size affect EtherCAT cycle time?

Yes — linearly. Every byte costs 0.08 µs of serialization at 100 Mbit/s, so payload bytes are one direct term in the cycle budget. But they're rarely the deciding term on an I/O-sized network: frame overhead, slave forwarding delay, cable propagation, application execution, and jitter reserve all add to it. Feed this calculator's total into the EtherCAT Cycle Time calculator to see the whole budget against your target.

How much PDO data fits in one EtherCAT cycle?

One Ethernet frame carries up to roughly 1,500 bytes of process data, so totals up to that level travel in a single frame per cycle. Larger networks send multiple frames per cycle, which is normal and supported — but each extra frame adds overhead this payload estimate doesn't price in, since it charges 0.08 µs per byte either way. For totals well above 1,500 bytes, treat the serialization figure as a floor and let the Cycle Time calculator's budget — plus your master's own reporting — have the final word.

Why does the result show serialization in µs and a rate in Mbit/s — which one matters?

They're the same payload wearing two units. Serialization (µs per cycle) is the figure that feeds cycle-time work: it's the payload's contribution to the time budget of one cycle. The rate (Mbit/s) is the figure for bandwidth conversations: how much of the link the cyclic payload claims at the cycle you're running. Use serialization when you're asking "will it fit in the cycle?", and the rate when you're asking "how loaded is the network?"

Take this payload into the timing budget.

The free Controls Toolkit includes the EtherCAT timing-budget workbook — slave and PDO inventory, cycle utilisation, and remaining timing margin, with the formulas built in — plus an Industrial PC sizing workbook. Free by email signup.

Get the Controls Toolkit →