Advanced Search

You should not need ui changes for these pins to work.
There is a description on the pins on the page before this one.

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.

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.

the fact that you get a bad spi payload is good, keep it at 32 probably

This may sound forward of me, but how long is your cable?

a kernel trace also provides interesting data. when I did that on a 4 core i5, the servo thread was using about 200 usec and slept for 800 usec. Its the random incursions that take the servo-thread beyond 1000 usec that are the issue. I don't think Wireshark will show the full picture.

It's because:shows up in every line.

I could modify the g-code filter to remove it, but honestly your Post Processor needs to be modified, there's a lot of stuff that needs cleaned up in your cut file. That, G1 lines with no XY movements associated, G00 being separated from the corresponding XY moves, etc.

I am attaching your file, with all of those Feed rates removed, except for one at the top. That will let you do RFL to show you that is in fact the issue.

You should take a look at the nc_files/plasma folder to see examples of what's expected. metric_wrench.ngc is a good starting place.

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.

 

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.

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.

Thanks, it was just a file location error. The new pins are showing up now, but from what I understand, I need to modify the Qdragon UI to use them? Or how can I use these new pins?

Many thanks for the reply. Just SSH'd onto the machine - yes, Intel Ethernet controller. I'll wait for morning (and for the icicles to disappear) and try the recommended settings in that link, and report back.

Have you looked in the bottom beside the battery. its a normal place for the upgrade modules ?

Probably Intel network card, so have a look here for use of ethtool to set the rx to 0
forum.linuxcnc.org/27-driver-boards/4750...i96s-a-little-jitter

Here are the complete files

I've ended up fighting the hal loader.

#

---

# M19 ORIENT – single driver / multi‑sink form
#

---

loadrt orient count=1
addf orient.0 servo-thread

loadrt pid names=pid.o
addf pid.o.do-pid-calcs servo-thread

loadrt mux2 count=1
addf mux2.0 servo-thread
loadrt or2 count=1
addf or2.0 servo-thread

# --- Orient PID tuning ---
setp pid.o.Pgain 0.05
setp pid.o.Igain 0.0005
setp pid.o.Dgain 0.0002
setp pid.o.maxoutput 60
setp pid.o.error-previous-target true
setp orient.0.tolerance 0.05
setp orient.0.angle 0

# --- One signal name, declared once and fanned out ---
net orient-bit spindle.0.orient => orient.0.enable
net orient-bit => or2.0.in1
net orient-bit => mux2.0.sel
# separate signal drives the encoder’s index enable input
net orient-arm-index orient-bit => hm2_7i92.0.encoder.05.index-enable

# --- Run enable OR gate ---
net run-enable or2.0.out => hm2_7i92.0.7i77.0.1.spinena
net spindle-enable => or2.0.in0

# --- Orient angle / feedback wiring ---
net orient-angle spindle.0.orient-angle => orient.0.angle
net spindle-revs hm2_7i92.0.encoder.05.position => orient.0.position

# --- Orient PID loop ---
net orient-cmd orient.0.command => pid.o.command
net orient-fb hm2_7i92.0.encoder.05.velocity-rpm => pid.o.feedback
net orient-out pid.o.output => mux2.0.in1

# --- Normal spindle path and output switch ---
net spindle-output pid.s.output => mux2.0.in0
net spindle-vfd-out mux2.0.out => hm2_7i92.0.7i77.0.1.analogout5

# --- Completion flag back to controller ---
net orient-done orient.0.is-oriented => spindle.0.is-oriented

#Error in file ./spindlecontrol.hal:
# Pin 'orient-bit' does not exist
#Shutting down and cleaning up LinuxCNC…