EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Proposed R3.13.3
From: Brian Bevins <[email protected]>
To: EPICS Techtalk <[email protected]>
Date: Thu, 15 Jun 2000 10:23:43 -0400
Ben,

Having a deadband field is definitely a good idea. The cpid record
already implements this, but in a somewhat different way. The DMIN field
can be set to prevent the cpid from writing out small changes. If the
change calculated from the cpid algorithm is smaller then DMIN, then the
output doesn't change. This provides a sort of deadband on the output
rather than on the input. There is also an analogous DMAX field that
sets an upper limit on the rate of change of the output. This is useful
in protecting sensitive devices from sudden drastic changes (like sensor
failures).

We use cpid's to run a lot of DC motors (among other things) and we find
that a non-zero DMIN greatly extends the life of the motors.

I agree that a deadband on the input side would also be useful.

--Brian Bevins



Benjamin Franksen wrote:
> Since it looks as if we are going to replace the PID anyway, I have
> another proposal: an additional field for an error deadband. Whenever
> the (absolute value of the) error in the controlled variable is smaller
> than this deadband value, the PID record should assumes the error is
> zero. So differences below this value will never lead to a change of the
> correction value, even if KI is non-zero.
> 
> This would be very useful in situations where the resolution of the
> controlled variable is low and corrections are supposed to occur as
> seldom as possible (for instance, the controlling device is a motor and
> you want to reduce wear and tear). An output from the PID record that
> tries to correct an error which is caused by the limited measurement
> resolution of the controlled variable is nonsense anyway and causes
> unnecessary and easily avoidable oscillation.
> 
> Ben
> --
> The Notorious Neb Nesknarf


References:
Re: Proposed R3.13.3 Mark Rivers
Re: Proposed R3.13.3 Leo Dalesio
Re: Proposed R3.13.3 Benjamin Franksen

Navigate by Date:
Prev: Re: Proposed R3.13.3 Mark Rivers
Next: mbbo record F. Gougnaud
Index: 1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Proposed R3.13.3 Benjamin Franksen
Next: PID records [was Re: Proposed R3.13.3] Brian Bevins
Index: 1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·