What is difference between local variable and property node ?

[JoeLabView]

One important item to consider when choosing between a property node or a Local Variable when reading or writing a value is "race conditions"..
 
Local Variable may be more susceptible to them. 
 
RayR
 

[chrisger]

hi there
-"Why would property nodes be more susceptible to race conditions?" property and invoke nodes have error inputs/outputs. this allows you to create a dependency in execution by wiring the error clusters. with locals you have to use sequence structures ore something like that to force a dependency.
- locals create data copies! so if you store lots of data in your controls memory may be an issue! property nodes don't create data copies.
- you should always seperate naming for the GUI from the naming on the block diagram. for the GUI use the "caption", for the diagram the "label". the locals name is the controls label.
- one of the most efficient ways to transport data through your app is the usage of "Functional global variables" aka "LV2 style globals". search here for this keywords. this dosn't use either locals nor property nodes.
 

[Kevin Price]

- you should always seperate naming for the GUI from the naming on the block diagram. for the GUI use the "caption", for the diagram the "label". the locals name is the controls label.


I'm curious -- I very rarely display the GUI caption, preferring to display either the label or nothing at all.  Since you advise always keeping the names separate, you must have a very different approach than me.  What's the thought process behind your rule-of thumb?  It's only on relatively rare occasions that I find need for the caption, usually for generic multi-use indicators whose present contents are id'ed by the run-time-writeable caption text. 
During development, I *like* having the same name on both front panel and block diagram, and having both update in sync if I change one.  I developed my rule of thumb when I was still pretty green with LV after a few frustrating debug adventures where captions and labels got criss-crossed and out of sync.  The code did some calcs and wrote to an indicator labeled "param 3".  On the GUI, that indicator showed only its caption, "param 1".  A *different* indicator had a visible caption "param 3" but was labeled something else on the block diagram.    What a mess!
-Kevin P.

[Ben]

Kevin asked
" What's the thought process behind your rule-of thumb?"
I believe that comes from the VI Checklist!
"
The name of a control or indicator should describe its function. If the control is visible to the user, use captions to display a long description and add a short label to prevent using valuable space on the block diagram.
"
See here
<a href="http://zone.ni.com/reference/en-XX/help/371361A-01/lvdevconcepts/checklist/" target="_blank">http://zone.ni.com/reference/en-XX/help/371361A-01/lvdevconcepts/checklist/</a>
BenMessage Edited by Ben on 09-21-2006 02:42 PM

[jwdz]

chris&nbsp;good ,thank you!
five stars.

[chrisger]

" What's the thought process behind your rule-of thumb?"
well, i think all has been said...
cause i'm using lots of references (access is deeply nested inside the hierachy) i'm using a naming convention for controls that allows me to find the purpose of a control by its label. these labels are for sure not suitable for&nbsp;the common user of the app, so for the GUI i'm using the captions.&nbsp;i'm writing the code (and so the labels) in english while the GUI is in german (or any other language).
btw.: jwdz, has your question been answered?:-)

[bfarley]

JLV,
Why would property nodes be more susceptible to race conditions?
A problem I have with locals is size.&nbsp; If you have a control with a long name - the local gets huge and takes up a lot of screen space.&nbsp; It would be nice if locals were a standrd size and identified by their label on the block diagram instead of embedding the label in the local itself.
Bill F

[JoeLabView]

Thanks chris,
You described it very well..
&nbsp;


JoeLabView wrote:
&nbsp;
Local Variable may be more susceptible to them.&nbsp;
&nbsp;


I thought I mentionned Locals..&nbsp; I try to avoid them as much as possible.&nbsp; I recently discovered that they are indeed useful when dealing with IMAQs.&nbsp; However, as Chris described, there is no dependencies and they are resource hungry..
Actually, in the Basics course, there is an example of race conditions that occur when using Local Variables.
RayR

[chilly charly]

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&nbsp;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+).
&nbsp;
This being demonstrated, I must add that I use globals and value properties quite often, because they are often very convenient ;)


