Experimental Physics and
Industrial Control System

"Bob Dalesio" <[email protected]> · Wed, 24 Apr 2002 06:42:44 -0600

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 

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. 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, but I may want to go to some safe state if the
input I am using to compute the new output is bad. I think
that this is unacceptable.

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

> 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.
I don't agree with the "add no more fields" philosophy. I do
agree that we should not add fields that are not generally
useful.

> 
> (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.
> 
> 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.
Really diagree - as stated above.

> 
> (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. 
These strings are fetched over channel access - or should
be. This should not be a problem. If it is, the applications
put in knowledge that should not have been assumed and need
to be fixed. I think if we changed the use of IVOA, a new
status would be required.

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

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

Bob

On Wed, 24 Apr 2002 05:00:52 +0200
 Benjamin Franksen <[email protected]> wrote:
> 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

Bob Dalesio
[email protected]
410 557 0297 Maryland
505 667 3414 Los Alamos
505 699 1632 Cell Phone
505 667 6087 Our Secretary (Judy)

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System