unload vi from memory

[altenbach]

A VI loaded in memory doesn't cost much, unless it allocates huge amounts of memory for data structures. If you are confident that the subVI is only called once to process large amounts of data, you can place a "request deallocation" node on its diagram.
 
<a href="http://zone.ni.com/reference/en-XX/help/371361D-01/glang/request_dealloc/" target="_blank">http://zone.ni.com/reference/en-XX/help/371361D-01/glang/request_dealloc/</a>
&nbsp;
Now the allocated memory for data will get deallocated when the VI has finished its job. Of course this also means that if yo call it again later, it again needs to reallocate memory, so things can get expensive very quickly if you constantly shuffle memory around. In a typical scenario, a subVI is called repeatedly and often with similar amounts of data, so it makes sense that it can retain the allocated&nbsp;data structures between calls.
&nbsp;
Can you explain your concerns&nbsp;in more details? What problem are you trying to solve?
&nbsp;
If you are running in the development system, You can also make code run a little bit leaner by disabling debugging, for example.
&nbsp;
If you are worried about memory use, it helps to optimized the code to limit the number of duplicate data copies im memory. This can often be achieved by limiting the use of local variables, doing operations on large arrays "in place", don't&nbsp;constantly resize arrays (e.g. don't overuse built array, insert into array, delete from array), keep the FP of non-interactive subVIs closed, and so on. Feel free to post some of your subVIs if you think this could be part of the problem.
&nbsp;
See also the article on VI memory usage:
<a href="http://zone.ni.com/reference/en-XX/help/371361D-01/lvconcepts/vi_memory_usage/" target="_blank">http://zone.ni.com/reference/en-XX/help/371361D-01/lvconcepts/vi_memory_usage/</a>

[altenbach]

I usually point to the newest help, because it&nbsp;sometimes is written more clearly and contains more detail. Yes, this function should be available in 7.0.
&nbsp;
There ae very few cases where&nbsp;"request deallocation"&nbsp;is beneficial, so don't over-use it. You still haven't really told us what problem you are trying to solve. :)

[tonitpp]

Hi again,I attach here the files generated.Remove the .txt extension of all the files except manifest.txt. I do this because it don't let me to send them with their original extensions.Sorry.ToNi.


sysdata.xml.txt:
http://forums.ni.com/attachments/ni/170/272247/1/sysdata.xml.txt


manifest.txt:
http://forums.ni.com/attachments/ni/170/272247/2/manifest.txt


Mini091407-01.dmp.txt:
http://forums.ni.com/attachments/ni/170/272247/3/Mini091407-01.dmp.txt

[altenbach]

I have no tools to analyze these problems from the provided data.
Have you tried to just look at the memory use via task manager every couple of hours (before it crashes!) and see if it increases over time.
For example, if you are building infinite arrays in shift registers or constantly create references without ever closing them, "request deallocation" won't help you at all. It cannot deallocate what you still have in use.
Please show us your LabVIEW code instead&nbsp;so we can point out potential problem areas.

[tonitpp]

Hi,

Yes, I have checked it with task manager from Windows and memory usage
increases over time but I think it must stop increasing at any point of
time. I think memory usage increases because from a VI I update the
charts (Oxygen, temperature, pH and RedOx) every x minutes. The chart
history length I use is 28800 waveforms. First of all, when the chart
history length is empty memory usage is low but it increases when the
chart history lenght increases because of I add a data point to it.
Also I suppose that when the chart history length reaches 28800 data
points of length it doesn't increase any more, it keeps its length
forever and LV replace old points of the chart history with new ones.
At this point, I think the memory usage is the maximum and then the
memory usage don't have to increase more because it has reached the
maximum length of the chart history.

I close all the references that I open previously and initially empty the arrays that I build in shift registers.

My application consists of a huge amount of VI's and it is not possible
to attach all them here and I am not allowed to attach here because it
is confidential. I hope you understand me. Despite of all I attach you
an image to show you how I update the data in the chart. I remember you
that the chart history length is 28800 data points. As you can see in
the picture I have a global variable (the reference to the chart) and I
update the chart with a pair of timestamp and a value. The VI that
contains the chart is always opened but hidden. It is shown when the
user presses a button from another VI.

Thanks,

ToNi.


updateChart.JPG:
Loading Image...

[altenbach]

If the points are equally spaced in time, maybe you want to use plain scalar data on your chart instead of waveforms and set x0 and dx once at the beginning. I could imagine that all these timestamps would create much more overhead for the code.
I never use it that way, so I am not sure what it does internally.
Do you really need to update the chart via a property node? This also causes more overhead.

[tonitpp]

Hi,It is difficult to explain here but my problem is that my application after running a few days it crashes and Windows shows the following message errors that I attach here.Then, I don't know if it is a problem caused by memory, because my application use a huge amount of RAM memory. The RAM memory usage increases and I don't know if become more than the available in the system and then maybe it crashes because of it . Then I want to check if this problem is caused by memory usage so I want to do what I mentioned in the following link:http://forums.ni.com/ni/board/message?board.id=170&amp;message.id=271931#M271931Why do I want to do this? because my application is running in a wastewater treatment plant and nobody is there monitoring this and seeing if my application works well, my application makes all the work for them: monitoring etc... and then when my application crashes nobody is there to see what happened and what was the status of my application before it crashed. So if I store the information that I mentioned in the link above, I'll be able to check the information stored about CPU usage, Memory usage, and maybe then I'll be able to see if the problem is caused by a huge amount of memory usage.Thanks,ToNi.


error31.JPG:
Loading Image...


error4.JPG:
Loading Image...


error21.JPG:
Loading Image...