From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview Efficieny - Assistance for a new approach

Greetings,

I have written a DATAQ VI program to analyze creep (Displacement (displacements are 0.X00s inches = 0-10 Volts) vs time (time scales are 1000+ hrs).  The program collects 12 channels (through two DATAQ devices) every 500 ms.  I collect data at 6000 Hz and average data every 3000 data points.  I have included in the VI the several different routines (SUBVIs) for different functionalities.  The most recent addidtion has lead to some problems and I need advice on how to create a more efficient program.  The SUBVI that seems to be causing problems functions by taking an initalized 2D array with only 2 zeros and appendeds two new data point every ten minutes.  It then outputs the appended array (in a cluster) to plot and the original appended array to eventually append more data to when my X time has passed.  This functions great until some time has passed then I get an error from the DAQmx read that tells me the VI has tried to write data to the device before the device can clear the buffer to the computer.  The first fix was to decrease my data acq rate, and that doubled my time before a crash (from 4.33 hours to 7.72 hrs), but still lead to the same error.  The device is a USB 9215A that is through a USB 1.1 port.  I did a quick calculation and at the rate of 6000 samples per second for a 16 bit device with 4 channels (at 1 bit = 0.125 bytes) I would only pass 48000 bytes of data per second through the USB port, well below the maximum rate of USB 1.1 (about 143 KB/s) So I don't think my issue is a device to USB 1.1 port (BTW nothing else access this USB port).  I feel what must be happening is that I run the entire program within a while loop.  Each time step that this function runs it appends data to this array for plotting and then passes that entire array through a shift register.  Thus as the array becomes larger and larger it requires more processing time to pass through the shift register to each iteration of the while loop.  Eventually, with all the other functionality in the main VI it takes the processor more time to run all the SUBVIs than the DATAQ USB card has time to clear the buffer space and thus the data sits on the onboard DATAQ buffer, which then tries to rewrite new data before it has transferred the last data to the computer memory creating this error.  Is there a better way to update this plot rather than passing the entire array time and time again as the array becomes larger and larger?

I am a graduate student and thus only have the academic version of Labview; I cannot create a built distribution to upload for critique.  I have included my top level VI, and the SubVI that I would like advice with.

Thank you,
Nick
0 Kudos
Message 1 of 4
(2,607 Views)

Nick,

I believe you are correct in your reasoning behind the error.  Because USB devices require interrupts to pass the data of the device, if no processor time is available to fill the request these types of errors can occur.

Instead of having to redimension the array, and forcing LabVIEW to copy the data to a new memory location, you could initialize the array to a predefined size at the beginning of your application.  For example if you wanted to record data for 1 hour at 2 samples a second you would initialize the array to have 7200 elements.  In each iteration of the array you would then insert into a specific element.  This would allow you to keep track of all the data.  Another alternative is to store that data to a file, and only keep a smaller history for your graph.  For example you could record data for 7+ hours into a file, but only keep the last 30 minutes of data in the graph.  Once the application has stopped you could do post processing on that data when time is not as critical. 

Regards,

Jesse O.
Application Engineering
National Instruments

Jesse O. | National Instruments R&D
Message 2 of 4
(2,584 Views)
Jesse O,

Thank you for the insight

Couple of questions.  Is it more efficient to allocate an entire array say of 120000 double precision points than it is to allocate an array of 2 double precision data points and add 2 every cycle. 

If I do allocate an array with 120000 data points and my program happens to need 120001, does labview then couple that entire array to an new location (which would definetly dump my acquition) or allocate another block and use an additional pointer to that new array memory block?

I intially decreased my aquisition rate from 3000 to 1000 Hz and have been running the program at full load for 7 + hours with no issues.  Would moving to USB 2.0 aid in decreasing the length of the interupt to transfer data from the USB device buffer to the computer memory also alleviating my issue.

Finally, how do I monitor the size of the on board buffer for the USB device.  I have done in past and remember that I have to use a property node through the 'DAQmx read' but cannot find documentation on how to or remember how to. 

Thank you again

Best,
Nick
0 Kudos
Message 3 of 4
(2,574 Views)

Nick,

It is more efficient to allocate the entire array before your while loop, and use the replace array subset vi to fill it in.  You can find information on this here:

http://zone.ni.com/reference/en-XX/help/371361A-01/lvconcepts/vi_memory_usage/

under the heading "Avoid Constantly Resizing Data".  If you need to add the data point to location 120001 you need to use the insert into array, and this will reallocate all the memory in LabVIEW.  As the document demonstrates with the build array, this is very time consuming. 

I do not think that going to USB 2.0 will help you past this problem because the issue seems to be with the processor.  It sounds like the processor is not fast enough to keep up with the memory allocation/copying of data and handling interrupts.

To find out how many samples remain in the buffer, you can use a DAQmx Read property node.  In this property node select Status >> Available Samples Per Channel.

Regards,

Jesse O.
Application Engineering
National Instruments

Jesse O. | National Instruments R&D
0 Kudos
Message 4 of 4
(2,554 Views)