Plasma Questions

I would have thought you have control over Z axis velocity in the.ini file settings. From what I could work out the THC component tells the system to move a certain distance and therefore the default axis settings in the .ini file would apply.

Part of me still says that THC should not update the position until the commanded movement has completed but until I have working hardware I can't explore this stuff. Maybe the range set by thc.voltage-tol is enough to stop seesawing movements.

rodw

This may well be a feature that other systems have to make up for other short comings, all I know is that the present leading commercial systems have this adjustment. It may not even be needed for a Linuxcnc system that is tuned correctly. I intend on having the control set a percentage of the maximum velocity from the .ini file. That way I can change things during a cutting session without editing the .ini file for every trial. I really don't need this because 98% of the time I am cutting the same type and thickness of material.

The THC.comp updates the offset for an arc voltage error once every servo period when enabled and the table is up to speed and the torch is commanded on. The correction (very small for each period) is added or subtracted from the offset if there is an arc voltage error. When enabled and the torch is on the THC.comp does not use the Z axis position or velocity to calculate the offset (correction). When the THC is enabled and the torch is not commanded on the change in Z position from the last period is used to see if the torch is moving in the correct direction to correct the offset. Then depending on the sign of the error and the offset the offset is either set to 0 or adjusted in the correct direction.

While this may not be quite as sophisticated as the PID servo correction advertised by the commercial offerings there are many here who claim it works well for them. I intend to try and use the stock THC.comp first to test this out. I think that by implementing the corner hold (called Velocity Anti Dive by one leading commercial offering) the way it does this thc makes up for its simplicity by the short correction (servo) period used.

John

I think you and I are both finding a number of weaknesses in the LCNC Mesa/THCAD/THC model. I have an external THC which might have been much simpler to implement.

Chainsaw and sandpaper approaches aside, some things I think about

• Why we are stuffing about setting cut voltages when we are really interested in cut height. Surely we should be sampling the voltage once we are at cut height during the leadin.
• Lack of PID control
• Not waiting for commanded moves to complete before the next adjustment
• Inability to sample voltage fast enough to apply any signal processing (40 usec only gives 5 bits of resolution)

I think the whole thing needs redesigning and eventually I'll have a go at it.

Using an Arduino is viable to read voltages at 40 usec. I have not pulled one out to play with but it seems they are able to sample voltage reasonably accurately at 20 usec so sampling using a ISR at 40 usec should give enough time to get other stuff done without lockup from ISR overruns. I think it would be viable to generate a frequency to send to THC to send voltages back to LCNC as the generated frequency would only be changed every 40 milliseconds.

rodw wrote:

Lack of PID control

PID shouldn't be hard to set up. But it might be fun to tune, and PID enable/disable conditions would need some thought.

I agree with most of the points you make here
however, I think Arduino by itself is not reliable enough for the application
at any point I asked about the following board from Mesa.

store.mesanet.com/index.php?route=produc...83_88&product_id=126

I think a reimplementation of the THC component need to be done to add PID and also decoupling from the Z axis
and let it work as a standalone entity that can receive all parameters need to work.

At the beginning, I was thinking to use a raspberry or beagle bone to implement the THC using machinekit, but this lead me back to LINUXCNC, and I realized that it can be done on the same machine using a new component.

One of the advantages of having it as a stand-alone entity is that the g-code gets less complex, ant the implementation easiest (once the proper component is developed)

Now I using a good quality stand alone THC plasma, the communication is RS232 but I have a lot of delay in the communication

Also used the proma but it is also not what I need

rodw

The THC mode of operation you describe is one I call "arc voltage sampling". This mode is implemented in most high end commercial THCs. Most small shop/hobby THCs don't offer it. You will find that I described it and my desire to implement it in one of my previous posts. Also if look at the posted screen shots of my GUI modifications you will see a radio button that at this time does nothing to select this mode of operation. The voltage sampling wants to take place after torch reaches programmed cutting speed plus any additional selected servo delay. This is the usual problem for most small shop/hobby THCs is that they are unaware of actual machine velocity on a real time basis. I have note from a HT guru on another forum who states that for good THC you need a servo loop with at least 25Hz bandwidth. I expect it is over kill to go much faster at typical air plasma speeds. You can download the manuals for HT THCs from their website if you want to check out the features and control modes. One of your fellow country men has done a lot of THC work with the UCCNC controller, He goes by beefy over at plasmaspider, I think he is in the southern part of the country.

I still intend to use the stock THC component at first. If it doesn't work well then I will investigate changes. I am sure it work better than my existing stand alone Torchmate AVHC box! The corner hold ability alone will be a big bonus.

John