Trouble with Error 66 in LV 8.2.1

[mikeporter]

Thanks for the information Travis, but as I stated I changed the access list several times - including adding the specific IP address I'm trying to access the system from - and LV never created the setting. In addition, if the default is to only allow access from the development system's IP address there is then the question of why the person in tech support was able to create a small executable and access it from another computer without the setting even existing in the INI file.

Mike...

[Ben]

Hi Travis,

Let me thank you as well.

AS Rolf mentioned documentation is critical and will make a big difference.

I'd also like to mention a use case slightly different from what I hear you describing.

In another one of my applications, I use multiple PC to run a mfg facility.

There is one master and multiple slaves.

The Master serves action engines via VI server to the slaves.

Each PC has LV installed.

To keep the line up and running all machines are identical except for their configuration which controls if they come up as a master or a slave.

If any node fails, we can swap in a spare and get the line back up and running.

So in our case we need to make sure that any PC can target VI's any any of the other PC's.

So please keep this use case in mind as you are chasing through this issue.

Thank you,

Ben

[THailey3]

Mike, I am also testing with LV 8.2.1 and do not see the behavior you describe.  It might be worth calling support and walking through this on the phone with an Applications Engineer (maybe you're doing something slightly different).  As far as documentation for ini tokens goes, it is something we have given thought to.  However, our mentality is if there is a token that we want to officially support and document, then we want to have UI support for it.  In this case, the corresponding UI for the server.tcp.acl token is the VI Server: Machine Access Options Page and the VI Server: User Access Options Page, both of which have documentation in LV Help, but from a UI perspective.  Theoretically, if everything is functioning as we'd like, there would not be a need for users to know about the token as configuration would be handled through the UI.  In this case, there was a problem transferring the token to the application's ini file upon build, which we will investigate fixing in a future version. 

If in the future we come out with a better way of specifying and configuring ini tokens in a build specification, I suspect there might be more formal documentation on the appropriate tokens.

[dan_u]

We have a special use case where it would help a lot if the acl token was documented as we would then be able to create a user interface that allows the user to configure access to the built application.
Here's our scenario:
Our clients get a built application and a set of LabVIEW functions to remote control the application via VI server. Now we don't know what IP address should have access to the application (and also we don't want to create customer-specific installers). But it is quite complicated to teach customers how they have to create this acl token for the exe so VI server will work. They might not know LabVIEW very well, especially they might not even know VI server and honestly, they shouldn't have to.
And for security reasons we don't want to allow access from any IP address.
What we would like now is to include a configuration utility in our application that would modify it's own ini file. But to do this, we would need insight to the acl token.
Or does anybody know another good solution?

Thanks,
Daniel

Message Edited by dan_u on 09-22-2007 12:06 AM

[mikeporter]

There isn't a way to manipulate the acl value directly, but you should still be able to get to where you need to go. As I think I indicated in another post, there is an application property that allows you to programatically define what IP addresses are allowed to access your application. The long name of the property is Server:TCP/IP Access List (short name is Srvr.TCPAccess). There is even an example that ships with LV showing how to use it.

Mike...

[dan_u]

That sounds great. I don't have LabVIEW here, I will try that on Monday.
Thanks!
Daniel

[dan_u]

Thanks again for the hint using the application properties to configure VI server access. It seems to work, I can set the access list and enable/disable the server. The only thing that doesn't seem to work in a compiled application is to set the port. It will always use the port specified in the .ini file (server.tcp.port). If no port is specified it doesn't work at all.
To me this looks like bugs in the implementation. If I change the access list of a compiled application (from within the app.) the server.tcp.acl parameter is changed in the .ini file. If I enable/disable VI server I don't see a change in the .ini file but the change is still applied. When changing the port number no change is done in the .ini file and the change doesn't even apply.
(All tests performed in LabVIEW 8.5).

It seems I can get to where I want to with this, but I don't believe this is expected behaviour.

Daniel