wire or local variable?

[ThunderBird]

The best method to pass data inside the same VI is wire or local variable? or the same? Which one is more effient? Thanks.

[Dennis_Knutson]

A wire is the most effecient way to pass data. Locals can cause race conditions, create copies of the data, and break dataflow. Sometimes, a local has to be used but they sould not be used when a wire can accomplish the same thing. They should not be used to make a block diagram "less messy" by using long wires.

[altenbach]

Everything Dennis said above is true. 🙂

Let's look at a seasoned text programmer suddenly forced to use LabVIEW: The first mental hurdle the new LabVIEW programmer might face is the fact that there are no visible "variables", something that is central to text based programming languages. Looking for "variables", he might stumble on local variables and suddenly he thinks he found the solution to keep programming the old-fashioned way.

What you might see as a result, is a LabVIEW program that has all controls and indicators completely disconnected, all lined up on the top or left side of the diagram (Similar to the variable definitions section in classic text code ;)). Then, on the right side everything is done writing and reading from local variables. Each disconnected code segment duplicating a programming statement, e.g. [Length] x [Height] = [Area] (where [...] are now a local variables).

This is NOT in the spirit of LabVIEW! In LabVIEW, the wire itself is the variable. Controls and indicators are just user interface access ports to the data, they contain their own data copies and are read or updated whenever dataflow might service them. Local variables are just secondary access points to the same controls or indicators.

Lets look at a (slightly flawed) analogy: I need to give you a CD with my LabVIEW program. I can (1) hand it to you directly (=wire) or I can (2) drop it off at the front desk (=front panel ;)) and you can pick it up later (local variable). As you can see, case (1) is more efficient and easier to debug. We both immediately know if the transaction succeeded. Case (2) could have a race condition, e.g. what happens if you try to pick it up before I had a chance to drop it off?

Local variables should be used sparingly. There are two main uses:
(1) Sometimes, it is required to either read from indicators or write to controls programmatically. This could be to initialize controls with a set of default values or similar.
(2) Exchanging data between two independent parallel processes in the same VI. For example to stop all while loops with a single control.

Anything that can be done with a wire should be done with a wire. If a wire is not sufficient, a shift register might do the trick. Local variables should only be used as a last resort.

Remember: Always go with the dataflow! 🙂

[AnalogKid2DigitalMan]

The wires also define dataflow and thus program execution flow. A function or vi will not execute until all of it's data are present.

Also steer clear of the sequence structure as a means to define program execution flow.

[remerlin]

In the spirit of your suggestion, I have two loops.  The top loop is a state machine that, when it is in "run" state, sets a boolean called "running" = True.  In all other states it is set to False.  The bottom loop uses that as a local variable to modify its own operation.  Unfortunately when the top loop is in RUN state, the bottom loop sees the variable as False, even though I can look at the value in the top loop and see it is True.  Any suggestions ?  (I ripped a lot of the actual code out of the diagrams to make them clearer...)

It may be a timing issue (?) because when I turn on the "highlight operation" switch, suddenly the code works as expected.

???????

[JeffOverton]

Well first, you revived a three year old thread, but second, there is no way to know if your local variable will be read before the true value is assigned to it.  Could your two loops be combined into one?  That seems like it would be a much simpler solution.

edit - it seems like your bottom state machine doesn't need to be there.  you could encapsulate your various functions into subvis and put them in the top loop.

Message Edited by JeffOverton on 07-03-2008 09:43 AM

[remerlin]

Thanks for the reply.  I agree that in the VI you see here, two loops are not required.  However, there's a lot going on in the bottom loop, in the real application.  So the question still stands, at least for future reference for me: assuming the two loops are operating in parallel, why does the bottom loop not see the correct value of the variable "running" when it changes to True ?  Note that I have been messing around with the VI and it appears that if I remove the error cluster and associated wires, the VI runs fine.  Any thoughts on that ?

(BTW, I revived the 3-yr old thread because NI makes you search before you can post...)

Rick

[JeffOverton]

The reason there's a delay is because there's no specified timing between when the Run state outputs a True, and when your bottom loop reads the local variable.  What's almost certainly happening is that your bottom loop is reading the local variable before the Run state updates the indicator.  Then, because your bottom loop has to take at least 1000ms, there's a delay before the local variable is read again, and this time the True value shows up.  A different option would be to pass a queue reference to both loops and have the top loop pass next state information into the queue, then have the bottom loop dequeue the next state as the final execution in a loop iteration.

This is called a Producer Consumer architecture because the top loop produces command states (or data acquisition, or ...) and the bottom loop consumes command states (or process data, or writes files, or ...).  I attached a quick example.

Message Edited by JeffOverton on 07-03-2008 01:09 PM

[altenbach]

The local variable only gets read IF the lower loop is in the idle state, and only once every 1000ms. If this is not good enough, you need to use a more predictable way of communicating between the loops.

[remerlin]

I was very patiently waiting for the bottom loop to change states (from idle to the next state) but it never happened, no matter how long I waited.  But, if I turned on the light bulb to watch program execution, suddenly the consumer loop WOULD start making the transitions that I expected. 

This behavior vanished once I removed all of the error wires in the VI - the transitions would occur as expected, with the one-second delay.  (I made it 1 second so that I could see the display of the states on the front panel).

So I have a working version but still am not sure why the original version failed to work...