Suggestions for using many event structures in one top level VI

[QuantumPenguin]

Hello all,

I have a rather large VI which has many event structures (over ten) each doing a different thing (controlling different parts of an experiment) each is surrounded by its own while loop with a wait of 1000 ms.

Is there a more elegant way of handling many event structures in a top level VI, I am thinking about  implementing the following:

http://digital.ni.com/public.nsf/allkb/A882E27D1D7A949386256E0D0066B91A

I know this won't solve the many while loop problem but it will reduce the block diagram a fair amount.

Any suggestions would be greatly appreciated.

Cheers all

[billko]

---

@QuantumPenguin wrote:

Hello all,

I have a rather large VI which has many event structures (over ten) each doing a different thing (controlling different parts of an experiment) each is surrounded by its own while loop with a wait of 1000 ms.

Is there a more elegant way of handling many event structures in a top level VI, I am thinking about  implementing the following:

http://digital.ni.com/public.nsf/allkb/A882E27D1D7A949386256E0D0066B91A

I know this won't solve the many while loop problem but it will reduce the block diagram a fair amount.

Any suggestions would be greatly appreciated.

Cheers all

---

LOL, my responses range from "What a brilliant idea!!!" to "What were you THINKING???" but we'll never know until you upload the actual VI you are talking about.

[altenbach]

Why would a loop containing an event structure need a 1000ms wait? While this will throttle the number of event that can be handled in a give time, it could also inflate the event queue.

All this seems rather weird and I am sure there are better alternatives. Can we see some code?

[QuantumPenguin]

I know It would be far more helpful to upload a VI, but it is ridiculously large I'm unable to upload it. I can upload an image? Essentially the VI consists of 13 event structures, each surrounded by its own separate while loop. The code inside each event structure is pretty varied, some is very simple, others have very large amounts of code - which could be VI's in their own right.

The main problem is that the block diagram is now ridiculous, and also I just hate the solution. There must be a less crude method than what is currently used. 

[billko]

While the VI would be better, of course, I think a picture of the BD would help somewhat.  Fire away!

[crossrulz]

---

@QuantumPenguin wrote:

I have a rather large VI which has many event structures (over ten) each doing a different thing (controlling different parts of an experiment) each is surrounded by its own while loop with a wait of 1000 ms.

---

General rule: A VI should only have 1 event structure.  It really sounds like you need to re-architect this code.  Have you looked into a Queued Message Handler (often incorrectly called a Queue State Machine and very similar to a Producer/Consumer)?  The idea is that you have 1 loop that handles UI events and the processing is passed to another loop via a queue.  That second loop just reads messages and does whatever it needs to with the message.  It gets a little better.  You can many QMHs, each doing their own job.  So you can make your big, giant VI into many VIs that run in parallel and talk over Queues and/or User Events.  This is actually called Actor Oriented Programming, so you might want to have a look at the Actor Framework as well.

[Ben · Accepted solution]

---

@QuantumPenguin wrote:

Hello all,

I have a rather large VI which has many event structures (over ten) each doing a different thing (controlling different parts of an experiment) each is surrounded by its own while loop with a wait of 1000 ms.

Is there a more elegant way of handling many event structures in a top level VI, I am thinking about  implementing the following:

http://digital.ni.com/public.nsf/allkb/A882E27D1D7A949386256E0D0066B91A

I know this won't solve the many while loop problem but it will reduce the block diagram a fair amount.

Any suggestions would be greatly appreciated.

Cheers all

---

While my implementation of that approach is slightly different, I agree with that approach. Doing so lets me break up my application into separate parts for each type of instrument I am using.

One example top level diagram looks like this.

and a typical sub-VI looks like this.

Works great, easy to maintain, and re-use code it easy to harvest.

Ben  

[Bob_Schor]

---

@QuantumPenguin wrote:

I have a rather large VI which has many event structures (over ten) each doing a different thing (controlling different parts of an experiment) each is surrounded by its own while loop with a wait of 1000 ms.

---

Quantum,

     I'm guessing that when you say "a rather large VI", you mean one whose Block Diagram does not fit on a single (even a 27") monitor screen.  That's your first problem -- all of your VIs should be relatively modest in size (which is most easily accomplished by using lots of sub-VIs to encapsulate functionality and using design patterns like the Queued Message Handler to manage program flow).

     You don't say (and we can't see) how the Event Structure communicates with the rest of the program.  There is something to be said for having a single Event Structure, and letting it run "full speed" (since it takes no CPU time if there are no Events, having a Wait to slow it down doesn't make a lot of sense).  Note that if by a "Wait of 1000 msec" you mean you programmed a TimeOut Event for 1000 msec, that's another story, since that (in principle) won't hamper your loop responsiveness.

Guess we really need to see this "interesting" VI to be of more help.

Bob Schor