"Function terminal not connected" detection (plus shameless plug for another pet-peeve of mine)

[X.]

Must have been discussed a zillion times, but just in case, there it goes:

what's wrong with this picture?

apparently nothing. If I grab the function and move it:

Note that LV must have "computed" something here to reroute the wires, etc.

But wait, what happens if I grab the wire and move it?

Oops! I did not connect the output of the function to the indicator. Instead, I inadvertently connected the input.

Needless to say, this is a F-ing nightmare to debug... unless you think of verifying that the value before the function and after the function actually gets incremented. Which you will, eventually, but not until after having wasted a lot of time thinking of all other possibilities elsewhere in the code.

Bottom line (this is only an example I just encountered for the umpteenth time a minute ago), LV does not provide much in terms of warning for this kind of potentially very damaging error. This is very much related to the discussion I started here with very limited success (man, am I an upbeat person!). 

Suggestion: not only allow to define VI outputs as REQUIRED but also add warnings when a function that has its only or most important output(s) unconnected.

And if not everybody is interested in this kind of sanity check (I am talking about functions), you could offer this "warning" as an option (in a warning definition panel in the Preferences).

[Darren]

The actual VI Analyzer test name is "Unused Code".  Here are the things it detects:

• Function with unwired outputs. Note that it ignores functions that perform actual work despite their unwired outputs (like "Wait")
• Case Structure with a constant wired to its selector terminal
• Unwired Constants
• Wires that flow through structures unused
• Unwired output tunnels on structures

You can selectively enable any combination of these options in the test configuration.

[JÞB]

And, Wires behind objects catches the example as well

[Darren]

Yes, I've given many presentations over the years in which I show all the great ways the VI Analyzer Toolkit can detect "gotchas" in your code that would otherwise take hours (days?) to discover.  Unused Code and Wires Under Objects always make an appearance. 😉

[X.]

Any chance that you can add "unconnected" VIs outputs (although that's not exactly what I am suggesting, that may play the role of temporary workaround)?

I suppose limiting it to user-developed VIs or some subsets of all VIs, may help avoiding having a zillion VIs showing up in the list... 

[Darren]

I think a test that returns a failure for unwired subVI outputs would return way too many false failures.  I don't know of a robust way to return meaningful results from such a test.

[X.]

Glad you agree with that 🙂

[X.]

First sign of early Alzheimer? I duplicated this idea here (although I may have expressed it slightly differently and did change the illustration).

I distinctly remember the VI Analyzer discussion with Darren, but could not figure out where to find it....

[X.]

Here is an older iteration of this request.

I also found this interesting XControl example in which one of the diagrams shows this:

See the "Do not leave this terminal unwired" comment? It means "output connector" obviously, and since the VI is part of a project published here, I gather this is NI's stuff...

[AristosQueue (NI)]

I support the idea of required outputs, X, but the image you just posted is another example of a required *input*.  That comment is there to remind the VI author to wire the FPTerminal -- it comes from the template for an XControl method; the comment should have been deleted by the person who filled in the template. 🙂 

A bit of update on this: required outputs stir up a lot of frustration/anger from various parties. There's a pretty complete post of their objections written by Darin.K on the forums from a couple months ago (sorry, I don't have the link close at hand). A lot of folks believe that this should be covered by VI Analyzer and only by VI Analyzer. Within R&D, although I've made a bit of traction with the argument that it should be possible to put it as an option on VIs that user's write, adding it to any of the commonly used primitives seems like a no-go. I continue to bring it up when it is relevant in meetings.

[X.]

OK, I thought it was meant to not forget to connect the output of that VI... My bad.