Why wont these globals update?

[RTSLVU]

I have only used globals once or twice before and they always seemed to work out for things like one VI running in the background continusly polling an instrument then have other VI's just read the global.

That does not seem to work in this case. The arrays in the global never change and are always the default value.

I know you will not be able to run the attached code without one of our boards, but at least you can tell me if I am doing something that is just plain wrong....

[Henrik_Volkers]

Don't use globals for such kind of architecture. You will easely run into race conflicts. Switch to a functional global or to an action engine (read more about it here).

[Yamaeda]

I cant open your file, so i'm taking a stab in the dark.

A common problem is to wire a variable to a loop or similar, but forgetting to feed it back to the next loop (e.g. by shift register). Thus you'll only ever update the same initial variable over and over.

/Y

[MikeS81]

Hi RTSLVU,

maybe the local variables in your for loops are the problem. Why do you need them? Did you try it without them? Can you upload an example with valid values for the for loop process?

Mike

[smercurio_fc]

Have you verified that the subVIs are actually generating values? Are the subVIs generating errors, and hence no data?

Your code has a number of flaws.

• The use of the global variables has already been pointed out.
• The use of the local variables has already been pointed out, and it's worse than you think. For example, in the "Get XM Counters" VI you are reinitializing the front panel values with each iteration. Furthermore, you are creating a race condition with those indicators that are updated by the subVIs that have an output that's actually wired to one of those indicators (e.g., the "Image$?" indicator).
• In the aforementioned subVI you execute a for-loop, but the outputs are not autoindexed. Thus, only the last value is actually sent to the indicators. Is this intended?

[RTSLVU]

---

smercurio_fc wrote:

Have you verified that the subVIs are actually generating values? Are the subVIs generating errors, and hence no data?

Your code has a number of flaws.

• The use of the global variables has already been pointed out.
• The use of the local variables has already been pointed out, and it's worse than you think. For example, in the "Get XM Counters" VI you are reinitializing the front panel values with each iteration. Furthermore, you are creating a race condition with those indicators that are updated by the subVIs that have an output that's actually wired to one of those indicators (e.g., the "Image$?" indicator).
• In the aforementioned subVI you execute a for-loop, but the outputs are not autoindexed. Thus, only the last value is actually sent to the indicators. Is this intended?

---

The VI's work fine on their own and I tossed in the globals so other vi's could use the data. I thought that's what globals were for?

I looked at the "Action Engine" example and don't really understand it...

The locals in that reinilialize the indicators in that vi are because I was worried about stale data. I had noticed during development that fir instance the "Image$?" indicator would still be true from the last time the VI was called, maybe I am over thinking it as teh indicators are only there for trouble shooting?

Yes the subVI's for-loop output is not auto indexed bacause in reality it should only run once and exit but the for loop makes it try up to three times befire failing. Hence the last iteration is the only ouput that I care about.

[Ray.R]

---

RTSLVU wrote: 

The VI's work fine on their own and I tossed in the globals so other vi's could use the data. I thought that's what globals were for?

---

You mean the VI that you posted worked fine?   Globals in LabVIEW....  Well your statement is correct for text-based languages.  For LabVIEW, other than giving headaches and storing static data, I'm not sure what else they are good for..  (we often have debates on the subject 😉 )

---

RTSLVU wrote: 

I looked at the "Action Engine" example and don't really understand it...

---

Action Engines or Functional Globals are not that complicated.  Functional Globals uses an un-initialized shift register to keep the last value from the previous run.  So they are often used as a means of sharing data.  Their safety (or safeguard) is that the Functional Globals use states to initialize, write a new valus, read the last value, and optionally reset the value (although initialize may do the same thing).

---

RTSLVU wrote: 

The locals in that reinilialize the indicators in that vi are because I was worried about stale data. I had noticed during development that fir instance the "Image$?" indicator would still be true from the last time the VI was called, maybe I am over thinking it as teh indicators are only there for trouble shooting?

---

You should initialize values on wires outside a loop (before entering the loop).   And you should avoid using Locals at all cost.  The variable in LabVIEW is the actual wire, so there is no need to "pass" a value.

[Ben]

---

RTSLVU wrote:

...

The VI's work fine on their own and I tossed in the globals so other vi's could use the data. I thought that's what globals were for?

I looked at the "Action Engine" example and don't really understand it...

The locals in that reinilialize the indicators in that vi are because I was worried about stale data. I had noticed during development that fir instance the "Image$?" indicator would still be true from the last time the VI was called, maybe I am over thinking it as teh indicators are only there for trouble shooting?

Yes the subVI's for-loop output is not auto indexed bacause in reality it should only run once and exit but the for loop makes it try up to three times befire failing. Hence the last iteration is the only ouput that I care about.

---

If you are serious about developing multithreaded code that must share information, please find some time to go back and read that Nugget again and post follow-up Q's in that thread if you still need help.

We wrote that Nugget to teach about one of the most simple methods for sharing data between threads in a way that can avoid race conditions. Race conditions can introduce just enough chaos to make it difficult to fully understand what and how LV works and can lead to great frustration on your part.

In those sub-VI, toss all of those local writes and try the code again.

Ben

[RTSLVU]

---

Ben wrote:

---

RTSLVU wrote:

...

The VI's work fine on their own and I tossed in the globals so other vi's could use the data. I thought that's what globals were for?

I looked at the "Action Engine" example and don't really understand it...

The locals in that reinilialize the indicators in that vi are because I was worried about stale data. I had noticed during development that fir instance the "Image$?" indicator would still be true from the last time the VI was called, maybe I am over thinking it as teh indicators are only there for trouble shooting?

Yes the subVI's for-loop output is not auto indexed bacause in reality it should only run once and exit but the for loop makes it try up to three times befire failing. Hence the last iteration is the only ouput that I care about.

---

If you are serious about developing multithreaded code that must share information, please find some time to go back and read that Nugget again and post follow-up Q's in that thread if you still need help.

We wrote that Nugget to teach about one of the most simple methods for sharing data between threads in a way that can avoid race conditions. Race conditions can introduce just enough chaos to make it difficult to fully understand what and how LV works and can lead to great frustration on your part.

In those sub-VI, toss all of those local writes and try the code again.

Ben

---

I took out the locals and the VI's still run (I knew it would run without them as actually added them in as an after thought anyway).

To my supprise the globals now work right too. (???)

I will give the Action Engine a closer look.

Thanks for your advice.

Message Edited by RTSLVU on 05-05-2010 11:17 AM