Today is...
Friday, April 19, 2019
The OPC Community Forum.
VB OPC client and network
Using OPCDAAuto.dll to make an OPC-client in VB over LAN

Hi, we are a group of students in Norway and we are trying to make an OPC-client that works over ethernet. We downloaded VB example from Steeplechase and it works fine when the OPC-server is on the same PC as the client. We canīt get it to connect to a server which is on the same network. Thatīs why we opened a new VB project using the opcdaauto.dll and its methods but it still canīt find nor connect to another OPC-server. Are there any restrictions on the dll?
We have done dcomcnf.exe but it still doesn't work over network.We have tried also "DrDCOM" from intellution, but it can't get access to registry. What else have we got to do to get any client-server communication over network?
We use NT4-server and NT4Workstation on pentium PC. Don't have any PLC , but think to use Iconics simulation-server in the beginning.

Grateful in advance

DCOM is the issue.
First, insure you can ping (ie. TCP/IP ok)
2, for test....be logged in on both machines as domain administrator.
3. DCOM must be configured correctly on BOTH ends.
- ENABLED on both ends
- on server end: under properties for the appexe, custom config permissions,
add/set SYSTEM, INTERACTIVE, and NETWORK (SIN easier to remember) properties to
everyone.

Once it works....back the security back into more safety...testing as you go.

By Gumshoe_2701 on 29 January, 2002 - 1:54 pm

If you are still experiencing problems, a complete DCOM configuration guide is included with some sample OPC servers and clients.

For example:
The Matrikon Simulation OPC Server and test client.
"http://www.matrikon.com/drivers/opc/simulation.asp":http://www.matrikon.com/drivers/opc/simulation.asp

NOTES:

