Jump to content

Application's VIServer port


Recommended Posts

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

Link to comment

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?

post-7452-0-43690200-1301991185_thumb.pn

Link to comment

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 by Roderic
Link to comment

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.

Link to comment

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.

Link to comment

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.