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

Similar Messages

How to archive citadel database. we have DSC 6.0.2

we have LabView 6i & DSC 6.0.2 . we develop a application using tags. we want to log our data to citadel database but some time the data is lost for some reason (like system hank or restart).so we want to take a backup of our citadel database.how it will possible.

Pilla,
Unfortunately, 6.0.2 does not have the capability. This was one of the new 6.1 features. Check Table 3 on page 7 in this manual. The Archive Database is what you need for programmatic archive. In 6.1 there is also a new utility called Historical Data Viewer, that allows you to do it manually.
http://www.ni.com/pdf/manuals/322955b.pdf
I remember seeing some online document about archiving Citadel database. ... oh, ya, here it is (I searched ni.com for "archiving citadel" and it was the first hit):
http://zone.ni.com/devzone/conceptd.nsf/webmain/2F24997EAD7C53A686256B6E00686D64?opendocument
Have a good weekend.
Dr.Tag

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

Display archived citadel data mixed with "live" Lookout machine data using Hypertrend object?

Maybe a new feature request item?
It would be really nice if you could use a Hypertrend object in Lookout to plot historical data from an archived Citadel database. So this would be a feature where you could connect an additional (or many) additional databases as machine processes in (read only mode of course). This would allow mixing display objects (trends) of running processes along with display objects (trends) of archived "processes" in the same Hypertrend display when using Hypertrend in the historical mode.
The Lookout Hypertrend object is awesome and it is about time you folks gave Lookout some attention again to exploit its power and coolness.
Thanks and Happy New Year!!

The hypertrend use Citadel service to transfer the data between computer, while the live data is different, so your problem is probably in networking setting or firewall.
If you have firewall on either computer, follow these KBs.
http://digital.ni.com/public.nsf/allkb/0D7B86F4B4D19A5E86256F9A006EECB1?OpenDocument
http://digital.ni.com/public.nsf/websearch/8AE45BBFA1D7025E862570F200642FD8?OpenDocument
Lookout client software doesn't install MAX.exe, but if you have MAX.exe on the client computer, you can use MAX to check the connection. In MAX, try to view the remote trace.
You can also use the NI Hypertrend ActiveX object to check the connection. Create a client process with just a NI Hypertrend ActiveX object. Move it to client computer. Edit its properties and add a trace, then try to view the remote trace. See the attached screenshot. If the Citadel communication has problem, you will not see the database or the trace.
The ActiveX object doesn't fix the problem, but can tell you whether the remote connection is good or not.
Message Edited by Ryan.S on 11-14-2008 03:49 AM
Ryan Shi
National Instruments
Attachments:
1.JPG ‏71 KB

Uable to connect to citadel database on network in MAX

I have a question regarding the "Citadel 5" in MAX 3.0.0.3/LV 7.0 (Win2k environment). Using MAX I can open/browse a database stored on the local PC and browse the tag names, but when I try to connect to a PC on the network with the same configuration, I am unable to browse the tag names of the remote database. I can well see the database name itself on the remote PC. In the database symbol of the MAX browser there is a yellow exclamation mark with red border displayed. I can't find any information what this means.
The remote PC is configured to allow full access for the local PC. Using the logos:// protocol I am able to read and write to the remote database.

Yes, I can browse the tags locally on the remote PC.
Citadel version is 5.
Here some more system information:
NI Software Information:
CVI Run-Time 6.0.4.105
FieldPoint 4.0
LabVIEW Interface 4.0.0.21
IVI Driver Toolset 1.5
IVI Engine 2.0.0
LabVIEW Run-Time 7.0
LabVIEW 7.0
Advanced Analysis 7.0
Application Builder 7.0
Datalogging and Supervisory Control 7.0
PID Control Toolset 7.0
Real-Time 7.0
Measurement & Automation Explorer 3.0.0.3014
NI Spy 2.0.0.16
NI-488.2 Software 1.70
NI-DAQ 7.0.0f8
NI-DAQmx 7.0.0f0
NI-PAL Software 1.6.2f1
NI-SWITCH 2.00.49156
NI-VISA 3.0
NIvisaic.exe 3.0.0.32
NiGpvx32.dll 3.0.0.32
NiVi488.dll 3.0.0.32
NiViAsrl.dll 3.0.0.32
NiViEnet.dll 3.
0.0.32
NiViEnetAsrl.dll 3.0.0.32
NiViGpvx.dll 3.0.0.32
NiViPxi.dll 3.0.0.32
NiViRpc.dll 3.0.0.32
NiViSv32.dll 3.0.0.32
NiViUsb.dll 3.0.0.32
NiViVxi.dll 3.0.0.32
NiVisaServer.exe 3.0.0.33
viic_ext.dll 3.0.0.32
visa32.dll 3.0.0.32
visaconf.dll 3.0.0.33
LabVIEW DSC 7.0
LabVIEW Datalogging and Supervisory Control Run-Time System 7.0

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.

