LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabView Real-Time & large files

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?

 

0 Kudos
Message 1 of 6
(3,105 Views)
This sounds more like a race condition in your code than a Windows XP problem, although the nondeterministic nature of XP may compound the problem.  If you are willing to post your application, we can take a look at it.  The code fragment image you posted should not have the problem you described (if it does, it is a bug we want to know about).
0 Kudos
Message 2 of 6
(3,066 Views)

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...

 

0 Kudos
Message 3 of 6
(3,054 Views)

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:

  1. In your top loop, you write to both the terminal and a local variable of the same control.  You only need to write to the terminal.
  2. In your top loop, the conversion to an array can be done more efficiently with a single FOR loop or using the  to DDT and from DDT Express VIs (convert to DDT format, then convert to array of scalars).
  3. I would recommend moving your file storage to another loop.  Use a queue to pass the data from one loop to another.  Look up producer/consumer in these forums or in the LabVIEW examples for sample code.  This will make data acquisition and file I/O parallel processes, allowing the code to run more efficiently and not allowing the file I/O to slow down the data acquisition.
My apologies for not finding anything better.  Glück!
Message 4 of 6
(3,027 Views)

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?

 

0 Kudos
Message 5 of 6
(2,998 Views)

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.

Message 6 of 6
(2,970 Views)