EtherCAT vs PROFINET vs Sercos III: Motion Control in 2026

Last Updated: October 2026

A servo axis does not care about your network’s average latency. It cares about the worst cycle in a million, because one late setpoint is a position error that the next cycle has to unwind. That is why the EtherCAT vs PROFINET debate, with Sercos III as the third serious contender, is not really a debate about speed. It is a debate about how each protocol turns a shared Ethernet wire into something that behaves like a backplane, and what you give up to get there.

It matters in 2026 for two reasons. The three incumbents are no longer competing only on cycle time: they are being pulled toward a shared Time-Sensitive Networking (TSN) layer and an OPC UA information layer, and the IEC/IEEE 60802 profile that anchors that convergence now appears in standards catalogues with a June 2026 publication date. At the same time, EtherCAT’s installed base keeps compounding, so ecosystem gravity is stronger than ever.

You will leave with the mechanism behind each protocol, the cycle-time and jitter figures that vendors and standards bodies actually publish (and which ones are only typical), a view of safety, drive profiles and masters, runnable configuration sketches, a decision matrix, and a short list of failure modes that bite real commissioning projects.

What this covers: processing on the fly, distributed clocks, PROFINET RT and IRT, Sercos III telegrams and the UC channel, cycle and jitter arithmetic, topology and redundancy, functional safety, masters and configuration, TSN and OPC UA FX convergence, trade-offs, and a selection method.

Context and Background

Classic fieldbuses such as PROFIBUS, CANopen and DeviceNet ran out of headroom for coordinated motion once machines wanted eight, thirty or a hundred axes updating in well under a millisecond. Serial and CAN-class buses top out at megabits per second and carry significant per-node overhead. Ethernet offered 100 Mbit/s full duplex at commodity prices, but plain switched Ethernet is best-effort: a motion frame can queue behind a bulk transfer, and the resulting variation in latency is exactly the thing a servo loop cannot tolerate. A retransmission is no help either, because a setpoint that arrives late is not worth delivering.

Industrial Ethernet protocols therefore choose one of two escape routes. The first is to bypass normal Ethernet switching behaviour with dedicated hardware in every node, which is the EtherCAT approach and, in a different form, the Sercos approach. The second is to keep standard switching but constrain it with a computed, time-triggered schedule, which is what PROFINET IRT does and what TSN generalises. Which route a protocol takes explains most of its strengths and its limits.

Three protocols dominate synchronised motion today. EtherCAT is stewarded by the EtherCAT Technology Group (ETG), founded in November 2003, and originated at Beckhoff. ETG reported more than 8,100 members from 76 countries and about 88 million EtherCAT nodes active in the field in April 2025, with 11 million added during 2024 (as reported in Control Design). PROFINET is stewarded by PROFIBUS and PROFINET International (PI) and has deep Siemens roots. Sercos III is stewarded by Sercos International e.V. in Germany; work on Sercos III began in 2003 and the first products shipped in 2005.

All three appear in the IEC 61158 and IEC 61784 families of fieldbus standards, so none is a proprietary dead end on paper. EtherCAT is additionally standardised in IEC 61800-7 for drive profiles and ISO 15745-4, and its safety layer in IEC 61784-3-12. In practice, ecosystem gravity matters more than the standards label: the drives, the engineering tool and the people who commission the machine are already attached to one of these worlds.

Governance shapes the trajectory as much as engineering does. EtherCAT’s low-friction membership and freely available slave-controller silicon produced a very broad device base, which feeds back into price and availability. PROFINET’s tight coupling to Siemens gives it deep tooling and the largest installed base in factory automation, with a strong vendor centre of gravity. Sercos is the smallest community: that concentrates drive expertise and narrows supplier choice. Choosing a protocol is also choosing a conformance regime, a community and a roadmap.

For the wider map of how these hard real-time protocols sit beside MQTT, OPC UA and the rest of the stack, see our industrial IoT communication protocols architecture guide. If you are comparing the same candidates specifically through the TSN and OPC UA FX lens, our companion piece on PROFINET vs EtherCAT vs OPC UA FX over TSN takes that angle. This article stays at the motion tier: the layer where a late frame is a scrapped part, not a retry.

How Each Protocol Wins Determinism

Figure 1: All three put a master at one end and servo drives at the other, but the frame moves differently. EtherCAT passes one frame through every drive, PROFINET IRT reserves scheduled time slots in switches, and Sercos III circulates MDT and AT telegrams around a ring or line.

