- Posts: 4
- Thank you received: 0
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
- Opc.UA.ServiceResult=0x80310000
Opc.UA.ServiceResult=0x80310000
- SIEMENS_ROC
- Topic Author
- Offline
- Senior Member
Sorry for my late reply and thanks for your help.
To simplify, I call the server that collects the local WinCC data via OPC-UA (using QuickOPC) and forwards it to another server "problemserver".
So the WinCC server (which is an external server that polls the "problemserver") polls the "problemserver" independently of the healthcheck.
The healthcheck is performed by the "problemserver" itself to check if its own interface is still active. Basically, the healthcheck and the WinCC request (external server) test the same thing.
Regarding your question: Yes, you understood that correctly.
Okay, then I will search and analyze the OPC-UA protocols on the server. If I do not find anything, I will check the communication with Wireshark.
I hope the communication is not encrypted.
Thanks for the links and kind regards
Please Log in or Create an account to join the conversation.
thanks for clarification. This changes my understanding of your system. I was under impression that the healthcheck you mentioned, and the WinCC logs, are independently monitoring the state of the same OPC UA server. However, now I think that the healtcheck service is based on the data from the QuickOPC-based application that connects to the server, and that WinCC is monitoring the healthcheck service, *is that correct*? If so, it is then understandable (and kind of redundant to know) that a problem between QuickOPC and the OPC UA server causes the healtcheck failure and consequently corresponding WinCC log entry; but it would not be an independent way of obtaining information the OPC UA server status, as I thought.
However, the likely cause is still the same (although now the conclusion is not backed up by such strong reasoning) - a server or comms problem. You will be well advised to try to collect some server-side logs too: The OPC UA server should ideally have some logs already available, or a possibility to turn them on for better diagnostics.
Wireshark would be the last resort - for really detailed analysis. Note that it only works well when the OPC UA communication is not encrypted - otherwise the only errors seen would be on the TCP-IP level, but not what is inside the OPC UA packets. Some more info if you end up going that way:
- kb.opclabs.com/Collecting_information_for_troubleshooting
- www.prosysopc.com/blog/opc-ua-wireshark/
Best regards
Please Log in or Create an account to join the conversation.
- SIEMENS_ROC
- Topic Author
- Offline
- Senior Member
- Posts: 4
- Thank you received: 0
Thank you for your reply and suggestions.
I like your tip with Wireshark, thank you.
The only problem is that now the connection is working again and the error has not occurred since. My task now is to analyze why this error occurred.
I think I have to mention that the WinCC server with this URL "http://<server name>/api/healthcheck/" is the server where the OPC UA application runs and collects the data from the local WinCC server via OPC UA.
This sounds a bit complicated. In short: The server with the application (with QuickOPC) is at the same time a WinCC server, which collects the local WinCC data via OPC UA and makes it available to another server via an API.
If the URL http://<server name>/api/healthcheck/ is called, a json file is generated which provides the OPC UA status.
The following code returns the state of the URL:
public HttpResponseMessage Get()
{
if (SyncController.StateIO == false || GlobalFields.RefreshComplete == false || GlobalFields.TransmitGSDV != "true")
{
GlobalFields.Logger_Healthcheck.Warning(HttpContext.Current.Request.ServerVariables["REMOTE_ADDR"] + ": GET Request Healthcheck --> (503 ServiceUnavailable)");
return Request.CreateResponse(HttpStatusCode.ServiceUnavailable, "Connection to OPC UA Alarms & Conditions Server not established");
}else
{
GlobalFields.Logger_Healthcheck.Information(HttpContext.Current.Request.ServerVariables["REMOTE_ADDR"] + ": GET Request Healthcheck --> (200 OK)");
return Request.CreateResponse(HttpStatusCode.OK, "Connection to OPC UA Alarms & Conditions Server OK");
}
}
The state that the connection to the server cannot be established is controlled by three values.
Therefore I assumed that it must be due to one of the three values and therefore somehow also with the OPC-UA connection.
But if I understand correctly you think that the self-written application (with QuickOPC) works fine and the problem is somewhere with the server.
I have already analyzed the server but found nothing, but I think I need to take a closer look at the server again.
Thanks and kind regards
Please Log in or Create an account to join the conversation.
To your question:
- The server should be able to handle multiple client session without such errors. If there is a limitation on number of sessions, the server can reject new sessions, but in such case that would be a different error code.
The most important error information here is "Opc.UA.ServiceResult=0x80310000: OPC UA service result - {BadNoCommunication}. Server not responding to keep alive requests. [...]". It usually indicates problems either on the server side, or in the communication infrastructure.
It would be possible to use Wireshark to capture the communication between the client and server, and then analyze it and "point the blame" to the proper side. However, since you already have OTHER indications that there is something wrong with the server at the same time - i.e. your healthcheck AND the WinCC logs indicating problems accessing the server, I really do not think there is any reason to think that the OPC UA client side (your app with QuickOPC) is doing anything wrong. Apparently, it does precisely what it is supposed to do - indicates that there are problems communicating with the server. But it cannot fix these problems ... they are elsewhere I believe.
Best regards
Please Log in or Create an account to join the conversation.
- SIEMENS_ROC
- Topic Author
- Offline
- Senior Member
- Posts: 4
- Thank you received: 0
Thanks for your answer.
Sorry that my description is so vague, I am still a beginner in programming and opc, but would like to work my way in.
Here is a more detailed description of the problem:
I am running several WinCC servers with my colleagues, where data is collected via OPC UA and forwarded to another server.
The code that collects the data via OPC UA is based on QuickOPC.
The communication worked fine, but a few weeks ago the message "topic Opc.UA.ServiceResult=0x80310000" appeared in the log file among other logged disconnection errors.
Here are other errormessages that appeared:
-First the following message appeared 2x in the logfile: "OPC UA Server not connected".
-Then in the log file 4x the message "[WRN] [] *** Failure Opc.UA.ServiceResult=0x80310000: OPC UA service result - {BadNoCommunication}. Server not responding to keep alive requests. [...]"
-Then the following message appears several times "[ERR] *** Failure: Cannot lock the OPC-UA client session because it is not available. The client method called (or event/callback invoked) was 'WriteMultiple'."
-Afterwards there is another 2x warning "[WRN] [] *** Failure OpcLabs.UAEngine=3201: OPC-UA client session is not available when connecting the client subscription. [...]"
-Before the message "OPC UA Server not connected" appears once again.
-Finally the message "OPC UA Server Connected" appears twice and it works again.
What I also noticed is that in one healthcheck log the following message is logged over and over again at the same time until the message "OPC UA Server Connected" appeared in the other logfile:
-GET Request Healthcheck --> (503 ServiceUnavailable)
In the logs of WinCC it is stated that the address "http://<Servername>/api/healthcheck/" was not reachable during that time
I hope this description is now a bit more accurate and understandable.
To your questions:
1. the error message is stored in the logfile. Where it originates exactly I can not say. I do not know enough about the code at the moment.
2. as I understand the code and according to the error messages, subscriptions are used.
3. the connection and disconnection is not problematic, but the disconnection with the following error messages is problematic, because the data of the WinCC servers are not forwarded anymore.
My questions:
-Could it be that several client sessions were open in parallel and because of that the error occurred?
-What can I do to fix these errors?
Please Log in or Create an account to join the conversation.
For start,
1. Where do you get this error? There is nothing like that in the code snippet provided.
2. Is your application using subscriptions, or just reads/writes?
3. What makes you think that connecting and disconnecting from the server is a problem?
Regards
Please Log in or Create an account to join the conversation.
- SIEMENS_ROC
- Topic Author
- Offline
- Senior Member
- Posts: 4
- Thank you received: 0
We monitor the OPC connection with the "EasyUAServerConditionChangedEventArgs" variable, like this:
private static void ServerConditionChanged(object sender, EasyUAServerConditionChangedEventArgs e)
{
if (e.Connected == true)
{
GlobalFields.Logger.Information("OPC UA Server connected");
}
else
{
GlobalFields.Logger.Error("OPC UA Server disconnected");
}
}
Please Log in or Create an account to join the conversation.
- Forum
- Discussions
- QuickOPC-UA in .NET
- Connections, Reconnections, Certificates
- Opc.UA.ServiceResult=0x80310000