I've looked through the forums for the "not enough memory to complete operation" error and despite following the advice I found, the error still occurs. I'm using LabVIEW 2012 to try and continuously monitor our system, recording temperature, power, etc vs time (values obtained from USB-6008 DAQ). The data being saved to file, is done every 60 seconds using a small array (no problems here). The typical run/time memory allocation to LabVIEW is about 180MB (4GB RAM on computer). The issue I feel is related to our wish to display this data on graphs for extended periods of time. The current iteration of the code works as follows. 1) we have 2 XY graphs with 2 plots each. 2) for each plot, I am initializing clusters of 2 arrays of 100,000 (XY pairs) which are wired to shift registers. I know this is larger than can be displayed on a graph but I am currently more concerned with reducing the number of data copies. 3) Every 10th data point is added into the arrays using an In Place Element Unbundle/Bundle along with a "Replace Array Subset". This means there are approximatly 8640 points per day. (A single day is the shortest time span typically viewed) 4) For two plots on an XY graph, two clusters are combined in an array (using Build Array). I think this is my problem right here. Since everytime I update the graphs Labview has to allocate memory for the 4 XY plots. ( Am I correct here?) Decimating the data further when looking over multiple days will reduce the amount written to the plots. However this operation creates data copies. Is it worthwhile in this case? Instead of initializing 4 clusters (1 for each plot) and combining into arrays later, would it be better to initialize Array of cluster of arrays (2 plots per graph) and update the data by "index / unbundle / replace array subset / bundle replace array subset" series of operations?

Nothing obviously bad jumps out at my, but that could be why it runs for days sometimes. A few things to try: 1) The section where you overwrite the oldest 3600 data points and rotate the arrays has code to initialize a new array. I'd move this initialize outside the loop to make sure you only do it once. You could always just replace the elements in the existing array with a NaN. 2) I'd try getting rid of the build arrays like you highlighted. Initialize these arrays outside the loop and replace elements as appropriate. 3) You build arrays of Irr and Time using the build array and reset them once/day. You could try initializing these outside as well. 4) If something happens and the file write hangs your queue can fill up. The dequeue element already waits for data before it does anything, so I don't think you need the delay in the same loop. This might help the dequeue catch up if the queue gets big. You can use a Get Queue Status vi to display the number of elements in the queue on the screen. As long as it isn't hidden by the error message it might give you an idea if the queue is causing your error. You could also log the queue size to see if it grows. 5) If your error handling of the DAQ loop isn't good, an error there can cause that loop to run as fast as possible. If you added the 1000ms wait just to show that it isn't a greedy loop, then this could easily be the cause. I don't think the USB DAQs are very reliable, so trying to use one for days might run into this error. Hopefully this at least gets you pointed in the right direction. My bet is on #5 🙂

LabVIEW

not enough memory to complete operation

Solved!

Author

I've implemented alot of the recommended changes, ensuring that all arrays in my program are initialized and then using replace array subset (i had forgotten this on a couple of them). I have also added some script to decimate the graph data based on the x-axis range so that I only wire 1094 data points, per plot, to the graphs. I think wiring 4 plots of 100,000 data points to each could have cause some unforseen problems.

The code has been running now for 3 weeks without major incident. There was a single case where the data files were being updated but not the front panel (viewed through a URL). I think the laptop had implemented some power saving options and stopped updating the graphics (adjusted power settings and haven't seen this happen again)