- 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: 18
- Thank you received: 14
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
-
- Away
- Moderator
-
- Posts: 21943
- Thank you received: 7471
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: 18
- Thank you received: 14
Please Log in or Create an account to join the conversation.
- tommylight
-
- Away
- Moderator
-
- Posts: 21943
- Thank you received: 7471
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: 12156
- Thank you received: 4149
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
- Away
- Moderator
-
- Posts: 7368
- Thank you received: 2181
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: 18
- Thank you received: 14
forum.linuxcnc.org/plasma-laser/58942-fa...ing-scanning-project
Thanks!
Jeff
Please Log in or Create an account to join the conversation.
- skunkworks
- Offline
- Moderator
-
- Posts: 351
- 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: 261
- Thank you received: 80
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.
- FabLabRacing
- Offline
- New Member
-
- Posts: 18
- Thank you received: 14
Back in July, I posted about the PC and realtime issues I encountered while converting my home-built plasma table from MASSO to LinuxCNC / QtPlasmaC. Now that I have been using it for a few months, I wanted to follow up and, more importantly, thank the LinuxCNC community.
The short version is that I am very happy I made the conversion.
At this point I have cut roughly a dozen actual parts and spent a large number of hours setting up the machine, troubleshooting it, experimenting with it, and generally just playing with it. None of those hours were wasted.
The Dell OptiPlex 7060 with Intel Ethernet has proven to be the “boring” control PC I was looking for. After some additional tuning, including CPU isolation and changes to how my camera project delivers frames, I have been able to run QtPlasmaC and FabScan together for hours without realtime, Mesa, watchdog, or Smart Serial faults.
I still stand behind the main point of my original post: with Mesa Ethernet, the details of the PC matter more than raw horsepower. The NIC, driver, BIOS and power-management behavior, and long-term realtime stability are more important than whether the computer looks powerful on paper. A modest business-class PC with Intel Ethernet has worked much better for me than the newer mini PC I originally tried.
What has changed since July is my understanding of LinuxCNC itself.
LinuxCNC / QtPlasmaC can definitely be challenging to set up and dial in. There are a lot of layers, and there are plenty of opportunities to configure something incorrectly. At first, that can make it seem unpredictable.
After working with it for a while, I have found the opposite to be true. LinuxCNC is actually very predictable. When something does not work, there is normally a logical reason for it. It may be a signal polarity, a HAL connection, a configuration path, a file permission, a post-processor issue, or a setting I did not completely understand, but there is usually an identifiable cause.
More importantly, LinuxCNC gives me the tools to find that cause. I can look at the HAL signals, see the machine state, follow what the controller is doing, and change the logic when necessary. Once I began to understand how the pieces fit together, troubleshooting became much less intimidating.
I also think LinuxCNC is easier to get into now than it was a few years ago. One of my previous problems with Linux-based projects was that a traditional Google search would often return information that was several versions out of date. AI-assisted searches have helped me sort through that, especially when I include the specific LinuxCNC and QtPlasmaC versions in the question.
The documentation also seems better than I remember, although it is possible I am just getting older, slowing down, and actually reading it this time.
The QtPlasmaC feature set has lived up to my original expectations. The material handling, probing, THC operation and visibility, Arc OK handling, cut recovery, scribing, hole processing, and operator feedback all feel like they were designed specifically for plasma cutting rather than added to a general-purpose CNC interface afterward.
Cut recovery is probably one of my favorite examples. If a cut stops, I can use Reverse to back up along the actual cut path, stop wherever I want, and press Cycle Start. QtPlasmaC then performs the normal plasma-start sequence, including waiting for Arc OK before continuing. When cutting larger parts, that is a very useful production feature rather than just a convenience.
The openness has also allowed me to do things that would be difficult or impossible with a closed controller. I was able to connect and configure my existing MASSO MPG pendant through the Mesa card, integrate the THCAD-2, customize the QtPlasmaC interface, and continue developing FabScan alongside the machine control.
FabScan was one of the main reasons I started looking at LinuxCNC in the first place. It uses a USB camera mounted to the machine and LinuxCNC motion to trace existing parts and templates, with the eventual goal of exporting usable geometry. It is still very much an ongoing experiment, but LinuxCNC gives me access to the machine state and motion control needed to build it. I am not limited to whatever features the controller manufacturer decided to include.
For perspective, I have used GRBL, ChiliPeppr/TinyG, Mach3, Mach4, MASSO, Langmuir Systems’ MR-1 Cut Control, and now LinuxCNC. If I build another CNC machine, I am almost positive it will be a LinuxCNC machine.
That is not because I now think every other controller is bad. MASSO, for example, remains a very solid and reliable controller. For someone who wants an appliance-like system, does not need much customization, and stays within the intended configuration, it is extremely easy to recommend.
The difference, in my opinion, can be summed up this way:
MASSO is easier until you need something it does not support.
LinuxCNC is harder until you understand it—then very little is off-limits.
Finally, I want to thank the LinuxCNC community.
A project like this only exists because people contribute their time to writing the software, developing QtPlasmaC, maintaining the documentation, designing hardware such as the Mesa cards, and answering questions from people like me who are still learning how all the pieces fit together.
The help I received made a real difference. Even when the answer turned out to be a single setting, an inverted input, or changing a 1 to a 0 after several hours of troubleshooting, someone was willing to help explain what that setting actually did and why it mattered.
When I wrote the original post in July, I hoped my experience might help the next person avoid a few days of chasing intermittent PC and realtime gremlins. After a few months of real use, my conclusion is that the “boring PC” advice still stands—but LinuxCNC / QtPlasmaC has absolutely been worth the effort.
Thank you to everyone who helped me get this far.
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