Re: [foxboro] FW: Alarm Capture
- From: "Pan, Jim" <Jim.Pan@xxxxxxxxxxx>
- To: "'foxboro@xxxxxxxxxxxxx'" <foxboro@xxxxxxxxxxxxx>
- Date: Mon, 22 Mar 2004 13:48:30 -0500
PlantState Suite software supports all versions of Historians, including:
* legacy Historian
* FoxHistory
* AIM*Historian
* FoxAMI
There is a requirement of 2nd Ethernet connection. The ODBC driver or OPC
server is not required for collecting messages from legacy Historian.
If your goal is to view alarm history in real-time mode then the
printer-port alarm capturing products should suite your need. If your goal
is to analyze the alarms (optionally for alarm optimization) then you should
focus on alarm historization and event analyses capabilities, not the
real-time displays.
Jim Pan
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of gop@xxxxxxxx
Sent: Monday, March 22, 2004 12:10 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] FW: Alarm Capture
All such programs capturing alarms from the Alarm History through the
TCP/IP port require AIM*AT packages in the I/A side (ODBC,OPC server).
We are still using Legacy Historian and interfacing this with the
external world is not easy . By capturing from the printer port, the
alarms could be displayed in real-time mode , whereas reading from the
Alarm History could not give a real-time display. The only bottleneck
is sending the Alarm priorities to the printer , without the need for
reconfiguring the priorities again in the capture program.
Thanks & Regards,
GOPS
Aramco Mobil Refinery
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Sieling, Marcel
Sent: Monday, March 22, 2004 2:03 PM
To: 'foxboro@xxxxxxxxxxxxx'
Subject: [foxboro] Alarm Capture
Hi list,
GOPS wrote:
>Is there a way to customize the format in which the alarm=20
>printers print ? Can we include the alarm priority as well in the =
printout
?=20
>How does the printer recognize 1st priority alarms =20
>and print them in a different color ? If this is a printer=20
>command, could we extract this information from the=20
>COM ports ?=20
We investigated this problem because one of our big customers here=20
in Germany had the same requests. They even stronger wanted to=20
collect all alarm messages from their 22 I/A-Systems in one central=20
database and examine them there with a commercial tool.
We offered them a combined solution using the state of the art=20
Solution "PlantStateSuite" from PAS (http://www.pas.com) to=20
rationalize, analyze and report all kinds of statistical analisys =
reports=20
based on any kind of message data (Alarms and Operator Action)=20
and a software package we will develop here in germany which=20
provides an OLE-DB interface from the I/A Alarm Manager directly=20
to an SQL server via a network link. The Alarm Messages are=20
transferred in a structured manner, so no need to parse byte=20
streams. All information available in the alarm system is transferred=20
with this solution. In that interface the following information will be =
transferred directly from the Alarm Messager without COMM=20
processors and their serial interfaces and the parsing of string data.=20
The data structure is as follows:
typedef struct ALARM_NEW_MSG
{
short messg_type;
char date_time[DATE_TIME_LENGTH];
char letterbug[LETTERBUG_LENGTH];
char compound_name[COMPOUND_NAME_LENGTH];
char block_name[BLOCK_NAME_LENGTH];
char point_name[POINT_NAME_LENGTH];
char alarm_type_msg[ALARM_TYPE_MSG_LENGTH];
short pnt_no;=20
short sct_no;=20
short opr_err;=20
char parameter_name[PARAMETER_NAME_LENGTH];
char tenths; =20
char inhprt; =20
char id_length; =20
char dummy[DUMMY_LENGTH];=20
char ack_state;=20
short monotonic_time;=20
short valid_time;=20
short priority;=20
short stepno;=20
char subrno;
char sbxno;=20
float alarm_limit;=20
float real_value;=20
short block_dscrp_length;=20
short msg__text_length;=20
short in_out_length;=20
short units_length;=20
short state_text_length; =20
char text_buffer[LENGTH_LEFT];
} ALARM_NEW_MSG;
The software is not ready yet and will be produced and sold as a=20
commercial product if customers are interested. We expect it to be
Ready in a few weeks in case there is a request.
In case you need more information or in case you are interested feel=20
free to contact me directly, I'd be glad to answer any questions, if I =
can.
Best regards -
Marcel Sieling
Systems Technologies
Invensys Systems GmbH
Heerdter Lohweg 53 - 55
40549 Duesseldorf
Germany
Tel.: +49-211-5966-171
Fax: +49-172-50-2673077
Mobile: +49-172-2673077
Email: mailto:msieling@xxxxxxxxxxx=20
Homepage: http://www.invensys-process-systems.de=20
Visit my private homepage: http://www.powerslider.de
>-----Urspr=FCngliche Nachricht-----
>Von: foxboro-bounce@xxxxxxxxxxxxx=20
>[mailto:foxboro-bounce@xxxxxxxxxxxxx] Im Auftrag von gop@xxxxxxxx
>Gesendet: Samstag, 20. M=E4rz 2004 11:25
>An: foxboro@xxxxxxxxxxxxx
>Betreff: [foxboro] Alarm Capture
>=20
>=20
>=20
>Is there a user option to configure the alarm printouts in Fox I/A ? =
>=20
>The alarm printing format is embedded somewhere in the base=20
>software .=20
>=20
>We have tested various alarm capture packages to convert the=20
>alarm text dump to useful data,=20
>=20
>but so far we could not come up with a perfect solution .=20
>There are ways to extract the alarms=20
>=20
>from the Alarm History using AIM*AT packages , but this is=20
>not good replacement for the=20
>=20
>real-time alarm printers . At the same time , alarms captured=20
>from a printer port does not=20
>=20
>contain alarm priority , which is an important information=20
>for analysis.=20
>=20
>Is there a way to customize the format in which the alarm=20
>printers print ? Can we include=20
>=20
>the alarm priority as well in the printout ? How does the=20
>printer recognize 1st priority alarms=20
>=20
>and print them in a different color ? If this is a printer=20
>command, could we extract this=20
>=20
>information from the COM ports ?=20
>=20
>________________=20
>=20
>Thanks &Regards,=20
>=20
>GOPS=20
>=20
>Aramco Mobil Refinery=20
>=20
>=20
>______________________________________________________________
>_________
>This mailing list is neither sponsored nor endorsed by=20
>Invensys Process Systems (formerly The Foxboro Company). Use=20
>the info you obtain here at your own risks. Read=20
>http://www.thecassandraproject.org/disclaimer.html
>=20
>foxboro=20
>mailing list: http://www.freelists.org/list/foxboro
>to subscribe: =20
>mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
>to=20
>unsubscribe: =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
>=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
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
_______________________________________________________________________
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: