Tips for breaking a VI down into subVIs

[Potticary]

Hi all,

I was (still am) new to labview and needed a VI that controlled a process in our lab. Using examples and the help forums I was able to get everything I needed done except...I've now created a monster. I'm sure I've not done things in the most efficient way but I'd really like to break it up into smaller VIs, so troubleshooting or modification isn't such a pain. Are there any unwirtten rules or tips for breaking a large VI into subVIs I can follow to slowly make sure I don't break things?

I'm happy to post the VI, if people want to give specific tips but I'll wait for a request before I do. I don't want to invoke spontaeneous vomit if someone doesn't steel themsleves enough when they look at it.

Thanks.

[GerdW]

Hi Potticary,

Are there any unwirtten rules or tips for breaking a large VI into subVIs

Well, some hints from own experience:

- prerequisite: organize all code in a LabVIEW project!

- place one instance of duplicate code in a subVI, replace other instances of the code by the subVI (or place the new subVI into a loop when appropriate)

- create subVIs by selecting parts of your code and Edit->create subVI: Avoid picking controls/indicators of the mainVI!

- create useful icons and (atleast small) descriptions for all subVIs to recognize them easily in the context help

- use the recommended 4-2-2-4 connector pattern for subVIs (there need to be very good reasons to use any other pattern!)

I'm sure other hints will follow…

[bseguin]

Everything start from the design usually...

When we do a preliminary design, we have what we call object. Then every main object can have it's own library without dependency of other object. (Portability/Reusability) Try to create as well one folder per object in witch you will save all files with the corresponding library.

So here some example of object

Instrument communication (each of them in a separate object)

File report saving loading and analysis

GUI (Graphic User Interface)

Control (PID, fuzzy logic other algorithm)

Communication with external world (Database, Internet/Ethernet...) each of them in a separate object.

Now that you have your main object, you need to separate them in a smaller one in what we can call function.

Example of function

Open file

Save file

Initialize communication

Send command

Close communication

If you have type def or other sub function that you do not want them to be exposed outside your main object, you can create a virtual folder in the LabVIEW library and changing it to private.

Do you understand where it goes?

With this suggestion you will have a very good start.

Benoit

[Bob_Schor]

I find it useful to "write (some) documentation", emphasizing what I want to do (and ignoring the details of how I want to do it).  If I'm starting (as you seem to be) with a large "unstructured" VI, I try to look and see where I can "draw a box" and say "This is doing that, taking a few (1-3) inputs, doing something, and creating a few (1-3) outputs" (the fewer the inputs and outputs, in general, the better).  This is a candidate for a sub-VI, as inputs and outputs are defined, and the interior "details" might not be so important.

I strongly echo the suggestion that every sub-VI needs an Icon, even a simple Square Outline with 2-3 lines of text ("Get Test Params", "Find Data Folder", "Filter Signal").

Bob Schor

[billko]

Every subVI should have a purpose.  Ideally, only one purpose.  This would be the equivalent of breaking down text code into functions, where every function has a specific task that it does.

Learn to recognize redundant code and create one subVI that will replace all of the redundant code instances.  This is tougher than it sounds; sometimes you can recognize the redundant code, but because of subtle differences in the instances, you have really put on your thinking cap to figure out a way to make your subVI usable for all instances.

Don't worry about limiting your block diagram to one screen.  By following the tips above, you'll rarely come close to that limit.

Food for thought:

As Bob mentioned, it's good to have a plan of attack.  If it's in outline form (like a formal SDD, for example), you can almost create a subVI for each paragraph, with its own set of subVIs for each sub-paragraph.  I probably wouldn't go beyond that, though.  Anything more than a few layers deep is not in keeping with LabVIEW best practices.  If you can think about the overall project in pieces, you can code that way!

[rmarcink]

To add on the very useful advises above, here are some tutorials that you might find interesting as well:

http://www.ni.com/white-paper/7593/en/

https://www.youtube.com/watch?v=zr2qqv1F4kk

Good luck!

Ruta

[RTSLVU]

I would like to see your code and make a few suggestions...

Honestly it can't be any worse than this code I was handed years ago, and this code uses sub-vi's.

[Ben]

---

@RTSLVU wrote:

I would like to see your code and make a few suggestions...

Honestly it can't be any worse than this code I was handed years ago, and this code uses sub-vi's.

---

Was that written before LV 6i ?

It is not fair poking fun at pre-LV 6i code since it used attributes nodes because property nodes had not been invented yet.

Ben

[RTSLVU]

---

@Ben wrote:

---

---

Was that written before LV 6i ?

It is not fair poking fun at pre-LV 6i code since it used attributes nodes because property nodes had not been invented yet.

Ben

---

Nope I do believe this was written in LV8.0 as you can see in the first picture there is a "GRAPH" property node used.

But my concern is the fact that this program architecture is one big loop that spans three 1920x1080 monitors.

[Hooovahh]

There's lots of good advice here.  In English class I was always told to write a layout of my story before working on the actual paper.  This was obviously an attempt to get me to think about things before jumping right into them.  Of course one good and bad thing about LabVIEW is you can just start writing that novel without any plan at all, and by the end of it you'll have a book.  Just maybe a book that is hard to read and has pacing issues.  I was never all that good at English...

Refactoring software is a big part of any programming language, and for me it is a large part of what I do.  There are times that in LabVIEW I just start writing code to quickly test out something, or make sure something behaves the way I expect.  I will usually start with a state machine, or Queued Message Handler but other than that there isn't much structure, it just organically grows and grows with more and more states and inter-dependencies until...I need to clean this place up.  Start making more subVIs, start making more states, start modularizing the code where it makes sense.  You get better at refactoring, and cleaning up code with experience, so working with someone who you can talk through the software with often helps.  I have a few pieces of code I've refactored probably 4 or 5 times heavily.  It is a class based set of APIs so the public methods never changed, just the underlying mechanisms.  After every refactory the code gets better, easier to read and follow, and has less code smell.