Jtdylktuy

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

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.

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);

}