Digital Multimeters (DMMs) and Precision DC Sources

cancel
Showing results for 
Search instead for 
Did you mean: 

Large NI-DCPower Sequences not releasing RAM

Hello,

I am loading large sequences into my PXIe-4139.  According to this, the sequences are loaded into RAM and streamed to the unit as it executes.  Everything works as described.  As expected, the RAM jumps up to close to the limit for a 32-bit program when the Initiate VI is called.

 

The problem is that once the program has run and I have closed the session, all the RAM used by the sequence does not get released.  It drops from 2.9GB down to 2GB.  If I run the program again, I get a "not enough memory" error.  After closing and re-open LabView, the program runs just fine.  Is there another way of freeing the RAM?

 

Calling "Reset" does not clear the memory.  There is no "Delete Sequence" VI like the advanced sequences have.  Is this a bug in the NI-DCPower driver?  Any advice?

 

Thanks,

Jacob

0 Kudos
Message 1 of 9
(3,191 Views)

I'm surprised by the behavior you are observing.

Would it be possible to attach a small program that reproduces what you are seeing?

Marcos Kirsch
Chief Software Engineer
NI Driver Software
0 Kudos
Message 2 of 9
(3,150 Views)

What version of NI-DCPower are you using?

Marcos Kirsch
Chief Software Engineer
NI Driver Software
0 Kudos
Message 3 of 9
(3,147 Views)

I am running LabView version 20.0.1 and using NI-DCPower version 20.6 (latest update from Package Manager.)

 

I don't do anything that isn't already in the example "NI-DCPower Sequence Multi-Channel Sync.vi"  I am syncing two SMUs to start their sequences at the same time.  I am not doing a Source Sync like the example.  I reference this one only because it is the only one that demonstrates a sequence.  I have two SMUs, each running sequences that are 560,323 samples in length.

0 Kudos
Message 4 of 9
(3,139 Views)

I ended up filing a service ticket for this issue.  I will update this post once we figure out the solution.

 

I was able to replicate the problem using the example VI called "NI-DCPower Sequence Multi-Channel Synchronization."  I removed the multi-channel portion and added VIs to build the large waveform.

0 Kudos
Message 5 of 9
(3,093 Views)

Thank you, I also had filed an internal bug, #1498027 for reference and so that we can link them in the system. It's on our plate but I cannot promise a delivery date for a fix. Sorry for the waste of your time this bug has caused you.

Marcos Kirsch
Chief Software Engineer
NI Driver Software
0 Kudos
Message 6 of 9
(3,079 Views)
I spent a decent amount of time reproducing and investigating the behavior you observed in NI-DCPower. There does not appear to be a memory leak in the driver. What you are seeing is a combination of committed memory and 32-bit address space fragmentation. I tested with NI LabVIEW 2019 and NI-DCPower 20.6 on a Windows 10 32-bit system with 4 GB of RAM. I also tested with 64-bit LabVIEW on 64-bit Windows for comparison.
 
When you create a large sequence, a large amount of memory is allocated by the driver in user space. Some of that is on the stack, but most of it is on the heap. When you close the session (or replace with a smaller sequence) most of that memory is freed, but the process still maintains a hold on it for use later. This is committed memory, and the process will re-use that block for future allocations. However, 32-bit Windows processes are not as good about memory fragmentation as 64-bit Windows processes, so if something is allocated in that large committed-but-unallocated block after the session closes, the next time you try to commit your sequence, it will have to allocate more memory in a new contiguous location. Since the large free block is no longer free, it tries to create a new giant block rather than be clever about it and split it up into smaller chunks. Since there's not enough free space for that much contiguous memory, the OS returns an out of memory error.
 
Since you are running into the memory management limits of an OS that NI no longer supports, my advice is to upgrade to 64-bit Windows.
Tobias
Principal Software Engineer
Driver Software
National Instruments
0 Kudos
Message 7 of 9
(2,904 Views)

Tobias,

Thanks for taking the time to look into this.  Your explanation makes sense because I can see the reallocation does not need the full chunk of RAM.  It just needs a little bit more and then it re-uses what it already has.

 

One slight thing to note, I am using 64-bit Win10 but 32-bit LabView.  Some of the functions I use are (were) not support in 64-bit LabView, which is why I am sticking with the 32-bit version for now.  Of course, my survey of 64-bit LabView coverage was done years ago so maybe things have changed.  I'll take another look when I have the time.

 

Thanks,

Jacob

0 Kudos
Message 8 of 9
(2,898 Views)

Jacob,

 

Glad to hear this does appear to match your behavior!

 

Out of curiosity, what features were not supported in 64-bit LabVIEW at the time you last looked?

Tobias
Principal Software Engineer
Driver Software
National Instruments
0 Kudos
Message 9 of 9
(2,868 Views)