LabVIEW
Best way to structure code to control multiple instruments
Solved!
You're playing with fire when using multiple event structures. My preferred method for running an instrument that has a "stream" mode (example: a spectrometer where you want to continuously see the spectrum), is to give that it's own loop, with a dequeue element. The "element" can have a message (or state) portion in the form of an enum or string, as well as some data in the form of a variant. Say you want to set a parameter, you could send a cluster containing the "Set Parameter" enum as well as the value of the parameter in the form of a variant. The default case would be to obtain a spectrum and update a graph (or send yet another message to a UI handling loop that updates the graph).
You can open up the QMH Project Template that ships with LabVIEW to see how one queue might work, and then you can add multiple queues for different instruments. I keep the new loops in their own SubVIs and the queue reference in a functional global to clean up the main block diagram.
Here is an example of what your module stream case might look like (the empty string constant seen as double quotes is default from the dequeue message timing out)
First! EXCELLANT question!
You stated that you have multiple event loops in the top level vi. This may be unwise. I'm not looking at your specification documents so, I won't state it as a surity however, generarally it is a poor choice to involve multiple event structures interfacing with a single user.
Have you looked into the Actor Framework? I typically avoid it because my clients are uncomfortable with it yet, from what you describe, it may be a good choice for you.
Another option you may wish to consider is "Simplifying" the GUI. Some Actions may be combined into a "Do this Sequence" rather than take "These independant Steps" and the USER can assist you greatly in telling the story of how the ideal interface should behave.
I would also agree that the Queued Message Handler is the way to go here. It is very similar to a Producer/Consumer. But the idea is that you have a loop and a queue for each instrument. You then just send messages to the insturment handler with the corresponding queue whenever you want something done with that instrument. Keep each instrument in its own space will make things a lot simpler for you.
