08-29-2016 03:56 PM
I am using NI USB 6000 with labview. I am acquiring continuous analog data but then after running for sometime I get an error
"The application is not able to keep up with the hardware acquisition.
Increasing the buffer size, reading the data more frequently, or specifying a fixed number of samples to read instead of reading all available samples might correct the problem." Please find the attached vi.
Solved! Go to Solution.
08-29-2016 04:11 PM
Try using a producer consumer architecure. Put all the data capture in your producer and all of the analysis in the consumer.
08-29-2016 06:16 PM
First of all, it would help us diagnose your issue more if you posted the actual VI.
So from the picture, here are a couple of things I would fix:
1. Get rid of the XY graphs. They are just showing information that is already in the charts you have. Have the From Dynamic Data configured to output an array of waveforms and you will have the time information in the charts.
2. I am guessing the case structure that is cut off on the right is for data logging. You really should ask to log upfront and then you can use a Producer/Consumer setup to have your logging happen while you capture the data. This will save a lot of time asking for more memory.
08-30-2016 07:17 AM - edited 08-30-2016 07:22 AM
The reason I am using 2 charts is the waveform displays the data during continuous acquisition while the xy shows the entire data after stopping the application. Also through xy i am able to obtain the actual time im getting my data.
Could you please help me more with the producer/consumer architecture. I have attached my vi
08-30-2016 10:26 AM
Take a look at these links for help with producer consumer. You can also find examples under help/find examples in the labview environment.
http://www.ni.com/white-paper/3023/en/
https://decibel.ni.com/content/docs/DOC-2145
08-30-2016 10:39 AM
You are autoindexing evergrowing 2D arrays at the while loop boundary, requiring LabVIEW to request more memory from the memory manager, a relatively expensive process. If you don't stop the VI, you are quaranteed to run out of contiguous memory eventually. As your VI runs, it is digging itself deeper and deeper into memory problems. What is the loop rate?
Please show us the rest of the code, there has to be more to it. Why are the graphs outside the loop? Are they configured to retain data between calls? (another memory issue). What are the values of the various booleans and where do they connect to? An image is insufficicnet to see these things.
For some general guidelines on optimization and memory considerations, have a look at part II of our NI-Week presentation.
08-30-2016 10:44 AM - edited 08-30-2016 10:46 AM
The reason for graphs outside the loop is that when I press the stop button the entire data is displayed on the X-Y graphs. the chart that is inside the loop displays it continuously when the loop is running and acquiring data. The only way I have retained the collected data is by storing it in the array and writing that array to an excel file. Also the loop rate is 1000Hz but varies as the values settle. Please find the attached vi
08-30-2016 10:52 AM
Recommendations:
1) Use the producer-consumer architecture
2) Move your GUI activities into a separate loop. Your GUI interractions are the slowest executing parts of the code.
3) (opt) Apply this technique to your GUI:
4) (opt) If the execution is still not fast enough, add a data collection loop. Use Queues to xfer data to the main data crunching loop.
5) Waveform data doesn't have to immediately displayed. You can crunch the data and pass it to the GUI at your leisure.
08-30-2016 01:36 PM
I will try the producer consumer architecture but I need to display the data on waveform immediately because of the purpose for which I am making it
08-30-2016 01:39 PM
Are you concerned about losing any data or just displaying the most recent data?