Rods "Spaceship" Scratch built Plasma Cutter build

I played with external offset too - It was initially designed for a jog while paused solution. The offset inputs are counts. (not a big deal but odd when trying to do this type of thing) I stripped it down and tried to do a simple pid voltage loop - I could not tune it to save my life. (granted - it could be me) It has been a while - but I was thinking it was the simple tp that was integrated into it. (it has been a few months so I may be remembering wrong.

Basically - Torch voltage -> PID -> Scale volts to dist -> limit3 -> Offset -> Zaxis seems to work (atleast in the initial testing) (there are a lot more logic and such of course...)

Yes - linuxcnc doesn't know that there is an offset (though you do) - but you take care to remove the offset when 'you' want to.

Rod

Please find attached a block diagram of where I am headed using the EO branch. This is based on the good working THC I have using mixed HAL components and the EO branch. I think that this will be the best of both worlds, no following error trickery required and good THC. Once everything is dialed in again (how many times have I done this now/) I try and use some deadband in the THC PID and see what the effect is.


John

Andy

I have no good engineering reason for this, it just works to control following error. The Z axis pid is used for positioning the z axis under program control and the error output is the "position" error between the commanded position and the actual or feedback position. The error is only used to keep the z axis command position synched with the actual position when the THC PID is enabled ( to control following errors). The THC PID generates a velocity command to the step generator based on the arc voltage error and is only active when the THC is enabled and there is not a corner or kerf crossing hold active. The kerf crossing component also does the real time decoding from the G code file for forced height hold.

I really tried hard to get the eoffset_pid to work for controlling the torch height but never got it to work well. I am literally several hundred test cuts into this. I think the problem is using the arc voltage error to create a position correction. What I am doing with my THC (which is how most of the successful THCs use) is to create a correction velocity command based on the arc voltage error.

I have a HAL only THC that doesn't use any part of the EO branch that works really quite well, much better than my old commercial external THC ever did. The only down side is that the Z axis position is not tracked while the THC is active and it takes a bit of HAL and G code trickery to prevent (fool) following errors.

I don't know if my approach will work if you are not using the Mesa hardware for step generation and arc voltage measurement. What I am posting is for everyone's information. I am leaving it to the good coders to come up with the definitive generalized solution.

John

Skunkworks, thanks, when you first spoke of this, it did not make sense to me and now it does. I know exactly the relationship between volts and torch height based on a regression analysis of 9000 readings.

So its 7.53 volts per mm with 99.4% confidence!



Thanks to everyone else for feedback. I really feel that LinuxCNC is going to catch up in the plasma cutting stakes.

Tommy, the best bet is to compile the dgarr/external_offsets branch and make play with the the Axis/external/offsets/hpid sim.
Then when you are ready, follow the instructions to make a live config. which won't take long. Just copy over known good ini file parameters as most of it will be done for you. You might need to unlink some default signals to use your own. There are also many useful tuning windows with the sim so retain as many as them as you can when making your live config. In the plasma section, I do have a nice component to parse the thcad 10 calibration but it not hard to do.

Tommy

Which configuration do you want? The external offsets version or the HAL only version? I didn't get the new EO version done today because of other work. A word of warning my coding is very sloppy with many interconnected parts What is the best way to package this? Just zip the configuration directory?

John

skunkworks wrote:

I played with external offset too - It was initially designed for a jog while paused solution. The offset inputs are counts. (not a big deal but odd when trying to do this type of thing) I stripped it down and tried to do a simple pid voltage loop - I could not tune it to save my life. (granted - it could be me) It has been a while - but I was thinking it was the simple tp that was integrated into it.

I had a good look at the eoffset_pid component again today. The counts are calibrated with a scale which defaults to. 0.00254 mm per count so I can't really see why counts rather than a distance offset should make any difference. But I am way out of my depth. As I wrote this, I wondered if a 1 khz servo thread is just too fast. Anyway, the OCD side of me wants to change the scale to 0.001mm because I don't do imperial units (or in this case derivatives thereof) so we'll see what happens. The other idea I just had was to skip some servo thread cycles before processing adjustments.

Anyway, my new plasma consumables arrived so I have some ceramic shields again.
Also my new misalignment shaft coupling arrived late this afternoon. (Shown here partially separated).



This is 20mm in diameter. I have to bore it out to suit my shafts. I also looked at a 30mm diameter coupling that could handle 15 Nm
of torque but after some research, it seemed best to not oversize the coupling. This one is good for 5 Nm backlash free and the acceleration forces is calculated at about 3.3 Nm so we have a 1.5x safety factor which seems adequate.

Anyway, hopefully tomorrow we will be backlash free and ready for further testing.

rodw wrote:

Skunkworks, thanks, when you first spoke of this, it did not make sense to me and now it does. I know exactly the relationship between volts and torch height based on a regression analysis of 9000 readings.

So its 7.53 volts per mm with 99.4% confidence!

After a bunch of searching online - I found a few references to .004/volt. (what I have been using) And I think that falls pretty close to what you are finding...