Dear Sir,

thank you for the nice words. Do we have your permission to use (parts of) your text in our marketing?

If you need to test for more than 30 minutes continuously, we can issue an evaluation license to you with the restriction lifted (and instead, make it limited by an absolute day in future; usually we give 30 days ahead).

I will, of course, reply to your other post, separately.

Best regards
Zbynek Zahradnik

Dear Sir,
in your case, it looks like that you are using OPC UA, whereas the original post appeared to be about OPC DA (at least that's what the assumption is, as it was not posted under the QuickOPC-UA category).

Anyway, the principles I operation of any of our EasyXXClient objects are similar, and therefore the explanation given is still valid, except that details like parameter names are different. For example, with EasyUAClient, one can use the SessionParameters.HoldPeriod property and set it to quite a long value, in order to prevent frequest session disconnections.

The other way is to create a subscription to ANY item. The EasyXXClient object won't disconnect by itself as long as there is any subscription present.

I do not quite understand the remainder of your post. The idea of the EasyXXClient desing is such that your code should (normally) have no need to know about the server connections/disconnections. Semantically, they are irrelevant to what the intent of the code is. We have plans for future to give you an event that would inform you about the connections/disconnections, but currently it is not there. Yes, with EasyUAClient you can filter out the LogEntry events and figure out the connections/disconnections. But, there is always a danger that it would only be done for improper reasons.

I have yet to see a use case why anybody would really need to know about the connections/disconnection to/from the server, if the application code works on the basis of on-time operations (Reads/Writes etc.). If the application makes a subscription, it already DOES receive the connection/disconnection info, except that it is not per-server, but it comes as a status indication for each subscribed for item. For example, when you subscribe to multiple monitored items using EasyUAClient.SubscribeXXXX method, then it is guaranteed that for each of the items, you will receive an event notification with either success (attribute data), or failure (in a non-null Exception property value). If the connection is later lost, there will be notifications for all the monitored items, with the exception info again. If the connection is reestablished, the notifications will come with the valid data. Isn't that what's needed?

Frequent connecting and disconnecting to/from an OPC server is not efficient, that is correct. Besides timing measurement, it should not have any other effects, though, and if it creates a problem to the server, then it is a problem that the server vendor should fix.

But obviously you want to prevent frequent connections/disconnections for performance reasons, too. QuickOPC does not allow you to directly connect the connection/disconnections, because it whole concept is based on making the OPC interface appear connection-less to the developers.

In general terms, QuickOPC opens a connection whenever it is needed. It performs the operations it is asked to do, and then *holds* the connection open for some time, called a "hold period". After the hold period elapses, if the connection is no longer needed (for some other operation), it is closed. One-time operations (such as reads, writes) only need the connection for the duration of the method call, then it enters the "hold period", and can be closed if no longer needed. Subscriptions need the connection all the time until they are all unsubscribed, therefore when subscriptions are used, the connection is kept open - which is one of the possible approaches/workarounds if you try to control the connection.

Connection can be shared - multiple EasyXXClient objects share the same connections unless they have their .Isolated property set to true.

The hold period does no longer apply when the EasyDAClient object is disposed using IDisposable.Dispose, or by a finalizer). In this case (if the connection is not shared and thus needed elsewhere), it is closed immediately, because the "protocol" of IDisposable requires all resources associated with the object be released immediately (without it, we would release them anyway, after the hold period elapses, but users were complaining about a perceived "memory leak" if the resources were not released immediately).

My suggestion is that if you want to keep the connection open, you

1) you set a quite long hold period (in EasyDAClient.InstanceParameters.HoldPeriods) - see e.g. www.opclabs.com/files/onlinedocs/QuickOpc/Latest/Reference/QuickOpcNet/index.html .

and

2) use a global EasyDAClient object (not one per request) - so that there is no chance for it being finalized or disposed at the end of the request.

Best regards

From: OPC Labs Contact Form - M.
Sent: Tuesday, December 09, 2014 2:08 AM
To: Zbynek Zahradnik
Subject: OPC Labs Contact Form - QuickOPC question -keeping server open

[...]

Hello, your QuickOPC seems very nice, [...] trying to create a stable connection to some Matrikon and Rockwell OPC DCOM servers.

In my application a webserver keeps asking for a server and item. My problem is writing an WCF service that the webserver can talk to, this WCF service is an OPC client.

One problem I had was opening and closing an OPC connection seems to make the Matrikon OPC servers get "sick" and stop working. I am told I am only supposed to open and close a connection once, and not every time the webserver requests a tag/item.

I am looking through your sample projects, but it appears the client is created and destroyed each time, is this true? Perhaps I have not found it.

I am using the older 5.2.

Thank-you

M.