Variable not always updated from a local

[Rhayes]

 I have a Cluster of booleans and I have a few locals around my program writing and reading bundles. If I place a probe on the local that is changed and one on the cluster itself I notice that the cluster isn't always updated. Also I have noticed that is I placed probes on the wires feeding the bundles then they update a little more frequently but not 100% of the time.

I admit I'm a novice to labview and that I probably should not be using locals but I know of no other way.
Can someone provide a solution or maybe another way instead of using locals?

Ron

[kehander]

Not quite sure from that little bit of code alone, but it sounds like you're encountering a "race condition" - one of the dangers of using local variables. If you're writing to a local variable in one part of your code and trying to read from the same variable somewhere else, sometimes the outcome can be unpredictable.

You can either try to remove some of your local variables, or if you must use them, try to introduce better flow control. Sometimes you can do this by wiring the error terminals of particular VIs, but you might need a flat sequence structure instead.

The optimum way would be a state machine, actually, but that might be a little complicated if you're new to LabVIEW.

Message Edited by kehander on 09-05-2006 01:44 PM

[Rhayes]

Well I can't provide the whole code since it's way too large and you can't run it unless you have the hardware as well.

I understand state machines, I'm actually an embeded programmer that is used to assembly but now I have been thrust into the very different world of Labview.  This code is for the most part a state machine, except for the external VI's. I didn't want to have wires going from one end of the program to the other. I am actually using 20 locals on the one cluster, 2 per bundle.Would it be better to route the cluster wire around the program?

Ron

[JulieC]

With the caveat that I don't know exactly what you are trying to do ...

I think you need to get rid of allllllll the local variables.  Bad bad.  I had to experiment because I've never used them.  Here is a custom control and a VI that uses them.  Is this along the lines of what you are trying to do?  I'm not going to explain unless it is.  Two concepts you (probably) need to learn:

• Custom controls
• Unbundling clusters

[Ben]

Hi Ron,

I think kehander was correct in calling this a race condition.

In this thread we talk extensively about how evil globals are and you will find many of the issues with globals are shared by locals.

http://forums.ni.com/ni/board/message?board.id=BreakPoint&message.id=2362&jump=true

The race condition in your code happens when the state of the cluster is read as shown here

Then the cluster value is read again here

which gives them both a copy of the "before" data.

THEN you do the bundle and write the results to the indicator.

MEANWHILE the other code does a bundle using the "before" data and writes the modified cluster over-top of the data that was written by the first writter of the local.

If you read the posting by Roberto ( a C programer) you will see that this issue is not just a LV issue.

The issue boils down to "TWO Writters".

How to avoid this?

The hard way:

You can create a semaphore that must be acquired before writting or reading and then you various code snippets use this flag to controll access to the control. I have only had to resort to this approach once (let's not go there).

THe easy way:

Use a LV2 global! See the LAVAL FAQ here for more background info.

http://forums.lavag.org/index.php?showtopic=273

In a LV2 the data is stored in a shift register inside a sub-VI. Since only one VI can call a sub-VI at the same time (Re-entrant VI will not work here) the code that modifies your data structure is protected from race conditions.

I hope that helps,

Ben

[altenbach]

---

@Rhayes wrote:
If I place a probe on the local that is changed and one on the cluster itself I notice that the cluster isn't always updated.

---

You cannot place a probe on a local variable or on an indicator terminal. Probes are always on wires. The wire receives only new data whenever it gets serviced by dataflow while a terminal can also get updated if one of the local varables receives new data. This will then not be reflected on a probe on the wire leading to the terminal. And vice versa...

What exactly are you doing?

[Rhayes]

Sorry let me clear that up, I place my probe on a wire closets to an indicator, I realise that they cannot be placed on an indicator.

I am in the process now of doing away with the locals and I'm sure that will sovle my problem, since I am seeing the probes flickering to the on state. I think there are two writers as previously stated.

Thanks for the insight.

Ron

[Rhayes]

I have now changed from using LOCALS to an LV2 Global and I'm still not able to change all of the Booleans, they change localy (I put a probe on the wire leading to the LV2 global from my bundle)  but when the read is done to send the values out to the PLC only the first four have changed.

Ron

[Ben]

HI Ron,

Could you please post a small set of VI's that demonstrates the problem you are having now?

Trying to help,

Ben

[Rhayes]

From these two pictures you can see that probe#18 reads the first 4 booleans properly( they even change correctly) but the last 4 never turn on.

In the other pic Probe#19 show what should have been transfered to the PLC05.

How can only some of the data make it but not all of it?

(btw, I know I have more Locals but I want to get this one working first before switching them all and making a mess)

Ron

Message Edited by Rhayes on 09-06-2006 01:50 PM