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
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
