Pass Boolean b/t parallel threads

[super-neuron]

Dear Labview Board,

I have two Labview processes that run in parallel.   One performs data input and the other data output.   They where originally designed to run independent of each other, but today I need them to perform some modest integration.   Both processes are very complex, so I would like to avoid a costly rebuild.   I'm looking for a quick and dirty solution.

I need process #1 (which is loop based) to temporarily hold execution based on a condition (Boolean indicator) in process #2.   I am not familiar with parallel processing techniques in labview, and I'm wondering if I'm making this harder than it really is.   Can I place a wait loop in one process that references an indicator in another process?   What is the easiest way to pass Boolean data between parallel threads?

Thank you,

Zach

[SteveChandler]

You need a functional global. Do a search for that and you will find many examples and tutorials.

[super-neuron]

I don't understand exactly how this works yet, but here is my first attempt at the VI.

Does this look correct?

Thanks,

Zach

[Ben]

---

@super-neuron wrote:

I don't understand exactly how this works yet, but here is my first attempt at the VI.

Does this look correct?

Thanks,

Zach

---

Take a look at this Nugget on Action Engines to see if tht can clear up some confusion.

Ben

[SteveChandler]

That's really good. I didn't reply that long ago and you are already starting to get it.

Two comments

• One key thing about Functional Globals is that they ALWAYS have a true wired to the stop terminal of the loop. The loop iterates exactly one time when the vi is called.
• You should wire an enum instead of an integer to the case selector. Make one entry "Set" or "Write" and the other "Get" or "Read". This way you can see the text in the case selector instead of a number. The enum should be a type def as well.

Definitely study the nugget that Ben posted on Action Engines. (Functional Global is your most basic Action Engine which has a set and a get method.)

[super-neuron]

Steve,

I am beginning to understand the nature of the functional global.   I made the changes you recommended and attached the VI.   Would you please review it real quick?   Between your help and Ben's nugget I feel like I can now ask an intelligent question:

My implementation only requires the passing of one boolean.   It is written in only one place, and read from only one place.   For me, what are the advantages of the functional global action engine versus a regular global variable?

Promise this is my last reply!

Thanks,

Zach

[F._Schubert]

It is written in only one place [..] global variable?

Yes.

Felix

[SteveChandler · Accepted solution]

That vi is perfect.

In your case using a variable is probably ok. But don't use a global - use a local! I would still stay away from using variables though - you never know what the future holds. Maybe you end up adding some other loop. Maybe you want to add error checking and signal the loops to stop on error.

There is an important difference between Functional Globals and just a simple variable. Since the FG is a vi only one instance can execute at a time*. With a variable you have no way of knowing who is writing or reading what or when unless you use semaphores or sequence structures.

* unless you make it reentrant

[super-neuron]

Thanks Steve!

[Ben]

---

@f. Schubert wrote:

It is written in only one place [..] global variable?

Yes.

Felix

---

"But can't I get away with just using a penny instead of a fuse for now?"

For the current application and assuming

1) the code will never change and

2) if it does change you will be that person and

3) you will remeber you used a global and

4) also remeber that gloabls have the potential of a race condition.

I code by the hour and do so such that my customers can confidently twaek their app without getting me involved. If I have to be involved, then I failed in my goal (sorta like what I do here on the forums )

So if the question is "can I get away with it?" then yes.

"Would I allow one of my rookies to do it?" NO

Ben