On Tue, 8 Feb 2011, Hsuyao Tsai wrote:
> Date: Tue, 8 Feb 2011 12:43:47 +0800
> From: Hsuyao Tsai <hsuyao.t...@araisrobo.com>
> Reply-To: EMC developers <emc-developers@lists.sourceforge.net>
> To: EMC developers <emc-developers@lists.sourceforge.net>
> Subject: Re: [Emc-developers] pid bug
>
> Hi Peter,
>
> Theoratically the limit_state would not cause integrator freezing.
> Use the following code block again.
>
> /* if output is in limit, don't let integrator wind up */
> if ( ( tmp1 * pid->limit_state ) <= 0.0 ) {
> /* compute integral term */
> *(pid->error_i) += tmp1 * periodfp;
> }
>
> We would see the integrator be frozen when error term (tmp1) is in the same
> direction of limit_state. Once the pid overshoots, the error term would in
> opposite direction of limit_state. The integrator should start to recovery
> from positive or negative.
Right. I think I figured out the problem. We are using negative P,I,D terms
which works fine except it breaks the integral freezing logic in the PID comp.
This is for a velocity PID loop for spindle control. I blame Matt...
>
> To refer to tune the pid gains from this webpage(
> http://en.wikipedia.org/wiki/PID_controller), I agree to set the igain a
> reasonable value.
>
>
> 2011/2/4 Peter C. Wallace <p...@mesanet.com>
>
>>
>> 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
>>
>
>
> Best regards,
> Eric, Hsu-yao Tsai
> Arais Robot Technology
> (www.araisrobo.com)
>
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
