EtherCAT vs Profinet vs Sercos III: Motion Control 2026
A six-axis pick-and-place machine that drifts by even one encoder count per axis per cycle will smear a part placement by millimetres after a thousand cycles. The fix is not a faster CPU — it is a network that delivers setpoints to every drive at the same instant, every cycle, forever. That is why the EtherCAT vs Profinet question (and the third contender, Sercos III) is really a question about determinism: which wire-level mechanism keeps a dozen servo axes phase-locked while the rest of the plant keeps streaming data. By the end of this post you will be able to map cycle-time, jitter, topology, safety, and TSN-readiness onto a concrete choice for your machine, backed by a weighted decision matrix and a decision tree.
What this covers: how each protocol achieves hard real time, where their cycle times actually land in practice, the safety and ecosystem trade-offs, the convergence path to TSN, and a defensible way to choose.
Context and Background
Industrial motion control outgrew classic fieldbuses (Profibus, CANopen, DeviceNet) roughly two decades ago. The bottleneck was bandwidth and jitter: coordinating eight or more servo axes at sub-millisecond cycle times needs more than a 1–12 Mbit/s serial bus can carry. The industry’s answer was to put determinism on top of standard 100 Mbit/s Ethernet physical layers — but plain switched Ethernet is non-deterministic by design, so each camp engineered a different escape from that non-determinism.
Why is plain Ethernet unfit for motion? A standard switch buffers and forwards frames on a best-effort basis. Under load, a motion frame can sit behind a large file transfer, and the resulting latency variation — even a few hundred microseconds — is fatal to a coordinated axis. Worse, retransmission semantics that make TCP reliable for IT are useless for motion: a setpoint that arrives late is not worth retransmitting, it is simply wrong. Real-time industrial Ethernet protocols therefore abandon best-effort delivery for one of two strategies: bypass the standard stack with custom hardware (EtherCAT, Sercos), or constrain the standard stack with rigid scheduling (Profinet IRT). Understanding which strategy a protocol uses tells you most of what you need to know about its behaviour and its limits.
Three protocols dominate the synchronized-motion segment today: EtherCAT (Beckhoff, stewarded by the EtherCAT Technology Group), Profinet IRT (Siemens, stewarded by PROFIBUS & PROFINET International), and Sercos III (rooted in Bosch Rexroth, stewarded by Sercos International). All three are standardized under the umbrella of IEC 61158 and IEC 61784 communication-profile families, which is why none of them is a proprietary dead end on paper. In practice, ecosystem gravity is strong.
Governance shapes each protocol’s trajectory as much as engineering does. EtherCAT’s stewardship by the EtherCAT Technology Group and its low-friction membership has produced an unusually broad vendor base, which feeds back into cost and availability. Profinet’s home at PI is tightly coupled to Siemens’ market position, giving it deep tooling but a strong vendor centre of gravity. Sercos International is the smallest of the three communities, which concentrates expertise but narrows supplier choice. When you choose a protocol you are also choosing a community, a conformance regime, and a roadmap — that is part of the decision, not a footnote to it.
For the broader landscape of how these real-time protocols fit alongside MQTT, OPC UA, and the rest of the stack, see our industrial IoT communication protocols architecture guide. This post zooms into the hard-real-time motion tier specifically — the layer where a late frame is not a retransmit, it is a scrapped workpiece or a tripped axis.
How Each Protocol Wins Determinism
Figure 1: The three real-time industrial Ethernet protocols share a master-controller-to-servo-drive shape but differ entirely in how the frame moves on the wire.
Direct answer: EtherCAT uses processing-on-the-fly with one summation frame and distributed clocks for sub-microsecond synchronization; Profinet IRT reserves scheduled, isochronous time slots on switches so motion traffic never collides with best-effort traffic; Sercos III sends fixed MDT and AT telegrams around a ring or down a line with hard slave-to-slave timing. The mechanism, not the marketing, drives the numbers.
EtherCAT: one frame, processed in flight
EtherCAT’s trick is that there is effectively one frame per cycle. The master emits a single Ethernet frame; each slave node reads the bytes addressed to it and writes its response into the same passing frame in hardware, with a latency of nanoseconds, then forwards it. This “processing on the fly” is implemented in the slave’s ESC (EtherCAT Slave Controller) ASIC, so the master never waits on a software stack at each node.
Synchronization comes from Distributed Clocks (DC): one reference clock (usually the first DC-capable slave) is propagated and the master compensates for propagation delay, holding axis-to-axis sync typically well under 1 microsecond. For multi-axis motion that phase alignment is the whole game — it is why EtherCAT became the default for high-axis-count machines.
Two details are worth internalizing because they explain EtherCAT’s efficiency. First, the addressing is positional or logical, not switched: the ESC recognizes its slice of the frame by the FMMU (Fieldbus Memory Management Unit) mapping, so there is no per-packet switching lookup adding jitter. Second, the bandwidth utilization is unusually high — because one frame services every node, the protocol overhead per axis is tiny, and a 100 Mbit/s segment can comfortably carry process data for dozens of drives within a sub-100-microsecond cycle. The cost of that elegance is topological rigidity, which we return to under gotchas.
Profinet IRT: bandwidth you reserve in advance
Profinet has three performance classes. Standard (RT) rides best-effort Ethernet and is fine for I/O but not for tight motion. IRT (Isochronous Real-Time) is the motion-grade class: it uses IRT-capable switch ASICs (the historical “ERTEC” lineage) to carve each cycle into a reserved red phase for scheduled isochronous traffic and a green phase for everything else. Because the bandwidth and the timing are planned offline by the engineering tool, motion frames never contend with TCP/IP traffic. IRT also synchronizes nodes precisely enough for isochronous setpoint delivery, though its mechanism is scheduling rather than EtherCAT’s hardware insertion.
The planning step is the philosophical difference. EtherCAT’s determinism is emergent from the frame-on-the-fly hardware; Profinet IRT’s determinism is computed. The engineering tool builds a communication schedule — which frame leaves which port in which nanosecond window — and downloads it to every IRT switch. That up-front planning is what makes IRT robust against best-effort traffic, but it also means the network is less forgiving of ad-hoc topology changes: add a node and you generally re-plan. The payoff is that the same physical Profinet network carries motion, standard I/O, and IT traffic in clearly partitioned phases, which is a genuine convergence head start.
Sercos III: telegrams around a ring
Sercos III carries two telegram types per cycle: the MDT (Master Data Telegram) pushes setpoints out, and the AT (Acknowledge Telegram, also called Drive Telegram) carries actual values back. It is purpose-built for drives and was a motion protocol long before it moved to Ethernet. Its standout feature is native ring topology with hard slave-to-slave communication, so one drive can read another drive’s data inside a cycle without a master round trip — valuable for tightly coupled gantries and cross-coupled axes. The ring also gives a natural cable-redundancy story.
That drive-centric DNA shows in the timing model. Sercos III divides each cycle into a deterministic real-time channel for the MDT/AT telegrams and an open UC (Unified Communication) channel for standard IP traffic, so it too can mix motion and IT on one wire — conceptually similar to Profinet’s red/green split. Where Sercos earns its keep is the cross-communication: because every node sees both telegrams passing on the ring, a follower axis can act on a leader axis’s actual position within the same cycle. For an electronic gearbox or a cross-coupled gantry, that removes a whole cycle of latency from the control loop, which translates directly into tighter contour accuracy. The trade is a smaller vendor ecosystem than either competitor.
Cycle Time, Jitter, and the Numbers That Matter
The figures below are approximate typical ranges seen in real deployments and vendor documentation, not guaranteed absolutes — actual numbers depend on axis count, process data size, frame size, and master CPU. Treat them as engineering ballparks.
Figure 2: An EtherCAT cycle moves a single frame through every node and back, with Distributed Clocks aligning the outputs — the reason its effective cycle time scales so well with axis count.
The sequence above shows why EtherCAT’s per-node overhead is so low: the frame is read and written in flight at each ESC, then turned around at the last node and returned along the same path. Adding axes mostly adds bytes to one frame rather than adding round trips.
| Criterion | EtherCAT | Profinet IRT | Sercos III |
|---|---|---|---|
| Typical motion cycle time (approx) | ~12.5–100 us | ~250 us–1 ms class | ~31.25 us–1 ms |
| Sync mechanism | Distributed Clocks | IRT scheduling (red/green phase) | Hard cyclic MDT/AT timing |
| Axis-to-axis jitter (approx) | sub-microsecond | low microsecond | sub- to low microsecond |
| Native topology | Line, tree, drop (one logical ring) | Star, line, tree (switched) | Ring or line |
| Cable redundancy | Cable redundancy add-on | MRP / media redundancy | Native ring redundancy |
| Drive profile | CoE (CiA 402) and SoE | PROFIdrive | SoE (Sercos profile) and CiA 402 |
| Functional safety | FSoE (Safety over EtherCAT) | PROFIsafe | CIP Safety on Sercos / Sercos safety |
| Primary steward | EtherCAT Technology Group | PI / Siemens | Sercos International / Bosch Rexroth |
| Master cost / availability | Low, many soft masters | Higher, fewer soft masters | Moderate |
A few honest reads of this table. EtherCAT’s headline cycle-time floor is the lowest and it scales best with axis count, which is the main reason it dominates fast multi-axis machinery. Profinet IRT typically targets a slightly more relaxed motion class but buys you the largest installed base and the deepest Siemens automation integration. Sercos III’s drive-centric heritage and native ring redundancy make it strong where cabling resilience and slave-to-slave coupling matter most.
Notice what the table does not say: that any one protocol is universally best. The cycle-time numbers are headroom, not requirements. A packaging machine that genuinely needs 50-microsecond coordination is a different decision from a palletizer comfortable at 1 millisecond, and most plants run both. The right way to read the row labelled cycle time is “what is the floor I might ever need,” then check that the candidate clears it with margin — not “which number is smallest.”
Mapping protocols to machine archetypes
Three rough archetypes cover most real machines. The first is the fast multi-axis machine — CNC, electronics assembly, semiconductor wafer handling, high-speed packaging — where ten or more axes must stay phase-locked at tens of microseconds. Here EtherCAT’s frame-on-the-fly efficiency and DC synchronization are the natural fit, and its abundant soft masters keep the controller cost down.
The second archetype is the plant-integrated line built around a single automation vendor’s stack, most often Siemens. The motion may be no more demanding than a few hundred microseconds, but the operational value of one engineering tool, one diagnostic model, and one spare-parts inventory is enormous. Profinet IRT wins here on total lifecycle cost even when it is not the fastest option on paper.
The third archetype is the redundancy-critical or tightly-coupled machine — printing presses, web handling, large gantries with cross-coupled axes — where a single broken cable must not stop the line and where one axis must react to another within a cycle. Sercos III’s native ring and slave-to-slave communication are purpose-built for exactly this, and that is where its smaller ecosystem is an acceptable trade.
Drive profiles: CiA 402 is the common language
All three ultimately speak some flavour of the CiA 402 drive profile state machine (modes like Cyclic Synchronous Position, Velocity, and Torque). EtherCAT exposes it via CoE (CANopen over EtherCAT) or SoE (Servo Drive Profile over EtherCAT). Sercos exposes the Sercos/SoE profile. Profinet uses PROFIdrive, which is conceptually similar but not byte-compatible. The practical consequence: porting a CSP-mode axis between EtherCAT and Sercos is often a configuration exercise; moving to Profinet’s PROFIdrive is more of a re-mapping exercise.
The CiA 402 state machine matters more than it first appears. It standardizes how a drive transitions through Switch On Disabled, Ready to Switch On, Operation Enabled, and the fault/quick-stop states, and it defines the cyclic interpolation modes that motion controllers actually command. Because EtherCAT and Sercos both anchor on CiA 402, a control engineer’s mental model of the drive transfers cleanly. PROFIdrive maps the same concepts onto different telegram structures, so the behaviour is portable but the byte layout is not — budget integration time accordingly when a machine bridges both worlds.
Where jitter actually comes from
Jitter is the variation in when a setpoint lands, and it is the silent killer of contour accuracy. In EtherCAT, jitter is dominated by the master’s ability to release the frame on time and by DC offset compensation; the on-the-fly hardware contributes almost none. In Profinet IRT, jitter is bounded by the quality of the offline schedule and the precision of the IRT switch clocks. In Sercos III, the fixed MDT/AT slotting keeps jitter low as long as the ring is intact and timing is configured correctly. The common lesson: at these cycle times the network is rarely the jitter bottleneck — a non-real-time master OS or a sloppy interrupt model usually is. That is why a hard-real-time master (a dedicated motion CPU or a properly isolated PREEMPT_RT core) matters as much as the protocol choice.
Functional safety as a black channel
All three safety protocols — FSoE, PROFIsafe, and CIP Safety on Sercos — use the black-channel principle: the safety layer adds its own CRC, sequence counter, and timeout watchdog so the underlying network can be treated as untrusted transport. This is what lets a safe torque off (STO) or safe stop command share the same cable as standard process data without a separate hardwired safety bus. The corollary is that safety response time is a system property — it is the sum of the safety cycle, the network cycle, and the drive’s reaction — so you size it end to end against your required category and SIL, not from the network spec alone.
The master side decides more than the wire
It is tempting to treat protocol selection as a property of the network, but the master controller is where most real-world performance and cost is won or lost. EtherCAT’s ecosystem includes numerous soft masters — open-source stacks and commercial PC-based motion runtimes — so a standard industrial PC with a real-time OS can drive a fast multi-axis line at low licensing cost. That abundance is a structural advantage: it decouples the controller decision from a single hardware vendor. Profinet IRT and Sercos masters, by contrast, are more often embedded in a vendor’s PLC or motion controller, which raises the floor on controller cost but bundles in tested, supported integration.
The deeper point is that determinism is a property of the whole control loop, not the protocol in isolation. A 50-microsecond network cycle is meaningless if the master cannot compute the next setpoint and release the frame within that window, jitter-free. This is why teams that nail the wire-level spec still miss their motion targets: the bottleneck migrated to the operating system, the interrupt latency, or the motion-kernel computation budget. Choose the protocol for the wire, but size and validate the master for the loop — they are separate decisions that must both succeed.
Diagnostics and commissioning realities
Datasheets compare cycle times; commissioning engineers compare diagnostics. EtherCAT exposes per-port error counters and working-counter mismatches that make it relatively easy to localize a bad cable or a flaky ESC to a specific node — a real operational strength on a long line. Profinet’s diagnostics are deeply integrated into the Siemens engineering and HMI tooling, so a fault surfaces as a named, located alarm in the same environment the operators already use, which shortens mean-time-to-repair for plants standardized on that stack. Sercos III’s ring carries diagnostic information both directions, and a ring break is detectable and locatable because the two halves of the ring report independently. None of this shows up in a cycle-time spec, yet it dominates the day-2 experience of owning the machine — weight it accordingly when the technical numbers are close.
Trade-offs, Gotchas, and What Goes Wrong
Figure 4: A decision tree for choosing the network — ecosystem lock-in usually decides first, then cycle-time and convergence requirements break the tie.
The decision tree above encodes the uncomfortable truth: ecosystem gravity usually decides before any technical criterion does. If your line runs Siemens PLCs and TIA Portal end to end, Profinet IRT is the path of least resistance regardless of EtherCAT’s faster floor. If your motion comes from Bosch Rexroth drives, Sercos III is native. Only on a genuinely open or mixed build does the EtherCAT vs Profinet decision come down to raw determinism.
Concrete gotchas to plan for:
- Topology is not free.
