Citadel Database

Hey
I am trying to learn how to use a Citadel database, but haven't found any good pages or books to help me with the basics. I am totaly green so need help to set up the database, log some data and read the data. I have made a little program with a Sinus signal that i want to try it on.
Any help will be appriciated
Johan

jonaskj wrote:
Hey I
am trying to learn how to use a Citadel database, but haven't found any
good pages or books to help me with the basics. I am totaly green so
need help to set up the database, log some data and read the data. I
have made a little program with a Sinus signal that i want to try it on. Any help will be appriciated Johan
Citadel
database itself is not meant to be used in LabVIEW directly. It is part
of older LabVIEW DSC versions and the only way to log values to the
Citadel database is by using the LabVIEW DSC VIs. The ODBC connector
for Citadel only provides query capabilities but no way of writing to
it.
However newer versions (>= 7.0) of LabVIEW DSC do use the Microsoft
SQL server for data logging, a decision I don't fully understand but
that is another story.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Similar Messages

How to import measurment data from a Excel File to Citadel DataBase?

A Microsoft Excel File is being created in a PC and I want to include that flie´s data into my citadel Database wich is in another PC.

I give a example "Importing Spreadsheet Data to the Citadel Database" in the LabVIEW Version 6.1 and LV-DSC 6.1.
LabVIEW 7.0 with LV-DSC you must in the ini file "DSCEngine.ini"
set NoShutdownLog=1 and UseServerTimestamps=TRUE.
kind regards
amcholger
Attachments:
Write_File_to_Citadel_Example.zip ‏139 KB
Write_File_to_Citadel_VI_Server.zip ‏289 KB

How to add an array of data in Citadel database

I have an array of data which I want to directly put it in the Citadel Database. Normally the write tag VI writes one value at a time. How can this be done ?

It depends on what you really want. Could you be a little more specific? Does each point have its own separate timestamp? If so, you could simply put the "Write Tag.VI" inside a FOR LOOP and insert values one after another. This would give a separate timestamp to each value. I have attached a simple VI that shows how to do this.
Or are you looking to record some type of vector, where you log a complete array of data at each interval? I don't think this is possible (I'm using DSC 6.02) unless the data-type is a bit-array, in which case you would simply use "Write Data (bit array).vi".
Another option, depending on what you are aiming for, would be to create your own "VI-based Device Server" and use the VIs on the palette submenu call
ed "DSC Server Development". With your own Device Driver you can write multiple datapoints to the input queue simultaneuosly. In this way, you can write more than one point at a time... but that doesn't mean that each time interval will contain an array of data. Assuming that the data is analog, the data will still be logged to Citadel "one after another" so that when you look at it with the HTV, you will see one curve of analog values.
Attachments:
Write_array_to_citadel.vi ‏17 KB

Write to Citadel database from LabVIEW?

Hi. I'm a newbie when it comes to Lookout and the Citadel database... so here's my question for you all:
We have various labview applications that log data from instruments. We would like to be able to take this data and store it as "tags" in a Citadel database.
What do you think is the best way to do this?
There are ODBC drivers for the Citadel database, but they appear to only allow you to query the database to retrieve values... you can't write data to the database (so its read-only).
Are they any "Lookout VIs" or Citadel VIs that can write to the Citadel DB from LabVIEW? Or a DLL or something?
Any ideas?
regards,
John Paul

Very nice question John Paul. I take it you already have Lookout and LabVIEW. In this case, with the latest versions of either, simply use the LabVIEW datasocket to publish the items on your front panel. Lookout then can subscribe to these once you register the LabVIEW computer. Once you have subscribed to them in Lookout, you are then able to set up logging. You may need to create an expression object to route the data to citadel.
If you just want to use LabVIEW and the Citadel database, you might try VI Logger. This works in our configuration utility - MAX, and also comes with a set of VIs for LabVIEW. One caveot, the Citadel database in VI logger is newer (and faster) than the Citadel database in Lookout. I believe NI is working to synchronize
the version in the future, and its hard to say when. So till then, you would not be able to merge data in the dislike citadel databases. However, you can always use and ODBC call set to extract from both and store in a more permanent SQL database such as access, oracle, ms back office, etc.
Good Luck,
Preston Johnson
Business Development Manager
Industrial Applications
National Instruments
Preston Johnson
Principal Sales Engineer
Condition Monitoring Systems
Vibration Analyst III - www.vibinst.org, www.mobiusinstitute.com
National Instruments
[email protected]
www.ni.com/mcm
www.ni.com/soundandvibration
www.ni.com/biganalogdata
512-683-5444

