LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How do I generate "server.tcp.acl" entry for built applications?

I need to build an executable (winXP, LV8.0.1) from a LV Project to run on a remote PC that does not have LabView installed.  I intend dynamically load VI's on the remote host using the VI Server.  When I setup the build specifications, I can't find anywhere to configure the VI Server.  If I just install and run the built executable on the remot host, I cannot open an application reference to it.  If I install it on a third host which has LabView installed, and I go to "Tools>>Options>>VI Server:" and set everything up -- it works just fine.  If I copy the .ini files settings from an old built executable (built in LV7.1 => server.tcp.enabled,server.tcp.port,server.tcp.access,server.vi.access,etc.) into the .ini file for the LV8 application it still does not work.  I looked at the LabView.ini on the host with LabView installed where I set the VI Server options from the Tools menu and I saw an entry for "server.tcp.acl".  I added this entry to the .ini file for my build application on the remote host without LabView installed and I still could not remotely open an application reference to it.  I temporarily installed LV8 on the remote host, used the Tools menu to setup the VI Server, copied the generated "server.tcp.acl" entry to my application's .ini file, and uninstalled LV8. Then it worked just fine. 
 
Now to my question -- how do you generate these "server.tcp.acl" entries when LV8 is not installed?  Here is what it looks like:
 
server.tcp.acl="310000000B000000040000002E00000002000000040000004B10000000010000000000020000000000"
 
--Lee
 
 
0 Kudos
Message 1 of 9
(5,042 Views)

Have you thought of creating an installer that also has the run-time engine? You will need the run-time engine if you want to run anything anyways, so this would install everything you need to run the exe as well as the exe itself.  More to your issue, I am confused as to what you are trying to do with VI server. Are you wanting VI sever to be run as part of the exe to open another VI? If so the VI you want to open needs to be part of the project. If the VI is not part of the project, you need to have the exe open an ActiveX reference to an exe that was created with the other VI. The other VIs exe needs to have an ActiveX server created, so that it can be called. Let me know if you need any explanation or help with getting this to work.

Tyler H.

National Instruments 

0 Kudos
Message 2 of 9
(5,031 Views)

Hi Tyler,

Thanks for your response.  Sorry I was not clear in my initial post. 

I am building an installer and I want to dynamically run and load VI's on a remote machine by opening (on the local machine) an application reference to the instance of LV (the executable I built) on the remote host and using an invoke node ("Run VI" method) to load and run a VI.  All of the VI's I plan to load dynamically are included as source files in the build.  My problem is how to configure the access to the VI Server on the remote host.  Since it does not have LV installed I cannot use the Tools>>Options menu.  I tried setting the usual server.tcp config file parameters (that worked in previous versions of LV) and I also tried setting the VI Server parameters using Property Nodes when the remote application starts up -- neither of these worked -- I get a connection closed by peer error when I try to open the application reference.  I can't find a way to set the VI Server parameters for the build.  The only thing I have found that works is to temporarily install LV8 on the remote machine, setup the VI Server using the Tools>>Options menu, copy down the server.tcp.acl entry from the LabView.ini file, remove LV, install my application and add two lines to my applications .ini file:  one to activate the tcp listener for the VI Server and one to set the server.tcp.acl entry.  When I do this it works extremely well.  My question is how do I generate the server.tcp.acl entry without labview installed? Copying the server.tcp.acl entry from another host does not seem to work either.

I wish I could explain this better.  Anyway I hope my question is now a little clearer.

--Lee

PS: I also tried adding the Tools>>Options menu as a custom runtime menu (.rtm) to my built application but it does not show up when I install and run the executable, although my other .rtm meus are there -- very strange.

0 Kudos
Message 3 of 9
(5,029 Views)

Lee,

Ok I understand better now, but if you want to open VIs on a remote machine by using the reference of local VI that will not be possilbe. If you want to open a VI on a remote machine and the reference to that VI is on the remote, you need to have EXEs to do this. If you think about it this is why we have app builder. If someone was able to create a VI that would allow you to just open VIs on any remote/local machine, there would be no need for executables. This is why if you want an exe to open a VI on a remote machine, the VI on the remote machine must be made into an executable with the ActiveX server enabled. That way you can open from the host, the reference to the ActiveX object on the remote. This ActiveX library for the remote is created when you create the executable. What you want to do is possible, but just not in the exact way you want to do it. Your way uses Open VI reference, and the way you need to do it is Open Automation reference. Let me know if this is confusing or you need any explaination. Hope this gets you on the road to success.

Tyler H.
National Instruments

0 Kudos
Message 4 of 9
(5,023 Views)
Hi Tyler,
 
I see that my question is still not clear.  I am building an application with the VI's to be loaded included.  On the local host I am opening an application referece to the remote instance of LV (run time engine for my built application).  With the application reference, I open a VI reference to load the VI I want.  I then use an invoke node to call the "Run VI" method.  All of this I have been doing for years and I am very familair with how it works. 
 
My question has to do with changes in the access control to the VI Server on the remote host in LV8.  I cannot get it to work using any of the techniques I is used successfully in previous versions of LV.  The only way I have found to connect to the VI Server on the remote host is to supply the correct server.tcp.acl entry in the .ini file for my application.  My question is "How does one generate the server.tcp.acl entry?".
 
Again, I'm sorry that I don't seem the be able to pose the question clearly.
 
Thanks,
--Lee 
0 Kudos
Message 5 of 9
(5,020 Views)

Lee,

I spoke with the LabVIEW Product Support Engineers about the issue, and apparently what you have done in the past should not have been possible. The only explanation for what you were able to do is that there may have been a bug or loop hole that allowed  you to load VIs on a remote machine without LabVIEW being installed. Given that fact, we would like to know how you were actually able to open VIs on a remote machine with just the run-time engine. The PSEs couldn't think of a way to do this, so it will be helpful in gathering this knowledge. Furthermore, it is very possible that one of the developers knew of this and made it so you cannot do this in LV 8. Again the reason for this is because it would totally eliminate the need of out app builder if you could run a VI on a machine without LabVIEW. The solution to the problem is what I told you in a previous post with using the ActiveX server of an exe to load the application and run it remotely. Please let us know how you were able to do it previously, and take into account my previous post on how to do it now. Sorry for the confusion and inconvenience.

Tyler H.

National Instruments

0 Kudos
Message 6 of 9
(5,004 Views)

Hi Tyler,

The VI Server is integrated into the LV Run Time Engine.  Once I build and install (including the VI's I want to load dynamically) my application on the remote host I can talk to the VI Server on the remote host once my built LV executable is up and running (which means that the LV Run Time Engine is going so I can open a application reference to it).  There are plenty of examples of how to do this on the NI Website going all the way back to LV5.  My problem is with the new way VI Server access is handled in LV8.  In the past you could specify all the VI Server parameters in the .ini files for your application.  This does note seem to work in LV8, instead the information seems to be encoded into a single parameter called server.tcp.acl.  When inside the LV8 Development Environment you can set the parameters using the Tools>>Options  menu.  However, on the remote host without the LV Development Environment installed, I can't come up with a good way to generate the server.tcp.acl entry. 

 

--Lee

0 Kudos
Message 7 of 9
(4,997 Views)

Lee,

First I must appologize for not fully understanding the meaning of your issue. After sitting down and crunching this issue out with someone, I was totally off in what I thought you were doing. Sometimes even the best of us get confused. So now on to the issue.

The server.tecp.acl line in the ini file is associated with the access lists as part of the VI server configuration. One thing I noticed about the first post is that you were copying things over from the 7.1 ini file, which I would not recommend. Things have changed slightly and I wouldn't do that in your case. So here is what I would like you to try. First make sure that your LabVIEW enviroment is set up for VI server with all the settings you want. When you build the executable go to the Advanced category and make sure that "Use Default LabVIEW configuration file" is selected. This will make sure that the exe runs with the exact same setting as the LabVIEW enviroment has. When you create the exe you should be able to see that the ini file has the server entries.

Mine had the following:

server.app.propertiesEnabled=True
server.ole.enabled=True
server.tcp.paranoid=True
server.tcp.servic="My Computer/VI Server"
server.vi.callsEnabled=True
server.vi.propertiesEnabled=True

I did not have anything special in my access lists, so that is why I might not be seeing the server.tcp.acl file. I don't see it in my default LabVIEW ini file either. Try running the exe on the other machine, and then remotely trying to open a VI. This should work.

Again sorry for the confusion on my part. Let me know how things go.

Tyler H.

National Instruments

Message 8 of 9
(4,981 Views)

I need to update the server.tcp.acl with local host(in the labview.ini). What will be the Value for that?

 

How to generate? Will it vary for LabVIEW versions?

 

Any Suggestion!!!

 

Suresh

0 Kudos
Message 9 of 9
(4,315 Views)