How to correctly set up instrument queues for LabVIEW instances from different machines

[ptptcenz]

This is probably a bigger step than my LV knowledge allows me to take, but recently this problem has arised in the lab.

We are sharing several instruments, each with a number of channels, between experiments. To make two representative examples:

• one is a 4-channel oscilloscope with its LV drivers, which is connected via LAN to a local network (so it's directly accessible by every PC in the lab);
• one is a NI PXIe chassis with four PXIe cards, connected via a serial cable to one of the PCs.

Each experiment controls two oscilloscope channels and two PXIe cards (there's more, but the other instruments work the same way), and is run by a different PC.

Now, I already experienced problems when two VIs on the same machine called the same instrument at the same time, causing a timeout error. I can imagine that adding another computer, which runs a different LV version, only makes things worse.

I've read about queues, producer/consumer loops, but I don't really know which is better suited to our needs, and I haven't really understood well how they work (so far my "expertise" with LV is limited to event structures in a while loop - is that a state machine?)

I thought about having only one computer (the one connected to the PXIe chassis) control all the instruments (even the LAN-controlled ones), and the experiments VIs talk to it via TCP (or using global variables, if it's the same computer?). Should I have a separate VI for each instrument or is there a way to do it in a more efficient way?

[Ben]

From what you have described, the solution is not trivial.

First question before we get exotic is "can you just row more money at instruments so you do not have to share?

Beyond that I would consider setting up one machine that Serves the instrumentation to the machines running the test (Clients).

But that is where the "not trivial" comes into play.

You can start with first principals using TPC/IP as the transport mechanism and then define a prtocol that will provide the needed functionality.

Or you can set-up the Server to be continually acquiring all possible data and keep Action Engines updated with the data. Using VI Server will let you invoke methods of the Action Engine to retrieve the desired data.

Just throwing out ideas,

Ben

[ptptcenz]

---

@Ben wrote:

From what you have described, the solution is not trivial.

First question before we get exotic is "can you just row more money at instruments so you do not have to share?

---

Sadly, I do not think that's an option (though maybe in the future). Moreover, sometimes the same experiment will have two or more VIs call the same instrument. While this is rare, it is something that might happen.

---

Beyond that I would consider setting up one machine that Serves the instrumentation to the machines running the test (Clients).

---

I guess that is the conclusion I had arrived to as well

---

But that is where the "not trivial" comes into play.

You can start with first principals using TPC/IP as the transport mechanism and then define a prtocol that will provide the needed functionality.

Or you can set-up the Server to be continually acquiring all possible data and keep Action Engines updated with the data. Using VI Server will let you invoke methods of the Action Engine to retrieve the desired data.

Just throwing out ideas,

Ben

---

This is where you lose me. I think the idea of a simple TCP/IP communication might be ideal, given my basic experience as a user. When you say "define a protocol" you mean something like a client sending a string (e.g. "SCOPE MEASURE CH1 100MS" or "SMU SET CH1 VOLT 2.5", or rather a more compact notation) that can be decoded by the server, which will then queue the appropriate command?

[Ben]

---

@ptptcenz wrote:

---

@Ben wrote:

From what you have described, the solution is not trivial.

First question before we get exotic is "can you just row more money at instruments so you do not have to share?

---

Sadly, I do not think that's an option (though maybe in the future). Moreover, sometimes the same experiment will have two or more VIs call the same instrument. While this is rare, it is something that might happen.

---

Beyond that I would consider setting up one machine that Serves the instrumentation to the machines running the test (Clients).

---

I guess that is the conclusion I had arrived to as well

---

But that is where the "not trivial" comes into play.

You can start with first principals using TPC/IP as the transport mechanism and then define a prtocol that will provide the needed functionality.

Or you can set-up the Server to be continually acquiring all possible data and keep Action Engines updated with the data. Using VI Server will let you invoke methods of the Action Engine to retrieve the desired data.

Just throwing out ideas,

Ben

---

This is where you lose me. I think the idea of a simple TCP/IP communication might be ideal, given my basic experience as a user. When you say "define a protocol" you mean something like a client sending a string (e.g. "SCOPE MEASURE CH1 100MS" or "SMU SET CH1 VOLT 2.5", or rather a more compact notation) that can be decoded by the server, which will then queue the appropriate command?

---

I was just offering some initial ideas.

Quoting myself again: The first step in solving a problem is to clearly define what the problem is."

So go through all of your testing and write-up what type of messages will be needed to be transferred Client to Server and vise versa.

Start with the easiest and ask for help if you need it.

After getting something simple working then go for the most challenging.

Everything else should be variations on a theme (like Jazz).

Ben

[cstorey · Accepted solution]

As I tell my kids, sharing is never easy!    Multichannel oscilloscopes and multi-card PXI chassis are really only designed to be controlled by one master at a time not shared by many.  They usually only expose one GPIB/Ethernet address to a controller and thus when you try to have two controllers talking to the same instrument you run into conflicts (those timeouts you see).

So you either need to write really smart software that runs on 1 PC and can distribute tasks to the PXI+scope cards and channels when they aren't busy or you need multiple instruments.

If you want to code a test scheduler architecture then you would create measurement routines and them set them to run  sequentially.  You would run measurement X on CH1, then measurement Y on CH2, then X on CH1 again, then Z on CH3, etc..

But if there are multiple people involved your best bet is separate setups.

Craig

[Ben]

[Set TongueInCheek=True]

Now if you were developing in LV 7.1, and traditional DAQ there was a little known functionality that was called RDA "Remote Data Acquisition" where one machine could serve it's I/O devices to connected clients as long as the acquisitions did not fight with each about which channels are being used and the sample rate.

[Set TongueInCheek=False]

Ben