How good is Ethercat motion control?

Is there a real delay with rigid tapping when we're using ethercat?

I'm running my old okuma mill with a mesa setup and it's working just fine. Although max I've tapped is 600rpm.

Don't really know how fast the Spindle encoder is read by the mesa. But i guess it's definitely updating every servo thread cycle.

Can't we expect the same performance for rigid tapping with ethercat?

If your current Mesa setup already delivers stable rigid tapping, and you’re not confident you can guarantee the same margin of performance and robustness with EtherCAT, then from an engineering and risk standpoint there’s no strong reason to change.

EtherCAT can certainly work and can reach high performance, but it requires more integration effort, tuning, and understanding of the drives and control cycle to achieve the same level of determinism you already have with Mesa.

If the goal is simply to get “the same performance” you already have, the change becomes technical risk without a clear benefit. In that case, the most conservative and rational decision is to stay with Mesa.

Moving to EtherCAT only really makes sense if there is a clear advantage (architecture, cabling, drive availability, industrial standardization, etc.) and you’re willing to invest the time needed for commissioning and tuning to extract the same level of performance.

I'm trying ethercat for a new machine. It makes sense to go with ethercat because it originally had absolute servos for all axis and for the tool changer magazine. If I'm running a mesa setup i need to get the absolute encoder reading at the start via modbus.

I've been running Linuxcnc for a ling time for 3 of my machines. Also like to play with ethercat as it's more interesting.

I've seen a video of ethercat running at 8kz servo thread but also found out that some Ethernet ports do not support that due to power saving Ethernet stuff.

Running a faster servi thread might solve most of these issues i guess?

I see — if you want to explore EtherCAT and your machine already has absolute servos (including the tool changer magazine), that’s a perfectly valid reason to go that way.

Just be aware that you’re moving from a very KISS, well-understood Mesa setup into more of a “welcome to the jungle” zone: more knobs to turn, more things that can affect determinism (NIC, kernel, DC config, drive modes, etc.), and more commissioning work before you get the same level of predictability.

Coming from Mechatrolink, where a lot of this is implicit in the controller, with PC-based EtherCAT it looks like you first have to make these fundamentals explicit (DC, cycle stability, NIC behavior, jitter) before worrying about pushing the servo thread frequency.

A lot of people on the forum are still exploring this space too, so expect some iteration and experimentation along the way. And those who are really “in the trenches” with EtherCAT on LinuxCNC can probably give you much more concrete numbers and practical advice.

Marcos wrote:

with PC-based EtherCAT it looks like you first have to make these fundamentals explicit (DC, cycle stability, NIC behavior, jitter) before worrying about pushing the servo thread frequency.

 

Probably depends on the hardware you choose.
I have installed 3 ethercat Linuxcnc systems in the past 12 mo. and have not needed to touch any of the above mentioned tweaks. Everything just worked and is being used daily with no glitches yet. All of them running stock servo-thread of 1 mS.

Now just recently bought a 4 axis ethercat stepper drive, this is the first ethercat hardware I've used that was not fully supported out of the box.

Plus I have two half finished LinuxCNC projects that don't count because they're not yet in use. The ethercat part went together easy enough but other aspects of these two projects are needing more work.

My reply was specifically addressing the “8 kHz” comment earlier in the thread. That question mixes three different layers in one sentence:

The internal drive loops (current/velocity/position), which often run at several kHz inside the drive,

The EtherCAT communication cycle, and

The LinuxCNC host servo thread on the PC.

Many drives advertise 4–8 kHz internal loops, but that does not mean running the host servo thread at 8 kHz is either necessary or trivial. Once you start talking about pushing the PC/host loop to a few hundred microseconds, things like DC configuration, cycle stability, NIC behavior (EEE, IRQ coalescing, etc.) and jitter stop being “details” and become the main engineering problem.

So my point was not that EtherCAT needs heavy tweaking to work at 1 kHz — it usually doesn’t with decent hardware — but that when someone brings up “8 kHz on the host”, it’s important to make these fundamentals explicit, because that’s a completely different class of problem than the drive’s internal control loops.