Direct answer: EtherCAT uses one frame that each slave modifies in hardware as it passes, plus distributed clocks for synchronisation. PROFINET IRT divides each cycle into a reserved isochronous phase and a best-effort phase using a precomputed schedule and IEEE 1588-based clocks. Sercos III sends fixed Master Data and Acknowledge Telegrams in a collision-free real-time channel. The mechanism, not the marketing, sets the numbers.

Figure 1 compresses the architectural difference into one picture. The master is the same logical role in all three: it owns the cycle, computes setpoints and consumes feedback. The difference is entirely in what happens to a frame between the master’s port and the drive’s. The next three subsections take each mechanism in turn, with the specifics that matter when you size a machine.

EtherCAT: one frame, processed in flight

EtherCAT’s central idea is that the master emits a frame and each slave reads and writes it in hardware as the frame passes through, rather than receiving a full frame, deciding what to do and sending a new one. The frame travels in a standard IEEE 802.3 Ethernet frame with EtherType 0x88A4. Each node’s EtherCAT Slave Controller (ESC) extracts the output data addressed to it and inserts input data into the same frame, with forwarding delay measured in tens of nanoseconds, then passes it on. At the last node the frame is turned around and returns to the master along the other pair of the full-duplex link, so the physical line is logically a ring.

This has three consequences that explain EtherCAT’s reputation. First, protocol overhead per node is tiny, because one frame (or a few, for large process images) services every node. The EtherCAT Technology Group’s published figures quote more than 90 percent user-data utilisation of the full-duplex 100BASE-TX capacity, 1,000 distributed digital I/O points exchanged in roughly 30 microseconds, and 100 servo axes updated at up to 10 kHz. Second, addressing does not use switching lookups. Third, adding axes mostly adds bytes to the frame, not additional round trips, so cycle time scales gently with axis count.

Where the data lands inside the frame is decided by the ESC’s Fieldbus Memory Management Units (FMMUs), which map logical addresses in the frame to the ESC’s physical memory, and by Sync Managers, which control access to that memory so the master and the local application never read a half-written value. The master configures these from the device description (ESI file) and its own network information (ENI). Because the mapping is data rather than logic, a master can reconfigure a process image at start-up without any per-device code.

Distributed clocks and why they matter

Passing a frame through is not enough for coordinated motion: axis three must apply its setpoint at the same instant as axis seventeen, even though the frame reached them hundreds of nanoseconds apart. EtherCAT solves this with Distributed Clocks (DC). Every DC-capable ESC keeps a local 64-bit time counter with a 1 nanosecond base unit, counting from 1 January 2000. The master measures the propagation delay to each node, writes the compensation values, and continuously drifts every local clock toward a single reference clock, typically the first DC-capable slave.

Each slave can then generate a SYNC0 pulse, and optionally SYNC1, at a shifted, identical system time, and latch its input samples against the same clock. The outputs are therefore applied synchronously regardless of where the node sits on the line, and inputs are time-stamped to nanosecond resolution. ETG describes the resulting synchronisation jitter as significantly less than 1 microsecond, comparable to IEEE 1588 PTP, and quotes a design target of cycle times of 100 microseconds or less with communication jitter of 1 microsecond or less. Note the word target: your real jitter is dominated by the master.

PROFINET: RT for I/O, IRT for motion, TSN for convergence

PROFINET IO has three performance tiers. RT (Real Time) uses prioritised Ethernet frames on an unmodified network. It is aimed at I/O with cycle times in the 1 to 10 millisecond range and shows jitter that is acceptable for process I/O but not for tight motion. IRT (Isochronous Real Time) is the motion class. PROFINET over TSN replaces the proprietary IRT mechanisms with the IEEE 802.1 TSN toolkit and was introduced with specification V2.4.

IRT divides every cycle into a red phase and a green phase. During the red phase only scheduled isochronous frames may be forwarded, and switches buffer any non-real-time frames that arrive in the meantime. During the green phase everything else, including standard TCP/IP, flows. The schedule is computed offline by the engineering tool from the topology, the cycle times and the data volumes, then downloaded to the devices. Synchronisation is built on IEEE 1588 concepts through the Precision Transparent Clock Protocol (PTCP), which measures cable and switch delay so all switches open and close the red phase together.

