You are welcome - I am glad to hear it.

Best regards

Hello,

please download and test the new build, available from our download page (www.opclabs.com/products/quickopc/downloads ). It should identify itself (on the first page of the installation wizard) as 5.35.1115 or later.

The fix was aimed at the Exaopc server problem, which in the end was a bug on our side - and thank you for reporting it.

At the moment I am not quite sure about the order server (ExaopcDARDSTS1). The trace file showed some weird behavior too, but different. The GetItemID function of the server was always failing, although its inputs appeared to be correct. Let me know if there is any issue (and if so, how does browsing that server work from some other OPC clients).

Best regards

Mike,

thank you, your answers are very helpful. Please give us several days. We will give you then a new build of version 5.35 which should resolve the issue.

Best regards

Thank you very much.

Short answer: The server uses an uncommon behavior that however appears to be OPC compliant; we should be able to resolve it on the client side.

Elaborated answer: As can be seen from the captured trace, when browsing the problematic nodes, the server returns the first 100 requested elements, returns TRUE in the pbMoreElements argument, indicating that more elements exist, and returns an empty string in the pszContinuationPoint argument. Next call to the Browse method with this continuation point returns the same first 100 points again. This behavior puts the client into a server-induced infinite loop.

The reason why other OPC clients may work is probably because they either 1) use a different browsing interface (the one we use and that uses the Browse method is for OPC 3.0, but many OPC clients use OPC 2.0 which works differently), or 2) they use a browsing "chunk" size that is high enough to hold all nodes at once (or use no restriction whatsoever), or 3) detect an empty continuation point and interpret it is unability to support continuation points.

We should be able to use this knowledge to provide you with a solution, but before we do so, can you please answer the questions below? There are quite a few of them, and some require additional effort on your side; I understand you may not be able to willing to answer all of them, but can you please do as many as possible. This would allow us to provide a solution that would be as narrowly focused as necessary, and hopefully work at first attempt. Thank you.

1. Is there a chance to obtain a (trial version of) the OPC server? Alternatively, a VM image of some computer where it is installed?
2. I know it's Yokogawa ExaOPC; can you please state its version as well?
3. Which ProgID (or CLSID) you use to connect to the server?
4. Can you please provide one more picture of the browsing dialog, this time when the server node itself is selected, and the OPC server details appear in the lower pane of the dialog?
5. Please confirm that the problematic nodes contain more than 100 sub-nodes. (how many roughly?)
6. The OPC trace you have provided was good in the sense that it showed precisely the calls that show the problem, but we would like to also see what has lead to them. Would it be possible to make one more OPC Analyzer capture, this time enabling the trace even before you connect, and then proceed to browsing some good and some bad node?


Thank you once again, and best regards

From: M.
Sent: Sunday, March 06, 2016 10:50 PM
To: Z.
Subject: Re: OPC Analyzer for QuickOPC

Hi Z.,

I ran the OPC Analyzer as instructed and saved the trace. The tag browsing issue was recorded by the analyzer. I used the QuickOPC 5.35 test client and waited until the browser said Timeout browsing nodes.

Please let me know how to proceed from here.

Thanks a lot,
M.

Thank you.

I have sent the necessary instructions, and a download link, by email.

Best regards