Using VI Server to check if another LabVIEW executable is running

[jmorris]

Hello all you helpful people,

I need to have one LabVIEW executable check whether a different LabVIEW executable is running.  The simplest way to do so would seem to be to ask Windows if that executable name is running.  A good thread on that technique is here.

However, that requires using a tool (tasklist) which does not exist on all of the Windows OSes I need to support (all flavors of XP, Vista, and 7).  Plus, even if I did find an equivilent for each OS, I'd need to make sure they keep working and update my program each time a new OS came out.

A much better solution would seem to be to use VI Server within LabVIEW, so it will be cross-platform.  However, despite reading over my printed manuals, reading through many topics in the electronic manual, scanning through the forums, and doing some limited searching for a manual on the NI website, I still cannot seem to understand the basics of setting up VI Server communication between two executables.  It's very frustrating, because I'm pretty sure it's a simple task but I just can't find the right instructions.

A lot of the instructions for setting up VI Server say to go under Tools -> Options -> VI Server: Configuration and turn on the TCP/IP option.  That seems like overkill if I only need to communication on a local computer, but ok.  However, in other places it tells me that that sets the default settings for the main application instance (another topic I'm still pretty fuzzy on), so how does it apply to my existing LabVIEW project?  My current project has a main executable, and I thought I would create a new build specification for the second executable.  Executable A has all my existing code, while executable B would just have a VI Server reference available to ping, in order for executable A to tell if it is running.

So I built executable B, and I have attached its VI for your reference.  Deciding that setting the VI Server settings programmatically will be more understandable, I set the options which seemed to make sense: a unique Port number, TCP Listener Active = True, TCP/IP Access List = My computer's IP, and VI Access List = Executable B.vi.

In my test Executable A.vi, which I am using to get this up and running before modifying my main code, I use Open Application Reference with my computer's IP, the unique port number, and a short timeout.  I hooked that up to an App Property Node to determine if I am getting the correct connection.  All I really need is to verify the Application Name and I'm good.  However, I keep getting "LabVIEW.exe".

If anyone call tell me what I'm overlooking in this simple setup, I would be very appreciative.  A short primer on anything else I'm missing on how VI Server works, how the Tools -> Options settings of it relate to all this, etc., would be a big bonus.  Eventually I'm going to need a way to not specify the IP address of the computer (or a way to query it from LabVIEW), so I can distribute these two executables onto any random PC.

Thanks in advance for your help!

-Joe

P.S.  In the preview window all my text has run together; I sincerely hope that doesn't happy when this posts, especially given its length.  If so, I apologize!

[TCPlomp]

Well you have described your question throughly, so I should be able to answer it.

First some basics:

-An application instance is like a real application. A VI in application instance A (or A.exe) isn't aware of instance B.

During development an application instance is basically a project, you can see the instance name in the lower left hand of the window during development.

To communicate between instances you need VI server (TCP/IP) or ActiveX

The settings you made in  Executable B.vi, allowed other application to access the VI server instance of ExeB. However you mistyped the name of the VIs accesible. It should start with a '+' (as the help mentions).

But that isn't the problem, since you are not accessing a VI inside ExeB.

Here is a shot of an adjusted VIB:

It only allows access from this computer.

On my computer I got an error 1032 out of the 'AllVIsInMemory' since it is forbiddin to read this setting in a remote instance (RemoteAccessDisallowed). (it would be an enormouse risk, like an OpenFolder on a webserver.

 If I remove the  'AllVIsInMemory', I get the application name actually running (LabVIEW.exe), to change the name you should compile ExecutableB.vi into an executable with a different name.

Ton

PS you can use 'localhost' as IP address.

Message Edited by TCPlomp on 29-01-2010 11:20 PM

[jmorris]

Thanks, TCPlomp!  Your answer was very clear and helpful.   

However, I created a build specification in my project with just VI B as the source code, built it, and ran that executable, and the application name I get back when I run VI A is still "LabVIEW.exe."  I suppose it doesn't matter if I assume my port number is unique, that should still positively identify my program if it successfully connects on that port.  However, for my general knowledge I'd like to know why it isn't returning the specific name I gave the application.

As a followup question, are there conventions I should follow when choosing my listening port number (i.e. ranges reserved for special purposes)?  If I use the default, and some other application is also listening on the default number, which one gets returned when VI A opens a reference?

Finally, how long do you think is an appropriate timeout length for the Open Application Reference VI?  It seems near-instant when I run it here, but I suspect it will depend on the computer processor load.  However, if I have to do this check when my main application is starting up, I want to minimize the time it sits and waits for an answer.  Would 1 second be sufficient for nearly all cases?  Half a second?

Thanks again very much for your help!

-Joe

[TCPlomp]

Strange, VI_A should return the actual name of executable of VI_B. Could you upload the whole project?

Normally I will start with the default LabVIEW port +1.But have a look here for a wikipedia page on port numbers.

Ton

[jmorris]

Here's a zipped project.  Now I'm not even consistently getting a connection, much less the correct application name.  When I run A while B is running, regardless of if it's in the development environment or as their executables, first I get error code 56 (which I consider the normal "not running" error):

LabVIEW:  The network operation exceeded the user-specified or system time limit.

Then if I run it again I get error code 63:

LabVIEW:  Serial port receive buffer overflow.
=========================
LabVIEW:  The network connection was refused by the server. For TCP/IP, make sure the server is running and listening on the port you are trying to use. Firewalls can also cause a server to refuse a connection. For VI Server, make sure you have enabled VI Server from Tools>>Options>>VI Server:Configuration.

And it stays on error code 63 until I stop and restart B.

The reason I close the VI Server in B when I am quitting is I got a weird error back when it was working, where it would see it as running even when I had stopped B; I'm guessing that was because the VI Server wasn't closed, especially in the development environment since the whole program was not closed.  But now I can't even get consistent results, much less the ones I want. 

And the error message again implies that I have to have VI Server enabled in the Tools>>Options dialog - is that required to be turned on for the programmatic opening of the server to work ever?  If so, how does it apply to applications I built earlier?  That would be very confusing to me.

Thank you many times again for your help!

-Joe

P.S.  Now I can't even reproduce the error code pattern I described above - they're all 63.  Sigh.

P.P.S.  If you post a zip file in return, please rename the extension so my work firewall won't automatically kill it. 

[TCPlomp · Accepted solution]

The ini file of the application should contain the following line:

server.tcp.enabled=True

Besides here's a better way to see if your inside an executable:

Ton

[jmorris]

Thanks!  Adding that line to the .ini file fixed the problem (including now seeing the application name correctly). 

It's frustrating that there is no programmatic way to enable the TCP VI Server without that line in a separate file that I have to make sure is distributed with my executable B, but at this point I'm just happy it works.

Also thank you for the improved executable detection; I'm always happy to make my code simpler and more robust at the same time.

-Joe

[Paul_Torek]

Thanks guys.  I used your ideas with a little bit of modification.  I know the name of the VI so I appended it to the application path+application name.  The above diagram is of VI A.

I used TCP port 3363 for executable B and 3364 for my development environment, in case that matters