Bridgeport Servo tuning

I'm tuning servo control loops on my Bridgeport Series II Interact 2 now and I have a couple of questions about others' experiences tuning. I've been attempting to tune by setting speed to a nominal range (61 ipm is what I've been using lately), setting the HAL scope to record hm2_5i25.0.encoder.01.velocity with axis.1.f-error, and jogging 3 inches in one direction and 3 inches in the opposite direction. I've used the Ziegler-Nichols method described here www.linuxcnc.org/docs/2.4/html/motion_pid_theory.html and I've tried just P-only (and FF1 and some FF2). So far, I've found my following errors are much smaller with P-only. My questions are -

1) Does this seem like a reasonable way to tune axes?

2) Is it common to see best performance on milling machine axes using proportional-only control?

3) What is a common worst-case following error for tests like this? Do the errors seen in the attached pictures seem reasonable for this kind of machine? I would think the ~.0001" f-error at steady-state is OK but the spikes around accel and decel are a little larger than I'd prefer and I can't tune them out with FF2.

I suspect that I'm not executing the Ziegler-Nichols tuning as it was intended. Can anyone make some suggestions to improve my method? FYI I'm using a max acceleration of 8 in/s^2, which seems about like the acceleration was before I converted to LinuxCNC.

P-only example

Maxdvh:

First of all, keep me patience for my little English
After some months of mistakes and nervous, i have tunned my drives to get a max following error of 0.06mm (0.00236in?) (without the drives connected to the machine).

Some things i learned:
1) You have to use PID, so you have to use velocity mode in your 5i20 card not position mode. Remember that PID inputs are in position, output is in speed. Configure it correctly in INI and HAL file.
2) If you follow the error "behind", thinking to keep on it, you are lost. You have to "anticipate" to the trayectory. The best parameter to do this is FF1 NOT P.
3) Do not use jog in halscope, use a program like G1 X100.0 F1000.0 mm (mm/min, equals to 78.74 IPM?).
4) I don't know what kind of drives you have, but if you can, cancel every parameter that smooth the input pulses, may be a smooth filter a noise input canceller or a velocity input estimator or a delay in the input, and then autotune it (will set its internal P, I, D, FF0, FF1, FF2 for his own inertia).
5) If you have an intelligent drive with feed forward built in (FF0), put it to 100%, in my case it was set to 50% by default, so it generated a delay in the accel deccel ramp hard to follow (it was not intelligent at all). If you have a dumb drive i think it is already at 100%.
6) You have to initialize in the INI file each axis with MAX_STEPGEN (or something like that) with near 20% more than MAX_ACCELERATION (or something like that). Remember MAX_ACCELERATION is used by the trajectory planner and MAX_STEPGEN is used by the 5i20 card. If you are requesting an acceleration of MAX_ACCELERATION and you are behind with Ferror, how do you plan to keep on it if you have an equal acceleration in your drive ? you have to have a speedy acceleration.
7) This may help or not, in mi INI file i use a 1khz for the TRAJ planning thread and 4 Khz for the servo thread. Because the servo have to follow the TRAJ, so you have to have a better speed feedback.
8) With halscope record velocity commanded (PID output? i dont remember), and velocity feedback of the encoder (velocity of the encoder in 5i20? i don't remember). As an additional parameter in order to measure the error record Ferror.
9) First of all set all P I D FF0 and FF2 to 0, and FF1 to 1. Halscope it incrementing P while you get oscilations, then set P to near half of it. So you will have a P that do not oscilate.
10) Now starts the critical part of the tunning: the goal is to match the "real" trapezoid to the "requested" trapezoid. Remember the accel is the 1st ramp, the 2nd ramp is the deccel and the line is the velocity reuested.
11) Concentrate in the acceleration, Is there a delay between the real and the requested accel? Look at the base of the ramp if you have a difference. You have to correct it wit FF1. In my case values are near 1.0, may be 0.994.
12) Now look at the angle of both ramps. Are the same ? In my case when a had a 50% in the internal FF1 of the drive there were a difference, the drive didnt accelerate at the requested accel, it tryed to follow it with its internal P and D parameter but it was not working. When i set it to 100% it accelerated correctly. May be another case is when MAX_STEPGEN is less or equal to MAX_ACCELERATION.
13) The same happens with the deccel ramp.
14) If all this is working OK. Ask, do i have oscilations in the ramp or velocity ? It may be caused by excesive P, incorrectly I, or D (D is hard to adjust, better is to set it to 0).
15) Now you will note a spike at the start or end of an accel or deccel, it is caused by the trapezoide form of trajectory planning that generate jerk. You have to correct it with FF2 that anticipate the acceleration of the acceleration, visually as the change in the ramp angle recorded. FF2 are low values (i dont remember the range). This spike may be masked and confused as an oscillation and you will thinkg that you have to adjust P, but this doesn work, you have to adjust FF2 that anticipate the jerk or D a little that function as an amortiguator (buffer?).
16) Remember that if you have a hig ramp (high accel) the tune may be difficult and the machine maybe suffer. So you have to set a moderate MAX_ACCELERATION. In my case is half the MAX_VELOCITY. Because i want to accelerate from 0 to half MAX_VELOCITY in 1 second. MAX_VELOCITY is set to 10 mts/min so in 1 second it accelerate from 0 to 5 mts/min (196 IPM?)

