Memory Overflowing

[QU-1]

Hello together!

I am currently working on a nasty memory problem that keeps filling up my working memory.

I think I have narrowed the problem down to the size of one array in my subVI (see attached picture).

If the size of this array increases the memory overflow problem increases as well (MB per subVI run).

The working structure is the following:

In my main VI an array of "Waveform Descriptions" is created and sent to the subVI. This VI than translates the array into a different array that is than sent to a device. The red-marked subVI in the picture is creating an array that can contain >100000 datapoints. This procedure is called repeatedly about every 10 seconds.

During these iterations the memory, Labview is using, increases every step until it overflows. Since the subVI is always called again and should not save any data, I don't know why this memory is increasing.

I also attached a picture where I monitored the memory usage as suggested by NI.

I tried so far to put Request Deallocation functions at the end of the subVI and Close References at the .net references. But that did not solve the problem.

 

If anybody has any suggestions what I can try to resolve this problem I would be very happy. Thanks!

[altenbach]

That inner loop should be a FOR loop, because you know the number of iterations before the loop starts (use the conditional terinal to stop early on error).

How big does that array get you are building?

If you suspect the subvi, why don't you show that code? Please do.

[QU-1]

I have attached the marked subVI from the sequence. This generates a DBL array with >100000 elements.

As described in my first post, if I reduce the size by generating fewer elements in this array, the problem of the memory overflow decreases as well.

[ConnerP]

I suspect Insert Into Array is acting like Build Array and getting stuck allocating a new buffer each iteration. Change this highlighted part to be auto-indexing. More performant and looks nicer:

[crossrulz]

---

@ConnerP wrote:

I suspect Insert Into Array is acting like Build Array

---

Not just a suspicion.  It IS acting just like a Build Array and should be replaced with a concatenating output tunnel; an Autoindexing will build a 2D array, which appears to be not desired.

And the same issue lies in the outer loop as well.

[ConnerP]

---

@crossrulz wrote:

---

@ConnerP wrote:

I suspect Insert Into Array is acting like Build Array

---

Not just a suspicion.  It IS acting just like a Build Array and should be replaced with a concatenating output tunnel; an Autoindexing will build a 2D array, which appears to be not desired.

And the same issue lies in the outer loop as well.

---

Ah yea right on both accounts. Good catch.

[QU-1]

First of all, thanks for all the answers so far!

Since many answers were hinting towards the Insert into Array part, I removed this from the VI, since that part was for display information only.

Sadly that did not resolve the problem. Therefore I tried to simplify everything into one VI that I attach here.

Now the simple oberservation is that this VI runs fine if called once on its own.

BUT if it is called by an event Structure (for example as a SubVI to my main VI) it keeps allocating memory.

As observed from the Task Manager (pivate working set) of Labview.exe

I am guessing that the VI itself does somehow not exit cleanly even if it has run and performed all operations.

If somebody could look into this I would be very grateful. And sorry that the VI is not programmed very elegantly.

[crossrulz]

Stop using a property node to set values.  That is HORRIBLY inefficient (as in THOUSANDS of times slower than a local variable) since it forces a panel redraw and a context switch to the UI thread.  Propagate your error cluster and chain things along.  If a previous step had an error, you likely don't want to continue anyways.  You can also use the Unbundle By Name and Bundle By Name to add information to the "Source" string of the error cluster, which will eliminate one of your indicators.

Also, when you get rid of the property nodes, the VI will be able to run without having to load the front panel, which will save memory and potential leaks.

Also beware of passing references through FOR loops.  If something happens and the loop is set to run 0 times, you will lose your reference.  The solution is to use Shift Registers for your references instead of tunnels.

[Intaris]

I see a "Waveformstruct" object being instantiated each time the loop runs I think .....

I don't think this is being destroyed when you close the reference to the ABC Channel thingy.....

Maybe you're accumulating lots of these in memory.  Try either reusing the same one over and over or at least destroy it after it has been used.

No idea if this is helpful, but that occurs to me on the first view.

[QU-1]

Thanks for the further answers.

Right now I don't know how to easily get rid of the property nodes, which is possibly because of my lack of experience. But I will try to work this out.

I forgot to mention that the problem of memory overflow still scales with the created array I have marked in the attached picture. If this array has more datapoints the memory increase is also larger. The SubVI with the question mark is the SubVI that I have attached in the beginning of this thread.

The remark with the "Waveformstruct" object is interesting. Do I just put a close reference behind the property node to destroy this?