Citadel database error 81bc0163 (Citadel 4.3)

I’m not sure how my database was corrupted (I suspect a NaN)
but the result is that when displaying a certain period of time, either from
within the LabView DSC module or with the Measurement and Automation Explorer (MAX),
the LabView DSC (or MAX) crashes by exiting without notice. If you attempt to
archive the data, you get the error 81bc0163 and archiving is aborted. How to
solve:
1. Make a complete copy of the database directory (with the
.thd and other files). You will need the dates on which the .thd files were
created, and the Citadel database engine wants to repack these files and thus
change the dates (Citadel will sometimes use ‘holes’ in existing files to store
new data, but it generally creates files and stores data sequentially.)
2. Using MAX, open your copied Citadel database and create a
new view to it. Include the 1st 20 traces. Plot these traces (select
them and then click on the Display tab) for the entire duration (this can take
a while). If MAX does not crash, plot the next 20 traces, until MAX crashes. The
goal is to find which trace cause MAX to crash. (If you can plot all traces for
all times, you don’t have the problem I encountered.)
3. Now create a view that includes the 20 twenty traces that
caused the crash and Display it for various periods of time . Select an end
date, and then choose the Display tab. If MAX crashes, then repeat with a
different end date, util you can isolate the date and time of the faulty
record. Be sure to use a very narrow Display time to get good resolution. A
binary search of time periods is the most efficient, unless you already have
some clue about the problem date.
4. Once you have identified the date and time of the date
that causes the crash, exit MAX and then delete the .thd file whose creation
date is just prior to the chars date and time.
5. Restart MAX and open the view of your copied data base.
BE PATIENT, it can take many, many minutes for the Citadel database to deal
with the deleted .thd file, but it appears that the Citadel database is robust
enough to recreate its indices.
6. Create a second new view of the copied database (this resets
the time from the beginning of creation to the distant future), select the
critical 20 traces, and click on the Display tab to make sure the database can
now be viewed without crashing. If, not repeat the process with yet another
copie database.
7. Now, rename the copied and the original folders so that the
fixed database replaces the original. Verify that the ‘new original’ is OK by
running MAX and crating a view of the 20 traces and displaying them for all
times.

I forgot to include the full stack trace:
java.lang.UnsatisfiedLinkError: /nfsmounts/risc14/cmsd/gdfr/dbxml/dbxml-2.2.13/install/lib/libdb_java-4.3.so: /nfsmounts/risc14/cmsd/gdfr/dbxml/dbxml-2.2.13/install/lib/libdb_java-4.3.so: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:992)
at com.sleepycat.db.internal.db_javaJNI.<clinit>(db_javaJNI.java:48)
at com.sleepycat.db.internal.DbEnv.<init>(DbEnv.java:200)
at com.sleepycat.db.EnvironmentConfig.createEnvironment(EnvironmentConfig.java:738)
at com.sleepycat.db.EnvironmentConfig.openEnvironment(EnvironmentConfig.java:691)
at com.sleepycat.db.Environment.<init>(Environment.java:30)
at org.oclc.da.gdfr.registryprototype.pvt.CollectionDbXml.createDefaultManager(CollectionDbXml.java:361)
at org.oclc.da.gdfr.registryprototype.pvt.test.CollectionDbXmlTest.setUp(CollectionDbXmlTest.java:324)
at org.oclc.da.gdfr.registryprototype.pvt.test.AllTests.main(AllTests.java:22)
I'm also installing the DB with this tar:
dbxml-2.2.13.tar.gz

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

Detach citadel database to move

