Issues with connecting to remote OPC server through a VI.

[NIJanell]

Hello JH2006,
Unfortunately, Windows Server editions are not supported platforms for LabVIEW.  Could you try running these VIs on a Windows XP machine to see if they are still occurring?
Happy Holidays!
Janell R | Applications Engineer

[JH2006]

Thanks Doug for the reply and the link to the OPC Foundation. I had already reviewed that document but it pertains to Windows XP systems. I have Windows 2000 and Windows 2000 Server.
The odd thing in all of this is that NI's ServerExplorer works fine as I am able to see the remote PC and connect to the OPC servers. My request of NI would be: How does ServerExplorer operate? That way I could program in the same method.
Jason

[JH2006]

Thanks again Doug for your input. Here is where I am at:
1. I have installed LabView 8.2.
2. I am able to connect to the RSLinx Remote OPC Server through NI ServerExplorer utility, create a group, add variables and view data.
3. When I create a new LV8.2 vi utilizing the DataSocket Open function with the following URL
opc://vmstary16s/RSLinx Remote OPC Server/[FCS]BILLET_QUE[82].SLN
I am still getting errors. The error is -2147023170 DataSocket Open in opctest.vi
Your thoughts? Thanks!

[xxxxxxx]

 I have a similar problem. I want to connect to a 3rd  part OPC server on a remote computer running WinXP.
 
When I use the "DataSocket Select URL" vi, I can see the all the variables on the OPC server, but when I try to connect, I get error # 1184 - Path not found, FTP login incorrect, or no FTP write permission.
 
I get the same error using 2 different computers (one running Win2K and the other running WinXP). On both of these computers, an OPC client application from the same 3rd party works fine. I don't really have access to the computer running the OPC server.
 
Does anyone have an idea? Is it possible that Labview has some security features preventing the connection? Can it be disabled?
 
any help would be appreciated.
 

[Doug M]

Just to reiterate, getting remote OPC to work is usually not trivial.&nbsp; It is suggested where possible to run OPC Servers locally. I am not sure why Server Explorer is having no problems viewing the remote OPC items data but I can suggest a few things to look into to try to make this work with Datasocket.&nbsp; First, for users of Windows XP, there is an excellent white paper published by the OPC Foundation on Remote OPC setup.&nbsp; I previously linked to it but there is a version newer than the one I linked called <a href="http://www.opcfoundation.org/Archive/72e9fbfa-6a89-4ef2-9b6d-3f746fd7eb05/Using%20OPC%20via%20DCOM%20with%20XP%20SP2%20v1.10.pdf" target="_blank">Using OPC via DCOM with Microsoft Windows XP Service Pack 2 Version 1.10</a>. Many of the principles in that paper will apply to earlier Windows OSes also.&nbsp; There are quite a few resources on the web for using Windows 2000 with Remote OPC.&nbsp; One by Automated Solutions can be found <a href="http://www.automatedsolutions.com/technotes/opcserverconnectivity/Default.asp" target="_blank">here</a>. Here are some tips:1. Account preparations&nbsp;&nbsp;&nbsp; (a) If you work with two computers in the same domain, just add your domain account to the 'administrators' group in both computers.&nbsp;&nbsp;&nbsp; (b) If you work with two computers not in any domain, create two totally same accounts (same user names and same passwords) for both computers.&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; And make these two accounts as member of the 'Administrators' group. (Or you can assign the same password for both 'administrator' accounts.)2. Configure DCOM settings correctly according to the documents linked above.3. 'Security Options' configuration (both sides)&nbsp;&nbsp;&nbsp;&nbsp; Launch the 'Local security settings' window. (Control Panel -&gt; Administrative Tools -&gt; Local Security Policy)&nbsp;&nbsp;&nbsp; Choose 'Security Settings -&gt; Local Policies -&gt; Security Options' from the left tree. And make sure the value of policy 'Network access: Sharing and security model for local accounts' &nbsp;&nbsp;&nbsp; is 'Classic - local users authenticate as themselves'.4. (For users of DSC and the Shared Variable Engine) &nbsp;&nbsp;&nbsp; The default user name of the Shared Variable Engine is SYSTEM which is the top priority account in windows system. If you leave the Shared Variable Engine under this account,&nbsp;&nbsp;&nbsp; you have to make sure the remote OPC server's identity property is NOT 'the launching user'.<img src="Loading Image..."> 5. Making the Shared Variable Engine work with a specified account should make things work more smoothly.<img src="Loading Image..."><img src="file:///C:/DOCUME%7E1/dmumford/LOCALS%7E1/Temp/moz-screenshot-1.jpg" alt=""><img src="file:///C:/DOCUME%7E1/dmumford/LOCALS%7E1/Temp/moz-screenshot-2.jpg" alt=""> Message Edited by Doug M on 03-15-2007 11:19 AM


OPC1.JPG:
http://forums.ni.com/attachments/ni/170/235800/1/OPC1.JPG


OPC2.JPG:
http://forums.ni.com/attachments/ni/170/235800/2/OPC2.JPG

[Chris_From_Brussels]

Hello Doug and the others,
The link you mention is interesting but known. I have the same issue as the one mentioned by JH, XXX and so many others. I guess what is really odd with Labview is why when all other OPC clients in the world succeed to connect to a remote server when the DCOM is configured properly, still the Labview cannot, using Datasocket or DSC. What are the differences? I thought that from Labview 7 to Labview 8 there was a major improvement in the sense that now Labview respect the same OPCENUM than Kepware client for instance (no more regedit connections), but still I cannot connect remotely with DS where it is so easy to do with Kepware, Excel or Applicom OPC client.
Where is it possible to find detailed info about the way DS and DSC use the OPC connectivity to a remote server? Why is Labview OPC client different than all others clients?
Why cannot NI make those simple tests: PC A with a 3d party OPC server (Applicom is a good example) and PC B with Labview 8.20 (DS and DSC to be used) and go step by step in the DCOM and all other peculiar settings needed to make it work and publish the details of the procedure, a link to the OPC foundation document is not enough to make it work (for Labview), sorry. I have lost so many hours in Labview 6, 7 and 8 to try to understand and never could get a support from NI sadly as if nobody out there knew how the Labview OPC clients differ from the others...
Thanks
Christophe

[xxxxxxx]

Finally, I have purchased a third (fourth?) party software - OPCWare - that is compatible with Labview through ActiveX. It works great. There is definitely an issue with Labview OPC client. In the future, I might run the Labview client locally with the OPC server and communicate to&nbsp;the client&nbsp;from my remote computer through a TCP connection. It has 2 advantages: solves the OPC issue with Labview and it creates a layer between my application and the OPC server. That way, if the server changes, I don't have to change the full application. The problem with Labview OPC client remains though...
&nbsp;

[xxxxxxx]

Hi HenryLimmer,
&nbsp;
I'm not sure what is your issue. On one hand, if your issue is speed, I don't think I can help you. My setup needs approximately a response time of 200 ms and I get that. I don't know what kind of speed performance you should expect from OPC on a network. Your network characteristics might be important here.
&nbsp;
On the other hand, if you have issues with configuring OPCWare, what thing I found is that you need to Enable the "Network access:Let Everyone permissions apply to anonymous users" in the Control Panel/Adminitrative tools/Local Security Policies.
&nbsp;
I hope it helps
&nbsp;