07-06-2009 07:25 AM
I am using a PXI 8108 controller with 80 GB hard disk. The disk is partitioned as dual-boot for Windows XP and LabView RT.
Currently I am using Windows XP for storing a lot of measurement values (up to 100 GB and more) in binary file mode with 4 kHz. This works, but as Windows is no real-time system, I am missing data in rare situations, i. e. I am missing some incoming counter values. It really looks like Windows gets out of sync on some occasion. I am talking of a very little percentage, maybe 0.01 % or less.
I am wondering, if I can use LabView RT to log the data and avoid those sync problems. Is the archaic FAT32 the only supported file system? NTFS would be nice as FAT32 limits to 4 GB files. Is there a way to let the binary write block (see attachment) automatically begin a new file after 4 GB while logging?
07-07-2009 07:38 AM
07-07-2009 09:40 AM
Thanks for your reply, DFGray. I attached a screenshot of my LabView program. You may ignore the upper loop, as my sync problem arises without it.
The program saves an external counter value (incoming with 1 kHz) together with some analogue measurement values (with even higher sample rate). As explained before, in rare occasions, the saved file is missing some counter values, e. g. a jump occurs from counter value 629 to 636.
The resulting binary data file contains data like this (in this case without an unexpected counter jump):
counter analogue analogue
value channel 1 channel 2 ....
-----------------------------------------
628 1,54 2,97
629 1,73 .
629 1,76 .
629 1,60 .
629 1,78
630 1,90
and so on...
07-08-2009 08:41 AM
I don't see anything obvious (or not so obvious) which could be causing this issue. I would suspect noise or a loose connection on the counter input. I would check for faulty cables or ground loops. Are there any intermittent RF sources near the hardware (e.g. a large AC motor/compressor)? This could cause the issue. I do have a few suggestions:
07-09-2009 09:17 AM
Thanks for the very useful tips. I added a separate loop for binary writing. I "connected" both loops with a qeue (see attachement). At the moment, a 140 GB measurement file is checked by my C++-programm for counter jumps. Even after 60 % no unexpected counter jump has been detected (the check is still running). All other measurement values are plausible. Of course I have to do more checks, but this is promising.
The only problem is, that the top loop reads zero values for the first cycles. After a very short time, the values are read as expected. Maybe the top loop reads ahead of the lower loop. Do I need a sync point for both loops?
07-13-2009 07:54 AM
Given your code, I would expect the first few values from the top loop to be zero. I would assume that since you are reading temperatures your top loop is fairly slow. The bottom one is not, so it will generate several values before the top loop generates any. You do need some synchronization between these loops. You may also consider putting the initialization of the traditional DAQ outside the top loop, similar to how you have done the DAQmx code. I realize this is not necessarily trivial (traditional DAQ was difficult to move from a simple to a more complex model). If your hardware supports it, you may want to use DAQmx for the top loop, as well. It would make your synchronization easier.
Final note, your file I/O loop appears to never exit. If you wire a TRUE to the force destroy input of the Release Queue, this will cause the Dequeue in your file I/O loop to generate an error, which you can use to exit the loop. If you do this, do not wire the error into your close file VI, or it will not work.