Also, in the context of the original goal of “OEM-like” behavior: in most industrial controllers that does not mean an 8 kHz host loop. It usually means fast internal loops in the drive, a stable CNC/interpolator cycle (often 1–2 kHz), and good determinism with low cycle-to-cycle variation.

And just as an architectural note: even at 1 kHz, Mesa-based systems tend to be more “KISS”, because the time-critical I/O timing lives in the FPGA on the card, not in the PC and NIC. With EtherCAT on a PC, the host remains the time master, so platform details matter more — which is fine, just a different set of trade-offs.

I don't think its right to say Ethercat needs heavy tweaking to do 1 khz. My first ethercat machine worked straight out of the box. Ethercat is designed for 1 kHz and to imply its not suited to play with LinuxCNC's servo thread is just plain wrong! What it does internally is none of our business but many slaves run much higher sampling times and pulse trains than 1 kHz!

People just want to excessively complicate things for no reason.

However with later kernels, any RT system not just CNC needs careful tuning for optimised performance. This applies to space shuttles, Mesa cards and ethercat slaves. In fact, I believe that ethercat protocol is superior to the Mesa hm2-eth protocol. I have  a couple of videos about optimisations in a playlist. Here is the first of them.

 

rodw wrote:

In fact, I believe that ethercat protocol is superior to the Mesa hm2-eth protocol.
 

My experiments with the hardware support that belief. Last I tried this, I could physically unplug the network cable; hm2-eth crashes, on the other hand, ethercat lcec properly reports the affected slaves as no longer responding, I reconnect the cable and all functions promptly recover without a restart.

Hi Rod,

I think there is a small misunderstanding about what I was trying to say. I’m not claiming that EtherCAT needs heavy tweaking to run at 1 kHz — I fully agree that with decent hardware, a 1 ms servo thread often works out of the box, and EtherCAT as a protocol is designed for that class of cycle times.

My comment was specifically aimed at the earlier “8 kHz on the host” remark. That kind of statement mixes three different layers: the drive’s internal loops (which indeed run at several kHz), the EtherCAT communication cycle, and the LinuxCNC host servo thread. Once you start talking about pushing the host loop into the few-hundred-microsecond range, things like DC setup, cycle stability, NIC behavior (EEE, IRQ coalescing, etc.) and jitter stop being details and become the main engineering problem. That was the point I wanted to make.

When I said Mesa tends to be more “KISS”, I meant it in an architectural sense, not as a value judgment. EtherCAT is a full industrial fieldbus: multi-vendor, DC, flexible topologies, designed for distributed systems — that’s a big strength. The hm2-eth approach is intentionally simpler and focused on talking to the card, with the time-critical I/O timing living in the FPGA. Different tools, different trade-offs.

I also don’t think a fully centralized-in-one-panel setup is where EtherCAT really shines. It still works perfectly fine that way, and in fact I think it’s great that many people run it like this today, because that’s exactly how the LinuxCNC + EtherCAT integration gets exercised, debugged and improved in practice. Its main advantages just show up much more in distributed architectures, with drives and I/O spread across the machine and synchronized via DC.

For context, I’m actually looking at EtherCAT for my own project because it’s a modular machine (about 2 m per module, ~16 m total), where a distributed setup makes a lot of sense. That’s exactly the kind of case where EtherCAT really shines. So my comments are not “against EtherCAT”, but about keeping the architectural layers clear and not mixing up internal drive loops with very high host loop rates.

So yes, EtherCAT at 1 kHz on LinuxCNC works fine in many setups, as you said. My concern was only about the conceptual jump to “8 kHz on the host”, which is a very different class of problem.

Hi,NWE,

That’s a fair point, and I agree: EtherCAT (and the lcec stack) has a much richer network/state model and clearly handles link loss and recovery more gracefully than hm2-eth. That kind of supervision and recovery is a real advantage of EtherCAT as an industrial fieldbus.

My earlier comment wasn’t about network robustness or error recovery, but about where the time-critical control loop lives when people start talking about very high host rates (like “8 kHz on the PC”). Those are somewhat orthogonal aspects: EtherCAT is stronger as a fieldbus and in fault handling, while the Mesa approach keeps the tight I/O timing in the FPGA and is more “KISS” on the host side. Different strengths, different trade-offs.

Thanks for the discussion, and all the best to everyone doing the hard work in the trenches.