The cost of that determinism is rigidity and certification. Every device between controller and drive, including each switch, must be certified to Conformance Class C. PI documentation cites IRT cycle times of 31.25 microseconds and clock synchronisation deviation of at most 1 microsecond for this class; cycles below 250 microseconds require the fragmentation features added in later specification versions, and the green phase must remain at least 125 microseconds. Dynamic topology changes generally imply recomputing the schedule.

Sercos III: telegrams for drives, born for motion

Sercos began in 1980s as a fibre-optic drive interface, so motion is its native language. Sercos III runs on 100 Mbit/s full-duplex Ethernet (100BASE-TX or 100BASE-FX) and divides each communication cycle into a real-time channel and a Unified Communication (UC) channel. The real-time channel carries the Master Data Telegram (MDT), which delivers setpoints, and the Acknowledge Telegram (AT), in which each slave inserts actual values, using EtherType 0x88CD. The UC channel passes any other Ethernet traffic, including TCP/IP and UDP/IP, in the time left after the real-time telegrams, without tunnelling.

Cycle times are user-selectable: 31.25, 62.5 and 125 microseconds, then multiples of 250 microseconds up to 65 milliseconds. Topology is a ring or a line, and both are circular in the sense that telegrams start and end at the master. The ring provides automatic infrastructure redundancy: a broken cable is detected in under a cycle (the specification quotes 25 microseconds) and telegrams are looped back so the loss is bump-less. Hot-plug lets devices join a running network. Slave-to-slave communication lets one drive consume another’s actual values within the same cycle, which is valuable for cross-coupled gantries and electronic gearing.

Sercos III safety is built on the CIP Safety protocol from ODVA, supporting SIL 3 over the same medium. Because it was designed from the drive outwards, Sercos III timing is tightly coupled to the drive’s control loops, and many Sercos systems let the drive handle interpolation and loop closure locally. The trade is a much smaller device ecosystem than EtherCAT or PROFINET.

Cycle Time, Jitter and the Numbers That Matter

Treat every figure below as a published capability or a typical range, not a guarantee. Real cycle times depend on axis count, process-data size per axis, frame fragmentation, the master’s CPU and operating system, and how many other tasks share the loop. Where a number comes from a specification or an organisation’s own material, we say so.

Figure 2: One EtherCAT cycle. The master releases a frame, each slave reads outputs and writes inputs in flight, the last node returns the frame, and the distributed clocks fire SYNC0 on every node at the same system time.

The sequence in Figure 2 shows why EtherCAT’s cost per node is so low: the frame is processed at each ESC and turned around, and the timing of the output event is decoupled from the arrival time of the frame by the SYNC0 mechanism. A practical consequence is that the master only needs to deliver the frame before the shifted SYNC0 time, not at a precise instant. That relaxes the jitter requirement on the master by roughly the length of the shift.

Side by side

Criterion	EtherCAT	PROFINET IRT	Sercos III
Mechanism	Single frame processed on the fly in the ESC	Scheduled red phase with IRT switches	MDT and AT telegrams in a collision-free channel
Stated cycle capability	Design target of 100 us or less; typical update rates 1 to 30 kHz	31.25 us in CC-C material; 250 us without fragmentation	31.25 us up to 65 ms
Synchronisation	Distributed Clocks, 1 ns base unit	IEEE 1588 based PTCP, 1 us max deviation	Hard cyclic MDT and AT timing
Synchronisation accuracy (published)	Significantly under 1 us	At most 1 us	Not stated by a single headline figure
Topology	Line, tree, star, ring or mixed; no extra switches needed	Star, line, tree with IRT switches; ring via MRP or MRPD	Ring or line
Cable redundancy	Ring with a second master port	MRP under 50 ms; MRPD seamless	Native ring, loss detected in under one cycle
Drive profile	CoE with CiA 402, SoE	PROFIdrive	Sercos SoE profile, CiA 402 style modes
Functional safety	FSoE, IEC 61784-3-12, up to SIL 3	PROFIsafe, IEC 61784-3-3, up to SIL 3	CIP Safety, up to SIL 3
Steward	ETG	PI	Sercos International
Master options	Many software masters	Mostly PLC or controller built in	Mostly controller or drive vendor built in

