Re: [foxboro] RE : RE : Hard-coding the block inhibit parameters
- From: "Armour, Alan" <aarmour@xxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Fri, 29 Jun 2007 10:18:48 +1000
Joseph,
I believe that foxdocs for any block with alarm function has the =
information on which bit is which to use for alarm masking using INHALM. =
Rather than say "RTFM", (read the flaming manual)here it is from a copy =
given to me by an Foxboro employee, Bill Lynn (I think now retired)>
BIT# USAGE
1 BLNALM point1, TRIP
2 BLNALM point2
3 BLNALM point3
4 BLNALM point4, OOR (out of range)
5 BLNALM point5, OPER (operational error)
6 BLNALM point6, STA (state)
7 BLNALM point7, HHA (high high Absolute), TARG, (target)
8 BLNALM point8, LLA (low low Absolute), PTRG (pretarget)
9 ROC (rate of change)
10 BAD (bad I/O)
11 HDA (high deviation)
12 LDA (low deviation)
13 HOA (high output)
14 LOA (low output)
15 HMA (high measurement)
16 LMA (low measurement)
In this list bit 16 is the least significant bit, so to inhibit HMA and =
LMA INHALM needs to be 0X0003.Note that some bits mean different thins =
to different blocks!A common trick I use is to set INHALM to -1 integer =
via logic for alarm suppression, then logically set it back to 0 to =
remove the suppression. this still allows the operators to use INHIB if =
they need to inhibit the alarm.=09
Terry,
Interesting... We definitely could toggle both parameters from the =
Select display for any value =3D3D 0, but not if value =3D3D 1. What =
exact values did you enter? Maybe I am confused with the format as you =
wrote TRUE/FALSE in your initial response and I used 1/0 (or Hex for =
INHALM)? The block book indicates "boolean con/set 0 to 1" for INHIB and =
"pack-b con/set 0 to FFFFFFFF (Hex?)" for INHALM. What is the correct =
value/format for each parameter? =3D20
I don't seem to have the same success with TAC that many of you folks =
seem to have so I will have to wait until this becomes a more urgent =
issue...
My thanks to Terry and everyone for their feedback.
J
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: Thursday, June 28, 2007 2:50 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] RE : RE : Hard-coding the block inhibit parameters
Joseph,
=3D20
I had a chance to test a connection to INHIB and INHALM at V7.1 in AIN =
block. (FoxSelect displays used for the test) =3D20 When connected, I =
could not toggle UNINH_ALL if the connected bit was TRUE. I could not =
toggle the individual alarms marked "INHIBITED". =3D20 If the connected =
bit was FALSE, I could not toggle INHIB_ALL and I could not toggle the =
individual alarms . I could select the box (Yellow
highlight) but toggle never caused the alarm to be inhibited.=3D20 =3D20 =
So the rule as I know it remains true that you cannot write to a =
connected variable regardless of the value of the source. =3D20 You =
should contact TAC and enter a CAR if your test still allows you to =
write to a connected parameter when the source is zero (false). =3D20 =
Terry ________________________________
De: foxboro-bounce@xxxxxxxxxxxxx de la part de Doucet, Terrence
Date: mar. 2007-06-26 14:54
=3DC0: foxboro@xxxxxxxxxxxxx
Objet : Re: [foxboro] RE : Hard-coding the block inhibit parameters
Joseph,
I understand your concerns now. At some sites, a "start of shift" =3D3D =
report of Inhibited Alarms is printed and Operators are instructed to =
=3D =3D3D verify that each inhibited alarm is actually supposed to be =
inhibited =3D =3D3D and not merely left in the inhibited state by error =
(or ommission). The =3D3D shift log must state that the work (Inhibit =
check) was performed and =3D =3D3D Operators are held accountable for =
this.
I hve no explanation on why one can write to a connected parameter. My =
=3D =3D3D understanding is the same as your's.
Terry
-----Message d'origine-----
De : foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
=3D3D De la part de Joseph M. Riccardi
Envoy=3D3DE9 : June 26, 2007 2:41 PM
=3D3DC0 : 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 =
=3D3D during our experimentation it was discovered that hard-coding the =
2 =3D3D inhibit parameters (INHIB & INHALM) only secured the parameter =
if the
value(s) were high (1); it did not prevent the operator from over-riding =
=3D3D the value(s) set to 0. I was just shocked and trying to get an =
=3D3D explanation as I always thought hard-coding "any" parameter value =
=3D3D "always" secured the parameter no matter what the value. Unless I =
=3D3D missed it, no one has explained the reason and if maybe other =
parameters =3D3D have similar traits. However...
The real issue is that we have planned to secure specific blocks to =
=3D3D prevent the operators from inhibiting (1) critical alarms by =
hard-coding =3D3D 0s in the INHIB and/or INHALM (Hex) parameters =
(C:B.INHIB.0, =3D3D C:B.INHALM.0x0003, etc.). Unless I am missing =
something, we need to =3D3D change to Plan B and will have to connect =
these parameters to dummy =3D3D blocks; one for each combination of =
inhibits. Plan A was much =3D3D 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 =
=3D =3D3D 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 =
=3D3D 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 =3D =3D3D the AIN High/Low Option (HLOP) then you =
have=3D3D20 =3D3D20 0 =3D3D3D No =3D alarming 1 =3D3D3D High and Low =
absolure 2 =3D3D3D High Abs only 3 =3D3D3D Low abs only =3D3D20 So if =
you only want low alarming then configure a 3 in this parameter =3D =
=3D3D and you never need to worry about high alarms. =3D3D20 Once you =
have your alarm configured then you should connect the .INHSTA =3D3D =
parameter to the INPUTS parameter of a MCIN (no IO) block. Then you can =
=3D3D use the AIN default display - ALARMS - overlay to toggle the =
inhibits =3D3D that you desire. Now go to the default display for the =
MCIN and you can =3D3D view the hex pattern in the INPUTS: box. For =
example =3D if you inhibit =3D3D the High and Low Absolute alarms your =
will see 00030000 displayed. =3D3D20 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 =3D =3D3D write this hex value. =
=3D3D20 Toggling the AIN.INHIB to a TRUE will inhibit all the =
configured alarms =3D3D in your block. Setting AIN.INHIB to a FALSE =
will release the AIN block =3D3D to inhibit only those specified by the =
hex pattern of the INHALM. Obviously, with INHIB =3D3D3D FLASE and =
INHALM =3D3D3D 0 all configured =3D alarm =3D3D annunciation is enabled. =
=3D3D20 Terry
-- No attachments (even text) are allowed --
-- Type: application/ms-tnef
-- File: winmail.dat
=3D3D20
=3D3D20 =
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process =
=3D3D Systems (formerly The Foxboro Company). Use the info you obtain =
here at =3D3D your own risks. Read =
http://www.thecassandraproject.org/disclaimer.html
=3D3D20
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: =3D3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3Djoin
to unsubscribe: =3D3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3Dleave
=3D3D20
=3D3D20
=3D3D20 =
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process =
=3D3D Systems (formerly The Foxboro Company). Use the info you obtain =
here at =3D3D your own risks. Read =
http://www.thecassandraproject.org/disclaimer.html
=3D3D20
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: =3D3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3Djoin
to unsubscribe: =3D3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3Dleave
=3D3D20
_______________________________________________________________________
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: =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
to unsubscribe: =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
-- No attachments (even text) are allowed --
-- Type: application/ms-tnef
-- File: winmail.dat
=3D20
=3D20 =
_______________________________________________________________________
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
=3D20
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
to unsubscribe: =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
=3D20
=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: //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: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
