Thank you.

I have checked the code history, and the additional protection against some server problems which I described is not present in version 5.31. Can you please download and try out the current version (5.35?). You do not have to rebuild your project or test it with it - it would be sufficient just to start the Demo application that comes with version 5.35, point it to the target server, and then try the item browsing from within the demo app.

Here is what the possibilities are:
1. A bug in the server, mitigated in version 5.35. Note that even if the additional "sanity checks" we have added help to prevent the infinite loop, the results returned from browsing may still be incorrect (incomplete).
2. A bug in the server, but not mitigated in version 5.35.
3. A bug in the client.

We may have to deploy the OPC Analyzer in the next step anyway, in order to figure out how the actual communication looks like.

Best regards

Hi.

It is actually unlikely that the issue is related to DCOM, because from the screenshot you sent, it is apparent that other parts of the address space can be browsed successfully, and DCOM is not concerned about the actual details of the OPC calls.

Unfortunately there are several ways to do the browsing: It major version of OPC-DA specification (1.0, 2.0, and 3.0) has made significant changes. And servers may implement multiple specs, and it then depends on the client which one it picks up. Consequently, if there is a problem in one of the implementations and not the other, and the clients pick a different one, the clients may behave differently for the same server - and it does not have to be a "fault" of the client.

QuickOPC prefers the highest version available (3.0 if it is there), but many clients out there have support up to 2.0 only. In the past, we have met a server that had a bug in the 3.0 interface which caused the client to loop indefinitely, and the symptoms were similar to what you have described. We have added a special treatment for that server (not Yokogawa), and some sanity check in attempt to prevent that from happening, although the check cannot be done with 100% reliability.

My first question is therefore, which precise version and build of QuickOPC are you using? I am trying to determine whether this additional check is present on not.

My second question is: Is the behavior deterministic? I.e. is it so that each named node either always works fine, or always shows the problem. Or does the problem "shift" randomly between nodes?

Thank you, and best regards