Help me be less of a Labview noob: what's the proper way to deal with tons of variables?

[optoelectro]

You guys have helped me learn a ton about labview over the years. For example, you guys showed me the light of using state diagrams rather than convoluted hellscapes of for loops, flat sequences, and case structures, and my code is neater as a result.

However, I'm aware that my code is still awful and would make most of you hurl if you saw it (the problem is partly that I'm usually under some pressure to get results in the near future, and learning the proper technique would take me too long compared to doing the messier thing I currently know how to do).

The thing I think I should learn how to fix now (that I'm sure I'm doing incorrectly) is handling all the variables in my program. I usually have maaaany variables I set via the front panel. I end up having these awful networks of wires and reference values like this:

(please be gentle with me, I know it's god awful.)

What's the proper thing to do here? I'm dimly aware of clusters, is that the right solution? Or is there something even more elegant? Any tutorials on this I could read would be greatly appreciated, thank you.

[GerdW]

Hi electro,

first suggestion: use Autocleanup (Ctrl-U) from time to time! 😄

Next hint: use clusters to bundle related parameters. Use arrays for multiple items of the same kind… (You would do so in other programming languages too!)

- Don't use the "value" property nodes - it really seldomly needed. LabVIEW uses DATAFLOW by wires!

- Don't call them "variables"! In LabVIEW (due to DATAFLOW) the wire is the "variable". All those items in your image are controls or indicators (or dataflow sources and sinks)!

You will find a lot of tutorials at www.learnni.com …

[Ben]

A little question with a big answer...

First!

The GUI should be viewed as a I/O device where you display something or get info from a user. So if the user does not see it touch it should not be on the GUI.

A lot is need on the GUI?

Use pop-up sub-Vis to get an answer you need now and let the pop-up return the value.

A lot of stuff ahs to be shown on the GUI.

Use a GUI controller (see here for images and review those postings) put stuff on the GUI or control visability and settings...

I need a value determined in one place but used in another...

You are already using a State machine so add a shift register and a cluster "internal state" to store the value you figure out in one state and then unbundle in the state where you will use it.

But carrying a value in the internal state through a lot of state to use it one one other place seems like a waste and all of the values I have remember gets confusing?

If a value is only used in a lmited number of places and working with a widget, create an Action Engine for the widget and keep all of the info the widget needs in the AE.

So using Shift registers, AE's and a GUI controller will let you develop code that "LOOKS" like what it does and lets you push the details down into a sub-vi devoted to specific tasks.

Just my 2 cents,

Ben

[optoelectro]

Hi, haha, I've actually tried to use auto cleanup -- but I dunno if it's because I have way too many controls or my PC is older or what, but it tends to crash LV for even a small area of selected stuff to auto clean up.

Thanks, I'll keep that in mind. I kind of thought value property nodes were a cleaner way to do it, but I guess not. 

[crossrulz]

Clusters will help you a lot, especially with that subVI that has many many inputs.  Be sure to make them Type Defined controls so that updates are done semi-automatically for you (add an item to the type def cluster and all instances get updated).  And with clusters, use the Bundle By Name and Unbundle By Name as that adds self documentation.

[optoelectro]

Thank you. I already use a type def labview control and shift register with my state diagrams. I'll try and figure out and work in the other stuff you said.

[optoelectro]

Thank you, I just read about clusters and un/bundle by name and it actually seems to be exactly what I want for passing values to functions.

So I just want to make sure this is the right idea. If I have a cluster of values that I want to pass to a bunch of different sub-VIs, from my main VI, should I do it like this?

(that's within the sub VI, the cluster is what I passed to it.)

The thing is I want to use all those values separately in different parts of the sub-VI, so I have to unbundle them into different variables unless I want to grab them directly from the cluster each time I use them, right?

[prettypwnie]

By "unbundle them into different variables" you mean wire them into indicators, right? You say you need to do this because otherwise you would have to grab them directly from the cluster each time you want to use them - yes, exactly, that is what you should do: when you need a value, you should get it by wiring up to wherever the value came from. It is unnecessary to store them in indicators just because you need the value somewhere else in the subVI. You only need to store values in indicators if you want your user to see them (which since it is a subVI, I'm assuming it is not visible to the user, so you don't need that).

[billko]

Unchecking this option allows you to use the little terminals instead of the big icons.  This makes it look a lot neater (IMHO).  Right click on a terminal icon and uncheck the "view as icon" option for existing terminals.

It's awesome that you want to learn best LabVIEW practices.  A great book to start you down the right path is Peter Blume's LabVIEW Style Book.  It's a little outdated, but still extremely relevant!  🙂

[crossrulz]

---

@optoelectro wrote:

The thing is I want to use all those values separately in different parts of the sub-VI, so I have to unbundle them into different variables unless I want to grab them directly from the cluster each time I use them, right?

---

Unbundle directly from the cluster.  There is nothing wrong with that

Though, the way you are asking these questions, I am starting to think you have too much happening in your subVIs.  You might want to look to see if you can break up the code into smaller VIs and/or make more states in your state machine.