Re : Re: Issues with connecting to remote OPC server through a VI.

[Doug M]

Just to reiterate, getting remote OPC to work is usually not trivial.  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.  First, for users of Windows XP, there is an excellent white paper published by the OPC Foundation on Remote OPC setup.  I previously linked to it but there is a version newer than the one I linked called Using OPC via DCOM with Microsoft Windows XP Service Pack 2 Version 1.10.

Many of the principles in that paper will apply to earlier Windows OSes also.  There are quite a few resources on the web for using Windows 2000 with Remote OPC.  One by Automated Solutions can be found here.

Here are some tips:

1. Account preparations
    (a) If you work with two computers in the same domain, just add your domain account to the 'administrators' group in both computers.
    (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. 
          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)
     Launch the 'Local security settings' window. (Control Panel -> Administrative Tools -> Local Security Policy)
    Choose 'Security Settings -> Local Policies -> Security Options' from the left tree. And make sure the value of policy 'Network access: Sharing and security model for local accounts'
    is 'Classic - local users authenticate as themselves'.

4. (For users of DSC and the Shared Variable Engine)
    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,
    you have to make sure the remote OPC server's identity property is NOT 'the launching user'.



5. Making the Shared Variable Engine work with a specified account should make things work more smoothly.

Message Edited by Doug M on 03-15-2007 11:19 AM

[Christ0phe]

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

[MarcDub]

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 the client 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...

[henrylimmer]

xxxxxxx and others,

Based on your post, I have downloaded OPCWareX and am trying to get it setup as an OPC client to operate between my OPC server and LabVIEW. Is there any way you can walk me through the steps you used to get data passing smoothly between LabVIEW and your OPC server using OPCWare? I'm having limited success, especially with registering ActiveX events and callback VIs.

I have been using DataSocket connections, front panel object Data Binding or both in my control programs thus far. I'm now to a point where I just can't get data to pass between my OPC server and LabVIEW as fast as I'd like. I can't seem to read new values faster than 30-50ms and I believe that my Automation Direct Terminator field I/O is "faster" than this. I have a total of 56 OPC tags that refer to physical channels of discrete and analog I/O. There are a handful of configuration and status tags, most of which don't concern me.

Thanks very much for any help you can provide!

[MarcDub]

Hi HenryLimmer,

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.

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.

I hope it helps

[Christ0phe]

Hello all,

I think I am now able to make a complete answer, after hours and hours of interesting discussions with NI R&D.

1st case: OPC server on a Windows 2000 box. Labview 8.20 DataSocket on a Windows 2000 box. Not in the same domain.

Run the attached SetupDCOM_DASIP_HMI_W2K.bat file on both the server and the client PC and restart. All this .bat does is to set the proper DCOM configuration.

The other thing to ensure is that the username/password/domain on which the server is logged is the same as on the client PC.

2nd case: OPC server on a Windows 2000 box. Labview 8.20 DataSocket on a Windows XP box. Not in the same domain.

Run the attached SetupDCOM_DASIP_HMI_W2K.bat file on the server and restart.

Run the attached SetupDCOM_DASIP_HMI_XP.bat file on the client and restart.

The other thing to ensure is that the username/password/domain on which the server is logged is the same as on the client PC.

3nd case: OPC server on a Windows XP box. Labview 8.20 DataSocket on a Windows XP box. Not in the same domain.

Run the attached SetupDCOM_DASIP_HMI_XP.bat file on both the server and the client and restart.

All it does is to enable the DCOM, add Anonymous Logon, Network, System and Interactive in the Dcom securities (activate and launch) and switch the Local Security Policy: Network access: sharing and security model for local account=classic

In this particular picture (XP to XP) the username/password/domain do not need to be the same on both PCs but the username/password with which the server is logged on must be defined in the list of username/password of the Labview PC (client). Note that in some cases this was not even necessary but I was not able to conclude why it worked without defining it in the Labview PC.

Another thing to ensure is that the Labview.ini or the application_name.ini file contains the line 'ole.authnlevel=1'.

Finally before making a first DataSocket connection to the remote server, there is a need to create a first connection to the server PC using a net use. As an example: net use w: \\servername\c$ 'password' /USER:servername\username

Typically I make a .bat with this command and put a shortcut in the Startup Folder.

The last message that I got from the R&D mentioned another INI key that I could use to avoid making this first net use before opening the first DS connection (note that other OPC clients tested do not require this step). 'ole.ImpLevel=' could be used with one of the following option, but in my tests I have not been able to improve the situation with none of them. This is what R&D says:

0: default

1: anonymous

2: identify

3: impersonate

4: delegate

I hope this will be as helpful for others than it was for me, this is truly the result of a long fight and am now relieved to use the DS communication for OPC instead of using (and paying) for the whole DSC.

Christophe