[foxboro] RES: alarm inhibiting vs. alarm disabling - process summary reporter
- From: "Ricardo Abech" <abech@xxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Tue, 2 Jan 2007 15:43:45 -0200
Dear Corey,
The only feasible solution I see without making use of SEQ blocks is using
an external program to do it (I had the same issues of CP loading with SEQ
blocks). I implemented something similar in my old company using an external
program and worked fine. The application is based on:
- CALC blocks to detect the abnormal situations (the number of CALC block
will depend on the number of abnormal situations you want to deal with). I
used BO01 to BO08 where FALSE means NORMAL and TRUE means ABNORMAL.
- 1 IND block for WATCHDOG (if for some reason the program stops running
then the IND block runs to return all original block groups). This will be
used just in case of program failure (AW freezing or rebooting is a good
example of a problem that can happen).
- 1 CSV file containing 4 columns for each CBP that will have the group
changed:
1st column - CBP of condition (the CALC block output)
2nd column - CBP of the BLOCK that will have its GROUP changed
3rd column - Normal Group Number
4th column - Abnormal Group Number
Ex .csv file:
COMPOUND:CALC1.BO01,COMPOUND:AIN1.BAG,1,2
COMPOUND:CALC1.BO02,COMPOUND:AIN2.BAG,1,2
COMPOUND:CALC1.BO03,COMPOUND:AIN3.BAG,1,2
The external program runs on AW and reads the CALC outputs, compare with the
*.csv file and write the results back to DCS. I ran the program each 1
minute. If for some reason the program stops then the IND block will be
flagged and all Groups will be returned to ORIGINAL state.
To exchange the information with the DCS I used the legacy tools (omsetimp,
omgetimp) but OPC worked fine too (when I developed the application we only
had Unix stations).
You can use the same idea to change bitmasks values in station blocks or the
GR* parameters in compounds.
I understand that this is not the optimal solution and have some flaws, but
still better that having alarm flooding on every Plant upset.
Hope this help,
Regards,
Ricardo P. Abech
Chief Software Architect
LimeWare Company, Inc.
[phone]: +55 51 3251 4662
[mobile]: +55 51 8192 9723
[email]: abech@xxxxxxxxxxxxxxxxxxx
[http://]: www.limewarecompany.com
-----Mensagem original-----
De: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] Em
nome de Corey R Clingo
Enviada em: Tuesday, January 02, 2007 2:08 PM
Para: foxboro@xxxxxxxxxxxxx
Assunto: Re: [foxboro] alarm inhibiting vs. alarm disabling - process
summary reporter
Are the STATION.GR* parameters connectable? The documentation is mum on=20
the topic. In fact, it only mentions these parameters once in passing=20
when describing the configuration overlay.
I can use sequence to set the *GP parameters too, I imagine. They are=20
settable, but not connectable (which also causes me problems with access=20
control). What I want is to be able to lock them down with loopback=20
connections, or use CALC* blocks to drive them. I avoid sequence where=20
possible, primarily because of the load it puts on the CP (at least in the =
couple of sequence programs I have written).
Corey Clingo
BASF Corporation
Sascha Wildner <swildner@xxxxxxxxxx>=20
Sent by: foxboro-bounce@xxxxxxxxxxxxx
01/02/2007 06:21 AM
Please respond to
foxboro@xxxxxxxxxxxxx
To
foxboro@xxxxxxxxxxxxx
cc
Subject
Re: [foxboro] alarm inhibiting vs. alarm disabling - process summary=20
reporter
Corey R Clingo wrote:
> So let's take a poll: who would like to see connectable alarm=20
destination
> group (*GP) parameters?
If you use alarm groups 4-8 (configured in the station block) you can
set the masks with a sequence on the fly.
Not quite what you want but as Alex already pointed out...etc etc.
Regards,
--
Sascha Wildner
erpicon Software Development GmbH
Neusser Str. 724-726
50737 K=F6ln
Germany
Phone: +49 221 9746089
Fax: +49 221 9746099
eMail: swildner@xxxxxxxxxx
_______________________________________________________________________
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 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:
- » [foxboro] RES: alarm inhibiting vs. alarm disabling - process summary reporter
