Rods "Spaceship" Scratch built Plasma Cutter build

Rod

It does look like your THC is still a bit "nervous" considering the the thickness (flatness) of the sheet you were cutting. This is pretty exciting as I want to see a working EO PID solution that does away with all the muxing and scaling feedback to keep the motion planner happy (ferror).

A simple way to limit acceleration may be to insert a limit2 component between your Z axis PID component and the step generator. The load pin can be used so that it is only applied when under THC. You may have to use a limit3 before the PID if your axis PID does as much hard limiting as mine. I will not have any time to try this before the end of next month because of travel.

John

John,

I see no problem using pid. All the thc work is normally done by one component.
It's up to the component level to make plasma cutting very easy for users. Maybe rod can add a simple timer to his used component to add a reaction delay in ms. This will solve his nervous floating cutting head to a much more stable floating head.
I dont know wich component he is using, but reacting z axis value after 5v plasma difference voltage is normal. Using this feature will eliminate nervous behaviour at the begin stage. My advice is 5v is 0.5mm reaction.

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

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.

I am not sure this going to quite do it. I will actually be surprised if the Z axis ever gets up to full velocity given the short distances involved and the short time periods we are looking at. If this is actually a case of inadequate acceleration then we need to significantly increase the power we are putting into our Z axis so we can accelerate fast enough. This may be part of the reason all the high dollar commercial THCs actually use servo motors to drive them. I have an old Animatics Smart Motor here that I could try but it is so under powered I doubt it will be an improvement. So my money is still on a delay some where that is causing the mechanics to overshoot the correct position.

I forgot about the .ini values for velocity and acceleration being twice what is actually applied under EO when the stock .5 AV ratio is used. I just assumed that your adjustments were the actual values used. I still believe that slowing down the acceleration will help or cure the problem. After all skipping PID update times is just doing the same thing by a different method.

John