I usually see anti-windup schemes for PID loops based on the output limits.
When the output hits 100%, don't allow the error to increase the I value
since the output is limited to 100% anyway.
That eliminates windup.
The car analogy is: If your foot is already on the floor what is the
point of pushing harder? I won't make the car go faster.
I've also seen contribution limits - such that the I term can't
contribute more than 30% to the output value - or else the I term is
clamped/frozen so it can't be further incremented.
This of course has nothing to do with I gain.
I've never seen any benefit to allowing I term windup when the output
reaches 100% (Although there are probably some situations where it
could be useful, but probably not for motion control.)
Dave
On 2/4/2011 10:50 AM, Peter C. Wallace wrote:
> I have an idea for a better patch to the pid comp than simply removing the "if
> limit_state" conditional around the integrator. I understand the benefit of
> "freezing" the integrator when the output is saturated. This is useful for
> good PID loop behaviour when a large step command is received: the Pterm
> saturates the output and prevents the integral term from winding up. The
> problem with the current code is that if the integrator "freeze" occurs during
> an integral term caused overshoot, it can never recover. My suggestion is to
> "freeze" the integrator only when limit_state is true and the error is
> in the direction to increase the absolute integral term. This retains the
> benefit of reducing windup during a step but will recover from overshoot.
>
> Also note that simply removing the "if limit_state" conditional around the
> integrator would require setting the integral limit default to a reasonble
> value (like< MaxOutput/Igain)
>
> Other random suggestions:
>
> I think the integral limit would be easier to understand if it was
> commensurate with the output (if you have a full scale output of 1, an
> integral limit of .5 would limit the integral terms contribution to the
> output to .5 full scale independent of Igain)
>
> Another integral overshoot reducing scheme is to bound the error input to the
> integrator. This is really an alternate to the " freezing" approach.
>
> We've had some inprovement on integral behavior by using 2 integral terms, a
> small one when the absolute integral term is increasing, and a larger one when
> the absolute intergral term is decreasing. This has the effect of speeding
> recovery from overshoots.
>
>
> Peter Wallace
> Mesa Electronics
>
> (\__/)
> (='.'=) This is Bunny. Copy and paste bunny into your
> (")_(") signature to help him gain world domination.
>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
