Integral Windup

[terryjmyers]

If Output is maxed due to a very large error (like when the controller first starts), it looks like Integral will continue to wind up (outputSum increasing) until it ALSO hits the outMax. This woudl then require outMax worth of integral needing to be integrated away. Why is the integral term processed at all when the output is clamped at either end?

Isn't this what is required (line 69):
if (output< outMax && output > outMin) outputSum+= (ki * error);
I realize it will be evaluating the LAST iterations output, but this is probably good enough.

[br3ttb]

I think there's confusion as to what it means for the integral term to "wind up." wind up means that the integral term is growing even when the output isn't changing. if there's a large error on startup, and there's room for the output to move, then the integral should help it move. that's not windup.

…

On Mon, Apr 16, 2018 at 4:11 PM Terry J Myers ***@***.***> wrote: If Output is maxed due to a very large error (like when the controller first starts), it looks like Integral will continue to wind up (outputSum increasing) until it ALSO hits the outMax. This woudl then require outMax worth of integral needing to be integrated away. Why is the integral term processed at all when the output is clamped at either end? Isn't this what is required (line 69): if (output< outMax && output > outMin) outputSum+= (ki * error); I realize it will be evaluating the LAST iterations output, but this is probably good enough. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#76>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAWL8sr4YuwT1MxvlGNcGW2fhx6T4eA3ks5tpPsAgaJpZM4TXLau> .

[terryjmyers]

In my scenario above there was no room for the output to move, in other words the output would be clamped at Max. However the integral some would continue to increment which doesn't seem desirable

[terryjmyers]

In my testing I'm getting a much more desirable response (less overshoot) by not letting the integral term increment when the output is at 100:

	   if (*myOutput < outMax ) {
		   if (ki != 0) outputSum += kp * (1 / ki * error);
	   }

(Note I switched to dependant gain sets, but its basically don't sum when *myOutput < outMax).
I mean..the way the code is right now, I basically gets to max, even while P is doing all of the heavy lifting at the start of a process.
Also note that my process is mostly an integrating process (reflow oven with as little heat loss as possible).

[br3ttb]

Much more desirable? Can you show plots before and after (including input and output) I'm surprised, as the output sum IS clamped to max output (as per the windup mitigation post in my blog series.) The integrating process thing makes me wonder if you're getting less overshoot merely because you're stopping the output from getting all the way to max, or staying there for as long. If that's the case, this isn't about windup (or my library,) at all. The trick for me is to make a library that behaves predictably and consistently no matter where it's used. So if I see that there's improvement here, the first thing I'm going to ask is "does it also improve performance on, say, a throttle control" The last thing I will suggest is trying ponm of integrating overshoot is your pain point.

…

On Mon, Apr 16, 2018, 11:16 PM Terry J Myers ***@***.***> wrote: In my testing I'm getting a much more desirable response (less overshoot) by not letting the integral term increment when the output is at 100: if (*myOutput < outMax ) { if (ki != 0) outputSum += kp * (1 / ki * error); } (Note I switched to dependant gain sets, but its basically don't sum when *myOutput < outMax). I mean..the way the code is right now, I basically gets to max, even while P is doing all of the heavy lifting at the start of a process. Also note that my process is mostly an integrating process (reflow oven with as little heat loss as possible). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#76 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAWL8uhvIbtdxxiJOkgo0kGXq3sQsqrkks5tpV6ogaJpZM4TXLau> .

[mike-matera]

I have something to add to this conversation. I've been validating my PID controller by random coefficient testing. The testing has helped my tighten up my code and I want to repay all the help you've given me.

Here's a case where ArduinoPID varies significantly from my reference implementation:

What's happening in the graph is that the initial step causes a big shift in the output because the coefficients are crazy. In the reference implementation there is no limit on the integral sum and the integral winds up and it takes several steps under the setpoint to wind down.
I've traced through your code and found that what's happening is that the integral windup is clamped to the output limits.

https://github.com/br3ttb/Arduino-PID-Library/blob/master/PID_v1.cpp#L74

      if(outputSum > outMax) outputSum= outMax;
      else if(outputSum < outMin) outputSum= outMin;

This means that ArduinoPID will forget a large error quickly, perhaps too quickly. I think you might consider making the integral windup limit separate from the output limit so that the integral can have a bit longer memory for large errors, especially since you have a floating point number to work with.

[terryjmyers]

Yes this makes sense. My whole issue with it was that when there is a large error (on startup) its appropriate to let P be the main driving force. This is why I didn't want any I at all.
But its entirely appropriate for I to start doing SOMETHING..as its going to be needed in the end anyway. I just didn't want it ramping up to 100%. I think ideally you would want to clamp it at what the output WILL be IF you could somehow know the future. I.E. Output will eventually be 40% and stable, therefore let I get up to 40% at the start even while P is maxed out just trying to get up to the SP in the first place. Something like that.

[mike-matera]

We should be careful when we talk about what the PID controller should do. What it should do is follow the equations we all know and understand even if that makes it unfit for a particular circumstance or condition. Inside of that @br3ttb has software engineering decisions to make, like whether and how to clamp integral windup, which is a feature of many controllers.

Try commenting out the lines that I highlighted. If that helps your use case you have a need for more flexibility with integral windup. If not you might consider using a feed-forward controller to minimize first-step errors.

[madhephaestus]

Just thinking about the math in terms of what its supposed to represent, the Integral should be cleared when the error changes from negative to positive, or from positive to negative. This allows for the integral tuning term to be high enough for the integral to be useful, while at the same time preventing the integral oscillation the occurs when the offset is large for a long time. If a PR would be welcome, i would be happy to add this feature.

