running subVIs 3 different ways - some are incompatible with others... help please?

[zskillz]

I've attached a bit of sample coad to show the problem...  here's what you're looking for:

Buttons 1 and 2  or 1 and 3 can be run at the same time with no problems, but  if you try and execute 2 and 3 at the same time, 3 fails... 

I can't understand why this is, but I'd appreciate any explanation.

In the code, it's important to use the "diagram disable structure" to enable/disable 2 or 3 so that you can see the behavior.

thanks
-z


p.s. - i think that as long as you save the subVI in the same directory, you won't have to change the path, so be aware of that

Message Edited by zskillz on 11-15-2006 10:57 AM

[Evan]

The problem is that you have the VI already running.  Button 2 has the SubVI on the diagram.  So as soon as main runs then the SubVI is running... just waiting to be called.  So calling Run on a Running VI returns the error.

See this Common VI Server Errors

[zskillz]

That's what I was concerned about.... if that's the case, then every time I embed a VI as in button 2, then I assume I'll load all VIs into memory as soon as main is run???  I may not even use some of the embedded subVIs though, so that sort of seems memory inefficient.

Is this just a default setting or can I change it?

this is more out of curiousity then out of necessity.  I like the control that I have using button 3 the most anyway.

-z   

[Evan]

Actually LabVIEW loads the entire Hierarchy at load time.  So as soon as you open a VI all the subVIs are loaded, if they where not all loaded how would LabVIEW know if the VI was broken due to a subVI?

It can be memory inefficient but in all honest I rarely have had the VIs be the problem.  Most Vis are very small in relation to your RAM or the data you are using.  If I am having memory issues its normally huge arrays.

If you are really worried about memory footprint you could create a new SubVI that all it does is dynamically call the other VI.  Then you can place that wherever and the VIs will only be loaded when needed.  This will be a lot slower because now every time you call that SubVI the VIs will be loaded run and then unloaded.

As always you trade speed for memory, you just have to decide which is important.  In this case I am leaning towards speed, like I said VI footprint is generally small.

[zskillz]

That's what I figured.

Anyway, these are subVIs that require user interaction, so I'm not really worried about the small amout of overhead that it takes to load them as in three.

In the end, computers are getting so fast now that I don't really notice much of a difference in either the memory or the speed! --- I can't imagine what we're going to have available in the future!

thanks Evan,

-Z