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.
OPC UA Write Exception
07 Jun 2016 14:07 #4093
by support
Replied by support on topic OPC UA Write Exception
Can you provide us with the Wireshark logs?
Please Log in or Create an account to join the conversation.
07 Jun 2016 13:00 #4091
by sebpinski
Replied by sebpinski on topic OPC UA Write Exception
Sorry for the slow response.
We've found after updating to the latest builds that the OPC DA DLLs are behaving very well and are now very stable and do not lock out. We are using the same license on the same server to use the OPC UA DLLs, so we are sure it is not a licensing issue.
As I've said before, its not an exact time frame from the point of starting our windows service, but after some time, any read will response with the provided error/stack trace and we find that this never recovers. On one occasion it seemed that even a service restart didn't cause this issue to recover, though this may just be that the issue occurred immediately after the restart of the windows service. So we cannot pass blame onto the TOP Server developers as of yet.
We've found after updating to the latest builds that the OPC DA DLLs are behaving very well and are now very stable and do not lock out. We are using the same license on the same server to use the OPC UA DLLs, so we are sure it is not a licensing issue.
As I've said before, its not an exact time frame from the point of starting our windows service, but after some time, any read will response with the provided error/stack trace and we find that this never recovers. On one occasion it seemed that even a service restart didn't cause this issue to recover, though this may just be that the issue occurred immediately after the restart of the windows service. So we cannot pass blame onto the TOP Server developers as of yet.
Please Log in or Create an account to join the conversation.
23 May 2016 13:10 #4070
by support
Replied by support on topic OPC UA Write Exception
There is a difference in what QuickOPC does when the type with Write is specified, vs. when it is not (the discussion here is for the Value attribute of the node; other attributes behave differently because their type is fixed).
When the type is not specified, QuickOPC first reads the type information from the server, and then attempts to convert the given value to the UA data type the server claims for (the Value attribute of) the node. Note that this is done once per session; QuickOPC then remembers the type and reuses it with further Writes to the same node, for efficiency.
When the type is specified, the above is not being performed, and QuickOPC just converts the given value to the specified type, and sends it to the server.
I am not sure how that relates to your issue, but it is good to know, as you have mentioned the difference in the behavior before/after the change.
If you have the content of the WriteRequest (and WriteResponse) messages, and you think the requests are correct (i.e. the client did what it was supposed to), why don't you contact the server vendor and ask them why the server does not behave as expected? Or do you understand something incorrectly?
Regards
When the type is not specified, QuickOPC first reads the type information from the server, and then attempts to convert the given value to the UA data type the server claims for (the Value attribute of) the node. Note that this is done once per session; QuickOPC then remembers the type and reuses it with further Writes to the same node, for efficiency.
When the type is specified, the above is not being performed, and QuickOPC just converts the given value to the specified type, and sends it to the server.
I am not sure how that relates to your issue, but it is good to know, as you have mentioned the difference in the behavior before/after the change.
If you have the content of the WriteRequest (and WriteResponse) messages, and you think the requests are correct (i.e. the client did what it was supposed to), why don't you contact the server vendor and ask them why the server does not behave as expected? Or do you understand something incorrectly?
Regards
Please Log in or Create an account to join the conversation.
23 May 2016 10:40 #4068
by sebpinski
Replied by sebpinski on topic OPC UA Write Exception
In fact, using the OPC UA write method has been completely fine for months too. Its only when we changed the code to allow for different hardware that required the ability to write booleans as well as words. We edited the code so that our write extension methods had an additional var type argument. Since this point we've ran into these issues where after roughly 30 minutes of usage we get the supplied error on any write.
The following user(s) said Thank You: Dan
Please Log in or Create an account to join the conversation.
23 May 2016 09:27 #4067
by sebpinski
Replied by sebpinski on topic OPC UA Write Exception
Regarding the licensing, we're using our site license which we believe is installed correctly as the service has been working fine using the DLLs for OPC DA for quite some time on the same machine.
We realised after posting that for some reason the WriteResponse message did not appear using the 'opcua' filter on wireshark, but it was present after all WriteRequest messages. The messages are exactly the same for both UAExpert and QuickOPC so I agree with your notion.
We realised after posting that for some reason the WriteResponse message did not appear using the 'opcua' filter on wireshark, but it was present after all WriteRequest messages. The messages are exactly the same for both UAExpert and QuickOPC so I agree with your notion.
Please Log in or Create an account to join the conversation.
22 May 2016 14:24 - 22 May 2016 14:24 #4065
by support
Replied by support on topic OPC UA Write Exception
For a WriteRequest message, there should be a WriteResponse message as well. Besides the "envelope" (such as creating the secure channel and opening a session), these are really the two messages that make up a Write operation.
And, if you get the exception with "bad" status code from a QuickOPC Write, we would really be interested to see the contents of these two messages, including the WriteResponse.
Ideally, you would collect the Wireshark logs with QuickOPC, and the same with UA Expert, and possibly even the one with QuickOPC that works well - i.e. from your development environment, compress/post them here or send to us, and we would compare them and analyze.
Some of the facts, and my intuition, however, tell me that this issue is likely to be purely on the server side of things.
Regards
And, if you get the exception with "bad" status code from a QuickOPC Write, we would really be interested to see the contents of these two messages, including the WriteResponse.
Ideally, you would collect the Wireshark logs with QuickOPC, and the same with UA Expert, and possibly even the one with QuickOPC that works well - i.e. from your development environment, compress/post them here or send to us, and we would compare them and analyze.
Some of the facts, and my intuition, however, tell me that this issue is likely to be purely on the server side of things.
Regards
Last edit: 22 May 2016 14:24 by support.
Please Log in or Create an account to join the conversation.
20 May 2016 19:14 #4064
by support
Replied by support on topic OPC UA Write Exception
I will reply to your other posts later.
To the call stack that you have posted: This time you have not posted the actual exception (text + possible inner exceptions) to which it belongs. Are you sure that it is the same as you have reported originally? (the one with the StatusCode 0x80000000)
If "something" happens regularly after 30 minutes, please check if you have the QuickOPC license installed - and whether the exception is not indicating a license issue. The trial license (which kicks into effect when no other license is found) times out after 30 minutes of process run.
To the call stack that you have posted: This time you have not posted the actual exception (text + possible inner exceptions) to which it belongs. Are you sure that it is the same as you have reported originally? (the one with the StatusCode 0x80000000)
If "something" happens regularly after 30 minutes, please check if you have the QuickOPC license installed - and whether the exception is not indicating a license issue. The trial license (which kicks into effect when no other license is found) times out after 30 minutes of process run.
Please Log in or Create an account to join the conversation.
20 May 2016 16:33 #4063
by sebpinski
Replied by sebpinski on topic OPC UA Write Exception
Further to this, it doesn't always seem to recover after a service restart. Even though, I can clearly view the data via an open UA Expert session.
Please Log in or Create an account to join the conversation.
20 May 2016 16:31 #4062
by sebpinski
Replied by sebpinski on topic OPC UA Write Exception
Thanks for all of your help so far. We appear to have stumbled on the true issue now. We were dwelling on the issue where some of the tags appear to remain in a Bad status code after being read. But it seems that even in this situation we can force a write, it takes effect, there are no real problems from then on.
After a few short soak test, what we are finding is that after around 30 minutes of operation, single writes are failing and they do not recover. This is still in keeping with the boolean write that we've been discussing, but there appears to be a time element involved. The stack traces are as follows (again sorry for the poor formatting):
" at OpcLabs.EasyOpc.UA.EasyUAClient.CheckSuccess(OperationResult operationResult)\r\n at OpcLabs.EasyOpc.UA.IEasyUAClientExtension.WriteValue(IEasyUAClient easyUAClient, UAWriteValueArguments writeValueArguments)\r\n at OpcService.OpcUaExtensions.WriteItem(KeyValuePair`2 refs, Boolean rethrow)"
" at OpcLabs.EasyOpc.UA.Toolkit.UAClientSession.WriteAttributes(UAWriteEntry[] writeEntryArray, Exception[]& exceptionArray, UAWriteOutcome[]& outcomeArray, List`1[]& warningsArray)\r\n at OpcLabs.EasyOpc.UA.Engine.EasyUAEngine.InternalWriteList(UASmartSession smartSession, List`1 writeList, UAWriteResult[] writeResultArray)\r\n at OpcLabs.EasyOpc.UA.Engine.EasyUAEngine.WriteList(EasyUASession session, List`1 writeList, UAWriteResult[] writeResultArray)\r\n at OpcLabs.EasyOpc.UA.Engine.EasyUAEngine.Write(ICollection`1 writeListDictionary, UAWriteResult[] writeResultArray)\r\n at OpcLabs.EasyOpc.UA.Engine.EasyUAEngine.WriteAttributes(UAWriteArguments[] writeArgumentsArray, EasyUAAdaptableParameters easyUAAdaptableParameters)\r\n at OpcLabs.EasyOpc.UA.EasyUAClient.DisposeGuard[TResult](Func`1 func)\r\n at OpcLabs.EasyOpc.UA.EasyUAClient.DisposeGuardNotNull[TResult](Func`1 func)\r\n at OpcLabs.EasyOpc.UA.EasyUAClient.WriteMultiple(UAWriteArguments[] writeArgumentsArray)\r\n at OpcLabs.EasyOpc.UA.IEasyUAClientExtension.WriteMultipleValues(IEasyUAClient easyUAClient, UAWriteValueArguments[] writeValueArgumentsArray)\r\n at OpcLabs.EasyOpc.UA.IEasyUAClientExtension.WriteValue(IEasyUAClient easyUAClient, UAWriteValueArguments writeValueArguments)\r\n at OpcService.OpcUaExtensions.WriteItem(KeyValuePair`2 refs, Boolean rethrow)\r\n at OpcService.OpcExtensions.ProcessList(Queue`1 actions)\r\n at OpcService.Jobs.RtuHandshake.DoHandshake(Int32 rtuId, DateTimeOffset now)\r\n at OpcService.Jobs.RtuHandshake.<>c__DisplayClass1_0.<Process>b__0(Int32 rtu)\r\n at System.Threading.Tasks.Parallel.<>c__DisplayClass17_0`1.<ForWorker>b__1()\r\n at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask)\r\n at System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object )\r\n at System.Threading.Tasks.Task.Execute()\r\n at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)\r\n at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)\r\n at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot)\r\n at System.Threading.Tasks.Task.ExecuteEntry(Boolean bPreventDoubleExecution)\r\n at System.Threading.ThreadPoolWorkQueue.Dispatch()"
After roughly 30 minutes of operation with the same EasyUAClient any write returns with this error and continues to do so. Any ideas why this is?
After a few short soak test, what we are finding is that after around 30 minutes of operation, single writes are failing and they do not recover. This is still in keeping with the boolean write that we've been discussing, but there appears to be a time element involved. The stack traces are as follows (again sorry for the poor formatting):
" at OpcLabs.EasyOpc.UA.EasyUAClient.CheckSuccess(OperationResult operationResult)\r\n at OpcLabs.EasyOpc.UA.IEasyUAClientExtension.WriteValue(IEasyUAClient easyUAClient, UAWriteValueArguments writeValueArguments)\r\n at OpcService.OpcUaExtensions.WriteItem(KeyValuePair`2 refs, Boolean rethrow)"
" at OpcLabs.EasyOpc.UA.Toolkit.UAClientSession.WriteAttributes(UAWriteEntry[] writeEntryArray, Exception[]& exceptionArray, UAWriteOutcome[]& outcomeArray, List`1[]& warningsArray)\r\n at OpcLabs.EasyOpc.UA.Engine.EasyUAEngine.InternalWriteList(UASmartSession smartSession, List`1 writeList, UAWriteResult[] writeResultArray)\r\n at OpcLabs.EasyOpc.UA.Engine.EasyUAEngine.WriteList(EasyUASession session, List`1 writeList, UAWriteResult[] writeResultArray)\r\n at OpcLabs.EasyOpc.UA.Engine.EasyUAEngine.Write(ICollection`1 writeListDictionary, UAWriteResult[] writeResultArray)\r\n at OpcLabs.EasyOpc.UA.Engine.EasyUAEngine.WriteAttributes(UAWriteArguments[] writeArgumentsArray, EasyUAAdaptableParameters easyUAAdaptableParameters)\r\n at OpcLabs.EasyOpc.UA.EasyUAClient.DisposeGuard[TResult](Func`1 func)\r\n at OpcLabs.EasyOpc.UA.EasyUAClient.DisposeGuardNotNull[TResult](Func`1 func)\r\n at OpcLabs.EasyOpc.UA.EasyUAClient.WriteMultiple(UAWriteArguments[] writeArgumentsArray)\r\n at OpcLabs.EasyOpc.UA.IEasyUAClientExtension.WriteMultipleValues(IEasyUAClient easyUAClient, UAWriteValueArguments[] writeValueArgumentsArray)\r\n at OpcLabs.EasyOpc.UA.IEasyUAClientExtension.WriteValue(IEasyUAClient easyUAClient, UAWriteValueArguments writeValueArguments)\r\n at OpcService.OpcUaExtensions.WriteItem(KeyValuePair`2 refs, Boolean rethrow)\r\n at OpcService.OpcExtensions.ProcessList(Queue`1 actions)\r\n at OpcService.Jobs.RtuHandshake.DoHandshake(Int32 rtuId, DateTimeOffset now)\r\n at OpcService.Jobs.RtuHandshake.<>c__DisplayClass1_0.<Process>b__0(Int32 rtu)\r\n at System.Threading.Tasks.Parallel.<>c__DisplayClass17_0`1.<ForWorker>b__1()\r\n at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask)\r\n at System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object )\r\n at System.Threading.Tasks.Task.Execute()\r\n at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)\r\n at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)\r\n at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot)\r\n at System.Threading.Tasks.Task.ExecuteEntry(Boolean bPreventDoubleExecution)\r\n at System.Threading.ThreadPoolWorkQueue.Dispatch()"
After roughly 30 minutes of operation with the same EasyUAClient any write returns with this error and continues to do so. Any ideas why this is?
Please Log in or Create an account to join the conversation.
20 May 2016 13:55 #4061
by sebpinski
Replied by sebpinski on topic OPC UA Write Exception
Thanks for the response, so our setup and the way we're communicating with the OPC server appears to be correct.
So finally, you may be able to help with the OPC protocol itself then. I find that there is very little documentation regarding this.
The setup is as follows:
- Beckhoff RTU with OPC UA Server on remote static IP address
- TOP Server V5 with OPC UA driver, tags pointing at Beckoff tags, exposing own OPC UA endpoint
- Windows service writing to TOP Server over OPC UA
The system has been setup in this way as all RTUs can be viewed on a single quick client. Some of the RTUs have 3G modems and therefore we'd prefer to have a "bad" status code rather than an unreachable IP.
In any case, I've just noticed now that the boolean write from the TOP Server Quick Client to the Beckhoff RTU also caused the status code to show 'Bad' immediately after a write. I've done a wireshark trace for OPCUA.Boolean writes and only appear to capture a single "WriteRequest" packet. Should there be any additional packets?
So finally, you may be able to help with the OPC protocol itself then. I find that there is very little documentation regarding this.
The setup is as follows:
- Beckhoff RTU with OPC UA Server on remote static IP address
- TOP Server V5 with OPC UA driver, tags pointing at Beckoff tags, exposing own OPC UA endpoint
- Windows service writing to TOP Server over OPC UA
The system has been setup in this way as all RTUs can be viewed on a single quick client. Some of the RTUs have 3G modems and therefore we'd prefer to have a "bad" status code rather than an unreachable IP.
In any case, I've just noticed now that the boolean write from the TOP Server Quick Client to the Beckhoff RTU also caused the status code to show 'Bad' immediately after a write. I've done a wireshark trace for OPCUA.Boolean writes and only appear to capture a single "WriteRequest" packet. Should there be any additional packets?
Please Log in or Create an account to join the conversation.
Moderators: support
Time to create page: 0.064 seconds