LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

dataflow vs local variables

Solved!
Go to solution

Is it preferable to use dataflow (wires) instead of local variables? If there are a lot of local variables, but they could be replaced by wires, does it worth to replace them?

Thank you.

0 Kudos
Message 1 of 13
(5,100 Views)
Solution
Accepted by nikosfs

Yes

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



Message 2 of 13
(5,098 Views)

Yes, yes and yes. LabVIEW is a dataflow language and using local variables is basically limiting the power of the language. Not to mention it can negatively impact performance too. I would recommend that new LabVIEW programmers should follow the rule of never use a local or global variable. This will get them into the habit of using dataflow. Then when they are comfortable with that they can sparingly use local variables for the few cases where they are required. (Generally this is for handling initialization of the UI since it is required to write a value into a control.)



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 3 of 13
(5,090 Views)

Well said Mark.

Richard






0 Kudos
Message 4 of 13
(5,076 Views)

You probably don't understand yet, but your question is actually flawed.  🙂

 

Locals are places to put data - they can be written to or read from at multiple places on a block diagram. Wires represent data flowing from _one_ place to other place(es).  They both use dataflow, but in wires the timing is controlled and (generally) in locals it is not. Also, since locals are copies of data, multiple instances of locals can contain different values depending on the execution order (which may not be what you expect!).  If you truely understand the difference, then the sparing use of locals is OK (I use them for resetting boolean buttons, where the local is inside a case that was activated by that button).

 

I got stuck on too many locals and globals at first too, until I understood them (or rather, had a better understanding of dataflow).  In addition to use of mostly wires, many folks (myself included) also use what are known as "LabVIEW 2 Globals" (or "Functional Globals") - these are really just sub-VIs with shift registers (on while loops) that retain the data so that it can be passed into or out of the sub-VI wherever it is needed.  One additional benefit is that there is only one copy of the data, saving memory in larger programs.

 

Regards,

 

Michael Tracy

Synergy Microwave

 

Message 5 of 13
(5,042 Views)

I thought I had seen a performance increase when using Local Variables versus a Property Node (when changing values)? 

 

Still, the bug I seem to get bit by most often is that the value of the local variable will be evaluated/read prior to when I wanted it read, which means a lot of the time I have to enclose them in a flat sequence and route an error bus through it.

0 Kudos
Message 6 of 13
(4,851 Views)

Locals are generally faster than property nodes.

 

Your second comment is exactly the reason why most data should be passed via wires.  Locals and property nodes are both subject to race conditions. In a properly designed and written LV program local variable are very rarely used and then for specific purposes where the risks of breaking dataflow are minimal and the task cannot be performed by wiring directly.

 

Lynn

Message 7 of 13
(4,843 Views)

 


 

beavercreek wrote:

 

Still, the bug I seem to get bit by most often is that the value of the local variable will be evaluated/read prior to when I wanted it read, which means a lot of the time I have to enclose them in a flat sequence and route an error bus through it.


 

I would replace this with "cause of bugs". The bug is not the race condition itself, but instead the bug is caused by improper use of what is available to the programmer. 

Smiley Very Happy

Message 8 of 13
(4,790 Views)

 


@for(imstuck) wrote:

 


 

@beavercreek wrote:

 

Still, the bug I seem to get bit by most often is that the value of the local variable will be evaluated/read prior to when I wanted it read, which means a lot of the time I have to enclose them in a flat sequence and route an error bus through it.


 

I would replace this with "cause of bugs". The bug is not the race condition itself, but instead the bug is caused by improper use of what is available to the programmer. 

Smiley Very Happy


To add to what Greg said, this is not a bug. Your code is doing exactly what you wrote. Position on a block diagram has does not convey anything about order of execution. While you might think the local variable sitting in the lower right corner will execute after everything to the left and above it will this is not the case. In fact, the read from that local is generally one of the first things executed. You are developing in a data flow language therefore you should learn exactly what that means and embrace it. Once you get the hang of it it is quite effective and useful.

 



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 9 of 13
(4,784 Views)

So is eliminating globals as important as eliminating locals? We use ethernet cDAQ's and multiple computers to view the acquired data and perform analysis. Wouldn't using network published globals in this case make sense or is there a benefit to another solution?

0 Kudos
Message 10 of 13
(4,676 Views)