Category: Plasma & Laser
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.