The table is a map, not a ranking. EtherCAT leads on how much cyclic data it can move per microsecond and on how many vendors build compatible devices. PROFINET leads on installed base in discrete automation and on convergence of motion, I/O and IT traffic on a switched network. Sercos leads on native ring redundancy and drive-centred integration. Which of those matters depends entirely on the machine.

Notice what the cycle time row really tells you. It is headroom, not a requirement. A packaging machine that genuinely needs 100 microsecond coordination is a different problem from a palletiser comfortable at 1 millisecond, and most plants run both. Read the row as the floor you might need, confirm the candidate clears it with margin, and then stop. Choosing the smallest number buys nothing if the master cannot compute setpoints that fast.

A worked example of cycle arithmetic

Suppose a machine has 24 servo axes, each exchanging 16 bytes of outputs (control word, target position, target velocity or torque offset) and 16 bytes of inputs (status word, actual position, actual velocity or following error), plus 200 bytes of digital and analogue I/O. That is 24 times 32 plus 200, or 968 bytes of process data. On 100 Mbit/s, one byte takes 80 nanoseconds, so the raw payload serialisation time is roughly 77 microseconds one way, before Ethernet and protocol headers.

On a full-duplex EtherCAT line the frame travels out and back at the same time as other segments of the frame are still being serialised, so the cycle time is dominated by serialisation of the frame once, plus the sum of per-node forwarding delays, plus the return path. For 24 drives at an assumed 1 microsecond forwarding and cable delay per node, that adds 24 microseconds each way. A cycle of 150 to 250 microseconds is comfortable, and 125 microseconds is feasible. These are back-of-envelope figures for planning, labelled illustrative: real designs must be validated on hardware with the master and device parameters in hand.

The same payload on PROFINET IRT shares a cycle with the green phase, which must be at least 125 microseconds according to the PI-derived figures. The practical IRT cycle for this machine would therefore sit at the 250 microsecond to 1 millisecond class unless the IRT fragmentation features are available end to end. On Sercos III the MDT and AT sizes are set per device by the connection profile, and the 62.5 or 125 microsecond cycle options are typically the ones that work for 24 axes, because the UC channel needs time after the real-time telegrams.

Where jitter actually comes from

Jitter is the variation in when a setpoint lands or a sample is taken. In EtherCAT, hardware insertion contributes almost none, so jitter is set by the master’s ability to release the frame on time and by DC compensation quality. The SYNC0 shift hides most master jitter from the drive. In PROFINET IRT, jitter is bounded by the correctness of the offline schedule and the quality of the switch clocks. In Sercos III, the fixed slotting keeps jitter low provided the ring is intact and the cycle time is configured to match the connection profile.

The common finding is that at these cycle times the network is rarely the bottleneck. A non-real-time operating system, a shared interrupt line or a power-management state change in the master will add tens of microseconds of jitter, and no protocol can mask that. This is why a hard-real-time master, whether a dedicated motion CPU or a Linux machine running PREEMPT_RT with isolated cores and tuned interrupt affinity, matters as much as the protocol itself.

Topology, Redundancy, Safety and Drive Profiles

The wire mechanism gets the attention, but four neighbouring decisions determine whether the machine is maintainable: how the cabling is laid out, what happens when a cable fails, how safety traffic is carried, and how the drive is addressed. Each protocol has a defensible answer, and the answers differ more than the headline cycle times do.

Topology and cabling

EtherCAT runs line, tree, star, ring or mixed topologies without additional switches, because every device with two or more ports contains the forwarding logic. ETG documentation cites up to 100 metres between nodes on copper, up to 20 kilometres between nodes on single-mode fibre, and up to 65,535 nodes in one segment. In practice the line is the default, branch junctions use a three or four port coupler, and the cost per drop is very low. The price is that the frame must traverse everything, so a failed node in the middle of a line cuts off everything downstream unless a ring is closed back to a second master port.

PROFINET IRT uses switched star, line and tree layouts, and the IRT-capable switch function is normally integrated into the device so a line of drives behaves like a chain of small switches. Because IRT bandwidth is planned in advance, the engineering tool needs the topology, and the real cabling must match it. PROFINET’s topology detection (LLDP) is a feature here: the controller can compare the commissioned topology to the engineered topology and name the exact port that has been mis-cabled.

Sercos III lines and rings use the same device-integrated forwarding approach as EtherCAT, with the master at both ends of a ring. The advantage of a ring is that a single break is invisible to the cyclic data: telegrams loop back at the break and the system keeps running. The disadvantage is that it uses two master ports and one more cable.

