Rods "Spaceship" Scratch built Plasma Cutter build

Thanks for the support guys. It looks like you really want me to nail this. The support is so much appreciated.

Grotius, I had a look at the opa code and its essentially using the same technique for scaling, just its dealing with a much simpler and predictable geometric shape. The component I am using is the eoffset_pid.comp component from the original external offsets code. It has been removed from master branch when the eoffsets was incorporated because it did not work.

John your idea of the limit 2 makes some sense. The EO adjustments must pass through the PID to reach the stepgen. I guess we also have control of this by manipulating the ini file max velocity and max acceleration settings and I do have a tuning window for them. I did not have much luck with it except to notice yesterday that reducing the acceleration increased oscillations.

I thought the other thing to do is to add a mult2 component on the eoffset-pid output to the axis eoffset counts. This would allow me to reduce the calculated number of adjustment steps applied to the offset which hopefully might prevent overshoot

Grotius, with regard to the reaction delay, I did think of writing a skip component that ignored some servo cycles and only applied an offset on every second or third servo cycle. This also would allow time for a motor to move to the offset position before asking for further adjustment.

Anyway, the feedback all helps to make me think! We all know a lot more then when we started this journey so I'm confident we are close to a result!

Rod

I don't think you need to use the mult2 component if you want to change the scaling. As I recall you can set the EO error to counts and the reciprocal independently using the appropriate pins. I recall trying many combinations and never really hit a sweet spot but feel I understand the problem much better now so it might be worth another try.

Right now I am limiting my max Z velocity at 110ipm when under THC and the acceleration is the same for axis moves and THC at .145g (55ips^s). So I guess about the best I can do is a 30 degree slope on the 2mm plate I use.

Did limiting the Z axis acceleration under THC change the frequency of the oscillation or the amplitude or both? If you look at the output of the Z PID and compare it to the actual arc voltage it should be clear if you are overshooting or undershooting the response.

John

You can try all of the above mentioned, or you could do it the crude way, namely get some capacitors with different values and wire one directly to the input of the THCAD. That would slow down the voltage fluctuations and ultimately the THC response.
I have 2 THC of my own design, made to do over 10Khz of sampling and corrections, and that has proven very unnecessary, and troublesome i might add. Adding some low value capacitor to the A/D converter input was the only thing needed to slow it down to very usable levels. One of them is in production work for the last year working perfectly. The second one i will try to install in the following days if time permits.
Mind the polarity and try it with a 1uF/50V at first, see how the Z axis reacts.
BTW, Proma does use relays on the ouptuts, very small ones so they are pretty fast. On a fine tuned machine it can do at least 2" over a foot of length easily ( that is 5cm over 30cm length ). It can do much more but requires the toma config to adjust the reaction speed.

Thanks guys. I'm not really sure if reducing the acceleration response will help much with the model I'm using. Here is a plot with reduced acceleration and greater oscillation



You can compare that with plots a couple of pages ago.

Tommy, I'm not really a hardware guy and Dewey cautioned against any type of filtering. I know Peter suggests a lowpass filter on the torch volts which I have not added. Skunkworks mentioned PCW suggested a lowpass gain of 0.02 from memory. If you go back a couple of pages, you will see a voltage plot with no THC and its very smooth. The other smoothing technique used in plasma is to compute a moving average. I've written a component to do this for kerf crossing and I was going to break it out as a standalone component.

The more I think about this, the eoffset counts are held in an accumulator register that is reduced every time the counts are applied to the trajectory. This is fine in a geometric sense if you are machining a cam lobe as its a steady state but in the case of torch volts, we have a random signal. I kind of think that the offset adjustments are stacking up before the hardware can fully apply the adjustment. I think I will write a skip component that if configured for say a skip 3, it will hold the eoffset adjustment to zero for two cycles and then apply an adjustment on the third. The offsets will still be correctly calculated but hopefully, the hardware has time to reach its adjusted position.

Then the next approach might be to scale the offset before applying it.

Rod

It is really hard looking at screen shots at the chosen scales to tell much. It does look like the frequency of oscillation reduced by about 30% when using the limited acceleration. By counting I got about 10hz on the first example and about 6 hz or 7hz on this last one. The voltage scales are too coarse to really tell much about the amplitude on the screen shots but look to be about the same. Your just going to have to do the measurements off a live halscope so you can expand scales and get real numbers. At this point I think keeping the maximum velocity up to the normal axis velocity and reducing the acceleration to around 980mmps^2 (.1g) is about right and maybe even go to 98mmps^2 (.01g). Right now you are trying to run your Z under THC quite a bit faster than I am. Tommy's 2"/12" is a much slower response than I am using and even slower again to what your settings indicate you are trying to achieve.

The inner workings of the EO aren't that clear to me. I figured we just kept correcting the error until it was gone like a normal PID. If the error has not been removed during the first period we don't zero it out for a normal PID. Is this part of the problem applying position corrections twice in series?

John

John,Thanks I forgot to mention we trick the external offsets into using 100% of the actual velocity and accel by doubling the real values in the ini and applying a 50% offset ratio so you need to halve the values shown. We can do this because THC control and normal axis movement is mutually exclusive. So I'm actually similar to your settings (1000 mm/sec/sec accel vs your 980).

I've written this component this morning which will allow me to both scale the output from eoffset_pid.comp and also skip some servo cycles. I'll see how it goes once I get it installed.