Also, are the ReadItem and WriteItem timeouts already significantly increased, as you have indicated in the original post? Thinking more about this, the timeout can occur even without the queue actually overflowing – it is enough if there is heavier load and the component is busy processing earlier results and callbacks – then it takes longer time before that particular result is pulled from queue, and timeout can occur.

<span style="font-family: "Arial","sans-serif"; color: #1f497d; font-size: 10pt; mso-fareast-font-family: 'Times New Roman'; mso-themecolor: dark2; mso-no-proof: yes">Zbynek Zahradnik

R.,
There may be no easy way of determining that the queue overflows in QuickOPC.NET. Since the queues are first-in-first-out and quite large, the first symptoms of them getting filled would be that the client application will start receiving values with more and more delay – unless the customer is seeing this, the queues are probably just fine. It is possible to increase the queue sizes by setting the corresponding properties.

Using multiple DAClient objects gives you separate queues, that’s right, except for two of them (called Input queue and Event queue: those are always shared by all instances – so it may be worth increasing their size by setting the properties; this has to be done at the very beginning, before any OPC operations are invoked).

Zbynek Zahradnik

From: R.
Sent: Thursday, February 03, 2011 2:56 PM
To: Zbynek Zahradnik
Subject: RE: Topic Timeouts

Zbynek,

I know the customer is using [...] TOP Server- I don’t know if he is using any other servers. I sent him a message this morning to check. I also had him try distributing the load thinking maybe he was processing data too quickly. His application has a lot of handshaking so that basically, every value update requires about 6 read/write transactions. I recommended he try two DAClient Objects, one for reading and one for writing. I think he decided to do 6 (one for each part of the transaction). The error also only appears to be happening on one service out of 8.

This is the latest information I have from him:

I change the services to distribute the work between each function with its own EasyOPC object. The same error occurred after about 7 hours of running this way on one of the 8 services running. The same message appeared about read failure / timeout / etc.

The full error stack trace is copied below:
1/31/2011 11:00:19 AM, USPLATCONV01/iccs1, OpcLabs.EasyOpc.OpcException: OPC operation failure ---> System.Runtime.InteropServices.COMException (0xC004C013): Read not completed. This error indicates that it could not be verified that the requested read operation was completed during the timeout period. It is possible that the read operation will actually succeed or fail, but later. Increase the timeout period if you want to obtain positive or negative indication of the operation outcome. Other reason for this error may be that under heavy loads, topic request or response queue is overflowing. Check the event log for queue overflow errors.
--- End of inner exception stack trace ---
at OpcLabs.EasyOpc.DataAccess.EasyDAClient.CheckComResult(Int32 hResult, IErrorInfo* pErrorInfo)
at OpcLabs.EasyOpc.DataAccess.EasyDAClient.ReadItem(ServerDescriptor serverDescriptor, DAItemDescriptor itemDescriptor)
at OpcLabs.EasyOpc.DataAccess.EasyDAClient.ReadItem(String machineName, String serverClass, String itemId)
at MDCSShippingSortationService.MDCSSortationControl.Read_Scanner_Data(String TagReceived, Int32& PseudoID, String& ScannerData)
1/31/2011 11:01:19 AM, USPLATCONV01/iccs1, OpcLabs.EasyOpc.OpcException: OPC operation failure ---> System.Runtime.InteropServices.COMException (0xC004C002): Cannot connect topic (timeout).
--- End of inner exception stack trace ---
at OpcLabs.EasyOpc.DataAccess.EasyDAClient.CheckComResult(Int32 hResult, IErrorInfo* pErrorInfo)
at OpcLabs.EasyOpc.DataAccess.EasyDAClient.WriteItemValue(ServerDescriptor serverDescriptor, DAItemDescriptor itemDescriptor, Object value)
at OpcLabs.EasyOpc.DataAccess.EasyDAClient.WriteItemValue(String machineName, String serverClass, String itemId, Object value)
at MDCSShippingSortationService.MDCSSortationControl.Write_DataAck_To_PLC(String TagReceived, Int32 SequenceNumberReceived)
1/31/2011 11:01:19 AM, USPLATCONV01/iccs1, Scan, Container = , Psuedo ID = 0, Sequence Number = 1541
1/31/2011 11:02:19 AM, USPLATCONV01/iccs1, OpcLabs.EasyOpc.OpcException: OPC operation failure ---> System.Runtime.InteropServices.COMException (0xC004C013): Read not completed. This error indicates that it could not be verified that the requested read operation was completed during the timeout period. It is possible that the read operation will actually succeed or fail, but later. Increase the timeout period if you want to obtain positive or negative indication of the operation outcome. Other reason for this error may be that under heavy loads, topic request or response queue is overflowing. Check the event log for queue overflow errors.
--- End of inner exception stack trace ---
at OpcLabs.EasyOpc.DataAccess.EasyDAClient.CheckComResult(Int32 hResult, IErrorInfo* pErrorInfo)
at OpcLabs.EasyOpc.DataAccess.EasyDAClient.ReadItem(ServerDescriptor serverDescriptor, DAItemDescriptor itemDescriptor)
at OpcLabs.EasyOpc.DataAccess.EasyDAClient.ReadItem(String machineName, String serverClass, String itemId)
at MDCSShippingSortationService.MDCSSortationControl.Read_Scanner_Data(String TagReceived, Int32& PseudoID, String& ScannerData)
1/31/2011 11:02:19 AM, USPLATCONV01/iccs1, Failed to Write to Tag CPA.CPA.Route14. Exiting Send_Route_And_RouteSeq_To_PLC without completing.
1/31/2011 11:02:19 AM, USPLATCONV01/iccs1, Assigned, Container = , Route = (NO CONTAINER RECORD)(NO LANE ASSIGNED), Lane Assigned = 0, Reason = No Lane Assigned for Destination
1/31/2011 11:03:19 AM, USPLATCONV01/iccs1, OpcLabs.EasyOpc.OpcException: OPC operation failure ---> System.Runtime.InteropServices.COMException (0xC004C002): Cannot connect topic (timeout).
--- End of inner exception stack trace ---

