How does the operating system manage labview vi's

[Timmar]

Background:

I am using compact field points and low end compact rio's for my projects and I am approaching the RAM limits of my devices.

I am looking to modify my coding practices to minimize RAM usage.

I follow the "Labview 101" do's and don't for optimised code but I need more information about how the VI's are handled in memory.

My background is in embedded C coding where when a function is called the code is run from ROM and uses memory from the stack, releasing it on completion.

My observations (best quess) from my cFP application is that all vi's are unpacked (decompressed) into RAM (takes 5-10 minutes) and executed is from there.  Each .VI keeps it's memory.

My application uses quite a lot of code reading configurations at the start, never to be used again.  I am speculating that this resides in RAM until the end of time.

If this is the case, is there a method to release the unwanted VI from memory.

To minimise RAM usage I tend to use In Place structures and wire data in and out of VI's using it.

Attached code snippet show data from an object being passed through a sub .VI.

I want to be sure that additional RAM isn't being used here,  If so I will need to do the manipulation directly to the object.

[Eric-E]

I think if you use Close VI to close the refference to the configuration file, the memory should be free from then on.

[Timmar]

Was more interested in the the rest of the vi's memory and code.

[tst]

If you want a VI to fully off-loaded, then load and run it dynamically (using Open VI Reference with a path) and when it's done running and you close the reference, it should unload completely. That said, I have no real experience with memory management on RT. I understand it is relatively sensitive and doesn't like reallocations of memory and such, but I'm assuming if it's only done once it won't be as bad.

Note that if you do this, you will need to get the VIs compiled and on the target somehow. I would assume that including the top level dynamic VI in the build settings should help, but then you will need to find the path to it and I'm not sure if .rtexe behaves the same as a regular EXE in that sense (if it does, I would suggest placing a VI in the same folder as your top level dynamic VI and using that to get the path of the VI).

[Timmar]

thanks tst,  Not sure how labview classes handle being loaded dynamicaly,  sounds like 7 ayers of heck to debug. 

If I know for sure that they are going to stay in memory I will change how i use variables and other thinks like inline or subroutine (I need to find out about this also)

iTm.

[Yamaeda]

There's a request deallocation node, but i have no idea of it works in this case.

[tst]

Loading classes dynamically is super easy - load anything in the class and the entire class (as well as all its ancestors) will load. One problem you might have is that as far as I know LV doesn't have any way of unloading classes, but that's incidental knowledge and might not apply to RT.

What I would suggest is that you look specifically for material about program architecture and memory management in RT, as that's a very specific area. There are all kinds of documents around and I believe NI also has some webcasts and courses on this.

[Timmar]

I seem to have terrible luck finding these mythical white papers/KB articles.

My searches yield nothing and some kind soles on this froum point me to a couple revealing all.

Would be great to find someone who knows where I can start my quest.

To date, I haven't found much documentation about what goes on behind the labview curtain.

[tst]

This seems pretty specific, and it took about a minute to find - http://www.ni.com/white-paper/4430/en

Since you also seem to want to know about LVOOP, you will probably want to look at this - http://www.ni.com/white-paper/3574/en

Try using the terms real time, RT, memory, architecture, etc.

[Timmar]

tst,

Thanks for the links.

The array allocation is a bit of an eye opener, I will think carefully about how I use arrays.

I have seen the OOP one before, re-reading it was helpful.

I found a few hints about default data.

It does illude to once all vi's (not dynamicaly loaded) are loaded into memory and stay there, required or not.

In the case of dynamic allocation, this makes sense for a transient object, in my case the objects hand aroung, about half of the methods are only called at startup, Squatting on memory without further need.

I can think of an ugly workaround where a "Read Config" VI is dynamicaly loaded, Hands off it's data to a more permanent object before being dumped.

I would like to know more about the deallocate memory VI, Does it Dump RAM and Program or just RAM?

Does it apply to LVOOP Methods?