[foxboro] Hard-coding the block inhibit parameters
- From: "Joseph M. Riccardi" <joe@xxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Fri, 22 Jun 2007 11:30:14 -0400
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
-- No attachments (even text) are allowed --
-- Type: application/ms-tnef
-- File: winmail.dat
_______________________________________________________________________
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:
