01-18-2019 04:13 PM
@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"):
Bob Schor
01-18-2019 06:12 PM
@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)
01-20-2019 03:25 PM
@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.
01-20-2019 03:30 PM
@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.
01-21-2019 02:24 AM
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...
01-21-2019 08:05 PM
@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
01-22-2019 01:42 AM
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.
01-22-2019 02:05 AM
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
01-22-2019 08:11 AM
@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
01-22-2019 09:20 AM
@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