EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: AO Record: New Drive Limit Mode?
From: Kay-Uwe Kasemir <[email protected]>
To: [email protected]
Date: Tue, 09 Apr 2002 10:46:45 -0600
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  <20022003  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  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·