With regard to the security settings, there is absolutely no difference between ReadItem vs. ReadMultipleItems,

ReadItem simply constructs a call with a single item to ReadMultipleItems, and then "unpacks" the single result it receives.

Note that ReadMultipleItems does never throw (given that it is passed valid arguments); if there is an error, it is returned for each item separately, in the .Exception property of the DAVtqResult.

BTW, if you are doing things such as reading 700 items, you should definitely use ReadMultipleItems - the performance difference will be enormous.

Regards

For OPC & DCOM configuration, it is very important to know whether both computers are in the workgroup, or one in the domain and one in the workgroup. The security consequences and settings are completely different in the two settings. And, the configuration when one is in the workgroup and the other in the domain should be avoided at all costs. In my opinion, in general case, it cannot be set up to work with OPC, without compromising the security of the domain.

To the exception: You need to look into the InnerException and give us the details of it.

It is a common DCOM configuration problem to have such settings in which the OPC client can access the OPC server, but the OPC server cannot access the client. For full OPC communication, *both* directions must be correctly configured. You might be in this situations, based on the symptoms you have described.

We have made special provisions to allow QuickOPC work, with a degraded functionality, under such circumstances as well. Parts that will *not* work without the reverse-direction channel are asynchronous operations, and subscriptions (and a server shutdown request, which is not that important). Everything else should work. This may explain why with AllowAsychronousMethod = false, the ReadItem works. I do not see it as a problem per se that sync reads is used, because if you are using one thread and waiting for the results in a loop anyway, async reads only add complexity but no benefit. What may be worse is that you should not ideally used repeated reads at all, if you are reading still the same thing - for that, we have subscriptions (but I understand that they may not work for you - but that again usually boils down to the proper DCOM settings).

Regards

This has to do with very complicated area of COM/DCOM security, and any answer I give here cannot be complete. Instead, I'll just point out some things:

1) You do not say whether the two computers are in the same domain, or different domains, or one of them is in a domain and other in a workgroup, or whether the two computers are in a workgroup. Many other answers and facts rely on this.

2) The LocalSystem account has, by default, very limited privileges on the network (and it is highly recommended to keep it configured as such). It is therefore not suitable for remote COM/DCOM.

3) It is certainly possible to run OPC client and OPC server on different machines and with different accounts. It is, in fact, precisely how it is generally used in many industrial installations. This is not to say it is easy to configure, though. I do not know where you have taken the information about it being not possible. In addition, "same account" is not the same as "having same username/password", at least not in the domain environment (where "same" means "the same account in the domain" - two local accounts with the same username and password are still different one from the other and from the domain account with the same username and password). You might have confused it with the fact that in a workgroup environment, if one wants to refer to a user account and does not have it locally, then first a corresponding local account with the same username/password needs to be created - but even then, the client and server should be able to use different accounts.

4) Impersonation on the client side is not supported by QuickOPC (and I have never seen it being used by any OPC client). AFAIK, proper security settings is always done by running the client process under a specific account. The UserName and Password in the ServerDescriptor are ignored for COM/DCOM servers: They only have to do with OPC-XML.


In order to try to put it at least in a bit simplified way: The common approach that works is to use a domain, and run the client and the server under specifically created accounts (not LocalSystem); if needed, they can be different on both sides.


Best regards
Zbynek