Markus Krumme writes:

>I have a few arrays consisting of a large number of data points, that shall
>be analyzed in a couple of different sub-VIs. Each of the sub VIs needs a
>transformation of the entire dataset, so that total amount of memory used
>increases everytime one of the subVIs executes. As the analyses shall be
>one at a time, they are located in case structure. Now, as there are about
>30 subVIs, the memory required is tremendous or the length of the arrays
>possible is decreased in the same way. But, as it is only one of the subVIs
>of the case structure running at a time, is there a way to force each of
>them to free up their memory used after execution?

>Thanks in advance & greetings, Markus
>Dr. Markus Krumme
>e-mail: cpire01@mailserv.zdv.uni-tuebingen.de

I have also experienced data memory requirement problems when dealing with
large arrays. The problem is not really the memory usage of subVIs, but the
total number of data buffers that are utilized in processing a large array,
whether in the top level VI or in subVIs. You can determine the data memory
utilized by each VI by checking its Get Info dialog box. LabVIEW determines
how many data buffers are required according to its own set of rules, which can
be fairly difficult for us lowly end users to discern. The data buffers are
NOT released after execution. As far as I know, the only ways to recover the
memory used by the data buffers are to close the VI, compile the VI, or execute
the VI with a zero-length array as input. Since none of these methods is
particularly attractive, the best solution is to recode the VI such that the
number of data buffers required is minimized. In the ideal case, all
operations on a large array can be performed in place so that only one data
buffer is required, plus any additional buffers needed to back up front panel
indicators. National Instruments published at least two technical notes on
minimizing data memory requirements (LabVIEW 2 Technical Notes 012 & 013).

I have done some experimentation to determine how to minimize the number of
data buffers for a situation that is similar to the one you described in your
message. I wrote my experimental VIs in the beta version of LV 3, but I
believe the results apply to LV 2 as well. The top level VI in this experiment
acquired a large array of data. A ring control was used to choose from a
number of alternative operations that could be performed on the data. Each
operation accepted the acquired data array as input and produced an output
array of the same length and data type. The reduced data array was displayed
in an array indicator on the top level VI.

I implemented this application in two ways. In method 1, I used a case
structure in the top level VI, where each case consisted of a single subVI with
an acquired data input and reduced data output. This method required n+1 data
buffers for the array, where n is the number of cases. Each time a different
case was chosen, the amount of data memory required increased just as you
described in your message.

In method 2, I modified each of the data analysis subVIs so that I could
eliminate the case structure from the top level VI. The modification of the
analysis subVIs consisted of adding the analysis method selection ring control
to each subVI. Each subVI then compares the ring control value to its assigned
ID number. If its ID number is selected, the subVI performs its analysis
function and provides the result as its output; if its ID number is not
selected, the subVI passes the input array unchanged to its output. The
analysis operation MUST be implemented in a true/false case structure, where
the other case simply wires the array input tunnel to the output; this allows
the analysis to be performed in place. If you use the SELECT function instead
of a case structure, an extra data buffer will be generated and we will end up
with exactly the same result as in method 1. The top level VI in method 2
simply consists of the data acquisition followed by all of the analysis subVIs
wired in series. Even though all the analysis subVIs are executed every time,
all the operations on the array are performed in place so that only 2 data
buffers (including one for the array indicator) are required regardless of the
number of analysis alternatives. The execution time is about the same as for
method 1, since only one of the analysis subVIs actually does any work.

I hope this information is of some use to you. The results may not be directly
applicable to your situation if your output data arrays are not of the same
type as the acquired data, but you might still be able to do something similar.

Good Luck.

Andy Lowe (alowe@arri.uta.edu)
Automation & Robotics Research Institute
University of Texas at Arlington