Having Trouble Copy and Pasteing Local Variable in LabVIEW 2010

[smercurio_fc]

---

@dbaechtel wrote:

What is the difference between reading from a Local Variable which contains the Value of a Front Panel Numeric Indicator and reading from a Variable Property Node that reads the Value of the same Front Panl Indicator?

---

Reading from a property node causes a switch to the UI thread.

---

Why does one tend to give you a race condition and the other does not?

---

Actually, both can lead to a race condition. The difference is that the property node has error terminals, which allows you to enforce execution order by using dataflow. The local variable have no error terminals, so when they actually execute is indeterminate. The LabVIEW compiler will decide when they actually get executed, not you.

[smercurio_fc]

---

@dbaechtel wrote:

I can not use a Global Variable or FGV because this is a reentrant VI and the method used must be Local to the Instance of the VI.

---

Reentrancy has no bearing on using a global variable or a functional global variable. You can have a reentrant VI and still use a functional global variable. The reentrant VIs will need to wait for the functional global variable (a.k.a. Action Engine) to finish being used by another instance, but that's usually fairly small, especially if the FGV is designed to be efficient.

I would agree with the suggestion that you post your code.

[Norbert_B]

I think he has to have different values in the "variable storage" for each reentrant instance. Therefore, a FGV is really not the need mechanism.

The problem of variable/value-property nodes is:

Maybe it does not create a race condition NOW, but if you change something in the code, it possible CAN INTRODUCE it.....

I suggest you either working with a proper VI architecture which will enable you to work with shift register (state machine) or using queues (producer/consumer).

But for real valuable hints, you have to post your current approach.

hope this helps,

Norbert

[smercurio_fc]

---

@Norbert B wrote:

I think he has to have different values in the "variable storage" for each reentrant instance. Therefore, a FGV is really not the need mechanism.

---

I didn't quite get that from reading the posts, but I don't discount the possibility.

[dbaechtel]

---

@smercurio_fc wrote:

---

@dbaechtel wrote:

What is the difference between reading from a Local Variable which contains the Value of a Front Panel Numeric Indicator and reading from a Variable Property Node that reads the Value of the same Front Panl Indicator?

---

Reading from a property node causes a switch to the UI thread.

---

Why does one tend to give you a race condition and the other does not?

---

Actually, both can lead to a race condition. The difference is that the property node has error terminals, which allows you to enforce execution order by using dataflow. The local variable have no error terminals, so when they actually execute is indeterminate. The LabVIEW compiler will decide when they actually get executed, not you.

---

Can't switching to the UI thread potentually cause performance problems for VIs that require high performance (frequent updates, minimal delays).

In this case, wouldn't using a Local Variable be better because it does not cause a switch to the UI thread?

[JÞB]

Getting Back to the subject!  (as an aside we've probably flamed the OP enough for Localitis- 2010 still has them on the palattes in both data communications And structures so they should work)\

My system 2010 on xp does not exhibit the OP reported trouble of bad copy/paste.

Instead I get the expected functionality of Ctl+drag creates a new instance of a local tied to the same FP object.  Ctl-C Ctl-V creates a new FP object with a local variable on the BD.  The relationship of the Local and the new Terminal have the same X-Y offsets as the original.

So, If I dropped a CTL-V local inside a structure without autogrow the new terminal would often be hidden beyond the border of the structure! 

OP is this what you are seeing?  Turn on auto grow, try auto clean-up or use the VI analizer to check for hidden objects.

[smercurio_fc]

---

@dbaechtel wrote:

---

Can't switching to the UI thread potentually cause performance problems for VIs that require high performance (frequent updates, minimal delays).

---

Yes.

---

In this case, wouldn't using a Local Variable be better because it does not cause a switch to the UI thread?

---

Define "better". If it's purely a performance "better", then yes, it's "better". Though not as "better" as a wire. If it's a "proper coding practice" "better" then no, it's not better or worse for the reasons stated.

[Ray.R]

---

@Jeff Bohrer wrote:

Getting Back to the subject!  (as an aside we've probably flamed the OP enough for Localitis- 2010 still has them on the palattes in both data communications And structures so they should work)\

My system 2010 on xp does not exhibit the OP reported trouble of bad copy/paste.

Instead I get the expected functionality of Ctl+drag creates a new instance of a local tied to the same FP object.  Ctl-C Ctl-V creates a new FP object with a local variable on the BD.  The relationship of the Local and the new Terminal have the same X-Y offsets as the original.

So, If I dropped a CTL-V local inside a structure without autogrow the new terminal would often be hidden beyond the border of the structure! 

OP is this what you are seeing?  Turn on auto grow, try auto clean-up or use the VI analizer to check for hidden objects.

---

I'm with you.  I've already mentionned that using a wire is a more appropriate approach to the solution.  Once we see the code, we can explain how to do it..  So with respect to the original post, I've asked some similar questions.  I suspect the local was created, it is simply not seen.

---

@Ray.R wrote:

So if I understand correctly, you are trying to copy & paste the Local Variable from within the same VI.  How large is your block diagram?  Did you try right-click on the variable and select "Find > Local Variables"?  If it's a block diagram larger than 1 single screen (which it shouldn't), then it is possible that the Local is hiding beyond the screen.  You should find it as I described earlier.

---

---

[tbob]

It seems as if you want to manipulate one or more variables at different states of your state machine.  The attached vi (LV2010) shows the proper way to do it.  Instead of using local variabls, use a cluster of constants and a shift register.  The cluster can be called "Local Variables".  Wherever you need to change the value, set the value, or read the value of one or more cluster elements, use unbundle and bundle. 

This is much better that using actual local variables because it prevents race conditions, keeps the code neat, and makes it easier t read.  Trust us.  We are not telling you to avoid local variables to be mean or bossy.  Most of us have learned the hard way.  We preach this to every newcomer, and even some oldcomers because we know the havoc it can cause. 

Even though locals seem to work fine now, one day in the future, all of a sudden, you will be posting here saying how your code worked for months, and now it isn't working.  This is a typical race condition rearing its ugly head.  So please follow the advice of people who learned the hard way.

[dbaechtel]

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

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

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.

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

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