07-24-2018 09:57 AM
Hey,
I am currently developing a measurement program.
The measurement setup consists of a Notebook running LabVIEW 2015, a Power Unit (controlled via GPIB), a device to collect ambient temperature and humidity (read via RS232) and some mass flow controllers to regulate a gas flow (controlled via RS232). I am now wondering what a good architecture may look like for this setup.
In my opinion the setup fits inside a state machine but I wonder how I could implement that with multiple devices. I have states like
for each device.
In addition to that I have states like:
The measurements are done every second, the Power Unit is only activated every few minutes, the mass flow controllers change their value every few minutes. Therefore I have some kind of asynchronous behaviour.
Is it now the best to create a single state machine with states like:
Or do I use just a state
where I put all my devices to initiate?
Or maybe some parallel state machines, one for each device? If somebody knows a good example VI, it would be very much appreciated.
07-24-2018 10:27 AM
since this will not be a trivial program, some pointers to look into:
- a combination of state-machine and producer-consumer patterns
- queues/user-events
- asynchronous VIs
i would create asynchronously run VIs (producers), that have an event-structure inside a while loop. the timeout event i'd use for the data acquisition and user-events for initiate/stop/other.
a controller VI that is a state machine
- initialization (queues, user-events, asynch starting of the producer VIs)
- normal running
- teardown
you will need at least one queue to report back the measurements,
possibly more depending on your design decisions (e.g. separation for UI and program-control/state)
best way to start i think is to first build self contained solutions for each device,
and then try to string them together in the fashion mentioned above.
regards and have fun!
07-24-2018 11:50 AM
These days, any time there's an instrument hanging off a communication bus, I automatically think about it as an independent vi with it's own parallel While loop. I typically use a variant of the Queued Message Handler template for something like this.
Each "instrument interface" loop is capable of receiving commands or queries and producing data or replies. Much like jwcs recommended, this approach lends itself to making individual, self-contained solutions for each device. That makes it easier to test each of these modules out independently before you integrate them together into the overall app.
-Kevin P
07-24-2018 02:35 PM
I just did something like this, and chose the QMH approach mentioned by Kevin. The only difference is that I use Channel Wires instead of Queues, so I called it a "CMH" pattern. Here's an example of what/how it was organized:
Bob Schor
07-24-2018 03:08 PM
I use a JKI State machine. However, I set up my system a bit different.
Personally, I would throw all of the instruments in a single loop rather than have individual loops for each instrument.
mcduff
07-24-2018 10:09 PM - edited 07-24-2018 10:10 PM
You just described what I have been doing every day with multiple instruments for over a decade.
A simple state machine fits this nicely as long as your instruments can keep up with the one second sample rate.
You pretty much already named all the states in your post.
07-24-2018 10:18 PM
My post here leads someone through a simple state machine architecture