LabVIEW
Best Architecture for my application
You can use Master Slave architecture for your application. If your application follows a series of action then Queued State Machine will be fine
Queued Message Handlers (QMH) will be your friend. Each instrument/device can have its own QMH to be controlled by. You may need a main state machine to further tell the QMHs to do stuff.
If you want to go hard core into OOP, then have a good look at the Actor Framework. It would actually fit pretty good here.
Of course you don't need to use any OOTB architecture.
Especially with OO, you can compose your application from objects, 'glued' together with patterns and\or synchronization objects.
I like it like that, as it gives me the perfect fit for each of my applications. But if you just want a quick start (at the expense of boilerplate code 
), you can of course use on of many frameworks.
And of course both ways have a learning curve, but for me doing it on a per project basis is something I've learned over the years. Learning XYZ framework takes time to solve a problem I personally don't have. That could be different for you.
Search LabVIEW like a graph!
pers.jolanta@gmail.com wrote:
Hi, thank you for your tip!
I am trying to understand a difference in performance between the Queued State Machine and Queued Message Handlers and I do not see it clearly. Queued State Machine can also have multiple queues and while loops for each device, controlled by one event structure, or not? Exactly like with queued message handler. What do I miss?
Thank you for your help!
I don't think you're missing something.
A SM (as we use it in LV) is basically a while loop with a case structure. States go from one iteration to the next in a shift register. A QSM has an queue of states, but is still a loop with a case structure. As you'd usually want to have parallel processors (that you could call "actors"), you'' basically end up with a mixture of SM, QSM, Actors, QMH, etc..
I'm not a CS guy, and I use more pragmatic designs for my architectures. But I'd say most "architectures" use other patterns as well. So, SM will use Actors, AF will implement (Q)SMs, etc..
And that's how it should be done: pick what you need. Or as I see it: pick the simplest solution that does the job.
BTW: Haven't used a (Q)SM in 10 years. If I need something like that, I prefer a state pattern. But even those a rare.
BTW2: I often use a loop with an event structure in my main VI. If something needs to be done in parallel, I start something in parallel. Don't really care what to call that "architecture". Probably an event handler, with some actors, mixed with a bit of (queued) message handler.
pers.jolanta@gmail.com wrote:
Queued State Machine can also have multiple queues and while loops for each device, controlled by one event structure, or not?
A Queued State Machine (QSM) is a single loop that uses a queue to hold its states that it will progress through. NOBODY OUTSIDE OF THE QSM SHOULD EVER SEE THE STATE QUEUE.
A Queued Message Handler (QMH) is a single loop that gets a message (via a queue or the like), reacts to said message, and then waits for a new message to come in. THE QMH SHOULD NEVER ENQUEUE A MESSAGE TO ITSELF. Only other loops/actors/modules should tell the QMH what to do. I will go ahead and throw in the grey area where the QMH does something based on a timeout (no message is received in X ms). This is how I typically set up my instrument communications. When commanded, start reading from the instrument and repeat on a timeout until commanded to stop.
So each architecture has its own uses and there is nothing wrong with using multiple architectures in a single project. One of my favorite projects was based on a QSM to help the user through a process. The QSM sent messages to several other QMHs that handled the instrument communications, error handling, data logging, and a few other minor things. Those QMHs also send data to each other and back to the QSM using User Events.
