Rods "Spaceship" Scratch built Plasma Cutter build

Ah, here it is.

forum.linuxcnc.org/plasma-laser/33277-plasma-gui?limitstart=0

PID tuning.... did you get anywhere?

I am not an expert at PID, but the advice always seems to be tune the P, set I and D to zero, then add the I to speed up the corrective action, and once you get overshoot, add the D to calm the end of the process down.

There are a load of PDF's on PID tuning online....

Like most things with me there is always a catch..... the catch is you need repeatable data to tune the PID loop I believe.... hence I suspect that you really need to be able to simulate input for your PID loop to correct..

Given you now have sampled data, is it within a table / log that you can reuse to feed back into linuxcnc as a datastream in order to allow you to tune the values....

I must admit at this point I am at a loss as to what element you are using as feedback and what element you are using as error and your control signal.......... [this is something I've struggled with when considering the use of PID with THC]

I know and understand that we are all trying to control the torch height... but the issue is what does the error tell you (lets presume it's voltage error, setpoint - feedack signal [think that is standard to everyone])

so the basic error tells you that your torch is too high or too low

At this point you can use bang-bang control (fire the torch up or fire the torch down) [which is the "traditional" THC control arrangement for Mach3, Mach4, uccnc etc]

What does the P, I or D bit tell your Z-axis to do (differntly than digital up / down control untill the error is zero or switched telling the torch to go the other way)?

Lets presume that the P, I and D bits tell you that you still have an error at the next sample..... what does than mean... what can you do about it (is the error greater or less than it was last sample time) ..... lets presume that the error is less... (we're getting closer to the target / [setpoint])

So what do you want the PID loop to do? Because at this point you will be adding integril action to make your error (and PID loop output greater) but if your torch is say aleady going up.... is this "greater PID loop output" going to make it faster or slower

Sorry I really struggle to see what PID loop is actually trying to do (PID loops with heating or water flow make the heat or water flow greater when the error is still there at the next sample [ok there may be some derivative action if this error sampled is less than the last error!, but all this does is lessen the heat or water flow as we are approaching our setpoint)

Also does (or will) your current X + Y [or A] blended feedrate have any effect on the motion of the Z axis torch hight correction?

If it does not .... then why not given kerf detect at 400ipm will (should be) different to kerf detect at 200ipm [voltage spike] .... likewise the ascent / decent of the torch at 400ipm feedrate should be quicker than at 200ipm as the bevel or bend in the plate its trying to correct should be coming up quicker


As you can see I'm struggling with PID application here.... which is a digital application unless you add in z axis acceleration + feedrate to control with it (digital application >> voltage low, send torch up, voltage high >> send torch down).... PID adds in either distance to move or speed to get there in my opinion... small error move slowly or dont travel far, big error move fast, travel long distance.

Don't get me wrong I'd like to use PID, I've not not figured out to do what yet (speed of z axis or distance to go control)

Explanation here on pi loop control for thc, controls the z axis motion (velocity)
trucutcnc.com/trutracthc.html

robertspark wrote:

Explanation here on pi loop control for thc, controls the z axis motion (velocity)
trucutcnc.com/trutracthc.html

I don't think that the PID objective is any different to the link you posted which clearly shows the difference between vastly superior PID torch control and the bit bang approach used by Mach et al.

As I understand it, the beauty of PID is that it can be applied to any control circuit if the controlling signal (in our case volts) has a relationship with the desired output (in our case Z axis height). So we have a commanded volts signal (say 95 volts for a given material) and a feedback signal (actual measured torch voltage). We don't need to know how much to adjust the torch height, as the PID algorithm sorts that out. So what happens is the required adjustment is fed back to the linuxcnc trajectory planner as an external offset so Linuxcnc says geeze, I'm off course, I better fix that and the trajectory planner makes the necessary adjustment as it knows nothing about the external offset applied by the PID algorithim.

And yes, I think everybody following my journey into this uncharted territory is making the same mistake I did and leaps into making a working config instead of stopping, taking a deep breath, getting to understand the external offset hpid stimulator and building a working config of their machine based on it where all of the tuning and simulation features are available. Once the PID loop has been tuned in the real world in this way, then it will be fairly trivial matter to migrate to whatever cool interface you want to run with.

Also I forgot to mention that because we are only interested in measuring and adjusting voltage, the travel speed of the x & y axes has no impact on our torch height control algorithm. We are just changing the setpoint.. I have not got to kerf crossing control but I doubt that material travel speed or material thickness will have much impact as a void is a void if you stumble into one in error regardless of these parameters.

Finally, unfortunately the last few weeks life and business have overtaken me so I have not had any time to play for a while.

Thanks Rod, I know I'm being a bit thick and do appreciate you taking the time with this one.

I too have been busy, so I know how hobby time goes (+ if you have several projects on the go at once).

Linuxcnc is a mamouth task to get your head around HAL, components and python to try to understand how it all fits together (especially when you arrive here thinking + seeing Linuxcnc offers you the opertunity to software side programme whatever you want where as before it would have had to have been microprocessor based).

Off to understand PID and some of the plasma hal files... linuxcnc.org/docs/html/man/man9/pid.9.html

Rod, Hope I'm not tainting your build thread here (if so, let me know and I'll start my own Journey into understanding LinuxCNC thread).

hmmm... looking at the wrong PID component doesn't help.... hahah

github.com/LinuxCNC/linuxcnc/blob/dgarr/...nts/eoffset_pid.comp

Rod, now your plasma.hal file makes sense....

setp zo.pgain 40
setp zo.igain 0
setp zo.dgain 0.7

setp zo.k 394
setp zo.fnum 0

indicates that you are not using the integril gain setting (although a read of the eoffset_pid component) does indicate the igain may not be used:

When used to regulate an axis offset, the eoffset_pid component servo loop is an outer loop to the LinuxCNC motion loop. Since the inner loop effectively contains an integrator, use of the igain pin is not expected to be helpful and some amount of dgain may be required for stability.

I am not sure about your k factor setting [not got my head around that one...]

Scaling for axis.L.eoffset-counts is controlled by the unsigned integer input pin k; a reciprocal floating point output is provided at the kreciprocal pin for connection to axis.L.eoffset-scale. The default value (10000) for k is equivalent to 0.0001 inches/count (0.00254 mm/count). Proper scaling requires connection of the units-per-mm pin to halui.machine.units-per-mm.

// Make pid gains settings comparable for either inch or mm
// machine-unit specification. With k=10000, 1 count is scaled
// by the axis.L.eoffset-scale == kreciprocal or: 1e-4in ==.00254mm
kfactor = kfactor / (25.4 * units_per_mm);
kreciprocal = 1/((float)kfactor);
dbg_state = the_state;
is_off = !is_on; // convenience pin
the_feedback = feedback;

An interesting read was the:

An optional input pin, perturb, is added to the command input internally. This pin is provided to support addition of a small perturbation signal for testing and tuning the pid loop.

_________________________

Side note question.... what language is HAL written in? I'm using notepad++ as my editor [viewer] and it makes life easier if the correct plugin is loaded / custom language define to read it

Another good read:
github.com/LinuxCNC/linuxcnc/blob/dgarr/...external-offsets.txt

At each servo period, the 'axis.L.eoffset-counts' pin is compared to its value in the prior period. The increase or decrease (positive
or negative delta) of the 'axis.L.eoffset-counts' pin is multiplied by the current 'axis.L.eoffset-scale' pin value. This product is
accumulated in an internal register and exported to the 'axis.L.eoffset-request' hal pin. The accumulation register is reset
to zero at each machine-on.

If using axis.L.eoffset-counts, in combination with eoffset_pid.comp, you probably want to set axis.L.eoffset-scale = 1, so that the PID can properly calculation the target eoffset counts as a multiplier other than "1" probably won't help the error as it would apply an odd gain that the PID could not keep track of [given it's a combination of P, D and maybe Igain]



--- presume you know that the eoffset_pid was updated 8 days ago (not sure that the change was though) but it may have been a tuning / bug fix if you've been busy with life + work.

Robert,
Don't forget to check out the readme and hpid.txt in this folder. Follow the instructions.
github.com/LinuxCNC/linuxcnc/tree/dgarr/..._offsets/eoffset_pid
K factor is something Dewey came up with and originally was set to 10000. Then after reviewing my results, he realised that it was out by a factor of 25.4 for a metric machine hence my 394.

I would exercise care here because I suggested that it was a bit lazy that a hal file needed a setting that was altered depending on the machine units used. I know he's changed this in the latest rebase of the external offset branch.

HAL is its own thing and syntax. I don't view it as a language. Its a way of defining a "circuit" in software by joining components to build systems. I use notepad++ on windows and geany in LInux as its nicer than gedit.

I don't mind the thread hijack.