Suggestions on how to clean up a VI

[Pith]

I know they say the best Labview programs are ones where everything fits on one screen. I wrote this over time and just slowly kept on putting it all in 1 huge VI instead of making 4-5 smaller subvi's to take up some of the space. My question is what are some other things I could have done to reduce the clutter on my VI?

I also want to throw out there that I'm not a programmer by any means. I used to program as a kid, but went into the health sciences. I now code Labview for my graduate thesis project and so I apologize if my programming lacks considerable

conplexity.

Any advice would be much appreciated for future coding I do. 

[srikrishnaNF]

Hi pith,

  Actually..in front panel and block diagram,there is a lot of things to modify and needs lots  of things for you to learn.In block diagram,since you keep three parallel infinite while loops and inside some while loops,you have kept event cases...that aritecture is not at all valid one.Because,you can think ,a while loop as a process.If the CPU is locked to a particular process,definitely it will be unresponsive to other events in other while loop.You need to go through labview basics I&II.

Thanks and regards,

srikrishnaNF

[Pith]

I understand my programing abilities are limited as I stated. My question is cleaning up the VI so that it is more condense, cleaner, easier to read and change things later down the line.

As you have pointed out there are flaws with my programming. I'm trying to learn how to consolidate my VI and clean it up so alterations to the programming are more easily made and I can more easily identify how to deal with problems, like event structures in while statements and circumvent those problems.

[MikeS81]

Hi Pith,

you should create sub vi's for function you you need more than ones (your while loop which checks if the file or folder exists). Instead of building a string array inside a loop, you should use an init function which will be called only if you really need it, not every iteration in a loop. If you need a string array with fixed values, then you can directly use a string array with your values. You should use only one event structure per vi. You don't need the timeout case of the event structure if you don't need it. You can connect the "NewVal" directly to the case structure.

You can use a design pattern like Producer/Consumer with Event to avoid the two event structures.

Hope it helps.

Mike

[Darin.K]

First of all, if I were paying you as a LV developer I would be pulling my hair out.  But, if I were paying you as a grad student trying to get something going in lab, I'd say, let's work on a few things here.  Let's assume the latter.

A few tips off the top of my head.

1) You have controls "grouped" via decorations on the FP, they look like natural choices for clusters, really reduces the #wires you are stringing around.  Eliminates that monster bundle on the BD.  (When the datatypes are identical, arrays are a better choice unless you are planning some serious UI tricks).

2)  That collection of string constants built into an array should be a constant string array

3)  I have not had a chance to guarantee equivalent functionality, but one event structure is almost always enough.  You should examine that.

4)  At any rate, the case structure in the lowest while loop could easily be sucked into the Timeout case of the event structure.  Use a shift register to connect to the Timeout, start with -1 (no timeout), put the Case structure code inside (without the case), and wire -1 back to the shift register from this event.  The other events should pass 0 to the shift register so the timeout case executes.

5) I see you are planning to use the stop button to end execution, this is generally considered very bad form.   You should search for examples of stopping multiple loops, or better yet, simplify your code so you only have one loop.

6)  Booleans such as the 'Save' button should reside inside the event case that handles the event, this way it is 'read' and the latching action works properly.

Hopefully others will chime in as well.

[Pith]

So I could see myself making ~5 subvi's for this whole program. At what point do you stop making subVIs? Because I could look at a section of code and be like, "Wow, this makes this whole thing look way more confusing. I should just make a subvi." Is that the right logic?

[Pith]

So, how do I build a String Array constant?

So, I should also try to consolidate all my event structures into one structure.

[Pith]

---

A few tips off the top of my head.

1) You have controls "grouped" via decorations on the FP, they look like natural choices for clusters, really reduces the #wires you are stringing around.  Eliminates that monster bundle on the BD.  (When the datatypes are identical, arrays are a better choice unless you are planning some serious UI tricks).

---

I'm confused about what your suggesting here.

I appreciate all of the help thus far! I'm working on it as we speak. Slowly cleaning things up.

[Darin.K]

String Array Constant:  In general you create an array constant, then drop a string constant inside of it.  In this case I would Right-click on the output of the Build Array node, create Indicator.  Run the VI once, right-click on the indicator and Change to Constant.  Now you have the equivalent String constant.

Yes, I would definitely strive to have a single event structure. 

Cluster:  Take for Example your 'PowerCycle' group.  That could be a Cluster of 4 DBLs, or even better, a cluster of 2 clusters.  One cluster would be Power with 2 DBLs and the Other would be RPM with two doubles.  This gives you grouping, a decoration, a label, all for free.  You can pass around one wire on the BD and unbundle the values as needed.  When passing values to a subVI, it gets pretty hairy to feed in too many wires.  Extra Credit:  You can make your clusters Type Definitions and future changes will auto-propagate to all VIs.

[Mark_Yedinak]

---

@Pith wrote:

So I could see myself making ~5 subvi's for this whole program. At what point do you stop making subVIs? Because I could look at a section of code and be like, "Wow, this makes this whole thing look way more confusing. I should just make a subvi." Is that the right logic?

---

SubVIs are used to effectively turn an algorithm, operation or some related functionality into a single, reusable piece of code. When making subVIs avoid doing multiple unrelated tasks in them. In rare cases a subVI can be used simply to reduce bloat on a block diagram but I would avoid using this as a normal criteria. You should almost always be able to look at a subVI and see a way that it could be reused. Plan ahead when creating subVIs to maximize the potential for reuse. If you find several areas in your code that are copies of each other or are very similar these are also good candidates for subVIs.

If you have a state machine they are generally good candidates for being turned into a subVI as well.

A general LabVIEW style suggestion is that a block diagram and its code should not fill more than one screen display. If it does use more than one screen it should only scroll in one direction.