Limiting PID Loop Overshoot

Jerry Avins made a comment in another thread that made me realize: I discussed a lot of methods for use with PID loops that, when used correctly, limit overshoot. But dangit if I never actually said "if you want to limit overshoot, this is what you do"!

So now I'm all fired up to write an article on how to design your PID loop so that overshoot would be limited, and I'm wondering if you could share your favorite methods of doing so. The methods that I know of are:

  1. Combine a controlled command trajectory (trapezoidal) with clever feedforward to keep the integrator from really winding up, and hence relieve the need for that overshoot at the end.

  1. Use comparatively heavy derivative feedback (or back off on the 'P' and 'I' terms) to generally slow things down. This will give you a low, long overshoot which is sometimes acceptable.

  2. Seen here -- change the tuning of the controller as the target is approached, to continually kill the overshoot.

  1. Make a two-loop system with an inner, limited velocity loop wrapped by a position loop. I've done this before with success, but I think I may have also had to wrap it with feedforward -- I'm going to check.

Anyone have any others?

Thanks.

Reply to
Tim Wescott
Loading thread data ...

Classical PIDs that overshoot because the integrator has seen a net shortfall by the time the setpoint is reached (unless the response is instantaneous) and the sign of the error must be reversed for a while to discharge it. The overshoot will be 11% if the entire operation takes place in the linear region. Several solutions exist. One is dumping the integrator whenever the error it has accumulated is opposite in sign to the actual error. A further refinement prevents integration when the error exceeds a certain small amount. That may seem counterintuitive. A note below attempts to make it less so. Another way to avoid overshoot is making the forward loop consist /only/ of integration, using linear and derivative feedback.

formatting link
describes this in a little more detail. Almost every servo designer has a favorite way to modify the internals of what he calls a PID, but is no longer a PID by the time it's done.

Jerry _________________________________________ Sidebar. The purpose of integration in a PID controller is the removal of error due to finite proportional gain (an integrator has infinite gain at DC). It removes error by changing the setpoint chosen by the operator. Many commercial PID controllers call the integrator "reset" because moving the setpoint is seen as its function. The proportional gain is called "proportional band". Increasing the gain reduces the width of the linear band by allowing a smaller error to drive the circuit into saturation. Since the integrator exists to remove small errors by fine tuning the setpoint, it has no use when the system is so far from equilibrium as to be in saturation. No use doesn't mean no effect. It does harm by "winding up". When the integrator wants to move the system "up" and we know it already too "high", the only sensible thing to do is force it into line: *SHUT UP AND SIT DOWN! You'll have your turn later!*

Reply to
Jerry Avins

Overshoot is caused by insufficient phase margin. All you need to do is add phase-advance and it will fix it. You need to be careful about structural resonances however as phase advances have high freq gain and will amplify them. You may need to sacrifice some bandwidth therefore.

Tam

Reply to
Entropy

Then explain how the I-PD or I-PV that is mentioned in Jerry's link can close the error without overshooting when properly tuned. I-PD or I-PV controllers adds no zeros ( phase lead ) to the closed loop transfer function. The closed loop Bode plot has only phase lag.

Peter Nachtwey

Reply to
Peter Nachtwey

I think it is more a matter of implementation and proper tuning. I still think you have to look at pole placement first. If the closed loop poles are placed on the negative real axis the result will be either a critically or overdamped response. I still like dynamic integrator limiting when using the standard form of PID, but I prefer the incremental form because the P and D gains can be in the forward path or feedback path and not overshoot when properly tuned.

Peter Nachtwey

Reply to
Peter Nachtwey

Not so. A classical linear PID overshoots 11% in response to a step change of command. A practical PID with limited proportional band that is allowed to enter that band with a saturated (fully wound up) integrator usually overshoots more. A more practical PID whose integrator is disabled until it reaches the proportional band overshoots

11% of half the width of the proportion band. Once the error charges the integrator, overshoot is needed to discharge it.

There are many controllers that don't overshoot. Those that don't aren't really PID, whatever they're called.

Jerry

Reply to
Jerry Avins

Peter,

They can avoid overshoot because their integrators don't need to be discharged even in the absence of error due to load. Their integrators only secondarily cancel small errors. The integrator's primary purpose is limiting a step command to a ramp that the actuator can follow. That's why the time constant of integration can be shorter than you are prepared to believe. With short enough time constant, Phelan's position servos behave very nearly like an ideal bang-bang servo, accelerating full tilt half way to the setpoint, then decelerating the rest of the way. Keep in mind that bounding the integrator makes the circuit quite nonlinear, although in a mathematically tractable way.

Jerry

Reply to
Jerry Avins

The simplest option that limits overshoot on setpoint step change is to drive the proportional term only with the process measurement, not with error. This causes the process to ramp to setpoint with integral action, only. Changes in process are reacted to by all 3 terms.

In the Honeywell 3000 DCS system, this version of the PID is called equation C.

Reply to
John Popelish

The action is then very similar to what's described on my website, except that integrator windup is handled /ad hoc/ if at all.

Is it really PID if the block diagram is different?

Jerry

Reply to
Jerry Avins

Its not classical PID (everything based on error), but a variation. What I want is a controller that allows me to not just select if the proportional and derivative gains are based on error or process (the Honeywell equation selections), but allow a continuous variation between all process and all error for these terms (or a separate gain for setpoint and process changes for these two terms). This would make tuning of cascade loops much more customizable. And it would allow tuning with no overshoot on setpoint changes possible without the very over damped response of Equation C.

Reply to
John Popelish

-- snip --

- snip -

I'm not sure what you define as PID and what not -- as far as I'm concerned if the feedback path experiences P, I and D then it's a PID. You can rearrange the forward path profitably, moving the differentiator or even both differentiator and proportional out of the forward path, but as long as all three are in the feedback path then it'll respond the same to disturbances.

Ditto with how you handle integrator windup -- you can choose various methods to deal with it (and I have more than one favorite, depending on the circumstance), but if it acts like a PID to disturbances when the integrator is operating in its linear region then it's a PID to me.

Reply to
Tim Wescott

I know Jerry. The purpose of my question was to see if Tam could justify his statement. I have all forms of PID analyzed to death. PID, I-PD, PI-D, multiple degrees of freedom, double derivatives, with and without integrators etc. I am not a rookie. See Tam's statement about phase lead and overshoot. I know his statement isn't so, for reasons you have pointed out. In addition, I-PD is a PID that doesn't add zeros to the closed loop transfer function like a PID does. If Tam's statements were true then you would not want to add zeros. It is the zeros that cause the derivative jerk etc. However the zeros do extend the closed loop bandwidth which means a PID will respond faster than an I-PD to changes in the set point. I still take issue with point 1 and 4 in you link. I know you don't consider my dynamic limiting a standard PID but I haven't got a clue what you think a standard PID is.

Peter Nachtwey

Reply to
Peter Nachtwey

Our new controller provide this capability but how is one to select the PID gains and the coefficients when most can even get the PID gains right? My company makes motion controllers. I need to provide this flexibilty to maximize bandwith. I would think process people would do just fine with the I-PD.

Yes, but how would you optimize all these numbers? I know how I would do it, but must don't have the math capability.

Again, I-PD will do what you want. Cascaded I-PD should work just fine. I-PD gives up bandwidth for two important features:

  1. It doesn't overshoot when tuned properly
  2. It works well as an inner loop because it only the I term works on the error. The output of the outer loop or set point to the inner loop is usually noisy. If the inner loop is a PID, the inner loop would respond to all the 'noise' in the set point that the I-PD doesn't. This allows one to crank up of the gains on the inner loop which makes the system 'stiffer'.

When following a motion profile one want all the available bandwidth so the actual position can follow the target position during quick accelerations. In this case a PID is best.

Peter Nachtwey

Reply to
Peter Nachtwey

One way to prevent integral windup is add a limiter as the last element in the PID. Set the high and low limits that you want - typically 0 to 100. However in some cases, such as oversized valves, you may want to use a high limit less than 100 - as you get all the flow through the valve at a lower output. Subtract the input of the limiter from the output, multply by a gain obtaining: k*(output - input). Add this value to the input of the integrator. As long as the output doesn't exceed the limit, the value is

0.0. You don't want to make k too large.

Fred Thomasson

Reply to
Fred Thomasson

All right. I use 'PID' with no modifier to mean a particular configuration. You and others apparently allow the unmodified name to apply to an entire family of configurations. Which usage is "right" doesn't matter, only understanding what's meant.

Jerry

Reply to
Jerry Avins

Another comment. We use the integrator wind up error as a 'you must tune your feed forwards alarm. If the feed forwards are adjusted properly the integrator will not wind up at all. We provide a means of graphing the integrator contribution. If the feed forwards are properly tuned the integrator term remains very close to 0. One can tell by the integrator's slight variances from 0 where the feed forwards must be adjusted and it what direction. We have used this technique for years. I know that using the integrator as a tuning tool for the feed forward seems backwards but think about it. PID, in any form, only works where there is an error. If the feed forwards ( inverse of plant model ) are correct, there is very little error with even without the PID. The PID is just there to provide the necessary corrections to the output in response to load changes and modeling errors.

The use of feed forwards allows one to dodge the integrator windup problem.

Peter Nachtwey

Reply to
Peter Nachtwey

I guess that is why I get the big bucks. ;-)

I tune by trial, both with output disturbance, and setpoint disturbance. Very little math involved.

(snip)

That sounds like "Equation C" I mentioned. It is my default choice, unless its slow setpoint response is a problem.

Reply to
John Popelish

I agree. This is another benefit of having two proportional gains, one derived from setpoint and one derived from process. The one derived from setpoint is essentially a linear setpoint to output feed forward term. The I-PD form does not provide this feature.

Reply to
John Popelish

That's becuase the loop does not have the maximum bandwidth that it could. You can always reduce overshoot by reducing bandwidth (and hence increasing phase margin) but that's not always a good call.Come on - this is basic stuff - why are you still debating this in the 21st century!

Tam

Reply to
Entropy

Leave bandwidth out of it - you fix teh bandwidth and then design the controller around it. Let's suppose the bandwidth is 1kHz but there is too much overshoot. You add phase advance BUT KEEP THE BANDWIDTH AT 1kHz! That way the response time is approx the same. You cannot really design properly except in the frequency domain where you knwo what is happening.

Tam

Reply to
Entropy

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.