LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

writing to file limiting system performance

Hello,

 

I really could use some help with my VI in terms of writing data.  I’ve had a LOT of help optimizing my code and am trying to enhance the performance in terms of data acquisition.  However, it seems as though writing to a data file is really limiting the frequency I can sample at.  I’ve done some research and understand that writing data at every iteration of the while loop and the build array function slows things down.  How would I modify the code so that the array buffer would store maybe 5000 data points before writing to a file, then clearing the array?  That would keep the array size small, as well as reduce the number of times the program is performing the write to file function.  Is there a better way of doing this?  I’m open to any other ideas as well.    

I am taking data from 14 channels, and would like to sample at 1 kHz each.  The task right now is created within Measurement and Automation Explorer, and the number of samples is at 100.  I also use a buffer indicator, which will generally grow out of control, no matter how much I modify the number of samples and the frequency.  The length of my test can last upwards to 6 hours, so it needs to work that long without crashing.     

 

The code and attached subVI’s is attached.  Hopefully it's all there.

 

Thanks for your help,

Alex

0 Kudos
Message 1 of 5
(3,001 Views)
Alex,

Style Guide: Try to keep the diagram to one screen.

If you put the data acquistion and save to file in separate loops, you can control the rates for each loop separately. Use queues or LV2 style functional globals to pass the data from one loop to the other. Each loop should have a small wait (even 0 ms) so they will share CPU resources. Using Initialize Array outside the loop and Replace Array Subset inside the loop avoids memory allocation problems. The functional global can be configured as a circular buffer with read and write markers to keep track of what data has been stored in the file. Then there is no need to clear the array after writing.

Also, event structures make handling the user push buttons easier.

Lynn
0 Kudos
Message 2 of 5
(2,987 Views)

Lynn,

Yea, I'll have to keep on the block diagram size in the future.  Can get unwieldy.

I tried incorporating the Recent History Buffer example into my code.  I did have a few hang ups, which are giving me some trouble.  Mostly, how do I connect my waveform data to the Buffer VI?  Will I be able to have all my channels connect to this?  Also, ultimately I will have two write to file VI's.  Can the buffer differentiate between which file to write?

Thanks,

Alex

0 Kudos
Message 3 of 5
(2,973 Views)
Alex,

I do not have the Recent History Buffer. It may be platform specific or tied to the DAQ VIs. Anyway, I cannot comment on it.

Lynn
0 Kudos
Message 4 of 5
(2,962 Views)
Hello,
 
Check out the Help Context for the history buffer VI - it is an example which shows you how to store the last N data elements in a 1D array, but it was built for a dbl type and not a waveform.  Furthermore, it takes scalar doubles as input to store internally as a 1D array - your waveform is really an array underneath, not a scalar.  You can use it as an example to build a similar VI for your waveform time if you would like.
 
Best Regards,
 
JLS
Best,
JLS
Sixclear
0 Kudos
Message 5 of 5
(2,929 Views)