Is there any way to log alarms to a SQL database?

[Davidd]

Using Lookout 5.1, I have an application where it would be useful for Historical purposes to log alarm messages (generation, acknowledgement, completion) to an SQL database.  It is desired to run a 3rd party application in order to compute response times, and determine historical trends that might be discernable from the frequency of particular alarms (equpment out of calibration, equipment needing replacement, etc...).

Is there any way to acquire information on alarms, their generation and completion?

David Dudley

[Richard P.]

Here is information current to Lookout 6.0, found in Appendix B of the Developer Manual. There is also an SQLExec driver object which can execute commands in SQL.

"The Citadel historical database includes an ODBC driver, which enables
other applications to directly retrieve data from a Citadel database using
SQL queries.
The Citadel 5 ODBC driver is compliant with SQL 92 and ODBC 2.5
standards. All clients that follow these standards can retrieve data from a
Citadel 5 database. ADO clients can now use the ODBC driver through the
Microsoft OLE DB Provider for ODBC Drivers to access the Citadel 5
database. MS Query wizard can be used to build-up queries."

You can configure various data members of the $Alarms object to be logged.

[Davidd]

I was hoping to be able to do something similar to that (however I need to use SQLExec statements to write the Historical and Alarm information to a reliable secure SQL system.  We've never been able to get Citadel to work for over around 2 to 3 weeks without crashing.).

Problem is, when I open the object view to link information for the $Alarms object, there aren't any data items displayed.

David Dudley

[Richard P.]

Hi David,

Are there any erors logged by Citadel that might point the cause of the crash?

Also, can you elaborate on the specific object you are linking alarm data to?

Thanks

[Davidd]

To be honest, we don't use Citadel for Historical information storage any more.  We have tried for the past 3 years (starting with version 5.0) to get the Citadel system to operate reliably, but have had database corruption problems and Citadel crashes almost consistently once every couple of weeks.  We have had considerable problems with the MoscadModbus driver also, but those problems finally appear to have been resolved.

We currently spool every data item acquired from the PLCs to a MySQL database  running on a Linux server through SQLExec blocks, which we have refined to the point that it works reliably and has never failed for the past couple of years, and at this point, are not interested in going back.

Citadel is used to store the previous 30 days of data for hypertrend displays on the SCADA system, but any historical information before that is done through the database server.

There have never been any identifiable or repeatable errors from Citadel that would point to a specific problem.

I'm currently going to work on setting up a pilot system to allow me to do testing for spooling the alarms, which I may have inadvertently found a reason I was having problems before.

David

[Khalid]

As a side note, Citadel 5 (Lookout 6.0 and greater??) logs alarms to SQL -- MSDE to be more precise.  I haven't played much with it to see the format, etc., but it might just be easier to retrieve the alarms from there.  Just a thought.. and as I said this is as of Citadel 5 and above only.

-Khalid

[Davidd]

After all the reliability and integration headaches we've had with Lookout 5.0, it was an uphill battle just to get those above me to upgrade to 5.1.  I'm not about to start that mess again, in order to upgrade to 6.0, and in addition, if I went to them and said "It'd be nice to do .... to Lookout, and it will only cost us $$$ in order to do ....", I think I'd be kicked out of their office before I finished the sentence.

We've finally got Lookout 5.1 into a condition where it works reliably *most* of the time.  I'm not about to start another upgrade path, unless it were to something else.  Lookout seems fine for "small" systems, which are worked on by a single user, but in this case, we've got over 5000 tags from some 60 PLC's we're handling, with around 2000 or so discrete alarms.  The system is maintained by me, and I do *some* development on it, but we also have 3 or 4 other people who also work on the *same* system, which in the current design, with a single lookout file, and no discrete process database system, makes it extremely difficult, since only one of the users can be working on the system at a time*, and they MUST do it on the production system, as you can't merge pieces from different developers into the single operating system.

Can Citadel 5 be added or merged into Lookout 5.1?

David

[Khalid]

I can feel your pain.  I agree:  upgrading to 6.0 wouldn't be an easy option for you. 

About more than one developer working on the system, is the entire system implemented as a single process file?  It may be a good idea to implement it as a group of multiple process files, especially since you have large number of tags -- one (or a couple) just to access the IO, and the rest as a client processes.

Regards,

-Khalid

[Richard P.]

David,

Do you have the latest version of Logos installed? 4.5.1 is available here:
ftp://ftp.ni.com/support/logos/

Although the errors which cause Citadel to fail are not consistent, can you post a few of them anyway, in case they do provide some insight to us as to the root of the problem?

I'm sorry to hear that upgrading has caused frustration. We work hard to improve our software with each release and try to cover as many test scenarios as we can. I hope we can make some headway into these Citadel errors and improve your experience with the software.