Provide an option to call a sub VI dynamically

[CaseyM]

When you drop a VI on the block diagram it's becomes statically linked to the calling VI. If instead you wanted to call the same VI dynamically (without creating an edit-time dependency by using a Static VI Reference) you'd have to change the code to, instead, open the sub VI's ref by path, create a type specifier and then wire the reference to a Call by Reference node.

Why not instead just provide the option to call a given sub VI dynamically by right clicking on the sub VI itself? I'm picturing a right-click menu that has two options:

• Static Call (default)
• Dynamic Call

If "Dynamic Call" were selected, all the steps to convert the call to dynamic would be handled would be handled by the IDE/compiler without the developer having to actively modify the block diagram. The IDE has 90% the information to make this happen, right? And the missing information could be provided by an options dialog if necessary (e.g. synchronous vs asynchronous call, run as sub VI vs top-level).

There should probably be some sort of visual indicator on the BD that the sub VI is being called statically vs dynamically.

[wiebe@CARYA]

You mean like when you right click the VI and select "Call Setup..."?

[AristosQueue (NI)]

Already exists since at least LV5.0. Right-click on the subVI call and select "Call Setup..." There are three configuration options.

[Darren]

Already available with the subVI "Call Setup" options.

[CaseyM]

Already exists since at least LV5.0. Right-click on the subVI call and select "Call Setup..." There are three configuration options.

---

Yeah, but that method still loads the sub VI and all of its dependencies into memory since there's a static VI reference to the sub VI in question in all of the outputs from that operation. I'd like to avoid that (at least after the initial setup).

The key part of my original post, which I probably should have highlighted, was the "without creating an edit-time dependency" part.

[AristosQueue (NI)]

It only loads the subVI if you open the block diagram. Keep the block diagram closed. Not having any edit-time dependency is meaningless: there is, by definition, some edit-time dependency.

[AristosQueue (NI)]

If it is a significant issue for you, you could wrap the dynamic subVI call in a wrapper VI and then call that, so when you open your real top-level diagram, the only thing that loads is the wrapper VI.

[CaseyM]

It only loads the subVI if you open the block diagram. Keep the block diagram closed. Not having any edit-time dependency is meaningless: there is, by definition, some edit-time dependency.

---

Maybe my terminology is wrong so let me try to clarify.

If I put this on the block diagram...

... the list of dependencies in my project gets filled with not only the VI itself, but the library that contains that member VI as well as any other members of that library and their dependencies, etc. etc.

By contrast, if I put this on the block diagram...

Absolutely nothing gets added to my project dependencies during edit time. This is important to me because in dealing with large projects or libraries (either my own or the one I'm calling) the IDE can start to crawl (especially when a project is first loaded).

I'm asking for is the option to go between one of the first three call setup options to this last one quickly and easily (i.e. with a couple clicks vs writing new code).

[AristosQueue (NI)]

Oh. So your problem is not dynamic loading. Your problem is IDE speed.

Mine too. 🙂 First I'll respond to this specific idea, but after that, I've got some points about IDE speed that you may like.

Now I get what you're asking for in this feature. I will ask Darren to re-open the idea so it can garner more kudos, but, honestly, I doubt we would even consider doing this request. There are other, higher priority features, but if it garnered enough kudos, we would look into it. The good-ish news is that this is the kind of transform -- from subVI into the dynamic notation -- that can be done through scripting, if you want to build your own right-click plugin to to that. I know: you asking for a bed and me saying "make it yourself!" isn't what you want to hear, but I try to be honest in managing expectations for the Idea Exchange.

Now, as far as the IDE performance...

LabVIEW 2019 made a dent in load speed... LabVIEW 2020 will provide even more relief for load, as well as unload, save, and compile performance. Various other IDE operations pick up speed along the way. These have been under a lot of focus for the last couple dev cycles. How much any particular project gains varies greatly, but all should see improvement. I hope you're able to upgrade when 2020 comes out shortly.

Please enable source-only setting on ALL of your libraries and VIs. If I had my way, it would just be on permanently for every file always, but there's some TestStand use cases that prevent that. But with source only, yes, there's a hit when you first load a project on a machine, but after that, things get lots faster. Every file you flip over makes the IDE that much faster for a wide range of operations. And when everything in a project is source-only, we are able to skip a lot of steps during the unload process.

[Darren]

Idea re-opened based on feedback in the idea discussion thread

[CaseyM]

The good-ish news is that this is the kind of transform -- from subVI into the dynamic notation -- that can be done through scripting, if you want to build your own right-click plugin to to that.

---

Yeah, I had considered that but wanted to see how many others might be in the same boat. Fingers crossed.

LabVIEW 2019 made a dent in load speed... LabVIEW 2020 will provide even more relief for load, as well as unload, save, and compile performance.

---

I was aware of the improvement in compile performance coming in 2020 (I was one of the ones really pushing for this at the CLA Summit), but I didn't know that any of that carried over to the other aspects of IDE performance.

I'll definitely be looking to upgrade when it arrives.