Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Wed, 24 Apr 2002 05:00:52 +0200

Kay-Uwe Kasemir wrote:
> 
> 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.

I beg to differ. I am not happy with the proposed solution. That doesn't
mean that we shouldn't do something about the problem. See below for
alternative solutions that reuse or rather extend the already existing
features.

The first problem I see with the DRVM proposal is the apparent
discontinuity of the behavior. Let for example DRVL=0, DRVH=100, VAL=5.

Enter 10 -> VAL goes to 10
Enter 20 -> VAL goes to 20
...
Enter 99 -> VAL goes to 99
Enter 100 -> VAL goes to 100
Enter 101 -> VAL stays 5, huch?

As a user, I would find such behavior rather strange. If values in the
whole range from DRVL to DRVH may be set in one step, why should the
behavior "jump" when the limit is reached? Isn't this more confusing
than helpful, *if nothing else gives the user a hint that there is
something wrong with his/her input*?

It seems to me that such a discontinuous behavior *must* be accompanied
by the record going to some non-normal alarm severity and INVALID
appears be the "best fit" in this case. This suggests looking again at
the already proposed solution using the IVOA field for rejection of user
(or other) inputs outside the drive range by setting IVOA="Don't drive
outputs". See below for details.

> ...
> 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?

Not a good solution, indeed. Not even possible, because calcout cannot
drive hardware. Putting the calcout "before" the ao doesn't help,
because the ao's VAL could be written to directly. Yes, we can set it to
"closed_loop", but then, what if someone writes "supervisory" to the
OMSL field? As explained below, drive limits are meant for hardware
protection and garuanteeing consistency, not for fancy GUI.

> 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.

It is different but that doesn't matter at all. IVOA doesn't have to
know the reason *why* the record became INVALID. It just needs to know
*that* it is. If IVOA is set to "Don't drive outputs" this is a clear
order not to forward *any* invalid values, no matter what the reason.
And there is no question that in your case the new value *is* deemed
"invalid", otherwise you wouldn't want to "reject" it!

You could argue that VAL is not affected by IVOA but isn't this exactly
what we need? Other records that get the VAL via input links can set
their links to MS, so they know that the value isn't good. One could
even go further and say that the drive limits should similarly not
affect VAL but only OVAL, the value that finally gets written by the
record. But this would probably break existing databases so I doubt we
can do that.

The real question is not "is IVOA appropriate for handling this?",
because I think it is, but rather "How do we get the SEVR to INVALID, so
that the InValidOutputAction will be executed?".

This could be achieved in a number of ways.

(1) If we absolutely want to avoid to add more fields, we can live with
the alarm limit solution i.e. set HIHI=DRVH and LOLO=DRVL and
HHSV=LLSV=INVALID.

(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.

This would be useful for the "normal" use of the DRV* fields, too. In
many cases, the HIGH/LOW and HIHI/LOLO fields are already used to
provide "yellow" and "red" warnings (i.e. MINOR and MAJOR).

The point here is that *if* we add fields, these should provide more
than a special solution to a special problem. DRVS (combined with IVOA)
is at least more generally usable than DRVM.

(3) We could think about adding a new menuAlarmStat value, to go along
with a non-OK severity whenever the value is clamped or else rejected.
This is a little problematic because user interface clients either have
the strings compiled into them or they cannot display them properly. And
this is because the menuAlarmStat has already more entries than CA
allows for the DBR_GR_ENUM data, so CA cannot get the enum strings for a
STAT >= 16 (try monitoring STAT field with the dm2k on a record with
STAT=UDF, you'll see nothing). But this need fixing anyway, doesn't it?

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.

Some more comments on what drive limits are for and what not:

> * 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.

In principle, yes, but this is limited to cases where nothing gets
broken if the user circumvents the interface (see e.g. the 'caput'
command line utility) or the user interface cannot be relied upon. Or if
the value does not come from a user interface, etc...

> But the DRVL,DRVH checking with the original "clamping" implementation
> was generally accepted because not all user interfaces implement all possible
> checks. 

No, I don't believe this was the reason, rather:

> 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.

Exactly. My opinion is that drive limits are meant for two things:

- keeping the IOC database in a consistent state, and
- protecting the hardware

Both can only be achieved reliably at the IOC level. I would never trust
the GUI clients, neither for protection of my hardware nor for keeping
my IOC database (possibly including state machines) in a consistent
state.

> And then, in some instances DRLM=Reject is better than DRLM=Clamp.

Yes, but you can do this with the existing fields. See above.

> * 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.

It is the responsibility of the record support code to notify interested
clients (such as user interfaces) of significant changes. AFAIK the
usual display managers monitor for alarm and value changes. And both,
clamping a value as well as rejecting it, are IMHO significant enough to
post either an alarm or a value event. The least thing we should do is
to change the ao record support code so that events gets posted whenever
the value is clamped to the drive limits. This should be the same with
OROC limitation, btw. One way to unite these features is to post an
event whenever OVAL (the output value) deviates from VAL after any
applicable adjustments.

On the other hand, utilizing IVOA as proposed above automatically solves
the problem, since the record's alarm state will change and thus an
alarm event is sent. Then the user sees both, the actual value and the
changed severity which is a good thing anyway as I tried to explain in
the beginning.

Ben
-- 
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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System