R.

From: Zbynek Zahradnik
Sent: Thursday, February 03, 2011 2:44 PM
To: R.
Subject: RE: Topic Timeouts

R.,

this is going to be somewhat difficult to figure out. In general, both errors are timeouts, in different parts of the process (the first one has to do with the actual Read operation, while the second one with operations such as AddItems on the group – which is needed before Read, unless we already have that item in some OPC group. Since there is basically one working thread per each target OPC server, an operation that takes quite long or completely “blocks” on the thread affects other operations with that OPC server, too.

If the cause of this is simply that the it takes the OPC server quite long to perform certain operations, then increasing the timeouts that you have listed should resolve the issue. If, however, there is some kind of bug in the OPC server or in the component that causes the worker thread to block indefinitely (or close to it, for our purposes…), increasing the timeouts will not help. This is where the hard parts starts – how to determine where we are blocked. We may need a debug build, and enable extra logging, to figure this out.

Is this some kind of well-known server that is on the market and is certified, or is it some more exotic OPC server? I would be inclined to suspect a server bug if it’s something exotic; but if it’s happening with a “known good” server, we should start thinking of a problem in the component.

As to the default values, I do not have a list of them ready. The easiest way to obtain it is to install QuickOPC-COM on a fresh computer, invoke the EasyOPC-DA Options utility, and all the default values are right there (the defaults for QuickOPC.NET are identical to those for QuickOPC-COM). The labels on the form are very close to the property identifiers, there should be no problem figuring it which is which. I have taken the screenshots with defaults for you (there are screenshots for two tabs; I am not sending the 3rd tab, as it only applies to QuickOPC-COM).

Default parameters (per-instance properties):


DefaultParameters.png


Global parameters (static properties; note that in QuickOPC.NET these values CAN be changed from the code):


GlobalParameters.png


Actually, it should also be possible to drop the component onto the designer surface in C# or VB.NET (as in Quick Start), and then look from Visual Studio at its properties.

Best regards,
Zbynek Zahradnik
The images in full size can be viewed in separate attachment: images.zip

From: R.
Sent: Tuesday, February 01, 2011 9:33 PM
To: Zbynek Zahradnik
Subject: Topic Timeouts

Hello Zbynek,

I have a customer who is receiving errors:

System.Runtime.InteropServices.COMException (0xC004C013): Read not complete

and

System.Runtime.InteropServices.COMException (0xC004C002): Cannot connect topic (timeout) errors in his app.

He says that restarting the application resolves the errors, but that they can loop for a long time- up to 20 minutes that he’s waited so far.

I believe we can resolve the first error by adjusting the ReadItem and WriteItem timeout periods. However, I am unclear as to what generates the Cannot connect topic error. Does he just need to unsubscribe and resubscribe?

Also, can you provide a list of what the default values for the parameters in the supporting classes are (such as EasyDaClientParameters and EasyDAClientTimeouts)- or is there one already and am I just missing it?

Thanks,
R.