Thank you for letting us know. I am glad to hear that.

Best regards

I will send you a download link to the email address you used to register with the forums.

Note that in order for the analysis to make sense, I need to correlate the events in the trace from OPC Analyzer with information from your application. Basically, I need you to also create a time-stamped log with each read/write you called on EasyDAClient, and the time it has taken. I will then compare the info from OPC Analyzer from the info from your app, and determine whether the problem is on the server or client side.

Best regards

Hello, thank you for details.

Yes, there is a single connection shared by all the EasyDAClient objects, provided that you keep the Isolated property at its default (false), which you have confirmed.

I did not know that you are using ReadItemValue (as opposed to ReadItem). In such case, it is to be expected that the advise about turning off the automatic subscriptions would cause the slowness or timeouts you described. These two things (ReadItemValue, and automatic subscriptions) are intertwined. Sorry for having mislead you.

Using WriteItemValue is correct.

I have looked at your code and have some suggestions. I will list them here for record, but in fact, none of it is likely to be causing the problem you originally reported. Here they are:

1.. If the logic allows, use ReadItem (or ReadMultipleItems) instead of ReadItemValue, and check yourself for the quality. At the same time, turn off the the automatic subscriptions (as you have done now).
2. If the logic allows, read or write multiple items at once, using ReadMultipleItems and WriteMultipleItemValue, instead of looping through the items and performing the operation one by one.

But doing these changes right now would probably just be a distraction from the problem you have. In order to address that problem, I suggest:

- please revert the change with turning off the automatic subscriptions
- have a look at this article: kb.opclabs.com/How_to_use_OPC_Analyzer . Will you be able and willing to capture the communication traces using that procedure?

Best regards

Hello,
thank you for the answers.

First. I suggest that you make the settings described here: www.opclabs.com/forum/reading-writing-subscriptions-property...scriptions-made-with-opc-reads , and retest. The first two are static parameters and need to be done just once, before you create any EasyDAClient. The last two need to be done on *each* new EasyDAClient instance.

Explanation: There is no direct indication that the automatic subscription mechanism is related to your issue, but disabling is is a precautionary measure. As its behaviur depends on actual timings, it behaves somewhat unpredictably, and I want to rule out that it contributes to the problem.

Second. The reason I have asked the question about Isolated, the subscriptions, the frequency of operations etc. is as follows: When there are two very different times to perform the same operation in QuickOPC, it is usually due to the fact that in one case, the connection to the server is already established (and the operation can be done quickly), while in the second case, the connection needs to be established first (and setting it up takes some time). We want to figure out whether something like this can be the cause. QuickOPC maintains the connection automatically, and (simplified) it keeps it open when there are any active subscription, OR some time after the last "single-shot" operation (such as read, write). When you repeatedly call reads or writes frequently, the connection should stay open; or, when you are subscribed. What you have described looks similar to possible re-opening of the connections (especially in the fact that it can be prevented by having a subscription around), but the default "hold periods" are around 5 seconds, so if you do anything within that time range (as you have said you were doing), the connection *should* stay open.

So, here is what I propose you/we should do:
1. Disable automatic subscriptions as described above, and retest.
2. Verify once again that your code is written in such a way that it invokes a read or write less than 5 seconds apart. If it is not doing that, either change the code (if it makes sense to do the operation faster), OR let me know and I will describe how to increase the "hold" period to any value if you wish.
3. If the above steps do not help, I suggest to use OPC Analyzer in order to figure out what OPC calls are taking place, and where the delay comes from. It is also possible that it is the *server* that takes so much time to perform the operation. Using the analyzer should tell us who is at fault.

Last but not least: Are you checking errors from the operations properly? And can you confirm you are getting no errors? Can you post the error handling piece here? It would not be surprising to see increase in times if there are some errors associated.

Best regards