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: Tue, 4 Nov 2014 10:00:16 -0600
On 11/04/2014 04:21 AM, Benjamin Franksen wrote:
> how do you handle a client writing NaN to an analog record (which
> probably happens by accident)? My intuition tells me that the proper
> response for the record is to go into an INVALID status, but apparently
> this is not what happens by default...

Depends on the record type and the version of Base you're using, we've
fixed some of them...

> The problem with accepting NaN is that subsequent tests (e.g. via calc
> or sub record) may give wrong results, perhaps leading to motors
> starting to move when they should not (it happened to us, which is the
> reason why I write this).

Writing any kind of code that handles NaN and Inf values correct takes
extra thought that many programmers don't do. We have made various
changes to the Base record types in recent years but I'm sure we haven't
found all of the issues.

Ralph did some work on alarm limit tests recently for 3.15 so I think
we're good there, but (since it was raised earlier in this thread) I
don't remember if anyone looked at the DRVH/DRVL code yet, so here goes.
These are the first lines in the convert() subroutine [on both 3.14 and
3.15 branches]:

    if (prec->drvh > prec->drvl) {
        if (value > prec->drvh)
            value = prec->drvh;
        else if (value < prec->drvl)
            value = prec->drvl;
    }

* If either DRVH or DRVL is NaN then the first test will fail so the
value will not be limited.
* If the value is NaN, both limit tests will fail so the value will
remain a NaN. Since NaN is neither low nor high, this makes sense.
* Further into convert() a NaN value will result in OMOD being set, thus
triggering VALUE and LOG monitors. I can't say what RVAL will be set to
as I think that will be implementation dependent.

After convert() returns the process() routine does
    prec->udf = isnan(prec->val);
This results in the record being put into UNDEFINED/Invalid or UDFS
alarm state and can thus trigger the IVOA processing actions.

This seems reasonable to me, any comments?

- 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

Navigate by Date:
Prev: support for NIKHEF Hall probes Pierrick Hanlet
Next: Sequencer: are variables shared? Damiano Bortolato
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 Ralph Lange
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 ·