Re: [foxboro] Hard-coding the block inhibit parameters

Hello Corey,
              The mystique of managing I/A alarms lives on! What I have
found is if you definitely do not want the operators to inhibit a
particular alarm, but you want to allow them to inhibit others, both
INHIB and INHALM on that block have to be tied to another paramater.
Perhaps the INHIB can be tied to itself,or to the output of another
block which is always zero. For the INHALM I mostly tie it to an Integer
output of a calc block, and set the integer value to whatever masking
pattern you require. Having said this, be advised that as soon as you do
this to a block,it always appears as an inhibited alarm on the process
summary inhibited alarm report, whether you tie it as a zero or not!
regards from sunny Australia,(where it's tomorrow already)
Alan Armour

You may know this already, and/or it may not be your problem, but I
found=20
that connecting .INHALM does not prevent inhibit changes using .INHIB.=20
Fortunately, this worked for me, since I was trying to selectively
inhibit=20
certain alarms based on process conditions, but did not want to remove
the=20
operator's ability to globally inhibit alarms on the block.

I have not had problems when connecting .INHALM with the zero bits=20
remaining settable, but I have not tried any loopback connections.
Maybe=20
it has to be hex (i.e., .INHB.X000 or 0X000 or whatever the syntax is),=20
but I would think just .INHALM.0 would also work.


I have a similar issue on other parameters though, ones that are
settable=20
but not connectable.  I'm still mulling over ways to deal with that=20
problem (d_edit scripts on the faceplates/details to set protection=20
classes on them, sequence block "enforcers", etc.).


Corey Clingo
BASF Corporation






"Joseph M. Riccardi" <joe@xxxxxxxxxxxxx>=20
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=20
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=20
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=20
high
(1) bits?  Since the INHALM parameter is one of the few Hex types, I=20
assume
it is some how treated differently?

This dilemma becomes more significant as we develop plans to hard-code=20
both
block inhibit parameters (0 =3D 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=20
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.=20
Adams





=20
=20
_______________________________________________________________________
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
=20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20
__________________________________________________________________________________
                                DISCLAIMER

The contents of this electronic message and any attachments are intended only
for the addressee and may contain legally privileged, personal, sensitive or
confidential information. If you are not the intended addressee, and have
received this email, any transmission, distribution, downloading, printing or
photocopying of the contents of this message or attachments is strictly
prohibited. Any legal privilege or confidentiality attached to this message and
attachments is not waived, lost or destroyed by reason of delivery to any
person other than intended addressee. If you have received this message and
are not the intended addressee you should notify the sender by return email and
destroy all copies of the message and any attachments.  Unless expressly
attributed, the views expressed in this email do not necessarily represent the
views of the company.
 
 
_______________________________________________________________________
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:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: