- Hardware & Machines
- Computers and Hardware
- Mesa Ethernet / QtPlasmaC retrofit experience — lessons from a marginal mini PC
Mesa Ethernet / QtPlasmaC retrofit experience — lessons from a marginal mini PC
- FabLabRacing
- Offline
- New Member
-
- Posts: 10
- Thank you received: 8
This is not a complaint about LinuxCNC, far from it. After working through the issues, I am still happy to be moving forward with LinuxCNC and QtPlasmaC because I think the plasma feature set is excellent. But I do think my experience shows that the “PC side” deserves more attention than I initially gave it.
My setup:
- Home-built plasma table conversion from MASSO to LinuxCNC / QtPlasmaC
- Mesa 7I76EU
- THCAD2 planned
- Ethernet Mesa connection
- QtPlasmaC
- Separate camera-assisted project running alongside LinuxCNC during some tests
One of my reasons for moving away from a closed standalone controller was that I wanted to experiment with a camera-assisted tracing/scanning workflow, somewhat similar in concept to SheetCam’s Scanything. I have been working on a small project I call FabScan, which uses a USB camera mounted to the machine to help trace parts/templates and eventually export geometry. That type of experimentation is much easier on an open PC/LinuxCNC system than it would be on a closed standalone controller such as MASSO.
I originally planned to use a small MeLe mini PC that I already had. It booted fine, LinuxCNC installed, QtPlasmaC launched, Mesa connected, and the machine homed and jogged. At first glance it seemed usable.
The problem was intermittent realtime/Mesa communication errors. I saw errors such as:
- Unexpected realtime delay
- hm2 error finishing read
- Watchdog has bit
- Smart Serial communication error / timeout
- Smart Serial Port 0 stopped
The PC had a Realtek RTL8111/8168 Ethernet controller using the r8169 driver. I tried the usual tuning steps:
- Dedicated Mesa Ethernet interface
- Static IP, no gateway, no DNS on the Mesa NIC
- Disabled Ethernet offloads
- Disabled EEE
- Disabled coalescing
- Disabled Wi-Fi during testing
- Disabled power-management options in Linux
- Increased servo period from 1 ms up to 3 ms and later 4 ms
- Switched from r8169 to r8168-dkms
The r8168 driver helped a lot. The system would run longer, but it still eventually produced realtime delay / watchdog / Smart Serial failures. In my case, the MeLe was simply not boring enough to trust as a control PC.
I also found a separate issue that was not the PC’s fault. My generated config had PID loops driving Mesa velocity-mode stepgens, with DEADBAND = 0.0 on the joints. After homing or jogging, the axes would twitch slightly because the PID loop was chasing sub-step position error. Adding deadband fixed that:
X/Y/Y2:
DEADBAND = 0.0008
Z:
DEADBAND = 0.00025
That stopped the axis twitching.
Eventually I replaced the MeLe with a used Dell OptiPlex 7060 Micro with Intel Ethernet. With the Dell, I tested QtPlasmaC, FabScan/camera load, and NoMachine remote desktop while watching Smart Serial. The Dell stayed clean at a 2 ms servo period. Smart Serial stayed at:
fault-count = 0
port_state = 3
run = TRUE
For over an hour, the takeaway for me:
LinuxCNC can run on modest hardware, but for Mesa Ethernet I would not say “any old PC” is good enough without testing. I would now strongly prefer:
- Used business-class Dell/Lenovo/HP mini PC
- Intel wired Ethernet
- Good BIOS power-management controls
- Dedicated Mesa NIC
- Long latency tests, not just short ones
- Real workload testing: QtPlasmaC, camera, remote desktop, Wi-Fi if used, etc.
I am not posting this to criticize LinuxCNC, again, far from it. QtPlasmaC is exactly why I am doing this conversion. I just think new users coming from MASSO, Mach, GRBL, etc. would benefit from clearer up-front guidance that the control PC needs to be “boring,” not just powerful enough.
In my experience, horsepower was not the issue so much as the details. The NIC, driver, BIOS/power-management behavior, and long-duration realtime stability mattered a lot. I wish I had understood those details better up front, so I am posting this in case it helps the next person avoid a few days of chasing intermittent gremlins.
Please Log in or Create an account to join the conversation.
- tommylight
-
- Offline
- Moderator
-
- Posts: 21727
- Thank you received: 7424
That is what we usually advise here, and by now there are plenty of PC's and some laptops tested and working fine with LinuxCNC.
In general, 4GB and up, Core2Quad would be the absolute minimum usable, avoid i3 Intel's although some do work fine, no spinning hard drives, and no NUC type PC's although some do work fine.
Also, i had/have plenty of new builds, some quite powerful that do work fine with LinuxCNC but would be overkill for a machine controller only, so can also do CAD/CAM on the same PC.
Please Log in or Create an account to join the conversation.
- FabLabRacing
- Offline
- New Member
-
- Posts: 10
- Thank you received: 8
Please Log in or Create an account to join the conversation.
- tommylight
-
- Offline
- Moderator
-
- Posts: 21727
- Thank you received: 7424
Probably due to power saving options being implemented everywhere...
Please Log in or Create an account to join the conversation.
- rodw
-
- Away
- Platinum Member
-
- Posts: 12018
- Thank you received: 4097
I think the minimum spec is i5 (4 core ) with Intel NIC.
People became a bit blase with PC specs until the recent kernels as above, but when I started with Mesa you had to compile the kernel to get the required PREEMPT_RT we took a lot more care with PC selection...
Please Log in or Create an account to join the conversation.
- cmorley
- Offline
- Moderator
-
- Posts: 7340
- Thank you received: 2164
Can you tell us more about this in another thread?. I have been working on a small project I call FabScan, which uses a USB camera mounted to the machine to help trace parts/templates and eventually export geometry. That type of experimentation is much easier on an open PC/LinuxCNC system than it would be on a closed standalone controller such as MASSO.
Please Log in or Create an account to join the conversation.
- FabLabRacing
- Offline
- New Member
-
- Posts: 10
- Thank you received: 8
forum.linuxcnc.org/plasma-laser/58942-fa...ing-scanning-project
Thanks!
Jeff
Please Log in or Create an account to join the conversation.
- skunkworks
- Away
- Moderator
-
- Posts: 350
- Thank you received: 153
sam
PS - my plasma is running a rpi 5...
www.youtube.com/shorts/9-y316bJrGk
Please Log in or Create an account to join the conversation.
- NWE
-
- Offline
- Elite Member
-
- Posts: 223
- Thank you received: 71
Adding to the list, I have a really cheap Uxx and MinisForum mini-pc here with the same shortcomings. I suspect most NUC type mini-pc's are built with laptop type of hardware.I originally planned to use a small MeLe mini PC that I already had. It booted fine, LinuxCNC installed, QtPlasmaC launched, Mesa connected, and the machine homed and jogged. At first glance it seemed usable.
The problem was intermittent realtime/Mesa communication errors. I saw errors such as:
- Unexpected realtime delay
- hm2 error finishing read
- Watchdog has bit
- Smart Serial communication error / timeout
- Smart Serial Port 0 stopped
On the other hand, I have used at least 4 different "fanless industrial mini-pc" from Aliexpress, several of them are running 24-7. None of these have disappointed me yet, but I am still somewhat cautious of them. I like their compact size, multiple network ports, and fanless means I'm not plugging them with dust in dusty environments (hopefully).
Projects where I want solid performance, I sometimes use servers or workstations with ECC RAM. Probably overkill in every dimension. They seem to run LinuxCNC just fine.
Please Log in or Create an account to join the conversation.
- Hardware & Machines
- Computers and Hardware
- Mesa Ethernet / QtPlasmaC retrofit experience — lessons from a marginal mini PC