Wire or local variable?

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

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 [x] 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!

Similar Messages

What is difference between local variable and property node ?

What is difference between local variable and property node ?
" 一天到晚游泳的鱼"
[email protected]
我的个人网站：LabVIEW——北方客栈 http://www.labview365.com
欢迎加入《LabVIEW编程思想》组——http://decibel.ni.com/content/groups/thinking-in-labview

To make things clear, here are two small examples that show how nasty locals and value properties can be to the naive programmer.
- Open the diagram of the race condition.vi before running it and try to predict what will be the values of the two counters after the third run.
- Use the Compare Locals Properties and Wires.vi to find out how slow locals and value properties can be (times 1000+).
This being demonstrated, I must add that I use globals and value properties quite often, because they are often very convenient
Chilly Charly (aka CC)
E-List Master - Kudos glutton - Press the yellow button on the left...
Attachments:
Race condition.vi ‏9 KB
Compare Locals Properties and Wires.vi ‏18 KB

RE: local variable cross-talk?

Jeff
A global can be considered as a variable to the entire code, where lots of
different vi's can operate it. Locals only have any meaning within their
own vi, or instances of their own vi.
If anything writes to a particular global, whether in reenterent vi's or
not, it's available everywhere in the code.
What you were asking was about locals though. If a vi is non-renentrant
(i.e. as they come out of the box) then the values in the locals are vi
specific, no matter where the vi is, where it was last used, it retains the
data from it's last operation. If it is re-entrant, then the values in the
locals for each occurance of the vi are its own for EACH instance, i.e. just
like different locals in different vi's, it doesn't matter where else the vi
is used, the data held is that from the last operation of that specific
instance.
Simple way to demonstrate this. Make a vi that has one numeric control,
then code in +1 and get it to write to a local variable for that control.
Throw in an indicator to wire out the result of what is written to the local
for the control.
Then take this vi, put it in a for loop, then put another copy in the for
loop as well. Wire the indicators to the side of the for loop and create
indicator arrays for them. Get the loop to run 6 times say. Now try
running this with the vi in the for loop non-reentrant and then reenterrant.
One way the arrays will contain either all the odd no.s 1,3,5,7,9,11 and
then the other array 2,4,6,8,10,12 (don't know which array will be which,
depends which executes first in the for loop of this example). The other
way they will both be 1,2,3,4,5,6. In the first example, the same vi has
run 12 times, i.e. one copy of the vi which retains its info and is called
in many places and therefore only has one set of values, and the other with
two re-enterant copies where they have their information specific to that
instance of them i.e. effectively they are different vi's. Both ways are
useful, depends what you want.
If you're looking for a use for non-reenterant vi's then consider this:-
For instance. Supposing you get many things to try to write to a global
array of numbers, and you have two vi's one "A" writes to the first element
in the array and the other "B" writes to the second element. Because in LV
you have to read a global first and then write to it to perform a change,
these independant vi's "A" and "B" (be they re-enterant versions of the same
vi, or different vi's), can be performing the tasks simultaneously in the
code. I.e. "A" reads, "B" reads, "A" writes, and "B" writes over the top
with a modified version of what it read, and "A"'s changes are lost. This
is what's known as a "race condition" as "A" hadn't finished and "B" needed
to know what "A" was going to write before "B" performed "A" read. Try it,
hours of fun if you code this kind of thing in inadvertantly!
If the same vi is used, and is not re enterant, it can only run in one
instance at a time, hence two read / write operations cannot be performed
together, problem solved. Unless that gives you timing issues of course,
waiting for one to finish, to write the other......but that's another whole
can of worms.
cheers
Tim Price
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are confidential and may be legally
privileged. Access by any other party is unauthorised without the express
prior written permission of the sender. If you have received this e-mail in
error you may not copy, disclose to any third party or use the contents,
attachments or information in any way.
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Jeffrey W Percival
Sent: 29 November 2001 21:12
To: [email protected]
Subject: Re: local variable cross-talk?
Another useful reply! What a great news group this is.
One last thing I wanted to ask about, though, is global vs. local. I see
you talk about globals, but in fact the variables in my subVI's were locals.
I can easily understand the behavior I observed accompanying the use of
global variables, But I guess the use of the word "local" stumped me.
Should I interpret "local" in LabVIEW's sense to mean "local to all
instances of this VI"? And global to mean "visible to all instances of this
VI as well as other VI's"?
-Jeff
Tim Price wrote:
This facility is actually very useful, for instances where you want to
encapsulate some code so that it can only run in one place at a time,
i.e.
global arrays that are written to in more than one place. This method
can
eradicate race conditions completely for example when used like this.
There
are multiple other uses as well.
However, using a vi as a module of code, to run in more than one
instance at
a time simultaneously, re-entrant is the way to go. Just make sure you
debug it first!!!
Remember though, just because a vi may be re-eneterant, doesn't mean
that
everything inside is; sub-vi's, Globals etc. The classic one I've seen
is
where people think that a re-enterant vi is talking to it's own copy of
any
Globals used within it, i.e. counters etc., where in actual fact of
course,
they are all using the same Globals.
Worth playing with a few examples to get familiar with it.
Tim Price
Jeffrey W Percival, Senior Scientist and Associate Director
Space Astronomy Laboratory, University of Wisconsin - Madison
1150 University Ave, Madison, WI 53706 USA
608-262-8686 (fax 608-263-0361) [email protected]
http://www.sal.wisc.edu/~jwp

