The Bent Wire Phobia: LabVIEW

If someone asks me what that one unique thing in LabVIEW is that other programming languages don’t have, I would say it's ‘The Wires’. The one thing that is more flexible and scalable than our program (just a pun – not to hurt hardcore programmers). The one that comes in many colors and widths. The one that carries all your data everywhere. The one thing we don’t really notice much.

An interesting fact about LabVIEW is that you can tell if the code is written well by just taking a 1-sec look at it. It’s graphical, and the look matters!!

Have you judged the above code???

Think when you have to debug code written by another developer. You are tracking down an issue several levels into the program. You feel you are almost there. It’s nearing Friday evening so you are about to knock the issue down and go home happily. And then you landed on something like the one above.

Welcome to Bent Wire Phobia!!!

As much as we talk about Object-Oriented Programming skills, Actor Framework skills, Design Pattern skills, we also wanted to talk about our ‘Wiring Skills

Let’s talk about your ‘Wiring Skills’?

Wiring is an important thing to learn in LabVIEW. You do only a little, but it makes your programming so much better. It makes your code readable, debuggable, and provides an opportunity to make it better later.

It’s not that complicated to make your code look better; there are only a few rules that you should follow at the start, and it soon becomes muscle memory.

1. Always keep your error wires straight

Keep error wires straight!!!

Whatever happens with other functions, always make sure that you have error wires straight. Error wires pass through all major functions, and keeping them straight will make sure your code flow stays horizontal and doesn’t deviate much. (If your program requires you to have two error lines and then merge them at the end – go for it, please)

Error wire is sorted out, but what about other wires?

2. Data Cluster for rescue

Each function has inputs and outputs. Let’s not try to sneak them from one part of the program to another; too many wires will easily make the program spaghetti. This is where Data Cluster is very useful. You can bundle all your variables into a data cluster (single wire) and unbundle them only when you want the data in the program and bundle the result back into the data cluster.

It’s like keeping all your books organized on a shelf and taking them out to read when needed and putting them back once used.

Bundling the variables into the data cluster

Now that we have created data clusters to group data, how can we better use them?

3. Shift registers, modular cases for shorter wires

Don’t give an opportunity for your program to grow wider – There will be long/lengthy LabVIEW wires that go from left to right and are difficult to track.

You can modularize your program into separate cases using a state machine. The error structure and data cluster can be shared across all the cases by using the case structure. Similar to the error case, you can also have the data cluster shared across all the cases

As a beginner, even if one of the cases was not manageable – that’s Ok! Your other cases would be neat as they are separate, and you can come to any bad case and clean them up at any time!

You could use some out-of-the-box state machine architecture like JKI state machines to implement this quickly.

4. Bundle and Unbundle rules

Let’s try at max to use only one bundle/unbundle on the data cluster per case. So, all data comes from one single place and goes back to one single place.

Also, one other practice that you can follow, which might look silly but is my favorite, is: have the wire that connects the data cluster to the bundle/unbundle uniform. I used to always have the wire from the data cluster to bundle/unbundle be vertical to the edges of the bundle/unbundle functions. This will make all the cases look uniform when scrolling.

5. Avoid wire crossings

LabVIEW wire crossings are difficult to avoid. We can’t always achieve this, but if we can, we will attain the ultimate peace. A lot of cross wires kills readability and makes it hard to branch from wires. There is no one way to avoid this, but there are a few simple practices that you can follow,

• Be intelligent/uniform in assigning terminals for your SubVI: For example, error terminals at the bottom and class objects/reference data at the top terminal help wire between VIs more easily. Similarly, common controls (left & bottom) and indicators (right & top) that are present in multiple VI’s should be wired to the same terminal patterns so it makes it easier to connect the wires across these VI’s.
• Parallel Tracks: If the data output of your VI is going into a data cluster, then make sure the bundle order and the output from your subVI order is same
• Using Subcluster/Objects: Using a cluster for VI in and out will reduce the wire density in your program. Group data based on functionality into a cluster.
• Create SubVI: If there are a lot of wires around, then it means you are trying to do manipulation in a single VI. Look into making your code modular into SubVI’s which will also reduce the wire density.

These suggestions won't make your code cool in one go, but if you start following them slowly, you will figure out new ways, based on your coding style, to manage your wires!

Written by

Navin Subramani

Nov 26, 2019