How good is Ethercat motion control?

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.

Now that I'm using my ethercat machine daily, I'm seeing some odd issues. Sometimes on startup it will trigger error b2 on the drives rapidly. this is apparently a timing conflict with modbus. Happens every dozen start ups.

Today i had a new one. I homed that machine, and then it began triggering joint errors and limits exceeded despite being nowhere near limits. i had to reboot the computer, and then it was fine.

If the machine starts "fine", it stays fine, but there is some flakeyness with the start up sequence.

Another thing I notice is when I tune my servos perfectly in the omron (usb) software, when they start under linux they are resonating, vibrating like 1 micron in travel. I don't know if that's a linuxcnc thing, and ethercat thing, or just a stupid omron thing.

Other than these quirks though, its great and I would not switch back for anything haha.

This is just an interpretation from reading similar issues here(forum), not empirical experience.

But the pattern you describe (random errors on startup, weird state after homing, reboot fixing it, and then everything staying stable) really looks like something in the startup / state synchronization / handshake is sometimes not lining up cleanly.

It doesn’t sound like a continuous motion control problem, more like: sometimes the system and the drives don’t start in exactly the same state (mode, position reference, command bits, etc.), and once that initial state is “clean”, everything behaves fine.

Things like edge-triggered vs level-triggered command bits, timing of enable/mode changes, or initial position/mode sync could easily lead to this kind of “works most of the time, but not always at startup” behavior.

So my guess would be to look closely at the startup sequence and state/mode/position synchronization, rather than at EtherCAT performance or servo tuning itself.