Best way to control and read data from multiple instruments?

[SimonGoodson]

Hello,

I'm building an application to test power supplies involving multiple pieces of equipment over a couple of different comm busses. The application will also send control instructions to some of the instruments, and read data from some of the instruments. The reading and control profiles will not run on the same schedule (variable length control steps, configurable read interval).

I was thinking of using a queued statemachine (producer/consumer) for the control profile and another to read the data, but I got concerned that there would be collisions between sending control commands and read commands to the same machine. Is there a suggested design pattern for implementing something like this?

Timing of the commands isn't critical down to the milisecond, but I need to collect reasonably accurate timestamps when the data is read. The same is true for the control commands.

Here are the instruments I'm going to use, if the are control, read, or both, and the communication method

Instrument             Funtions                    Comm Method
-----------            -------------               ----
Power Supply           Read data                   Communicates to PMBus Adapter
PMBus to USB Adapter   Read data                   USB (Non-Visa)
Switch                 control relays              USB (VISA)
Power Dist. Unit       read data/control outlets   SNMP (Ethernet)
Electronic Load        read data/control load      GPIB (VISA)
Thermal Chamber        read data/control temp      Ethernet (VISA)

Thanks,

Simon

[Blokk]

Hello, there is a template in LV called "Continuous measurement and Logging".

It can give you some idea how to properly decouple the "GUI Event handler" top loop (where your Event structure is) from the DAQ and other loops.

You do not need to totally replicate the above example, but you can find there nice tricks which can help you at certain points.

The second loop from the top is the "UI message loop". It handles the commands coming from the top loop, and regarding to the local state machine and other possible conditions and states, it can command the other loops below.

During normal run, the different instrument loops just do the data reading, but if you send a control command from the top loop to a certain instrument loop (use a separate Queue for every instrument loops), that loop will Dequeue the control command, execute it, and goes back to data reading mode (in data reading mode the loop Dequeu itself with a "data read" command automatically). In this way the control and data read modes happen in serial not in parallel which you want to avoid (but I think some instrument drivers can even handle parallel access, it will not happen in really parallel...).

In every instrument loop when you read a value, attach a TimeStamp to it, and send this timestamp/value couple to the DataLogging loop via a Queue. You can use a cluster including 3 items: Source(instrument)/timestamp/value. All the instrument loops can use the same "Data logging" Queue. In the Datalogging while loop, after Dequeue-ing, you can Unbundle the cluster and save the timestamp and data-value into the required channel (different channel for every instrument) of a TDMS file.

(Important: NEVER use 2 Event structures in the same top level "main" VI!)