CITADEL DATABASE NOT CONFIGURED AS A RELATIONAL DATABASE

HI:
I have the same problem described by another member before, and I haven't found any resolution of this problem:
The problem was:
>I enabled database logging, and configured the shared variables that I wanted to log. Then I deployed the variables. When I try to read alarms and events (Alarm & Event Query.vi), I get this message:
>Error -1967386611 occurred at HIST_RunAlarmQueryCORE.vi,
Citadel: (Hex 0x8ABC100D) The given Citadel database is not currently
configured to log alarms to a relational database.
Please help me with this topic
Thanks in advance

I'm configuring the variables to be logged in the same way that appears on the file you send, but it doesn't work... I don't know what else to do.
I'm sending you the configuration image file, the error message image and a simple vi that creates the database; after, values are logged; I generate several values for the variable, values that are above the HI limit of the acceptance value (previously configured) so alarms are generated. When I push the button STOP, the system stops logging values to the database and performs a query to the alarms database, and the corresponding error is generated... (file attached)
The result: With the aid of MAXThe data is logged correctly on the DATA database (I can view the trace), but the alarm generated is not logged on the alarms database created programatically...
The same vi is used but creating another database manually with the aid of MAX and configuring the library to log the alarms to that database.... same result
I try this sabe conditions on three different PCs with the same result, and I try to reinstall LabVIEW (development and DSC) completelly (uff!) and still doesn't work... ¿what else can I do?
I'd appreciate very much your help.
Ignacio
Attachments:
error.jpg ‏56 KB
test_db.vi ‏38 KB
config.jpg ‏150 KB

Latency in accessing Citadel Database over the LAN

Hi!
I have two systems running LabVIEW 2013 with DSC 2013 and I am using one of the systems to acquire (using shared variables) and log data internally in the citadel database. I have made an application to visualize this data either locally on the same PC or over the LAN. When I am using the application on the same local machine which is logging the data, its all working fine and very fast. But when I access the same database over the LAN, the application takes a finite amount of time (anything between 2-18 secs everytime) to retrieve and show the data. Since the database size is very small (less than 5MB), logging rate is low (1Hz), number of traces are not much (14 traces), data is boolean, it should not take so much time to show the values over the LAN (the application should be as snappy as it is on the local PC). I am at my wits' end but I am not able to reduce this latency or find any logical reason for it to be present.
I specify the logging PC's name whenever I want to retrieve the trace (as shown in the attached picture), I have a feeling that if I replace that with the IP address of the system, things should become fast. But whenever I try this, LabVIEW throws up an error saying that the specified trace/database does not exist.
I am attaching a pic of the architecture and a simplified image of how I am retrieving the data from the database with this post.
Any help shall be deeply appreciated.
Attachments:
LAN Architecture.png ‏23 KB
Accessing database.png ‏14 KB

To enable external access without VPN, you must assign an external IP address and also map that external IP to the server. Additionally, you must open the associated ports (http) on the firewall (doesnt matter what firewall you use). You will have to map the extranal ip to the internal IP that you have set on the EBS server configuration. In some cases, you have to enable the proxy as well.

Archive citadel database in MAX hangs

I am trying to Archive a 4.13 GB uncompressed DSC database on LabVIEW 2013 SP1 (although the database was started with LabVIEW 2013). I have tried twice and it gets stuck (new location folder size is at 151 MB both times). The progress bar says "Archiving database=20.5%" and "Copying Data=83.0%". I have chosen the option "Destroy source data after it has been archived (local computer only)". The status says "copying data" and I no timestamps of files in the new folder have changed after about 9 hours of waiting. If I cancel, MAX cannot display any Citadel databases. This is fixed if i reboot.
Any ideas?

Hello barkeram,
Where are you storing the archive (locally or remote)?
Are you following the steps in one of the following documents?
http://digital.ni.com/public.nsf/allkb/E076A0661E03F1EB862571A800079E7B
http://digital.ni.com/public.nsf/allkb/2B0C74744BB37391862571F500067C64
Can you try to navigate to the file path of the database and duplicate the file? Afterward, manually add the new database to MAX and try to Archive the new file.
Regards,
Thomas C.
Applications Engineer
National Instruments

