AO Record: New Drive Limit Mode?

[Kay-Uwe Kasemir <kasemir@lanl.gov>]

Hello:

Some users here at LANL had a suggestion that's actually useful.
The best solution seems to be a new AO record field,
but before adding it, Marty suggested to run the idea by the
community. His concerns:

1) Is it compatible with existing applications? VERY important.
Definitely: Default behavior of AO stays the same.
When new field is added to the "end" of the other AO fields,
driver/device support is binary compatible(!) with original AO.
Otherwise recompilation is required.

2) Are these new fields generally useful?
I'd say so.

3) Are there other ideas that will accomplish the same purpose
   but provide even more functionality with about the same overhead.
I'll list some, but none look compelling to me.

The problem is about entering "wrong" values from a GUI,
that is values outside of [DRVL, DRVH].
Per default, the AO record would "clamp" the value, e.g.
Value > DRVH    ==>   value = DRVH.

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.

It's little things like this which make people
(at least here at LANL) say: EPICS stinks, this would be
so easy to do in LabVIEW, Visual Basic, Fortran, anything else.

Marty suggested that OROC weakens the "jump". True,
but it is confusing to the user when he enters a
something outside the limits and suddenly the value
starts ramping towards the high/low end.

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).

Alternatives to this solution are:
a) Don't modify the "original" AO but create a new "MyAO".
   ==> Have to add new device support DBD entries.
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.
c) AO record for GUI, AO record for the value that's actually used,
   SNL sequence that handles the checking.
   ==> Like b but worse


Thanks,
-Kay

PS: Here are the diffs from R3.13.5 that implement DRLM:

Index: aoRecord.dbd
===================================================================
4a5,10
>
> menu(aoDRLM) {
>       choice(aoDRLM_Clamp,"Clamp")
>       choice(aoDRLM_Reject,"Reject")
> }
>
105a112,119
>
>       field(DRLM,DBF_MENU) {
>               prompt("Drive Limit Mode")
>               promptgroup(GUI_OUTPUT)
>               interest(1)
>               menu(aoDRLM)
>       }
>                                          

Index: aoRecord.c
===================================================================
96a97,99
> #define DRLM_Clamp 0
> #define DRLM_Reject 1
>
475,479c478,498
<         /* check drive limits */
<       if(pao->drvh > pao->drvl) {
<               if (value > pao->drvh) value = pao->drvh;
<               else if (value < pao->drvl) value = pao->drvl;
<       }
---
>     /* check drive limits */
>     if(pao->drvh > pao->drvl)
>     {
>         /* Clamp  => Force to be within DRVL ... DRVH
>          * Reject => Revert back to old value unless within limit
>          */
>         if (value > pao->drvh)
>         {
>             if (pao->drlm == DRLM_Clamp)
>                 value = pao->drvh;
>             else
>                 value = pao->oval;
>         }
>         else if (value < pao->drvl)
>         {
>             if (pao->drlm == DRLM_Clamp)
>                 value = pao->drvl;
>             else
>                 value = pao->oval;
>         }
>     }