Having Trouble Copy and Pasteing Local Variable in LabVIEW 2010

[smercurio_fc]

---

@dbaechtel wrote:

The VI Analyzer is recommending that I replace many of my Value Variable Property Node writes with Local Variables for increased performance. Who am I to argue with the "Expert".

---

That's expected, since as noted previously, property nodes incur the overhead of switching to the UI thread. So, as I noted, in terms of purely a performace question, a local variable will be better.

---

The code you have provided is interesting but I wouldn't call it straight forward or easy to read.

---

I currently cannot open tbob's code, so I cannot comment on this.

---

It appears to me that LabVIEW has taken the simple straight forward concept of a Local Variable which is so basic to many other languages and development environments and botched the implementation so badly that people like yourselves have spent years fighting it and finding workarounds that are by no means simple.

---

You are preceding from a false assumption. LabVIEW is not a text-based program, so it doesn't have variables to begin with like text-based programs. So, you cannot compare local variables to the variables in text-based programs. They're different beasts. A local variable is just another way to access a front panel control or indicator. A similar concept to the variables in a text-based program would be if you could create a local variable that's tied to a wire rather than a front panel object.

I think the fundamental problem you're having is that you are trying to program LabVIEW like a text-based language. That's ultimately self-defeating and just causes aggravation.

---

What is going on here? Why doesn't NI just fix the problems with their development environment?

---

Well, there really isn't anything to fix. It's a different language. Would you say that Pascal has to be "fixed" so that it programs like Perl?

---

Please hold the flames unless you can provide a good justification for the current state of affairs.

---

I wasn't aware that anyone was flaming you in this thread. I think you may be letting your frustration cloud the statements that are being made.

[Dennis_Knutson]

Local variables are not at all 'botched'. You just have to remember that LabVIEW is different than the text programs you are used to using. LabVIEW is based on dataflow and is inherenty parallel. A local breaks dataflow and forgetting that means that you can have race conditions unless your program is correctly designed. A local serves very specific needs and if used correctly, are indespensible. One of the worst uses of locals in LabVIEW is when someone uses one (or a value property) to avoid long wire runs. That just about guarantees a race condition at some point.

[tbob]

---

@dbaechtel wrote:

The code you have provided is interesting but I wouldn't call it straight forward or easy to read.

---

Here is a picture of my code for others to see.  Well it just shows one case.  However, this is very straight forward and very easy to read to anyone with Labview experience, but maybe not to a person with only text language based experience.  It shows a cluster element being unbundled, incremented, and bundled back again.  This is very simple code.  You really need to learn Labview by taking the online tutorials.  Then you will see how easy this is.  As others said before, the variables are the wires.  In this case, three variables are bundled together on one wire.  They can be separated (unbundle), operated on (+1), and put back together onto one wire (bundle).

In text based languages, the flow is executed step by step.  The only way to store values is to use a local varaible.  Not so in Labveiw.  The execution depends on the wiring.  Values are stored in the wires.  Labview local variables should not be used the way they are in text based languages because they are not the same thing.

[dbaechtel]

Quote:

"Well, there really isn't anything to fix. It's a different language. Would you say that Pascal has to be "fixed" so that it programs like Perl?"

You don't think that the unexpected race conditions and all the problems that people have warned might occur when Local Variables are used is not a problem that can and should be fixed?

[dbaechtel]

I have written many Data Flow programs in ISO IEC-61131-3 standard Data Flow Diagrams and none of them have this horrendous problem with Local Variables that you all warn that LabVIEW has. I do not believe that Local Variables are at odds with Data Flow graphical programming at all. It just appears that LabVIEW has their implementation tangled up.

[Dennis_Knutson]

No, there is nothing to be fixed and you are comparing apples to oranges. The local in LabVIEW is not what you have used before. The local you are used to is either the value property or what is called a 'functional global'. The functional global precedes the local introduced somewhere around version 3. What is called a local in LabVIEW was deliberately designed to be disconnected from dataflow. I have no idea if it this type of variable is unique to LabVIEW but it is important to understand all the variable types and not get hung up on a label. Perhaps you can call it something other a local in your head to make the distinction clear. As has been mentioned many times, a LabVIEW local variable is not at all the same as programming language x local variable. If you want to use it, you have to understand the rules under which it can and cannot be used. If you have no interest in learning those rules, use the LabVIEW variable types that are the same as what you are used to.

p.s. a race condition is never unexpected by a programmer who really understands the implementation in LabVIEW. We can spot them a mile away when a beginner uses them without first learning what they are.

[dbaechtel]

The point is, there should be no case where Local Variables cannot be used in a LabVIEW application. You should be able to use it in any case where the developer feels that it is appropriate. In other languages and graphical Dataflow programming environments this is true. I don't understand why it has to be a problem in LabVIEW. I don't understand why it can not be fixed so that they don't misbehave and cause race conditions.

[RavensFan]

I'm glad you really seem to be trying to learn LabVIEW.  You certainly have posted a lot of questions about different issues you've been having.

But if you are already expecting to get flamed by your questions, I can only suspect it is because of the questions you are asking.  Or more precisely the way you are asking them.

It seems that every question you ask has had a negative attitude with it.  "What's wrong with LabVIEW? "   "I found a LabVIEW bug" (when upon further investigation you actually haven't) "Why did NI botch local variables?" 

It seems like you are fighting LabVIEW rather than trying to work with it.  Like you are trying to coerce LabVIEW to fit within preconceived conditions you've learned from other programming languages including other "ISO data flow diagrams."

Please start asking questions in a more positive manner, and I think you'll see fewer responses where you feel you're getting flamed.

Rather than

"I found a LabVIEW bug" try "Did I find a LabVIEW bug?  This is not working the way I expected."

Or "LabVIEW's broken!  What's wrong with it?" try "I want to LabVIEW to do this like I do whatever in C, or however in another dataflow language.  How do I do it here?"

I'm going to assume you've already done the online tutorials.  And it seems like you are willing to make a time investment in learning how to use LabVIEW to do whatever your job requirements might be.  You are asking questions on much more advanced topics then the typical "How to I write my data to an Excel spreadsheet?" like we see everyday from all the first time LabVIEW users.  It might be time to invest in a book or two about LabVIEW.  Perhaps sign up for some of the LabVIEW courses.  If you come from a different programming background, some of the concepts that are the core of LabVIEW are at odds with how things work in a text based language and can seem foreign.  With a good book or two, and/or further training, I'm sure you'll be able to learn how to work with LabVIEW rather than fight against LabVIEW, then your posts will lose that level of frustration/negativity that they seem to have quite frequently right now.

[Dennis_Knutson]

Forget it. I tried to explain but it seems you are still hung up on insisting that all language elements have to fit into ther small little world that you are comfortable with. LabVIEW has features that brain dead plc language will never have. To bad you are not willing to learn about them.

[dbaechtel]

You make all kinds of assumptions and statements that are not true.

I wish that you would stick to just the facts.

I did not say many of the things or say them in the way that you claim. You do not know, and yet you propose to know, what I have done and not done.

I did not say that Local Variables were BAD or should not be used. I just said that I was having trouble copy and pasting them.That is still the case and apparently no one cares about that issue with LabVIEW 2010.

Many of you immediately told me that using local variables were BAD and should be avoided apparently at all costs.

Now, since many of you have brought it up, I am trying to get at the reason as to WHY that should be the case. WHY are Local Variables such a problem when used in LabVIEW? In other graphical dataflow programming environments they are not a problem and can be used freely without such difficulties. WHY are LabVIEW users willing to tolerate such difficulties when there is no other excuse than "that's the way it is" ? Why can't someone ask "Why does it have to be this way?" without being beaten down so badly?