New property of Method to indicate, if an input of a sub-VI is connected to some source inside the calling VI

[Marc Blumentritt]

If you write a multi-purpose sub-VI, it is sometimes desirable to know during run-time, if an input of the sub-VI is connected to some source inside the calling VI or not. E.g. if you have two inputs and you want to do a certain action whichs depends on which input is connected, you have to write a polymorphic VI. Therefore you have to write at least 3 VIs: one VI for each input and the polymorphic VI. With a new control property or method, which tells you if the input got it's data from some source, you could do this with just one VI. There are of course other scenarios where this new feature could be useful.

Regards,

Marc

[JackDunaway]

One common solution to this is to define a null or invalid value and set it as the default for those input connectors. Then, inside the subVI, you can determine whether the input was wired by comparing the input to that null or invalid value. Another common solution is to have an additional enum input called "Action" or "Method" that defines what to do inside the subVI (e.g., Action Engine). Can you describe a specific scenario where neither method suffices?

[Intaris]

Can you give me an example of null U8?

[JackDunaway]

It depends on what data you interpret as valid in your application. Maybe 0 is invalid, maybe 255 is invalid, or any number in between. It's possible, however, that every value is a valid value and you cannot determine what is "invalid" (think Booleans!). In this case, the "Action" or "Method" route is necessary as the discriminator when there's ambiguity in the range of a "null" value.

[AristosQueue (NI)]

Users have three existing options to solve this problem:

1) A sentinel value (as described by mechelecengr above)

2) If all the values in your range are valid values, create a cluster of the u8 and a boolean and use the boolean as the sentinel value.

3) Create a poly VI that has a junk type (perhaps boolean) on the first implementation listed in the polyVI and and the desired type (u8 in your example) on the other implementation. If the u8 is wired, LV will call the version where it is assumed the input is wired. Otherwise it will call the other, which is written to assume the input is not wired, which may be way more efficient because the runtime system doesn't even have to test anything.

Your request for this "is wired" property is a feature that I explicitly asked for early in my time in R&D. I learned that it is a bad idea because pretty much any proposed solution that we could do in the LV compiler would be LESS efficient than what a user could code on the diagram. To begin with, the Invoke node itself causes the FP to be loaded into memory in order to have anything to reference. That slows the execution of a subVI considerably right there. More, because we wouldn't know whether a given terminal would necessarily be asked for its "is wired" status, and because there is no block diagram for VIs in the runtime engine, every caller VI would have to compile into itself information about whether or not optional terminals were wired.

We can do various things like say "this method can only be selected on an implicitly linked Invoke node", which lets us flag callers of subVIs that they need to compile in "wired or not" records into themselves for particular subVI terminals. But that creates problems for Call By Reference nodes since something that had the "this terminal will be tested for 'is wired'" would have a different conpane signature from an otherwise identical conpane that did not test for "is wired". 

In the end, this request is not really supportable by subVIs. Built-in functions can do it because they generate all of their code into the caller VI. Even if we someday have inline subVIs, this would require special code that told LV which portions of a diagram to inline based on whether or not a given terminal was wired -- probably a new structure node or something like that. 

So, short story:

Yes, this has been contemplated extensively by R&D over the years.

No, we're not likely to do anything to implement this feature or anything similar to it. 

[tst]

At least we finally have a real answer.

[Marc Blumentritt]

Thanks for your answer, Aristos Queue. I didn't thought, that this would be so complicated.

[G-Money]

Adding this functionality could result in negative performance of the LabVIEW compiler for other VIs.

[drjdpowell]

 Question: could this be done in the context of a VIM Malleable VI?   The reasons given apply only to non-inlined VIs, where the "is connected" question can vary with call site.  This idea would be quite useful for VIMs.