Re: [foxboro] Bad I/O vs. high/low alarming
- From: "Ali Ahmed Zahidi" <alizahidi@xxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Mon, 12 Jun 2006 22:58:41 +0500
If you set BADOPT=3 it means you want to get an I/O BAD alarm when a HIGH or
LOW Out of Range Alarm is raised.
This is normally used if you think that it is not distinguishable when
input signal is out of range and when it is BAD.
However, you can set the BADOPT option to a suitable value as per your
desired BAD alarm strategy.
LASTGV is default to 1 because it holds the last good value of the input
signal when it goes to BAD. This setting is very useful because it prevents
the control loop from being disturbed.
If you are using input types other than FoxCom the individual input signal
BAD will not be registered in SMDH. In this case the individual I/O failure
will not cause an FBM failure alarm.
Rgds,
Ali Ahmed Zahidi
Pakistan Refinery Ltd.
Karachi, Pakistan.
----- Original Message -----
From: "Corey R Clingo" <corey.clingo@xxxxxxxx>
To: <foxboro@xxxxxxxxxxxxx>
Sent: Monday, June 12, 2006 7:16 PM
Subject: [foxboro] Bad I/O vs. high/low alarming
> Hi list,
>
> We are undertaking an "alarm management" (well, at this stage, alarm
> elimination) project in one of my plants. The question of why we need bad
> I/O (BAO) alarming when we have high and low alarms on an AIN block was
> raised. Most of our bad I/O alarms are due to sensor/transmitter
> failures, which typically either open the loop or drive the signal high,
> so it is a valid question.
>
>
> So I was trying to think of a situation where one might get a bad I/O
> alarm but not a high or low when both high and low are enabled. We set
> LASTGV = 0 as a rule (why it defaults to 1 is beyond me), and card
> failures would show up in system management. Any other scenarios I might
> have overlooked? What is the general feeling on this topic?
>
>
> Thanks,
>
> Corey Clingo
> BASF Corporation
>
>
>
> _______________________________________________________________________
> 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
>
>
_______________________________________________________________________
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
- References:
- [foxboro] Bad I/O vs. high/low alarming
- From: Corey R Clingo
Other related posts:
- » Re: [foxboro] Bad I/O vs. high/low alarming
- » Re: [foxboro] Bad I/O vs. high/low alarming
- [foxboro] Bad I/O vs. high/low alarming
- From: Corey R Clingo