# Where to put the PID windup guard?

Should I put a windup guard on each term of the PID, or just the I, or maybe the whole output?

• Windup is mostly an issue of the integral term. If you are getting windups from other terms, these are probably not designed properly. – Eugene Sh. Dec 12 '18 at 16:20
• The I term only. Switch it's input to zero when it just enters saturation – Chu Dec 12 '18 at 16:30
• @Chu If you switch it's input to zero, it will never go down. – Eugene Sh. Dec 12 '18 at 16:35
• @EugeneSh. I'm not sure if "windup" is the correct official term, but in some circumstances plant states can get out of hand. In my experience it's been mechanical assemblies driven by torquer motors, putting the traveler into a combination of velocity and position such that even at maximum braking torque it'll whack into a stop. – TimWescott Dec 12 '18 at 16:36
• @TimWescott I would call it a general instability. Can be caused by integrator windup of course. – Eugene Sh. Dec 12 '18 at 16:38

Integrator anti-windup is a measure you need to take because of output saturation or other limits in the system, and such limits are nonlinear behavior. When you start doing nonlinear control, a lot of the nice, clear, procedural things that we're taught in undergraduate control theory classes don't entirely apply.

In general you should apply integrator anti-windup to just the integrator term, although you may also need to apply limiting to the output term before it's applied to a DAC (assuming you're doing the work in software). There are a lot of ways to do this. My preference is to either limit the integrator state to certain bounds by itself:

// (Calculate integrator_state)
if (integrator_state > integrator_max) {integrator_state = integrator_max;}
if (integrator_state < integrator_min) {integrator_state = integrator_min;}


Or to calculate a candidate output, then trim the integrator state:

output_candidate = integrator_state + error * prop_gain;
if (output_candidate > output_max) {
integrator_state = output_max - error * prop_gain;
} else if (output_candidate < output_min) {
integrator_state = output_min - error * prop_gain;
}
// Re-calculate the actual output, possibly with a D term


The method that @Chu mentions would work, if you remember to only apply it when the integrator is being pulled to excess, not pulled back (but my first method is equivalent). Another method that is used often is to hold the integrator term at zero when the error is large, then allow integrator action when the error gets below some threshold, or if you're doing a motion controller that knows when a "move" starts to set the integrator at zero at the start of a move and hold it there for some finite time. I'm not a big fan of either of those methods, but others are.

Because you're venturing into nonlinear control, even if you're so far in the shallow end of the pool you can lie down without drowning, there are options on options on options, and there's no one right way to do it. Moreover, you can't find an answer by analysis -- you have to either implement the real system and give it a whirl, or make a simulation and try your algorithm out on that.

• I have opted for your first solution, and will try it out tomorrow. It's just a heater control with no safety critical features – Dirk Bruere Dec 12 '18 at 16:54
• You may find this article useful. Note that the model of a heating system in there is completely fake; you probably don't want to use it in your work. What you'll find useful is the code, and the discussion of integrator windup. – TimWescott Dec 12 '18 at 16:58
• Tim's article has been fundamental to my understanding of controls. It is well worth the short read and will help out immensely! I highly recommend it. Thank you @TimWescott! – Drew Fowler Dec 12 '18 at 17:01
• @DrewFowler: I thought I recognized that code. – TimWescott Dec 12 '18 at 17:06
• The young Padawan meets his master. – Harry Svensson Dec 12 '18 at 17:10

Windup guard is typically referred to as the protector of the integral term in order that it will not accumulate continually. The controller can overshoot significantly and will continue to overshoot with the integral continuing to grow.

Therefore, the windup guard is just the integral term. As this term can "windup" and keep growing. But, the output of a PID can/should be limited on the output as well.

For example the following code calculates the integral term and then limits it according to a set value. It also limits the output of the controller, but according to a different limiting term.

void PID_Compute(PID *pid)
{

//Find all error variables
pid->lastError = pid->error;
pid->error = pid->setpoint - pid->input;
pid->derivative = pid->error - pid->lastError;
pid->integral += pid->Ki * pid->error;

//Anti-integral Windup
if(pid->integral > pid->IntegralLimit){
pid->integral = pid->IntegralLimit;
}
else if(pid->integral < -pid->IntegralLimit){
pid->integral = -pid->IntegralLimit;
}

//Calculate PID
pid->output = (pid->Kp*pid->error) + (pid->integral) + (pid->Kd * pid->derivative);

//Set limits
if(pid->output > pid->Outmax){
pid->output = pid->Outmax;
}
else if(pid->output < pid->Outmin){
pid->output = pid->Outmin;
}
}


For anything pertaining to writing or understanding a PID controller, refer to Tim Wescott's article.

As others have already said, windup is only a problem for the I term.

Where I differ from almost everything else that I've seen, is that I don't like to arbitrarily limit my I. I want it to be able to saturate the output no matter what it takes to do that, but there's no point in going beyond that. So my limits are floating, based on the final output.

So I use a bigger datatype to hold the output than what I actually need, so I can detect out-of-range and clamp it. Then as part of that clamp, I also unwind the I. For one project, I actually back-calculated what it should have been to saturate exactly, but for another, I just switched on an exponential decay:

I_acc += Error;

//other code here

if (OUTPUT_OUT_OF_RANGE())
{
CLAMP_OUTPUT();

//anti_windup
I_acc -= (I_acc >> 2);
}