EtherCAT vs Ethernet: what you are really choosing, and the numbers behind it

Every retrofit where a machine shows up with EtherCAT inside the frame and EtherNet/IP everywhere outside it, somebody eventually asks me why we cannot just patch the two together at a switch and call it done. That is usually where the EtherCAT vs Ethernet question starts, and it starts from a bad premise. Both of them run on ordinary Cat 5 with standard IEEE 802.3 frames. Neither of those facts tells you whether an axis holds position when a cable gets yanked out of a drag chain. So here are the real numbers, out of the two organizations' own publications, and where they actually diverge.

Two networks meeting inside one cabinet. This is where the EtherCAT vs Ethernet argument normally starts.

EtherCAT vs Ethernet puts a protocol up against a wire

Take the phrase apart and it falls over. EtherCAT is Ethernet. It uses the physical layer and the frame format out of IEEE 802.3, it lives under Ethertype 0x88A4, and Beckhoff says exactly that on the first technical page of its EtherCAT brochure. What differs is what happens to the frame after it leaves the controller.

On EtherNet/IP the frame carries CIP inside TCP/IP and UDP/IP. Every device holds an IP address and answers as its own endpoint. EtherCAT does something else entirely: the frame is the network, one telegram leaving the master while every node on the line reads out of it and writes into it as it goes past.

So the honest form of the EtherCAT vs Ethernet question is EtherCAT against EtherNet/IP. That one is worth an afternoon.

One frame for the whole line

In an EtherCAT segment the master is the only node allowed to send a frame. Everything else forwards it downstream, reading the bytes addressed to it and inserting its own on the fly, and the frame is held up by nothing except hardware propagation delay. The last node in a segment or a branch sees an open port and sends the telegram back on the full duplex pair.

Sounds like trivia. Look at what it does to the arithmetic.

The shortest Ethernet telegram runs 84 bytes counting the inter-frame gap, and 46 of those bytes are usable for process data. Now give a drive its own telegram in each direction. The drive sends 4 bytes of actual position and status, and takes back 4 bytes of target position and control. Effective data rate on those telegrams: 4/84, which is 4.8 percent. That is Beckhoff's own worked example of the one-telegram-per-node model, and it is the reason the technology exists. Fold every node into a single frame instead and the effective rate climbs over 90 percent, with the brochure putting theoretical throughput above 100 Mbit/s on a 100 Mbit/s wire once both pairs are working.

The bandwidth side of EtherCAT vs Ethernet is not about cable speed. Both are 100BASE-TX. It is about how much of each frame is payload.

EtherCAT vs Ethernet in one picture: a single frame walking every node, against one frame per device.

Topology, and what leaving the switches out actually buys

EtherCAT needs no hubs and no switches, so the cascade limits that shape a conventional industrial Ethernet layout do not apply to it. Line, bus, tree, star, any combination: the machine decides the wiring instead of the other way around. Up to 65,535 devices per segment, which no one is going to hit. Branch ports are already built into a lot of the I/O modules, so a drop line does not mean one more box in the cabinet.

Cable is plain industrial Ethernet, up to 100 m between two nodes in 100BASE-TX, and 100BASE-FX fiber past that.

Then the part that lands on an invoice. An EtherCAT master needs one standard Ethernet port, no interface card and no co-processor, using the MAC that is already there. The timing-critical work sits in the EtherCAT Slave Controller inside each device, as an ASIC, on an FPGA, or as an option in a standard microprocessor, which is also why segment performance does not ride on how well one vendor wrote its firmware. Beckhoff puts the CPU load saving at 25 to 30 percent against other bus systems at the same cycle time.

EtherNet/IP went the other way. A traditional star out of standard Ethernet infrastructure devices, or a Device Level Ring, with an IP address and a subnet plan for every node and a full TCP/IP stack inside every device. That is not a defect. It is what lets somebody reach a drive from a laptop two buildings away, and plenty of people want exactly that.

