Advanced Search

Went through this twice, still have no clue what ...
We have a modern THC, fully implemented in LinuxCNC, including PID and closed loop and everything, with a bit to much added functionality for my taste. All made possible by Mesa THCAD.
Have a look at PlasmaC and QtPlasmaC, everything mentioned is already there and working properly, and much more.
THC has a single purpose: to keep the torch the set amount of height from the material while cutting.
Everything else are added features that a THC might or might not have, be it in software or hardware.
-
Proma THC 150 SD is the stand alone version that intercepts step/dir signals from Z axis
Proma THC 150 sends UP/DOWN/ARC OK signals to PC, and the PC makes the moves, so not stand alone, and can be considered closed loop for sure.

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.

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.

Where is the arc ok derived from? Plasma? Reed switch? or from THCAD?
For first two, check the plasma source, not LinuxCNC/Mesa/THCAD

mariusl wrote:

I just discovered that my formula and the one in the QTPlasmaC documentation ids not correct for the THAD2. Those formulas work for the previous release of THAD.
PncConf has the correct formula by the looks of it. Does any have the correct formula for me?

Have you looked at the THCAD2 manual? the formula is in it,

The THCAD2 is scaled the same as a THCAD-10 when jumpered
for 10V full scale and scaled the same as a THCAD-5 when jumpered
for 5V full scale.

You need to plot the voltage or encoder with halscope. I think that is way too low. I would expect around 130 volts. I suspect the THCAD is not properly calibrated. The plot will tell you how long to delay. I would check the input voltage at the thcad with a multimeter.

I did have a machine once that needed about 2 seconds to be stable...

Use halscope to do a plot of encoder.0.velocity pin during a pierce, might be interference, although as you are getting 55 and 75V readings it also seems not right, and this might be due to scaling and/or due to interference.
What divider ratio is Mesa THCAD set to? Usually 1/32.
If this is a new machine, disable auto volts, disable void lock and velocity lock, well disable everything automated until you get the machine working correctly, only then enable the automation.

besriworld wrote:

Well, the reason is very simple Each additional Beckhoff module is a bag of money for the small user.

You need to consider this before selecting a control method.
I've been scouring eBay for various beckhoff modules and the price is not too bad but they are never in Australia so the wait time sucks!
But AUD $132 for above module landed was not bad v's a THCAD given our appalling exchange rate.

A Beckhoff EL3162 has 2 channels of 0-10 volt input with 500v isolation from the Ethercat bus. This could replace 2 THCAD's without worrying about needing encoder inputs.

I don't understand why people want to mix MESA and Ethercat systems even though it can be done.

Hello 
I have managed to get a few motors running with etherCAT, but I still need a simple I/O system with analog out and encoder input, to use a mesa THCAD.

How is it feasible? Do I need a dual Ethernet card? 
The PCs I’m using have a single Ethernet port, so to run both mesa and ethercat I will need another Ethernet system, to have different NICs, right?

thank you.

Installed the THCAD2 and to no ones surprise, it works!
No evidence of the deed though, sorry.

Gents,

Continuing my learning process of LinuxCNC and Mesa cards i've managed (thank you PCW and tommylight!), to start my permanent magnet DC servomotor driven by BTS7960 H-bridges, all hooked up to Mesa 7i95T on the test bench.
forum.linuxcnc.org/configuration-tools/5...-bridges-pmdc-servos

Did some basic PID tuning and motors are not reaching following errors. Ferror is loose however - fine tuning not required at this stage.
On my learning short list now there is two topics:
1) encoder-ratio module
2) Mesa THCAD card. As I'm powering my motors and limit/home switches from old laptop power supply - its voltage sags easily when loading servos so found it good opportunity to practice THCAD and PyVCP by reading power supply voltage and present it on AXIS. 

Ad 1) While reading LinuxCNC documentation i found an interesting function ENCODER_RATIO. First thought was "hey! let's do some experiment and slave Z axis servo to X.". Let's say the final idea is to link spindle encoder with rotary/dividing head servo - i can imaging hobbing gears like that:)
Experiment conditions:
- there is three servos available X, Y, Z so three encoders, all the same ppr = 400
- X will be the master, Z will be slave
- i want Z to turn 4 times slower than X

If i understand the documentation right i did the following:
- detached joint.2.motor-pos-cmd from pid.z.command
- detached hm2_7i95.0.encoder.02.position from pid.z.feedback and joint.2.motor-pos-fb
- connected pid.z.feedback and joint.2.motor-pos-fb with encoder-ratio.0.error
- decided to use one of the switches for slave axis on/off so detached remote e-stop (will not using it now) input hm2_7i95.0.inmux.00.input-06-not and hooked it up to encoder-ratio.0.enable
- connected master axis (X) encoder signals A and B to encoder-ratio.0.master-A and encoder-ratio.0.master-B
- connected slave axis (Z) encoder signals A and B to encoder-ratio.0.slave-A and encoder-ratio.0.slave-B
- set ratio by stating ppr: encoder-ratio.0.master-ppr 400 and encoder-ratio.0.slave-ppr 100

AXIS started with no issues. Checked HAL configuration and what i can see is:
- encoder-ratio.0.master-A and B signals are successfully connected to X encoder
- encoder-ratio.0.enable is ok - turning TRUE when switch is activated by me

And i failed successfully:)
- i can see no change on pid.z.feedback as well as on pid.z.output when i move X axis - no change on encoder-ratio.0.error 

I thing i'm not getting fully what manula says about encoder_ratio. i couldn't find any HAL examples showing correct configuration.
What i found is that unfortunatelly encoder-ratio.0.master-ppr and encoder-ratio.0.slave-ppr are PARAMETERS, not PINS so no chance to make nice 'change ratio' option in PyVCP (imagine you can input different spindle/slave axis ratio and hob whatever spur gear you want!). The only option i see it close LinuxCNC, edit ppr numbers and re-start LinuxCNC to get ratio i want.

My idea was to have motorized dividing head connected and with just one switch make it move in sync with spindle @ required ratio...So it is basically ELS. Ehmmm those dreams.

Anyway, please! Could you guys look at it and poke me in good direction? I did research and tried by myself before i bother you but, as i said before, failed successfully:)
Thank you.

Short answer:

My Powermax is paired with a THCAD-10.  I changed it to 20:1.  It’s served me well with no issues over the years.

Long answer:

forum.linuxcnc.org/plasmac/39999-thcad-1...powermax45-xp#181612

It depends on your machine amperage. No scaling resistors are rwquired. Most people use 20:1 which gives a 200 volt full scale, 125 amps might be better at 30:1. (300 volts)
The thing is that the THCAD is rated for overvoltage of 500 volts. The voltage will only go over 200 volts on piercing when we do not care about the voltage then. During cutting voltage is between 100-170 volts. Keeping the max voltage range low means the readings are more accurate as more of the ADC's range is used. 50:1 is popular with a lot of non-linuxcnc THC's  (probably with a 0-5 volt ADC). That would be better for a THCAD5.