Labview Style: How to handle dense wire diagrams

[brett.frymire@baesystems.com]

Hello,

I am looking to improve my programming skills and one of the areas I am not happy with, is diagrams with a lot of variables/wires.  I do not use globals, and hence, the diagrams can get quite complicated with wires.  I group as much as I can, and try to have a clean diagram, with little or no crossing wires.  I have included a small scale ideal type diagram for me.  I am sure everyone has their own style, and I am looking for ways to improve look of the diagram.  I can manage and move about the diagram, but other people get very quickly intimidated with the density of the wires.  (I had one programmer change one set of code to eliminate the wires and replace them all with globals.  I personally think this is the wrong approach, but I am open to ideas or even a link to a white paper on this.  I could not fine one with a search.)

Example:

[altenbach]

This diagram does not look too bad at all.

You do a lot of repetitive operations (5x "write key" in a row!) where only the strings change. One possibility would be to use a FOR loop and iterate over an array of string constants, for example.

One potentially problematic section is your path to string and back (bottom center). This breaks the code on different platforms. You should exclusively use "strip path" and "build path". You should never operate on entire paths as strings. 

Using globals and locals is not a good strategy, because locals and globals use significantly more diagram space than wires and they also potentially introduce race conditions, requireing extra sequence frames.

[altenbach]

If you want to see some real "dense" wire diagrams, browse around in the Rube Goldberg thread. 😄

[brett.frymire@baesystems.com]

Thanks for the replies. 

The diagram I showed was a nice one.   And I will go back and look at the code, based on your inputs.

I have one diagram, which I am somewhat embarrassed to show, has an incredibly dense wiring diagram.   Was wondering if anyone had some general rules of thumb, etc to improve it.  I am not kidding about the amount of variables.  There has to be around 100 wires one diagram.  This is due to the post processing of data, that requires a ton of parameters, and a fair amount of managed paths.

Just want to raise the level of my code.  🙂

-- brett

[altenbach]

One good option is to bundle related data into clusters.

[Yamaeda]

This diagram looks alright. You seem to have the same problem as me though, you add on functionality instead of creating sub-vi's. The bottom write to file could well be in a sub-vi of it's own which'd clear up the diagram and all those write keys should really be a loop. With those 2 small changes it'll be alot easier on the eyes.

I often thinks in the line of "only this added function" or "i cant come up with a good sub-vi name", but names can be changed later if needed and as long as they're in the same folder structure it's clear where they belong. 🙂

That said, it's well wired and structured and looks good. As Altenbach said, Clusters are good to lessen wires running around and sub-vi's for lowering functional blocks in the diagram.

/Y

[F._Schubert]

Style suggestion:

You should use 4x2x2x4 connector pane consistently. Take a look at the 'remove ** CFG' SubVI. Having 4 term to the left will allow to have straight wires from the Write Key VIs.

Having this pattern will require to use clusters for a max of 8 (better less than 6 or less than 4) incoming wires.

Especially when using Config files, I suggest to use the OpenG Variant Config Toolkit.

Felix

[brett.frymire@baesystems.com]

I pretty much use standard connector panes throughout my diagram.  And because of the dense wiring, it use the 6x3x3x6 pane for all my VIs, and use clusters as much as I can.  I find there is a problem using clusters, as i have  VI hierachy that is 10 layers deep, in that one small change now has to be changed in several locations.

The applications that i write are very complicated.  I work in the imaging area, as we make cameras and sensors.  We do in depth characterization of cameras, and hence, the amount of wires and variables needed.  Most of the functions that I need and use do not exist in the vision libs.  So, a lot of custom code. I used to work in FO, and it was a lot simpler.  🙂

If someone has links to materials to research, that would also help.  I have the style guide, but I may have missed something in there that might help.

And for everyone's help.  Thank you very much.  I read every reply and will apply all the helpful advice.

-- brett

[altenbach]

---

@Brett.frymire@fcimg.com wrote:

I find there is a problem using clusters, as i have  VI hierachy that is 10 layers deep, in that one small change now has to be changed in several locations. 

---

Make sure your clusters are type definitions.

[F._Schubert]

Maybe a transition to LVOOP would help?

Then a cluster becomes an object.

A cluster of clusters becomes a Composition 'design pattern'.

But then you get all the extra features of OOP like inheritance or organization of the VIs by making them methods of a class.

Felix