Redundancy compared

Failure	EtherCAT	PROFINET	Sercos III
Single cable break	Ring with second master port keeps all nodes reachable	MRP recovers in under 50 ms; MRPD gives seamless switchover	Automatic loop-back, detected in under one cycle
Master failure	Hot Standby master supported	Controller redundancy (optional feature)	Vendor specific
Device swap	Hot-connect of segments, device change in operation	Device naming through topology, no engineering tool in many cases	Hot-plug of devices into running network

An important distinction is between recovery time and bump-less behaviour. A 50 millisecond ring recovery is excellent for process I/O but is many hundreds of motion cycles, so a coordinated axis group will fault long before MRP converges unless the drives ride through. For motion-class machines the relevant mechanisms are MRPD on PROFINET, ring healing on EtherCAT and the built-in loop-back on Sercos III. If a single cable fault must not stop the line, put this requirement in the specification explicitly, because it filters the options sharply.

Functional safety as a black channel

FSoE (Safety over EtherCAT), PROFIsafe and CIP Safety on Sercos III all use the black channel principle: the safety layer adds its own CRC, sequence counter, source and destination addressing and timeout watchdog, so the underlying network is treated as untrusted transport. That is what lets safe torque off or a safe stop command share a cable with standard process data without a hard-wired safety bus. EtherCAT’s FSoE is certified by TÜV for SIL 3 under IEC 61508, PROFIsafe covers SIL 3, Performance Level e and Category 4, and Sercos III safety supports SIL 3.

The corollary is that safety response time is a system property. It is the sum of the safety function’s processing time, the network cycle times in both directions, the safety watchdog timeout and the drive’s reaction. A 100 microsecond network cycle does not give you a 100 microsecond safety reaction. Size the safety response end to end against your required category and Performance Level, with the network’s worst-case cycle in the sum, and never infer it from the network specification.

Drive profiles: the part that decides portability

All three eventually map to a servo state machine and a set of cyclic modes. On EtherCAT, drives commonly implement CoE, which tunnels the CANopen object dictionary and the CiA 402 profile, with cyclic synchronous position, velocity and torque modes (CSP, CSV, CST). SoE carries the Sercos drive profile over EtherCAT. Sercos III uses the Sercos drive profile natively. PROFINET uses PROFIdrive, which is conceptually similar but not byte compatible.

The CiA 402 state machine standardises the transition from Switch On Disabled through Ready to Switch On and Switched On to Operation Enabled, plus the fault reaction and quick stop states. A control engineer who knows it can commission an unfamiliar EtherCAT servo quickly: write the control word through the sequence, set the mode of operation, supply target values, read status and actual values. Porting a CSP axis between EtherCAT and another CiA 402 transport is typically a configuration exercise; moving to PROFIdrive means re-mapping telegram structures, and the behaviour must be re-validated.

Masters, Configuration and Runnable Examples

A network master is where most real-world performance, cost and risk is decided. It owns the cycle, the process image mapping, the DC configuration and the error handling, and it must do so from an operating system that was not designed for microsecond determinism unless you take specific steps.

Figure 3: The convergence path. The motion application and master sit on top of a protocol-specific real-time layer today. TSN replaces the protocol-specific scheduling at layer 2, and OPC UA FX standardises controller-to-controller and controller-to-device information on top.

Why EtherCAT masters are abundant

EtherCAT’s stack is split in a way that favours open and commercial software masters. The slave side lives in hardware (the ESC), so the master only needs to send and receive standard Ethernet frames in a tight loop. Open-source masters such as SOEM (Simple Open EtherCAT Master) and the IgH EtherCAT Master from the EtherLab project, along with commercial real-time stacks, run on ordinary industrial PCs with a real-time Linux or RTOS. SOEM moved to version 2.0 in 2025, with the legacy ec_ API removed in favour of the ecx_ context-based API, a new mailbox handling API for CoE, FoE, EoE and SoE, an ENI parser, and a dual GPLv3 or commercial licence (as described in the rt-labs announcement). That licensing detail matters if you ship a product, and is worth checking before you commit.

PROFINET IRT and Sercos III masters are far more often built into a vendor’s PLC or motion controller. This raises the floor on controller cost and ties you to that vendor, but it brings tested engineering, diagnostics and support. That is a trade, not a defect: for a plant that wants one throat to choke, it is a feature. For an OEM that wants to run soft motion on a commodity PC, EtherCAT’s openness is a structural advantage.

