EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: calc/calcout and NAN
From: Marty Kraimer <[email protected]>
To: Korhonen Timo <[email protected]>
Cc: [email protected]
Date: Thu, 28 Mar 2002 13:42:07 -0600
EXECUTIVE SUMMARY: Yes


DETAILS:


While looking at the severity set during the current round of record processing it is nsev NOT sevr that should be checked.

A grep for sevr in src/rec for both 3.13 and 3.14 shows only two uses of sevr. This one and in mbboDirect.c which has

        if(pmbboDirect->nsev < INVALID_ALARM
        && pmbboDirect->sevr == INVALID_ALARM


Thus it is looking for the record going from INVALID to something else. This is OK.


I will fix this in both 3.13 and 3.14

Thanks again.


Marty Kraimer




Korhonen Timo wrote:

Hi Marty,

there was a little bit more to this story:

I wanted to use the IVOA field in calcout record to prevent the
NAN to be propagated to further records when the return value
from the calculation is invalid. This almost works - but the
first time the 'nan' gets through and corrupts other records
down the chain. It can even hang the ioc, and what was particularly
nasty that the nan was propagated down to a motor record and the
controller card (oms58) 'died', i.e., needed a sysreset to restart
it (after ctl-x, iocInit was hanging.)

After some more investigation (by the way, 3.14 on a Linux host is a
tremendous tool to debug this kind of things!) I could figure out that
the value really got only out once. The record decides if the outputs
are driven by looking at sevr field. However, sevr is the alarm status
from previous processing and gets updated only when recGblResetAlarms
is called (which in this case is done in the monitor routine.)

Now, my question is: is it OK to check nsev instead of sevr here?
I don't see a reason why not, but I may be missing something.

The code (around line 588 in calcoutRecord.c, in routine execOutput):

       /* Check to see what to do if INVALID */
        if (pcalc->sevr < INVALID_ALARM ) {
            /* Output the value */

in the middle line, change pcalc->sevr to pcalc->nsev

This prevents the NAN being propagated (when the record is
configured properly.)

Timo






References:
calc/calcout and NAN Korhonen Timo
Re: calc/calcout and NAN Marty Kraimer
Re: calc/calcout and NAN Korhonen Timo
Re: calc/calcout and NAN Korhonen Timo

Navigate by Date:
Prev: Re: calc/calcout and NAN Korhonen Timo
Next: seq 1.9.5 restored to ftp site Peter Kurpis
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  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: calc/calcout and NAN Korhonen Timo
Next: seq 1.9.5 restored to ftp site Peter Kurpis
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
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 ·