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: Benjamin Franksen <[email protected]>
To: EPICS Techtalk <[email protected]>
Date: Thu, 15 Jun 2000 13:21:10 +0200
Mark Rivers wrote:
> 
> I think that the CPID record suffers from some of the same problems with the
> PID record which I describe at:
> http://cars.uchicago.edu/software/epidRecord.html#Problems
> 
> I think my EPID record fixes these, and would suggest that it might be a
> better candidate for inclusion in base.  I am also happy to continue to
> distribute it separately.

Leo Dalesio wrote:
> 
> It seems that we all agree that the one in base needs to go. Perhaps we
> could include both EPID and CPID. Rename EPID to be PID. It appears to be a
> correct version of what PID attempted to do. CPID is special in that it
> includes some model features. If CPID has some of the same problems that
> were found in PID, it would be worthwhile to fix them. Someone at JLab may
> want to look at this.
> Is anyone using the original PID? SUccessfully? 

Yes. Our configuration is currently so that the error Mark described
should not occur. I nevertheless support the proposal to replace PID by
EPID since the error in PID could become a *real* problem if our
configuration changes. It seems to be a good idea to fix this problem in
the CPID, too.

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


Replies:
Re: Proposed R3.13.3 Brian Bevins
References:
Re: Proposed R3.13.3 Mark Rivers
Re: Proposed R3.13.3 Leo Dalesio

Navigate by Date:
Prev: RE: Proposed R3.13.3 Steve Lewis
Next: Re: Proposed R3.13.3 Mark Rivers
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 Leo Dalesio
Next: 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 ·