Inspecting an EtherCAT network from the command line

The IgH master ships a command-line tool. After the master kernel module is loaded and bound to a dedicated NIC, these commands are the first things to run. This is an illustrative session for a four-drive line; the exact output depends on your devices and version.

# Show master state and link status
ethercat master

# List slaves with their position, state and names
ethercat slaves

# Dump the PDO mapping of slave 2 (useful to confirm CiA 402 objects)
ethercat pdos -p 2

# Read the CiA 402 statusword (0x6041:0) over CoE from slave 2
ethercat upload -p 2 0x6041 0

# Capture a trace for later analysis in Wireshark (EtherType 0x88a4)
tcpdump -i enp3s0 -w ethercat.pcap ether proto 0x88a4

Look for slaves not in OP state, working counter mismatches and a growing count of lost frames. A working counter lower than expected tells you which segment of the frame a device failed to process. That diagnostic is cheap and fast on EtherCAT, and one of its practical strengths on long lines.

A skeleton for a deterministic cyclic task

The sketch below shows the shape of a user-space cyclic task using the IgH application interface. It is not production code: it omits error handling, PDO entry registration and DC reference-clock handling, and the function names should be checked against the version of the library you install. Its purpose is to show the structure that makes the loop deterministic: a monotonic absolute timer, locked memory, a real-time scheduling policy, and a strict order of receive, process, queue and send.

#include <time.h>
#include <sched.h>
#include <sys/mman.h>
#include <ecrt.h>

#define CYCLE_NS 250000  /* 250 us cycle, illustrative */

static void add_ns(struct timespec *t, long ns) {
    t->tv_nsec += ns;
    while (t->tv_nsec >= 1000000000L) { t->tv_nsec -= 1000000000L; t->tv_sec++; }
}

int main(void) {
    struct sched_param p = { .sched_priority = 90 };
    sched_setscheduler(0, SCHED_FIFO, &p);      /* real-time policy */
    mlockall(MCL_CURRENT | MCL_FUTURE);         /* no page faults in the loop */

    ec_master_t *m = ecrt_request_master(0);
    ec_domain_t *d = ecrt_master_create_domain(m);
    /* configure slaves, sync managers, PDOs and DC (SYNC0) here */
    ecrt_master_activate(m);
    uint8_t *pd = ecrt_domain_data(d);

    struct timespec next; clock_gettime(CLOCK_MONOTONIC, &next);
    for (;;) {
        add_ns(&next, CYCLE_NS);
        clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &next, NULL);

        ecrt_master_receive(m);       /* pull the returned frame */
        ecrt_domain_process(d);       /* update the process image */
        /* read actual positions from pd, compute next setpoints, write to pd */
        ecrt_domain_queue(d);         /* queue outputs */
        /* ecrt_master_application_time(), sync reference clock goes here */
        ecrt_master_send(m);          /* release the frame */
    }
}

Three habits in this skeleton matter more than any protocol feature. Use an absolute timer so drift does not accumulate. Lock memory and pre-fault the stack so a page fault never lands inside a cycle. Isolate the cyclic core from interrupts and general scheduling with kernel boot parameters, and pin the NIC interrupt to a neighbouring core. On a tuned PREEMPT_RT system these steps are what separate a few microseconds of jitter from hundreds.

PROFINET and Sercos configuration

PROFINET configuration is tool driven. The engineering tool imports GSDML device description files, assigns device names and IP addresses, defines the IRT synchronisation domain with a sync master and sync slaves, sets the send clock and update times, and then computes and downloads the schedule. There is little to script and little to hand-edit, which is the point: the tool takes responsibility for correctness. The practical advice is to keep the topology file under version control and to treat “device replaced” as a procedure, since naming and topology matter for fast replacement.

Sercos III configuration similarly runs through the controller vendor’s tool. The master walks the communication phases CP0 to CP4 at start-up: CP0 and CP1 identify and address devices, CP2 sets up the cycle and telegrams, CP3 transfers parameters, and CP4 is cyclic operation. Understanding the phase model helps when a drive refuses to leave a phase, because the error normally names the phase and the parameter that failed.

TSN and OPC UA FX: Where All Three Are Heading

