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: Drive Limit Mode
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Wed, 24 Apr 2002 18:04:30 +0200
Bob Dalesio wrote:
> 
> After writing a long letter and deleting it, I decided a
> small table might better argue the point.
> 
> Current Proposal allows the following:
>                     IVOA                DRLM
> closed loop        Safe Value           clamp or
>                    or Don't Change      reject
> 
> supervisory        Don't care           clamp or
>                                         reject
> 
> Overloading IVOA - Invalid from clamp or bad input -
> closed loop        Safe
>                    Don't Change
>                    Clamp
> 
> Invalid only from clamp
> Supervisory       Safe value - really doesn't pertain here
>                   Don't Change
>                   Clamp

IVOA is not responsible for imposing drive limits, because that is what
the drive limits are for. Therefore IVOA="Clamp" is nonsense. I would
never propose such a value for IVOA. Also, I see not what this has to do
with "overloading".

Anyway, the point is: nobody forces you to set the (proposed) DRVS to
INVALID. If in a certain application, e.g. a closed feedback loop, there
is nothing bad about reaching the drive limits then the value is clamped
by the drive limit fields and written and that's it; just as it is
nowadays. No severity change in this case, so IVOA does not apply. If,
however, the INVALID severity is reached via an MS link, then the value
definitely *is* invalid and IVOA can and should apply.

> In the overloading of IVOA, it becomes unclear if the clamp
> is from a bad input or a limit being reached. I would argue
> that you may want to handle them differently. 

At the moment you cannot do this. Invalid is invalid and IVOA only looks
at the severity. I am arguing that further distinction is not necessary,
because the drive limit clamping works independent from any alarm state.

> In this case,
> we can't I could want to clamp at the limit if the PID
> computed a new output that is past the drive limit of the
> hardware, 

No problem, just use DRVL & DRVH and do not set HHSV/LLSV to INVALID.

> but I may want to go to some safe state if the
> input I am using to compute the new output is bad. 

No problem, just set IVOA accordingly.

> The problem of what to do with the INVALID severity in the
> case where we clamp and the VAL is returned to the previous
> value also exists. We could keep the VAL as the INVALID
> value and stay in INVALID alarm until someone changes it 

...which could be done today by setting HHSV / LLSV to INVALID...

> or
> reject the VAL, restore VAL, and go into INVALID severity,
> Drive Limit alarm status, until the next time the record is
> scanned. Either are OK, but not great. In the case where we
> add DRVM, the new VAL is just rejected and no new alarm
> condition created. Maybe this is also - just OK.

Everyone I have seen so far using the motor record for the first time is
quite confused when their values are rejected. That this is because the
value is outside the soft limits seems not to be obvious, *even* with a
visible alarm state change.

> > (2) Add a field DRVS, aka "Drive Limit Severity"; a db
> > configurable
> > field which determines the severity the record gets,
> > whenever (and for
> > whatever reason) VAL reaches the drive limits.
> There is a very slim difference between this and the DRVM
> suggestion. In this case, we get another way to set an alarm
> condition that is mutually exclusive of the limit switches.
> In the DRVM case, we get an additional way to handle a
> different problem.

I repeal my DRVS proposal. It is pure luxury. Just use the alarm limit
fields and set their severities.

> > Alternatives to using IVOA are:
> >
> > (a) Add a new value to the IVOA menu, saying "Revert to
> > previous" and
> > meaning that the VAL field should be reset to PVAL, but
> > OVAL should
> > nevertheless be set as in "Drive outputs normally". Or
> > any combinations
> > such as "Don't drive and revert to previous", etc... I
> > think this is
> > preferable over adding a field.
> >
> > (b) Use the OROC field. Didn't you argue that "sudden
> > jumps" in the
> > value should be avoided? Is this not exactly what OROC
> > supplies? Here,
> > too, it would be useful to have the possibility to make
> > the record
> > somehow go to an INVALID (or some other) severity if OROC
> > limitation
> > applies, i.e. abs(VAL -PVAL) > OROC.
> This is not a limit, but a ramping constant. So the value
> would go from the current value to the new, large value by
> these increments at the scan rate.

I am quite aware that OROC can be used for ramping. This does not
preclude it use for avoiding accidental sudden jumps of the value.

> The one arguement not met by this is the argument that a
> rejected value should cause an alarm to trigger. This needs
> further thought in the DRVM solution. Another field to set
> the severity of rejecting a value? Then that's two new
> fields - oh no. It probably should be so. 

With my proposal this is not necessary, since the invalid alarm causes
the rejection.

> Does the VAL stay
> the out of range value and the alarm state conitnue to be
> out of range? Or do we reject the value, set VAL back, and
> only report the alarm condition once, but loose what the bad
> VAL was?

>From the record reference manual:

If IVOA is CONTINUE, then call writeValue.
If IVOA is NO_OUTPUT, then do not write output.
If IVOA is OUTPUT_IVOV, then set VAL to IVOV, call convert if necessary,
and then call writeValue.

-> add this

If IVOA is REJECT, do not write output and reset VAL to PVAL.(*)

This is all we need to implement the reject behavior, where VAL does not
change if user tries to give it a value outside drive range. That record
has to go to invalid state before, is - as I explained - only
consequent.

Note: If the INVALID severity comes from bad user input, e.g. HIHI=DRVH
and HHSV=INVALID, then STAT will become HIHI_ALARM, although VAL is
below HIHI. But then, reject behavior is strange anyway, and a look at
the IVOA field will explain this.

In complex applications I never let the user directly interact with
control records. Rather I use a soft record that outputs its value to
the controlling record(s) via OUT link. The user record always has
DISS=INVALID and IVOA=NO_OUTPUT. This makes it easy to reject wrong or
unexpected input. Very simple and very effective. Needs only one
additional ao record for the user interaction.

Ben

(*) More precisely: Set VAL to the value that PVAL had at the start of
the record processing. Currently PVAL is set to VAL inside convert()
which is called before IVOA is evaluated. Thus for the above to work,
PVAL must be saved in a local variable inside process() before calling
convert() and in case IVOA=REJECT this saved value should be used for
resetting VAL.
-- 
Berliner Elektronenspeicherring-Gesellschaft für Synchrotronstrahlung
(BESSY) GmbH, Control System Group
Albert-Einstein-Straße 15, 12489 Berlin, +49 30 6392 4862, www.bessy.de

Replies:
Re: AO: Drive Limit Mode Benjamin Franksen
References:
Re: AO: Drive Limit Mode Bob Dalesio

Navigate by Date:
Prev: GTR: Generic Transient Recorder Marty Kraimer
Next: Racal 3161 Waveform Generator John Faucett
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: menuAlarmStat [was: AO: Drive Limit Mode] Benjamin Franksen
Next: Re: AO: Drive Limit Mode Benjamin Franksen
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 ·