Multiple VI's collecting on one DMM/Mux

[reniam]

I have a PXI-4070 mux'd with a PXI-2503. I am trying to create multiple VI's to read the DMM (for example, one VI for voltages on a range of channels, one for resisrtance on another range, etc). Is this possible? There appears to be only one IVI instrument handle for each PXI device and whenever a new VI is run it wipes out the VI that was already running.

Thanks.

[johnsold]

Generally a good approach when you have one device which will generate data to be used by several different destinations is to create a single VI which does all the reads from the instrument. Then the Read VI can send the data to the appropriate destination via a queue - with a separate queue for each destination.

The details depend on how your program works overall. Do you cycle through all the mux channels and all the measurement types sequentially or do the destination VIs request data when they need it, or something else?

Lynn

[reniam]

Thanks Lynn. The destination VIs would request the multiplexer scan channels using different triggers and read the DMM. I'm wondering if there is a way to create seperate instrument handles so multiple VIs may share common hardware simular to a DAQmx task.

[johnsold]

I would probably set up two-way communications between the Read VI and the destination VIs using named queues.  

There would be one queue for sending requests  to the Read VI. Its datatype would be a typedef cluster containing an enum for the type of measurement, a string with the name iof the response queue (essentially a return address for the data), and the mux scan channel to be read.  If there are other parameters which must be used, they can be added to the cluster.

The return data would be via named queues, one queue with a unique name for each destination. These queues would carry the return data. They could be as simple as a single scalar numeirc value or more complex depending on the nature of the data. For example a timestamp could be included if necessary. These queues should all have the same datatype to keep things from getting complicated, but if there is a good reason for different datatypes, the extra complexity might be worth the trouble.

By using a common request queue there is no possibilty of the data getting mixed up and sent to the wrong place.  The Read VI Dequeues one request, configures the mux and the DMM accordingly, takes the reading, and returns the data in the named queue for that destination.  Then it is ready to dequeue the next request.  This brings to mind another thought: The Read VI will be a loop waiting for an element to appear in the request queue. To stop this VI one of the values in the type of measurement enum should be "Stop" to tell the loop to shut down. You also need to consider where and wen to close the queues.

Lynn