Ad 1) That's what you are currently doing in your other post here: Any EasyDAClient.ReadXXXX is suitable for that. EasyOPC may decide to subscribe to the tag as well, to improve performance with further periodic reads; this can be disabled, see
www.opclabs.com/forum/reading-writing-subscriptions-property...scriptions-made-with-opc-reads .
Ad 2) For this, you will use some of the EasyDAClient.SubscribeXXXX methods. Code examples are incldued with the product - just open of the example solutions and look for projects that have "subscribe" in their name, or projects like HMIScreen, or the "logging" projects.
Ad 3) This is not recommended and rarely there is a true reason for that. If you insist, you can force EasyOPC to disconnect immediately after each use, by setting the "hold periods" to zeros, e.g.:
easyDAclient = new EasyDAClient();
easyDAclient.InstanceParameters.HoldPeriods.TopicRead = 0;
easyDAclient.InstanceParameters.HoldPeriods.TopicWrite = 0;
..... and so on, with all periods that are in there
(if you have the component placed on the designer surface of Windows form, you can set the parameters right there, without any manual coding).
As to this quote:
It seems that after my program is halted or aborted the task is not immediately disconnected from the OPC server. My OPC server generates a large number of error messages indicating that i cannot deliver its notification. After some time the connection disappears.
It is necessary to distinguish the case when the client truly disconnects, and the case in which the case in which the client or the connection is abruptly terminated (such as terminating the process in the Task Manager or from the debugger).
Simply remaining connected for some time (in terms of OPC specification, having a reference to the OPCServer object, but nothing else) should not be a problem, that's what OPC cliently normally do and what keeps the "connection" up. It is a normal situation and the server should not hava problem with that. The client can then (immediately, or after some time) release the last reference to the OPCServer object, and and that moment the "connection" is really terminated.
I think that when you say that the server complains about the inability to deliver the notifications, you may be describing the second case: An unorderly termination of the client. In such case, it is possible that the server is not (at least not immediately) informed of the client "disappearance", and calls back to the client will return errors. This, however, is totally unpreventable from the client side: The behavior would be the same with *any* OPC client with an open connection to the server, terminated in such a way.
Best regards
