W.,

I have tried to reproduce the problem (i.e. the fact that the timeout cannot be set), but have not succeeded. I have set the EasyDaClient.Timeouts.ReadItem to 15000, and I have artificially blocked the target OPC server so that it does not reply soon enough. The method call returned with the "Cannot connect topic (timeout)" exception after roughly 15 seconds, as expected.

Note that in multithreaded situation where multiple threads are connecting to the same item, AND the Isolated property is not set to True, the threads also share the error information that relates directly to that item (not just to particular method call; for example, errors or timeouts in AddItems are shared for all uses of that item, while errors in read/write methods calls are not). So, in some cases the timeout can occur sooner; e.g., following would be expected behavior:

1. At time 0.0, thread 1 calls ReadItem. The component is working on the request, and it takes long to fulfill it (most likely inside the target OPC Server)
2. At time 10.0, thread 2 calls ReadItem for the same item.
3. At time 15.0, thread 1 receives "Cannot connect topic (timeout)" exception.
4. At time 15.0 (!), thread 2 ALSO receives "Cannot connect topic (timeout)" exception. That is, 5 seconds after the method call was initiated, not full 15 seconds.

Best regards,
Zbynek Zahradnik

From: W.
Sent: Friday, January 14, 2011 8:58 PM
To: Zbynek Zahradnik
Subject: RE: Error Explanations - "Cannot connect topic (timeout). "

Hello Zbynek,

Thank you for the explanation. The version is 5.03.446.

The customer is not overly concerned with this error. They just want to understand it, make any applicable changes in the code and retry when it makes sense.

W.

W.,
.....

The fact that the timeout occurs too early looks like a bug. The EasyDaClient.Timeouts.ReadItem setting is supposed to be effective in this case.
I will look into it further here. Can you please obtain the product version and build number from the customer?

Is the fact that the timeout occurs too early the only problem they have with it? I.e. does it appear that the long time is somehow justified, and if they can set the timeout as needed, it would be what they need?

Explanatory note: This error does not originate in the OPC server. It comes from QuickOPC, meaning that operation such as AddItems on the OPCGroup takes quite long.

Best regards,
ZZ

From: W.
Sent: Thursday, January 13, 2011 10:47 PM
To: Zbynek Zahradnik
Subject: Error Explanations

Hello Zbynek,

.....I have some thoughts on this and would like your expert opinion. The customer has proposed a workaround ...... I will comment on that ... error and the workaround below the error

.....

---

The ReadItem call fails because it "Cannot connect topic (timeout)"

OpcLabs.EasyOpc.OpcException = {"OPC operation failure"}
Source = "EasyOpcDANet"
StackTrace = " at OpcLabs.EasyOpc.DataAccess.EasyDAClient.CheckComResult(Int32 hResult, IErrorInfo* pErrorInfo) at OpcLabs.EasyOpc.DataAccess.EasyDAClient.ReadItem(ServerDescriptor serverDescriptor, DAItemDescriptor itemDescriptor) at

InnerException
System.Runtime.InteropServices.COMException = {"Cannot connect topic (timeout). "}
Source = "OpcLabs.EasyOpc.DataAccess.EasyDAClient"
StackTrace = Nothing

This error is unusual in that it occurs "too early". The EasyDaClient.Timeouts.ReadItem setting is 15000, yet this exception is thrown after only 5000 ms. There doesn't seem to be any configuration option for adjusting this particular timeout value, so I assume that it's an internal OPCData.NET thing which is beyond the scope of our code.

Proposed workaround: when this exception occurs, retry the ReadItem call and hope that the error goes away.

---

I think this error may be happening because the connection to the OPC server is timing out. If so is there a parameter I can change that would effect this timeout? I do think even if he gets this error he must retry.


.....


Thanks in advance for you time.

W.