Time-Sensitive Networking is a family of IEEE 802.1 standards that adds deterministic behaviour to standard Ethernet. The pieces relevant to motion are time synchronisation (IEEE 802.1AS), the Time-Aware Shaper for scheduled traffic (IEEE 802.1Qbv) and Frame Preemption (IEEE 802.1Qbu with IEEE 802.3br). The IEC/IEEE 60802 profile selects and constrains these features for industrial automation, and standards catalogues now list IEC/IEEE 60802:2026, “Time-sensitive networking profile for industrial automation”, as published on 28 June 2026. For a deeper treatment see our write-up of the IEC/IEEE 60802 TSN profile.

PROFINET is the protocol that has gone furthest toward TSN. Specification V2.4 introduced TSN, and Conformance Class D is defined as the TSN class, with frame preemption mandatory and all communication carried at Ethernet layer 2. PI’s stated strategic direction is TSN as the common layer-2 foundation and OPC UA for controller-to-controller and vertical communication. A maintenance update in July 2020 referenced IEEE 802.1AS-2020 and early coordination results with 60802. In 2022, Avnu Alliance, CLPA, ODVA, the OPC Foundation and PI announced the TSN Industrial Automation Conformance Collaboration (TIACC) to build a single shared conformance test plan for the 60802 profile.

The practical takeaway is not that TSN replaces EtherCAT or Sercos. EtherCAT’s frame model is not an IEEE 802.1 TSN stream: it is a different mechanism with its own silicon. Instead, EtherCAT scales bandwidth with its G and 10G variants at 1 Gbit/s and 10 Gbit/s while keeping the same processing model, and it coexists with TSN-based networks at the machine boundary. The realistic multi-vendor future is one converged TSN backbone carrying PROFINET over TSN, OPC UA FX and standard IT traffic, with EtherCAT or Sercos as the machine-internal motion bus beneath a controller.

OPC UA FX (Field eXchange) is the OPC Foundation’s specification for controller-to-controller and controller-to-device communication. It lets controllers from different vendors exchange data and configure devices through a common information model, using TSN for determinism where required. For architectural detail see our OPC UA FX field exchange reference architecture. For a motion engineer, FX matters most at the machine boundary: it is how a line controller will tell a packaging machine’s controller to change recipe, not how the machine’s controller will command its servos at 250 microseconds.

Trade-offs, Gotchas and What Goes Wrong

Figure 4: A decision tree. Ecosystem and engineering-tool commitments usually decide first. Cycle time, redundancy and convergence requirements break ties only on open or mixed builds.

The tree encodes an uncomfortable truth: ecosystem gravity usually decides before any technical criterion does. If your plant runs Siemens controllers and TIA Portal end to end, PROFINET IRT is the path of least resistance regardless of EtherCAT’s lower stated cycle time. If your drives and controls come from a Sercos-native supplier, Sercos III is the integrated answer. Only on open or mixed builds does the EtherCAT vs PROFINET decision come down to determinism, cost and openness.

Concrete failure modes to plan for:

Line topology fragility. On an EtherCAT line, one dead node or a loose connector isolates everything behind it. Close the ring to a second master port or use junction couplers with bypass, and test pulling a cable during commissioning rather than during production.
Schedule rework in IRT. Adding a drive or a branch changes the schedule, so the engineering project must be re-compiled and downloaded to every IRT device. Leave spare capacity in the red phase and plan modification windows.
Non-certified switches. Putting an off-the-shelf unmanaged switch inside an IRT or Sercos real-time path breaks determinism, sometimes silently. Use only devices that carry the right conformance or certification for the protocol.
Master jitter blamed on the network. Teams measure bad contour accuracy, suspect the protocol, and discover that a graphics driver or a power-saving state in the master was the cause. Instrument the cycle on the master first.
Mixed stacks and gateways. A gateway between EtherCAT and PROFINET adds at least a cycle of latency and a data-consistency boundary. Do not run closed loops across one.
Safety response miscalculated. As noted earlier, safety reaction is end-to-end. Ignoring the master and drive contributions is the most common error in safety validation reports.
Licence surprises. Open-source masters have specific licence terms, and SOEM 2.0 is dual licensed under GPLv3 or a commercial licence. Confirm obligations before shipping a product that embeds one.
Vendor ESI or GSDML quirks. Device description files vary in quality. Two drives with the same profile can expose different PDO defaults, so always verify the mapping rather than trusting a template.

