- Posts: 12160
- Thank you received: 0
Useful Plasma Thread
8 years 2 months ago #115927
by rodw
Replied by rodw on topic Useful Plasma Thread
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.
I just tried to boot into Linux on my desk PC but it failed for some reason and left me at the command prompt. GrrAnyway, 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:
Attachment not found
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).
Attachment not found
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.
Please Log in to join the conversation.
8 years 2 months ago #115936
by rodw
Replied by rodw on topic Useful Plasma Thread
Russians or Dutch, I'm not sure....
fperiod is not guaranteed to be exact if the thread is early or late so testing for equality is not going to work every time. you need to do a if... else if... else if ... and test for > T1, T2 etc. Steal The buffer approach using pointers I shared and see how you go. Just change the BUFFSIZE to 5000.
fperiod is not guaranteed to be exact if the thread is early or late so testing for equality is not going to work every time. you need to do a if... else if... else if ... and test for > T1, T2 etc. Steal The buffer approach using pointers I shared and see how you go. Just change the BUFFSIZE to 5000.
Please Log in to join the conversation.
Time to create page: 0.278 seconds