Stuck at the start on servo tuning w/ Youtube video.

[Garage14]

OK the tool changer code works now so everything is set up and I am down to final polish before I try to actually make chips. The last issue I have before I try to load some Gcode into Kmotioncnc is the jog function is still pretty rough. I have spent a bunch of time dorking around in the step response tab and gotten my command and position graphs looking good and everything moves well until I try keyboard jogging in kmotioncnc. I pick up intermittent stuttering that seems totally unaffected by any changes in the axis tuning INIT file. Is there some way to tune the jogging?

[TomKerekes]

Hi Dave,

Jogging should use the Acceleration and Jerk settings in the INIT file.

Do you have reasonable speeds set in KMotionCNC | Tool Setup | Trajectory Planner | Joystick/Jog | Jog Speeds?

[Garage14]

Hey Tom,
I think my jog speeds are reasonable. My current values result in motion that is a good deal slower than what I was achieving in the step/response tab during initial tuning.

I tried playing with the acceleration and jerk settings but even going from 10000 to 1000000 didn't remove the stutter. I restarted kmotioncnc between INIT file edits, and I saw a big change in speed so I know it took the changes ok.
Someone else suggested communication lag, because unlike a commanded position, jog is a constant stream of individual movement commands. all I could think of there was to try switching usb ports but that had no effect. I am direct from the kflop to the pc on a 4' cable so not much else I can do there.
I thought maybe it was a resonance because my frame is pretty tall, so I braced the top of the frame to the wall. The machine is very rigid now and if anything actually made the shuddering worse.
I noticed that the stutter builds and then fades across very large moves.
I removed the belt and turned the leadscrew by hand to check for stiction but everything moves free and smooth.
I'm out of ideas atm.
https://youtu.be/_KXQs29FSso
It's hard to see but you can hear the shaking by the tools on the table
Thanks -Dave

[TomKerekes]

Hi Dave,

I think your system is borderline unstable. At certain speeds and positions the friction and structural resonances are such to go unstable. Did you tune the system? Did you test at different speeds and positions? Do you gave good margins in your gains?

When Jogging the Jog Velocity is set by KMotionCNC. Acceleration and Jerk from the Init file are used. Your problem seems to occur while moving at constant velocity. Acceleration and Jerk wouldn't have any effect when going at constant velocity.

You should see the same effect in the Step Response Screen if you make a similar large move at the same positions and velocity. Although it may be somewhat hard to catch since the Step Response Plot can only capture 3.5 seconds of motion.

This wouldn't have anything to do with communication.

[Garage14]

I did tune the system. The first time I went through following the instructions in the wiki to go as high as possible until I get shaking and then back off on P then D then P again and then I. but I decided to start over with the additional goal of changing values up and down in tiny increments trying to get the smoothest output graph as possible. 4 hours later I have my best effort for the X axis "finished"

after putting these values in the INIT file the machine jogs a lot smoother now. I still get light shuddering now and then but it's a lot better. You said that the jog only uses accel and jerk but I feel like the PID and max limits do affect the jogging as well because when I tried just changing the accel and jerk it made almost no improvement to the jogging.
I'm just wondering now if I need another filter of some kind to further reduce the spikes in my output? I applied the one from your previous suggestion but I feel like the output is still a bit to erratic and PID changes only get me so close.
Thanks - Dave

[TomKerekes]

Hi Dave,

You forgot to plot error or post the raw data as we requested. With this we can't see the errors or performance.

You didn't plot Velocity or use TripsWPF to check what you are testing. The Velocity is only 171000 not 700000. The Acceleration is only 600000 not 2000000. What is your KMotionCNC Jog Speed?

You said that the jog only uses accel and jerk but I feel like the PID and max limits do affect the jogging as well because when I tried just changing the accel and jerk it made almost no improvement to the jogging.

Correct. I was referring to only the KMotionCNC Jog Velocity was used in the the trajectory of the motion. All other parameters from the INIT file are used.

I feel like the PID and max limits do affect the jogging as well because when I tried just changing the accel and jerk it made almost no improvement to the jogging.

Well that should make perfect sense. Velocity, Acceleration, and Jerk don't effect the stability of the system. To make a system more stable you must change the feedback parameters. Think of the Velocity, Acceleration, and Jerk as the path you are testing your car on. Think of the feedback parameters as the driver of the car trying to drive down the center of the lane. If the driver of the car is making over corrections and weaving the solution is to stop making over corrections rather than changing roads.

I'm just wondering now if I need another filter of some kind to further reduce the spikes in my output?

No I doubt if a filter would help with that. I wouldn't describe that oscillation as spikes. Possibly the system is still somewhat unstable. You didn't supply the data we need to see what effect it actually is having.

