AMC drive tuning

Acceleration is at 30. 30 ips per second. I'll lower it and see if it improves.

Can someone tell me how to interpret the values shown on the bottom of halscope? The numbers that change based on curser position.

IIRC, the left number is the relative time withing the sample window. The right number is the actual reading. velocity will be in user units (mm or inches) per second, position will be in plain user units. Error will be in user units (should be really small units like
micro-inches when properly tuned).

Jon

Jon,

Thanks for the explanation. So the f number represents time? And ddt? What do the abbreviations stand for? I didn't see any details in the docs. I may have missed it.

ddt is df/dt = the slope of the trace at the cursor location

I reduced my acceleration down to 20 for the Z and 15 on x/y. I see some improvements but it's still off. How does linuxcnc deal with different joint velocities and max accelerations? I assume the motion planner/trajectory detunes to the lowest value internally?

Second, I don't think I saw an answer on this:

Also, in the Hal file, do the setp pid.x.error-previous-target true have to be off for tuning only then turned back on after? Are they no longer needed?

What is a realistic expectation for my knee mill on the following error numbers? I know it's really machine specific but could I get to +/-.001" with .0004" encoders?

What I'm seeing with an indicator now is that there is some inconsistency. I can rapid to my 0, most of the time it's dead on, sometimes it's .002" off but the display shows correct commanded 0 position.
With 15 ipm , I'll get an overshoot by .001 followed with a slow creep back to 0. I think at faster speeds it performs better.

Did you try a bit of FF2 to minimize the following error at the start and end of motion?

You can display the commanded or actual position. you would want to display the actual
scale position for testing. If the actual position error is 0 but you see a physical error, you
may have some mechanical issues (loose gibs for example) If your tuning does not
result in a 0 static error you could add some I term

It is difficult to do a whole lot better with such relatively coarse scales,
but you may be able to tune out some of the the error spike at the
beginning and end of motion with FF2 and eliminate any static error with some I.

edit

Also, in the Hal file, do the setp pid.x.error-previous-target true have to be off for tuning only then turned back on after? Are they no longer needed?

That should always be set true

OT-CNC wrote:

What is a realistic expectation for my knee mill on the following error numbers? I know it's really machine specific but could I get to +/-.001" with .0004" encoders?

That is a bit iffy. +/- .001" is just over two encoder counts. I generally get well under .001" following error (with some larger spikes during accel/decel) but my shaft encoders map out to 20,000 counts/inch (that a 1000 line/rev encoder with quadrature resolution of 4000 counts/rev X a 5 TPI leadscrew. That is pretty easy to accomplish, getting usual following error at cutting feedrates of about 10X the encoder resolution.

Jon

When I did my tuning, I was able to get the follow error plot level (not counting the spikes), meaning not switching from a high to low during reversals for all joints.
Now looking at the plots again my Y is off! I did not change the PID parameters. How is this possible? Do I understand this correctly?
The Y is clearly switching high and low, shown in the lower red plot on the video. First blue plot is the x and is level.

That looks like a scaling change so something that sets voltage relative to velocity changed.
LinuxCNC's FF1 and output scale change this as do drive reference gain and tachometer output.
LinuxCNC's P terms has a secondary effect on this as higher gains counteract the scaling error
minimizing the magnitude of the error.

That looks like a scaling change so something that sets voltage relative to velocity changed.
LinuxCNC's FF1 and output scale change this as do drive reference gain and tachometer output.
LinuxCNC's P terms has a secondary effect on this as higher gains counteract the scaling error
minimizing the magnitude of the error.

PCW, thanks for explaining/confirming this. I assume that changing the acceleration should not have an effect on this as it just lowers the spike a bit and curves the start. I did add .002 for FF2 for the X which I couldn't really make out the change on the plot but test indicator stops correctly now on 0. So I'm really close now I think.
I'll re-tune the y, easy enough to adjust the numbers. Once set, I hope it stays consistent.

That is a bit iffy. +/- .001" is just over two encoder counts. I generally get well under .001" following error (with some larger spikes during accel/decel) but my shaft encoders map out to 20,000 counts/inch (that a 1000 line/rev encoder with quadrature resolution of 4000 counts/rev X a 5 TPI leadscrew. That is pretty easy to accomplish, getting usual following error at cutting feedrates of about 10X the encoder resolution.

Jon, thanks. That explains why .004" inch or so would work for my settings on the XY and a tighter setting on the Z screw mounted encoder.
Correct me if my understanding is wrong, following error has nothing to do with the accuracy of linuxcnc as it tries to have 0 error but is a flag to stop movement when the error exceeds the set point. My f error plot shows the spike on start of acceleration, I set my value above that. In other words, a setting of .004" would trip at .004" and above. When not tripped, it has no affect of arriving at the target say .004" short or too far.
Now, how does the trajectory planner come into effect on this for tuning? Should tuning be done with exact stop mode or does it not matter?

Last, sorry, the newer INIs have 2 sentries of the same max velocity, max acceleration, min and max limits under axis and joint. I assume that's for backwards compatibility? I think when I save the settings from the calibration screen it just updated the joint section. Can I delete that axis section or just duplicate the values over?