EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: NaN and analog records
From: Andrew Johnson <[email protected]>
To: <[email protected]>
Date: Wed, 5 Nov 2014 09:48:24 -0600
Hi Ben,

On 11/05/2014 05:59 AM, Benjamin Franksen wrote:
> As it turned out (I did not observe the failure myself, and perhaps I
> misunderstood my colleague) the client wrote the NaN directly to the A
> field of the subroutine record with no intervening ao record. Using an
> ao record which forwards its value via OUT link to the subroutine
> record's A and setting its IVOA to "Dont' drive outputs" would have
> prevented the problem. Also, the subroutine record probably *did* become
> INVALID, but this wasn't checked by subsequent records which monitored
> the subroutine's VAL field.

Note that just having a NaN in one of the input fields of a sub record
may not result in the record going INVALID, only the VAL field is checked.

> Furtehr comments:
> 
> The way NaNs are handled in the ao record seems reasonable to me, too.
> One might question whether it makes sense to actually (try to) convert
> when VAL is NaN, but I guess this is a matter of taste.

No, I think that's a good suggestion. The NaN handling has been added to
the Base record types only in the later versions and that's one idea
that nobody has suggested yet. The record should have a defined
behaviour for a NaN value, but currently it probably does different
things on different architectures.

> What about other record types?
> 
> Looking at the code (base 3.14.12.2 sources) for sub, calc, and calcout
> reveals that they, too, set prec->udf = isnan(prec->val), so I think
> these record types are doing the right thing. (I haven't checked this in
> depth, though).
> 
> One loop hole remains in the ai record: it checks for NaN only inside
> the convert procedure. Thus, writing a NaN directly to the ai record's
> VAL will not cause the record to become INVALID (assuming INP is empty).
> This is perhaps a somewhat non-idiomatic use of an ai record, but there
> is nothing to prevent it being used like that, so I guess the check for
> NaN should be made directly inside process() like for the ao record.

I'm not disagreeing with you and I haven't looked at the code since
reading that, but I would point out that the ai record doesn't have
anything like the IVOA/IVOV fields of the ao record, so the NaN
detection is probably not as important.

Patches for the 3.16 branch will be welcome after we've released 3.15.1.

Thanks,

- Andrew
-- 
People everywhere confuse what they read in newspapers with news.
-- A. J. Liebling

Replies:
Re: NaN and analog records Benjamin Franksen
References:
NaN and analog records Benjamin Franksen
Re: NaN and analog records Andrew Johnson
Re: NaN and analog records Benjamin Franksen

Navigate by Date:
Prev: Job opening at PSI (Control System Specialist/Software developer) Celcer Tine
Next: Re: catools (caget/caput/camonitor) and locale settings from the environment Torsten Bögershausen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: NaN and analog records Benjamin Franksen
Next: Re: NaN and analog records Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·