Call-and-response between EXE through Functional Global Variable Events and VI Server

[AllisonSCJ]

Hello,

I'm attempting to communicate between two running executables on the same local machine using VI Server and a Functional Global Variable.

Communication must occur via events, due to the design of my main application. 

My idea was this:

Create a FGV that holds two event registrations, one for the Client to listen to (Response Event), and one for the Main (server) to listen to (Endpoint Event).

The Functional Global Variable allows creation of these events and their registrations, and allows the sending of messages by creating either event. 

The FGV is available from VI Server, and the client uses VI Server to establish a connection to the application, and send an Endpoint Event to the Main VI of the application. This all works great, both in Development and as an executable.

Here is the problem: 

Although I can send a message from the client in both the development environment and the executable, I can only receive a response back from the main vi when in development mode. Why is this?

I initialize both the Endpoint Event and Response Event within the main application, so that the lifetime of both is the same as the main application. 

To recreate what I did in the development environment: 

1. Open Message Call and Response Main Example.vi, (Main)  and run.

2. Make sure that Message Call and Response FGV.vi is listed as an enabled vi in the string array on the Main vi's front panel.

3. Take note of the port output to the front panel (It should match the port set within tools->options-> vi server from your labview instance)

4. Open 'Send Message and Wait for Response from Event VI Server.vi" (Client). Fill in the port number input with the port output from the main vi. Add a string message to the Message input. Click run.

Expected behavior: The main vi should show a popup dialog with your sent message. The client vi should display the response message from the Main vi in the Client output 'Response Message'. The 'Timed out' boolean should be false. This works just fine when in the development environment.

To recreate what I did in runtime:

1. Build FGVListener. (The startup vi of this build is Message Call and Response Main Example.vi). Make sure that under advanced, the exe is using the custom config file included in the project (FGVListener.ini)

2. Start FGVListener.exe

3. Take note of the port number on the executable's front panel. It is a port number set by the .ini file (Make sure it is not the same port in the Labview instance!)

4. With the executable still running, open the client vi (Send Message and Wait for Response) in the DEVELOPMENT environment. Repeat step 4 from the development environment section above.

The exe is expected to behave the same as it did in development. However, in my environment, the popup dialog still occurs, but the client shows no response message, and instead experiences a timeout.

Things I've tried:

1. I've attempted to initialize the Response Event within the Client, instead of on the server. This failed to provide any change in behavior.

2. I created a Response Event Queue output on the FGV, and registered to it within the Client. Again, no difference in results.

[Ben · Accepted solution]

While I have not done this with events, I have done something similar with queues going back to LV 6i RT when this approach was "THE METHOD" transfer data between a Windows and a RT machine.

I suspect your issue is related to the process context of two exe's being unique. While the client can retrieve the event reference reading from the Action Engine, that reference is not valid in the context of the client.

I would split it up into two Action Engines. One for the server one for the client.

The two AEs should get initialized in the context where you will be running the event structure for each.

Then as you run the AE on the server will be invoked from the Client to fire the event on the server and then the server invokes the AE running in the Client context to fire its event.

BTW:

The project has settings that will let you control the port used by an application that was built with a build in the project.

Give that a whirl and let us know what you find.

Ben

[AllisonSCJ]

Thank you so much Ben, that worked!

I can't believe I didn't think to make two seperate FGVs (With an Action Engine design), with one on the client side, and the other on the server side. The closes that I got to this was to have the client initialize its own event queue, but still only using a reference to the FGV from the main application. But you're right, that event was not valid in the context of the client.

In case anyone is curious, I've attached a copy of the project with the solution in place.

Thank you again!!!

[labmaster]

Thank you for the code, demonstration of FGV and VI server between applications.

First, both codes showed that the messaging of client-> server was okay but client-> server is still time-out.

I found the code modify the list of machine and export list in VI server in Options.

So I deactivated it then get the response in both sides.

In any way, I failed to get the same result with two applications after building two VIs.

The port was single value 3363 in two VIs in development environment  but the ports were not same, 3365 (server) / 3363 (client), in run-time applications.

Have you tried this?

Thank you again.

labmaster.

[labmaster]

Simple mistake in editing the code.

No problem even in applications.

Thank you much for providing example code on Functional Global and VI server.

labmaster.