Running SubVIs with state machines in parallel

[braxat2000]

Hi,

I'm new to labview, working on it for a couple of weeks.

I'm building an application where there are a number of identical elements atht each is controlled by an identical state machine which is independent from all others.

My problem is how to place each state machine in a subvi and running them in parallel.

Each of the subvi has a while loop for the state machine, and the program gets stuck inside never entering another subvi.

Is there an elegant way to run a couple of SubVIs each holding a state mchine in parallel?

I come from the VLSI world so there is no problem implementing this kind of logic in hardware description language but the labview way to do it eludes me...

thanks you very much for any help,

Eyal.

[AdnanZ]

You can definitely do this. Your question seems a little vague. Is it possible for you to post your project that has the main VI and a couple of subVIs, so we can visualize the issue, and resolve the issue quickly.

[Stranman]

If all you're asking is how to run parallel instances of the same function, while each maintains their own state information, then all you need to do is enable Reentrant Execution.

VI Properties >> Execution >> (Check) Reentrant Execution

- Preallocate Clone for each instance

Hope this helps; otherwise, please post code to clarify your question.

-P

[tbob]

---

braxat2000 wrote:

Each of the subvi has a while loop for the state machine, and the program gets stuck inside never entering another subvi.

---

You probably have an output of one subvi wired to an input of another subvi.  If this is so, the second subvi will not execute until the first is finished because that is how Labview works.  Data dependency.  A section of code will only execute when all of its inputs are present.  If the second subvi takes an input from the first subvi, then the first subvi must complete before the second can start.

To run your subvi's in parallel, you need to eliminate any wires that are outputs from one subvi connected to inputs of another subvi.  Then both subvi's will run in parallel.  If you post your code, we can confirm this or find out what the problem is.

[braxat2000]

Hi,

Thank you everybody for your kind help.

The problem was solved and my application is ok now.

For future reference,

I used the execution reenter subvi to allow multiple instances of it in parallel, and added a global variable that the subvis can change, and the main can read from.

Used semaphores to make sure correct parallel write to common sources.

Cheers,

Eyal.

[JÞB]

---

@braxat2000 wrote:

Hi,

Thank you everybody for your kind help.

The problem was solved and my application is OK now.

For future reference,

I used the execution reenter subvi to allow multiple instances of it in parallel, and added a global variable that the subvis can change, and the main can read from.

Used semaphores to make sure correct parallel write to common sources.

Cheers,

Eyal.

---

Great solution- but how to avoid race conditions in the global variable?  Globals are notorious for causing headaches, nightmares and nausea so if there is a way to avoid them and enforce a bit of cause- effect its highly desirable.  In this case you have clones of a re-entrant vi running in parallel so you CAN'T use a functional global (the most common solution see Ben's famous Action Engine nugget)

Since we can't enforce data dependence we need something else as a cause-effect team..... Change event dependency would be a good substitute.  Two methods for getting this type of dependence would be a dynamic event or my favorite the "Named Queue"  set the data type of the named queue as a cluster of instance of source and data from your global and the main loop will be able to see EVERY write to the queue AND the source.  Moreover the queues datatype can be expanded to offer any information the main vi needs to be a good executive. In fact a new sub vi that "monitors status" of the clones would make the application highly scalable and robust. 

[JÞB]

If course I stopped a step short of nirvana.  For those of you that missed it-

The re-entrant clones each have their own state information so there is a bottleneck accessing common resources.  The OP used semaphores to control access but the Named Queue would work as well.   IF all the resource access was through a single consumer of the named queue the semaphores and global variables could both be done away with and the queue would process all requests in the order they arrived.

[braxat2000]

Hi,

Thank you very much for your answer,

I'm still learning Labview, so in time I hope to be able to use more complex features of the tool.

For now I use semaphores when writing to the global data base, and as my application resolution run on a slow clock it looks like I solved race problems.

In faster applications the semaphore use may cause overhead delays, but for now it is ok,

thanks again,

Eyal.

[JÞB]

Glad to have been helpful!  these little "thought experiments" are an interesting means of practice and a valuable reasource for me as well-  See you around!