Advanced Search

**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.

Get rid of the relay boards, opto boards and the 5V rails, you do not need them and they will only add to stuff collecting interference, Mesa 7i96S has isolated inputs and outputs, just check what output to connect the torch on as there should be two types of outputs on it.
Put the Mesa board in the middle vertically with LAN side down, THCAD and power supplies to the right and drives as they are.

Looks like its going to be a tidy control box. If it were my build I would put the 7I96S closer to the drives to shorten all the drive wiring, keep the THCAD2 and relays close to the 7I96S for the same reason.

  
This is my first time building something like this cnc plasma table so looking for opinions on what I can improve before wiring everything.
7I96S
THCAD2
24v 16Amp psu
5v 4 amp psu
dm556 drivers (x, y1, y2, z, a)
5v relays for arc and torch control
8 opto isolators for limit switches (2 x, 2 y1, 2 y2, z, z touch)
e stop
If you room for improvement please chime in and let me know before I attempt to not make a rats nest of wires. 

1. I use Mesa for everything.
2. Not sure, but i think those are EXE something or another, and yes, LinuxCNC should work with them, from what i read here.
3. Yes, see Mesa THCAD
4. Guessing, stepper with current control should do, servos should also do, but for more info/ideas look for BAX EDM on youtube.

Hu Gemox,A plasma cutter generates a huge amount of electrical noise, so all signals should be galvanically isolated.For this reason, I would not recommend the Mesa 7i97. Instead, I would use a 7i83 for the analog outputs, since it provides galvanic isolation from the rest of the control system.To determine the complete hardware configuration, the machine’s existing electrical schematics would need to be reviewed.A THCAD2, or an equivalent interface, is necessary to measure the plasma arc voltage. This voltage measurement is used by the torch height control to maintain the correct distance between the torch and the plate.I would not recommend using a stepper motor for the Z axis, as it may not be able to achieve the required speed.How are you planning to generate the G-code?

Hi, I'm building a plasma table (QtPlasmaC, THCAD-300) around a 7I80HD-T and would like to run the ST8_PLASMA config — 8 stepgens plus the two encoder inputs is exactly the right fit for this machine.

I see PIN_ST8_PLASMA_72.vhd ships in the 7i80hdt.zip hostmot2 source, but there's no prebuilt 7i80hdt_st8_plasma.bin among the stock configs, looks like it was only ever built for the Spartan 7I80HD.

Any chance of getting a Trion build of that config a test. If it's easier to point me at the Efinity project setup to build it myself, that works too.

Thanks!

tommylight wrote:

That would be redundant as LinuxCNC is the motion controller.
In short:
-buy a Mesa 7i96S and a THCAD

I was wondering if I should buy direclty the 7i95T as it has all needed i/o and encoder feedbacks for up to 6 axis.
What you suggest ?

I plan to set up a separate head in the future for plasma and who knows maybe even a spindle for drilling.

Thanks Heaps Stefan and Rod I just received the THCads and am about to draw up my Transition drawings from masso to linuxcnc.
Have either of you used Qelectrotech for drawing before as I am about to give it a go. Supposedly there are libraries for Mesa boards available.

qplasmac is a complicated GUI. Normally, it is set up assuming a mesa card using pncconf. 
I think I  would try running up pncconf and build a rough config for a 7i96s. You just need a template for all of the plasma specific pins so pick a mesa pin to use for each. don't worry about scaling the axes etc
Then I would copy the pin layout to your hal file and make sure any plasma  specific stuff in the ini file is copied to your ini file, then replace the Mesa pins with your lcec pins. 

With linuxcnc running open another window and type halcmcd show pin lcec should list all your Ethercat pins and you could probably filter out just the inputs or outputs

Also reviewing recent plasmac configs on the forum may help
I have one but its a very complex one with lots of custom stuff so would not recommend following it github.com/rodw-au/showstopper/tree/master 

In the qtplasmac GUI, there is a couple of fields for THCAD parameters. Set the offset to 0 and scale to 1 and use the actual torch volts. You may need to use mult2 to calculate the full scale voltage. Alternatively, use the scaling field which might be better.

Good luck
 

tommylight wrote:

Yes you should leave them out, as noted above the only usable way for DMM drives is in Position mode as they have a delay in position signal outputs.
Also the encoder input will be used for THCAD if you want plasma.

By "leave them out" I meant to not connect them at all. But then how the linuxcnc will know where it is at certain point ? I will probably loose a part of precision with not connecting the encoders feedback.

tommylight wrote:

Yes there is, Mesa 7i85 or 7i85S should have 4 encoder inputs.

I see this card has a DB25 connector to connect it to the computer I suppose, or does it gets connected to the
7i96s ? Sorry for dumb questions.
Is the DMM Dyn4 encoder output supported by the Mesa 7i85 ?

tommylight wrote:

No, not per se, but LinuxCNC can be programmed as you need it, so a simple G04 P1800 will make the machine wait for 30 minutes at the first cut to preheat the material.
Same for outputs and solenoids, everything can be automated and even add a side panel with settings and buttons and stuff.

OK for this, I will take a look better on it once I install it in a virtual machine.

saxa wrote:

I see the board has only one input for the encoder feedback. But I have 3 drives, so should I leave the encoders
signals from the drive to linuxcnc out ?

Yes you should leave them out, as noted above the only usable way for DMM drives is in Position mode as they have a delay in position signal outputs.
Also the encoder input will be used for THCAD if you want plasma.

saxa wrote:

Or there is a way to connect all 3 encoders to the board ?

Yes there is, Mesa 7i85 or 7i85S should have 4 encoder inputs.

saxa wrote:

Also has LinuxCNC some settings to make the preheat , and open the various gasses vales at ceartain time already in or should I be doing this from zero up ?

No, not per se, but LinuxCNC can be programmed as you need it, so a simple G04 P1800 will make the machine wait for 30 minutes at the first cut to preheat the material.
Same for outputs and solenoids, everything can be automated and even add a side panel with settings and buttons and stuff.

In an Ethercat world, I think you can use a Beckhoff 0-10 volt analog interface as it has similar over voltage specs as the THCAD. People have cracked the Hypertherm Ethercat machines here. But do use industrial Ethercat cables in a HF world

I recently bought an old plasma + oxyfuel machine to retrofit and resell. I awaits me first finishing some other projects. I plan to connect ethercat servos directly to a linuxcnc pc. I have not yet studied the serial interface for the big XPR plasma power unit that came with it. On a previous project I used mesa + THCAD, never heard any complaints from that one.

Welcome. Have a look in the ethercat section. There are a couple of stickies. There is a seperate Ethercat master application that runs on the Linuxcnc  PC and there is another driver that connects Linuxcnc to the Ethercat master which in turn talks to all your slaves. You should be able to use a Beckhoff analog input (0-10 volts) to read the divided torch voltage. Other than that, it will be similar to what Tommy described for Mesa hardware. The Beckhoff modules are rated for over voltage of 500 volts, same as the Mesa THCAD. I'm uncertain that other brands of analog inputs have this protection. I can't help with oxy.