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?

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?

Thanks!

Hi,

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.

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?

HERE IS THE STRANGE PART:

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: opclabs.com/forum/connections-reconnections-com-dcom/1244-co...achines-via-code-quickopc-dcom 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.