06-10-2021 12:59 PM
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?
06-11-2021 08:51 AM
I'm surprised by the behavior you are observing.
Would it be possible to attach a small program that reproduces what you are seeing?
06-11-2021 08:52 AM
What version of NI-DCPower are you using?
06-11-2021 01:51 PM
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.
06-17-2021 06:48 PM
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.
06-18-2021 08:40 AM - edited 06-18-2021 08:41 AM
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.
10-14-2021 02:09 PM
10-14-2021 02:48 PM
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.
10-18-2021 04:41 PM - edited 10-18-2021 04:41 PM
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?