Hi,
I'm upgrading the computer I use for datalogging. I want to move my citadel database over. Ive tried following the intrucctions here: http://digital.ni.com/public.nsf/allkb/2B0C74744BB37391862571F500067C64 , but when I go to Detach the database, I get an error "The operation cannot be completed because the resource is in use by another client." There is nothing else running besides MAX, as far as I know.
Do I actually need to detach the database if I won't use it again on this computer? Can I just copy the data folder over?
thanks
mike
Solved!
Go to Solution.

Hi mooseo,
It seems this error occurs when the process is still connected in Distributed System Manager. Try this KnowledgeBase article (do not do step 3, do the other KB article that you have there instead)
http://digital.ni.com/public.nsf/allkb/5E68A6BC5526F165862573BD005C1A42?OpenDocument
It is probably safest to detach and move the database.
Let me know how it goes.
Matt S.
Industrial Communications Product Support Engineer
National Instruments

Is there a way to test for integrity of the Citadel Database?

Gday,
Currently I am logging OPC data to a Citadel 5 database (Labview Version 8.2.1).
I have done some integrity testing to try and "break" the citadel database and I noticed that if you delete any of the .cdpg files no alarms are flagged or notifications given in MAX or elsewhere to show that the database has been comprimised.
The result of deleting or the corruption of any of these .cdpg files will result in valid data being 'moved' back in time as the citadel databases only log changes in value with no corressponding timestamp. For example if you delete from 9.00am to 10.00am then all data logged after 10.00am will now start at 9.00am.
So I was wondering if there is anyway to either correct or even test for corruption in a citadel 5 database.
Regards
Ben

This should not happen according to the design of Citadel. Also I tested with current Citadel, and didn't see this problem. I'm not sure if it was a bug in the old Citadel(the one with DSC 8.2), but for current Citadel, I can't reproduce it.
There are many files in database folder. The .cdpg file is the data file, containing all the logged data. Some other files, such as .cdin, .cdih, .cdib, are the index files. When you read data from a trace, Lookout will first find the index from those files, and then locate the position of the data in .cdpg files. Actually Citadel will rebuild the index files if it finds something changed or damaged. If you delete one .cdpg file, Citadel will rebuild the index files. With the new index files, you can work with the database without any problem. The only difference is that the data in the deleted file can't be viewed then, just like the data was nevered logged. So, to delete the .cdpg file won't damage the whole database. The new data will be logged to database with the real time or the user-defined time. Citadel does log the delta value, but it also records the time for each trace. The detailed architecture is too complex to describe.
Can you give some screenshots to show the problem?
Ryan Shi
National Instruments

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

I am unable to create a new Citadel database

I am using DSC module 8.5 and am trying to create a new database using MAX. I am following the instructions, but when I select "Finish" to create the database, the progress meter pops up and stays at 0%. I should add that there was not a default database for Labview 8.5, although there are ones for 8.0 and 8.2.

Hi,
I think you are trying to create with same name which is already existing in your system. You want to select a new database path with new name.
with regards
vijay

Database creation process hangs

I am manually creating a database on Windows 2k3 server using Oracle 11 r2. Using the Database Configuration Assistant to create a database, the process hangs for hours.
I figured out and triedthe following:
1. I have attempted using the GUI tool more than once to create the database and each time it hangs.
2. Using the scripts have been created using the with configuration tool, I manually attemped to create database. -- I have attempted more than once.
3. The database creation process hangs while running the EXECRM.SQL file that is called by the CATPCNFG.SQL which is called by CATPROC.SQL which is called by CreateDBCatalog.sql
3. The EXECRM.SQL file hangs on the following statement EXECUTE DMBS_RMIN.INSTALL;
I'm not sure why the PL/SQL packag is hanging at this point. Any help is appreciated.
Thanks,
Sheila

I was able to create the databases prior to installing Enterprise Manager Grid control. I deleted the databases to re-create so they would be registered with Enterprise manager. Once I install Enterprise manager the creation process hung. I have also installed Essbase and Oracle/Hyperion Enterprise Performance Management Suite on the server. I'm trying to do some research on these BI tools.
I'm tempted to uninstall Essbase and the Hyperion producst along with Enteprise Manager and start from scratch to test to see if I can create a database without these other products.

Archive citadel database in MAX hangs

Similar Messages

Maybe you are looking for