Dear Sir/Madam,
thank you for your interest in our products.

Ad 1. Yes, this is normal behavior. In "Classic" OPC, the server is only expected to send the values that have changed (even if it has collected the value anew and it has not changed). This, of course, is sub-optimal for some applications (trending). The new OPC (Unified Architecture) allows the client to specify a "trigger" (value, value/status, value/status/timestamp). Some OPC "Classic" servers can also send unchanged values - but that's server-specific.

You can, however, rely on the fact that if you don't receive values, that they have not indeed changed. There are checks on the connection presence, so e.g. if the connection to the server is lost, you would receive a notification with an error (and will not wait "forever", thinking that the value is still as it was before).

Ad 2. Yes, subscriptions are more efficient and should be used (in place of repeated reads) whenever possible for the purpose.

Ad 3. We internally split the requests into each server. And, the operations that have to do with different server will be performed in parallel by our component. Therefore it is recommended that you *do* "mix" multiple servers, if that's what your app needs to do.

Ad 4. OPC-DA Version 3.0 has a notion of server-side buffer, but few servers support it, and QuickOPC does not support it.

Ad 5. There is no such method, but what you are doing should be fine.

Best regards