0x80040112 error when connecting to RS Linx OEM

[Frederick R]

Hello,

i'm newbie on OPC Client development, recently i create a client using utgard lib and it work for several OPC vendor such as Matrikon, Softing, RedLion, etc.. but when trying to use it with RSLinx, i encounter this 0x80040112 error, has anyone encounter a 0x80040112 error when connecting to an OPC Server especially RSLinx? any idea what might cause this error? any workaround for this?
i read that there is a license issue in which RSLinx only allow OPC when the license is OEM or Gateway, but here i have the OEM license and still get the issue.

Please help..

Many thanks and best regards
Fred

[Justin Smith]

I have not dealt with RSLinx in some time so I may be a bit off, but I think you need RSLinx Gateway installed regardless of your license (OEM or Gateway) to make this work.  I'm an integrator, so we usually connect to an instance that is already running, and I have not seen this error.  I did find this when I checked Google for your error code.  http://www.opcfoundation.org/forum/viewtopic.php?p=9178

JInterop is the interop library behind utgard, and the project website mentions the threading model: http://j-interop.org/faq.html#A3

I put a simple project on github a while back, specifically for browsing tags in an RSLinx Gateway system, https://github.com/summitsystemsinc/netbeans-opc-browser . I can't say that I had a similar experience as you with the Gateway, as I recall it worked for what I needed. Maybe look at that code and see if anything is different?  Just keep in mind, we have not touched that code in some time, and it may be lacking.  We used it to debug a third process that was making OPC connections.

Have you verified the DCom object you are trying to connect to with a third party app, i.e. anything listed at http://www.opcconnect.com/freecli.php ? I've always found that the first step to debugging OPC DA and Java, was to make sure it worked in the native Windows stack first.

--
You received this message because you are subscribed to the Google Groups "openSCADA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openscada+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Justin Smith
Summit Management Systems, Inc
(615) 281-9454
Skype: jwsmith22

People demand freedom of speech as a compensation for the freedom of thought which they seldom use.  ~ Soren Kierkegaard

[Frederick R]

Hello Justin,

Thanks ! i've checked your first two link and it seems the threading model is not the problem here, what interest me is that you mention there is an application called RSLinx Gateway, and i thought 'Gateway' is a license name, i will check if i miss some installation here.

just now i try to use Matrikon Explorer and Matrikon simulator server to test the DCom in the PC as you suggested, and it can get the data without problem, additionally.. it also can read the RSLinx..!
back again with my custom client, it can read the data to Matrikon simulation server, but sill cannot read from RSLinx, how on earth Matrikon can read it ?  :(

first thing first, i will check the RSLinx Gateway you mentioned.

Best regards,
Fred

[Justin Smith]

If Matrikon can read it, then you must have the proper software and licenses.  All of the RSLinx stuff is confusing to me.

Fred

--

You received this message because you are subscribed to the Google Groups "openSCADA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openscada+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Frederick R]

Hello,

Got a question regarding how DCOM works, is the connection made to DCOM considered as a remote connection, even though it was requested by local application ?
Reason of my question is maybe the 0x80040112 was raised due the connection considered a remote by RSLinx, and since it is a OEM license, it won't allow the connection. Sorry if my question is a bit off, i'm still learning on this DCOM & OPC stuff.

Thanks in advance
Fred

[Jens Reimann]

Well with Utgard every connection is a remote connection. This is due to the fact that Utgard uses native java which can only access com using the network layer dcom. Even if it is remote windows does not make a difference between a local IP connection an a remote one.

[Kyle Hayes]

I'm a bit late with the reply, but I think I have seen that kind of error before (not using Utgard) and it did have something to do with the version and licensing of RSLinx.  It is finicky.  Here is a link that might help:

http://support.softwaretoolbox.com/app/answers/detail/a_id/2812/~/opc-data-logger-and-rslinx---getting-error%3A-class-is-not-licensed-for-use

We decided to drop OPC and our reliance on Windows for our latest HMI work.  We have too many systems where the OPC wrappers or other Windows-side components leak memory or otherwise are not stable/reliable (nothing to do with OpenSCADA!).  We are not using OpenSCADA yet, but we follow it in the hopes that we can use it at some point.

We have our own library in C with a Java wrapper to directly contact Allen-Bradley PLCs.  It has taken a long time to get to this point with the library, so I have not posted much at all before this.  We are currently rolling out our first HMI on Linux using our library and wrapper.  We aim to release the library under the LGPL license when we are done.  If there is interest, I'll post back to this list when we have it released.

Best,

Kyle

[James Renault]

This error simply means your RsLinx OPC server is installed properly, but it isn't licensed for use.  I don't know the reason Rockwell is using this specific error, but I did get it as well.  I used OPCTI's OPC Expert (www.OpcExpert.com), and it told me the cause.  Once I talked to Rockwell and licensed the OPC server, everything worked fine.  Let me know how it goes.

[Andrew Stitt]

I was getting this same error and discovered I had the wrong CLSID. I used the CLSID listed in Component Services (dcomcnfg.exe) under "RSLinx, which was {A05BB6D6-2F8A-11D1-9BB0-080009D01446}. As it turns out this is the DCOM clsid for remote connections only. The clsid for local connections is {A05BB6D5-2F8A-11D1-9BB0-080009D01446}  (note the 8th digit is a '5', not a '6', and this clsid is not listed under DCOM configuration) 

I'm posting here because I searched google for days, and nowhere did anyone suggest I might have the wrong clsid. Plus the 2 clsid's are so similar, that a visual check did not confirm that it was wrong.

I hope this helps other people. 

 

[Amouzigh Driss]

Hello,

I have the same error when trying to connect to both A05BB6D6-2F8A-11D1-9BB0-080009D01446  and A05BB6D5-2F8A-11D1-9BB0-080009D01446

What should I do in this case?