LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Tips for breaking a VI down into subVIs


@rmarcink wrote:

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/

 


Wow.  I didn't know those tutorials existed!  And it is recent, too.  [Can we get a link to "useful NI Tutorials" somewhere on the Forum?]

 

Not to be too contrarian, but I'd take exception to the section on Connector Panes, which basically advised making a Connector Pane that fit the number of Inputs and Outputs.  My advice (which, I think, is consistent with LabVIEW Best Practices) is to (almost always) use the 4-2-2-4 Connector Pattern, put Error In and Error Out on the lower left and right corners, and try to limit yourself to no more than 3 inputs and outputs (fewer, if possible).

 

There are several reasons for this advice (speaking from personal experience, not necessarily from "conventional wisdom"):

  • Most newer LabVIEW functions use this pattern.
  • Using it means input and output "wires" tend to line up (and look neater).
  • Error In and Error Out in a "known place" keeps the layout of sub-VI Icons neat.
  • Using the Error Line provides a means of Serializing when necessary, and catches "silly mistakes" at run time.
  • If you have >3 inputs or outputs, a warning bell should be going off that says "Cluster!".
  • Note that Object Oriented code usually has the Object Wire in the upper Left/Right connector.  DAQmx and IMAQdx also use this position for Task/Channel wires, while File I/O uses it for the File Reference wire.
  • Style is Important!  In fact, there's an entire book ("The LabVIEW Style Book") on it.

Bob Schor

0 Kudos
Message 11 of 25
(1,359 Views)

@Ben wrote: 

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


I thought the two were the same and just the terminology changed.

 

 

@Potticary wrote:

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?

 

Yes, of course there are, but I would break all rules writing them down because they would immediately cease to exist under that definition 😄 Poof! (see also)

0 Kudos
Message 12 of 25
(1,348 Views)

@GerdW wrote:

 

...

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

 

 


Why?  I never understood the 4-2-2-4 fetish.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 13 of 25
(1,332 Views)

@Bob_Schor wrote:

@rmarcink wrote:

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/

 


Wow.  I didn't know those tutorials existed!  And it is recent, too.  [Can we get a link to "useful NI Tutorials" somewhere on the Forum?]

 

Not to be too contrarian, but I'd take exception to the section on Connector Panes, which basically advised making a Connector Pane that fit the number of Inputs and Outputs.  My advice (which, I think, is consistent with LabVIEW Best Practices) is to (almost always) use the 4-2-2-4 Connector Pattern, put Error In and Error Out on the lower left and right corners, and try to limit yourself to no more than 3 inputs and outputs (fewer, if possible).

 

...

Bob Schor


Hmm.  So the recommendation is ti always use a 12-pin connector, but never use more than 8 pins.

 

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 14 of 25
(1,329 Views)

You can find other tutorials using this link:

http://www.ni.com/innovations-library/white-papers/

 

Just type in "Tutorial" in the search engine. It is not very convenient or well structured site though...

0 Kudos
Message 15 of 25
(1,310 Views)

@paul_cardinale wrote:

Hmm.  So the recommendation is ti always use a 12-pin connector, but never use more than 8 pins. 

PC:  What, never?

BS:  No, never!

PC:  What, Never???

BS:  Well, hardly ever ...

 

The main point was the advantage of the (NI-recommended) 4-2-2-4 Connector Pattern (with Error In/Error Out used consistently, and straight-line connections between sequential VIs).  However, I've also read a number of books on modern program design/refactoring/SOLID principles (I confess that "S" is the one that's easiest for me to understand and remember).  One that I read within the last two years had several sections on numbers of parameters for routines -- 0 was the best, 1 was OK, 2 was less good, and 3 or more were strongly discouraged.  I have to confess I occasionally pass 8 connectors, but my current average is probably 6-7 (recall that I almost always have the lower corners filled with the Error Line ...).

 

H.M.S. Bob-a-Schor

0 Kudos
Message 16 of 25
(1,295 Views)

I rarely have more than four connectors (error in and out inclusive) on the 4-2-2-4 pattern connected.  Sometimes I'll use one of the really crowded patterns, but that's only because I'm going to only use half of it.  I still use the same amount as above, and for the same reasons.

 

I maintain that if you make subVIs properly - i.e., a subVI accomplishes one thing, and one thing only - and if you bundle your wires properly (think of the wiring harnesses on your car bundling wires that go to the same place), you'll rarely need more.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 17 of 25
(1,278 Views)

Refactoring is a skill, as such it's hard to write down hard rules, but some methods and ideas can help.

It'd be helpful if you post the code, but my experience says that these types of big loop programs translates well into a state machine.

The more states the better! (there are limits to everything, but if you get to 40-50 states you'll know...)  I assume you would have states as Init, Idle, Setup, User input, Start measure, Wait for measure, Write result and Exit. Am I close? 🙂

Moving the code into the right case should be fairly straight forward. Before, during and after, also look for code that can be made into sub-vi's, code parts that are identical are easy to realize (but can be hard to spot if the code is messy), it's the "almost identical" that can be tricky, often they can be generalized through some parameter (can e.g. 10 text constants be 1 loop where the loop counter is used to generate text?)

 

Post the code and try to implement the suggestion above and we'll see how it develops. 🙂

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 18 of 25
(1,273 Views)

@altenbach wrote:

@Ben wrote: 

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


I thought the two were the same and just the terminology changed.

 

...


Property nodes are implemented as ActiveX while Attributes nodes predated such. Attributes node HAD to live on the diagram of the control/indicator, property nodes worked with control references and could be used in sub-VIs.

 

We wrote a complex application that really could have used tab controls (which had not been invented yet) hiding a showing FP objects as various views were selected but using attribute nodes, the BD was very complicated. I swear it is was one of the "horror story" VIs we sometimes see in presentations of dab code. Considering the bear skins and stone knives we had to work with it was the best that could be done with the resources we had available at the time.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 19 of 25
(1,258 Views)

@Bob_Schor wrote:

@paul_cardinale wrote:

Hmm.  So the recommendation is ti always use a 12-pin connector, but never use more than 8 pins. 

PC:  What, never?

BS:  No, never!

PC:  What, Never???

BS:  Well, hardly ever ...

 

The main point was the advantage of the (NI-recommended) 4-2-2-4 Connector Pattern (with Error In/Error Out used consistently, and straight-line connections between sequential VIs).  However, I've also read a number of books on modern program design/refactoring/SOLID principles (I confess that "S" is the one that's easiest for me to understand and remember).  One that I read within the last two years had several sections on numbers of parameters for routines -- 0 was the best, 1 was OK, 2 was less good, and 3 or more were strongly discouraged.  I have to confess I occasionally pass 8 connectors, but my current average is probably 6-7 (recall that I almost always have the lower corners filled with the Error Line ...).

 

H.M.S. Bob-a-Schor


Since I usually have no more than 3 in, 3 out, I most often use 4-4.  If I need more, I step up to 4-1-4*, then 4-2-4*, then 4-2-1-4 or 4-1-2-4, then 4-2-2-4.  Sometimes I even take a 3-2-x and rotate 90 deg.  Worst of all, I don't even see anything wrong with doing all that.  Attached are some of my VIs with unusual pinouts & icons.

 

Paul Cardinale

 

P.S.  I think your sign-off should have been: Bob Schor, Captain H.M.S. Lab-a-VIEW

 

* Sometimes flipped horizontally depending on which are input and which outputs

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 20 of 25
(1,248 Views)