- The install has its own version of the OPC Automation DLL (most vendors do, who's implementation are you using anyway?).

- DCOM configuration gets even worse if the machines are on different domains.

- DCOM timeouts are ~16 minutes, this is hardcoded into the OS kernel.

Good luck.

By Frank Iwanitz on 29 January, 2002 - 11:35 am

Hi,

there are some things related to security to consider. DCOM security is user related, i.e. a user (or a group of them) is allowed or not allowed to do something. If client and server are running in a domain, make sure that domain users are used for security settings, if client and server are running in a work group make sure that the users are known on all pcs. DCOM security differentiates between launch and access rights, authentication and impersonation. Launch and access rights can be set either on system wide level or on component (application) level. For the first try enter SYSTEM, Administrator, Everyone and Interactive both for launch and access rights. This can be later restricted to specific users. After launching the component, it is more or less reachable for everyone. The DCOM protocol is known, anybody can implement some program to interact with a component without having started or accessed it. to avoid these things authentication is used. The server (and very important for opc the client for callbacks) can try to authenticate the calling user. This can be performed on different authentication levels. They can be set again on system level and component level. For the beginning set the level to None. You must set it both on the client and the server pc. This avoids problems, if users are not known, e.g. an Administrator on one pc is not known on another. Sometimes a server must be able to act on behalf of the cleitn, e.g. to obtain its user identity. The client can set the so called Impersonation Level. For the beginning set it to Impersonate. this si a system wide level, that must be set on the client pc. At the end have a look on a application specfici setting called "User Identity". Set the identity either to Interactive User or (the best solution) set it to "This user" and define a specific user.

Regards,

Frank

I have the same problem however when attempting to connect to the OPC server on a remote machine( on the same network/domain) I get the following error:

Error connecting to Node:leader, ProgID:HWHSC.OPCServer. -2147467259: Method 'Connect' of object 'IOPCAutoServer' failed

I am using VB and the OPC Automation 2.0 library.

Is this a DCOM problem also?

By Conny Jakobsson on 6 November, 2002 - 1:34 pm

I have this problem too. It worked fine until recently, but not anymore. I cannot remember any changes to my computer configuration that could cause this. The OPC Server per see works fine.

/ConnyJ

By Conny Jakobsson on 6 November, 2002 - 1:34 pm

OK, I was too quick. After the last e-mail I first tried to just reregister the OPCDAAuto.dll with regsvr32.exe, but that didn't help at all. Then I reinstalled it and that made it work directly.

I've got the DLL from Matrikon with their Simulation server. I used this servers installation program and deselected everything else but the OPCDAAuto.dll. That made it work.

I still don't know why it worked, and that makes me a little nervous. I hope someone will come up with an explanation.

/ConnyJ.

Sorry,
I have the same problem: "Error connecting to Node:leader, ProgID:HWHSC.OPCServer. -2147467259: Method 'Connect' of object 'IOPCAutoServer' failed
"

I tried the KepwareEx as the OPC Server and the INFILIK HMI included in this package.

I tried the VB example in the kepwareEx software and it works fine in the same local machine, but when I changed the nodeServername by the IP address of the server where i ran the KepserverEx OPC server and then I ran the VB client in another PC. voila!!!

BUT, I tried the remote connection with INFILINK and all works fine!!!!!!

ref.: www.kep.com, www.kepserver.com

Regards,

TG

By Fred Loveless on 19 December, 2002 - 8:18 am

Hi, I do the VB support at Kepware. The error code that you are seein "-2147467259" or hex code "0x80004005" is an access violation that is usually directly related to DCOM security. With DCOM you have to make sure that you allow access and launch to all the Users that are involved in the process.

We generally recommend on a Domain that you enable "Everyone" form access and launch to start with. You can narrow it down after you have proven connectivity. If you are running the server as a sevice you will need to add the system user for access and launch on all the PC's as well since that is where the server runs as a service and if it is not added then you will never see the response to your connectin message.

We have also notice problems with connecting from VB when running as a service unless you have OPCenum.exe running as a service as well. You can make this run as a service by typing OPCenum /service from the command prompt.

Also on the remote PC that is connecting to the server you should have the server registry entries. The easiest way to do that with KepserverEX is to use the server install set but only select the OPC Quick Client for install. This makes the required registry entries and installs the OPCenum.exe, opcproxy.dll, and opccomn_ps.dll files. You can also use the quick client to check the server connection although it uses the registry to browse for servers rather then opcenum which is what the Automation wrapper uses. I believe that Infilink uses the same method as our Quick client.

Ok, the last 2 things I want to mention are a bug that was introduced by IE6.0 that effects OPC connectivity on none Win2k OS's and the automation wrapper itself "opcdaauto.dll".

First the bug. IE6.0 installs an OPCenum and OPCcomn_ps.dll file that have a bug that does not allow you to browse for OPC servers on non Win2k OS's. The OPC Foundation has finally gotten new ones and our latest install set will install the update ones.

Secondly, the OPC Foundation provides a vanilla Automation wrapper that all is provided to all OPC Foundation members. The members are encouraged to recompile this wrapper with a unique name and ensure that it works with their product. Kepwares wrapper is named kepopcdaauto.dll. We had clients that experienced problems doing remote connections with the vanilla wrapper but ours seems to be working correctly.

Sorry this is so long. Visit Kepware's web site at http://www.kepware.com or http://www.opcsource.com and check out our manuals and viewlets on DCOM.

By Charles Treen on 13 January, 2003 - 11:26 am

Fred,
I believe that Kepware have a file OPC_remote.reg that adds registry information to the CLIENT using RSView32, in order to allow RSView to see remote Servers. I have a remote server which works well normally, but with RSView32 it can only be seen on the network, but not browsed. Are you able to let me have a copy of OPC_remote.reg that I can customise for my app. email to charles.treen@loma.co.uk if you are able & willing! Thanks very much
Charles Treen.

By Mark ravid on 6 May, 2002 - 4:18 pm

I was looking for that demo from Steeplechase, but since they were bought by Schneider their website does not exist anymore. Could you please send your personal email for a copy?

Regards

I can send you a copy of steeplechase client if you supply your e-mail. Our e-mail is "at60202b@studpors.hit.no", mailto:at60202b@studpors.hit.no
We succeded to make it work over LAN but are still interested how it could work over different domains.
Regards

Boris

DCOM security settings are only relevent if both of your computers have the same PDC (Primary Domain Controller). Otherwise on both computers you need to configure local accounts with exactly the same names and passowrds, then run you OPC connection under that particular account.

Regards,
vvv

By Anonymous on 28 May, 2002 - 6:06 am

I suggest u install service pack 6 on winnt

Just completed a project getting a VB based server to talk to Win 2000 Client (RSView32) over a NT hosted network. Not easy! I found that our OPC Server needs to be registered with the client, and initially achieved this by setting the OPC Server up as a network drive of the client, which obviously forces registration.

In a workgroup passwords must be common, and in a domain the server must be a fully trusted domain member. I use DrDCOM to check out the link - by far the best tool so far, although ENUMTEST from OPC Foundation also works well - in general I find that if it passes the DrDCOM test it will work, although some SCADA systems, RSView32 for example, only support OPC 1.0. If you are NOT registered with the client there is very little chance of getting the link working!!!!
ctreen.

Dear sirs,

I experience some problems connecting the VB OPC client to the OPC Server if the VB is located in a diferent PC, but just few days ago I received a note from Kepware and they mentioned that it is neccesary to add some lines in the windows registry. I will try this maybe this weekend and if it succeed I will tell you how to connect the VB to the OPC server.

I will include in this e-mail some explanation that maybe will help us to connect the VB to our OPC Servers.

some ref: http://www.kepware.com/Support/KEPServerExRemoteDCOMConnection.html

download the pdf document: http://www.kepware.com/Support/SupportDocuments/Dcom_Configuration.pdf

If you made it works, please tell us. I will try it to this weekend.

Regards to every one,

tgiacaman

By Anonymous on 31 May, 2005 - 10:53 pm

Have you try to use same "user name" and same "password" between those computer???