Aynchronously calling VI

[edjones93]

Description

Description-Separate-1

Overview

Using VI Server, you cannot make asynchronous calls of VI's to run on a remote machine. This can be a desired behaviour of an application, additionally communication back and forth between the two machines may also be desirable to control states or send information with regards to the operations performed.

Description

Application requirements:

1. Call VI's asynchronously to run on a remote machine.

2. Achieve communication between the machines supporting both control states (state changes) and information (message data).

The Local Machine (host):

The Producer:

To achieve this it was required to create a producer consumer architecture on the local machine. The producer would initiate the calls to VI's on the remote machine as well as control the shutdown of the overall application and VI's on the remote machine (this could be extended to other application needs).

Prior to continuing it should be noted that this example illustrates the methodology for one remote machine but with the ability to run multiple instances of a VI on the remote machine asynchronously which can be adapted to incorporate multiple machines and multiple VI's through the communication method selected. prior to the producer loop, a VI is "called to run" on the remote machine which acts as an action engines, we initiate a VI on the remote machine to run asynchronously by sending a command to do so via a network stream. The first issue then with this is that we want to have a communication method back from the remote machine which interfaces with the consumer.

Since Queue's are application specific, it seemed appropriate to have network streams maintain a 1:1 relationship so that it would later be identifiable which remote VI sent the command if needed. The producer therefore, aynschronously calls a VI which continuously (until the network stream is destroyed) pulls elements from the network stream and pushes these to the consumer queue.

The producer then sends a command to the remote VI to run the VI after we have created the necessary stream, these are then connected and we can receive data from the remote VI which gets pushed back to our consumer to process.

It should be noted that in order to avoid issues with larger applications, the producer should be implemented to know when a remote VI has completed and to then remove this VI from the array such as to avoid errors and additionally maintain an array of the used values for the reader/writer endpoints such as to not cause a conflict. This example is purely a proof of concept as to how one can achieve the framework for their application requirements.

The Consumer:

In the consumer we are only reading data received which is of two command sets, to shutdown the consumer, after which all network streams are destroyed and the queue is released. The other state is a response from the remote VI to verify that it has successfully been called after which a numerical indicator is incremented to illustrate this to the user through the front panel.

The Remote Machine:

The remote machine's current operational states are to await commands from the host machine, these are either to run the example VI or to shutdown and close all remote VI's on said machine.

The example VI which is run currently only opens a network stream to our host machine, sends a message that it has been executed and then closing the endpoint (this then stops execution of the network interface VI on the host machine which transfers data from the network streams to the consumer queue).

Steps to Implement or Execute Code

1. Appropriately allow the host machine on the remote machine to run VI's, the steps are given (for all machines) in the article linked below:

    2. Place the Slave VI's under the slave folder into a known location on the remote machine.

    3. Modify the file path in the StartEngine VI under the Master VI's folder to point to this VI.

    4. Ensure that LabVIEW and other services/executables have been allowed for your network type in the Windows firewalls and additionally that the required ports are open through the network. The required ports and applications are listed in the articles given below:

Recommended Firewall Settings When Using Network Streams

Configuring Software and Hardware Firewalls to Support NI Products

    5. Input the remote machine IP Address to the Slave Address control on the MainProducer VI prior to execution, execute the VI and you can now call the Run VI by pressing the Run Button.

Requirements

Software:

LabVIEW 2014 or greater (request earlier versions if needed or ask the Version Conversion forum to do so) on both machines (alternatively you can compile the program to an executable on both and then only need the LabVIEW Run Time Engine - corresponding to the LabVIEW version you compiled with).

Hardware

Two machines connected over a network.

Additional Images or Video

Figure 1: The Main VI which executes on the local machine.

Figure 2: The Main VI which executes on the remote machine.

Description-Separate-2