Experimental Physics and
| |||||||||||||||||
|
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 -- Timo Korhonen PSI (Paul Scherrer Institut), SLS CH-5232 Villigen PSI tel + 41- 56 3103262 fax + 41 - 56 310 3151 e-mail: [email protected]
| ||||||||||||||||
ANJ, 10 Aug 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |