Having Trouble Copy and Pasteing Local Variable in LabVIEW 2010

[Dennis_Knutson]

I can assume a lot when everyone tells you that locals in LabVIEW are a different thing than in other languages and you still complain that you successfully use locals in other languages. You still insis on comparing apples to oranges and you want the the apple to be changed to an orange.

As far as your belief that LabVIEW 2010 has a bug in copying and pasting, no one has been able to reproduce it and you have been asked to post some code that demonstrates it. No code, no proof, no bug. And just in case you are wondering, we all love to expose bugs. They get reported, they get fixed, we get a better product.

[RavensFan]

---

@dbaechtel wrote:

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 do know because I've read most of your posts.  And it seems like so many of them have a negative attitude associated with them, just like your messages have developed in this thread.  If anyone else following along feels that I am completely wrong and that none of this poster's messages have the negativity I keep sensing, them please correct me.

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.

You're right.  This thread started out as a problem you were having with copying and pasting.  So far, no one seems to have been able to replicate the problem you are seeing.  Please post a copy of your VI like Norbert asked so we can have a better chance of replicating your problem.  I think Jeff's message and Ray's message where the local is hidden in the block diagram might be pertinent.  Also, if you can post a screen shot of the problem variable, that might help in analyzing what is going wrong.

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

It's unfortunate that this thread has devolved into a locals are bad argument.  It has distracted from your original problem.  And honestly, locals are not inherently bad.  If they are used improperly or abused then you will have a lot of bad unexpected things happen in your code that you will have a difficult time troubleshooting.

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?

I don't know any other graphical dataflow programming languages, so I don't know how they differ from LabVIEW.  And as Dennis said, the concept of a local in them may be completely different from a local in LabVIEW.  I don't feel like we are "tolerating any difficulties" with LabVIEW locals.  And I don't think there is any way to avoid the problems they could cause in a dataflow language like LabVIEW if you don't use them properly.  Why?  Because locals break the concept of dataflow.

What is dataflow?  A piece of code is allowed to execute whenever all inputs to it are available.  A structure (subVI, loop, case structure, sequence structure) is allowed to end and pass out its data when all code within it has executed.  Unless you have some wire or structure that forces an order of execution between two different pieces of code, then they could be possibly run in parallel and there is nothing that prevents one or the other from executing first.  All of this is the concept of a race condition.

Here are two situations where locals are bad.  If you have a piece of code that reads a local variable in parallel to a piece that writes data to the local variable inside of a loop, what data do you get?  It could be data from the previous iteration of a loop, or the data that was written in that iteration of the loop.  It all depends whether the local write or the local read executes first.  Also, if you have two locations in the code writing to a variable, let's say one spot writes a False to a boolean, the other writes a True.  What should the value of the boolean be?  It all depends whether the True or False writing occurs first, and when the other write occurs, then that is the value that is going to be put in there.  The value of the boolean will depend on whether the writing of the True or the writing of the False happened most recently.  And those two local writes will just be banging heads against each other now and forever.

---

[Norbert_B]

I think it is a good time to tell him the reason for locals being "bad":

Local variables are (using terms of other programming languages) "call by reference" only for writing. Reading is done "by value" so each reading local variable represents a copy of the value from the control the local is linked to.

Taking into account that the local variable node does not provide an error in/out for "synchronization" purpose, the read is done any time the dataflow would allow it. This "random moment in time" for reading is commonly the reason for race conditions: you read old or new data but you never know for sure.

This is the reason for using variables (globals work the same!) should be avoided. But as different persons already posted: variables have their use and therefore cannot be removed from LV. But please do not consider variables to be botch! They simply work different compared to other programming languages.

Regarding performance:

Using the terminal/wire to transfer data is using X. Variables introduce a slight overhead. Sadly, this overhead depends on the system you are running on and on the LV version.

Just to give you some figures: I use LV 2010 and the local variable is about 10% slower than writing to the terminal for update of the indicator.

The value-property node is about 1000 times slower than the terminal due to the switching of threads (as being posted before). You can "cheat" a bit by hiding/minimizing the frontpanel, but it'd be still about 900 times slower.

This is the reason why the VI Analyzer suggests you to exchange all value-property nodes with local variables. This can be done when:

a) error in/out is not used for synchronization

b) performance matters

So please make it a rule of thumb:

- Try to avoid any type of "remote access to controls/indicators". Those mechanisms are local/global variables and value-property nodes. The latter ones lack of performance due to heavy thread swaps and all of them easily create race conditions if not used properly.

- There are situations where variables come handy and can be used. Those are most of Write Once, Read Many. But you should read the info tbob linked in his "signature" because this is an elegant way to prevent using variables.

hope this helps,

Norbert

PS: Without seeing the issue you described in your very original post, we cannot give you any valuable information about the issue. So please post code where we can reproduce this. Otherwise, you will never get any answer!

[dbaechtel]

THANKS for the useful technical information.

About my original problem. I am producing this code under NDA terms so I can not disclose any of it directly to any 3rd party. Plus it is fairly large and requires additional hardware to run. I will attempt to replicate a small example that may show the problem, but that may take some time. Have Patience.

About my use of Local Variables. I am using them in a VI that is many a State Machine. The reading and writing of Local Variables takes place in seperate States that run only one at a time by design, so it is never the case where the Locals are read or written in multiple places simultaneously. The design of the State Machine prevents this.

Also, I feel that my State Machine is already heavily overwired. Anything that any State in the State Machine deals with has to come in as an input and be sent out as in output in every State, even when the value is not changed in most States. I already have 12 wires (and there will be more) that are just wired from input to output in most States because the value is not changed in most States. I did not design the basic State Machine. I got it from JKI, who also did the VI Package Manager.

So, even with what you have explained, the careful use of some Local Variables inside the State Machine seems to be IMHO both relatively safe and beneficial.

[johnsold]

The suggestion to use a cluster is the way around the "heavily overwired" issue. Look at tbob's posting in message 23.  I have state machines with dozens of inputs and outputs and only three wires passing through each case: the state (usually a typedefed enum or a string), the error cluster, and a large typedefed cluster with everything else.  If I am passing large arrays of data, I may handle them separately rather than part of the cluster.

Lynn

[Norbert_B]

It may be ok for now to use variables. I just want to point out that maybe in the future the software will be extended and possibly a parallel loop is introduced using the same locals. Viola, you WILL run into race conditions.

Passing the data in your state machine using shift registers is therefor the suggested solution. I concur that having lots of wires/shift registers is cumbersome and can introduce difficult-to-read code. But tbob already posted the solution for this: Use clusters to bundle the data to well structured datasets.

If i use a state machine (usually as queued based consumer in a classic producer/consumer), there are up to 5 clusters i use. The depth ot the clusters should never succeed about four. If it does, you should restructure your datasets.

Please note that the depth of a cluster does not refer to its "itemcount", but nesting. But too large itemcount is not recommended as well.....

hope this helps,

Norbert

[aeastet]

Local variables can be useful tools. Most of the time there are more efficient and better ways of programming to get the proper result. If you understand how the local variable works then you can use it. It is a powerful tool but like all powerful tools you need to know when to use it or you get burned. Most people try to avoid using them to keep from having the opportunity to have a "race" or "chase" condition. There are definitely time when a local variable is the right solution for the problem at hand. Many have found way to program around them.

The overall theme here would be to be very careful using them and understand how they work or you WILL spend hours trying to figure out why your code seems to be erratic sometimes. Many people telling you this have had to find these problems at one time or another. It is no fun when you have to.

I do applaud your efforts in trying to understand how LabVIEW works. It is very refreshing. I enjoy someone truly trying to understand and not just have us do it for them. It is also nice to have discussions that all everyone to have an opinion and to discuss the pros and cons of the subject.

[Norbert_B]

I forgot to add the following info to my last post:

Using clusters for keeping the data will give you some nice features for modularization. Combining "intelligent" techniques properly will reduce development time esp. when extending/changing functionality. Clusters are perfectly suited for type definitions like TCPlomps nugget shows. This will result in nice code which is scalable.

hope this helps,

Norbert

[JÞB]

OK.  So Locals should be avoided.  There are may threads devoted to that concept.  Now, can we please, address the copy / paste issue the OP is reporting.

Dude- obfuscation with statements like  "I'm under an NDA..." and "I will try to reproduce..." leave me feeling a bit put out.  Either post an example so your question can be treated OR start a new thread on "HOW do Locals work in LabVIEW as compared to other languages."  Norbert,  the Knights, and several "heavy hitters" have contributed what amounts to one of the best compendiums on the topic of locals in recient forum history.  HMMMMMMMMMM..... maybe they know something about programming in LabVIEW that you don't- YET.  If you respect their advice they will share their VAST knowledge.  (-thanks all)

Frankly, I'm interested in the copy- paste behavior you reported for two reasons:

1. It may be a real bug on some development enviornment that would improve LabVIEW and be of benefit to the community to have on record.
2. It may be an unexpected but NORMAL consequence of how LabVIEW differentiates copy/paste and ctl+ drag operations and may help the community by exposing what the IDE is doing behind the scenes and add to the community by increasing predictablity of  behavior for similar cases- (e.g.  "darn snippet tool" vs. the famous "code capture tool" why do they have different outputs and what predictors exist that they would differ)

[tbob]

I've said it before and I'll say it again.  Labview Local Variables are NOT bad.  Its the improper use of locals that are bad.  Its the bad programmer that is at fault, not the object itself.  Don't just avoid using locals altogether, just use them properly.  That take experience and knowledge. 

Because newbies tend to use locals improperly, many veterans here have adopted the "locals are bad" philosophy.  This is really a shame, and it is what has caused this whole mess.  Instead of preaching that locals are bad, teaching the proper use of locals, and teaching proper programming techniques, like using shift registers and a cluster full of variables (see post 23), would be far more beneficial than constantly screaming how bad locals are. 

Just saying that locals are bad really gives Labview a black eye.  As the OP pointed out, why doesn't NI fix its problem?  We know that there isn't a problem, but newcomers see a statement about something being bad and they immediately assume that there is a problem that needs to be fixed.  So please, everyone, stop saying locals are bad.  They are not bad.  Stop saying avoid using locals.  Start saying that a better method of programming is to use shift registers or using the wires.  Start explaining why using locals in an improper way is improper programming.  I think locals are GOOD.  I'm glad we have them.