Open Appl Ref gives Error 66

[Gary Armstrong]

I am using the VI Server to access controls on a vi running on a remote computer. This interaction is intiated with a call to the Open Appl Ref VI, it returns an error 66. Independent of what we do to the VI Server Configuration and Access List (Tools->Options), the result is that same. I can ping the remote computer. I can open the port (3363) with a telnet command from the command window ( telnet 192.168.10.15 3363).

All this started when I ported the main LabVIEW application (LV82) to a new computer with LV86. The main LV82 application on the older computer can talk to the remote computer (running LV82) just fine.

We have read some of the info in the NI Forums on server.tcp.acl in the LabVIEW ini file and have changed and played with it every way possible but can not resolve the problem. (http://forums.ni.com/t5/LabVIEW/Trouble-with-Error-66-in-LV-8-2-1/td-p/580394)

We can run the LabVIEW VI Server example on the remote computer to talk to the main computer but can't get things to work the other way???

[Grampa_of_Oliva_n_Eden]

I am using the VI Server to access controls on a vi running on a remote computer. This interaction is intiated with a call to the Open Appl Ref VI, it returns an error 66. Independent of what we do to the VI Server Configuration and Access List (Tools->Options), the result is that same. I can ping the remote computer. I can open the port (3363) with a telnet command from the command window ( telnet 192.168.10.15 3363).

All this started when I ported the main LabVIEW application (LV82) to a new computer with LV86. The main LV82 application on the older computer can talk to the remote computer (running LV82) just fine.

We have read some of the info in the NI Forums on server.tcp.acl in the LabVIEW ini file and have changed and played with it every way possible but can not resolve the problem. (http://forums.ni.com...2-1/td-p/580394)

We can run the LabVIEW VI Server example on the remote computer to talk to the main computer but can't get things to work the other way???

After verify the target machines ACL and otheer VI server stuff is correct in the ini used on the target then check the port used for TCP and verify the firewasll has that port open.

That is all that comes to mind off hand.

Ben

[Gary Armstrong]

FIre wall is off. No virus sw running.

We are on an isolated network with no router, only a switch, so there is no DNS other than the Resolver Cache provided by Windows XP. I have run "ipconfig /displaydns" from the cmd window and see the loopback address. I have also run "ipconfig/ flushdns".

After verify the target machines ACL and otheer VI server stuff is correct in the ini used on the target then check the port used for TCP and verify the firewasll has that port open.

That is all that comes to mind off hand.

Ben

[Cat]

When you start getting real desperate... if you can, put 8.6 on the old computer, recompile, and see if your app still runs. If it does the problem might be the new computer.

[Grampa_of_Oliva_n_Eden]

When you start getting real desperate... if you can, put 8.6 on the old computer, recompile, and see if your app still runs. If it does the problem might be the new computer.

Cat called my attention to a subtlty I missed.

Since the client is now running LV 8.6 and the target is running 8.2 and the changes were added between those two versions... I am suspecting the target will need updated.

check that!

My associates tell me they are serving 8.2 on cFP to 2009 apps on Windows.

Not sure what to say now.

Ben

[Rolf Kalbermatter]

Cat called my attention to a subtlty I missed.

Since the client is now running LV 8.6 and the target is running 8.2 and the changes were added between those two versions... I am suspecting the target will need updated.

check that!

My associates tell me they are serving 8.2 on cFP to 2009 apps on Windows.

Not sure what to say now.

Ben

The only incompatibility I'm aware of for VI Server communication between different LabVIEW versions was I believe between 5.1 and 6.0 and also only from 5.1 server to 6.0 client, because they added some extra features to the initial connection establishment message.

[Gary Armstrong]

I added the IP addresses and names to the Windows hosts file which fixed the problem (for several days), until I updated the Licenses file and now it is broke again???