Tim Price wrote:
Tim, thanks very much. I'll try the experiment you suggest.
Thanks for taking the time.
-Jeff
Jeffrey W Percival, Senior Scientist and Associate Director
Space Astronomy Laboratory, University of Wisconsin - Madison
1150 University Ave, Madison, WI 53706 USA
608-262-8686 (fax 608-263-0361) [email protected] http://www.sal.wisc.edu/~jwp

Having Trouble Copy and Pasteing Local Variable in LabVIEW 2010

I am Having Trouble Copy and Pasteing Local Variable in LabVIEW 2010 in s subVI.
I have a VI that has a Local Variable called "Node Addr". I can select it OK, and it appears to Copy OK, But when I go to paste it, nothing appears. It doesn't matter if I use Cntrl-C Cntrl-V or the Copy and Paste from the Edit menu, I get the same results. I tried many times and got the same results. I made sure that I had click a paste location. I can insert the Local Variable if I use the Data Communication panel.
On one of the Paste, I got an error in the error list that said that a Local Variable was not connected to anything. When I clicked on the error, it took me to an insible item in the lower right corner of the block diagram that had nothing but a select box around it. I couldn't select the invisible item, but I could delete it.
Why does the copy and paste of this local variable not work?
Why does the paste cause the insertion of an invisible item?

dbaechtel wrote:
My VI is fairly complicated. In several places in the VI, I am either reading or writing to this variable which is an numeric Indicator on the Front Panel. Using local variables seems to be the best way to handle this situation rather that using wiring all over the VI. Since the VI is mainly a State Machine and there are only 2 Writes to the local variable, I am not afraid of race conditions in this case. NO!! While you may think that using Locals is your solution to wiring, it is not! The fact that you are writing and reading, most likely from several places, will most definitely contribute to a race condition. Depending on your implemetation, you should ALWAYS use wires. The wires are the variable. If you are using a loop (While, For), then using shift registers are appropriate means for routing values so that they are used by other sections of the code, later. One thing you must respect with LabVIEW is the dataflow. That's where Locals often fail.
I am not copying the Local Variable from one VI to another.
I am not copying the Local Variable from one VI to another.
The Data Communication panel is one of the panels that shows up in the Functions pop up list when editing the Block Diagram. It is the panel that includes the Local Variable function.
I don't know if the invisible item that was inserted in my block diagram was hidden or not. All I know is that the Errors List said that it was a Local Variable and that it was not connected to anything. I couldn't select it to get more information. All I could do was delete it.
You did not address my questions about why the Copy and Paste does not work properly for my Local Variable. Maybe it's a sign from the Software Gods not to use them LOL!..
So if I understand correctly, you are trying to copy & paste the Local Variable from within the same VI. How large is your block diagram? Did you try right-click on the variable and select "Find > Local Variables"? If it's a block diagram larger than 1 single screen (which it shouldn't), then it is possible that the Local is hiding beyond the screen. You should find it as I described earlier.
See my comments in red above.

Programmatically update Combo box won't update its Local variable

Hello all,
I followed a tutorial from NI website and programmatically edit items in a combo box. It worked successfully but not for the Local variables. Local variables still retain items that it had before.
Any suggestions ?
Thanks !
Solved!
Go to Solution.

