LabVIEW
Reading a control from LV Built application.
I am trying to establish a VI Server connection between a LV VI that is in the development environment and an executable that was built using the LV Application builder.
So I built an application that increments an indicator (name: "numeric") once/sec. This is called "Test Exec.app" which is built from the single VI "Test Exec.app". My main LV preference for LV 2020 is actually 3376 to keep from version collision.
I edited the "preferences" file for that application to have the following:
server.tcp.enabled=TRUE
server.tcp.port=3374
server.tcp.paranoid=True
server.tcp.serviceName="My Computer/VI Server"
server.tcp.access="+127.0.0.1;+localhost;+*"
server.vi.callsEnabled=True
server.vi.propertiesEnabled=True
server.vi.access="+*"
Now I try to open a connection to this application on port 3374 which seems to work. And then a connection to a VI that does not. The only app that it connects to is LabVIEW.app and not my built application even though LV is restricted to another port. Of course trying to open a link to my application front panel fails as that VI is not found.
The documentation seems to imply that this can be done, but the details seem to be lacking. Why is LabVIEW on both ports (3374 and 3376)???! And if I am connecting to LV on the port, why does it not show the executable?
Long shot...
Do you need a server.tcp.acl line in your ini file?
It's plausible you'll get a connection, but no access without it.
See
Search LabVIEW like a graph! Thanks for the pointers. Now I have to figure out how to give access to single VI? Or is it the executable build name? Does it have the .app (.exe) extension?
Since this executable has its own unique port then the only "VI" should be the top level VI or does it allow sub-VIs in the executable.
It seems like that acl is a mystery code, that one has to just use and can only have that particular value?
[Interlock 32T Network Client.app]
server.app.propertiesEnabled=True
server.ole.enabled=True
server.tcp.paranoid=True
server.tcp.serviceName="My Computer/"
server.vi.callsEnabled=True
server.vi.propertiesEnabled=True
WebServer.Enabled=False
DebugServerEnabled=False
DebugServerWaitOnLaunch=False
server.tcp.enabled=TRUE
server.tcp.port=3375
server.tcp.access="+127.0.0.1;+localhost;+*"
This is my .ini file but shouldn't the server.tcp.access be the acl?
Yes, but what does it specify. I can't really find a reference since LV 2011. There is a vi.access token
server.vi.access that does essentialy the same thing? It specifies what access is allowed for what VIs.
server.vi.access="+Hybrid PS Read gateway.vi;+*"
for example.
But what does the setting mean as an obscure hex string? How does it interact with the server.vi.access token? How is that token interpreted within the executable run time environment.
The VIs in "vi.lib\Platform\security\user" seem to create this information.
NI_Security ACL_Create.vi returns a reference, that has properties and methods. The Flattened ACL method might return the ini file data, but haven't tested it. There's no help at all...
There are also a few brown nodes in Application>NI Security.
Something in the lines of this:
But frankly, I don't even know how it works from the IDE...
The result is all empty arrays. But the Flattened ACL returns what I put into it, and there are no errors.
Ok, and the reference (thanks! Mike P.) is very thorough and fills in a lot that should probably be in the NI documentation! Of course it contains:
server.tcp.acl=???: This setting defines the TCP/IP access control list (ACL) — or who is allowed to connect to the application. Already I can hear you wondering, what is the deal with that long string? Well, if you ever find out be sure and let me know. The bottom line is that the original interface included an ACL that simply listed the IP addresses that were and were not allowed to access the application. For reasons unknown, NI decided to change this common sense approach to something more enigmatic. So how do you generate this string? Glad you asked. According to LabVIEW’s documentation, you need to set up your development environment to have the same access list as you want your application to have, and then copy and paste the resulting string from LabVIEW’s INI file to your application’s INI file, seriously…Yeah, "seriously???"
BUT, is this only for a previous version of LV? The access list in the LV preferences shows up in the .ini file as a normal text string under:
server.tcp.access="+127.0.0.1;+localhost;+*"
But changing that access does not create a server.tcp.acl token. So either all those references are out of date, or something is no longer functioning as it did when Mike wrote that document in 2015.
BUT, (yes again) Weibe has some interesting code at: Re: Reading a control from LV Built application.
This seems to be what I want but is a very obscure way to figure out the ACL. And of course not documented by NI. (or ni)
For some reason I can't load that code snippet. But in trying to recreate it, I can not find "ACL Create" or "Access Rights Create". I can find NI_Security but it is only a 'change password', login, or login_proxy commands. Is this a windows only functionality?
And if it is windows only do I need the corresponding .ini token on the Mac. I will try to implement that on the windows side since this is a multi-platform application.
This accessing of VI Server methods on an application is "a lot trickier than I thought" as Dennis Moore said.
