"...I think like a C-programer..."
This can be cured with a large dose of vitamin G on a regular basis!
Please post some code that show what you are trying to do. We provide better answers when we have visual aides to work with.
Lacking example code I will proceed to guess.
It sounds like you have a cluster control/indicator on your top level VI that gets updated from ore than one place.
You are updating it in the top level VI and the sub.
"This is bad." (Mr. Macky S. Park)
In LV and C it is not a good idea to update the same data structure from more thatn one place in your code without taking special precautions to ensure that the shared data structres are not corupted due to subtle timing issues.
STILL GUESSING!
At some point your sub VI and top level VI attempt to modify part of the cluster. If one peice of code reads the cluster, and then bundles in a new value, the other part of the code could be reading the previous contents of the cluster before the first completed. So the second reader get a copy of the old data to do its work,
BUT meanwhile the the first chunk of code now writes its updated cluster values.
The other peice of code that is using the old data now does its bundling based on the stale data and it does its update.
Bingo! Race condition.
In C you could prevent this conditon by using a protected section or mutexes to ensure that the two processes did not step on each other.
Both peices of code would first acquire a mutex before updating the shared data structure. When they were done with the update, they would release the mutex to allow others to work with the shared data.
If I got my C version goofed up, please forgive me. I gave up C years ago.
In LV alot of the low level "computer specific" work required in C is done automatically in the background. While this allows developers to concentrate on the application rather than "taming the beast",
BUT,
Sometimes the behind the scenes work can mask some issue.
One of these areas that require some special thought in LV is,
"How do I share data bewteen multiple threads?"
You can get away with using a front panel control (like I am guessing you are doing) provided there is only one writer or the control. The number of reders is unlimited. (Note: I do not encourage the practice and if one of my rookies did this, I would have to talk to them. FP controls should be thought of as as method of getting info from a user or telling them something, they are not data storage elements!).
There a many methods of sharing data between threads in LV. Above, queues were suggested, and my personal favorite is the "LV2 Global" (aka functional global, action engine, Uninitialized Shift Register, USR, ...).
THe queues functions can be found on the
Advanced>>>Syncronization >>> Queue operations pallette.
A queue can be thought of as a pipe. You can stuff wads of data in one end and the pop out the other end in the same oreder they we pushed in. I invite to explore that palette and post seperate follow-up questions as they occur to you.
Earlier I said FP controls are permisable if there is only one writer and multiple readers.
Queues genearlly adapt themselves well when you have multiple writers and a single reader.
What if you want to read and write from multiple locations?
That is where the LV2 comes in handy.
I have attached an example of a LV2 Global.
This construct is rather amazing. It takes advantage of some of LV's behind the scenes work.
1) Becuase the VI is non-Re-entrant, no two threads can execute the LV2 at the same time. This is accomplished by LV using mutexes (behind the scenes) to ensure no two threads are executing it at the same time.
2) A shift register is used to stor the data. Th shift register acts like a Static local in that it persists from call to call.
OK, I'm done rambling for this AM.
Have fun,
Ben
