Which LinuxCNC HW for 2026+?

I have been using LinuxCNC/EMC1-2 for more than 20 years by now; currently, on five machines (one with Machinekit) - and every single of them now has issues with newer versions:

- probe tripped during movement  
- queue full  
- joint following errors  

It's a wild mix of interfaces and computers, two parallel ports, two Mesa cards, a RPi 5 (Mesa) and a Beaglebone Black (PocketNC).  
I have never ever experienced joint following errors before. I also made millions (guessing here, hehe ) of probe movements without any issues.  

Now, I'm not even able to finish a single milling job longer than 15 minutes without error.

I already went back to Wheezy (this also halved the latency again) and duplicated the setups without containing any probe pins,  
just to keep things going. Of course, I always forgot to switch back and rammed mills into the length probes and elsewhere.

While browsing the forum, I noticed that many others seem to have the same issues, but there have to be working setups.  

One machine was already converted to grbl. I always thought about this as a joke, and I now have to use my phone instead
of my handwheel - but it's actually not that bad. I also checked Acorn CNC and Masso, probably the way to go unless I find
time to develop sth on my own - the 87th standard. Lol.


I would like to stick with LinuxCNC, so which >>working<< setups could you propose?


Thx,
AS

What versions of LinuxCNC?
What GUI is being used?
What "probing" is used?

Oh sorry, this was not meant as a complaint or rant.

My intention was to make clear, that basically all my completely different setups are failing to work - including
the ones which include a Mesa card. Which, at least to what I understood, is recommended or even the only option
after the golden parallel port times.

Issues started with 2.8.x on Wheezy. At that time, only the probing was affected, but I found that out
much later, after I deleted the 2.7 partitions bc I probed on a non-LinuxCNC machine.
Fixed it with a flipflop:
forum.linuxcnc.org/38-general-linuxcnc-q...move-deadlock#332412   
But there's sth wrong in the code, probably related to the RT system, as a longer latency makes things
significantly worse.

Everything with Bookworm and >=2.8.x doubled the latency and also brought the bespoken queue and
now also joint following errors. This does even happen on a Machinekit setup, after upgrading to a
tool center point capabale version on a five axis machine.
The most annoying thing is that there is no workaround. Not even increasing the following limits to absurd
values do help here. So the machine stops (without any mechanical errors) and there's nothing one can do.
On one machine this excusively happens with a rotary table. Randomly.

GUI doesn't matter. I only use the "blue one" and Axis. Stock settings, no plugins or mods - zero difference.


I have this Mesa Ethernet thing and the RPi variant. Both also have these issues with a bookworm setup.
What are you using?
 

AkkiSan wrote:

What are you using?

 

If this was for me, by now probably over 70 or 80 (i would bet more) of Mesa cards, on over 40 machines, from EMC2 to the latest LinuxCNC 2.10 still in development.
Most of them use LinuxCNC 2.8.4, and all of them use old "enterprise" computers and laptops from Dell, HP. Lenovo and Fujitsu.
But none of them use probing, so far.
-
Do the issues occur without probing involved?

With newer operating systems like bookworm, there is a huge number of additional features outside of linuxcnc that affect real time and network latency. Plus the world is more complex so there is more hardware to consider. Plus the big push to power saving features has permeated everything.

If you are not using a parallel port, the old latency test is not relevant. Its all about network latency. The network is not real time but we want it to be.

Probably the biggest issue is using the wrong network driver (mainly on Realtek NICs), followed by NIC interrupt affinity. By default all system interrupts including the NIC's are placed on CPU 0 so we need to move the interrupt for your NIC to another core.  

I think this means you now need at least a 4 core CPU (eg Celeron J1900 or higher) as you need to have CPU 0 for the system and a core for the NIC and a core for the real time servo thread.

In summary, if you are not prepared to oprimise the OS for a RT environment, stay on an old and obsolete OS and hardware.

Other possibilities:

Make sure you use a pncconf or MesaCT created configuration for Mesa hardware
as these use a number of techniques to minimize timing related  following errors:

1. Using the DPLL to retime the position sampling
2. Using the stepgens in velocity mode with a PID loop
3. Using a small PID max_error value so a dropped packet does not cause a
large bogus correction because of stale stepgen position data

#2 is especially important

To check network latency:

sudo chrt 99 ping -i -q -c 60000 [mesa_card_ip_address]

This will run for one minute and then print timing statistics.

Other possibilities are using a newer Kernel, the default RT kernels used with Debian seem
quite poor latency wise (using 6.17 currently and its decidedly better than earlier kernels)

Pinning the Ethernet IRQ to the last processor also helps (if you also isolate the last processor
on your grub command line, or however you do it on the RPI)