What is the best way/place to initialize everyting in my VI?

[rkmadse]

Ok LabVIEW Pros.... I am new to LabVIEW and am creating my first (Semi-complex) work station powered by LabVIEW. In an attempt to form the best LabVIEW habits possible I am in need of help. With GUIs, there are always several variables and controls/indicators that need to be initiailized. What is the best method for doing so? This works perfectly but just looks Ugly to me.... Would it be better to throw this all in a subVI or at that point do I have to worry about all of the references etc...? Ideas and best practice advice is much needed/appreciated. See example below...

Thanks Guys!

Kellen

[Gregory]

If there are things that can change during the program and you want to remember them when the program closes, then you can read from and save to a config file. You can use local variables to set the value of things, no need to use the "value" property node.

For manipulating control properties it can be helpful to create a cluster of all of the control references and store them in an Action Engine

for later use.

You probably don't need to collect the errors of all the property nodes, I don't think much can go wrong there. Sometimes I initialize things in a flat sequence as you have done, or if I have some kind of a state machine I will do it in an "Init UI" state, which saves a lot of space.

[altenbach]

It's hard to judge an image, but things don't look that great. It would be more useful if you could attach the actual VI and also explain how it is used and what it is supposed to do.

• From the outer case structure, this seems to be a subVI. Is it? In this case, controls typically receive values from the calling VI via connectors.
• Why are none of your controls connected to the code?
• It is typically not a good idea to hide an event structure inside a case of a case structure, so things seems inside-out.

[rkmadse]

I was just using the error out's to try and GUARANTEE that these things are executed. For some reason I thought this was necessary, but what your are tellin me is if they are in a flat sequence then I don't really need to connect the error wires at all and they will all get executed for sure before entereing the while loop?

[Hooovahh]

In the initialize state of a state machine.  Then you can also go to that state again to reinitialize.

[rkmadse]

altenback,

This is a subVI, but it doesn't receive any inputs from the calling VI, just allows the user to pop up this SubVI to create a measurement sequence file. The only thing returned is the Multi-Column Listbox values. This subVI allows the users to Edit, Swap, and Delete rows from the sequence being generated, as well as save and load the sequences. The idea was to give the use some tool to generate these measurement sequences that will be used with insturmentation and a switch matrix. I haven't attached an actual VI before so hopefully this works.

[Gregory · Accepted solution]

---

@rkmadse wrote:

I was just using the error out's to try and GUARANTEE that these things are executed. For some reason I thought this was necessary, but what your are tellin me is if they are in a flat sequence then I don't really need to connect the error wires at all and they will all get executed for sure before entereing the while loop?

---

Yes, you don't have to merge all the error clusters, just running one wire out to the while loop is good enough, as you have done. In this snippet, the For Loop on the right has to wait for the one on the left to finish before it executes. If you disconnect the error terminal though, they will both execute at the same time.

[aputman]

This will handle default values that have been saved to a control/indicator. 

[JÞB]

This is one of those well thought out questions that I really love to answer.  Thank you!

I believe you have been pointed towards some really good reading material!  an Action Engine for the User interface is a good start and using a Event Driven Producer-Consumer Loop to queue commands into a State Machine is often good practice for VIs that get to interact with those darned humans.

If you look into the help on some of the "Project Templates" you will find some extremely good examples of how to use those design patterns.  And, if you take the time to watch the "Developer Walk-Through"s NI has online you will save you and your team a lot of time that they would otherwise spend "Re-inventing the wheel"

Your picture does not tell us all about the requirements of the VI you wish to develop.  But, It does offer clues to some of us to direct you to the study of applied design patterns in the LabVIEW Enviornment.  Start with the links above and the walkthroughs... Then tell us how it worked or (ask for clarifications) You are close!

[natasftw]

---

@aputman wrote:

This will handle default values that have been saved to a control/indicator. 

---

This assumes the end user will never want to change the initialization values and this won't be built into an executable.

If these two aren't both true, it's a pretty quick way to do what's going on with the rest of the code.

If I'm not mistaken, local variables are faster than the value property node.  If we're going to initialize in this manner, we should be using the local variable.  The subVI really won't help much here as you've already noticed, you'd have to pass all of the references.  This makes for a mess when you build the array/cluster you'd pass into the subVI.  I'd stick with the state machine answer you received.  If you want to modify the code going forward, you can put that initialization code into the state.  If you want to update it to read from a file, it's mostly painless to work with that style.  It's built around being able to maintain your code.  That's what we want to do.