- Posts: 8
- Thank you received: 1
Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.
Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.
Do not use the Contact page for technical issues.
UA interface for non-UA OPC
And yes, it is almost self-evident that j-interop always uses the "remote" channel. It implements the "wire protocol" of DCOM, so even when locally, it needs to go over the network loopback. J-interop does not "hook into" local COM objects directly.
If the issue is in j-interop and related permission etc., OPC UA has nothing to do with, and cannot help here.
PHP: it works well. I used it as evidence of working communication between QuickOPC and OPC classic server in my enviroment.
J-interop: For creating connection the library need some special permissions even on localhost. I don't know which one, because we found out it after somebody dramatically change permissions settings. As I wrote I suspect j-interop uses remote connection for localhost as well. According the exceptions I seen during issue I thing j-interop use samba for connection.
In another - easier - way: j-interop not works without super administrator account (in some enviroments).
There are only 2 ways to use QuickOPC: With .NET, or with COM. QuickOPC is mainly written in .NET, and it provides the "best" interface and biggest amount of features. COM layer is implemented on top of the .NET code, and is a bit limited (although sufficient for most purposes).
So, if the J-interop and COM do not work well with you (can you give some details?), the only remaining option with QuickOPC is .NET.
The whole QuickOPC documentation is full of examples in .NET, and they are also installed with the product.
But, you need a tool/language that can consume .NET. If your requirement is Java, you would need some Java-to-.NET interop. This is not my area of expertise. See e.g. stackoverflow.com/questions/6378022/java-net-interop .
You still have not explained what's the issue with PHP. In our experience it works relatively well with QuickOPC over COM.
Thanks to you I am able to describe our issue better:
The communication QuickOPC - OPC classic server over COM/DCOM (points 4 -6) works correctly. I know it because PHP application communicate with QuickOPC correctly.
I have issue with application in java. The issue is probably caused j-interop. So I am looking for another way how communicate with QuickOPC (not COM/DCOM).
In your scenario: I need replace 3 and remove/replace 2
You write standart communication way is .NET. Do you hava come samples? Have I another options? Thank you
I think it is much clearer now.
Now, I do not understand what actually is the problem here: "The issue we have is in point 3, because another our app (in PHP, same computer) communicate with 4 via COM correctly.". Another application, including PHP, can use (4) QuickOPC too, why not? [The PHP app must be on Windows, though]
And, coming back to your original question: QuickOPC is also OPC UA client. Therefore, if you replace (6) with OPC UA server (or the server is both OPC "Classic" and OPC UA server), (4) QuickOPC will be able to use OPC UA communication (usually "opc.tcp") in place of (5) (instead of COM/DCOM).
In this case, your Java applicaton, or PHP application, can still communicate with (4) QuickOPC over COM. But, it needs to use another set of QuickOPC objects and methods (for start, it needs to instantiate the EasyUAClient object and not the EasyDAClient object). The API is somewhat different, although you would recognize that the main principles remained.
Your summary is very helpfull.
So, when I say DCOM I usualy mean a)
The whole, broad meaning - DCOM can be either remote or local
To your question 2:
Everything is on one computer.
I can confirm your scenario Just point 3 - I am not sure if j-interop use local or remote access. I suspect it uses remote for localhost as well.
The issue we have is in point 3, because another our app (in PHP, same computer) communicate with 4 via COM correctly.
First of all, let's explain some terms. "DCOM" (Distributed COM) is an extension of Microsoft COM (Component Object Model). COM by itself only works locally (server and client on the same machine). DCOM also allows remoting.
When somebody (you) uses the term DCOM, it can therefore mean two things:
a) The whole, broad meaning - DCOM can be either remote or local
b) it is used *in contrast* to the term COM - that is, by saying DCOM, you are basically saying "I am doing things remote".
I do not know for sure which of the above meaning you have in mind.
Then, there are some more questions that come with the fact that you are using J-interop. This means that if you Java code is using QuickOPC, it is using it via COM interface (as opposed to the .NET interface which is how QuickOPC is primarily written). So that's the FIRST usage of COM. And then, if OPC "Classic" (not OPC UA) is used, QuickOPC communicates with the server using COM or DCOM - so that is the SECOND usage of COM. So, my current understanding of your architecture is as follows:
(1) Java application ->
(2) J-interop ->
(3) COM ->
(4) QuickOPC ->
(5) COM/DCOM ->
(6) OPC "Classic" server.
Can you please confirm the above. And, if it is correct, please tell me how many "boxes" (computers) are involved, so make clear to me where the remoting is used, and, on which of these the components (1), (4) and (6) reside. So, for example, I would expect that most likely answer is that there are 2 computers, say A and B, and that (1) and (4) reside on A, and (6) resides on B. Please confirm.
If you have placed (1) and (4) on different computers, and used "true" (remoting) DCOM in place of (3), that would be quite unusual scenario.
Only after all of this is clarified, I can go back to your original question.
We have another applications written in PHP. This apps communicate with QuickOPC via DCOM too. And this is working on all computers.