Useful Plasma Thread

Hi Rod,

Today i have tested the component on a real plasma machine. It work's realy amazing !
It's real time responding to the user interface ( screen ) input signals, so if you change settings like pierceheight, or travelheight,
you see the machine is direct responding on the input signals. It's always nice to see a machine executing your orders real time.

One little issue i had and solved, when i use a glade spinbox and add a value of 2.5mm cut height, the component code was not responding. Machine stayed in pause. When i use full value's for this item, it worked directy. So it is a float signal, but maybe i missed something here. The problem is in fact outside of the component.

I now go further with the probe function, restart function, etc.

For my user interface, i want to make a xml file load in coupled to the component input value's, at this way we can load tool list's.

Hi i am thinking about the Mesa equipment that measures the actual THC arc voltage input and how to implement this voltage input value to the new component.

I added a short list that is connected to the new component at this moment. It's a list that works, names can be changed.


If we add in the component a input from the Mesa ad board: We can add an optional calibration value for Mesa hardware, that we can calibrate with a volt meter, but for now not important.
in the component : In the postgui.hal :
So if we have the voltage input, let's say 267 volt dc on our linux plasma screen. What does this say to us?

1. We have to make a voltage input reaction channel. Let's say 5 volt's.
2. The THC delay function at start. Not the Pierce delay, but THC delay at start in seconds. This is the time THC is not responding,
cause of fluctuating voltage during plasma start. Stable arc voltage is usually up 1.5 to 2 seconds and monitoring only at cut height.
3. If we cross a kerf or stay for long time in a corner, we need some of " corner lock? " or " pierce gap? "
For both item's we can make a formula. But i think a good formula has to have a Arc voltage time logger for a periode of 3-5 seconds, with log's for 0.1 seconds, and must be able to interpolate the logged data, when " corner lock ' or " pierce gap " is set true.
It's not as easy as making a minmax component. This is about logging the gap and the corner. The corner has also a speed issue we can use as input value. But the cleanest way is to use a voltage logger.

Who has input?

For the logger, maybe i have a idea :

If we log the plasma arc voltage continue for 5 second's, we can make the minmax. We can calculate the perfect value.
But we can also set the perfect value by hitting a screen button when the plasma arc is visual perfect.

If during cutting there is a big hole, or gap, or kerf cross, we have the :

1. voltage thc reaction input ( 0 to 20 volts dc, standard set on 5 volts )
2. thc correction speed ( z-axis thc correction speed integrated in the function, just as pierce speed, etc )
3. The interpolated perfect destination height during the past 5 seconds of logging
4. The time value within we react to voltage differences. ( 0.1 to 5 seconds )
5. The minimal torch height control possible value in mm
6. The maximum torch height control possible value in mm
7. Hysteris

In my opinion 5 seconds is to much for anything that has to do with plasma, but i do see the reasoning for having say 1 second of min/max values to get a median value and use that as a reference point for the cutting ahead.
Just as some additional info that is not verified in any way shape or form, the PROMA uses small relays for the output so i doubt it can do more than 10 to 20 pulses per second and that 1/10 or 1/20 of a second is enough for the torch to fire and settle voltage enough to continue cutting without issues.
It is also enough to cut at 7000mm/minute on a fairly flat sheet of metal. It is not enough to cut corrugated metal plates that are 0.6mm thick.
On the other side, the THCAD with any Mesa board can measure the torch voltage 1000 times per second, and that is to much for what it needs to do, but it is perfect for that corrugated 0.6mm plate given the Z axis is capable of moving fast enough.
Then again, i wonder, if a servo motor with encoder can count RPM and adjust the speed 1000 times per second, and keep a constant speed easily, why no one got to implement that same servo loop for controlling THC voltage ??? It already has everything implemented except the spindle output would be coupled to Z axis position. Also no servo control should be active before getting the ARC OK signal and subsequently it would have to cut that servo control at an M5 instantly to avoid having the torch move up or down. That would also require having voltage limits that would govern at what voltage should the servo start and stop, say start at 90 and stop servoing at 130.
To tired, need badly some sleep.