Options to edit historical data in Citadel database (Lookout 6.0)

We are running a new installation of Lookout 6.0
I am looking for ways to edit the historical data that is found in the Citadel database. For example, if an alarm clears before I can enter comments, I would like to go to the database after the fact and enter comments regarding the alarm.
We are running this on XP pro operating system.
Thanks,
Alan

Hi Alan,
I am afraid this will be difficult, if at all possible. Citadel data, by design, can be written to (and edited?) only by the product using it, i.e., Lookout, LabVIEW-DSC, etc. Outside of these products we can only retrieve the data -- not edit or add to it. As you are probably aware, some of the options for writing user data (as opposed to IO/system data) from within these products is to use the Logger Object in Lookout and the VI-Server approach in DSC (http://zone.ni.com/devzone/conceptd.nsf/webmain/5a921a403438390f86256b9700809a53).
So, I guess one option is to "annotate" / write additional data separately using the Logger Object, referencing the Alarms somehow.
Having said that, I believe Lookout 6.x (Citadel5) uses MSDE for storing Alarm data (other data is still stored in the native Citadel database). You could explore this -- try opening the MSDE database from Query Analyzer, from instance, and see if it can be edited. I haven't tried this.
Hope this gives you some ideas.
-Khalid

SQL queries from a Citadel database

We are retrieving data with third-party package SQL queries from a Citadel database. Certain queries for some object members will not return data, but the SQL search application software returns an "error". An analysis of the error from the SQL end does not find problem on SQL side. I suspect corruption of Citadel database. The link to database is good, as most tags do return a value as expected.
This problem occurred at the time of re-location of the database to a replacement computer. Any ideas on how to fix such a problem?

Can you give an example of the "bad" SQL statement and a good one?
Ryan Shi
National Instruments

Configuring Database for logging to citadel Database using shared variable engine

Hello All,
I have two systems with me here, one with LabVIEW 8.5 and one with LabVIEW 8.6, I'm using Shared Variables in my code and I am Logging to citadel Database. In a PC with LabVIEW 8.5, I am able to Log Data to citadel Database, but with the same code I am not able to Log Data from the PC with LabVIEW 8.6. Both the PC's have Database Installed and the connection with the Database Exists when I test connection with database through control panel. I would Like to know any configurations (in LabVIEW or in code or in Database or in PC) that have to be done for Logging to Database because the PC with LabVIEW 8.6 was added recently and the code was upgraded to 8.6.

It was due to a dll in LabVIEW, a dll named nitaglv.dll
Now I have a issue with Data Logging from the EXE, once the shared variables are deployed programatically from the EXE the Data Logging stops,
can I get any input on this issue..???

Recover Citadel Database from Corrupt Hard Drvie

Hey All,
I recently suffered a hard drive failure / corrupted hard drive. However, I was able to recover several Citadel 5 database files from the corrupted drive. For example, I have 16 GB of CDPG files that I was able to recover. I might be able to recover other file types too, if I knew what I needed.
Is there anyway to recover these data and put them back in Citadel? Anway to view the data at all?
Thanks in advance for any advice / help!
Mike

Hi,
The link bellow shows the extension files used by Citadel databases. If you can perform a search by the extension of the file (*.thd) you will be able to recover your files.
http://digital.ni.com/public.nsf/allkb/A9A702342A4E332C86257807006D3D5D
Regards,
MCOTO

How do you change values after logging data to the citadel database (DSC)?

How would one go about changing values that already exist in the citadel database. So say I were logging a numeric value with a timestamp for 1 year and then wanted to change a few values for the month of June because my sensor wasn't working at that time. How could I do this? Is it possible without re-creating the whole database over?
Thanks
Matt

mattyk wrote:
Hey Ben,
Thanks for the quick response. I called NI and asked about this because this would be a big show stopper for me. Their applications engineer said that the best way to change previous data would be to read in the trace that you want to change, modify it and save it as a new trace. I am also looking into SQL querying. I was able to connect to the citadel database by setting up a ODBC data source and using the database connectivity toolkit to query the database. This worked. Now I am trying to come up with a statement in SQL to change previously saved data. I'll Keep you posted.
Thanks
Matt
That reinforces my suspicions.
I have an app running for about 8 years now that keeps a paper trail to enusr ethe cartdiges used in respirators (operated NIOSH National Institute of Occupational Safety and Health par teh CDC) that use DSC to enusre nobody can ever falsify those records. If they can be hacked I my customer and anyone using a respirator with a NIOSH sticker on the side of it, want to know.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Citadel database to store constants?

can i use citadel database to store constants?
normally use citadel to store trends of any variable (and work fine), but if i need store a constant value, for example the result of a test (user name, erorr, etc...). i can do it using memory tags, but is a good practice? or maybe the best way to do is with other database and the connectivity toolset?
thanks for any answer!

I've used memory tags for stuff like this and I've also Flatten to String on clusters and saved this string to a file. Then read the file back into labview and use the Unflatten from String with a cluster constant to get the original data.

Logging large .ctl to citadel database is slow

Hi, All
I'm using LV 8.5 with DSC.
I'm logging my own.ctl types shared variables to citadel database. This own.ctl includes 52 piece doubles, strings and boolean datatypes. I have 200 piece this tape of shared variables and I record all that shared variable information to citadel database. All operations as writing, reading, achieving, and deleting database are very slow. They also consume lot CPU time. Is there any capacity limits on citadel database ? Which is best structure to record this kind of data to database? I have tested (see attacment) structure but it seems to be very slow because I have to delete and create database trace references after 1st database is full.
BR,
Attachments:
code_structure.jpg ‏51 KB

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?
blic.nsf/websearch/B871D05A1A4742FA86256C70006BBE00?OpenDocument>How Do I Avoid Out-of-Synch (a.k.a....
The Hot-Fix can be found:
LabVIEW Datalogging and Supervisory Control Module Version 6.1 for Windows 2000/95/98/ME/NT/XP -- Fi...
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
Attachments:
BackInTimeAnalyzer.llb ‏622 KB

Editing tag values logged in tag history / citadel database

Hi,
I having been logging data from input/output tags and memory tags to my citadel database over the past week and due to some errors in my vi (my fault) some values are showing on my trends that are incorrect. These values are affecting my calculations (e.g. zeros, infinite numbers etc) and I would really like to delete them if possible.
Does anyone know a way of going in to the database/tag history and selecting and deleting values whilst still leaving other data in tact?
Many thanks,
Stuart

You can remove the data from a Citadel database using LabVIEW, Lookout or Measurement and Automation Explorer (MAX). This is a two step process:
First you archive the data that you want to delete. When archiving, choose to delete this data from the original database. The archiving operation will move the data from your database to new database.
The second step is to delete the new archived database. This removes the extra database that was created by the archive operation. Once the data has been archived you can remove the archived data by either deleting the database manually or by using file VIs from LabVIEW.
The document elaborates this process for MAX, LabVIEW and Lookout separately
Measurement and Automation Explorer (MAX) You must have Historical Data Viewer installed. It comes with Lookout 5.0 and LabVIEW DSC 6.1.
To remove the historical data in MAX, follow these steps:
Under the Historical Data folder in MAX, select the database that you want to remove data from.
Right-click the database and select New View»Trace. This creates a trace view with the default name of New View under the database folder.
On the Trace Attributes page, click on Add new traces. Select the traces you want to archive.
Select a starting and stopping time.
Right-click New View and select Archive.
Enter a directory path to store the archived data.
Check the Delete data from source database checkbox to delete the data from the source database.
Click Start.
Once it is complete, click Close.

Slow opening archived citadel database on first read

I have archived a citadel database using the archive vi. I then copied this database to another computer. when I try to read data from this archived database, it is taking a long time to return the first set of data (5-10 minutes). New attempts to read data execute much quicker than the first read. Is there a way to improve this opening of the citadel database?? Right now I am using the OPEN DB sub vi that was sent to me to resolve an error accessing citadel problem. The database is not setup as the logging location in the tag engine. This OPEN DB vi is locked so I can't do any kind of probing to see what it is happening. Are you not supposed to work with an archived database??
Attachments:
my_citadel_viewer.llb.zip ‏108 KB

Bump,
I was unable to reproduce your problem. I archived a DB on my machine and moved it to another Win2k machine. The program works fine, whether or not I use the open and close DB VIs. How much data are you trying to retrieve? You also may have a corrupted database, and Citadel is trying to fix its corruptions when you first access the data. Have you tried to access the original (pre-archive) database with the VI? What is the result?
Regards,
Michael Shasteen
Applications Engineering
National Instruments
www.ni.com/ask
1-866-ASK-MY-NI

Citadel Database

Similar Messages

Maybe you are looking for