Race condition.vi:
http://forums.ni.com/attachments/ni/170/206664/1/Race condition.vi


Compare Locals Properties and Wires.vi:
http://forums.ni.com/attachments/ni/170/206664/2/Compare Locals Properties and Wires.vi

[Ben]

CC,
Could you please post the VI's used to generate these numbers?
Thank you,
Ben

[chilly charly]

Jarrod S. a écrit:One thing people haven't mentioned yet that can be very important in terms of performance when choosing between locals and property nodes is that property nodes (implicit or by reference) cause a syncronous update of the control on the front panel whenever you update the value from them. That means LabVIEW has to stop whatever it's doing, jump to that front panel and update the control. If you do this a thousand times in a loop, you're looking at at least 1000 thread swaps and 1000 redraws. Nevermind that the human eye can't possibly see each of the 1000 updates, that is a huge burden on your system resources.If you update a value using a local variable, LabVIEW may make a copy, but it can still be smart about when to update that control on the front panel. LabVIEW's default behavior is to store all front panel update requests in a queue and service all of them at once about 60 times a second or so. This provides (or is intended to provide) minimal thread swaps for maximum visual acuity.



This is illustrated by&nbsp;these experimental results : relative execution time for&nbsp;the replacement of&nbsp;100 000 array elements :
wires&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;1locals&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;1607L2 type globals&nbsp;&nbsp; 2257Property nodes&nbsp; &nbsp;15000

[JoeLabView]

Jarrod S. wrote:One thing people haven't mentioned yet that can be very important in terms of performance when choosing between locals and property nodes is that property nodes (implicit or by reference) cause a syncronous update of the control on the front panel whenever you update the value from them. That means LabVIEW has to stop whatever it's doing, jump to that front panel and update the control. If you do this a thousand times in a loop, you're looking at at least 1000 thread swaps and 1000 redraws. Nevermind that the human eye can't possibly see each of the 1000 updates, that is a huge burden on your system resources.



Wow...&nbsp; This one I did not know..&nbsp; :o
Interesting..&nbsp; :o
Glad this forum exists!&nbsp; :)

[devchander]

It looks like we all just&nbsp;compiled a thesis on the subject:smileyvery-happy:


Glad this forum exists!&nbsp; <img height="16 src= Loading Image..." width="16" border="0">



&nbsp;
Exactly! :smileywink:

[JoeLabView]

shoneill wrote:Who said race conditions need not be reproducible?



Shane,
No one..&nbsp; ;)&nbsp; That's why (certain) race conditions can / may cause unpredictable results.&nbsp; :o
RayR

[Ben]

JLV wrote "That's why (certain) race conditions can / may cause unpredictable results.&nbsp;"
&nbsp;
I agree!
&nbsp;
I often review code developed by LV novices. As soon as I hear "sometimes", "occasionally", "not always" I go looking for race conditions which or almost always solved with a proper action engine.
&nbsp;
Ben

[zskillz]

JoeLabView wrote:


shoneill wrote:Who said race conditions need not be reproducible?



Shane,
No one..&nbsp; ;)&nbsp; That's why (certain) race conditions can / may cause unpredictable results.&nbsp; :o
RayRMy response is based on this definition of a race condition:http://searchstorage.techtarget.com/sDefinition/0,,sid5_gci871100,00.htmland though it's not worth arguing about, I still think that this gives predictable/reproducable results every time and is not a good example of a race condition.anyway - it's not a good way to do something, but maybe I need to broaden my definition of "race condition"=)-z

[Ben]

Hi -z,
I agree that CC example was predicable. Here is an other example that I believe is predicatably-unpredicable.&nbsp; :smileywink:
<img src="Loading Image...">
BenMessage Edited by Ben on 11-18-2006 02:17 PM


Race_condition.vi:
http://forums.ni.com/attachments/ni/170/216164/1/Race_condition.vi


Predicably_Unpredictable.JPG:
http://forums.ni.com/attachments/ni/170/216164/2/Predicably_Unpredictable.JPG