Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Tue, 09 Apr 2002 11:20:03 -0500

I'd like to throw in a few more spanners to consider.

Doesn't the AO record already have a very similar behaviour controlled by
the IVOA field?  It's not quite the same, but do we really need this kind
of thing to be implemented twice?

Kay-Uwe Kasemir wrote:
> 
> This can lead to jumps. Example: [DRVL,DRVH]=[0...10], current value 0.5.
> User wants to make it 0.6 but accidentally enters 60
> ==> You jump to 10. That's a big jump from 0.5!
> Just staying at 0.5 and allowing the user to try again
> might be better.

This input-range check is a problem that really only applies to user-typed
inputs - why should the IOC be doing work that the GUI can do?  CA can
provide the drive limits for a channel (control double), which the AO
record supplies from DRVH and DRVL, thus it would be possible to do this
elsewhere.

> Solution: New AO field DRLM - "Drive Limit Mode"
> Possible Values:
> 
> a) "Clamp" (default)
> As before, any value outside of DRVL ... DRVH
> is clamped/changed to DRVL or DRVH.
> 
> b) "Reject"
> Any value outside of DRVL ... DRVH
> is rejected. The record returns to the
> previous value (still available in the OVAL field).

What does "reject" actually mean though - with this implementation the CA
client doesn't get notified that the value was bad.  The only way to
detect this programmatically would require that we monitor the AO.VAL
field and ensure that our new value sticks - yuck.

Shouldn't it also also provide
c) "Reject-alarm"
As "Reject" but puts the record into an alarm state.  But what severity to
use?  perhaps we'd need "Reject-MINOR" and "Reject-MAJOR".  Actually this
behaviour can probably be done already using IVOA though, so maybe it's
not needed.

> b) Replace each GUI-related AO record by a combination of AO, CALCOUT
>    that performs the checking.
>    ==> Much more CPU overhead: Multiple records instead of ~5 lines of C.

Adding one CALC record isn't that much more CPU overhead for your
application, but you have just added a little bit more work to every AO
record that doesn't need this behaviour.

> c) AO record for GUI, AO record for the value that's actually used,
>    SNL sequence that handles the checking.
>    ==> Like b but worse

Agreed this is worse - a CALC record would use much less CPU.

d) Add an option to check an entered number against the channel's control
limits to the GUI.

Something does bother me slightly about just changing VAL back to the old
value when there is a text widget pointing to the channel - do all display
managers properly and immediately update the display if the value of a
record is changed underneath a text widget that has focus?  ISTR that some
only update the text input string when the focus is moved away, so until
the user moves his mouse he doesn't know that the value didn't "take". 
Maybe this isn't a problem though as the user will have just pressed
return, but I'd like to see this checked on the main OPIs as I can't think
of many fields that currently bahave like this.

PS: Don't use #defines in aoRecord.c for DRLM_Clamp and DRLM_Reject, put
the menu into its own menuDRML.dbd file and convert it to a .h file that
you #include instead, that way your definitions are always guaranteed to
match the menu.  See src/db/menuIvoa.dbd and aoRecord.c for a good
example.  OMSL is a *bad* example...

- Andrew
-- 
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away.
- Antoine de Saint-Exupery

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System