Re: [foxboro] Compound Device/Alarm Groups
- From: "foxpat" <foxpat@xxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Tue, 17 Jun 2008 20:35:18 +0200
We typically do not use the alarms from the alarm generating source blocks
(like AIN, CIN, ACCUM etc) to be send to stations/alarm manager but always
connect the required alarm indicators of these blocks to additional PATALM
blocks.
This offers tremendous flexibility at the cost of (a significant amount of)
'extra' blocks.
An empty alarm group is essential!
Example:
An AIN block FI1010 with high and low absolute alarming.
HLGP = 8 (group 8 is empty)
2 additional PATALM blocks FAL1010 and FAH1010, FAL1010.IN_1 linked to
FI1010.LAI, FAH1010.IN_1 linked to FI1010.HAI, PAT_n and MSK_n configured as
desired.
SAG = 4 (group 4 has the required stations configured)
These PATALM blocks now allow you to connect (or omset if you would prefer
that) up to 15 additional (calculated) status signals which can be used for
'masking' the actual alarm.
IN_2 could be linked, for example, to a logic block which would
automatically mask the alarm after, say 10 minutes after a pump stop.
The FoxView display elements are configured to indicate a 'masking' state by
means of a predefined color.
The operator can only manipulate the INHIB of the PATALM which gives a 100%
clean OAJ and allows for a 100% clean standing INHIBITS report (we use
getpars and some scripting to generate FoxView substitution lists so the
inhibs report is actually a FoxView display. It contains info like descrp,
actual status etc.)
Operations does NOT have access to any standard I/A detail displays so there
is no way they can 'accidentally' set alarm groups or things of that kind.
Some additional advantages:
If you send the alarms generated by the 'alarm generating source blocks'
only to a printer (a data collecting PC like imac) and/or historian group,
you will always be able to see if these alarms would have been activated
even if the operator has inhibited the PATALM(s).
You can use the source block alarm indicators for interlocking purposes,
independent of operator inhib.
All alarms are generated by PATALM blocks, which makes it easy to create
overviews of the alarms actually configured.
In conjunction with CAD alarm filtering, linking of the CINHIB, linking of
the priority of the PATALM (and optionally retrigger the PATALM by pulsing
for example IN_3 for 2 sec. after you change the priority) you can do some
pretty nice things!
Personally I'm not very fond of applications or sequence blocks which use
omset. I prefer the linked approach where ever possible. For example: all
our compound CINHIB parms are linked (on a per process unit base) which
allows us to suppress all priority 4 & 5 alarms instantaneously! (ok, you do
get a flood when re-enabled but it's up to the operator to do this whenever
things have settled out)
Kind regards,
Pat
_______________________________________________________________________
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:
