Re: [foxboro] IOBAD
- From: "Jones, Charles R. (Chuck)" <CRJones@xxxxxxxx>
- To: "'foxboro@xxxxxxxxxxxxx'" <foxboro@xxxxxxxxxxxxx>
- Date: Tue, 7 Oct 2003 15:37:08 -0500
Tim,
I admit it's been a long time since I dealt with this problem and I'm going
from memory. I also did not try to split hairs on these alarms as fine as
you are. But, if you're looking for something to try...
You didn't mention the size of your OSV (off span variance?) parameters. I
increased my OSV parameters from 2.0% to around 10.0% (they vary). I
believe that the OSV allows the incoming readings to vary that much outside
of the declared span before determining the transmitter to be bad. I found
out from the instrument techs what the average variance is in their field
transmitters, then I set the OSV for a little bit more than that.
Chuck Jones
Refinery Automation Technologist
Tate & Lyle North America -- Lafayette South Plant
765.477.5324 - Office | 877.536.9219 - Pager
-----Original Message-----
From: Lowell, Tim: [mailto:Tim.C.Lowell@xxxxxxxxxxxxxxxxxx]
Sent: Tuesday, October 07, 2003 2:51 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] IOBAD
List,
We are going through an alarm rationalization process using the EEMUA =
standards, and the one aspect of the Foxboro DCS alarm system that we =
are having the most trouble dealing with is IOBAD for AIN blocks. =20
We get a lot of nuisance IOBAD alarms during upsets that are not really =
indicative of hardware failures. They are really Out of Range =
conditions. The transmitter and FBM are working fine, but the signal is =
either below or above the configured range. We have BADOPT set to 3, =
the default, which means Out of Range High or Low or Bad FBM =3D BAD. =
What we need is to be able to differentiate from an Out of Range =
condition and an actual transmitter failure, meaning the wire is cut or =
the transmitter loses power, i.e. no signal. When we get an Out of =
Range condition, we want to get only an Out of-Range Alarm, set the BAD =
bit which in turn puts any connected PIDA in HOLD or Manual, and not get =
an IOBAD alarm. When the transmitter actually fails, we want the BAD =
bit to be set which puts any connected PIDA in HOLD or Manual and to get =
only an IOBAD alarm. Unfortunately, BAD and Out Of Range seem to be =
inextricably linked in the I/A. Using the BADOPT parameter, it doesn't =
look like you can configure the system to set the BAD bit during an Out =
Of Range condition without also triggering an IOBAD alarm. Am I =
interpreting this correctly or am I missing something?
Has anybody else on the list gone through the EEMUA alarm =
rationalization process? What do you do with IOBAD alarms?
Tim Lowell
Control Systems Engineer
ConocoPhillips, Trainer Refinery
Phone: 610-364-8362
Fax: 610-364-8211
Tim.C.Lowell@xxxxxxxxxxxxxxxxxx
_______________________________________________________________________
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
*****************************************************************************************************
This email and any files transmitted with it are confidential and intended
solely for the
use of the individual or entity to whom they are addressed. If you are not the
intended
recipient or the person responsible for delivering the email to the intended
recipient, be
advised that you have received this email in error that any use, dissemination,
forwarding, printing, or copying of this email is strictly prohibited. If you
have received
this email in error please notify the sender immediately.
Please note that we reserve the right to monitor and read any emails sent and
received by the Company in accordance with and to the extent permitted by
applicable legal rules.
*****************************************************************************************************
_______________________________________________________________________
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:
