Application's VIServer port

[Antoine Chalons]

Hi all,

Let's say I have app_a.exe and app_b.exe two LabVIEW applications.

app_a.exe is instantiable and allocates itself a VIServer port dynamically - a different one for each instance of course.

How can app_b.exe find out the VIServer port of each app_a.exe instance?

[Tim_S]

Let's say I have app_a.exe and app_b.exe two LabVIEW applications.

app_a.exe is instantiable and allocates itself a VIServer port dynamically - a different one for each instance of course.

How can app_b.exe find out the VIServer port of each app_a.exe instance?

My initial thought is for app_a to tell app_b that it exists.

Tim

[Antoine Chalons]

My initial thought is for app_a to tell app_b that it exists.

Tim

Hi Tim,

I don't understand what you mean, can you explain how you would do that practically?

I dug a bit more into my specific issue which is to communicate with Vision Builder Engines (VBAI 2010), the VBAI API lets you start multiple VBAI Engines on a computer and basically I put some custom plugins in VBAI and try to access data contained in those from LabVIEW.

The issue was to know what port to use for each VBAI Engine, I found a solution (see attached) : in the API.llb there is a VI to do just that "Service Provider Get Info.vi".

It solves my problem. But still I was wondering how it works (of course it is password protected)... Any clue?

[Roderic]

Hi Antoine,

I know I'm a beginner but can't you just write the VIServer port reference into a FIFO or a notifier, this way you would be able to retrive the reference in your second application. I use this method to communicate between LabVIEW and testStand and it works just fine!

Regards,

Rodéric

Ps: you may have to cast your data.

Edited April 5, 2011 by Roderic

[Antoine Chalons]

Hi Antoine,

I know I'm a beginner but can't you just write the VIServer port reference into a FIFO or a notifier, this way you would be able to retrive the reference in your second application. I use this method to communicate between LabVIEW and testStand and it works just fine!

Regards,

Rodéric

Ps: you may have to cast your data.

Hi,

Yes, if I was the developer of both apps I could do that but in my case app_a.exe is in fact VBAI (developed by NI). Until recently the port could be read in the INI file of the exe, bu t now that the VBAI engine is instantiable, each instance will allocate itself a port dynamically.

I'm pretty sure there is "LabVIEW way" to determine the port that was dynamically allocated though.

[Rolf Kalbermatter]

Hi,

Yes, if I was the developer of both apps I could do that but in my case app_a.exe is in fact VBAI (developed by NI). Until recently the port could be read in the INI file of the exe, bu t now that the VBAI engine is instantiable, each instance will allocate itself a port dynamically.

I'm pretty sure there is "LabVIEW way" to determine the port that was dynamically allocated though.

You could look into service names. The TCP and UDP functions in recent LabVIEW versions allow to wire a string to the port input which can define a service name. For server functionality this registers the service name with the dynamically allocated port number at the NI Service Locater service for that machine. For client functionality it queries the Service Locater for the port number for the specified service name. I saw in the LabVIEW 2010 configuration yesterday that you can specify a service name to be registered for the current LabVIEW instance and I'm sure that can be put into the executable configuration too. Not sure however how that works in combination with multiple instances of the VBAI since they all would use the same configuration file to startup.

Also there is a VI library in vi.lib/Utility/ServLocater.llb that allows to interact with the service locater programmatically. It allows to query the service locater for all currently registered services, so you may be able to see if starting up multiple VBAI instances does register any service name and what pattern the service name would follow.

[Tim_S]

I don't understand what you mean, can you explain how you would do that practically?

I was assuming you had written both app_a and app_b. What I was thinking was app_a could send a TCP message to app_b with the port information. This won't work since you aren't developing both sides.

Tim

[Rolf Kalbermatter]

Actually a correction to my earlier post. The VI library mentioned does not allow to see all the registered services but instead you can enter in your prefered WebBrowser:

http://localhost:3580/dumpinfo?

[Antoine Chalons]

Actually a correction to my earlier post. The VI library mentioned does not allow to see all the registered services but instead you can enter in your prefered WebBrowser:

http://localhost:3580/dumpinfo?

Legend! That's perfect, thanks a lot!

[Wire Warrior]

Cool. A modifying JonKokott's Coding Madness 2011 entry would make this a programmatic function.

Jason

[Rolf Kalbermatter]

Cool. A modifying JonKokott's Coding Madness 2011 entry would make this a programmatic function.

Jason

I see why you think that, yet this tends to be rather static data, unless you happen to startup and exit lots of service enabled NI and LabVIEW software applications. So not really that exciting to watch