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
