Online Forums
Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.
Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.
Do not use the Contact page for technical issues.
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Reading, Writing, Subscriptions, Property Access
- Getting 'Read not completed' and 'Write not completed' errors
Getting 'Read not completed' and 'Write not completed' errors
I understand, but unfortunately I cannot offer real help. Since your application is the same as the relevant functionality on our part is also the same, I am inclined to think that the cause is elsewhere. If, for example, in the initial loading of the dependent assemblies and their compilation (JIT), as I suggested before - a different .NET Framework is in use by the newer versions, so it may behave differently.
Regards
Please Log in or Create an account to join the conversation.
Before I did the update to the new OPCLabs Version, when I was starting my application several clients were performing a multiple item subscriptions, the application was starting normally without any delay, now the same application sometimes started with a really Long delay, sometimes even more than 10 seconds. When I debug the application I can see that it is stuck in this SubscribeMultipleItem of one of the multiple clients, and not always is the same Client. I think it is an issue that is trying to perform the subscription but another Client is busy doing the same operation. I cannot understand why exactly the same application now is getting this delay. and before I do a performance test of the normal operation I want to understand what is happeing here. If you said that the underlying Operation is the same, then why the simple update of the OPCLabs is making that the application behave different when it is starting.
Please Log in or Create an account to join the conversation.
But there were no changes in underlying principles of the operation between 5.23 and the current version.
Please Log in or Create an account to join the conversation.
What happens if I start call at different Points the function SubscribeMultipleItems(), runs a synchronization process in the Background of the OPCLabs Library?
I can remember that in the old Version the event fired when a value from a opc changed were synchronized, and to avoid that I have to set the property OPCClientMeasurements.Isolated = true;
Please Log in or Create an account to join the conversation.
If it happens only the first time in each run, it can be due to .NET JIT (just-in-time compilation).
Regards
Please Log in or Create an account to join the conversation.
I have started running my first tests. And the first Thing I have been noticing that the function OPCClient.SubscribeMultipleItems(MeasurementsArguments); it is slower than the last library I was using (QuickOPC 5.23_1371.1), it means when starting the application it takes more than usual to show the user Interface, and when debugging it, it is stuck in this function. Do you know if something similar has been seen before?
Regards
Luis Garcia
Please Log in or Create an account to join the conversation.
in newer versions, Topic has been renamed to TopicParameters.
Best regards
Please Log in or Create an account to join the conversation.
EasyDAClient.SharedParameters.Topic.SlowdownWeight = 0.0f;
EasyDAClient.SharedParameters.Topic.SpeedupWeight = 0.0f;
var clientMapper = new DAClientMapper();
clientMapper.Client.InstanceParameters.UpdateRates.ReadAutomatic = Timeout.Infinite;
clientMapper.Client.InstanceParameters.UpdateRates.WriteAutomatic = Timeout.Infinite;
Please Log in or Create an account to join the conversation.
We do not know yet what causes the Write take so long. It is quite possible that it is the server-side taking so long. If that is the case, and it takes the server e.g. 6 seconds to complete the Write, then 5 seconds timeout on the client side is definitely too short, no matter how much we may dislike it.
List of QuickOPC versions is here: kb.opclabs.com/Versions . Under the column "Key Changes - What's New", there are links to pages that describe the major changes made in each version. There is no cumulative list that would go straight from 5.23 to the current version. Any concrete conversion problem you run into, report as a new thread on the forums, and I will advise how to change the code for the newest version. I still do not see what the issue is, what was the thing you do not consider a "minor change". Either way, if it a matter of single Write being clearly slow, you can take the newest version demo, use the demo app that is included, enter the server and item ID, and see how long it takes to make the write. No coding required. If it is also slow, then simply upgrading won't resolve anything.
The ReadAutomatic value has no significance if you are only doing Write-s. Still, I suggest to include the code as given in the link I have provided.
Best regards
Please Log in or Create an account to join the conversation.
Well, last time I try to did the update were not "minor changes" as you said, can you give me a resume of the differences between the 5.23 and the actual Version?
and actualy this Client is being used to write values not to read. Does the ReadAutomatic has effect when trying to write values?
Thanks in advance
Please Log in or Create an account to join the conversation.
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Reading, Writing, Subscriptions, Property Access
- Getting 'Read not completed' and 'Write not completed' errors