Why is VI Call Setup grayed out?

[crnbaker]

For some reason I can't access the VI Call Configuration dialog. When I right click on a sub-VI, 'Call Setup' is grayed out from the menu. Any idea why?

[tst]

Pure guess - is it inlined? I would assume that this would mean you can't load it dynamically.

[crnbaker]

No, it's any sub VI. I opened a brand new VI, created a sub VI with just an 'Add' in it (with inlets and outlets), and it's still grayed out.

Also, I just tried it out on another PC and it works fine. Must be something weird with my PC.

[tst · Accepted solution]

It's probably because you didn't save it. The call setup dialog allows you to control when the VI is loaded from disk into memory. If you don't save it, it has to be in memory all the time.

Personally, by the way, I haven't used this dialog even once. Why are you using it?

[crnbaker]

Ha, you're right! Thanks. Here's why I'm using it:

I'm using the MATLAB Script Node. The problem is that there are only 10 floating MATLAB licenses where I work, and if none are available when I load my main VI, then LabVIEW gets stuck in a loop trying to load the subVIs that use MATLAB and then not being able to find a license. So basically I can't edit my LabVIEW code if there are no MATLAB licenses available.

The theory is that if I put all my MATLAB Script Nodes in VIs that only load when called, then I'll be able to edit my LabVIEW code without a MATLAB license available (because the MATLAB subs wont load unless I run the main VI). Then I can build in an option to disable all MATLAB functionality if there are no licences available (just using case structures to make sure MATLAB subs arent called).

Thanks again, sorry about the stupid mistake.

[Halden]

Here's another answer to your question.

I have a program that needs to talk via .dll calls to one of multiple pieces of hardware depending on the system configuration.  Different systems ship with different hardware.   I don't want to distribute the .dll files for the hardware with the system that doesn't use it.  So, by loading the SubVI that talks to the hardware dynamically, the program won't search at startup for the .dll files that it doesn't need.  

Right now I'm trying to do this for another reason - so that the program won't take forever to load when first started.  In the process, I have found a few SubVIs for which the "Call Setup..." is greyed out.  These SubVIs have been saved and I haven't found anything particularly unique about them that would exclude them from dynamic loading.   I found that by clicking on these VIs and then "Create SubVI", I'm able to make a wrapper around the uncompliant SubVI.  The wrapper then permits the "Call Setup..." setting.  I thought I'd post this so that others with the same issue will see this workaround.

Halden