Its exciting to see so much development while I sleep on the other side of the world I just tried to boot into Linux on my desk PC but it failed for some reason and left me at the command prompt. Grr

Anyway, a couple of things.

Mesa THCAD-10 calibration
You don't need to worry about calibrating the Mesa THCAD as PCW has already done it for you for each individual board and applied a label to each board.

This earlier post is a component to decode the THCAD-10 data using that calibration data and has a pin to output the current volts. forum.linuxcnc.org/plasma-laser/32585-scalethcad-component .
Its tested and works well on my config.
I'm still not sure why we use the raw voltage (maybe only for display purposes) as the encoder frequency could be used without conversion.

If you grab a couple say of 48v power supplies and connect them in series, you have 96 volts and you can apply that as the input to your plasma cutters voltage divider board to check functioning. I found this useful.

Corner Lock
This thread includes a corner lock component that I have used for a long time so its proven and working. It outputs a signal to say hold the THC function forum.linuxcnc.org/plasma-laser/32658-thc-cornerlock-component
So this simply looks at the current velocity adjusted for speed override and asserts a hold signal when it falls below a set threshold say 80% of the commanded velocity.

Kerf Crossing
The attached chart shows what happens to torch voltage when crossing a kerf (data from a hal plot at 200 Mhz sample time:

So if we use a moving average, we can compare the change in voltage over this time period with the average over the last 100 readings and if it differs significantly, we hold THC behaviour. In practice however, I think a single servo period is too short to be doing the comparison with as normal hysteresis around the torch voltage set point might be enough to trigger the component from one period to the next.
Torch Sampling using Moving Average
I have not published this before so the man page might be wrong but this component calculates a moving average for BUFFSIZE readings (currently 100 but can be changed in the code) and samples the Average Torch volts when a signal from a delay component after ArcOK goes true. Its been tested enough to know it works (I think, at least I know the buffer does not overwrite other memory).



Conceptually, a moving average is very simple using a loop but in the servo thread we cannot use loops so we do some tricks separated into a separate procedure avgarcvolts().

We use pointers to read the readings into the buffer but if we sum the values and allow the buffer to fill (during the THC time delay), we subtract the oldest reading in the buffer and add the newest buffer reading. With this in mind, in a circular buffer, the oldest reading is the one in front of the current pointer position (assuming the buffer logic wraps the pointer from the last buffer position to the first automagically).

Its worth mentioning that the torch should not be sampled unless its near (say 95%) of programmed cut velocity as its possible that the trajectory planner may have reduced the cut velocity below what has been requested for a given line segment at the time you sample the volts. So that is the reason for the Case statement and the component will sit patiently in an ARMED state until this occurs.

Next Steps
My next step was to separate out the moving average into its own component so it can be used for both Kerf Crossing and Torch sampling. I think I should include the ability to create multiple instances with a different buffer size as it might be useful to have a long average and a short average (of say 5-10 readings) for different comparisons.

I also think that the THC component should be kept totally separate from the touchoff component. I'm not tested it yet, but I suspect that there would be merit in moving the THC component onto a separate slower thread (maybe at 200 Hz?) to allow time for the motor to reach its commanded position on a given adjustment before moving it again. This is just based on a lot of reading I have done about PID control and some comments from Hypertherm shared on my Spaceship Plasma Build thread.

I hope this helps.

tommylight wrote: On the other side, the THCAD with any Mesa board can measure the torch voltage 1000 times per second, and that is to much for what it needs to do,\.

Tommy posted while I was writing my last post. I think he confirms my thinking about keeping the actual THC component on a seperate thread where it can be running at a slower time frame (or it skips a few servo thread cycles between actions). Thanks Tommy!