Best way to run different sequences simultaneously on LabVIEW UI

[Chickentree]

Hello,

I am using TestStand 2016 and LabVIEW 2017. I need to develop a LabVIEW interface that can run TestStand sequences for two DUTs at the same time. The test can start and end at any time for any DUT. The test sequences running at the same time can be the same or very different depending on which external device they control. Therefore, I cannot simply run the parallel process model that runs the same sequence for all DUTs. For each DUT, I should be able to start, stop or select any given sequence at any given moment. The two tests should be completely independent. The following is the only relevant example I found, which didn't help much.

https://forums.ni.com/t5/Example-Programs/Run-Different-Tests-in-Parallel-that-Share-Hardware-with/t...

What would be the best approach to achieve my goal? It doesn't seem I can run two separate instances of TestStand in the same LabVIEW program.

[~jiggawax~]

Why don't you just open two user interfaces?  This would be the quickest and possibly best solution for your situation.

Regards,

[Chickentree]

---

@~jiggawax~ wrote:

Why don't you just open two user interfaces?  This would be the quickest and possibly best solution for your situation.

Regards,

---

I said any set of two sequences running at the same time will be completely independent of each other in a sense that they don't directly have to interact with each other. However, some of the data they process will be from the same data acquisition hardware in the PXI. Running two identical user interfaces will not work very well because of the shared hardware use. In the background, the LabVIEW interface program will be constantly collecting data for both sequences that are mostly for controlling external devices and getting data from them.

[Norbert_B · Accepted solution]

---

@Chickentree wrote:
[...] However, some of the data they process will be from the same data acquisition hardware in the PXI. Running two identical user interfaces will not work very well because of the shared hardware use. In the background, the LabVIEW interface program will be constantly collecting data for both sequences that are mostly for controlling external devices and getting data from them.

---

 Add an API to the LV program, compile it to an EXE and call it IO Server. Use the IO Server API in your sequences to get/create data.

Otherwise, you would use the parallel model with two sockets, have one "relay sequence" as client sequence which calls, depending to the socket, different subsequences.

[~jiggawax~]

Actually you don't need to create a crazy API or anything like that.  Simply name your locks with an * at the beginning.  This makes the lock work across multiple instances of TestStand.

For example if you have a step that is accessing a DMM then use *DMM for the step lock:

If you have an entire routine, put it in a subsequence and on the sequence call use the same locking mechanism.  If you have multiple instruments in the subroutine then use the array locking like this {"*DMM", "*PowerSupply", etc...}

Hope this helps,

[Chickentree]

Thank you everyone. I think I know which way to go now.

jiggawax, that is a very useful tip if the shared hardware is used intermittently in different sequences. In my case, data will be constantly acquired throughout the test. So I need DAQ to be running continuously in the background and two active sequences should have access to the data stream at any time. I will have to go with creating a DAQ server executable as Norbert suggested.

For anyone who will come across this thread:

Run Multiple Instances of a LabVIEW Executable Simultaneously

How Do I Communicate between Multiple LabVIEW Executables Using Shared Variables?

---

[~jiggawax~]

Looks like I misunderstood that you had the other process going.  Just out of curiosity, at what point do you kick off the instrument monitoring process?

BTW- it wouldn't be too difficult to create a multi-process UI like you want.  Just use one application manager but multiple sequenceview and executionview managers.  In fact you could do them in some sort of class in LabVIEW and then have it kick off a new class for every automation they open.  This way your UI could kick off your instrument monitor process as well.

Regards,

[Chickentree]

---

@~jiggawax~ wrote:

Looks like I misunderstood that you had the other process going.  Just out of curiosity, at what point do you kick off the instrument monitoring process?

BTW- it wouldn't be too difficult to create a multi-process UI like you want.  Just use one application manager but multiple sequenceview and executionview managers.  In fact you could do them in some sort of class in LabVIEW and then have it kick off a new class for every automation they open.  This way your UI could kick off your instrument monitor process as well.

Regards,

---

The DAQ should be running before the sequence enters the Main part.

What you suggested sounds like the most elegant way to implement it. I would definitely like to use a single UI that does everything if possible. I will give it a try.

Thank you.

[Norbert_B]

IO Server, the component managing the IO pins of your tester, can be started literally anywhere. If you compile it as separate EXE, you can put it in autostart of Windows, you can launch it when the UI is started or when you start an execution using the process model, the IO Server could be started in the ProcessSetup callback.

It is your use-case which defines the best location/technology for starting the IO Server, but my guess is that the UI or the ProcessSetup callback would be the easiest and most comfortable for your use-case.