THC accel/decel

[beefy]

Keith it is great to see that you have your THC up and running. I have waiting a long time to see it happen.

Since quitting the excavation game and doing a job, I've had very little time to really FOCUS on design. I was always broke in the excavation game but I did have a bit of time to study / design / test things. Then a few months ago I woke up on a Sunday morning with a nasty pain in my back. It was a kidney stone and I ended up having 5 weeks off work. That gave me some time to play again. I designed a touch screen remote pendant (pre-made touch screens - you just program them) for my Neuron system but simply could not find any way to control the Z axis, even with C# code to control the mouse clicks on the screen, in an attempt to do virtual clicks on the Neuron screen buttons for Z up/down. To cut a long story short, I spat the dummy and focused on my own bang bang THC. Got the very basics working on the bench then took a gamble and ripped out the Neuron and wired up my bang bang system - much to my surprise IT WORKED (cough gag, etc). It's just a rats nest of wiring at the moment and I'm expecting a bad connection will happen sometime and stop it working, but I have a lot more work to do to add more features like closed loop hole marking, auto torch refire, etc, etc.
Haven't touched it for quite a few months now. With family and other stuff that needs seeing to in the small amount of time outside work, I hardly get any time to get stuck into it any more. A job is nice and safe, but it's also like a prison.

I did get that dot line marking thingy working with Arduino (use direct AVR programming now), but that was ages ago, when I first designed the closed loop hole centre marking board, but never found any use for the line marking and didn't pursue it further. It would just do plasma dot marking along a path. It's just a distant memory now LOL.

Keith

[Vmax549]

Keith Your Boys must be about grown by now (;-) By the way my UCCNC still says "Gday"on opening.

(;-) TP

[stirling]

The screenshots show a test of a controllers ability to respond to a test THC which is trying to take a Z axis from 10 steps above zero down to zero.

The first screenshot is Mach3 through the parallel port.

Mach3

The behaviour is exactly what you want. The controller simply responds to the THC down signal and puts out down pulses (note the pulses are evenly spaced i.e. no accel/decel ramps). As soon as the THC sees Z==0 (after 10 pulses) it cancels the down signal and Mach responds immediately by issuing no further step pulses.

The second screenshot is the response of my UC300ETH_5LPT.

UC300ETH_5LPT

Notice that after 10 pulses (which are evenly spaced because accel is set very high) the THC deactivates the down signal. However, the controller continues putting out pulses almost as if it still thinks it needs a decel ramp even though it isn't actually decelerating. After the 11th pulse Z == -1 so the THC activates the up line. However the controller ignores it and continues putting out 2 more down pulses (note the dir line is still down).

From now on the controller is out of phase with the THC and continually tries to play catchup (actually forever). The result being that instead of reaching the steady state it oscilates around Z==0. (the 3rd screenshot zoomed out)

UC300ETH_5LPT zoomed out

[cncdrive]

Yes, the controller controls (reacts to) to those signals in a 1msec loop. We have already discussed this earlier, so it is not a new observation.
I don't really understand what the problem is, because even if there is infinate acceleration setup and the Z is set to a quite high for example 10m/min velocity then the Z axis still only moves 0.16mm in 1msec.
So, the worst case scenario is that with infinate acceleration and 10m/min velocity the Z axis will overtravel with 0.16mm.
I do not think that this as a problem in real world, I mean it looks a problem on a scope, but in real world I don't think that anybody will set the Z velocity to 10m/min high value and that the stepper motor could jump to that speed without acceleration and also the theoritical worst case scenario of 0.16mm overtravel is so small...

[Vmax549]

YES it is noticeable in the real world. Why do you think I mentioned it as well IF it was not a problem.

(;-) TP

[cncdrive]

Because 0.16mm is 0.00629 inches. And nobody runs a Z axis with infinate acceleration with 10m/minutes feedrate, because the stepper motor would simply stall. So, that feedrate with infinate acceleration with that high speed is even theoritical and so the real world overrun is much less than that. A 5m/min value is closer value to a possible realworld application and then the max. overrun is only 0.08mm, but i doubt that the stepper would still not stall if you will try to run it with that high speed with infinate acceleration.
So, this is all just theory which is not even possible in real world and so in real world that error which you see on the scope is not even there, it is so small.
I'm saying that you have to be realistic when you connecting the theory and measurements and real world applications and requirements.
If you connecting the dots incorrectly then you can think that something is a problem when it is not.

