Thought experiment: Let's design a modern THC (+ Closed loop discussions)

Hello,

Let me start off with the purpose of this thread. I've never built a plasma CNC and I've never used a THC. The purpose of this thread is partially to confirm some of the research I've done and partially to probe as a bit of a thought experiment, as from what I can see, things seem to be in a transitional state between a few control schemes. I don't know if what I've identified is valid, or if there's a reason behind it. Maybe it doesn't matter, but either way, I thought it might be fun to design a system (At a high level) from scratch and ask "what if?".


Let's take a step back and first talk about closed loop, older analogue controls and the like as that's quite important. (Or at least, my understanding. I'm basing some of this on an old Cincinnati Sabre 500 VMC with Fanuc controls I researched a while ago as I was looking to purchase it - It turns out that a 4t machine is a logistical nightmare, but the control findings were interesting.)

In ye-olde-days, you had motor drives with an analogue velocity signal. The drive didn't know what the position was, nor did it care. The motion control managed the position, and you had a full closed-loop setup. This was, I suspect, because back in those days, sharing digital signals over multiple devices was a pain, so it was easier to keep the digital stuff inside the motion controller and to have a fully analogue motor driver with analogue signals. An interesting part of this was the spindle motor orientation used for the tool changer - The spindle drive had a motor orientation board which was connected to the encoder. This meant that when the motion controller stopped the spindle, the spindle drive would automatically park it in a specific orientation. The motion controller didn't control this, it just told the drive to sort it out and the responsibilities were clear.

Next we have our standard step/direction drives, with stepper motors operating in a fully open loop. The motion controller assumes that when it commands a movement, that the motor and driver will keep up and hopes for the best. We know about the limitations, so let's not dwell.

After this, we have the hybrid closed-loop setups with step/direction signalling controlling either a "closed loop" stepper or an AC servo. (Which is closed-loop by nature) Some would say that these are not true closed-loop systems, but as long as there's a fault signal being fed back into the motion controller, it really is closed-loop by definition. Some servo drives allow a second machine encoder for increased accuracy.

Most of the more expensive Centroid offerings include ways to close the loop right back to the motion controller, but I believe this is more for compatibility with older hardware. (See above) I don't believe there's any benefit in a new setup as long as the motor drive can report a fault back to the motion controller; they are both closed-loop, just with different responsibility splits.


I wanted to take that detour about exactly what closed loop means because I think it applies to THC. There are many approaches, but I think it's also worth considering where the respective responsibilities should live between each component, and I think a good test is whether or not the system could, at least in theory, support buffered motion planning. I know that doesn't apply to LinuxCNC, but I think it's a good benchmark for responsibility splits either way.


As with motor drivers, there are many ways of approaching THC:
- You have "fully" stand-alone systems such as the Proma unit, which intercept the Z-axis motor control and over-ride it mid-cut.
- You have fully closed-loop systems where the THC is implemented within the motion controller in software with a hardware interface such as the Mesa THCAD.

I think most people would say that software solutions are superior as they can look ahead, implementing features such as anti-diving. However, from my research, I'd argue that the stand-alone systems are not actually standalone; there's a lot of confusion regarding responsibility, as both parts in these standalone systems control Z axis position. I'd also argue that a purely software solution isn't ideal when you start getting into Ethercat and certainly doesn't allow for offloading via buffered motion planning. I would propose that there's another way.


Fully stand-alone THC, with "fully" no longer in quotation marks. Consider the following statement: The motion controller does not care about the Z-axis position for a CNC plasma machine at all. It cares about the target arc voltage, it cares about anti-dive, it cares about the initial torch height - But it doesn't directly care about the torch height. What if the motion controller told the torch height controller about the target arc voltage, when to start/stop the torch, what initial torch height and dwell to use when starting, and when anti-dive should be considered? What if the THC handled probing and piercing itself, if it fully and directly controlled the Z axis, including the limit switches? What if the THC told the motion controller when it was good to start the motion, rather than just when the ARC is okay?

This is the step which I think is missing. You could wrap all of this up into an Ethercat device and it's a lot closer to being able to handle buffered motion. (Although it's not perfect, as the X/Y motor drivers would need to wait until the all-clear from the THC before they start their motion.) It could handle all things plasma, including gas and current control (E.g. Hypertherm's RS485 interface), it could report back all of the diagnostics (Such as current arc voltage, current torch height relative to the probe position, information about the torch tip. I think this would also be much closer aligned to the modern Fibre laser setups with how their focus control works.


I'm curious about people's thoughts. Have I made any mistakes or misunderstood anything? Is it nonsense or even just a waste of time? I'm also hoping my explanation on closed loop helped others understand what it really means, as it took quite a lot of research to get my head around what exactly it meant and why "proper" CNC machines used to have velocity control.

The best plasma controllers don't have a THC. Instead, the torch height control is done internally by the motion controller. Because the motion controller is all seeing, it knows when to apply anti dive and other corrections because it is THE MOTION CONTROLLER.

This is the approach Linuxcnc takes if you use QTplasmac plasma controller GUI. QTplasmac and its plasmac component take full control of the X axis so motion commands are only in the X,Y axes. In fact, any Z axis motion is stripped out of Gcode files when they are opened.

All you need to do is to feed Linuxcnc the torch voltage and it can use its robust PID routines to control the torch height. You can do this with a THCAD2 from Mesa electronics or in an Ethercat world something like a Beckhoff EL3162.

The THCAD2 is a voltage to frequency converter. It is connected to an encoder and the frequency is converted to a voltage inside Linuxcnc. The EL3162 reads the (divided) voltage directly.

There is a very high linear correlation between torch voltage and torch height so torch voltage becomes an ideal process control variable for torch height control. This is outlined in the Plasma primer in the docs. linuxcnc.org/docs/stable/html/plasma/plasma-cnc-primer.html 

The capabilities of Linuxcnc already far exceed anything from Centroid as the collective minds of open source provide much higher intellect than can be achieved by a closed team.
 
Open loop drives are ideal for plasma use because there are no irregular cutting forces so the system is perfectly predictable. A correctly designed open loop stepper system will use the enormous low down torque to provide high accelleration to minimize the times when corner lock is required. They will only loose steps if the original design is poor.

Linuxcnc does not care about what drives are in use as it just works in device units. Open loop, closed loop, analog, step and direction, ethercat are all the same once installed and configured.

Okay, I don't think I've done a very good job of explaining what I was getting at and why. I also think in retrospect the suggestion of a modern THC may have been taken as an offensive dig at what's already in LinuxCNC - It's certainly not intended to be that way and my thoughts are not aimed at any one platform.

I'm in full agreement that an integrated system offers many tangible benefits over the completely separate systems that you can buy off the shelf today, both in terms of anti-dive and also in terms of co-location of configuration.

The point I was trying to make was that the standalone hardware that we have today is a frankly weird setup, which seems confused about responsibility. The Proma SD is the perfect example of this confusion, but even the non-SD version is still a bit confused.


To try and make my point clearer, consider motor drivers. The old way of closing the loop was to run everything back to the motion controller and have a dumb motor driver (or amplifier). The "modern" approach is to have two loops - A "smart" driver which closes the loop with the hardware, then a second closed loop between the motion controller and the motor driver. (Step/Direction out, fault in) The advantage of the new approach is that each unit is smaller and better defined, it allows you to change the motor/driver combination for any which follow the same contract. It also allows for a higher bandwidth control loop on the motor side of things.


My thoughts were the same for THC:
- The current standalone solutions are weird. (See above)
- The software solution is very similar to the old analogue motor driver solution, with one massive control loop over the top of everything.
- It therefore stands to reason that there's a version of the standalone solution that deals with target arc voltage rather than position, with two closed loops that are more akin to the modern drivers that we have. A solution which still supports the software THC benefits of anti-dive support. One which would be applicable to all motion controllers, just as motor drives are today. One that could even communicate with the motion controller over Ethercat.

In this scheme, the motion controller gets much simpler. It doesn't need to know or care about anti-dive, or how to pierce and dwell, or to know when to strip out Z motion or really know anything about plasma. It just needs to output coordinated target arc voltage as it does the positions for the other motors (Strip the units and Volts are the same as mm or inches to the motion planner), and it needs to output the current motion velocity so that the THC can deal with that complexity.


Is that a clearer and less offensive way of explaining it, or am I just spouting nonsense? I'm sorry if I am, it can be hard to explain something when it's stuck in your own head.

An important aspect to keeping as much smarts in LinuxCNC as possible is that
complex control systems (like plasma control) work on all supported hardware. As
long as  LinuxCNC has enough control bandwidth, its an advantage to have a single
portable extensible and flexible solution with a single control locus (that has access
to all motion variables)

Do you really want to re-invent and maintain a control system that LinuxCNC can
do internally just as well? Buffered systems like Mach require this type of external
hardware, real time systems Like LinuxCNC do not.