Nobody answered my pop quiz!
Pop Quiz: Default data on a front panel control is useful, for example, when the control is on the connector pane, but isn't wired in the caller's diagram. The subVI runs with the default value in that case. When is default data on an indicator useful?
Read more for the answer...
We pass data out of subVIs through its indicators that are on the connector pane. But what if an indicator doesn't receive any data while the subVI runs? In that case, we use the indicator's default data and pass that out to the caller.
A picture helps. Here are the two frames of a case structure...
This is an example of a conditional indicator. The indicator is only updated in one frame. If the VI never executes that frame, no data ever reaches the terminal for the indicator. When the indicator's data is passed out of the connector pane, the default data for the indicator is used in that case.
So in the example above, I made the default data for "My Conditional Indicator" the value 456. I put the "Case?" Boolean and the "My Conditional Indicator" on the connector pane and saved the VI. In the calling VI, if I pass True, I get the result "123". If I pass False, I get "456". Make sense?
Why did I bring this up in a posting about performance? Because it affects memory usage. LabVIEW has to account for two different ways that a conditional indicator can be updated (through a wire or by copying the default data). This interferes with the in-place algorithm and means that LabVIEW can't be as efficient with memory usage.
Conditional indicators aren't typically needed. I could have achieved the same effect with the following diagram...
(Or, for simple things like this, I could have used the Select function.
So, you might want to look at your own code for places you are using conditional indicators to see if you can improve your memory usage. I wouldn't worry much about scalars and other small data, but if you have large arrays or strings, this can make a difference.
3 comments:
It's also ambiguous and a potential source for bugs, so the "terminal on the root" method is definitely better.
The one place where the default data for an indicator is useful is when you have typedef clusters. You can create a VI which will return the default cluster so that the cluster itself does not mess up the caller's diagram.
In C, this would generate a warning that an output parameter is not initialized during a code path.
Should LabVIEW consider such "compiler warning" to help people make better code?
Excellent point. LabVIEW has warnings, and perhaps this should be added to the list of things that we warn about.
And then I reconsidered... LabVIEW warnings are off by default, and don't seem to be that useful when they're on. There just aren't that many interesting things that we warn about.
In C, this kind of stuff used to be handled by a utility called "lint". Over the years, the more thorough code analysis has been pulled into the various C compilers.
That made me think of the VI Analyzer Toolkit. This tool can do a much more thorough code analysis.
And sure enough, it includes a test for "Wired Terminals in Subdiagrams". Here's what it does...
"Checks to see if any control or indicator that is wired on the connector pane does not reside within the top-level diagram. In order to avoid unnecessary memory copies, control and indicator terminals that are wired on the connector pane should be placed on the top-level diagram."
So the good news is that users of the VI Analyzer have this test available right now.
If you don't have the VI Analyzer, I recommend it. It can save you a lot of time, and it will teach you some good programming practices along the way.
For those of you developing instrument drivers, we also have an additional set of VI Analyzer tests just for you. A free download from IDNet.
Going back to the original request, I think we should still consider making this a LabVIEW warning without needing the VI Analyzer. I also think we should put in some effort to make warnings more useful overall.
Comments?
Post a Comment