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;
> > }
> > }
>
- Navigate by Date:
- Prev:
Re: AO Record: New Drive Limit Mode? Brian McAllister
- Next:
Re: AO Record: New Drive Limit Mode? Kay-Uwe Kasemir
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
<2002>
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: AO Record: New Drive Limit Mode? mooney
- Next:
RE: AO Record: New Drive Limit Mode? Kay-Uwe Kasemir
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
<2002>
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|