Bridgeport Servo tuning

Thanks. Can HAL Scope plot more than 3 items at once? When I try to plot commanded velocity it doesn't show up.

Is it possible to dial out the delay in amplifier response so that LinuxCNC expects it? I can't imagine that I can do much to improve that on the amplifier side. The amplifiers are the old original units from the machine so I can imagine they aren't the cutting edge technology.

Nevermind, I can plot 4 traces at once. It seems that my x amplifier has less of a delay than y; more on the order of 10ms.

Your suggestions about increasing FF1 to "look ahead" more make sense to me but the results of my testing don't agree. I find that increasing FF1 and decreasing P results in larger Ferrors and longer settling times. Below is a plot of what I found to be the most promising set of X gains I've seen so far -

P: 160
I: 0
D: 0
Bias: -.0051
FF1: 2.62
FF2: .01

The Ferror at constant velocity is on the order of +/- .0001in and the maximum Ferror during acceleration is about .00056in. That doesn't seem too bad but I'd like to know what kinds of numbers people are achieving. The biggest detractor from the low P, high FF1 approach for me is how long it takes to settle to 0 steady-state error. The number seems to be inversely proportional to P-gain.

Accel only (50 ms/div)

My suggestion of low P is only for setting FF1, not final tuning (that is the effect of FF1 is more clear when P is low)
(this goes for I as well, the effect of FF1 is masked by I)

Your suggestions about increasing FF1 to "look ahead" more make sense to me but the results of my testing don't agree. I find that increasing FF1 and decreasing P results in larger Ferrors and longer settling times.

I agree with PCW, the suggestion of low P is only for setting FF1, not final tuning

The Ferror at constant velocity is on the order of +/- .0001in and the maximum Ferror during acceleration is about .00056in. That doesn't seem too bad

I think it is not bad, it's better than before. It depends on the precision your are planning to machine. Only hobby or production ?

I'd like to know what kinds of numbers people are achieving

I'm arcieving 0.033 mm (0.00129in) of max ferror at 8000mm/min (315IPM?)

The biggest detractor from the low P, high FF1 approach for me is how long it takes to settle to 0 steady-state error. The number seems to be inversely proportional to P-gain.

Based on that, the setting of Bias: -.0051and looking at the graph i supouse the problem is not a delay in the drive, instead of it, is a failure to response in the range near 0V.
Look at the start of the deccel ramp, there insn't a delay there. It's only at the start of the accel ramp.
May be you need a high P to archieve a 0 steady-state error because you need to oscilate a bit near the 0V in order to compensate for the failure of the drive in this range.

Try with this component and see what happens.
idb -- Inverse Deadband
Useful for torque-mode servo amplifiers that don't respond to DAC output in some interval around zero. wiki.linuxcnc.org/cgi-bin/wiki.pl?Contri...idb_Inverse_Deadband
www.anderswallin.net/2008/04/idb-inverse...-component-for-emc2/

My experience was that FF1 is easy to set at all levels of P gain but the correct value varies depending on P gain. Increased P gain requires decreased FF1.

The inverse deadband idea sounds great but I think there really is a delay in the response of that amplifier. Please have another look at the decel plot from my Y axis on the first page. There is still ~20ms delay between the decrease in the PID signal and the axis slowing. Unfortunately I guess I'm going to have to accept this delay or get new servo amplifiers.

That should not be. That is FF1 just copys the commanded velocity to the PID comps output (with scaling) and P deals with position errors only.
FF1 by itself ( no P) should set the axis to the correct speed and P should just make corrections based on position errors. Basically FF1 factors out the
velocity so the feedback part PID loop is "centered" around the current velocity

FF1 should be independent of P. If not something is wrong here or you do not have velocity mode drives.

as far as the delay goes, are the tachometers directly connected to the motor shaft? is there perhaps some mechanical reason for this response?

P-only control results in some nominal following error from what I've seen so far. I can adjust FF1 to the point where the following error is centered around 0. If I change P, the following error will be centered above or below 0. The required change in FF1 is slight (if I change P by 10, I'll have to adjust FF1 by .01), but it certainly seems to be linked. I honestly don't know for sure that I have velocity-mode drives but I think if they were torque mode they wouldn't be anywhere close to accurate using the velocity mode PWM outputs. I don't have much detail on them, they are just the amplifiers that my machine came with. Perhaps somebody has more info about the 1980s era Bridgeport Series II Interact 2 servo drives.

There are both tachometers and encoders attached directly to the servo shaft. LinuxCNC is controlling off of the encoder (you probably assumed as much).

Others things to consider:
I used to adjust FF2 in order to eliminate a "spike" ferror and overshooting at the start and end of the accel and deccel ramp.
Could you connect the tachometer and compare the velocity with the encoder velocity ?
Aren't you confortable with the +/- .0001and 00056in ferror ?.
May be you want to set the MAX_ACCELERATION (INI file, TRAJ or AXIS section) a little bit slower.
Do you have backlash in the machine ?

Thanks for the ideas -

VNR wrote:

Others things to consider:
I used to adjust FF2 in order to eliminate a "spike" ferror and overshooting at the start and end of the accel and deccel ramp.

FF2 does appear to help a little bit with the spike at the start and end. I've set it to try to minimize that spike. If I were to set it lower or higher that spike would be a lot worse in the plots I've posted (I played around with it for a while before making those plots).

VNR wrote:

Could you connect the tachometer and compare the velocity with the encoder velocity ?

I could I suppose but it would take a bit of research into what kind of signal the tach generates. In order to investigate the delay that you guys pointed out I was going to connect an oscilloscope to both the PID input and the servo amplifier output and verify that the amplifier is, in fact, causing the ~20 ms delay in response. I will update when I get a chance to do this.

VNR wrote:

Aren't you confortable with the +/- .0001and 00056in ferror ?.

That error seems OK but it's tough to accept that my servo amplifiers are "bottlenecking" my machine's performance. If I can confirm that, I might be tempted to trash them in favor of some more modern units. I was considering AMC 30A20ACs www.a-m-c.com/download/datasheet/30a20ac.pdf but I'd be interested to hear about any more cost-effective options with good performance.

VNR wrote:

May be you want to set the MAX_ACCELERATION (INI file, TRAJ or AXIS section) a little bit slower.

I will test this.

VNR wrote:

Do you have backlash in the machine ?

There probably isn't much backlash but to be honest I haven't measured. This machine has very beefy ballscrews and has been used relatively lightly so I don't expect it to have worn much.