LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using multiple (measurement and control) devices in one VI / Program

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

 

  1. "Initiate-device-xy",
  2. "stop-device-xy",
  3. "do-something-with-device-xy" (like measure or activate)

for each device.

In addition to that I have states like:

  1. "wait"
  2. "initiate UI"
  3. "save data"
  4. "plot data"
  5. "load data"

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:

  1. "wait"
  2. "Initiate UI"
  3. "Initiate power unit"
  4. "Initiate mass flow controller"
  5. "Initiate thermometer"
  6. ...

Or do I use just a state

  1. "Initiate"

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.

0 Kudos
Message 1 of 7
(2,851 Views)

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!


If Tetris has taught me anything, it's errors pile up and accomplishments disappear.
0 Kudos
Message 2 of 7
(2,838 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 3 of 7
(2,819 Views)

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:

  • I'm recording data from a serial device that gives a reading 10 times a second (more-or-less, not super-precise or super-accurate).  I'm looking for a "reading change" that indicates "Event Start" or "Event End".
  • I have a camera taking frames at 30 frames/sec.  
  • I have a Video routine whose sole responsibility is to make an AVI of images from the Camera starting 1 second before the Serial Device says "Event Start" and stopping one second after it says "Event End".  [The Camera buffers the images, so I really can look backwards in time].
  • Needless to say, the Serial Device does the most signalling, getting "Start Frame" data from the Camera, sending it to the Video routine, and similarly signalling "Last Frame" information.  Each device also sends Messages to itself to switch from one State to another (or to repeat a State).

Bob Schor

0 Kudos
Message 4 of 7
(2,804 Views)

I use a JKI State machine. However, I set up my system a bit different.

 

  1. Every loop in my Main vi is a JKI State Machine.
  2. I communicate  to each loop over a Message Bus. See https://forums.ni.com/t5/Example-Program-Drafts/Message-Bus-Architecture-An-Intro/ta-p/3512280  (I have modified multiple parts of this example, but the idea is the same)
  3. Each Message has a type, command and data payload.
    1. Type means which loop, like Instrument loop, Data loop, etc
    2. Command is a string command to the state machine
    3. Data payload is a variant
  4. For each loop there is a helper loop that filters out the messages by type and only sends the ones that are subscribed to by the loop.

Personally, I would throw all of the instruments in a single loop rather than have individual loops for each instrument.

  1. For Parallel loops it may be hard to ensure the order of execution for each instrument.
  2. As far as I know, please correct if wrong, I don't know how those buses, GPIB, serial, etc handle parallel communication. That is, can they send multiple commands to different instruments at the same time? If not, then you will have blocking loops, and no parallel execution.

mcduff

0 Kudos
Message 5 of 7
(2,801 Views)

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.

 

 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 6 of 7
(2,787 Views)

My post here leads someone through a simple state machine architecture

https://forums.ni.com/t5/LabVIEW/Write-to-new-file-at-midnight-but-record-data-constantly/m-p/282400...

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 7 of 7
(2,783 Views)