Higher D Gain tends to stabilize the system. It sort of adds the equivalent of Drag to dampen out oscillations. Force proportional to velocity. Think of submerging a tuning fork in honey. But only up to a point. If mechanical delays cause the Drag force to get out of phase with the velocity it can itself make the system unstable. Typically D Gain has a value many times the P Gain.

It looks like your system has significant friction. Notice the Output required to accelerate is much greater than what is required to stop.

HTH

[Garage14]

Here's the error and velocity plots.

I couldn't attach the step response save data because it exceeds the 1 MB limit.

I didn't know what tripsWPF was so I searched it and found the dynomotion youtube video. The comments state that it is included in software version 4.35 however the software tab on the main dynomotion site still only goes up to 4.34. I found a link in a forum post to 4.35f and downloaded and installed that but after running a file search I still can't turn up tripsWPF.exe. If you could point me to a place to download it I can give it a go.

I lost track of the machine no longer keeping up with increases because I got completely focused on a loop of making a small individual change and then plotting output over and over. The graph liked more and more accel and jerk up to about 2000000. I guess the motor itself wasn't actually doing anything different for a long time prior to getting the values that high. I guess next I back the values down till I see a change in the actual motion and just do my best to maintain the smoothness of output I currently have.

My jog speeds in Kmotioncnc are currently pretty slow. 2IPS for X and Y and 1IPS for Z.

On the D gain I followed my path of adding little by little till I was at 50. The general shape of the output plot was the same except at that high value I had high frequency buzzing so the line looked thicker until you zoomed in to see microscopic vibrations. I backed it back down till I saw a negative effect on the graph down around 5 or 6.

No friction that I can find. Turning the leadscrew by hand it turns smooth and easy with one finger the whole way across. The X motor turns smoothly when disabled also. I noticed that certain parameters seemed to affect the positive move more than the negative move on the output graph too so I tried to split the difference on those but that seemed strange to me.

Thanks for the help -Dave

[TomKerekes]

I couldn't attach the step response save data because it exceeds the 1 MB limit.

Did you zip it?

Here's the error and velocity plots.

The max error is about 100 counts or 0.005 inches. Is that acceptable?

I found a link in a forum post to 4.35f and downloaded and installed that but after running a file search I still can't turn up tripsWPF.exe. If you could point me to a place to download it I can give it a go.

Strange its in the C:\KMotion35f\KMotion\Release folder. Sometimes Windows or antivirus thinks executables are malicious and removes them. You might check their logs or disable them.

I lost track of the machine no longer keeping up with increases because I got completely focused on a loop of making a small individual change and then plotting output over and over. The graph liked more and more accel and jerk up to about 2000000. I guess the motor itself wasn't actually doing anything different for a long time prior to getting the values that high.

You should have seen from the velocity plot that after 171000 the trajectory (blue) doesn't change at all. Just like in a car to test high speed you need a long road.

TripsWPF should also show you that the motion is Jerk limited. When the Jerk value equals the Acceleration value that means it will take one second for the acceleration to ramp up to the specified value. But before that it will be time to start stopping. The analogy with a car is that you can only apply the gas/brake very gradually. With driving a short distance the gas pedal won't be depressed all the way down before you need to start stopping.

Typical values for Jerk are 10X the acceleration so the acceleration is fully applied over 0.1 seconds.

Also keep in mind you can't "tune" or make things better by increasing Velocity (or acceleration). These are limits. In operation the machine will need to function at these limits and all lesser velocities.

My jog speeds in Kmotioncnc are currently pretty slow. 2IPS for X

So that's 20640 counts/sec. Did you test at that Velocity?

On the D gain I followed my path of adding little by little till I was at 50. The general shape of the output plot was the same except at that high value I had high frequency buzzing so the line looked thicker until you zoomed in to see microscopic vibrations.

In the output or the error? Did you have a 2nd order low pass filter Freq=500 Q=1.4 installed.

I backed it back down till I saw a negative effect on the graph down around 5 or 6.

Well no. You should have left it as high as possible. Which should then allow higher P or I gains than before.

[Garage14]

Sorry that took a bit, lots meat in that last post.
I did not zip the step response save file, I have unzipped tons of things but never made one. Sorta ashamed I didn't think to do that. Attached now.

step response 8-15.zip

(536.49 KiB) Downloaded 74 times

5 thou following error kinda stinks. I have played around with the step response a whole lot and found that at reasonable speeds my following error is actually around 250 no matter what I tried and to get that down I had to slow to a crawl and even then I have that 100 count following error. I don't know if that's mechanical or tuning?

