I have trouble when writing a binary file. Here is what I do: I have some VI's collecting various data for a fixed period of time. I put all the data into 1D arrays at a fixed frequency (they all have the same size). Once it is done I merge all the arrays into one 2D array and I write that to a binary file. If I wait about 10 seconds after writing the file and I repeat the whole thing, everything is fine and the timing is correct. If I wait for a shorter period of time (say a sec, and this is the maximum I can wait to have a usable application) then the timing is wrong in the first part of the loop (the time-critical data-acquisition one). Of course, if I don't write the file, everything is fine (I have to wait about 250 msec between two runs, but that's ok). Any advice ? I also tried several things like streaming the data to disk during the time-critical period and this works fine only if the file allready exists. If not I experience jitters again. I don't really want to stream the data in real time, but it could work if I can get rid of the jitters. Again, any advice ? I'm using LV7.1 and the real time module running on a PC (ETS). Another, sort of related, topic: I noticed that when using 2D arrays within time critical loops all the process are slowdown whereas if I use several 1D arrays everything is fine... Any idea why ? Thanks, Laurent
Here is a good knowledge base on how optimizing file I/O transfer in a LabVIEW RT application: * Optimizing File I/O in LabVIEW and LabVIEW RT http://zone.ni.com/devzone/conceptd.nsf/webmain/7134EFC95243E39286256AE2004F9386
I join also a good streaming to disk programming example for LabVIEW RT: * Fast File Writing in LabVIEW Real-Time http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=B45EACE3E19D56A4E034080020E74861&p_node=174823&p_source=external
Thanks for answering. These links are helpful but I still get some jitters after recording the file if I don't wait long enough (a couple of seconds). Is there a way to speed up the write to disk process ? Alternatively, is there a way to know when it's done so that I could wait for a trigger instead of waiting for a fixed period of time ? Regarding my other problem, do you know about an issue related to 2D vs 1D arrays ? What I see is that it takes more time to deal with one 2D array instead of a bunch of 1D arrays, even though the total amount of data is the same...
File I/O transfer rates during streaming to disk depends on several factors: CPU speed and load, hard drive technology (IDA / Serial ATA / SCSI ...), quality of programming. High jitter is always due to bad programming. File I/O operations are not deterministic. So, file I/O VI's must not be called in the critical task. Data must be saved in the normal priority VI's in order to keep jitter as low as possible. This is the reason why an application in RT is based on RT FIFO to transfer data from the critical loop and the normal priority VI. You will find a lot of tutorials detailing the key concepts for RT programming at the link below: * Real-Time Module http://zone.ni.com/devzone/devzone.nsf/webcategories/C25F8C664230613A862567DF006ABB06 Moreover, memory allocation in LabVIEW is implicit. You must use large set of data carefully because some function reallocate new buffers for their outputs instead of reusing the input buffers (like the function "build an array"). You will find an example of how we can decrease the memory use with array in LabVIEW in the tutorials linked above. If you need more specific advices, you can post a sample code that reproduce the behavior that you does not understand. I will try to look at this and give you my feedback.
Thanks for the input but I still have the same problem. I already transfer the data from the time critical loop to a normal priority VI using the FIFO thing. My problem happens after wrting the file. Here is the sequence : #1. Some VIs are acquiring data and put them in arrays (using FIFO since this is a time critical loop). #2. Save the data (write a binary file) and close the file (this is normal priority). #3. Wait. #4. Go back to #1. If I don't wait long enough at step 3, I see some jitters in the critical loop. I don't understand why, because I would assume that once I close the file, everything should be fine. Again if I don't save the data the timing is rock solid.
As I said before, can you post your code (or a sample code) in order to test it and see the behavior you describe. It will be more easy for me to identity your issue and give you a quick and approriate answer.