Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: AO rec flaw
From: mrk@aps.anl.gov (Marty Kraimer)
To: tech-talk@aps.anl.gov
Date: Wed, 19 Jul 1995 08:45:16 -0500
> From hill@luke.atdiv.lanl.gov Tue Jul 18 16:08 CDT 1995
> Date: Tue, 18 Jul 95 15:07:54 MDT
> From: hill@luke.atdiv.lanl.gov (Jeff Hill)
> To: tech-talk@aps.anl.gov
> Subject: AO rec flaw
> Content-Type> : > text> 
> Content-Length: 1180
> 
> 
> Hello all,
> 
> I just observed a passive analog output record that after rec init had
> STAT=UDF_ALARM, SEVR=INVALID_ALARM, and UDF=0. My device support
> successfully read the initial value out of the device (and 
> indirectly set UDF to false). Once this record is processed for the 
> first time then the UDF alarm condition goes away.
> 
> This appears to be a flaw in the AO record. The ascii rec def initializes
> stat=UDF and sevr=INVALID. When the record inits if we get the value from the
> device and the udf field becomes zero then we dont reset stat and sevr. 
> Most likely we need to call alarm() from within AO rec support just after 
> calling devRecInit()? Since recGblSetSevr() maximizes the alarm condition 
> we would need to init stat/sevr to no alarm?
> 


This is probably a problem for all output records that have device support
capable of reading current values from hardware. We have to be careful about
solution. Just changing stat and sevr is not a valid solution because there
may be other things wrong (value exceeds HIHI for example). I only can think
of two things to do.

1) Make record process once at the end of initialization. Is it a good thing
   to do this? Will this cause other problems?
2) Leave things as is. The alarm stat may be misleading since it should really
   be something like "never processed". Note that the user always has the option
   of asking that the record be processed once at initialization.

I am not sure that I like either solution.

Marty Kraimer


Navigate by Date:
Prev: AO rec flaw Jeff Hill
Next: Internal type conversion in Epics Andy Foster
Index: 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: AO rec flaw Jeff Hill
Next: Re: AO rec flaw Jeff Hill
Index: 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
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 ·