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

Joseph,

I understand your concerns now.  At some sites, a "start of shift" =
report of Inhibited Alarms is printed and Operators are instructed to =
verify that each inhibited alarm is actually supposed to be inhibited =
and not merely left in the inhibited state by error (or ommission). The =
shift log must state that the work (Inhibit check) was performed and =
Operators are held accountable for this.

I hve no explanation on why one can write to a connected parameter. My =
understanding is the same as your's.

Terry

-----Message d'origine-----
De : foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] =
De la part de Joseph M. Riccardi
Envoy=E9 : June 26, 2007 2:41 PM
=C0 : foxboro@xxxxxxxxxxxxx
Objet : Re: [foxboro] RE : Hard-coding the block inhibit parameters

Terry,

I appreciate the details.  The real purpose of the inquiry was that =
during our experimentation it was discovered that hard-coding the 2 =
inhibit parameters (INHIB & INHALM) only secured the parameter if the
value(s) were high (1); it did not prevent the operator from over-riding =
the value(s) set to 0.  I was just shocked and trying to get an =
explanation as I always thought hard-coding "any" parameter value =
"always" secured the parameter no matter what the value.  Unless I =
missed it, no one has explained the reason and if maybe other parameters =
have similar traits.  However...

The real issue is that we have planned to secure specific blocks to =
prevent the operators from inhibiting (1) critical alarms by hard-coding =
0s in the INHIB and/or INHALM (Hex) parameters (C:B.INHIB.0, =
C:B.INHALM.0x0003, etc.).  Unless I am missing something, we need to =
change to Plan B and will have to connect these parameters to dummy =
blocks; one for each combination of inhibits.  Plan A was much =
simpler...

Thanks again.


Joseph M. Riccardi
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


-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Doucet, Terrence
Sent: Tuesday, June 26, 2007 11:11 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] RE : Hard-coding the block inhibit parameters

I hope that I am not being redundant with any of this information.  The =
first item to configure when you want the alarm is the Option parameter.
Each type of alarm has its own parameter name.  As an example, we use =
the AIN High/Low Option (HLOP) then you have=20
=20
0 =3D No alarming
1 =3D High and Low absolure
2 =3D High Abs only
3 =3D Low abs only
=20
So if you only want low alarming then configure a 3 in this parameter =
and you never need to worry about high alarms.
=20
Once you have your alarm configured then you should connect the .INHSTA =
parameter to the INPUTS parameter of a MCIN (no IO) block. Then you can =
use the AIN default display - ALARMS - overlay to toggle the inhibits =
that you desire. Now go to the default display for the MCIN and you can =
view the hex pattern  in the INPUTS:  box. For example if you inhibit =
the High and Low Absolute alarms your will see 00030000 displayed.
=20
To set only the high and the low inhibit your would set the hex pattern
0x0003 into the AIN.INHALM. Use a program or a script with omsetimp to =
write this hex value.
=20
Toggling the  AIN.INHIB to a TRUE will inhibit all the configured alarms =
in your block.  Setting AIN.INHIB to a FALSE will release the AIN block =
to inhibit only those specified by the hex pattern of the INHALM.
Obviously, with INHIB =3D FLASE and INHALM =3D 0 all configured alarm =
annunciation is enabled.
=20
Terry
-- No attachments (even text) are allowed --
-- Type: application/ms-tnef
-- File: winmail.dat


=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

=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
 
 
_______________________________________________________________________
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: