Re: [foxboro] Auto open overlay
- From: "William C Ricker" <wcricker@xxxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Thu, 27 Mar 2003 14:27:55 -0500
>Both approaches so far pop the overlay up regardless of
>the Display on the WP.
>...
>The problem with just popping up an overlay is that it could be VERY
>inconvenient for the operator and you don't know where to put it
>necessarily.
True enough. I suppose I should also include that we only
have done this on a system where there are multi-headed WP's,
and one head is specifically designed to support this.
Where we have used the automatic pop-up, for example, is on a safety
system alarm, where the dedicated screen pops up display/overlay with
alarm information, and even pinpoints the tripped sensor on a 'map'
of the facility which is part of the display. ( I can't claim this
idea as mine; only it's implementation). The wprkstations there are
4 screen WP70s; pop ups are always to the same screen of the station,
and always on two stations at once (redundancy in case one WP is down).
>I don't know, but I suspect that the desired behavior is:
>
>1) Call up display
>2) While display is up, raise overlay if the bit is set (or reset or
toggles
> whatever)
>3) Close display and have the monitoring stop.
In my experience, this is usually not the case. The desire is to have
the operator be aware of a (sometimes) rare and (always) important
process or system condition regardless of what display is on screen.
My usual aproach to this request is to build an object which lights up
pretty clearly when the alarm condidtion occurs, and is configured to
call up the overlay when picked. This object is then added to every
operator display on the system, being built such that it will not
interfere with any display it's added to. After the discussion of
what a popup could do to the operator when he is ,for example, changing
a setpoint, or starting a motor, if the screen unexpectedly changes
under his cursor, this method generally becomes the prefered one.
A couple of notes on the sequence block idea...
a) Its nice because it keeps process control and operator
support functions in the realm of CIO and Display Data Base.
It is always better to stay out of UNIX or NT areas for these
direct control/operation functions. It is also far less likely
to be lost or botched on a system upgrade. Wish I'd thought of
it.
b) I expect there should be some handling for the case when the alarm
triggers, but the WP or DM is down ; in that case I fear the sequence
block would otherwise fail and switch to manual, and the operator
would not nessessarily know about it.
William C. Ricker
FeedForward, Inc.
Marietta, GA, USA
wcricker@xxxxxxxxxxxxxxx
770-426-4422
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
