one big vi vs multiple smaller

[nikosfs]

Is it better to develop a program in a single VI, or in multiple VIs that are smaller and have instances of the VIs in the main VI?

Could you please tell me some pros and cons?

Thank you!

[SteveChandler]

Better as in what? Performance, scalability, maintainability?

In general it is better to use subvis. But not just to make the main vi block diagram smaller. The subvis should perform specific functions. If the function of the subvi is complex that subvi can have subvis too.

I guess the only con to modularization is that you need to create descriptive filenames and a sensible directory structure. If you put everything into one vi then you don't have to worry about which vi is the top level vi, there are no cross linking issues or dependencies to worry about. But the project manager helps with that.

[nikosfs]

And what about performance, if a single big VI is used?

[smercurio_fc · Accepted solution]

The benefits of a modularized architecture far outweigh any benefits you could gain (if any) out of a single, monolithic VI. Think about. With a single monolithic VI you have something that's going to be large to manage, and require a lot of screen real estate just for the coding. This paradigm is not limited to LabVIEW, as it applies to any programming environment.

[Mark_Yedinak]

A single, large VI (or single procedure in a text based language) is a very poor way of doing things. One of the primary reasons is that the human brain simply cannot process and understand large compex things in one view. The brain needs to see things in smaller parts that it can understand. If you use a single VI and you have to scroll up and down, back and forth just to see the code you will not be able to keep track of the flow. It will be very easy to forget where things are coming from and where they are going. Worse yet is that you will not get any reusable code. This means that every time you write an application you would need to rewrite everything instead of simply reusing previously developed and tested code.

[SteveChandler]

There is a performance hit for loading a subvi but you can configure them to load inline. But a well designed modular program will likely perform better.

[nikosfs]

What do you mean by telling to load them inline?

Thank you!

[SteveChandler]

This is a new feature for 2010. You go to file/properties for the vi. Under execution there is a checkbox for load inline. What this does is put the subvi right into the calling vi as if it were not a subvi at all. You don't see it on the block diagram but the calling vi thinks it is part of itself.

[Mark_Yedinak]

---

@nikosfs wrote:

What do you mean by telling to load them inline?

Thank you!

---

I wouldn't worry about this right now. This is a more advanced concept and you need to learn how to walk before you can run.

One general rule for subVIs is that they should not be doing several things at one time. Try to keep the subVI to a single task or function. I'm not saying that the block diagram is nothing more than a single subVI but rather that it's focus is on accomplishing one task. For example, let's say you are developing a robot that will drive itself. It is capable of measuring the distance to an object, obtaining its current position on a field of some sort and determining it's speed and direction. You might be tempted to write a subVI that does all of these things in it. However, the better approach would be to develop a subVI that calculates the distance. A second subVI would be used to determine its position. A third subVI would be used to calculate the speed and distance. In this case the two values are related and can be calculated in a single subVI. Elsewhere in your code you may have a need to do all three tasks at the same time. In this case you can write another subVI that would call these three subVIs. In another case you may only need to get the position and distance. A subVI could be written to call the two applicable subVIs. This is how modularization can work for you.