Accessing non-logged data through ODBC

[Davidd]

Running Lookout 5.1

Actually, I already know the answer to this question, but it doesn't hurt to ask, as there might be a 'hidden' way to do this.

I need to acquire real-time process data from our application (on 30 second to 1 minute intervals).  Is there a way I can acquire data using the ODBC access for items that are NOT archived in Citadel.  Some items in the system change a lot, but I only need data for items spaced in groups once an hour, and don't want to burden Lookout any more to the point where it's having to log 5000 data points just so I can get a value at a specific time.  Also, is there any way I can acquire data directly from the process?  I have some computed values that are not archived, and that don't come from a remote unit, which I need to grab data from.

David Dudley

[Bassett_Hound]

Hi David,

You should be able to access items in other Databases using the SQLExec Object.  For the second question, I'm not sure exactly what you mean by acquiring directly from the Process.  You should be able to use an expression to compute a value and then read that value when needed.  If you are needing to be able to read previous computations you may have to log the data.

Hope that helps.

Regards,

Steven B.

[Davidd]

Oops, I wasn't clear enough, I guess....

What I need to do is to read information out of Lookout from another application.  Management wants to acquire some information for use in their CMMS system that is generated by Lookout.  I need to acquire information FROM Lookout to go into the City's billing and management process.  This process runs on another computer system entirely - in fact, it runs on our UNIX system - but I can acqure ODBC data through a set of tricks I have that accesses the ODBC data through a normal SQL interface.  Problem is, some of the data I need to acquire is generated through computations internally by Lookout, and is not logged or written to an I/O device.  Thinking maybe I can create a dummy MODBUS slave device that doesn't ever get accessed by an outside unit, just so I can get the stuff into ODBC, but that seems like a 'hack' to me.

David Dudley

[Khalid]

David,

Would the 'Spreadsheet' object work?  You can use this to log data at a very slow rate to CSV files.  The generated files can additionally be moved to the other computer using the 'Run' object and some DOS commands. 

Regards,

-Khalid

[Davidd]

The spreadsheet object is a possible option I have been looking at.  Problem is, the data they want to access changes based on their "mood", so I don't always have available access to what they want, at the time they want it, if I generate the access from Lookout.

If I generate an ODBC connection to 'everything', I'm just going to tell them "this is how you get data, now go get whatever you want", and that reduces work for me.

Still, it's a good idea.

David

[Khalid]

Hi David,

As you're aware, ODBC needs the data to be in some kind of a database.  So, that's pretty much ruled out (since you do not want to log all the data all the time). 

In which case, OPC might be a better option.  OPC is for real-time data -- the data doesn't have to be logged.  Lookout is an OPC Server by default.  Everything in Lookout is exposed as OPC items.  A simple OPC Client can be used to lookup the items of interest -- on the fly.  The main problem is:  OPC is very Windows specific (at least as of now).  So, to get this to work on Unix you will need some bridge app.  Something like the following:

http://www.opcdatahub.com/Features/OPC_to_Linux.html

Hope this gives you more ideas.

-Khalid

PS:  I must add that remote OPC is a real pain -- all the DCOM settings and user privileges, etc., etc., aaargh!  I can't believe I am now suggesting doing this across platforms!

[Davidd]

OPC looks very interesting.  I'll have to give that some serious looking into.  If I can setup access from the external app through this, that solves the problem of "providing access".  If it's difficult to setup and use - thats not my problem, I pushed it off on someone else (who'll probably end up hating me for it...).

They're talking now about ripping Lookout out of our system again, and putting in a "real DCS" type system - I think they're looking at Honeywell Experion.  That'll put me back at the starting point, but it's just more job security for me.

David

[Davidd]

You know, every now and then, it'd be nice if SOMETHING in this @#$@@#@ Lookout system worked right the FIRST time.

Trying to setup OPC to work is a pain in the ass for Lookout, but seems to work fine for other things righ off.....

Lets see, I start Server Explorer on any machine on our SCADA network.  Doesn't matter if it is the Server or one of the Clients, or just my test machine sitting on my desk.

I can access definitions for all the servers, with the exception of Lookout.  Its empty.  So far, so good.  Connect to the server, run the Wizard, things are fine till it gets to the point where it's building the point list, then things get busy for 30 seconds or so, then the program just "disappears".  Exits without even saying "goodbye".  Whats with that - except for STUPID?

Needless to say, I'm not amused.

David Dudley

[Bassett_Hound]

David,

Which Version of the Server Explorer are you using?  I was able to connect to several Lookout objects using Server Explorer version 2.4.1.

Regards,

Steven B.

[Davidd]

I'm using version 2.4.1, and Lookout 5.1.

Problem is, I can MANUALLY go through the server explorer and setup one or two tags to display in the explorer.  Using the Wizard, when I try to automatically generate a group of all items (which is what I want), the thing crashes.

My database has around 5000 I/O points in it, and probably in the range of around 10k-15k actual items.  Management wants a continuous record of ALL tag values, not just those that have I/O, but also computed values, saved values, triggers, alarms, etc.  I can't do it with ODBC since NI didn't see fit to give the capability of reading non-logged items through ODBC.  That means I have to use some kind of actual OPC client to read the items, since that appears to be the only way to get to anything that is NOT logged by Citadel.

The only way OPC is going to be practical, however, is if I can generate the data group in some kind of automated mode, and so far, that ain't happening through Lookout.

Works great with my AB, Modicon, and Siemens 505 PLCs however.  Even if Lookout fails on this, I'm going to use it for those.

David Dudley