Re: PID control and NIST Software

Fred Proctor wrote:

> From: Fred Proctor <proctor@...>
>
> CAD/CAM folks,
>
> Jon Elson and Mike Romine were posting about PID control and how feed
> forward considerably improves accuracy. There was a discussion about the
> integral (I) gain, and how the PID algorithm should compute an integral
> output. In the NIST EMC software, the integral output is proportional to
> the accumulated value of all errors in the past.

Hmmm, are you sure? I don't have the code in front of me, but I seem to
remember that it only looks at the last sample's error. I'll check it tonight,
though. Anyway, how could you keep accumulating errors indefinitely?
If you add the new error to the eternal average, your contribution becomes
infintely small. In a totally steady state system, that might be OK, but here,
we have a system that starts life open-loop. The loop is not even closed
until the operator takes the machine out of e-stop. What if he walks away
for an hour with the machine in e-stop? Does that hour of error (3.6 million
samples at 1 KHz) get added to the Integrated error?

> There is no moving
> window that drops the oldest one when the next error is added.
>
> Dropping oldest values is not what you want with PID. The I gain is used
> to compensate for steady state error, which arises when something
> (gravity, a preloading spring) is pulling the system away from its
> commanded position. As an example, consider a cantilevered beam that is
> being held horizontally by a motor. Gravity pulls it down, and the error
> is its angle from the horizontal. If only a P gain were used, the output
> would cause the beam to swing up to a position where the downward force
> of gravity is balanced by the upward force generated by the P gain. The
> beam can never be truly horizontal, because the P gain would then
> generate zero output and the beam would drop.
>
> If the I term were non-zero, error builds up to a point where the
> integral contribution exceeds the balancing force, and the beam moves
> upward. Only when the beam becomes truly horizontal does the
> single-cycle error become zero. At this point there is no additional
> contribution to the accumulated error, and the beam balances
> horizontally. Note that there is no P gain contribution anymore: it's
> all due to the I gain. The entire past error history has resulted in
> exactly the amount of compensation we need to hold the beam truly
> horizontal.
>
> Now, what happens if we drop the oldest value in a moving array?
> Suddenly the I contribution is reduced somewhat, since 0 error is coming
> in and non-zero error is dropping off. The beam would drop slightly, the
> next cycle would add some small error, and the beam would move up. So,
> in order to eliminate steady state error, we need to keep the entire
> error history.

Well, I beg to differ. A machine tool is NOT a steady-state system, as
the one you describe above. It also has friction (which changes sign
when velocity does) which is somewhat protortional to velocity plus
the static friction. Also, there are cutting forces, which vary all over
the place. All of this is why old errors are not relevant to the current
state of the system. You have to find a reasonable time window to
look back through, and keep a rolling sum of those errors - unless
you want digital filtering, in which older errors become less significant.

Now, the stady-state pull of gravity makes some sense in a vertical
mill's quill, but on the X Y table, it just doesn't make any sense at
all. I suppose if there were some large DC offset in the zeroing of
the servo amp, this would correct for it, but otherwise, it just doesn't
make sense to consider the machine tool as a steady state environment.

I will comment that I've looked at PID control loops for such gear
as ramp-and-soak ovens, and steady state isn't the case there,
either, as the time constants and loads change as the oven is heated
from room temp to whatever temperature it is set for. So, they also
use the rolling sum technique, and also have a process that looks for
discontinuities (such as when ramping up and then arriving at the setpoint,
the ramp slope is discontinuous as it intersects the hold setpoint
line). This condition 'resets' all the saved errors in the rolling buffer
to zero when a discontinuity occurs, to prevent 'Integral Windup'.

> If you are limiting yourself to only driving the system through errors,
> you'll always be suffering errors. A better method is to generate a
> contribution to the output based on what you *think* it needs to be
> based on a model of the system. This is feed forward control. In the
> case of the cantilevered beam, it's not hard to determine what the
> feed-forward output should be based on the desired angle. The problem
> with this in real life is that the system model needs to include
> friction, inertia, non-linear amps and motors, etc. that are all varying
> in time as the system heats up, cools down, and ages.
>
> However, we can usually give it a good guess. For motors with tachometer
> feedback to the amplifier (velocity mode), the velocity feed forward
> term is just volts per RPM or equivalent units. You can measure this as
> Matt Shaver and I did with a voltmeter while jogging the axes at various
> speeds. Putting this simple feedforward term in dramatically improves
> the performance, especially at high speeds. This is just what Jon Elson
> discovered.
>
> The advantage of feed forward terms is that they can't cause
> instabilities like P, I, and D can. The tuning procedure should begin
> with estimating the velocity feedforward, then clean up the residual
> errors using P to increase the stiffness, D to damp out oscillations,
> and I to get rid of any steady-state errors. Note that the EMC code also
> has an acceleration feed forward term, although I've never used it.
>
> The velocity feed forward gain can be automatically calculated by
> dividing the output send to the amp by the velocity (measured by
> differencing) in the next cycle. Time delay latencies introduce a lot of
> noise, but it can be done in the EMC code. I'm going to try this and see
> how well it works.

I'm not clear on what you mean here, but I'll look at it if it makes it
into the official distribution.

Jon