Independent sequences in parallel

[railang]

Hi all.

I would like to run multiple sequences in parallel, controlled by one LabVIEW UI. The sequences should be independent from each other, e.g. a LabVIEW global variable created by one sequence should not be seen by other sequences.

NI support told me, that it is not possible to start multiple instances of TS Application Manager form one LV exe. Therefore I see two solutions for my requirement:

(1) Create a management sequence, that controls the worker sequences. The worker sequences are started async by the management sequence. Of course this solution does not seperate the workers address space. All sequences have one common Application Manager and LV globals are also shared by all sequences. 

(2) Create a small LV exe that acts like a "TS Proxy" and can run multiple instances. Each instance of TS Proxy runs an Application Manager and controls one worker sequence. From the LV UI the TS Proxies are controlled via TCP/IP. 

I know, solution (1) is the common way to run parallel sequences. Has anybody tried solution (2)? Or maybe there is a third way to get this done?

Kind regards

Rainer Langlitz

[kosist90]

I would go for the second way, as you've described - create application, which will start others Operator Interfaces (simply as exe), which could start one dedicated sequence.

The question is - why there is such a need, please? I'm just curious - if sequences are different, why not to start them simply via different instances of the Operator Interface, without central management application?

[railang]

Hi kosist.

We have 3 testrigs, each with 20 slots for different UUTs. If we start 20 instances of an operator interface this will end up in a very cluttered desktop. Also the testruns must be synchronized with the central climate chamber control. 

Solution (2) includes a high implementation effort for exe management and communication. And it is some kind of cheating the NI infrastructure. I would like to do it "the NI way", what implies solution (1). I think I can get the sequence management done with the Parallel Model in TS (http://www.ni.com/white-paper/3757/en/). 

The problem is the data acquisition: My DAQ system has two interface-VIs to get (or set) a data point. The data point is identified with a "name" string. These VIs establish TCP connections to the hardware interfaces on RT systems. The information which RT sytem IP:Port to use for a specific name is resolved the following order:

(a) Input of the interface VI with name "DIR" (for directory)

(b) Global variable "DIR"

(c) TCP request to directory service (provided by the Operator Interface)

In TS sequences I need to tell the interface VIs the DIR record, specific for the assigned slot on testrig. The most flexible way to do this is (b), the LV Global. Another argument for this method is the sharing of established TCP connections for DAQ: They are also shared in the LV address space.

This boils the problem down to: Is there a way to create multiple LV address spaces (in terms of LV-Global visibility) inside TS?

Another approach: The DAQ VIs do also have a SequenceContext access. They could:

(d) read a TS variable to get the DIR information. 

Is there a TS variable visibility space for a multithreading sequence call? Does the option "Run Sequence in new Execution" work for this? (http://www.ni.com/white-paper/3757/en/)

Kind regards

Rainer Langlitz (KDM)

[kosist90 · Accepted solution]

In such a case, I would not go to separation of LV Global namespace.
Check it: you can use in your sequences, as input values, Parameters Variable type, instead of LV Global (so your code modules will have input, and value of this input will be defined by Parameter TestStand Variable).
Via such a variable, you can define what you need:
- DIR value (b/c you can select, based on number of test socket. You can get number of test socket via expression RunState.TestSockets.MyIndex (it returns number of socket, from 0 to N), and based on it, define value of DIR.
Also, then you can use Parameter Variable to hold TCP communication reference. Why Parameter Variable? B/c it will not be shared between parallel threads.
In case, if you don't share FileGlobals between parallel threads, you can use FileGlobals for this purpose.
If you will use SequenceContext, yes, you can also access/define all these parameters based on socket number.
Hopefully, this will help...

[railang]

I would like to avoid parameter variables, because I need to dig these into all subsequences und VIs. Thank you for the hint to TestSocket Index. I think this could be a suitable solution for my problem. I'll let you know when the implementation is done. Thanks