Data transfer, synchronization, and stopping multiple loops.

[J.Mamakos]

I've recently made a few changes to the main structure of my project and, although it does still seem to work fine, I was wondering if this was actually a robust structure or if I was inadvertently doing something very wrong!  The main changes were to how the main vi shuts down, and to the organisation of the synchronization primitives (queues, rendezvous, occurrences).  I enclose an example vi that I put together to show the systems I'm using.  Also, you might be able to get a good overview from the picture below:

The two 'True' cases in the slave loops merely wire the selector terminal to the boolean output to the conditional terminal of the while loops.

I have obviously not included everything and have made some simplifications to the loops, but everything from the synchronization pallet is as it is in my project.  Could I have some feedback on this if possible, please.  I got to where I am now largely through trial and error, exploration, and a few helpful nudges from some people in this community. 

- James

[J.Mamakos]

I am also wondering if there is a way I can initialize the two queues from inside the Master Loop?  In the main project, the main data cluster is actually initialized inside the Master Loop with default/initial values... but I also have this second cluster of 'empty' values/elements outside the loop (containing some of the data from the main data cluster) to initialize the queues.  This seems unnecessary to me, but is there actually a way around it?

[Mark_Yedinak]

I prefer to have my consumer loops accept explicit messages and not just a single data element. By using this methood you can define an explicit Stop/Exit message that you post to all of your consumers. Also, it is a good practice to release the queues outside of all the loops after each has processed the stop command. Also, an explicit stop message eliminates the need for your consumer loops to poll the Stop button. They would simply wait on the queue for the next message. I am not a big fan of polling architectures.

As for your "initialization" of the queues, you aren't really initializing them but simply creating them. They should be outside of the loops.

[J.Mamakos]

Thank you for clearing up my queue creation query.

---

@Mark_Yedinak wrote:

I prefer to have my consumer loops accept explicit messages and not just a single data element. By using this methood you can define an explicit Stop/Exit message that you post to all of your consumers. Also, an explicit stop message eliminates the need for your consumer loops to poll the Stop button. They would simply wait on the queue for the next message.

---

Could you elaborate on what you mean by the explicit Stop/Exit messages, and/or how you would implement them?  I'm not sure I completely understand where you're coming from.  

[J.Mamakos]

A minor point for clarification:

I understand why not to always use continuous polling architecture (that's why I now use event structures and queues, etc) but I'm just not sure how what you suggested could be implemented at the moment.  However, I'm more than willing to change anything that will be of benefit (to the program itself or just to my LabVIEW skill set / knowledge).  

[Mark_Yedinak]

Here is a basic example of using explicit messages to control things.

Note: The snippet got a bit messed up. Use th ecode from the zip file.

[J.Mamakos]

Are you able to down-save it for as low as LabVIEW 8.5?

[Mark_Yedinak]

Here is an 8.0 version I had. Let me know if this works for you.

[J.Mamakos]

---

@Mark_Yedinak wrote:

Here is an 8.0 10 version I had. Let me know if this works for you.

---

Downwards, I say, downwards!  Not up!  

[Mark_Yedinak]

Let's try this once more.