I agree this is related to DCOM. Most likely, it is the reverse direction (setting up and performing callbacks from the OPC server to OPC client) that does not work. This reverse direction is needed for OPC async read/writes, and for subscriptions.

Earlier versions of QuickOPC (5.12 included) required the reverse direction be always operational. The newer versions are more forgiving, and degrade their functionality where possible - so if you are just using reads and writes, and the callbacks are not operational, QuickOPC will just fallback to synchronous calls, and work. I suppose that this is happening with QuickOPC 5.23. It might be OK unless you need subscriptions as well. To verify that the reverse call direction is causing the problem, try to establish a subscription with QuickOPC Version 5.23 - my bet is that it won't work.

For truly resolving the issue, try to:

1. Configure DCOM - pay special attention to settings for the reverse direction - i.e. mainly on the client machine - it should be possible for the server to get back to (access) the client.
2. Experiment with parameter settings, as in this topic: www.opclabs.com/forum/quickopc-net--9/1244-connecting-to-remote-machines-via-code

Best regards

Hello,
I do not fully understand your report.

Can you please answer:

1. Are you only using Version 5.10, or some other version as well?
2. Is there is a situation in which the read or write DOES work?
3. Are there are other things that work - for example, the BrowseXXXX methods? Or SubscribeXXXX? Or, do they return the same error? Or have you just not tried them - you only tested ReadXXXX and WriteXXXX?
4. Does it work well when the OPC server is local (if it can be tested)?
5. Have you tried some other OPC client, from the same computer, and what were the results?

Thank you