At 10:20 AM 4/9/2002, Andrew Johnson wrote:
>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?
IVOA happens after the clamping, it doesn't solve the problem.
You are absolutely correct that it is best to solve
this on the CA client side.
Using a slider prohibits the user from "entering"
values outside the limits provided by the slider.
A text-entry box could check entered values for limits
before passing them on, displaying an error message etc.
As for your remaining thoughts, in all this "Reject"
behaves like the "Clamp":
When you enter something that's wrong, we depend
on the GUI to not only send the entered value
to the record but also to monitor the record.
Whether the entered value is clamped or rejected, the GUI
will display the current value.
Unless the display turns INVALID, we know that an entered
value reached the AO record.
There is no "CLAMP" alarm state, there needn't be
a "REJECTED" alarm state.
Thanks,
-Kay
>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
- Replies:
- Re: AO Record: New Drive Limit Mode? Andrew Johnson
- References:
- AO Record: New Drive Limit Mode? Kay-Uwe Kasemir
- Re: AO Record: New Drive Limit Mode? Andrew Johnson
- Navigate by Date:
- Prev:
RE: AO Record: New Drive Limit Mode? Redman, Russell O.
- 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? Brian McAllister
- Next:
Re: AO Record: New Drive Limit Mode? Andrew Johnson
- 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
|