Experimental Physics and
| |||||||||||||||
|
I just happened to be struggling with this kind of problem a while ago. I have to catch erroneus inputs before they are propagated down to the hardware. Let me just report the experience. This may be a bit exotic but nevertheless a real world example that is now in daily operation: I am driving two outputs (gap and so called "shift" of an insertion device), that are calculated from user inputs (desired photon energy, polarization mode & degree, harmonic). The range of acceptable values for the energy depend on the operating mode of the device (polarization, harmonic) and pre-calculating them would be extremely clumsy. In this case trying to catch the errors in the GUI would not be a good solution, even if it could be implemented somehow (in theory one could run a calculation to search for the max and min values every time the mode of operation is changed, and from the results to set the drive limits. However, I prefer a solid low-level solution to such cumbersome and error-prone approaches.) Another reason why I like to have the protection in the low level rather than in the GUI is that these values can be driven from other sources like a scan record, where the checks are not readily available. A particularly nasty thing (which now is fixed) was that the calculation result for some inputs can be NAN, and that was happily propagated through all the chain, down to the motors which could kill the whole IOC - a sysreset or cycling the power was necessary to restart it. (Jim Thomas wrote:) To provide another voice on Andrew's side, tough, they're all broken. The AO record already protects itself against garbage input. IMHO the GUI should not be inserting junk into the system. That's an input editing function, for which the GUI already has the necessary information. In my case, AO did not catch this (NAN) error, but passed it straight through! (the input was not coming from a GUI.) What I finally did, and seems to be running fine, was a solution using the IVOA in the calcout, sending a "Reject-alarm" to the user and reject the value - the invalid value is not sent out. In fact, with this combination I could implement both the options in Kay's original posting (although I had to play with the alarm states a bit - "Invalid" versus limit checks, like in what Andrew wrote.) Based on this experience, I would rather support Andrew's view of re-thinking the use of IVOA rather than implementing something for AO only. After all IVOA is already available in "Many" record types and it is (IMHO) better to have a general solution rather than to force the use of a particular record type (AO) if a user wants to have a validity check. But if there are good reasons to implement DRLM, then why not. Still one comment: users have complained about the fact that the value goes to the min or max limit if the input is out of range. So, having the option to reject the input is desirable, but how to implement it is another question. 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 · |