You wrote:
I have a loop that acquires data from NI DAQ and writes data to a text file.
'Acquiring' and 'writing to file' stages are separate sub VIs inside a loop. As soon as set of 'N' data is acquired, it is sent to write to file subVI to write in File 'X'. The process is repeated until acquisition is done for say, "t" seconds.
I wanted to write the data into two files inside the "Write to File" subVI. For this I just send a File refnum to the subVI and write data to a second file (File 'Y') after writing the first (File 'X'). I use a "flush file" command for both of them...
When I write to one file only, scan backlog stays at zero and acquisition happens properly. When I include the code for the second file too, scan backlog increases...
Could anyone let me know as to what I am doing wrong here?
The likely problem is that acquiring a sample and writing two files to disk takes more than one sample time. The question is, "What to do about it?" The answer is, "Several things."
1. With the acquisition and storage VIs both in the same loop, they have to run sequentially. Put them in separate loops so that they can run in parallel. It is almost always wise to do this.
This works because a write to a disk takes a long time but not much processor overhead. The processor can work on the acquisition while the disk controller is handling the storage. Use an intelligent global, queue, or ordinary global to transfer the data from the acquisition loop to the storage loop.
2. It sounds like you call the storage VI twice, once with each of the two different files specified. This causes these two writes to be sequential. Make two separate VIs, make the VI reentrant, or combine the two by making the VI reentrant and wrapping it in two different shell VIs for the two channels. depending on your needs and comfort level. Now the processor can set up one transfer while the disk controller is trying to find the right sector on the disk for the other.
3. Don't flush too often.
The actual transfer to the disk is what takes most of the time. The "write to disk" operations normally just write to the disk buffer, which is very fast. When the operating system thinks it's necessary, when you close the file, or when you flush the file, that buffer is transferred to the disk. If the computer crashes in the meantime, you lose all the data in the buffers. (If it crashes before you close the file, you can recover the flushed data with certain utilities. Since flushing is much faster than closing, it is commonly used to save a little computer time over and over again at the risk of very rarely wasting a lot of your time.)
Unless your data is extremely valuable, don't flush the buffer after each write. Accumulate data over a period that is reasonable to lose in the unlikely event that the computer will crash. In most cases, flushing every minute takes essentially no net time (milliseconds per minute) and puts only a minute's data at risk. If your data is very valuable (e.g.. crash test data), write the data as it is acquired over a network to a backup computer as well and store it both places in parallel or use something more reliable than a computer to capture the data.
Hope this helps. If anything is unclear, just ask.
--
EnWirementally,
Paul F. Sullivan----------------------------------------------------
SULLutions (781)769-6869
"when a single discipline is not enough"visit http://www.SULLutions.com
----------------------------------------------------
