How can I free RAM after running labview vi

[jam8c7]

 I am trying to acquire 7 channels of data for 60 secs at 44100 Hz using a PCI-6259 card and LabVIEW.  I am using the DAQmx Read polymorphic vi to acquire the data and the 'Write to Spreadsheet File' VI to write it.  When I run the program for the first time, it will acquire and write the data, however when I try to run the program again it says the memory is full when it tries to write the data.  I can close the program and reopen it and it will acquire and write the first time I run the program again, but it will not write the data the second time I try to run it.  I have 3GB of RAM on a Windows XP system.  The data is being acquired as a 2D DBL array and is creating an array that is 2646000x7.  Can someone explain how I might clear the memory without having to exit and reopen the program?  I would also like to increase my sampling frequency to get better resolution. 

[unclebump]

Take a look at these threads.

http://sine.ni.com/apps/utf8/niepd_web_display.display_epd4?p_guid=0D91084DF54857D7E0440003BA7CCD71

http://sine.ni.com/apps/utf8/niepd_web_display.display_epd4?p_guid=B45EACE3F12556A4E034080020E74861

http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=BDBC351349C011AAE034080020E74861&p_...

http://sine.ni.com/apps/utf8/niepd_web_display.display_epd4?p_guid=BD3FE826C91D23FAE034080020E74861

Do you really have to save DBL data?? could you change it to I32 or smaller?

[kehander]

I was just wondering about this as well, actually. My program also uses the Write to Spreadsheet file VI, and while most of my arrays are a lot smaller than 2646000x7, problems seem to crop up after repeated executions.

Direct streaming to disk seems a little unnecessary with my small arrays, but do the alternatives end up using too much unreclaimable RAM?

[AnalogKid2DigitalMan]

If you have a sub-vi that consumes a lot of memory, you could try request deallocation vi:

Deallocates unused memory after the VI that contains this function runs. When a top-level VI calls a subVI, LabVIEW allocates a data space of memory in which that subVI runs. When the subVI finishes running, LabVIEW does not deallocate the data space until the top-level VI finishes running or until the entire application stops, which can result in out-of-memory conditions and degradation of performance. Place the Request Deallocation function in the subVI you want to deallocate memory for. When you set the flag Boolean input to TRUE, LabVIEW reduces memory usage by deallocating the data space for the subVI.

[kehander]

But that VI would only seem to be useful for a VI that is running continuously. My application (and presumably Mr. jam8c7's) does get stopped entirely, and according to your description LabVIEW should deallocate the data space and run in precisely the same manner the next time it is executed. Yet this is not the case.

[Dennis_Knutson]

Not necessarily. Do you have an unitialized shift register in your program that is holding the data?

[kehander]

Actually, I believe I do...

So does that mean that repeatedly stopping and starting a VI that contains uninitialized shift registers will consume memory irrecoverably?

[Dennis_Knutson]

Yes. The fact that an unitialized shift register retains the last value until unloaded completely is actually the basis of something called a LabVIEW 2 style global variable. Using this type of global can have benefits beyond what the native global variable provides.

[kehander]

I see. Well, aside from initializing the shift registers at the start of the program's execution, is there no way to free the memory from an uninitialized shift register that does not involve shutting down LabVIEW?

[johnsold]

Yes. Write an empty array to the shift register when you are competely finished with the old array. Changing the size of an array causes reallocation of the memory for the array. When you are putting data into an array it is much more efficient to pre-allocate the space by using Initialize Array and then Replace Array Subset to put the data into it. That way only one allocation per run is required. This assumes that you know or can estimate the maximum size of the array for each run.

Lynn