No option for Acquire Read Region method

[NickDngc]

Wow... ok, so I bit the bullet and did what I should have done from the beginning. Per speleato's instructions, I expanded all subVIs into one diagram and started disabling portions to narrow down the leak. I was able to exonerate everything until the final write to the Digital Graph indicator.

I put back in the subVI and created two indicators: one of type "cluster of digital waveforms" and one of type "Digital Graph". I then created a diagram disable structure that controlled which indicator the data was routed to. When connected to the digital waveform cluster, memory usage was stable. When connected to the Digital Graph, memory usage slowly and steadily increased.

Does that mean the Digital Graph indicator is leaky?

[Great_Britton]

It shouldn't be. What version of LabVIEW are you using, and what version of the NI-RIO drivers? 

[NickDngc]

LabVIEW 13.0.1 (32-bit)

NI-RIO 13.1.0

[NickDngc]

By the way, this is what my Task Manager RAM profile looks like after closing all LabVIEW applications. Takes a few minutes for all the memory to finally free up unless I use "End Process" to kill it immediately. Very slow exponential decline with continued high processor usage even though nothing else is running on system.

[Great_Britton]

Hey,

I've been unable to recreate the issue using a Digital Waveform Graph. If you use ctrl+h to enable context help, what are the names of the indicators you are using one your front panel as listed in the help documentation? Also, what is in the clusters you are writing to the indicators?

[NickDngc]

problematic indicator: Digital Waveform Graph

less problematic indicator: cluster of 6 elements, each element is type Digital Waveform

I simplified my project as much as possible. I put the troubling stuff into one Host VI. I took all the VIs out of the Target area and left only the FPGA configuration (DMA regs, I/O, Regs, Clocks). That leaves three files that you should be able to run and reproduce:

1. FPGA project file (AcqTest.lvproj)

2. Host VI (AcqTest.vi)

3. Bitfile (LFIS_Target.lvbitx)

The first two are attached. I couldn't attach the bitfile; kept getting following error: "The contents of the attachment doesn't match its file type". If you give me an email address, I will send the bitfile as well.

[NickDngc]

This is even better - I took out the FPGA stuff and just generated a similarly-sized array of random U16 numbers. I then ran the array into the same functions used to generate the Digital Waveform Graph. I started the VI last night before I left, and the memory usage was at 4.30GB. When I came in this morning, LabVIEW was showing the "Not enough memory to complete this operation" screen, memory usage was at 6.79GB (8GB system RAM). VI is attached.

Trying to close LabVIEW resulted in the closing of the offending VI, but immediately another blank VI would be created. This repeated endlessly - everytime I closed the newly created blank VI, a new one would pop up. Eventually I used Task Manager to end the LabVIEW process.

[Great_Britton]

Hey,

Thanks for the information, I'm looking into it to, and will pass any information I find on to R&D. If you have any further questions, I'd recommend creating a new thread, since we've moved somewhat outside of the scope of this one. Thanks.

[NickDngc]

I agree that I've hijacked my own thread thoroughly. I do hope there will be updates on the new thread, because we just spent a few thousand dollars to upgrade controllers specifically to run this Acquisition VI only to find an apparent memory leak that prevents us from running the program for more than a few hours...

[Terry_ALE]

I know this is an older thread but was wondering if LabVIEW 64 bit could have been used?