Where EtherCAT vs Ethernet costs me real hours on site, it is never throughput. It is addressing. EtherCAT can hand out node addresses automatically, nobody administers MAC or IP addresses on the segment, and no IT department has to touch a switch or a router for it.

A cable break is where EtherCAT vs Ethernet stops being close

Redundancy on EtherCAT is cheap, but not free. Run a cable from the last node back into a second Ethernet port on the master and the line becomes a ring. The slave devices already support it, so nothing on the machine gets replaced. The master stack is where it costs you: the break is detected by a software add-on, and on TwinCAT 3 that add-on is a separate license, TF6220. Link detection in the slaves resolves the break with a recovery time under 15 μs, so at worst a single communication cycle gets disturbed. Hot connect gets the same figure, this time as detection time: pull a segment out of a running machine, drop it back in somewhere else, and the changeover is under 15 μs.

Device Level Ring does the same job on the EtherNet/IP side, and its published numbers are bigger. A DLR network wants at least one node acting as ring supervisor, and every node in the ring needs two Ethernet ports and an embedded switch. The supervisor sends Beacon frames on a default 400 μs interval and can be configured as fast as 100 μs. ODVA's Common Industrial Protocol publication, PUB00123R1, puts worst case fault recovery on a 50-node DLR ring at less than 3 ms.

15 μs against 3 ms is a factor of 200. They are measured differently, granted. Practically it means this: on an axis updating every millisecond, one of them costs you a single cycle and the other can cost you three.

And now the part that does not help me sell anything. On a conveyor, a palletizer, most material handling, 3 ms of recovery is nothing and DLR is completely fine. The gap starts to matter when the axis is geared to something that will not wait, a flying shear, print register on a moving web. Pick for the machine, not for the spec sheet.

Both schemes want two ports either way. In a ControlLogix rack that is a dual-port module such as the 1756-EN2TR instead of a single-port 1756-EN2T; on EtherCAT it means keeping the master's second port free for the return leg.

A DLR ring needs two ports at every node, which is why a dual-port 1756-EN2TR goes in the rack instead of a single-port 1756-EN2T.

Clock sync is a tie, and that one catches people out

EtherCAT synchronizes on distributed clocks, calibrated completely in hardware. Time from the first DC slave is distributed cyclically, propagation delay to each node is measured and compensated at startup or continuously during operation, and the clocks end up within much less than 1 μs of each other. System jitter comes out significantly under that. Sync accuracy shows up in the common-features list for every one of the EtherCAT technologies: better than 100 ns.

CIP Sync is IEEE-1588 compliant, and PUB00123R1 puts synchronization accuracy between two devices at better than 100 ns. The same document has CIP Motion coordinating 100 axes on a 1 ms network update to all of them, with axis-to-axis clock sync held to that same figure and described there as readily achievable.

Both sides claim better than 100 ns. Which means anybody telling you the EtherCAT vs Ethernet decision comes down to Rockwell not being able to hold a clock has never opened ODVA's own document.

The divergence in EtherCAT vs Ethernet is update rate, not clock quality. Running XFC, EtherCAT does I/O response times under 100 μs, TwinCAT gets cycle times down to 12.5 μs, and 1000 distributed digital I/Os are processed in 30 μs.

	EtherCAT	EtherNet/IP
Physical layer	IEEE 802.3, 100BASE-TX, Ethertype 0x88A4	IEEE 802.3, 100BASE-TX, carrying TCP/IP and UDP/IP
Devices per segment	Up to 65,535	Set by controller connections and switch layout, not by address space
Clock sync accuracy	Better than 100 ns (distributed clocks)	Better than 100 ns (CIP Sync, IEEE-1588)
Published motion figure	I/O response under 100 μs, TwinCAT cycle down to 12.5 μs	100 axes on a 1 ms network update (CIP Motion)
Recovery after a cable break	Under 15 μs	Under 3 ms on a 50-node DLR ring
Infrastructure	No switches or hubs	Managed switches, or DLR with two ports per node
Master hardware	Any standard Ethernet port	Scanner module or a controller with an EtherNet/IP port
Node addressing	Assigned automatically, no IP administration on the segment	IP address and subnet for every device

