Experimental Physics and
Industrial Control System

Kay-Uwe Kasemir <[email protected]> · Tue, 09 Apr 2002 10:56:09 -0600

Hello:

Russell and others are correct about user notification:
How do you notice that a value reached the record
but was rejected?

You hope that unless the GUI turns INVALID,
all entered values do reach the records but
are rejected.

This is not new: Enter something greater than DRVH.
You can do this over and over again, the record
will stay at DRVH. No alarm state, nothing tells you
why the entered value is "lost".

As Andrew indicated, the optimal solution would be on the GUI side:
Enter a wrong value, it's rejected.
Enter it again, a message box displays "XXX is not within DRVL ... DRVH".
Enter it again, a voice says  "XXX is still not within DRVL ... DRVH" etc.
There should be a configurable list of actions.

While we are updating edd/dm, medm, dm2k, edm and all the custom CA GUIs
written in tcl, python, Visual Basic, ...
DRLM="Reject" sounds like the best near-term solution to me.

Thanks,
-Kay

At 10:44 AM 4/9/2002, Redman, Russell O. wrote:
>A DRLM field sounds very sensible to me, and not just for the AO record.
>Similar problems are possible with mbbo, longout, and any other record that
>outputs values that must lie in a finite range records.  In most cases, I
>think leaving the old value unchanged is the correct response (i.e.
>DRLM="Reject").  
>
>I do have one other question, though. Other than noticing that the old value
>did not change, is there any way to detect the input error?  With the
>suggested change to the code (and indeed with the original code) the error
>response happens silently and nothing is recorded in the record to flag the
>attempt to set its value outside the legal range.  Whether the new value is
>sent from a GUI, another database via channel access, or an SNL state
>machine, it will vanish mysteriously, leaving no trace.  This makes the
>database hard to debug!
>
>At the least, I think the record should automatically push a message to the
>error log, if it has been enabled.   Since the record did not change its
>value, it would probably not be appropriate to modify the STAT and SEVR
>fields, yet there ought to be something to alert the user that an attempt
>was made to push a bad value into this particular record.
>
>Cheers,
>Russell O. Redman
>
>> -----Original Message-----
>> From: Kay-Uwe Kasemir [mailto:[email protected]]
>> Sent: Tuesday, April 09, 2002 8:27 AM
>> To: [email protected]
>> Subject: AO Record: New Drive Limit Mode?
>> 
>> 
>> 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;
>> >         }
>> >     }
>> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System