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
<2014>
2015
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
<2014>
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|