You need to programmatically update the value property in order to change what the local variable will return, the value that you will wire doesn't have to match with one of the Strings[] array.
Perhaps you need to do something like this to update your value to change from "Two" to "Five".

Local variable for an Array of fixed size

Hello,
I have a two multirate loops in a VI.
In one loop, I want to refer an fixed sized array initialized in the other loop.
But I coudn't name the array, so I can't refer it.
Is there any way to refer it?
Thanks,
Young.

If you need a local variable, there is no other way than to create an indicator for it.
In LabVIEW there is no "fixed length" array : you can always add or remove an array element, and you don't need to declare it as in other languages. They are intrinsic dynamic objcets. Of course, the memory manager has to cope with this, that's why it's often better to initialize an array, to give it its final size immediately, resulting in faster running programs. However, this is only noticeable with relatively large arrays (> 10000-100000 elements).
May be you should explain in more details what you intend to do, because trying to reproduce a C approach in LV is probably not the best thing to do. For instance, you said that you are initializing your array in a first loop. You mean that you re-initialize the array at each iteration ? I suppose no, so may be you could put the initialize step out of the loop, and wire the array to your two parallel loops.
Remember also that local variables are not always good programming solutions, since using them will generate copies of their content each time they are refered to. And that can low down your program very significantly...
Message Edité par chilly charly le 11-05-2005 05:05 PM
Chilly Charly (aka CC)
E-List Master - Kudos glutton - Press the yellow button on the left...

Can you sort the "local variable" pick list?

My program has a lot of local variables. If I right click on a variable and click on "select item", a loooong list of all my local variables appears. They appear to be in the order in which they were created in my program.
Is there any way to modify the display to where the local variables appear in alphabetical order?
Amateur programmer for over 10 years!

The best solution is to not use a lot of local variables . Here is a neat trick to use local variables without having to use local variables . If you are using a state machine (case structure inside a while loop), create a cluster constant on the block diagram inside a state or case called "Local Defs". Inside the cluster, put constants for every local variable you will use. Label the constants like you would a local variable. Put a shift register on the loop border. Wire the cluster to the shift register on the right side. Do not initialize the shift register on the left side. In any case frame, you can wire from the left shift register into an unbundle or bundle to read or write to the Local. You never have to call the Local Defs state, the cluster will be defined because of the wiring. If using controls at many places, make a local constant for each control and have a state where the control is written to the local. Then you can read the local to use the value at any time. See attached vi for an example.
- tbob
Inventor of the WORM Global
Attachments:
StateMachineWithLocals.vi ‏45 KB

Using local variables

trying to use a simple local buffer to get an interger value and use it some where else. any help?

If you are using a state machine, here is another way to create local variables. Create a cluster with all local variables that you need. Wire into a shift register. Use Unbundle to get the value and Bundle to change the value. See code below:
Message Edited by tbob on 05-09-2007 11:58 AM
- tbob
Inventor of the WORM Global
Attachments:
Local.png ‏4 KB

Using local variables to "clean up" diagram

I have attached a photo with red circles indicating my use of local variables to "clean up" a block diagram. Would I run into any issues doing this? Can I leave this task and error unwired?
-Sarah
Solved!
Go to Solution.

I see some possibly really bad race conditions with your VISA Resources. For instance, if Task Out 3 is empty (by default), it is likely that the local to read will happen before the local to write. What this will turn into is you loosing your VISA Reference in the shift register. Use wires. Locals very rarely clean up your diagram.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions

Create local variable using labview scripting

I am trying to use labview scripting to create a control and a local variable for that control. I want both the local variable and the control contained inside a case structure. My problems are twofold:
1. the local variable is left blank/unnamed
2. the local variable is wired outside of the case structure, even though I set it's owner to be the same as the owner for the control (which is placed inside the case structure).
The flat panel is there because I thought that my problem might be a result of the local var being created before the actual control, so this just forces the control to be created first. The other thing I wonder about is the VI Object Class for the local variable. I have tried 'Node' and Control->Boolean, but neither worked.
I have attached a jpg of the code I'm talking about. The picture on thetop is of the code in question. The picture on the bottom is of the resulting code that's created....
Can anyone offer any help?
Thank you...
Attachments:
vi_scripting_lv.png ‏95 KB

The reason your locals aren't tied to a control, is because you didn't make a local variable from any control. Use the Boolean reference wire and wire it to an Invoke Node and select the Create >> Local Variable method.
Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

