topic Re: Wire = variable..... or wire != variable... in BreakPoint

Wire = variable..... or wire != variable...

Ray.R — Thu, 13 Nov 2025 19:43:22 GMT

While reading on the subject of LVOOP, I discovered that LabVIEW does not have the concept of variables. Below is a quote from that article..

"In summary, LabVIEW, as a dataflow language, does not normally have variables. Wires are not variables. Front panel controls are not variables. Even local or global variables are not allocated with a specific lifetime, the way variables are in other languages. Variables are part of a model that conflicts with dataflow. Without variables and a way of defining the lifetime of those variables, construction and destruction are meaningless concepts, and therefore we left them out of the initial language design."

So why do we tell people that the wires are the variable when there is no such concept in LabVIEW?

Re: Wire = variable..... or wire != variable...

Mark_Yedinak — Wed, 25 May 2011 14:56:22 GMT

I actully say that wires are similar to variables. I specifically do not say they are variables specifically because they do not have a storage scope or concept of existence. The only time the value is "read" is when the wire terminates. You cannot read it at any time. like a physical memory lcation (which a variable is) like other languages. Probably the most similar equivilant would be to say a wire is like a local variable in a traditional language. This value is only stored while in that module and its scope is confined to that module. However, defining scope on a wire is not as easy since the compiler can dispose of it once it has determined nothing else will access it. Scope is not as clearly defined in a dataflow language.

However since people coming from traditional languages think in terms of variables it helps to give them some concept of a variable in LabVIEW when teaching them to write code. By at least sying the wire is like a variable you can help to avoid people littering their code with tons of local variables and front panel objects.

Re: Wire = variable..... or wire != variable...

Ray.R — Wed, 25 May 2011 17:49:26 GMT

Agreed.

I fully understand what you described and agree with it. The reason I posted this thread is because often I would read replies stating that it was, myself included... For the reason that you mentionned. When I read the paragraph in the article, my first reaction was "what??!!", and then as I though about it, it made sense. Although you can proble it, the wire is more like a reference to a memory location...

I can understand why we would say it is (or is like) a variable, because you can change the value along the wire with functions, terminals (control), or property nodes, etc. With the concept that the value may vary, the closest text-base object would be the variable.

I figured I would open the can of worms with this thread and get feedback as to what we should post when people have difficulty grasping the dataflow concept or a graphical language. If you do not mind, since I like what you posted, I would use a modified version of your explanation.

Thanks Mark!

Re: Wire = variable..... or wire != variable...

Mark_Yedinak — Wed, 25 May 2011 18:06:05 GMT

No problem. Feel free to use it. Just remember to pass the kuods along. 🙂

Re: Wire = variable..... or wire != variable...

Ray.R — Wed, 25 May 2011 18:09:42 GMT

some extra ones to get you started 😉

Re: Wire = variable..... or wire != variable...

JÞB — Wed, 25 May 2011 18:18:30 GMT

I'll take a sling at it.

The wire is data

the wire has a type property (like a variable)

the wire has a buffer associated with it (like a variable)

the value in the buffer can be accessed by a DVR (like an object)

Interesting choice of terminology Data Value Referance not Wire or variable referance but a reference to the value

it has a copy method (like an object)

we pass data from function to function and node to node

we copy data from buffer to buffer where a function can modify the buffer contents

Essentially without the node the wire is not a variable. But a wire and a node together define a variable that the function attached to the node needs to operate. (I bet that's why broken wires allways break the vi. Data without use and variables without value)

Re: Wire = variable..... or wire != variable...

Yamaeda — Fri, 27 May 2011 13:24:37 GMT

A Wire is a quantum string phenomenom! It's a string in space (wire on diagram) with undefined value until you read it! 😄

Re: Wire = variable..... or wire != variable...

Ray.R — Fri, 27 May 2011 20:10:10 GMT

You're not Sheldon, are you??

Re: Wire = variable..... or wire != variable...

altenbach — Fri, 27 May 2011 22:50:04 GMT

But does the mere act of reading the value of the wire potentially change it's value? 😄

Re: Wire = variable..... or wire != variable...

Yamaeda — Mon, 30 May 2011 13:04:18 GMT

@altenbach wrote:

But does the mere act of reading the value of the wire potentially change it's value? 😄

Actually it does, since i found a bug in 2010 beta whereas a calculation would fail unless i had it wired to an indicator ...

Re: Wire = variable..... or wire != variable...

Yamaeda — Mon, 30 May 2011 13:04:54 GMT

@Ray.R wrote:

You're not Sheldon, are you??

I surely hope i'm more socially competent ...

Re: Wire = variable..... or wire != variable...

Ben — Tue, 31 May 2011 02:16:29 GMT

@Yamaeda wrote:

@altenbach wrote:

But does the mere act of reading the value of the wire potentially change it's value? 😄

Actually it does, since i found a bug in 2010 beta whereas a calculation would fail unless i had it wired to an indicator ...

/Y

LV will skip code that is not used down stream since as far back as 5.0 to my knowlege.

THe has never been a one to one relationship between wires and storage allocation. That is what made Wack-a-mole so much fun. We express out idea in the diagrms and LV inteprets what we say but rarely do we direct variables. LV decides.

Q SRs in AEs?

Variables?

Ben

Re: Wire = variable..... or wire != variable...

Ray.R — Tue, 31 May 2011 11:50:15 GMT

@Ben wrote:

LV will skip code that is not used down stream since as far back as 5.0 to my knowlege.

That clearly states it. There is no such thing as a variable in LabVIEW..

🙂

Re: Wire = variable..... or wire != variable...

F._Schubert — Mon, 13 Jun 2011 20:53:59 GMT

Just throwing in some points that pop out of my brain:

1. We must take into account the knownledge and aims of our discussion partners. If they come from a background of text-based programming languages, they ask for 'the variable' and we are right to tell them it's 'the wire'. As normal LV-users they don't really care about memory-allocation and other compiler issues. I don't think they would benefit if we would use a more scientific precise explanation such as 'the wire is the construct to be used equivalent to a variable'. Better KISS (Keep it short & simple).

2. If they are clever (in terms of math/CS), they will ask how to make a loop invariant. So we present them the shift-register. Well, that's closer to what I would think about as 'variable', 'cause the value changes (in the LV-world).

3. I just checked wikipedia on variable:

In computer programming, a variable is a symbolic name given to some known or unknown quantity or information, for the purpose of allowing the name to be used independently of the information it represents

My interpretation: So a very important point on variables is to make it human-readable like 'i' or 'pressure' and not #00123ABC. A wire doese make that identification.

Felix

Re: Wire = variable..... or wire != variable...

jwdz — Tue, 14 Jun 2011 13:19:20 GMT

I think

Controls is a data container［Controls are similar to the data container］but the controls is not variable.

Wire equal to the assignment (=)

Control data is passed to the indicator, through the line, the equivalent of an assignment

LV have variables, local variables, global variables, shared variables

My English is poor, the expression is not clear.

Re: Wire = variable..... or wire != variable...

jwdz — Tue, 14 Jun 2011 13:32:45 GMT

I think

Controls is a data container［Controls are similar to the data container］but the controls is not variable.

Wire equal to the assignment, Such as "="

Controls data is passed to the indicator, through the wire, the equivalent of an assignment

LV has variables. Such as local variables,global variables, shared variables

My English is poor, the expression is not clear.

Re: Wire = variable..... or wire != variable...

Mark_Yedinak — Tue, 14 Jun 2011 18:50:52 GMT

@jwdz wrote:

I think

Controls is a data container［Controls are similar to the data container］but the controls is not variable.

Wire equal to the assignment, Such as "="

Controls data is passed to the indicator, through the wire, the equivalent of an assignment

LV has variables. Such as local variables,global variables, shared variables

My English is poor, the expression is not clear.

Controls and indicators should not be viewed as equivalent to variables. When they are you end up with code that has tons of controls and indicators whose only purpose is to hold a value. Overuse and incorrect use of local/global variables also lead to race conditions since you are breaking dataflow simply to access data on the block diagram. (Shared variables are a little different and I generally avoid using them. I prefer to define an actual API between processes for passing data between them.)

Controls and indicators should be only viewed as user interface elements or inputs and outputs from a subVI.

Re: Wire = variable..... or wire != variable...

F._Schubert — Tue, 14 Jun 2011 19:44:22 GMT

I actually like 'jwdz's view. While it might be completely wrong concerning the LV compiler, from the user perspective it's very clear. You 'assign' one output of a SubVI/function as an input to another one (or more). This idea emphasises that no other process/operation can alter the value of that 'variable'. That's much closer to the 'signal' concept of LV/dataflow than the 'variable'.

But then again, the 'variables' (include controls and probes) are buffered test points from an EE (electrical engineer) point of view.

Hope you ('jwdz') can follow my thoughts, despite language barriers. Privately, may I ask you where you come from/are located (mainland zonghua?)?

Felix

Re: Wire = variable..... or wire != variable...

jwdz — Tue, 14 Jun 2011 20:46:43 GMT

F. Schubert 已写：

I actually like 'jwdz's view. While it might be completely wrong concerning the LV compiler, from the user perspective it's very clear. You 'assign' one output of a SubVI/function as an input to another one (or more). This idea emphasises that no other process/operation can alter the value of that 'variable'. That's much closer to the 'signal' concept of LV/dataflow than the 'variable'.

But then again, the 'variables' (include controls and probes) are buffered test points from an EE (electrical engineer) point of view.

Hope you ('jwdz') can follow my thoughts, despite language barriers. Privately, may I ask you where you come from/are located (mainland zonghua?)?

Felix

I am come from People's Republic of China (Harbin），mainland 。

Re: Wire = variable..... or wire != variable...

jwdz — Tue, 14 Jun 2011 21:25:25 GMT

True that I do not understand the LV compiler.

Controls and indicators used to store data, but they are not C language variables.

Controls and indicators is the data container (shell)。

Wires equal to the assignment, Such as "="，Similar to the an equal sign。

Wires are not a variables.

Local variables is from the controls(data) and indicators(data).

Global variables is also from the controls(data) and indicators(data)