Professional OPC
Development Tools


Online Forums

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.

Cannot Connect Topic or Cannot Connect Data Access Client

27 Aug 2014 19:40 #2191 by support
No, there were no changes to speak of in these areas between versions 5.30 and 5.31.

Please Log in or Create an account to join the conversation.

27 Aug 2014 19:34 #2190 by Ahock
He is using Windows 7 32 bit system. He just installed the OPC Data Client 5.30. Would there be any advantage to upgrading to the 5.31?

Please Log in or Create an account to join the conversation.

27 Aug 2014 19:13 #2189 by support
I do not have much more to offer. The failed Advise is at the heart of it, so it will have to do with DCOM settings either in the system or on our part (the various parameters of EasyDAClient - try all the combinations).

Is this 64-bit or 32-bit systems? Which version of OPC Core Components is installed (from the Control Panel?)

Please Log in or Create an account to join the conversation.

26 Aug 2014 13:09 #2179 by Ahock
I've been working with cdunlap on this case and wanted to add a little more information. This is a Windows Form application and the customer tells us he is running as an interactive user. Do you have any ideas on things we can get him to try to help eliminate his errors?


Please Log in or Create an account to join the conversation.

23 Aug 2014 15:57 #2177 by support
I edited the previous post to read

"I was now able to open and view the OPC Analyzer traces."

instead of the incorrect

"I was not able to open and view the OPC Analyzer traces."

Please Log in or Create an account to join the conversation.

18 Aug 2014 07:37 - 23 Aug 2014 15:54 #2170 by admin
I was now able to open and view the OPC Analyzer traces.

Version 5.30 certainly already has the fallback/functionality degradation mechanism I described. This is confirmed by the fact that it continues to communicate with the OPC Server even after the Advise call fails. What is somewhat surprising is the sync Read that follows and succeeds (at the end of both traces). In case of FirewallOff.tra the success of the Read comes approx. 44 seconds after we started the connection process; in case of FirewallOn.tra it is during a second. With the standard timeout of 60 seconds, in both cases this should be reflected as a successful Read in the external API, but I understand that it isn't (ever)? How about subsequent Reads?

Anyway, even if the above is clarified, it is just about the fallback behavior. The true problem is in the failed Advise calls. Actually, both the Advise-s, one on the OPCServer object (for IOPCShutdown) and the other on the OPCGroup object (for data callbacks) fail with HRESULT: 0x800706ba, which corresponds to "The RPC server is unavailable.".

Is there anything unusual about the client app? What kind of project is it - Windows Forms, Windows Service, ASP.NET, etc. Is it running under the interactive user account (some as the other client app that works), or differently?
Last edit: 23 Aug 2014 15:54 by support. Reason: not able to open -> now able to open

Please Log in or Create an account to join the conversation.

17 Aug 2014 22:59 #2167 by cdunlap

Thanks for the input. A Response to your email will hopefully fix the OPC Analyzer problems.

The version of the software being used is 5.30.1034.1, and you are correct in that even when Advise fails, a response will eventually make it back - although this is usually around 20-30 seconds if his firewall is disabled.

I am unsure as to the exact context of the Log1 and Log2 logs -and I will confirm this to be sure - but more often than not, the exception that occurs is "cannot connect topic (timeout)" (Log1.txt). I have seen this one happen in both cases (with firewall on and off).

The customer let me know he also saw this second error "cannot connect data access client" (from Log2.txt) once while doing his testing, athough this may have been from before his current DCOM configuration settings, since now the topic error seems to appear each time.

Are there any particular places in the DCOM configuration that we can check to see if that is the issue? We have tried the most relaxed settings possible on both machines, but there is always the possibility we have missed something.

Thank you again for the help.

Please Log in or Create an account to join the conversation.

17 Aug 2014 16:47 #2164 by support
I am writing this reply without yet being able to open the OPC Analyzer traces - see my email to you. Therefore I am quite limited in what I can see, and my answer should be taken with that in mind.

What you are describing makes sense and I generally agree with it.

Which version of the component are we talking about? The reason I am asking is that newer versions allow (or should allow) a limited functionality even when the Advise call fails. The limitation would be that asynchronous Reads/Writes won't work, and subscriptions won't work. The earlier versions would consider a failed Advise as a problem that fully prevents any operations on the server. I will have to search through the records when the more relaxes approach has been implemented; we might be talking about something like (very roughly) 1.5-2.5 years ago.

Overall, the problem still seems to be in the DCOM communication in the reverse way (from server to client). We are struggling with it more than most other OPC clients do, because the .NET infrastructure initializes the security settings "for us", and we then have to find ways around it to allow for custom settings. OPC clients written in unmanaged C++ or other unmanaged tools(that is, the majority of clients) do not have this issue.

Also, can you please provide a correspondence between the environment used, and the files delivered? (what is Log1.txt versus Log2.txt?)

Please Log in or Create an account to join the conversation.

15 Aug 2014 20:31 #2163 by cdunlap
We have a customer using EasyOPC to write a DA client and he’s trying to establish a remote connection to his Standard Automation OPC Server. All his application does at its current stage is read a tag - nothing complicated, but it fails with an error (diferent depending on the situation). He also sees the same results using the Demo Application.

At first, he ran into the usual DCOM problems, and he should be past those now (after adding OpcLabs.EasyOpc.DataAccess.EasyDAClient.SharedParameters.Client.UseCustomSecurity = false to get around an RPC Server unavailable error) , as he can connect with another test client (OPC Expert). The problem is that he still cannot connect with his custom application.

We have tried with the firewall on and off, and he gets an RPC Server Unavailable (with firewall on) and one of these two errors with it off (the full errors are attached as well):

1. Cannot connect topic (timeout)
2. Cannot connect Data Access client (timeout)

When the firewall is on, the exception is returned immediately, and when the firewall is off, we have to wait for the 20-30 seconds to timeout.

Running the same code 2-3 times produced these two errors, which indicate that some OPC Operation behind the scenes was taking too long and the easyDAClient times out – right?


To get more information, we used the OPCAnalyzer. When connecting with through the Analyzer(on his local machine), the client works. This makes sense somewhat, as the OPC Expert client was able to connect, and the Analyzer is basically just being a client to the remote server and we are reading locally from it. The weird thing is this:

• With the firewall ON, whenever he calls ReadItem(), the call immediately returns with a value.
• With the firewall OFF, the call to ReadItem() returns much later, but still has the value

When looking at the traces (both are attached), it makes a little more sense. My theory is that in the trace with the firewall on, the call to Advise() (which I am guessing is made by the clients methodology of internal subscriptions) is immediately denied and it moves on to the actual call to IOPCSyncIO::Read() immediately. When the firewall if off, this doesn’t happen, so we have to wait until the internal OPC operation timeout happens (which is the cannot connect topic/DataAccessClient error) and then it tries to do the IOPCSyncIO::Read() and gets the value.

In both of these traces, we can see the call to Advise() returns with RPC Server Unavailable, but the read afterwards succeeds. Does this indicate something about the subscription callbacks not being able to make it back to the client machine?

I also had him try different security options as described here: in case it was still some wacky DCOM issue that is particular to the easyDaClient. His results are attached in one of the text files as well.

Do you have any input on what is going on here or something else we can try? Thanks in advance for the help.

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.076 seconds