EtherCAT vs Ethernet, side by side. Figures from Beckhoff's EtherCAT brochure and ODVA publication PUB00123R1.

When both networks have to live on the same machine

The retrofit from the top of this article is the common one, and it is where EtherCAT vs Ethernet stops being a choice and becomes a plumbing job. EtherNet/IP drives already bolted to the equipment, a Beckhoff controller running the motion, and no budget to rip out either side.

The EL6652 is the terminal for that job. An EtherNet/IP scanner in a 24 mm housing with two switched RJ45 ports, so it sits in line with the other EtherNet/IP nodes, and the EtherCAT master configures its process data. Multicast and unicast both work. Up to 16 simple EtherNet/IP slave devices come in through one generic node, with a catch that sends people back to the drawing board: only slaves whose EDS gives a config size of 0. Data width is a maximum of 1 kByte in and 1 kByte out. EDS import works in TwinCAT 3 and not in TwinCAT 2. Going the other direction, when an existing Allen-Bradley PLC has to see the Beckhoff system as a device, that is the EL6652-0010 slave version, which can present itself as two EtherNet/IP slaves with the second one virtual.

Then there is the parameter that lies to you. Object F800:2A on the scanner, 8000:2A on the slave, is named Forward Class3 to PLC, and the manual describes it as "Forward Explicit Messaging to PLC". Looks like precisely the switch you need. That same line then closes with "(actually not implemented)". Version 3.1.0 of the EL6652 and EL6652-0010 documentation still reads that way.

Say you have four EtherNet/IP drives and a Beckhoff controller. Cyclic data is fine: divide your 1 kByte each way across the four and get on with commissioning. But if the plan was to pull a fault log or push a parameter set over explicit messaging, that is not coming through this terminal, and it is a much cheaper thing to learn before the panel is wired than after.

The EL6652 EtherNet/IP scanner terminal: two switched RJ45 ports, up to 16 slaves through one generic node, 1 kByte of process data each way.

Questions I get asked about this

Is EtherCAT vs Ethernet the same question as EtherCAT vs EtherNet/IP?

In practice yes, and the second one is the version worth asking. EtherCAT is standard Ethernet at the physical and frame level, so setting it against Ethernet compares a protocol to the wire it runs on. EtherNet/IP is what people mean.

EtherCAT vs Ethernet for servo motion: which one do I need?

For servo work the EtherCAT vs Ethernet answer does not come from clock accuracy, which is a wash at better than 100 ns on both sides. It comes from how fast the loop closes and what a pulled cable costs you, and both sets of figures are in the table above. The rule I go by is simple. If a couple of milliseconds of missed updates would put tooling into the product, EtherCAT. Otherwise either one does the job, and the real deciding factor is what the plant already runs and already stocks spares for.

Can EtherCAT traffic share the plant switch?

Not in the way people mean when they ask. An EtherCAT segment is not a switched network you drop other traffic into. If the goal is getting TCP/IP out to something on the machine, the bandwidth headroom lets TCP/IP travel alongside the control data inside EtherCAT instead, and since EtherCAT is not based on TCP/IP none of it turns into an IT ticket.

Does the EtherCAT vs Ethernet choice change the cable I buy?

No. Ordinary industrial Ethernet, 100 m between nodes on 100BASE-TX, fiber beyond that. What changes is the switch count: EtherCAT does not need them, EtherNet/IP is built out of them.

Where I land on it

Most of the EtherCAT vs Ethernet arguments I sit through turn out to be budget arguments with a spec sheet stapled to the front. When the machine in front of you already speaks one of the two, a bridge is almost always cheaper than a network. We keep both sides on the shelf as surplus with a two year warranty: the EL6652 EtherNet/IP scanner terminal and the rest of the Beckhoff EtherCAT range, plus ControlLogix EtherNet/IP modules like the dual-port 1756-EN2TR when a DLR ring is what the job needs.