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-UA in .NET
- Connections, Reconnections, Certificates
- Issues with OpcLabs.QuickOpc on .Net Framework project but not on .Net Core
Issues with OpcLabs.QuickOpc on .Net Framework project but not on .Net Core
11 Jan 2023 14:24 #11440
by support
Replied by support on topic Issues with OpcLabs.QuickOpc on .Net Framework project but not on .Net Core
Hello.
If the settings reflect what you want, then they fine in the sense nothing is redundant.
I would be careful with setting TopicRetrialDelay to 0. I suggest to make it at least several seconds. With zero (or very small values), you can introduce a fairly "tight" loop which would unnecessary consume resources. "Topic failures" are errors such as when the item does not exist in the address space. In most cases, such error is *never* resolved, because the server 's address space does not change. So fast retrials are meaningless. In some case, the server's configuration/address space can be updated, and in such case an item that had not existed before may come to existence - so that's why the retrials exist, to pick up the item when it eventually appears (mostly with subscriptions). But it is not something that happens frequently (if at all) on any OPC server I have seen so far; thus, topic retrials do not have to be fast.
Regards
If the settings reflect what you want, then they fine in the sense nothing is redundant.
I would be careful with setting TopicRetrialDelay to 0. I suggest to make it at least several seconds. With zero (or very small values), you can introduce a fairly "tight" loop which would unnecessary consume resources. "Topic failures" are errors such as when the item does not exist in the address space. In most cases, such error is *never* resolved, because the server 's address space does not change. So fast retrials are meaningless. In some case, the server's configuration/address space can be updated, and in such case an item that had not existed before may come to existence - so that's why the retrials exist, to pick up the item when it eventually appears (mostly with subscriptions). But it is not something that happens frequently (if at all) on any OPC server I have seen so far; thus, topic retrials do not have to be fast.
Regards
Please Log in or Create an account to join the conversation.
10 Jan 2023 20:02 #11434
by aris
Replied by aris on topic Issues with OpcLabs.QuickOpc on .Net Framework project but not on .Net Core
I think it actually did work. I must have forgotten to recompile the code.
Here is how I do it. Is there anything, besides timeouts settings, that are redundant in my configuration?
Here is how I do it. Is there anything, besides timeouts settings, that are redundant in my configuration?
EasyDAClient.SharedParameters.TopicParameters.TopicRetrialDelay = 0;
_opcClient = new EasyDAClient();
_opcClient.InstanceParameters.EnableNativeClient = false;
_opcClient.InstanceParameters.EnableNetApiClient = true;
_opcClient.InstanceParameters.Mode.AllowAsynchronousMethod = false;
_opcClient.InstanceParameters.Mode.DesiredMethod = OpcLabs.EasyOpc.DataAccess.Engine.DAReadWriteMethod.Synchronous;
_opcClient.InstanceParameters.Timeouts.BrowseAccessPaths = int.MaxValue;
_opcClient.InstanceParameters.Timeouts.BrowseNodes = int.MaxValue;
_opcClient.InstanceParameters.Timeouts.BrowseProperties = int.MaxValue;
_opcClient.InstanceParameters.Timeouts.BrowseServers = int.MaxValue;
_opcClient.InstanceParameters.Timeouts.GetProperty = int.MaxValue;
_opcClient.InstanceParameters.Timeouts.ReadItem = int.MaxValue;
_opcClient.InstanceParameters.Timeouts.WriteItem = int.MaxValue;
Please Log in or Create an account to join the conversation.
10 Jan 2023 19:45 #11433
by support
Replied by support on topic Issues with OpcLabs.QuickOpc on .Net Framework project but not on .Net Core
If it did not change the behavior, you have not done it properly.
The NetApi implementation, when truly used, does not throw that exception, ever.
Please post here the pieces of code that you use to create, configure, and use the EasyDAClient object.
Regards
The NetApi implementation, when truly used, does not throw that exception, ever.
Please post here the pieces of code that you use to create, configure, and use the EasyDAClient object.
Regards
Please Log in or Create an account to join the conversation.
10 Jan 2023 18:14 #11432
by aris
Replied by aris on topic Issues with OpcLabs.QuickOpc on .Net Framework project but not on .Net Core
So, what can I do further to investigate the issue?
Please Log in or Create an account to join the conversation.
10 Jan 2023 17:11 #11431
by aris
Replied by aris on topic Issues with OpcLabs.QuickOpc on .Net Framework project but not on .Net Core
It didn't help
Please Log in or Create an account to join the conversation.
10 Jan 2023 16:54 #11429
by support
Replied by support on topic Issues with OpcLabs.QuickOpc on .Net Framework project but not on .Net Core
Hello.
At the lower levels of QuickOPC, there are two different OPC Data Access client implementations. Please read opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...ultiple%20Implementations.html .
.NET Framework 4.7.2 will use the NativeClient by default, .NET 6 will use the NetApiClient (it is the only choice there). So the difference likely comes from the fact that the issue only exists in the NativeClient implementation.
Therefore the workaround I woudl like to suggest is to switch to NetApiClient in .NET Framework 4.7.2 as well. This can be done by setting EnableNativeClient to 'false'.
This will probably help. Then of course there is the *real* question and that is why the "native" client is showing the problem. If you want to dig deeper into it (which won't be necessary if the workaround helps), let me know.
[referred from opclabs.com/forum/reading-writing-subscriptions-property-acc...eshoot-timeout-exception#11428 ]
At the lower levels of QuickOPC, there are two different OPC Data Access client implementations. Please read opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...ultiple%20Implementations.html .
.NET Framework 4.7.2 will use the NativeClient by default, .NET 6 will use the NetApiClient (it is the only choice there). So the difference likely comes from the fact that the issue only exists in the NativeClient implementation.
Therefore the workaround I woudl like to suggest is to switch to NetApiClient in .NET Framework 4.7.2 as well. This can be done by setting EnableNativeClient to 'false'.
This will probably help. Then of course there is the *real* question and that is why the "native" client is showing the problem. If you want to dig deeper into it (which won't be necessary if the workaround helps), let me know.
[referred from opclabs.com/forum/reading-writing-subscriptions-property-acc...eshoot-timeout-exception#11428 ]
Please Log in or Create an account to join the conversation.
09 Jan 2023 23:04 - 09 Jan 2023 23:47 #11425
by aris
I use VisualStudio 2022.
I use OpcLabs.QuickOpc from OpcLabs nuget www.opclabs.com/products/quickopc?nuget
When I install this nugget on .Net Framework 4.7.2 console project and use it I usually get:
OpcLabs.EasyOpc.OperationModel.OpcException: An OPC operation failure with error ID 'RawEasyDAClient.HResult=0xC004C010' occurred, originating from '' and with depth of 1. The inner exception contains details about the problem. ---> System.TimeoutException: Write not completed. This error indicates that it could not be verified that the requested write operation was completed during the timeout period. It is possible that the write operation will actually succeed or fail, but later. Increase the timeout period if you want to obtain positive or negative indication of the operation outcome. Other reason for this error may be that under heavy loads, topic request or response queue is overflowing. Check the event log for queue overflow errors (if event logging is supported by the product and enabled).
+ The client method called (or event/callback invoked) was 'WriteMultipleItemValues[1]'.
--- End of inner exception stack trace ---
at OpcLabs.EasyOpc.Internal.EasyUtilities.CheckSuccess(OperationResult operationResult)
at OpcLabs.EasyOpc.DataAccess.IEasyDAClientExtension.WriteItemValue(IEasyDAClient client, DAItemValueArguments itemValueArguments)
and/or I don't get notifications from subscriptions.
But, when I install and run from .Net Core 6 console project, I never get such issues. What can be the problem? It seems that the library does support .Net Framework.
I use OpcLabs.QuickOpc from OpcLabs nuget www.opclabs.com/products/quickopc?nuget
When I install this nugget on .Net Framework 4.7.2 console project and use it I usually get:
OpcLabs.EasyOpc.OperationModel.OpcException: An OPC operation failure with error ID 'RawEasyDAClient.HResult=0xC004C010' occurred, originating from '' and with depth of 1. The inner exception contains details about the problem. ---> System.TimeoutException: Write not completed. This error indicates that it could not be verified that the requested write operation was completed during the timeout period. It is possible that the write operation will actually succeed or fail, but later. Increase the timeout period if you want to obtain positive or negative indication of the operation outcome. Other reason for this error may be that under heavy loads, topic request or response queue is overflowing. Check the event log for queue overflow errors (if event logging is supported by the product and enabled).
+ The client method called (or event/callback invoked) was 'WriteMultipleItemValues[1]'.
--- End of inner exception stack trace ---
at OpcLabs.EasyOpc.Internal.EasyUtilities.CheckSuccess(OperationResult operationResult)
at OpcLabs.EasyOpc.DataAccess.IEasyDAClientExtension.WriteItemValue(IEasyDAClient client, DAItemValueArguments itemValueArguments)
and/or I don't get notifications from subscriptions.
But, when I install and run from .Net Core 6 console project, I never get such issues. What can be the problem? It seems that the library does support .Net Framework.
Last edit: 09 Jan 2023 23:47 by aris.
Please Log in or Create an account to join the conversation.
Moderators: support
- Forum
- Discussions
- QuickOPC-UA in .NET
- Connections, Reconnections, Certificates
- Issues with OpcLabs.QuickOpc on .Net Framework project but not on .Net Core
Time to create page: 0.105 seconds