From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
03-19-2005 11:47 AM
03-19-2005 11:51 AM
03-19-2005 01:23 PM - edited 03-01-2017 01:33 PM
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! 🙂
03-21-2005 09:51 AM
07-03-2008 08:10 AM
07-03-2008 08:39 AM - edited 07-03-2008 08:43 AM
07-03-2008 11:58 AM
07-03-2008 12:02 PM - edited 07-03-2008 12:09 PM
07-03-2008 12:11 PM
07-03-2008 03:08 PM
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...