I give you an example that a customer recently asked me about servo tuning, he said that he cannot tune the servo properly, it sometimes give following errors of 1-5 encoder counts, so he said it is an error, because there is a following error.
So, I had to describe him that a servo loop is based on error. The loop is controlled by the error. If there is no error then there is no control.
I'm just trying to describe that you have to understand how the theory and real world connect...

[cncdrive]

BTW, Terry, what exact problem did you experience? I'm asking because if you experiencing problems has to be something else, not related to what is on those scope pictures.

[Vmax549]

OK I will try this one more time (;-). In Mach3 cutting teh Z raids are set to 100 IMP rapids. The THC speed is 20 %.

So when the Machine references the Material or you rapid up and down is does so at 100 IMP which makes a fast function and does not waste time. The THC reacts at a max vel of 20 IMP and ZERO acel/deacel. At those settings there is NO osilation of teh torch height. The edges are claen and smooth.

With UCCNC you have to run very fast acel/deacel vaues and that means you have to cap teh Max velocity to 16 so whne you are running teh reference TOM routine or rapid up or down it will run but VERY slow .

With High acel rate for teh THC it stil does a bit of overun and this causes a light ossilation of teh Torch height which causes a slight scallop effect of teh cut. You can acutally see it and hear it cutting. It is minor at that point but still there.

Now because the ART type cutting can have 100s of pierces for each piece the SLOW rapids cause teh cut time to almost double. So iF you try to raise teh Max Vel by adding a touch of accelleration to teh THC side is does lower teh cut time BUT it makes teh Scalloping of teh edge WORSE. Trying to compomise leaves you with a poor cut that is easily seen in teh finish product AND a longer cut time which increases teh Part Pricing.

Neither are exceptable in teh competitive world of plasma art cutting.

In Mach3 or Mach4 or LinuxCNC or CommandPilot or FlashCut controllers this problem does NOT occur and smooth cutting is easy to acomplish. Easy Peasy so they say.

(;-) TP

[beefy]

Balazs,

these latest posts have made me think about what is planned for the new S-curve planner and THC control.

So there will be the instant start step frequency where no acceleration is applied, then above a certain Z speed we have acceleration. And of course visa versa for deceleration.

Initially I thought this sounded great but with the new input here, I'm envisioning the accel/decel applied above that certain Z speed will introduce delays to THC control.

Imagine the Z is coming down under THC control. The Z speed goes about the speed setpoint and acceleration is applied and the Z speeds up. The THC now removes the THC DOWN signal. The Z must now decelerate before it can stop and thus may overshoot somewhat, leading to the oscillation Terry has mentioned.

Perhaps this is why "bang bang" control is just that and nothing more, no acceleration anywhere.

Balazs, my suggestion is totally separate control of normal Z moves, and THC moves.

Normal Z rapids, G1, G2, G3, etc have the typical settings, just like the other axis have.

THC control has a separate max velocity setting, and no accel/decel applied. HOWEVER, if you wanted you could have an enable tickbox to apply accel/decel above a certain Z speed. This will give a choice of pure bang bang control with no acceleration, or bang bang plus acceleration.

Keith

[cncdrive]

Keith,

If there is no acceleration anywhere then the stepper will loose steps, except if the max. velocity for the THC movement is defined below the steppermotor's start stop frequency, because with infinate acceleration always the max. velocity is used since without acceleration the controller puts out that frequency always when there is movement as there is no acceleration time, it is zero.
And so this leads to the observation that our method can be only better than the "bang bang - no acceleration at all method", because with that you cannot use higher velocity than the stepper's start stop frequency
and our method will do the same (you just have to set the start velocity to the stepper's start stop frequency point) plus it can further accelerate above that velocity point where the "bang bang" method would fail.