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

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?
 

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)
 

Peter, I am curious if you have tested pinning the NIC IRQ to a non RT core (say second last core). From my research it was better to put the NIC on a different CPU to the RT program which will be running on an isolated core.

There are so many sources of latency to quell on newer hardware and Linux versions

I am hoping that the increasing interest in Linux (thanks to Windows stupidity) doesn't completely bloat Linux into
a slow pig of a system just to satisfy the new masses that don't want to learn anything more then how to turn the
computer on and watch streaming videos.  

Yes I am somewhat guilty of that myself.

Pining the Ethernet IRQ to a non-isolated core  would have the same effect
as not pinning the IRQ at all (especially if irqbalance is disabled as it seems
to be in the standard Debian LinuxCNC distributions)

Thanks, all.

In general, I like the Ethernet solution, especially because it comes with a built-in galvanic isolation.
What I dislike is, that this more or less rules out all notebook solutions, bc I need a network connection.

From what I experienced, but maybe it was all just bad luck, is that all internal WIFI connections do not work,
except for a couple of devices with a PCMCIA wireless card. I did not try every possible combination, but also
USB to Ethernet adapters seem to have a severe impact on latency.

Is my 7i91 too old maybe?
Of course, I set up everything with the help of pncconf and used the default settings wherever possible.

I had latency (network) test running for days without issues; I programmed a Python script to let the A/B tables
rotate for hours flawlessly; but five minutes of probing and error - one real longer milling job and joint error.
I spent hours in front of the HAL scope, just to catch this magic moment. I even had a camera recording it.
Nothing was caught in flagranti.

I now, just for fun, developed a USB to SPI MCU board and started to mod some of the LinuxCNC SPI
code for the 7c81. Not sure yet if isochronous transfer is possible or interrupt transfer would clog everything.
This would be my preferred (notebook) solution.


Which computers are you using for the 7i91? Whenever I browse through all of this here, I only see
10+ years old systems at work (like tommylight’s Thinkpad collection, hehe).
What about a top modern one?

And just to make sure, you all mean PREEMPT-RT, right? Not RTAI.