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