Memory Is Full Error in LabVIEW

Issue Details

When I am running a LabVIEW application, I sometimes receive one of the following error messages:
 

LabVIEW: Memory is full.

The top-level VI was stopped on the block diagram.

Refer to the VI Memory Usage topic in the LabVIEW Help for suggestions on monitoring and improving VI memory usage. 

Error
Not enough memory to complete this operation.

I have a large amount of available RAM, so why am I receiving this error message?

Solution

These error messages are typically encountered when developing an application with large data sets of arrays, clusters, or waveforms. As LabVIEW stores each data set in a contiguous block of memory, the block of memory available on your computer might not be large enough to store a large data set.

Another reason could be that a lot of references are being opened and not closed properly. Closing unused references is very important in LabVIEW and if not managed properly, it can result in memory leaks.

Below are some suggestions to help prevent this error message from appearing:

Reducing Memory Used by Arrays, Clusters, and Waveforms

• If you have an array with a large data set, if possible, use a smaller data type to represent the items in the array. For example, if the items in the array are represented with double-precision floating-point numbers (DBL), but the range of possible expected values is limited to integers between 0 and 100, you can change the integer representation of the items in the array to unsigned 8-bit integers (U8). The U8 numeric data type uses an eighth of the memory that the DBL data type uses.
• In LabVIEW 8.5 and later, use the In Place Element Structure to avoid making copies of data when using an array, cluster, or waveform.
• If you are graphing data from a large array, use max-min decimation to avoid graphing every data point. For more details on this technique, visit the Displaying Large Data Sets section of the Memory Management for Large Data Sets LabVIEW documentation.
• Use the Profile Performance and Memory tool to help narrow down and identify which VIs are responsible for the memory usage .
• Analyze the large data set to determine where memory is full. Stream or write the data to disk and use a high-performance analysis and reporting tool, such as TDMS files and NI DIAdem software.

Reducing Memory Usage in Applications

• To limit the number of times LabVIEW copies data, reduce the number of global and local variables in your application. Instead of using variables, consider using a producer/consumer design pattern or the New Data Value Reference function to create a reference to the data.
• Separate large sections of code into subVIs and use the Call By Reference Node to call the subVIs dynamically. A subVI is not in memory until a VI calls it dynamically.
• Set large subVIs to non-reentrant when possible. Non-reentrant is the default setting for Windows and Real-Time VIs.
• Use the NI LabVIEW Desktop Execution Trace Toolkit to identify problems that could negatively impact performance, such as memory leaks and reference leaks. The toolkit can also collect low-level information such as call chain, thread ID, and location in virtual memory of trace, as well as profile VIs, executables, and shared libraries.
• Reduce the polling rate of your front panel objects. If you are refreshing waveform graphs as quickly as possible, this could use a lot of memory. Reduce the polling rate to a user acceptable number.

Increasing Memory in LabVIEW

• Increase the amount of virtual memory of the system.
• Note that the amount of memory LabVIEW can allocate depends on the bitness of the LabVIEW software and operating system used.
• Consider using LabVIEW 64-bit, which allows for more memory usage but does not support all of the modules, toolkits, and drivers that LabVIEW 32-bit does. This and other differences are outlined in the LabVIEW 32-Bit vs. 64-Bit Applications FAQ. If the 32-bit version of LabVIEW is required for specific drivers/ toolkits, consider integrating both versions and using the 32-bit version only for the drivers/toolkits calls and the 64-bit version for the rest of the application. Use Network Protocols to communicate between 64-bit and 32-bit applications. 

• When you open a reference to an application, project, VI, or other reference source, LabVIEW allocates memory to store that reference. To free up the space in memory where LabVIEW stored the reference source, you must close the reference. For more information, you can read more information on Closing References in LabVIEW.
• When a shared re-entrant VI is called dynamically, a new clone instance is created and the instances are not re-used. Therefore, the references need to be closed properly.

Additional Information

This message is most common if LabVIEW cannot allocate a block of memory large enough for an array. For example, a 2D array of double-precision floating-point numbers of size 2,000 by 2,000 elements uses approximately 32 MB. Even if 32 MB of memory is available, you may not have a block of contiguous memory large enough for the array.

This message is also generated when an array containing more than 2^31 elements is used to index a For Loop. Arrays can contain up to 2^32 elements, but a For Loop can only index up to 2^31 values. This is because the N terminal uses the signed 32-bit integer (I32) numeric data type rather than the unsigned 32-bit integer (U32) data type. The most significant bit of the I32 data type is used to specify whether the value is positive or negative. To get around this limitation, you can split your array into two smaller arrays, or replace your For Loop with a While Loop, comparing the iteration value to the size of the array and terminating when the two are equal.

To add to that, this message can also be associated with the Windows OS issue, which is unable to provide the necessary resource memory for the LabVIEW application. Try to test the code with freshly installed NI software on a fresh Windows PC to try to resolve the issue.