Experimental Physics and
Industrial Control System

"Lawrence T. Hoff" <[email protected]> · Sat, 9 Oct 2004 07:44:20 -0400

	Just to be crystal-clear, it sounds (to me) like the 
consensus position is that CA should propagate, communicate, 
and otherwise handle NaN (and INF) like any other floating 
point value. 

	The places where such values should be rejected as 
inappropriate are at the client-side ("above" CA), or in 
device support. In addition, the aoRecord (but no other 
output records) will be modified so that it can optionally 
recognize NaN and suppress executing device support "write_ao()" 
function when NaN is encountered (essentially as a convenience
for existing device support modules which do not check for NaN 
themselves). Is that right?

	Blocking inappropriate values at the client side is not 
fool-proof, and not just for NaN. I am sure that the SNS 
save/restore program sent NaN due to design or programming error, 
not intentionally. Design/programming errors can result in other 
inappropriate values to be sent as well (e.g. improperly initialized 
memory). NaN, however, has the unique property that it is easily 
recognizable as highly likely to be inappropriate. Even so, the 
consensus seems to be that suppressing the transmission of NaN via 
CA is too restrictive, or may "break" existing applications.

	The ramification of this is that if a NaN (or other 
inappropriate value) is sent to a PV, it will make it at least as 
far as the record before being flagged as inappropriate. I think 
this means that the previous "good" value is obscured. Even though
the NaN is "trapped", it still may be necessary to re-send the
previous value in order for the system to operate properly.
Is that right? In the case of SNS, that would mean using some
older save/restore file that did have an appropriate value for
the PV in question.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System