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

Subject: Re: AO ALST & MLST stuck at nan.
From: Andrew Johnson <[email protected]>
To: [email protected]
Date: Thu, 4 Oct 2012 18:28:15 -0500
Hi Mike,

On 2012-10-04 Zelazny, Michael Stanley wrote:
> I have an AO record whose ALST & MLST are stuck at nan:

Interesting, that would appear to be a bug...

> According to Matjaz Kobal, COSYLAB, "Every arithmetic expression that
>  includes a NAN value will have a NAN value as a result. So "delta" will
>  have a value of NAN. Also every comparison with a NAN value will return
>  false. So none of the two if statements will execute their bodies and the
>  monitor_mask will not change. Since the ALST field value is not changed
>  anywhere else, there is no way to get inside the if statement."
> 
> I have not verified the above statement, but I believe it to be true.

Pretty much.

> Q1: Have you ever seen this?  If you have, how did you overcome it?

No.

> Q2: Any idea HOW my ALST & MLST got nan?

Well ALST and MLST get set from the VAL field at record initialization time, 
so the NAN could have come in that way.

> I'm tempted to change the code to:
> 
>         if ((epicsNAN == delta) || (delta > prec->adel)) {
>                 /* post events on value field for archive change */
>                 monitor_mask |= DBE_LOG;
>                 /* update last archive value monitored */
>                 prec->alst = prec->val;
>         }
> 
> Q3: Is there any reason I shouldn't?

Yes, because it won't work, (epicsNAN == epicsNAN) returns false (see Matjaz's 
statement above).  There have been bugs reported in more than one C compiler 
optimizer when their author assumed that x==x is always true.  Much better is 
to change the sense of the conditional so the comparison with NAN returning 
false triggers the if statement:

    if (!(delta <= prec->adel)) { /* handle NAN properly */

I would think a similar change should be made to quite a few record types in 
Base (if anyone gets there before I do please send me a patch file...).

- Andrew
-- 
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte

Replies:
RE: AO ALST & MLST stuck at nan. Zelazny, Michael Stanley
References:
AO ALST & MLST stuck at nan. Zelazny, Michael Stanley

Navigate by Date:
Prev: Re: Announcing pymsi - EPICS macro substitution and expansion tool Angus Gratton
Next: RE: Lambda-TDK Genesys support Allison, Stephanie
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: AO ALST & MLST stuck at nan. Zelazny, Michael Stanley
Next: RE: AO ALST & MLST stuck at nan. Zelazny, Michael Stanley
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·