![]() |
![]() ![]()
Experimental Physics and
| ||||||||||||||||
|
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 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 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
| ||||||||||||||||
ANJ, 10 Aug 2010 |
![]() · Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |