Not Enough Memory in TestStand + LabVIEW environment

Home / Blogs / Not Enough Memory in TestStand + LabVIEW environment

If you have your test running in 32bit version of LabVIEW and 32-bit version of TestStand, and especially if your application is dealing with image processing algorithms, then there are numerous chances you end-up with a Not Enough Memory dialog from LabVIEW as below. There are some creative way and some workaround way to fix this memory issue.

Not enough memory dialog from LabVIEW.

1. Unload option

Find out the step which consumes most memory and change the Unload Option for that step in TestStand properties. I prefer Unload after step executes. This option would unload that step from the memory and thereby releasing any data stored in that module. Ensure if this module deals with any references, which upon closing, other modules might get affected.

Choosing Unload after step executes in TestStand step properties dialog removes the module from memory to free up the memory it consumed.

2. Run the VI module in Run-Time

When you select to run any item on run-time, then it basically going to use the Teststand’s memory. LabVIEW run-time runs under the TestStand memory (SeqEdit process). The modules which are directed to use run-time will use the TestStand’s memory and not LabVIEW’s memory. If your module has overheads in LabVIEW development environment, then this option helps a lot.

Choosing Always Run VI in LabVIEW Run-Time Engine runs the module under TestStand SeqEdit process.

3. Run few VI modules on Run-Time and few on LabVIEW development Environment

If you strategically plan to split few modules to run use both of the above two options, i.e., few steps on LabVIEW development environment and few steps on Run-Time Engine, then you are supposedly having 4GB+4GB = 8GB memory for your sequence to run. This way you can get double the memory space to finish off your work.

These are numerous workarounds or creative ways like this to get around the memory issue. Nevertheless, the best solution is to optimize the modules which causes that memory gulp or memory leak.

2 Comments

Leave a Reply to matt watkins Cancel reply

Your email address will not be published. Required fields are marked *