[SimoDax]

I've just needed to check if anti-windup was implemented in this library because of a project so here's my thought about the thread:

Windup mitigation works by limiting the integral to the maximum output while allowing it to begin decreasing as soon as the error sign changes, and clamping is a simple way of doing it. This also implies that if the Proportional term is high, which usually happens on startup (like @terryjmyers has experienced), the output will be clamped but the integral will not, because the same threshold outMax is used to limit both terms (and rightfully so, there's no windup in the current implementation).
As an example, there may be cases such as this: once the controlled system is steady and very close to setpoint level, the output is only the Integral, so it must be allowed to grow up to outMax if needed. If you prevent its growth when the output is clamped (i.e. when P is still acting) then it will need to do it when it's unclamped (i.e. when P has become smaller), slowing down the controller and degrading its dynamic performance. The benefit, in the OP particular case, come from the fact that you know your system and built a "custom" controller for it. Not all system are equal though

      Just thinking about the math in terms of what its supposed to represent, the Integral should be cleared when the error changes from negative to positive, or from positive to negative. This allows for the integral tuning term to be high enough for the integral to be useful, while at the same time preventing the integral oscillation the occurs when the offset is large for a long time. If a PR would be welcome, i would be happy to add this feature.

If you clear the integral on error sign change it's not a PID anymore, since you're suddently forgetting all the system history. I agree with @mike-matera, controllers are built on a strong math basis and messing with them according to convenience can backfire, unless they're made from scratch to fit a particular application

[br3ttb]

Windup mitigation is definitely implemented in the library ( http://brettbeauregard.com/blog/2011/04/improving-the-beginner%E2%80%99s-pid-reset-windup/ ) I think the confusion may be because the sum that I'm storing isn't the error sum, but Sum(Ki+err) (this is why: http://brettbeauregard.com/blog/2011/04/improving-the-beginner%E2%80%99s-pid-tuning-changes/ ) if I were storing just the error sum, it would be tricky to figure out what value to use for a clamp. how big of an error sum is too big? because I've got Ki in there, the stored number is already in output domain. it's is, quite literally, the baseline from which the pid is working. if error is 0, the pidOutput = [my stored sum]. this is not the case for implementations that do pidOutput = ...+Ki*errSum+... because of this, I'm comfortable with how I've limited it. it may not match exactly what you need for a specific implementation, but in terms of a generic, robust, pid implementation. I'm happy with it. as a side note, if you're having trouble with large outputs on startup, you should be able to get what you need by using the SetOutputLimits() function. or, you know, changing the code however you like.

…

On Sat, Dec 22, 2018 at 3:53 PM SimoDax ***@***.***> wrote: I've just needed to check if anti-windup was implemented in this library because of a project so here's my thought about the thread: Windup mitigation works by *limiting the integral to the maximum output while allowing it to begin decreasing as soon as the error sign changes*, and clamping is a simple way of doing it. This also implies that if the Proportional term is high, which usually happens on startup (like @terryjmyers <https://github.com/terryjmyers> has experienced), the output will be clamped but the integral will not, because the same threshold outMax is used to limit *both* terms (and rightfully so, there's no windup in the current implementation). As an example, there may be cases such as this: once the controlled system is steady and very close to setpoint level, the output is only the Integral, so it must be allowed to grow up to outMax if needed. If you prevent its growth when the output is clamped (i.e. when P is still acting) then it will need to do it when it's unclamped (i.e. when P has become smaller), slowing down the controller and degrading its dynamic performance. The benefit, in the OP particular case, come from the fact that you know your system and built a "custom" controller for it. Not all system are equal though Just thinking about the math in terms of what its supposed to represent, the Integral should be cleared when the error changes from negative to positive, or from positive to negative. This allows for the integral tuning term to be high enough for the integral to be useful, while at the same time preventing the integral oscillation the occurs when the offset is large for a long time. If a PR would be welcome, i would be happy to add this feature. If you clear the integral on error sign change it's not a PID anymore, since you're suddently forgetting all the system history. I agree with @mike-matera <https://github.com/mike-matera>, controllers are built on a strong math basis and messing with them according to convenience can backfire, unless they're made from scratch to fit a particular application — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#76 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAWL8s8lbcYu-lrLs8HHN73vSf_t3yyYks5u7pvIgaJpZM4TXLau> .

-- Brett

[tablatronix]

I was having the same problem, what does it mean if the controller is still applying effort after setpoint for a large pulse with integration?

How can I do integral resets? to see if its a windup issue?

[riozebratubo]

I would be nice to have an API to tinker with the internal calculations and one solely to reset the pid.

[tablatronix]

I wound up just hacking in an integrator reset at 75% in my loop, calling SetTunings, ideally i should be using a smith predictor, but this is working for now

[br3ttb]

Resetting the internal effectively drops the output to 0. A way to accomplish this without a hack is leverage that the pid output initializes to the output pointer on the transition from manual to auto. Mypid.setmode(manual); Output =0; Mypid.setmode(automatic);

…

On Sat, Aug 22, 2020, 9:49 AM Shawn A ***@***.***> wrote: I wound up just hacking in an integrator reset at 75% in my loop, calling SetTunings, ideally i should be using a smith predictor, but this is working for now — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#76 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACYX4SHXVFZTOP4DDD4EBDSB7EHLANCNFSM4E24W2XA> .

[tablatronix]

I am doing that also for startup for example, but i had a problem using it for this for some reason, of course I forget what...
I will try it again and see what it was, i didn't comment it..