Servo PID Tuning - can't clamp down on overshoot

Howdy all,

We are having a bit of trouble getting our first servo motor (starting with the X-axis) on our latest retrofit tuned properly. This is a Mazak VQC 15/40 with Mitsubishi TRA-31 servo drives and HD81-12S-TT 0.8kW brushed DC servo motors.
The drive operating manual is at: TRA-31 manual
and the maintenance manual for the old Mitsubishi Meldas YM2 / Mazatrol M2 control (with various wiring info, etc) is at: YM2 Manual

We followed John Thornton's basic servo tuning guide, which worked well on our last mill (a CNC knee mill retrofitting old Anilam Crusader GXM controls). We started with P = 5, increased it to about 15-25 where it started oscillating, and then tuning FF1 to about 0.36 to center the cruising velocity, and increasing FF2 to try and clamp down on the starting/stopping lag.

Currently, max velocity is 700IPM (11.67 - in/sec - in the INI file), and 23.3333 in/s^2 acceleration, to reach max velocity in 0.5s. The max velocity is the specs we found on several websites for this mill, and the acceleration was a best guess. We did find a research article that had empirically determined maximum 'safe' acceleration for this model, and it was 78.74 in/s^2, so we SHOULD be safely in acceleration capabilities. These are pretty big servo motors for a fairly small table - 0.8kW motors for a 25 x 15.75" table.

PROBLEM: We can't get rid of the artifacts during starting/stopping. It seems to lag by 0.002-0.005", then overshoot by approximately the same amount, before settling in properly.
We have to drop P down to about 5 to get rid of noticeable oscillations altogether, and then it takes a LONG time to correct. We have tried various combinations of P, I, and D with basically no success.
Most of the adjustment pots on the drive say to leave them alone, as they are factory tuned, but we did try adjusting VR3 (Speed Loop Compensation) to try and increase response. It smoothed up the curve after the over-compensation, but didn't reduce the magnitude at all.

Any ideas??? Thanks to PCW, cradek, KimK, tjtr33, and others that have been helpful on IRC in getting this far!

I should be able to - I'll try again this morning and post back.

Here is a screenshot with the same values as last time, with Igain on the halscope.
I also increased the jog speed to the max rapid of 700ipm, and attached the screenshot. Pretty ugly!

The I gain thing is weird but a couple of things:

You have too much FF2, This s clear from the 700 IPM plot
( dont try to fix the initial error spike with excess FF2, but rather try to zero the
bulk of the error during long accel/decel phases )

There is a noticeable delay somewhere:

Possibilities:

1. Drives are slow and you are running higher accel than expected for the machine (lower accel)
(and or)

2. Resolver response is slow because of low signal (measure with a good voltmeter/scope)
is the 7I49 a 7i49HV model?

3. Driver velocity loop has low gain and you have not backed off on the (too high)
FF2 when raising the drives velocity loop gain, leading to more overshoot

1. I really don't think this is a problem. We had the acceleration even higher, and it didn't make the problem worse, IIRC. We can check again, though.

2. Possibly. The resolver specs say the excitation freq is 4.5kHz. We have it set at 5 on the 7i49. It is a plain 7i49 model (NOT HV). I don't have a good scope, and just a plain Lowe's Amprobe DMM. Would halscope be able to show anything, and if so, what should I be looking at???

3. I will try to drop the FF2 down. (we only used it this way to try to clamp down on the initial lag, because it seemed to work well in the Gnipsel tutorial - now that you point it out, it makes sense that it is making the overshoot worse.)
ALSO ... the overshoot doesn't really change magnitude much with FF2 = 0, it just oscillates a little less. Even without FF2, there is still significant overshoot.

I will try some variations of acceleration, etc in a little bit and post halscope pictures.

Attached are pictures with maxerrorI with FF2 from before, and no FF2

I don't know why the Igain changes. It is the Igain *PIN*, not the parameter, so I just assumed that it was the actual calculated I from the PID calculations.

Here are halscope shots at 100IPM, with & without FF2 ... ALL at HALF-acceleration (10 in/s^2 ==> ie reaches 100ipm in ~0.17s and 700ipm in ~1s). It doesn't really change that unresponsive lag.