How to creat multiple sub VIs'

[pnielsen@gplains.com]

I have a VERY large VI that finaly crashed due to the large size. What is the best way to create "Sub VIS"? I have almost 800K of code. Should I create all the sub vis and then add them to my Project? I want the program to call the sub vis automaticaly.

Thanks

Philip

[aeastet]

You can highlight areas and simply make it create a subvi. That is an option in the edit drop down. This way you do not need to hack up your code.

[pnielsen@gplains.com]

Thank you,

I was afraid of hacking my code.

Thank You very much

Philip

[johnsold]

Philip,

Make sure you have a back up copy saved somewhere else before you start.  Then save interim copies frequently as well.

While the process usually works quite well, it is possible to corrupt a VI or subVI when doing a major overhaul of a program.

Making backups takes only a few seconds.  Reconstructing an entire program from scratch will take much longer!!

Lynn

[pnielsen@gplains.com]

Thanks,

   That problem did occur when I first started programming.

Philip

[Mark_Yedinak]

And take this as a learning experience. In the future use subVIs from the very beginning. Using one large monolithic VI is never a good thing. Or as Jamie and Adam from Mythbusters would say, "Don't try this at home. Ever!"

[stevem181]

Hi Philip,

Backups:

As Lynn (johnsold) said, local backups are a minimum requirement.
A service like Dropbox is better in case of computer crash.
Note: Temporarily disable Dropbox syncing when doing builds in a Dropbox folder as this may cause builds to fail.
The best solution is true source control like the free TortiseSVN.

For sub vis I suggest:

Identify code sections that perform one specific function. This makes a logical sub vi. If you can easily come up with a name to describe the

section (like "Parse Input String" for example) then you are on the right track. With some practice you will be creating sub vis that can be used

in other programs and save you time in the future. This is a good reason to NOT include unrelated code in a sub vi just because it will fit.

Take note of the number of inputs and outputs in the code section. Ideally you want a small number of inputs and the same for outputs (3 or 4). Use clusters to reduce the number of I/O items.

Standardize on a connector pane layout - this makes wires line up better. The 4224 pattern works well. When LabVIEW creates sub vis it only creates the number of inputs and outputs that are required. So you will normally have to change the connector pattern and rearrange the controls and indicators every time you create a sub vi.

Include error in and error out in their standard places even if you don't need them for the particular application. When you use that sub vi later

you may need them.

Good practice is to use Type Defines for controls and indicators that go to more than 1 place. In your case, it is a jugement call if it is worth the trouble to do this on an existing program. Once you start using sub vis more, Type devs become very important. If you don't use them, changing a data structure will require manually changing every sub vi that uses that data structure.

steve

[pnielsen@gplains.com]

Thank You for the additional help.

Philip

[MoReese]

Steve has some good suggestions.  I would also add to peridoically test/run your program and test the section that you just changed just to be sure its working properly.