11-22-2019 07:35 AM
Hi,
I recently started to give it some use to the VI Analyzer, and there's a few things I'm not sure about it (Some of the warnings).
Most of the warnings i understand them but I'm not sure how to improve the code in order to get ride of it, or if it would affect my code somehow. I'll appreciate if anyone could give some insights on this.
1) The two most common Warnings i get on the VIs i have built are:
Controls and Indicators:
-This VI contains 31 indicator(s), which is more than the user-specified maximum number (24).
2) Fan Out
-This VI has a Fan Out of 18, which is more than the user-specified maximum number (10).
For the first one i believe it's the amount of indicators i have in the front panel, correct? and the second one is how many SubVIs I have.
My question is the following: can i ignore those warnings or is it something i should work on? I noticed that the whenever i reduced the amount of SubVIs the Fan Out goes away but then i get the Cyclomatic complexity....it's kind of annoying not to be able to reduce the number of warnings to 0 lol
Anyway any good explanation will be highly appreciate it,
Thanks!
Solved! Go to Solution.
11-22-2019 11:14 AM
This link should help you understand what they mean. The first warning tells me that you should spend more time understanding LabVIEW best practices. You should really NEVER have this warning.
11-22-2019 12:11 PM
The # of indicators warning probably should distinguish between top-level and subvi.
Still, reducing the number of indicators is often trivial. Use clusters and arrays instead of scalars. Show the digital display for gauges, charts, etc instead of a separate scalar, ...
11-22-2019 12:21 PM
@altenbach wrote:
The # of indicators warning probably should distinguish between top-level and subvi.
Still, reducing the number of indicators is often trivial. Use clusters and arrays instead of scalars. Show the digital display for gauges, charts, etc instead of a separate scalar, ...
I thought about editing my response to include what you said about top-level VIs, but the OP stated this was one of the most common ones. That's scary.
11-27-2019 09:11 AM
Thanks, I still have so much to learn on LabVIEW....but I have a better idea what to research and try to understand better, I'm not sure the difference between Top-level and SubVI, but thanks for redirecting me in a good direction.
11-27-2019 11:15 AM
@dreamheart wrote:
Thanks, I still have so much to learn on LabVIEW....but I have a better idea what to research and try to understand better, I'm not sure the difference between Top-level and SubVI, but thanks for redirecting me in a good direction.
Top level is the VI that contains all the other VIs. "All the other VIs" are your subVIs. Sometimes it's unavoidable to have your top level VI have a whole bunch of controls and indicators because you have so many things to control or monitor (or both). But if you're a good organizer, you can place related controls or indicators (but not a mix) into meaningful clusters. This is roughly analogous to having a keyboard and a mouse instead of 104 separate switches (keys), a trackball, and two buttons on your desk.
11-27-2019 11:39 AM - edited 11-27-2019 11:41 AM
@dreamheart wrote:
I'm not sure the difference between Top-level and SubVI, but thanks for redirecting me in a good direction.
There is only a functional difference, i.e. how you are using it.
Toplevel VI: This will also be the startup VI of the application that the user sees and interacts. A toplevel VI typically has no assignments in the connector pane. You typically run this and the subVIs (dependencies) will automatically follow. The toplevel VI runs for the duration of the session.
SubVI: A VI that is called by other VIs, often with the front panel invisible. Typically there are connectors assigned (but there are of course exceptions possible). You only run subVIs standalone during functional debugging and testing.
Historically, NI had a mechanism to assign a VI toplevel status inside llbs, but nobody really uses llbs anymore and you should not either ;). Promoting a VI to toplevel status is no longer an option (?) in more modern containers (e.g. lvlib, lvproj) and it's not really needed.
11-27-2019 11:50 AM - edited 11-27-2019 11:53 AM
The reason subVIs shouldn't have so many controls and indicators is because subVIs are generally not intended to be interacted with; the number of controls and indicators are generally governed by the amount of connectors available on the connector pane. You may need more controls and indicators than your subVI connector pane can handle, but again, careful organization of related wires into clusters helps. Again, using a computer analogy, imagine that, instead of having one connector each for your mouse and one for your keyboard, you had over 100 separate wires going to your computer. Now we have the physical equivalent of spaghetti code - and all of the inconveniences and inefficiencies of this situation applies directly to LabVIEW code as well. Imagine having to trace over 100 separate wires just to change out your keyboard.
Which brings me to my next point: why being "neat" with your code makes a difference. You might think it's just for looks because the compiler doesn't care how many bends a wire has, or whether it goes behind objects which, to a human, looks like it goes into and out of said object. But think about having that attitude coding in a text-based language. You have random indents because it doesn't matter to the compiler. Try saying that to the developer who needs to work with your code. If they wanted to go and strangle you, I'd just ask them what time they were planning on doing it so I can go to lunch then.
Last point: the need for subVIs. I have no idea why the most disciplined C programmer puts most of their code into functions, yet they cram all their LabVIEW code into one uber-VI. You wouldn't put all your C code in main(), would you? Apply common sense. Group related code into subVIs. Ideally, a subVI has one purpose, just like a function in a text-based language; in the real world, try to limit the functions contained within a subVI - you don't want an "uber-subVI" just like you don't want a top level "uber-VI".
Hope this helps.
12-05-2019 10:31 AM
Wow, Thanks so much, i feel much better now that i clearly understand it. I couldn't have asked for a better explanation 🙂 Thanks all of the people that replied as well. It's true that since i come from a text base programming world, LabVIEW can be challenging, but thanks again for all the great advise.