You are correct trips is in C:\KMotion35f\KMotion\Release. Dunno why file search couldn't find it but I played with it a little bit. I found that now that I am understanding the graphs in the step response screen better. You can see limiting parameters in the top of the graph scale. Kmotion limits the top of the scale to match the actual limit based on accel and jerk even if you set a higher max velocity.

I did test at 2 IPS in the step response screen but it's soo slow my movement is pretty short to fit within 3.5 seconds... the initial output spikes pretty high but once it's at constant velocity the output doesn't jump around so I'm not sure where the shudder was accumulating from on long moves however my new settings seem to have finally fixed that.

My error looked like an inverted mirror of output but now that I jacked the PID way up the error is a smoother shape. I do have the low pass installed.

ch0->InputMode=ENCODER_MODE;
ch0->OutputMode=DAC_SERVO_MODE;
ch0->Vel=160000;
ch0->Accel=600000;
ch0->Jerk=6e+06;
ch0->P=20;
ch0->I=0.025;
ch0->D=400;
ch0->FFAccel=6e-006;
ch0->FFVel=.00163;
ch0->MaxI=800;
ch0->MaxErr=800;
ch0->MaxOutput=1600;
ch0->DeadBandGain=1;
ch0->DeadBandRange=0;
ch0->InputChan0=0;
ch0->InputChan1=1;
ch0->OutputChan0=0;
ch0->OutputChan1=1;
ch0->MasterAxis=-1;
ch0->LimitSwitchOptions=0x11f;
ch0->LimitSwitchNegBit=140;
ch0->LimitSwitchPosBit=140;
ch0->SoftLimitPos=1e+09;
ch0->SoftLimitNeg=-1e+09;
ch0->InputGain0=-1;
ch0->InputGain1=1;
ch0->InputOffset0=0;
ch0->InputOffset1=0;
ch0->OutputGain=1;
ch0->OutputOffset=0;
ch0->SlaveGain=1;
ch0->BacklashMode=BACKLASH_OFF;
ch0->BacklashAmount=0;
ch0->BacklashRate=0;
ch0->invDistPerCycle=1;
ch0->Lead=0;
ch0->MaxFollowingError=2000;
ch0->StepperAmplitude=20;

ch0->iir[0].B0=1;
ch0->iir[0].B1=0;
ch0->iir[0].B2=0;
ch0->iir[0].A1=0;
ch0->iir[0].A2=0;

ch0->iir[1].B0=1;
ch0->iir[1].B1=0;
ch0->iir[1].B2=0;
ch0->iir[1].A1=0;
ch0->iir[1].A2=0;

ch0->iir[2].B0=0.0166094;
ch0->iir[2].B1=0.0332189;
ch0->iir[2].B2=0.0166094;
ch0->iir[2].A1=1.60679;
ch0->iir[2].A2=-0.673229;

So I went bananas on the PID and set the D to 1000 and just krept the other 2 up. I got P to 50 and I to .06. "I" is the one that really makes it grumpy but the other 2 I can almost go as high as I want. I did notice at really high values the servo starts so sing at idle tho so I backed things down. the jog stutter is gone but now I need to back the PID values down some more because the servo is still buzzing at idle.

I think I am actually close to getting this servo tuning sorted apart from the crummy following error

Thanks - Dave

[TomKerekes]

Hi Dave,

Thanks for stating what you did and what you understand clearly and thoroughly.

I think I see what is causing the somewhat large error of 250 counts. Whenever you see a constant error for a relatively long time (ie 1/2 seconds in your case) without being corrected something major is wrong. The relatively high value of D gain (which is great for stabilization) is causing a large "drag". At full velocity it is:

160,000 x 90us x 400 = 5760 Output DAC counts (in the negative direction as drag)

So something must provide an Output to overcome this without requiring error. There are 2 common methods to provide this. #1 the Integrator or #2 Velocity Feed Forward. Since nether of these are being allowed to do this the error must grow to ~250 so the Proportional gain of 20 can provide about 250 x 20 = 5000 counts of additional Output.

My error looked like an inverted mirror of output

This is another big clue. If they are proportional then you know that the P Gain is doing all the "work"

#1 The max integrator might be increased to 5760 + 800 = 6560 to allow it to do the job. Note there is a possibility in going unstable when you do this because right now the integrator is just saturating to its fixed limit and not doing anything dynamically. If unstable then reduce I gain until stable/

or

#2 The VFF might be increased. The Output supplied by VFF is:

Output = Velocity x VFF

or

VFF = Output / Velocity

or

VFF = 5670 / 160000 = 0.036

or 360X your current value. The actual value might be slightly higher than this to overcome the actual additional mechanical drag which looks to require about 250 counts of output.

VFF = (5670 + 250) / 160000 = 0.037

The other approach that avoids doing math is just to experimentally increase until constant velocity errors average zero.


You might also read this.

HTH