LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Accessing DataSets in Citadel Database is Slow

Hello:

I am currently using the Labview DSC Module to log data to a Citadel Database. I log data by DataSet and trigger the DSC Engine to Log Data only when necessary. The DSC Engine is logging data to a DataSet from 2 Allen Bradley PLC's using RSLinx as an OPC server. This may occur several times during the day depending on the conditions in the PLC (I have a small VI written to trigger DataLogging when the PLC turns on a certain bit).

Later in the process I am retrieving this data from the Citadel Database using Diadem's Data Navigator functions. Occassionally, I receive channels into Diadem that have a Timestamp but for data I have 'No Value'. When this occurs it usually takes Diadem 5-10 minutes to load this data
(approximately 208 data channels and 208 timestamp channels with 200 - 500 values apiece). When this does not occur, Diadem loads the data in approximately 30 seconds.

Do these 'No Value' data points mean my Citadel database is corrupted? How can I solve this problem if so?
0 Kudos
Message 1 of 4
(3,399 Views)

When you say "...to Log Data only when necessary... " I assume you are using Set Tag Attribute.vi to establish this behavior.

National Instruments recently added a feature (as a hot-fix) to the DSC Engine to be able to ignore timestamps coming from servers to prevent to log values with "back-in-time" timestamps. Citadel is really critical taking values back in time (logs a ) and therefore retrieval of Citadel data with such back-in-time traces could act wired.

You can find more info from:
Why Do I See a Lot of NaN (Not-a-Number) In My Citadel Database When I Use the Set Tag Attribute.vi? 

How Do I Avoid Out-of-Synch (a.k.a. Back-In-Time) Timestamps in the Citadel Database? 


The Hot-Fix can be found:
LabVIEW Datalogging and Supervisory Control Module Version 6.1 for Windows 2000/95/98/ME/NT/XP -- Fixes 


I assume you run into such a use case - maybe. It happen to me, too :). And I've created a small VI which would analyze traces on back-in-time (NaN - Not a number) values. I assume the missing Data in DIAdem are those Not-a-Numbers aka Break.

If you still encounter some problems after applying the DSCEngine.ini UseServerTimestamps=false, you might contact a National Instruments Support Engineer.

Hope this helps
Roland

0 Kudos
Message 2 of 4
(3,399 Views)
I ran your backintimeanalyzer.llb file on my active CITADEL logging directory. It ended with a value of 14 in the "#NaN w/o BiT = Engine Stop" indicator." If these are bad datapoints, could your vi be modified to remove these points from the citadel database?? I also noticed that some of the vi's when loading referenced the LVDSC7 examples directory. Any chance you could "leak" some info on future enhancements??? I don't do anything with modifying tag attributes in my vi's. I do however have my deadband set to 0 and I noticed one of the above links said not to set it to zero.
0 Kudos
Message 3 of 4
(3,399 Views)

Your database looks good, though. DSC logs a break whenever you shut down the engine. That's the reason you have NaN in your database... Those points are expected and have to be there to draw the trace in a LabVIEW graph. In the underneath streaming database (Citadel) is a special value logged () to indicate such a trace break. You can see it when you query through ODBC there is a "NULL" data value.

There is no "leaking" possible. The only way you can get info about National Instruments Beta Program is through either NI's sales channel or through National Instruments Beta Program Web Site

Hope this helps
Roland

0 Kudos
Message 4 of 4
(3,399 Views)