Hello:
After receiving several comments on this, the result seems to be:
A new "drive limit mode" DRLM field for the AO record
is generally accepted.
Here is a possible addition to the record reference manual,
Chapter "ao - Analog Output",
Section "3. Desired Output Parameters":
(current text)
"The VAL field's value is forced to be within the limits
specified in the fields DRVH and DRVL, which are configured
by the designer:
DRVL <= VAL <= DRVL
"
(new, additional text):
"The Drive Limit Mode field DRLM determines how the limits
are enforced:
The default setting of DRLM="Clamp" causes
values VAL < DRVL to be clamped to DRVL,
values VAL > DRVH are clamped to DRVH.
When DRLM is set to "Reject", values VAL outside of
[DRVL, DRVH] are rejected, that is VAL reverts to OVAL,
the old value. This behavior is often beneficial
for user interfaces or other cases where "jumps" should be avoided.
Example:
Assume [DRVL, DRVH]=[0, 10], VAL=1.5.
If a user tries to enter "1.7" but accidentally enters "17",
DRLM=Clamp would result in VAL=10, a rather big jump from 1.5.
DRLM=Reject would instead reject the entered value of 17
and revert back to 1.5."
Attached follow the source diffs for R3.13.3.
Comments & concerns:
* Aren't there already existing DB constructs?
A combination of ao & calcout should do the trick.
So let's remove DRVL & DRVH altogether
and guard each AO with a CALCOUT?
IVOA provides a similar functionality:
Use e.g. HIHI={value of DRVH}, HHSV=INVALID, IVOA=Don't drive output
to make the AO ignore "wrong" inputs.
Along this line, a new value ala "Revert to OVAL" was suggested
for IVOA. But: As Bob Dalesio explained, IVOA does not easily
know if we ended up in "INVALID" state because we tweaked HIHI & HHSV
or if maybe the incoming value from DOL was already INVALID.
IVOA was intended to be used with Maximize severity:
any of the records in the chain that ends in DOL might have been INVALID.
==> checking drive limits DRVL, DRVH is really different
from checking for alarm states.
* Doesn't this belong into the user interface?
It's generally best to do input checking in the user interface
instead of bogging down the IOC with this.
But the DRVL,DRVH checking with the original "clamping" implementation
was generally accepted because not all user interfaces implement all possible
checks. The value might also come from another IOC where the database
designer didn't know about our limits: In this situation
ao.OUT -----> ao
the first ao doesn't check the target ao's drive limits, it just writes to VAL!
So the IOC ultimately has to check before driving the hardware.
And then, in some instances DRLM=Reject is better than DRLM=Clamp.
* Does it work with all user interfaces?
What if I enter "17" and the record rejects the value,
reverting to the previous one? Do I see that on all display tools?
Good question.
The record will stay at the previous value. It does not send any new
monitor because after all the value didn't change.
The EDM TextEntry handles this case, correctly showing you the record's
value and not what you entered. Other display tools might show
what you entered and sent to the record, even though the record
didn't "take" it.
But the problem is not new:
Try the existing AO record, enter a value>=DRVH -> You get DRVH.
Now enter something greater than DRVH
===> The record stays at DRVH, it does not emit a monitor because
again the value didn't change. In some display tools (I tried dm2k)
you have to get "out" of the text entry field (click another widget) to see
the actual value. As long as your mouse & cursor stay in the text
entry, you see what you entered, not what the record really looks like.
* Which other output records should implement DRLM?
The longout record should: It has DRVL & DRVH, adding the DRLM field
is easy but there is no OVAL nor OVAL equivalent that would provide
the "previous" value for the rejection case.
Same: mbbo has no OVAL.
* Implementation details
In contrast to my previous suggestion, the DRLM menu is now a standalone
menu file, allowing later use with other output records.
The aoRecord.c code uses the macros which are generated from the menu file.
Thanks to Andrew for pointing this out.
Thanks to all who read this far,
-Kay
Changes from R3.13.5:
1) Added src/db/menuDrlm.dbd
# Drive Limit Mode:
# Selects how values outside the drive limits
# (e.g. AO record's [DRVL, DRVH]) are treated:
#
# Clamp: Values < DRVL are changed to DRVL,
# Values > DRVH are changed to DRVH.
#
# Reject: Values outside of [DRVL, DRVH] are
# rejected, the record reverts to the old value (OVAL).
menu(menuDrlm) {
choice(menuDrlmClamp,"Clamp")
choice(menuDrlmReject,"Reject")
}
2) src/db/Makefile.Host
--- 33,39 ----
MENUS += menuPriority.h
MENUS += menuScan.h
MENUS += menuYesNo.h
+ MENUS += menuDrlm.h
RECTYPES += dbCommon.h
USER_DBDFLAGS += -I ..
3) src/rec/aoRecord.dbd
***************
*** 282,285 ****
--- 282,291 ----
prompt("Was OVAL modified?")
special(SPC_NOMOD)
}
+ field(DRLM,DBF_MENU) {
+ prompt("Drive Limit Mode")
+ promptgroup(GUI_OUTPUT)
+ interest(1)
+ menu(menuDrlm)
+ }
}
4) src/rec/aoRecord.c (finally the code)
***************
*** 93,98 ****
--- 93,99 ----
#include "aoRecord.h"
#undef GEN_SIZE_OFFSET
#include "menuIvoa.h"
+ #include "menuDrlm.h"
/* Create RSET - Record Support Entry Table*/
#define report NULL
***************
*** 472,482 ****
struct aoRecord *pao;
double value;
{
! /* check drive limits */
! if(pao->drvh > pao->drvl) {
! if (value > pao->drvh) value = pao->drvh;
! else if (value < pao->drvl) value = pao->drvl;
! }
pao->val = value;
pao->pval = value;
--- 473,499 ----
struct aoRecord *pao;
double value;
{
! /* 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 == menuDrlmClamp)
! value = pao->drvh;
! else
! value = pao->oval;
! }
! else if (value < pao->drvl)
! {
! if (pao->drlm == menuDrlmClamp)
! value = pao->drvl;
! else
! value = pao->oval;
! }
! }
pao->val = value;
pao->pval = value;
- Replies:
- Re: AO: Drive Limit Mode Benjamin Franksen
- Navigate by Date:
- Prev:
EPICS Licensing Andrew Johnson
- Next:
Problem with iocsh prompt Rarback, Harvey
- 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:
EPICS Licensing Andrew Johnson
- Next:
Re: AO: Drive Limit Mode Benjamin Franksen
- 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
|