**A Few Months With LinuxCNC / QtPlasmaC — Follow-Up and Thank You**
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.
