Re: [foxboro] Hard-coding the block inhibit parameters
- From: Corey R Clingo <corey.clingo@xxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Fri, 22 Jun 2007 11:17:25 -0500
You may know this already, and/or it may not be your problem, but I found
that connecting .INHALM does not prevent inhibit changes using .INHIB.
Fortunately, this worked for me, since I was trying to selectively inhibit
certain alarms based on process conditions, but did not want to remove the
operator's ability to globally inhibit alarms on the block.
I have not had problems when connecting .INHALM with the zero bits
remaining settable, but I have not tried any loopback connections. Maybe
it has to be hex (i.e., .INHB.X000 or 0X000 or whatever the syntax is),
but I would think just .INHALM.0 would also work.
I have a similar issue on other parameters though, ones that are settable
but not connectable. I'm still mulling over ways to deal with that
problem (d_edit scripts on the faceplates/details to set protection
classes on them, sequence block "enforcers", etc.).
Corey Clingo
BASF Corporation
"Joseph M. Riccardi" <joe@xxxxxxxxxxxxx>
Sent by: foxboro-bounce@xxxxxxxxxxxxx
06/22/2007 10:30 AM
Please respond to
foxboro@xxxxxxxxxxxxx
To
<foxboro@xxxxxxxxxxxxx>
cc
Subject
[foxboro] Hard-coding the block inhibit parameters
Folks,
Based on info gleaned from this list about hard-coding block parameters
(i.e., alarm values, etc.) and the 2 block inhibit parameters (INHALM &
INHIB), we decided to try to eliminate the High Alarm function only on a
block and wanted to hard-code it so the operators could not override it.
1st of all, it was an adventure figuring out the Hex value for the INHALM
parameter (C:B.P.INHALM.0002 finally worked to inhibit the High Alarm
only;
the 2nd lsb). My thanks to a Matt on this list for his help. The reason
for the confusion was because hard-coding these block inhibit parameters
only appeared to secure the block parameter when a 1 is applied; a 0 did
not
prevent the operators from overriding the inhibit functions, nor did a 0
override an existing inhibit from the Select display. Any explanation for
why all bits are not secured when we hard-code this parameter; only the
high
(1) bits? Since the INHALM parameter is one of the few Hex types, I
assume
it is some how treated differently?
This dilemma becomes more significant as we develop plans to hard-code
both
block inhibit parameters (0 = uninhibited) on all blocks to prevent the
operators from inhibiting block alarms (they have no access to the control
configurator). Unless I am missing something, hard-coding this parameter
with all 0s (C:B.P.INHALM.0000) accomplished nothing, so it will not
prevent
the operators from overriding and inhibiting (1) alarms? Am I confused...
again?
I sincerely appreciate the help I get from this list...
Joseph M. Riccardi, Inc.
DCS Services - Industrial Process Control
Joe@xxxxxxxxxxxxx
"To give real service you must add something that cannot be bought or
measured with money; and that is sincerity and integrity." - Donald A.
Adams
_______________________________________________________________________
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:
