Servo PID Tuning - can't clamp down on overshoot

More
29 Dec 2016 02:07 #84833 by SRDC
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!
Attachments:

Please Log in or Create an account to join the conversation.

More
29 Dec 2016 11:16 #84846 by andypugh

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.


What is the I-term doing during this phase? Can you halscope it?

Please Log in or Create an account to join the conversation.

More
29 Dec 2016 12:17 #84847 by SRDC
I should be able to - I'll try again this morning and post back.

Please Log in or Create an account to join the conversation.

More
29 Dec 2016 17:46 #84860 by SRDC
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!
Attachments:

Please Log in or Create an account to join the conversation.

More
29 Dec 2016 17:55 #84862 by andypugh
I was actually meaning pid.N.errorI but your plots are interesting.

Why does the Igain change? Is it connected to something in HAL? Is it meant to be?

Please Log in or Create an account to join the conversation.

More
29 Dec 2016 19:27 - 29 Dec 2016 19:29 #84867 by PCW
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
Last edit: 29 Dec 2016 19:29 by PCW.

Please Log in or Create an account to join the conversation.

More
29 Dec 2016 19:51 - 29 Dec 2016 19:52 #84869 by SRDC
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.
Last edit: 29 Dec 2016 19:52 by SRDC.

Please Log in or Create an account to join the conversation.

More
29 Dec 2016 20:26 #84870 by SRDC
Attached are pictures with maxerrorI with FF2 from before, and no FF2
Attachments:

Please Log in or Create an account to join the conversation.

More
29 Dec 2016 20:27 #84871 by SRDC
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.

Please Log in or Create an account to join the conversation.

More
29 Dec 2016 21:18 #84874 by SRDC
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.
Attachments:

Please Log in or Create an account to join the conversation.

Time to create page: 0.160 seconds
Powered by Kunena Forum