Why don't subpanels work in my executable?

[Philip_Courtois]

Hi tst,

Well, maybe my wording was a bit too simple, but the fact is that adding the "localhost" string to the "machine name" input makes it possible to point to the opposite target. You still have to specify the port number in case you have multiple executables running, just like it's mentioned here:

Using VI Server to Pass Data between a VI and a LabVIEW Executable

[tst]

Allow me to quote from the help for the Open App Reference VI (7.1):

If you want to establish communication between a VI and a stand-alone LabVIEW application on the same computer, wire localhost to this input. localhost establishes communication with the LabVIEW Run-Time Engine.

The thing is that isn't so. If you wire localhost without inputing a port number, the connection will be opened to LV instance and not to the EXE, even if the port for the EXE is the default 3363. As far as I remember from my (bad) experience with this, you HAVE to specify the port number (and probably make sure that the port is different from that of the LV instance). My guess is that if you wire the port number, you wouldn't even have to wire localhost into the VI for it to work. This really should be mentioned in the help for the VI and not in the website.

[Philip_Courtois]

Hi tst,

I really appreciate that you question what we sometimes take for granted. Your comments made me look further into what exactly is going on when a VI and an EXE communicates through VI Server.

It turns out that wiring anything but an empty string to the "machine name" terminal on "Open Application Reference" enables the VI Server session to make use of TCP/IP and therefore make use of the "port number". If you don't wire anything to the "machine name" terminal, the "port number" will be ignored because the VI Server session will be established to the same execution system that the VI/EXE is running on. For VIs the execution system is the Development System and for the EXE the execution system is the VIs instance of the LabVIEW Run-Time Engine.

In case you simply wire "localhost" to the "machine name" terminal and nothing to the "port number" terminal, the default port 3363 will be used. That way the VI can access the EXE or the EXE can access the VI. I specifically say "or" because they can't access each other using the same port. And that's the catch that you probably are referring to. If both the Development System and the EXE are setup to enable TCP/IP access through the same port (e.g. 3363), the Development System's server will overrule the Run-Time Engine's server. Therefore you will only be able to access the VI from the EXE, but not the EXE from the VI. To access the EXE from the VI, you can either disable the TCP/IP access to the Development System or you can use another port for either the Development System or the EXE - just as long as they don't both use the same port.

I'm sorry that I previously jumped to conclusions, and I hope that this explanation helps understand the distributed VI Server settings. I have attached the LabVIEW 8 VI and EXE that will help you try out the different configurations. When changing the VI Server settings in LabVIEW 8, you now don't have to complete close the Development System before the new changes take effect - all you have to do is close the VI and return to the "Getting Started" window. After that, when you reload a VI the new LabVIEW.ini settings will take effect. To change the VI Server settings for the EXE you can simply manipulate the following tokens:

server.tcp.enabled=True
server.tcp.port=3363

Yes, you do have to close and reload the EXE for the new settings to take effect.

Thanks again tst - I hope this information helps.

Message Edited by Philip C. on 12-30-2005 01:34 AM

[tst]

Actually, most of it didn't help, because I already figured that much out (except for the part about having to wire a string and the one about not having to restart LV 8). BTW, I didn't realize that you had to restart older version of LV when changing this (from the options menu, not directly in the ini file). Is this so?

Yes, I did mean that if the port for the EXE is the default and the LV port stays the default then it won't work. It seems I just forgot to write this. The thing I keep saying is that the help for this is very unhelpful because it doesn't mention that you need to change the port number from the default, just that it will open a connection to the RTE. It only needs to be clearly mentioned in the help for the function in order to be obvious.

Thanks.

BTW, are you sure that with a default port number, the ES will always overrule the EXE, even if you open the connection from the EXE?
Just a potential experiment... I'm guessing this might be in your test app, but I don't have 8.0 installed yet (just the RTE).

[Philip_Courtois]

Okay tst, you got me again!

After playing more with the example I created, I have noticed a non-consistent behavior of the VI Server hierarchy of which system is in control when a port is shared. In other words, recent tests have given the result that the VI can access the EXE and NOT vice versa. I guess there's no way around it - we have to bring on the big boys from LabVIEW R&D and see if they can explain this behavior.

Regarding the missing documentation; I agree with you 100%! I'll submit a request for the documentation to be improved in this topic.