dataflow vs local variables

[nikosfs]

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.

[LV_Pro · Accepted solution]

Yes

[Mark_Yedinak]

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.)

[Broken_Arrow]

Well said Mark.

[SynergyMike]

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

[beavercreek]

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.

[johnsold]

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

[GregFreeman]

---

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. 

[Mark_Yedinak]

---

@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. 

---

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.

[iyeager]

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?