LabVIEW 2010 local variable behavior

Hi -
I upgraded to LabVIEW 2010 from 2009SP1 and the attached sub VI no longer works correctly. This is a state machine case structure that gets called inside a loop. I'm setting a Boolean local variable true, then on the next call when the case changes the variable has been reset to false. It did not do this in LV2009.
Someone will immediately tell me I have a race condition, but these local variables are not being written anyplace else, just within these separate cases.
See the attached code, specifically, the local variable "Enable" is getting reset when going from case "Enable" to case "Turn on".
Anyone else seen this issue, or can shed any light?
I fixed the VI by writing the value in each case, but this different behavior makes me wonder what other issues are lurking in LV2010?
Thanks
Solved!
Go to Solution.
Attachments:
eq99_cycling.vi ‏42 KB

This code looks more like some sort of an Action Engine than a state machine, but not quite. It gets called repeatedly from a state machine, and it decides what the next state will be depending upon the inputs. Instead of using all those local variables, I would use uninitialized shift registers (nothing wired to the left side). They hold their value from one call to the next. One more case needs to be added in this case. An unnamed, default case that would set the initial values of all the shift registers. Make it the default case and don't even name it. It will be called first automatically because the shift register is uninitialized so the default will be called. Inside the default case, set all the shift registers to desired values. Next time this subvi is called, those values will still be there. That is as long as nothing is wired on the left side, Whatever is wired to the state shift register will be the next case called.
See attached vi. It is broken because I did not wire anything to the indicators.
- tbob
Inventor of the WORM Global
Attachments:
eq99_cycling-4[2].vi ‏33 KB

Local variable behaviour different with panel open?!

Am I going mad?!
We write to a local variable in a subVI, set it TRUE, but when the subVI completes, if the panel is open, it reverts to FALSE. If the panel is closed, it retains its TRUE value as set by the local variable.
The true terminal of the local variable is cased so that it may, or may not, ever be written to.
This behaviour is definitely different from LV5.1.1.
Bug or feature? Any workaround?
TIA
Tom

> Bug or feature? Any workaround?
>
Both.
Indicators that are on the connector pane of a subVI must always return
a value. Problem is that since the diagram can have case statements, it
is possible for the diagram to run and never write to the indicator.
This was deemed a bad thing and it was decided that these "conditional
indicators" should return a default value if they weren't written to.
This writing happens at the last minute, after the diagram completes.
Each conditional indicator has a flag in it that is cleared before the
subVI runs and is set when the indicator is written to. If still clear
at subVI completion, the default is written to the indicator. When
local variables were added, and later when multithreading was added,
there
were some bugs introduced and later fixed. I don't believe the
behavior should be different depending on whether the panel is open.
It would be best if you would email technical support and tell them the
version of LV you are using, list out the steps, and they can tell you
if the bug was already known about and which version it was fixed by.
In the meantime, I'd recommend taking the locals and indicators taken
out of the case statement. Wire a default value of the case statement
or through the case statement and to the terminal or local.
Greg McKaskle

Local Variables and INLINING

LV2013SP1
When making a VI that originates a TYPEDEF'ed cluster, I have always used a local variable of that output cluster, and a BUNDLE BY NAME function to insert the various pieces.
Like this:
Now, when I try to INLINE the VI that does this, I get an error message: "This object is not allowed in a VI on which you enable inlining".
I can replace it with a constant easily enough:
My questions are these:
1... Why is the first method illegal? I suspect something to do with thread-switching into the UI thread, is that it? Or maybe there really isn't a front panel if it is INLINEd?
2... Is the constant pattern better, in terms of memory usage?
3... Is the constant pattern better, in terms of speed of execution?
4... Should I adopt that pattern anyway, regardless of INLINE or not?
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

the exact why is not explained
I believe the "why" IS explained. This all makes sense to me now.
There can be no instance of the control/indicator, because it's never been placed on the caller's panel.
If it existed, it would have to have properties like POSITION and BOUNDS, and those have never been set.
They COULD NOT be set, since they would have to be set (differently) for each instance of the inlined VI.
The INLINEd VI requires REENTRANCY, that means there is a separate dataspace for each instance.
I suppose that dataspace now would come from the caller.
The point of the INLINE is to connect the caller's output wire to the VI's input wire AS IF the VI's code were copied into the caller.
That means that the CONTROL/INDICATOR is totally unnecessary, and can be removed.
It therefore cannot be accessed. Not by property nodes. Not by local vars.
AND, ON A HUNCH, I tested this: NOT BY REFERENCE.
With a REFERENCE to a control/indicator on an INLINEd VI, I get the same error: this object is not allowed in a VI on which you enabled INLINING.
Because it doesn't exist.
The control/indicator is a metaphor for the interface between the code and the screen display. It ceases to exist when INLINEd.
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