May be it helps. God bless you.
VNR

Since your main problem is during accel and deccel, can you replot with just an expanded view of the velocity ramp?
At 8in/s/s the ramp up to 1 IPS only lasts .125 seconds and thats really the area of interest so instead of 1 sec per division, 20 ms per division (200 ms per screen) would help a lot. Also plotting the PID output will help

VNR, thanks for the detailed response. I'm a little overwhelmed. Some of those items I'm well aware of, some I hadn't considered, and some I don't understand. Is STEPGEN even relevant here in the case of servos? Also, I only have a servo loop, no TRAJ loop that I know of.

PCW, I took a couple more pictures of the P-only accel/decel profiles including PID output.

Decel

Looks like theres a large phase lag between the velocity command and actual motion
if you look at the first ~20 ms, the PID output = velocity command to the drive is there
for 20 ms with no actual motion (encoder velocity)

Not sure where the problem lies but I suspect its mainly in the drives/mechanics

It would be valuable to know if the oscillation is mainly in the velocity loop (in the drive)
or in the position loop. If its in the velocity loop you need to adjust your drives
This can be tested by opening the position loop and outputing a small velocity step (a step in analog out)
and checking the drive response. If the drive is marginally stable, this will not allow enough P gain
and that may be what you are seeing here.

Also FF1 should help but to tune FF1 you need to turn off I and D
and maybe lower P so the effect of FF1 adjustments on motion are clear

Is STEPGEN even relevant here in the case of servos? Also, I only have a servo loop, no TRAJ loop that I know of.

Don't care about that right now. May be later after the graph analysis.

In the accel graph note this:
1) the encoder velocity ramp starts 10 to 20 ms later than the requested velocity. This generate a large Ferror. This is because P acts "after" the requested velocity, trying to keep on that. Now you know that acts 10 to 20 ms later.
2) In order to avoid that you only count with FF1, the parameter that acts "before" the error and is proportional to velocity.
3) As a first step only change FF1 trying to match the start or the encoder ramp with the start of the velocity requested. Not after not before. As a start use the range between 0.90 to 1.00
4) Try to use the same escale in the graph of requested velocity and feedback velocity, is easier to see and analyse. The goal is to match the real velocity to the requested velocity. And then (and only then) the ferror will become minimal.
5) Post the new graph in the forum.

As a quick note. FF1 will only be in the ~1 range if the PID output is "normalised"
That is if the analog output scale is set to machine units per second
The default analog output scale of the 7I77 is in volts (10V full scale)
so this is "normalized" for a system with 10 IPS at 10V

Also Its true that P acts "later" but in a much shorter time frame than the ~20 ms delay.
You can see the P term is driving the PID output (green) early on with a greater
than commanded velocity slope, the drive is simply not responding.

like VNR said, plotting the commanded velocity will help as well