Re: AO Record: New Drive Limit Mode?

[Korhonen Timo <Timo.Korhonen@psi.ch>]

Hi,

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: 
       timo.korhonen@psi.ch