There is also a quieter risk: optimising for the wrong number. A team that picks a protocol for a 31.25 microsecond capability and then runs at 1 millisecond because of axis count, process-data size and master performance has paid for headroom it never uses. Conversely, a team that chooses for ecosystem and then discovers it needs sub-100 microsecond coordination for a single high-speed axis group can often isolate that group on a dedicated local bus. Bound the real requirement first.

Practical Recommendations

Start from the machine, not the protocol. Write down the fastest control loop you will genuinely close over the network, the number of axes, the process data per axis, the redundancy you need, and the safety level. Then apply the following.

Choose EtherCAT when you are building a fast, multi-axis machine from mixed vendors, when you want a software master on an industrial PC, when device availability and cost matter, or when line or tree cabling saves real money. Choose PROFINET IRT when the plant standard is Siemens or another PROFINET controller, when motion, standard I/O and IT traffic must share one switched network, and when integrated diagnostics in the existing tool matter more than the lowest cycle time. Choose Sercos III when native ring redundancy, drive-level coupling and slave-to-slave communication are central, particularly in printing, web handling and large gantries, and when your drive supplier is in that ecosystem.

Checklist before you commit:

Fix the required cycle time and jitter with margin, and confirm the master can meet them under load.
Decide whether a single cable fault must be invisible to motion, and select ring or MRPD accordingly.
Verify conformance or certification of every device, including switches, in the real-time path.
Calculate safety response time end to end for the required category and Performance Level.
Check that drive profiles (CiA 402 or PROFIdrive) match what your motion kernel expects.
Plan the TSN and OPC UA FX boundary at the machine edge now, not after the first customer asks.
Validate on real hardware with the real master, measuring cycle jitter at the master and at the drive.

Frequently Asked Questions

Is EtherCAT faster than PROFINET?

On published capability, EtherCAT is generally positioned for the shortest cycles with the most axes: ETG cites a design target of cycles of 100 microseconds or less. PROFINET IRT material cites a 31.25 microsecond capability for Conformance Class C. In real machines the limit is usually axis count, process-data size and the master, so the practical difference is smaller than the headline numbers. Choose on ecosystem and requirements, and confirm on hardware.

What is the difference between PROFINET RT and IRT?

RT uses prioritised standard Ethernet frames and suits I/O with cycle times from about 1 to 10 milliseconds, with some jitter. IRT reserves a scheduled phase in every cycle for isochronous traffic, uses IEEE 1588-based synchronisation with at most 1 microsecond deviation, and requires Conformance Class C devices and switches. Use RT for I/O and IRT for synchronised motion. TSN-based Class D is the converged successor.

Does Sercos III still matter in 2026?

Yes, in specific niches. Sercos III offers 31.25 microsecond to 65 millisecond cycle times, native ring redundancy with loss detected in under one cycle, hot-plug and slave-to-slave communication, with CIP Safety support up to SIL 3. Its ecosystem is much smaller than EtherCAT or PROFINET, so supplier choice narrows. It remains a strong fit for printing, packaging and large coupled-axis machines where those features are central.

Will TSN replace EtherCAT and PROFINET IRT?

Not directly. PROFINET is moving to TSN through Conformance Class D, and IEC/IEEE 60802 defines the industrial profile. EtherCAT uses a different frame-processing model with its own silicon, so it coexists with TSN networks rather than becoming one. Expect converged TSN backbones carrying PROFINET over TSN, OPC UA FX and IT traffic, with EtherCAT or Sercos often remaining as the machine-internal motion bus.

Can I run EtherCAT on a standard PC?

Yes. The master needs only a standard Ethernet port and a real-time capable operating system. Open-source masters such as SOEM and the IgH EtherCAT Master, and commercial stacks, run on Linux with PREEMPT_RT or on an RTOS. You must isolate cores, lock memory and tune interrupts to achieve low jitter, and a NIC with a well-behaved driver helps. Check licence terms, especially for SOEM 2.0.

Which protocol is best for functional safety?

All three carry safety up to SIL 3 using a black channel: FSoE on EtherCAT, PROFIsafe on PROFINET and CIP Safety on Sercos III. The right choice follows your controller and drive ecosystem and the safety devices you need to buy. More important than protocol is calculating the end-to-end safety response time, including network cycle, watchdogs and drive reaction, against your required Performance Level.

EtherCAT vs Profinet vs Sercos III: Motion Control 2026