Local variables???

I apologize for what may seem to be a novice question, but after searching
the web for a solution, I only found unclear and insufficient if at all
literature on this.
I have this situation: I am performing some data acquisition and I want to
periodically write the data to disk in such a way like every hour or so,
the data accumulated in the previous hour is written to a file with an
extension that has the time and date.
To do this, I would imagine a simple use of a local variable called
Next_dump that is incremented another hour when the hour is up seems to be
the way to go. However, LabView's funny thing with variables has puzzled
me and after a lot of experimentation, I can't seem to make it increment
past the first pass.
My question
specifically is: how do you get a local variable to be
incremented if after a case structure has been false or true, a certain
assignment is made to the variable?
I've tried to make this as clear as possible. Please let me know if you
have further clarification.
thanks,
James Tsai
U.S. Naval Research Lab.
James Tsai
http://www.people.virginia.edu/~jtt3e
[email protected]

> I have this situation: I am performing some data acquisition and I want to
> periodically write the data to disk in such a way like every hour or so,
> the data accumulated in the previous hour is written to a file with an
> extension that has the time and date.
>
> To do this, I would imagine a simple use of a local variable called
> Next_dump that is incremented another hour when the hour is up seems to be
> the way to go. However, LabView's funny thing with variables has puzzled
> me and after a lot of experimentation, I can't seem to make it increment
> past the first pass.
>
> My question specifically is: how do you get a local variable to be
> incremented if after a case structure has been false or true, a certain
> assignment is made to the variable?
>
I think there are really two questions here. First off, you probably want
to call a subVI each time through a loop that will either return the currently
opened file, or close the old one and open a new one depending on how much
time has elapsed. This can also be done in a case structure, but it makes
sense to build a subVI too.
Anyway, the file reference and a time reference, if needed, go into the code
which takes the current time, subtracts the reference, and determines if it
is time to open a new file. In one case it passes the file reference through.
In the other, it closes the current file, and either uses the current
time or
the old filename to create the new name, create the file, and wire out the
reference. This also assumes that the acquired points don't come in blocks
that need to be split into multiple files.
I'd use a shift register to pass the file reference and the time reference,
if needed. I wouldn't use a local variable in this case. You may be more
familiar with LV than I'm assuming, but one of the most common mistakes of
new users familiar with programming is to start making variables to store
things in. LV works much better if you resist the urge and instead use
wires and shift registers. You may want to browse through examples to get
the hang of it. It is partly a stylistic difference, but the overusage of
locals will affect performance and will introduce race conditions into your
program; so if you plan on using LV as a dataflow language, you might want
to limit your locals to parallel loop access and feedback controls in UI
diagrams.
The second question seems to be -- how to increment a local. The wire doesn't
represent a pointer; so make sure you read, increment, then write. Locals
can have any value written to them; so you may not need to read them because
you already have the value handy. Again, try to avoid reading and writing
things into variables the way you must in other languages, wires don't
evaporate, let them hold the data until you need it so that you can see
the dataflow of your algorithm.
Greg McKaskle

Local variables vs property knots- value

What is the advantage of local variables versus property knots (value)?
They tell in the manual, that for every local variable there is always a copy made of the original
input/indicator. If i use the property knots (value) no copy is made.
So what is the use of local variables?
Which methods exits else to avoid too long wires?
Sneff

As Mike already told you, you should try to avoid variables (both locals and globals) just as usage of property nodes value. There are several reasons for this:
- Bad diagram design with variables
- Trying to work around a bad architecture by using variables instead of switching to a fitting one
- race conditions (insecure datamanagement)
- performanceissues
Besides that, using variables vs propety nodes (value) are the following:
- property nodes are always executed in the UI thread => slow
- variables as well as the property node copy the data of the control\indicator in case of reading => exposed, well, predestinated for race conditions
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Wire or local variable?

Similar Messages

Maybe you are looking for