LabVIEW
Is there a way to find out how much memory is left while a VI is running?
Solved!
Hi Jim,
I don't know where and how you are looking for information, but I found this one by using Google with "labview find available memory"…
@Jim12345678 wrote:
I have a VI that acts as the user interface to another program. The other program collects gigabytes of data and stores it in memory as it cannot save it fast enough.
When you have two separate programs (aka executables) you need to use PerformanceMonitor calls to gain access to other process' statistics from your "UI program"…
If you only need the available memory with regards to the Windows OS, you might have some luck with the following function call: GlobalMemoryStatusEx function
Of course, if you're running Win 64-bit and LabVIEW 32-bit (I'd guess pretty common), there's a good chance that the value you receive is irrelevant...
The commands described in the question here (Get-Process with total memory usage) might be useful if you wanted to find the memory used by LabVIEW (and compare that to some static value, e.g. 3GB or similar).
For both of these approaches, you'll probably have to use system calls, either via the Call Library Function Node or the System Exec node (respectively).
@Jim12345678 wrote:
I have a VI that acts as the user interface to another program. The other program collects gigabytes of data and stores it in memory as it cannot save it fast enough. Currently, I run task manager (Windows 10) and watch as the computers memory gets consumed so I know when to stop the underlying program. Is there any way from within the LabVIEW VI to find out how much memory is left?
You don't really give sufficient information. The memory used is just a number and may or may not be useful to you anyway. How are the gigabytes of data" acquired and "stored in memory"? Is this in ever-growing arrays (1D, 2D)? Some complicated dynamic data? Waveforms? Higher structures? Do you have data duplication (local variables, indicators, etc.).
Arrays require to be contiguous in memory, so the amount of contiguous memory is much more important than the amount of free memory and if you constantly grow structures, the entire data needs to be moved to a new contiguous memory area once the current allocation runs out. Expensive and wasteful and you'll quickly fragment you memory.
So, the correct way would be to allocate an array at a fixed maximum size when the program starts (e.g. with NaN or some other sentinel value), then replace with real data as it arrives, keeping track of the insert point. If the initial allocation succeeds, you are guaranteed to never run out of memory and it is easy to track how much of that allocation has been filled by just comparing the insert point to the total size.
I really have no idea about your expertise, but I have the feeling that you are searching for a solution in the wrong place. It probably can be solved by significantly tightening the code.
@altenbach wrote:
So, the correct way would be to allocate an array at a fixed maximum size when the program starts (e.g. with NaN or some other sentinel value), then replace with real data as it arrives, keeping track of the insert point. If the initial allocation succeeds, you are guaranteed to never run out of memory and it is easy to track how much of that allocation has been filled by just comparing the insert point to the total size.
Another vote for this, a similar method worked great for me when I needed to have a crapload of memory used at once.
Not to mention it'll be faster than dynamically creating the arrays, which might be what you're doing now.
@Jim12345678 wrote:
Thanks for the suggestions. I'm aware of all of those things. I'm just looking for a decent measure of how much memory is left so I know to stop the code before the computer starts to hang up.
As I said, it can hang up way before you run out of free memory, so any such measure is probably not helpful. It will not tell you how much of the free memory is contiguous.
