Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 11 Oct 2004 12:47:19 -0500

Lawrence T. Hoff wrote:

 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.

In so far as it can do so, yet. CA also does conversions to other types
(currently implemented in the server, but Jeff has talked about moving it
to the client in the future), and we need to decide what should happen in
those cases.
 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?

The other output record types are not able to store a NaN in their VAL
field, so their behaviour related to NaN values is moot. We may need to
revisit the current calcPerform behaviour used by the calc and calcout
records too.
In common with all output record types, the ao record has IVOA and IVOV
fields that control what happens when the record is in Invalid severity.
There are several ways of putting the record into Invalid severity, the
alarm limits being one, UDF another, and reading a value through DOL with
MS from another record that is in Invalid severity. I am suggesting that
the ao's VAL field holding a NaN should cause UDF to be set, thus
triggering this mechanism, which allows the system designer to control
what happens in this circumstance.
 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.

There are records for which NaN and +/-Inf values may be appropriate; I am
currently revising the sel record slightly, which in all versions to date
has used a magic number of 1e30 in its input fields A-L to mean "Ignore
this field". This is not particuarly desirable as 1e30 could concievably
be a valid input for some system, so I'm modifying the code to use NaN in
place of the magic number. This now means that a system could be designed
that specifically needs to be able to put a NaN into one of those fields,
in order to tell the record to ignore this field in its High/Low/Median
calculation. A subroutine record could use a similar technique if the
user desires. Thus I don't like the idea of preventing the network
transport from passing NaN values around.
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.

To the point about the SNS application, there's no guarantee that the IOC
knows what the appropriate value is in this setup (the last value the
record held may not be correct in many cases), so there's no way the IOC
could solve this problem anyway.
It is concievable that we might want to add another IVOA action which does
a "restore previous value". However this would have to be implemented in
all appropriate record types, and might require the addition of a new
field to the record types.

[Beware, wild metaphors approaching...]
Historically IOCs have pretty much ignored the possibility that float and
double fields could contain NaN or Inf values, because vxWorks didn't seem
to provide the necessary infrastructure to detect and deal with them.
That particular issue is becoming less of a problem, so what I am trying
to do is wrench the Ostrich's head from where it's buried in sand, and
include some method by which systems can be protected from such rogue
values. CA is by no means the only way that a NaN could be injected into
an IOC, and I don't think that putting a guard on that transport mechanism
is a good place to try and fix the problem. If anyone has any other
suggestions on how to resolve this I'd be happy to hear them.
- Andrew
--
Dear God, I didn't think orange went with purple until I saw
the sunset you made last night.  That was really cool. - Caro

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System