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

Terry,

Interesting...  We definitely could toggle both parameters from the
Select display for any value =3D 0, but not if value =3D 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? =20

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.


Joseph M. Riccardi
DCS Services - Industrial Process Control
=20
North-Central Office (OH, PA, MI, IN, WV area)
South-East Office (FL, GA, AL, SC, NC area)

www.eRiccardi.com
=20
386-441-0250               Home Office
386-451-7607               Florida Cell
440-725-4025               Ohio Cell

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,
=20
I had a chance to test a connection to INHIB and INHALM at V7.1 in AIN
block.  (FoxSelect displays used for the test)
=20
When connected, I could not toggle  UNINH_ALL  if the connected bit was
TRUE.  I could not toggle the individual alarms marked "INHIBITED".
=20
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.=20
=20
So the rule as I know it remains true that you cannot write to a
connected variable regardless of the value of the source.
=20
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).
=20
Terry
________________________________

De: foxboro-bounce@xxxxxxxxxxxxx de la part de Doucet, Terrence
Date: mar. 2007-06-26 14:54
=C0: 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" =3D
report of Inhibited Alarms is printed and Operators are instructed to =
=3D
verify that each inhibited alarm is actually supposed to be inhibited =
=3D
and not merely left in the inhibited state by error (or ommission). The
=3D shift log must state that the work (Inhibit check) was performed and =
=3D
Operators are held accountable for this.

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

Terry

-----Message d'origine-----
De : foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
=3D De la part de Joseph M. Riccardi
Envoy=3DE9 : June 26, 2007 2:41 PM
=3DC0 : 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 =3D
during our experimentation it was discovered that hard-coding the 2 =3D
inhibit parameters (INHIB & INHALM) only secured the parameter if the
value(s) were high (1); it did not prevent the operator from over-riding
=3D the value(s) set to 0.  I was just shocked and trying to get an =3D
explanation as I always thought hard-coding "any" parameter value =3D
"always" secured the parameter no matter what the value.  Unless I =3D
missed it, no one has explained the reason and if maybe other parameters
=3D have similar traits.  However...

The real issue is that we have planned to secure specific blocks to =3D
prevent the operators from inhibiting (1) critical alarms by hard-coding
=3D 0s in the INHIB and/or INHALM (Hex) parameters (C:B.INHIB.0, =3D
C:B.INHALM.0x0003, etc.).  Unless I am missing something, we need to =3D
change to Plan B and will have to connect these parameters to dummy =3D
blocks; one for each combination of inhibits.  Plan A was much =3D
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
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
=3D 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
the AIN High/Low Option (HLOP) then you have=3D20 =3D20 0 =3D3D No =
alarming
1 =3D3D High and Low absolure
2 =3D3D High Abs only
3 =3D3D Low abs only
=3D20
So if you only want low alarming then configure a 3 in this parameter =
=3D
and you never need to worry about high alarms.
=3D20
Once you have your alarm configured then you should connect the .INHSTA
=3D parameter to the INPUTS parameter of a MCIN (no IO) block. Then you
can =3D use the AIN default display - ALARMS - overlay to toggle the
inhibits =3D that you desire. Now go to the default display for the MCIN
and you can =3D view the hex pattern  in the INPUTS:  box. For example =
if
you inhibit =3D the High and Low Absolute alarms your will see 00030000
displayed.
=3D20
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
write this hex value.
=3D20
Toggling the  AIN.INHIB to a TRUE will inhibit all the configured alarms
=3D in your block.  Setting AIN.INHIB to a FALSE will release the AIN
block =3D to inhibit only those specified by the hex pattern of the
INHALM.
Obviously, with INHIB =3D3D FLASE and INHALM =3D3D 0 all configured =
alarm =3D
annunciation is enabled.
=3D20
Terry
-- 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
=3D Systems (formerly The Foxboro Company). Use the info you obtain here
at =3D your own risks. Read
http://www.thecassandraproject.org/disclaimer.html
=3D20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
to unsubscribe:      =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
=3D20

=3D20
=3D20
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
=3D Systems (formerly The Foxboro Company). Use the info you obtain here
at =3D your own risks. Read
http://www.thecassandraproject.org/disclaimer.html
=3D20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
to unsubscribe:      =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
=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

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




-- 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

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