Can a LV exe have its own unique VI Server?

[viSci]

I have been beating my head against the wall for 2 weeks over this issue and so far I cannot get an answer to this question and its import.

Basically I have found that I cannot set the app class property Srvr.Port within a LV2009 executable. The property node executes without error

but I have verified that the VI Server Port is not being set and thus always remains at the default of 3363.

Any insight would be greatly appreciated, thanks.

[Antoine Chalons]

Basically I have found that I cannot set the app class property Srvr.Port within a LV2009 executable. The property node executes without error

but I have verified that the VI Server Port is not being set and thus always remains at the default of 3363.

Do you mean you try to modify the application's vi server port at runtime?

I've never tried to do that, without really thinking about it I was assuming it wouldn't be possible so I set the application's vi server port in the ini file next to the exe.

e.g.

[exe_name]

server.tcp.port=xxxx

server.app.propertiesEnabled=True

server.vi.propertiesEnabled=True

server.tcp.access=+*

server.tcp.enabled=True

server.vi.access=+*

server.tcp.paranoid=False

[viSci]

Yes I may have to try using the ini approach... I had assumed that since I can set the Srvr.Port when running from the project that it should work from an exe as well.

The help for the property indicates that it should work in the runtime. BTW, the advantage for me in dynamically setting the VI Server port is that I will have multiple instances of the same

exe running on one computer and would prefer to have the port number generated automatically (As Rolfk pointed out to me, you can use the Create TCP listener vi to generate an unused port number and then just close that TCP port and use it for the VI Server).

[smenjoulet]

I have been beating my head against the wall for 2 weeks over this issue and so far I cannot get an answer to this question and its import.

Basically I have found that I cannot set the app class property Srvr.Port within a LV2009 executable. The property node executes without error

but I have verified that the VI Server Port is not being set and thus always remains at the default of 3363.

Any insight would be greatly appreciated, thanks.

Yes, you can. See the attached snippet. Just drop it in a project and make a build. You can also put it in the ini as Antoine explains, but this allows you change it on the fly or keep it private, if that is your intent.

-Scott

[viSci]

Yes, that is what I am doing but unfortunately it does not work in LV2009

[smenjoulet]

Yes, that is what I am doing but unfortunately it does not work in LV2009

Well, I don't know what's different about your environment, but I just tried the snippet I posted and it works fine for me. Can you post a VI or snippet of what you're actually doing?

-Scott

[viSci]

I actually used your code snippet. The verification comes later in the code when I attempt to read the assigned port number and use it as part of a remote messaging scheme. It is there when I read the Srvr.Port property that I verify that is not the value the was set previously. It has reverted back to the default of 3363. So far the only technique that works is setting the port number in the exe's ini file.

I am curious to know how you are verifying that your code is working correctly.

[smenjoulet]

I added a little bit of code to read back the current server port in my snippet and it returns the value I last set.

As for actual testing, I open a connection to the exe from LabVIEW and ask it for some information (e.g. exported VI's in memory). If the port I'm using in LabVIEW doesn't match the port setting last used in the exe, it doesn't work. When they match, success!

-Scott

[viSci]

Ahhhaaa!!!! Here is what I have discovered:

The exe code works fine if and only if the LV2009 development is not open. Somehow the presence of the development environment is preventing a separate VI Server Instance to function correctly!?!

Could you please try this on your end?

Thanks for your help.

In more detail what I see is the the exe standalone will set and read the Port to lets say 4369. If I have the LV DE open first and then open and run the exe

the port will get set to 4369 but will be read as 3363 (the default LV port)

[smenjoulet]

OK, now I see what your problem is and why I didn't see it.

The exe code works fine if and only if the LV2009 development is not open. Somehow the presence of the development environment is preventing a separate VI Server Instance to function correctly!?!

In more detail what I see is the the exe standalone will set and read the Port to lets say 4369. If I have the LV DE open first and then open and run the exe

the port will get set to 4369 but will be read as 3363 (the default LV port)

The problem is with the default VI server port, not that the IDE is preventing another VI server from functioning correctly. Only 1 server can run on any given port at a time (of course). If you have the VI server set to startup in the exe (per the ini) and don't specify a port, it will try and start at port 3363. If any other VI server (LabVIEW IDE or other exe) is active on that port, then the VI server for that exe won't start. If you try and set the port to a different number later and restart the server, it will generate an error and not start. Actually, in LV2009, it looks like even if the server isn't enabled in the ini, you can't restart it later on a different port. That may be the intended action by NI for some reason, but it seems like a bug to me and I don't recall how it worked in earlier versions.

In either case, the property node for server port will return 3363, even though the node didn't generate an error when trying to set it to a different number. That also seems like a bug to me.

The reason I didn't have any problems on my end initially: I never run my IDE on the default port!

So how to fix it...

Use a defined startup port that the VI server for the exe will start on. This is only for startup so it won't conflict with any other instances of your exe.

Find an unused port and reset the VI server to use that port instead of your startup port.

That frees the startup for use when another instance of your exe launches.

Hope that helps!

-Scott

[viSci]

Hi Scott,

I am very impressed with your diagnostic skills.

Thank you very much for your help!