LabVIEW: Memory is full error.

[randomguy77]

I'm working on a VI and I've recently started to get a memory is full error. I am including a subVI that causes the issue. The issue is the reshape array block. When I remove that, the program runs fine, but with it there I get the memory is full error. Is there a way to reshape an array that will use less memory? The input data will be a sine wave with 8192 samples.

[altenbach]

What is the value for # of poles. If you leave that at zero, it will basically try to create an infinitely large array. What are the two values for the dimension inputs of "reshape array"?

(What's the point of "request deallocation"? Seems pointless)

[randomguy77]

The # of poles is the number of periods divided by two. The main vi supplies that value.

For reshaping the array, it will turn each period until it's own array, so that you can graph each period on top of each other. 

The request deallocation was something I added to each subvi, as an attempt to help clear up some memory.

[altenbach]

---

@randomguy77 wrote:

The main vi supplies that value.

---

... but what is the value supplied? (Are you sure the value is still wired? Why is the default zero?)

Can you probe the two dimension size inputs for "reshape array" and report what they are?

[randomguy77]

With what I was using the number or poles was 4 when I was getting the issue. I'm not at work anymore tonight, but I know everything was being passed correctly as I checked before leaving.

[altenbach]

Unless you want to trim or pad while reshaping, the two dimension sizes should be based on the size of the 1D array input and the desired number of rows or columns using simple math. 

[Yamaeda]

A Reshape only changes how the data is interpreted, it shouldn't touch the data, if memory serves, so you're doing something wrong.

(also ~16k of data would need to multiply a about a billion times to fill the memory so it's unreasonable)

/Y

[JonP]

I have run this in LabVIEW using "Sine Wave.vi" to generate the 8k sine wave and with "# of Poles" set to 4. LabVIEW does not show a significant amount of memory used, where "significant" is in the context of a Windows 10 32-bit LabVIEW process … are you by any chance running this on a real-time system like a cRIO?

However the reshape array function does produce a memory full error if I set "# of Poles" to zero. As Altenbach says you should check this value really is non-zero.

[altenbach]

---

@Yamaeda wrote:

A Reshape only changes how the data is interpreted, it shouldn't touch the data,

---

In the distant past, reshape array always showed a buffer allocation, but under some conditions it could probably re-use the buffer. (Back then, the help falsely claimed that it operates in place, but that got removed from the help long ago). Going from 1D to 2D, the size header needs to grow by 4 bytes in memory. Since the function can also be used to pad (or trim) an array, it might need a new allocation, especially if the new dimension sizes are not constants as in this case. (e.g. reshaping a 2D array with 1 element to a 1000x1000 2D array will need room for 1M points).

(I am not claiming that I know the internal details how the compiler handles all that, but it is clear that the data needs to be touched in at least some scenarios)

[Ben]

---

@randomguy77 wrote:

...

The request deallocation was something I added to each subvi, as an attempt to help clear up some memory.

---

Request deallocation only is effective if the VI containing that node is closed. So if you are not invoking the VI dynamically, explicitly opening the VI the VI from its path and hten closing it, that node is "No-OP".

And no we can not cheat and use a static VI ref, to the target VI, since it will be loaded when the VI that contains the static ref is loaded.

Ben