PID control and NIST Software

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. 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.

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.

--Fred