- Posts: 16
- Thank you received: 1
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
- Reading, Writing, Subscriptions
- The OPC-UA subscription publishing has stopped.
The OPC-UA subscription publishing has stopped.
- Alex-Derksen
- Topic Author
- Offline
- Elite Member
-
Less
More
17 Aug 2015 11:45 #3487
by Alex-Derksen
Replied by Alex-Derksen on topic The OPC-UA subscription publishing has stopped.
Dear Zbynek,
Thank you for the quick reaction.
In the last column in only form #3484 two values where wrong swapped by me. In the software I use:
EasyUAClient.AdaptableParameters.Subscription.LifetimeCount = 12;
EasyUAClient.AdaptableParameters.Subscription.KeepAliveCount = 4;
AND NOT:
EasyUAClient.AdaptableParameters.Subscription.LifetimeCount = 4;
EasyUAClient.AdaptableParameters.Subscription.KeepAliveCount = 12;
Sorry for the misinformation (I know that the LifetimeCount must be 3 times higher than the KeepAliveCount).
In the afternoon I will test the forcing the client to violate the OPC spec, by not monitoring what it should.
uaClient.Isolated = true;
uaClient.IsolatedParameters.Session.StatusSubscriptionSamplingInterval = Timeout.Infinite;
After this test I will sent your information and the result to Bosch Rexroth for more testing in this week.
I will inform you of the outcome.
Yours sincerely,
Alex Derksen.
Thank you for the quick reaction.
In the last column in only form #3484 two values where wrong swapped by me. In the software I use:
EasyUAClient.AdaptableParameters.Subscription.LifetimeCount = 12;
EasyUAClient.AdaptableParameters.Subscription.KeepAliveCount = 4;
AND NOT:
EasyUAClient.AdaptableParameters.Subscription.LifetimeCount = 4;
EasyUAClient.AdaptableParameters.Subscription.KeepAliveCount = 12;
Sorry for the misinformation (I know that the LifetimeCount must be 3 times higher than the KeepAliveCount).
In the afternoon I will test the forcing the client to violate the OPC spec, by not monitoring what it should.
uaClient.Isolated = true;
uaClient.IsolatedParameters.Session.StatusSubscriptionSamplingInterval = Timeout.Infinite;
After this test I will sent your information and the result to Bosch Rexroth for more testing in this week.
I will inform you of the outcome.
Yours sincerely,
Alex Derksen.
Please Log in or Create an account to join the conversation.
17 Aug 2015 10:17 - 17 Aug 2015 10:19 #3486
by support
Replied by support on topic The OPC-UA subscription publishing has stopped.
There is nothing really new in this response; it does not address the fact that the server violates the OPC UA specification by returning an incorrect combination of and RevisedMaxKeepAliveCount (4) and RevisedLifetimeCount (4). Here is the relevant quotation from the OPC UA Specification (Part 4: Services, Release 1.02), 5.13.2 CreateSubscription, Table 83:
"4" is not at least three-times as high as "4", therefore it is a violation of the specification. There is a good reason why the specification requires that the lifetime count is at least 3-times as high as keep-alive count: The lifetime period needs to take into account the actual processing of the Publish calls (which has a maximum of the keep-alive interval), plus the possible transport delays (two of them: one for the request, one for response). When the lifetime count is equal to keep-alive count, it is quite likely that the server will detect a "loss" of client communication, while in fact there is no such loss at all.
The proper solution is to fix the OPC server. You may try some workarounds on the client side, but it should be understood that this is just an extra work required from parties (you, and us) that are not fault, in this case.
To your question to the purpose of the subscription with 7500 milliseconds publishing interval: It is an "internal" connection that QuickOPC makes, in order to monitor the status of the server. QuickOPC makes it for each connection, and is not related to the subscriptions you make
explicitly. The existence of this subscription is prescribed by "UA Client Test Cases" document by OPC Foundation,
opcfoundation.org/developer-tools/certification-specifications/ua-client-test-cases/ , version 1.2.334.200, e.g. Behavior Testing -> Shutdown. It requires the client to handle the shutdown indication from the server - which can be obtained by monitoring the server's
Server_ServerStatus_State variable.
When there is a problem with this internal (status) subscription, it has an influence on everything else: The client disconnects, and (if requested) attempts to reconnect after a configurable period.
If the server responds with an incorrect revised lifetime count only for this subscription (possibly because it has relatively long publishing interval), you can try to change its frequency by modifying the StatusSubscriptionSamplingInterval property in EasyUAClient session parameters.
It is in milliseconds. The sampling interval defaults to 15000 milliseconds (the publishing interval is a half of it), and you can either make it faster (if the server has problem with slow subscriptions), or you can disable the status subscription altogether by setting it to
Timeout.Infinite (-1) - which, of course, would mean that you would be improperly forcing the client to violate the OPC spec, by not monitoring what it should.
Example:
The other part of your last post mentions the settings you have experimented with, specifically:
Normally, and if the server works OK, you should have no need to modify them, and I recommend against doing it in this case, too.
What's more important, however, is that you have made the change incorrectly - reversed. It is the LifetimeCount that must be 3 times higher than the KeepAliveCount (!).
Best regards,
Zbynek Zahradnik
revisedLifetimeCount
Counter
The lifetime of the Subscription shall be a minimum of three times the keep-alive interval negotiated by the Server.
"4" is not at least three-times as high as "4", therefore it is a violation of the specification. There is a good reason why the specification requires that the lifetime count is at least 3-times as high as keep-alive count: The lifetime period needs to take into account the actual processing of the Publish calls (which has a maximum of the keep-alive interval), plus the possible transport delays (two of them: one for the request, one for response). When the lifetime count is equal to keep-alive count, it is quite likely that the server will detect a "loss" of client communication, while in fact there is no such loss at all.
The proper solution is to fix the OPC server. You may try some workarounds on the client side, but it should be understood that this is just an extra work required from parties (you, and us) that are not fault, in this case.
To your question to the purpose of the subscription with 7500 milliseconds publishing interval: It is an "internal" connection that QuickOPC makes, in order to monitor the status of the server. QuickOPC makes it for each connection, and is not related to the subscriptions you make
explicitly. The existence of this subscription is prescribed by "UA Client Test Cases" document by OPC Foundation,
opcfoundation.org/developer-tools/certification-specifications/ua-client-test-cases/ , version 1.2.334.200, e.g. Behavior Testing -> Shutdown. It requires the client to handle the shutdown indication from the server - which can be obtained by monitoring the server's
Server_ServerStatus_State variable.
When there is a problem with this internal (status) subscription, it has an influence on everything else: The client disconnects, and (if requested) attempts to reconnect after a configurable period.
If the server responds with an incorrect revised lifetime count only for this subscription (possibly because it has relatively long publishing interval), you can try to change its frequency by modifying the StatusSubscriptionSamplingInterval property in EasyUAClient session parameters.
It is in milliseconds. The sampling interval defaults to 15000 milliseconds (the publishing interval is a half of it), and you can either make it faster (if the server has problem with slow subscriptions), or you can disable the status subscription altogether by setting it to
Timeout.Infinite (-1) - which, of course, would mean that you would be improperly forcing the client to violate the OPC spec, by not monitoring what it should.
Example:
client.Isolated = true;
client.IsolatedParameters.Session.StatusSubscriptionSamplingInterval = Timeout.Infinite;The other part of your last post mentions the settings you have experimented with, specifically:
It should be first said that these settings (Subscription.KeepAliveCount and Subscription.LifetimeCount) are just starting points, a "wish" from your app. The EasyUAClient runs these settings through a complicated set of conditions and applies various limiting factors to them, which may result in different values being sent to the server. These modifications are needed because a) OPC UA Specification requirements, and what implied by them, b) known limitations in the client stack we use, and some commonly used server stacks, c) experience with the best settings.• PublishingInterval = 250 m seconds (this per call back tag/object).
• EasyUAClient.AdaptableParameters.Subscription.KeepAliveCount = 12;
• EasyUAClient.AdaptableParameters.Subscription.LifetimeCount = 4;
Normally, and if the server works OK, you should have no need to modify them, and I recommend against doing it in this case, too.
What's more important, however, is that you have made the change incorrectly - reversed. It is the LifetimeCount that must be 3 times higher than the KeepAliveCount (!).
Best regards,
Zbynek Zahradnik
Last edit: 17 Aug 2015 10:19 by support. Reason: typo corr.
Please Log in or Create an account to join the conversation.
- Alex-Derksen
- Topic Author
- Offline
- Elite Member
-
Less
More
- Posts: 16
- Thank you received: 1
13 Aug 2015 16:06 #3484
by Alex-Derksen
Replied by Alex-Derksen on topic The OPC-UA subscription publishing has stopped.
Response about the subscription has stopped form Rexroth.
In the logging file that is attached, we see a subscription with Subscription.Create; publishingInterval: 7500. The applications don’t make a subscription with an interval from 7500 mseconds. Can you tell how this subscription is making? In the applications, we make subscriptions with an interval from 250 m Seconds.
Rexroth has asked to set the next condition:
Line 121 - 127:
Call.Diagnostics: [#91:@0002994,283/16] Call> Subscription.Create; publishingInterval: 7500
Call.Diagnostics: [#92:@0002994,298/16] Exit> Subscription.Create; publishingInterval: 7500
LogEntry("OPCLabs-UAEngine",Information,0,3121). The requested maximum keep-alive count of 10 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.1:4840" to a different value, 4. Further such warnings on this session will not be logged.
LogEntry("OPCLabs-UAEngine",Information,0,3123). The requested maximum keep-alive count of 10 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.1:4840" to 4, which is below the tolerance range. The subscription will still be used. Further such warnings on this session will not be logged.
LogEntry("OPCLabs-UAEngine",Information,0,3131). The requested lifetime count of 1000 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.1:4840" to a different value, 4. Further such warnings on this session will not be logged.
LogEntry("OPCLabs-UAEngine",Warning,0,3132). The requested lifetime count of 1000 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.1:4840" to 4, which is below the minimum of three times the maximum keep-alive count 4 negotiated by the server. Further such errors on this session will not be logged.
LogEntry("OPCLabs-UAEngine",Information,0,3134). The requested lifetime count of 1000 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.1:4840" to 4, which is below the tolerance range. The subscription will still be used. Further such warnings on this session will not be logged.
Line 987 – 992:
Call.Diagnostics: [#942:@0002995,406/3] Exit> Subscription.Create; publishingInterval: 7500
LogEntry("OPCLabs-UAEngine",Information,0,3121). The requested maximum keep-alive count of 10 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.2:4840" to a different value, 4. Further such warnings on this session will not be logged.
LogEntry("OPCLabs-UAEngine",Information,0,3123). The requested maximum keep-alive count of 10 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.2:4840" to 4, which is below the tolerance range. The subscription will still be used. Further such warnings on this session will not be logged.
LogEntry("OPCLabs-UAEngine",Information,0,3131). The requested lifetime count of 1000 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.2:4840" to a different value, 4. Further such warnings on this session will not be logged.
LogEntry("OPCLabs-UAEngine",Warning,0,3132). The requested lifetime count of 1000 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.2:4840" to 4, which is below the minimum of three times the maximum keep-alive count 4 negotiated by the server. Further such errors on this session will not be logged.
LogEntry("OPCLabs-UAEngine",Information,0,3134). The requested lifetime count of 1000 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.2:4840" to 4, which is below the
tolerance range. The subscription will still be used. Further such warnings on this session will not be logged.
In both cases the subscription parameters on client side are set to
• Publishing Interval: 7500
• Lifetimecount: 1000
• Max keep alive count: 10
and then will be revised to Publishing Interval: 7500, Lifetimecount: 4, Max keep alive count: 4 from the server.
From our point of view these counter settings are the cause for the subscription to be cancelled on server side.
Please rearrange your client settings in a way that both Publish Interval * Lifetimecount and Publish Interval * Max Keep Alive count do not exceed 30000 ms,
for example:
-RevisedPublishingInterval: 1000
-RevisedLifetimeCount: 12
-RevisedMaxKeepAliveCount: 4
In the our application, we have set the next item:
• PublishingInterval = 250 m seconds (this per call back tag/object).
• EasyUAClient.AdaptableParameters.Subscription.KeepAliveCount = 12;
• EasyUAClient.AdaptableParameters.Subscription.LifetimeCount = 4;
We have carried out all tests with our server and application. Here we would like to ask you to help us solve the following causes:
- Where the Subscription.Create; publishingInterval: 7500 publishing interval came from.
- 2 or 4 times per day un-subscription problem.
Please let us know your feedback in any case, how we can cancel this problems!
In the logging file that is attached, we see a subscription with Subscription.Create; publishingInterval: 7500. The applications don’t make a subscription with an interval from 7500 mseconds. Can you tell how this subscription is making? In the applications, we make subscriptions with an interval from 250 m Seconds.
Rexroth has asked to set the next condition:
Line 121 - 127:
Call.Diagnostics: [#91:@0002994,283/16] Call> Subscription.Create; publishingInterval: 7500
Call.Diagnostics: [#92:@0002994,298/16] Exit> Subscription.Create; publishingInterval: 7500
LogEntry("OPCLabs-UAEngine",Information,0,3121). The requested maximum keep-alive count of 10 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.1:4840" to a different value, 4. Further such warnings on this session will not be logged.
LogEntry("OPCLabs-UAEngine",Information,0,3123). The requested maximum keep-alive count of 10 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.1:4840" to 4, which is below the tolerance range. The subscription will still be used. Further such warnings on this session will not be logged.
LogEntry("OPCLabs-UAEngine",Information,0,3131). The requested lifetime count of 1000 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.1:4840" to a different value, 4. Further such warnings on this session will not be logged.
LogEntry("OPCLabs-UAEngine",Warning,0,3132). The requested lifetime count of 1000 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.1:4840" to 4, which is below the minimum of three times the maximum keep-alive count 4 negotiated by the server. Further such errors on this session will not be logged.
LogEntry("OPCLabs-UAEngine",Information,0,3134). The requested lifetime count of 1000 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.1:4840" to 4, which is below the tolerance range. The subscription will still be used. Further such warnings on this session will not be logged.
Line 987 – 992:
Call.Diagnostics: [#942:@0002995,406/3] Exit> Subscription.Create; publishingInterval: 7500
LogEntry("OPCLabs-UAEngine",Information,0,3121). The requested maximum keep-alive count of 10 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.2:4840" to a different value, 4. Further such warnings on this session will not be logged.
LogEntry("OPCLabs-UAEngine",Information,0,3123). The requested maximum keep-alive count of 10 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.2:4840" to 4, which is below the tolerance range. The subscription will still be used. Further such warnings on this session will not be logged.
LogEntry("OPCLabs-UAEngine",Information,0,3131). The requested lifetime count of 1000 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.2:4840" to a different value, 4. Further such warnings on this session will not be logged.
LogEntry("OPCLabs-UAEngine",Warning,0,3132). The requested lifetime count of 1000 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.2:4840" to 4, which is below the minimum of three times the maximum keep-alive count 4 negotiated by the server. Further such errors on this session will not be logged.
LogEntry("OPCLabs-UAEngine",Information,0,3134). The requested lifetime count of 1000 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.2:4840" to 4, which is below the
tolerance range. The subscription will still be used. Further such warnings on this session will not be logged.
In both cases the subscription parameters on client side are set to
• Publishing Interval: 7500
• Lifetimecount: 1000
• Max keep alive count: 10
and then will be revised to Publishing Interval: 7500, Lifetimecount: 4, Max keep alive count: 4 from the server.
From our point of view these counter settings are the cause for the subscription to be cancelled on server side.
Please rearrange your client settings in a way that both Publish Interval * Lifetimecount and Publish Interval * Max Keep Alive count do not exceed 30000 ms,
for example:
-RevisedPublishingInterval: 1000
-RevisedLifetimeCount: 12
-RevisedMaxKeepAliveCount: 4
In the our application, we have set the next item:
• PublishingInterval = 250 m seconds (this per call back tag/object).
• EasyUAClient.AdaptableParameters.Subscription.KeepAliveCount = 12;
• EasyUAClient.AdaptableParameters.Subscription.LifetimeCount = 4;
We have carried out all tests with our server and application. Here we would like to ask you to help us solve the following causes:
- Where the Subscription.Create; publishingInterval: 7500 publishing interval came from.
- 2 or 4 times per day un-subscription problem.
Please let us know your feedback in any case, how we can cancel this problems!
Please Log in or Create an account to join the conversation.
29 Jul 2015 18:37 #3467
by support
Replied by support on topic The OPC-UA subscription publishing has stopped.
Thank you. The attachments mentioned in the post are missing; and, I do not have access to the Wireshark logs either (maybe they were in the attachments). Anyway, I think the main point is clear to me.
The reason why the client does not send Publish earlier that 30 seconds is because the server has not responded earlier than in 30 seconds (it has used its keepalive interval, which is fine). New Publish can only be sent after a response for the previous one has been received.
The server is then interpreting the interval between Publish-es greater than 30 seconds as that the lifetime interval has been exceeded. This is because the server has incorrectly revised both KeepAliveCount and LifetimeCount to 4, giving *both* intervals equal to 30 seconds (4*7500). If the server has behaved as it should, the lifetime count would be at least 12, and the lifetime (detection) interval therefore 90 seconds, and a Publish after roughly 30 seconds would be OK .
So we are back to the same issue: The server should first make sure the revised intervals do not violate the OPC UA spec. Only after this is fixed, it makes sense to analyze analyze further problems (should they appear).
Best regards
The reason why the client does not send Publish earlier that 30 seconds is because the server has not responded earlier than in 30 seconds (it has used its keepalive interval, which is fine). New Publish can only be sent after a response for the previous one has been received.
The server is then interpreting the interval between Publish-es greater than 30 seconds as that the lifetime interval has been exceeded. This is because the server has incorrectly revised both KeepAliveCount and LifetimeCount to 4, giving *both* intervals equal to 30 seconds (4*7500). If the server has behaved as it should, the lifetime count would be at least 12, and the lifetime (detection) interval therefore 90 seconds, and a Publish after roughly 30 seconds would be OK .
So we are back to the same issue: The server should first make sure the revised intervals do not violate the OPC UA spec. Only after this is fixed, it makes sense to analyze analyze further problems (should they appear).
Best regards
Please Log in or Create an account to join the conversation.
- Alex-Derksen
- Topic Author
- Offline
- Elite Member
-
Less
More
- Posts: 16
- Thank you received: 1
29 Jul 2015 14:00 #3466
by Alex-Derksen
Replied by Alex-Derksen on topic The OPC-UA subscription publishing has stopped.
Opc-UA communication problems.
Bosch Rexroth is working to fix some items. By analyze of the problems they have some questions about, there are a couple of Publish Requests for several Subscriptions which Response. In two attachment files Bosch Rexroth has make an analysis of it.
The mail of Bosch Rexroth:
- TODO: Could you (DPpress) ask your supplier, what this means and what is the reason for?
After this, there are three CreateMonitoredItemRequests, which are good:
29-7-2015 8:16:46 General 2 1 Information Subscribing (with callback): ns=2;s=Thallo_MainController.WINDERHMI.arRewindHmiInterface[1].wMode
29-7-2015 8:16:46 General 2 1 Information Subscribing (with callback): ns=2;s=Thallo_MainController.WINDERHMI.arRewindHmiInterface[1].wStatus
29-7-2015 8:16:46 General 2 1 Information Subscribing (with callback): ns=2;s=Thallo_MainController.WINDERHMI.arRewindHmiInterface[1].wMessage
Then, there are a couple of PublishRequests for several Subscritpions which Response have NO errors.
What I am missing are the PublishRequests for the SubscriptionId 20962.
When I am looking into WireShark, using this filter
opcua && ip.dst==172.17.1.1 && opcua.SubscriptionId==20962
I get only three entries:
08:16:18.380542000 4764 172.17.0.110 172.17.1.1 OpcUa 167 UA Secure Conversation Message: CreateMonitoredItemsRequest
08:16:25.850782000 6170 172.17.0.110 172.17.1.1 OpcUa 125 UA Secure Conversation Message: PublishRequest
08:16:55.947706000 11572 172.17.0.110 172.17.1.1 OpcUa 125 UA Secure Conversation Message: PublishRequest
There are only two PublishRequests, which timedifference are 30.9 seconds.
I think that therefore the Lifetime has been expired: 4*7500ms = 30.0 seconds and the subscription has been deleted by our server.
I even cannot find the PublishResponse of the last PublishRequest (at time 08:16:55.947706000)
-TODO: We (Bosch Rexroth) have to check, why there is no response from our ua-server.
-TODO: You (DGpress) should check, why your Client does not send PublishRequests more frequent.
Then there is directly a DeleteSubscriptionRequest with the Id 20962, which doesn’t exists in the meantime:
29-7-2015 8:16:55 General 2 1 Information EasyUAClient: Failed to remove subscription on the OPC-UA client session to endpoint URL "opc.tcp://172.17.1.1:4840". This error is generally ignored. Further such warnings on this session will not be logged. OPC-UA service result - BadSubscriptionIdInvalid.
---- SERVICE RESULT ----
StatusCode: {BadSubscriptionIdInvalid} = 0x80280000 (2150105088)
In WireShark:
08:16:55.979944000 11582 172.17.0.110 172.17.1.1 OpcUa 121 UA Secure Conversation Message: DeleteSubscriptionsRequest
[0]: SubscriptionIds: 20962 This ID is ok, it’s the main_controller
08:16:55.983359000 11585 172.17.1.1 172.17.0.110 OpcUa 118 UA Secure Conversation Message: DeleteSubscriptionsResponse
[0]: Results: 0x80280000 [BadSubscriptionIdInvalid]
If you have any questions, just call me.
Bosch Rexroth is working to fix some items. By analyze of the problems they have some questions about, there are a couple of Publish Requests for several Subscriptions which Response. In two attachment files Bosch Rexroth has make an analysis of it.
The mail of Bosch Rexroth:
- TODO: Could you (DPpress) ask your supplier, what this means and what is the reason for?
After this, there are three CreateMonitoredItemRequests, which are good:
29-7-2015 8:16:46 General 2 1 Information Subscribing (with callback): ns=2;s=Thallo_MainController.WINDERHMI.arRewindHmiInterface[1].wMode
29-7-2015 8:16:46 General 2 1 Information Subscribing (with callback): ns=2;s=Thallo_MainController.WINDERHMI.arRewindHmiInterface[1].wStatus
29-7-2015 8:16:46 General 2 1 Information Subscribing (with callback): ns=2;s=Thallo_MainController.WINDERHMI.arRewindHmiInterface[1].wMessage
Then, there are a couple of PublishRequests for several Subscritpions which Response have NO errors.
What I am missing are the PublishRequests for the SubscriptionId 20962.
When I am looking into WireShark, using this filter
opcua && ip.dst==172.17.1.1 && opcua.SubscriptionId==20962
I get only three entries:
08:16:18.380542000 4764 172.17.0.110 172.17.1.1 OpcUa 167 UA Secure Conversation Message: CreateMonitoredItemsRequest
08:16:25.850782000 6170 172.17.0.110 172.17.1.1 OpcUa 125 UA Secure Conversation Message: PublishRequest
08:16:55.947706000 11572 172.17.0.110 172.17.1.1 OpcUa 125 UA Secure Conversation Message: PublishRequest
There are only two PublishRequests, which timedifference are 30.9 seconds.
I think that therefore the Lifetime has been expired: 4*7500ms = 30.0 seconds and the subscription has been deleted by our server.
I even cannot find the PublishResponse of the last PublishRequest (at time 08:16:55.947706000)
-TODO: We (Bosch Rexroth) have to check, why there is no response from our ua-server.
-TODO: You (DGpress) should check, why your Client does not send PublishRequests more frequent.
Then there is directly a DeleteSubscriptionRequest with the Id 20962, which doesn’t exists in the meantime:
29-7-2015 8:16:55 General 2 1 Information EasyUAClient: Failed to remove subscription on the OPC-UA client session to endpoint URL "opc.tcp://172.17.1.1:4840". This error is generally ignored. Further such warnings on this session will not be logged. OPC-UA service result - BadSubscriptionIdInvalid.
---- SERVICE RESULT ----
StatusCode: {BadSubscriptionIdInvalid} = 0x80280000 (2150105088)
In WireShark:
08:16:55.979944000 11582 172.17.0.110 172.17.1.1 OpcUa 121 UA Secure Conversation Message: DeleteSubscriptionsRequest
[0]: SubscriptionIds: 20962 This ID is ok, it’s the main_controller
08:16:55.983359000 11585 172.17.1.1 172.17.0.110 OpcUa 118 UA Secure Conversation Message: DeleteSubscriptionsResponse
[0]: Results: 0x80280000 [BadSubscriptionIdInvalid]
If you have any questions, just call me.
Please Log in or Create an account to join the conversation.
23 Jul 2015 13:51 #3458
by support
Replied by support on topic The OPC-UA subscription publishing has stopped.
Thank you.
I may respond with more information later, but here is one important point: As explained in my earlier post, the problem with "subscription post" is *not* related to the session-level keep-alive mechanism. The session-level keep-alive are repeated Read-s of some server variables, and there is no indication anything is going wrong with them. And the frequency is controlled by the IsolatedParameters.Session.KeepAliveInterval setting that you have attempted to change.
Therefore, at least part of the previous post is based on an incorrect assumption about the meaning of this parameter.
---
I do not quite understand this:
Where does the 30s value come from? Is it some kind of hard-coded value in the server? And what is meant by "it is reached"?
Where does the 7500 value come from? Doe it refer to one of the publish rates that we use with subscriptions? (In that case, most likely the one that is used for server status checking as well).
---
I am glad you mentioned the Wireshark captures. Using Wireshark for detailed analysis is something I had in mind should other analysis means fail. In case you already know how to capture them, then, together with the EasyUAClient.LogEntry capture, we should be able to get relatively good picture of what is happening. If, however, Bosch Rexroth is currently working on some kind of fix on their side, I suggest we wait until they come with something, do you agree?
---
Regarding the suggestion to change the settings (PublishRate, LifetimeCount, MaxKeepAliveCount) to specific values: That is not possible to, in this precise way, in QuickOPC. The values are determined using a fairly complex algorithm which involves a set of formulas that makes sure that no boundary conditions (such as those prescribed by OPC spec, or those that we deem necessary ourselves) are exceeded.
Best regards
I may respond with more information later, but here is one important point: As explained in my earlier post, the problem with "subscription post" is *not* related to the session-level keep-alive mechanism. The session-level keep-alive are repeated Read-s of some server variables, and there is no indication anything is going wrong with them. And the frequency is controlled by the IsolatedParameters.Session.KeepAliveInterval setting that you have attempted to change.
Therefore, at least part of the previous post is based on an incorrect assumption about the meaning of this parameter.
---
I do not quite understand this:
If the server internal MaxLifetime (30s) is reached
Where does the 30s value come from? Is it some kind of hard-coded value in the server? And what is meant by "it is reached"?
Where does the 7500 value come from? Doe it refer to one of the publish rates that we use with subscriptions? (In that case, most likely the one that is used for server status checking as well).
---
I am glad you mentioned the Wireshark captures. Using Wireshark for detailed analysis is something I had in mind should other analysis means fail. In case you already know how to capture them, then, together with the EasyUAClient.LogEntry capture, we should be able to get relatively good picture of what is happening. If, however, Bosch Rexroth is currently working on some kind of fix on their side, I suggest we wait until they come with something, do you agree?
---
Regarding the suggestion to change the settings (PublishRate, LifetimeCount, MaxKeepAliveCount) to specific values: That is not possible to, in this precise way, in QuickOPC. The values are determined using a fairly complex algorithm which involves a set of formulas that makes sure that no boundary conditions (such as those prescribed by OPC spec, or those that we deem necessary ourselves) are exceeded.
Best regards
Please Log in or Create an account to join the conversation.
- Alex-Derksen
- Topic Author
- Offline
- Elite Member
-
Less
More
- Posts: 16
- Thank you received: 1
23 Jul 2015 07:44 #3457
by Alex-Derksen
Replied by Alex-Derksen on topic The OPC-UA subscription publishing has stopped.
Thank you for this information.
I understand the information and discuss this with Bosch Rexroth.
Bosch Rexroth has also done research and given answers to some open questions of you.
Bosch Rexroth writes:
OPC UA allows specifying two related rates:
A sampling rate - that's how often the OPC Server should acquire the data, and publishing interval - that's how often the data is sent to the client. With update of the data is the server used? By default, with EasyUAClient, we just specify the sampling rate, and we determine the publishing interval automatically?
• The sampling rate can be configured for every monitored item. It’s independent from the publish Interval. We recommend the double sampling rate as the publish Interval.
Did the server pass the OPC compliance test (certification) by OPC Foundation?
• The Server SDK we use is compliance tested.
Regarding the discussed Problem:
We strongly assume that the combination of requested publishrate/MaxkeepAliveCount on client side leads to the observed behavior:
If the server internal MaxLifetime (30s) is reached, the Lifetimecount will be computed as Lifetimecount = MaxLifetime/PublishInterval
In your case: Lifetimecount = 30000/7500, Lifetimecount = 4
Since MaxkeepAlivecount (the factor that determines the time, after an empty server response is generated in case there has no value change whit in the requested variable) is set to 4 we get as result
LifetimeCount = MaxKeepAlive
Which could lead to the corresponding subscription being removed.
(We observed from the WireShark capture that the notification result with in the publish had a timeout. Regarding our Stack, this means that the subscription has been removed)
We are now aware of the incorrect negotiation result that is computed using your actual communication settings.
Therefore, we will check our server routine and get in contact with the provider of our SDK, if necessary.
Meanwhile please try to change the communication settings in order to have different values of LifetimeCount and MaxKeepAlive
Publishate: 1000
LifetimeCount: 30
MaxKeepAliveCount 5
to check if subscriptions still will be removed on server side.
This is the status on this moment from Bosch Rexroth.
In a telephone discussion whit Bosch Rexroth we changed the parameter KeepAliveInterval to 30 * 100 -> "EasyUAClient.AdaptableParameters.Session.KeepAliveInterval = 30 * 1000;" and testing this chaning.
If I have more information, I will inform you.
Yours Sincerely
Alex
I understand the information and discuss this with Bosch Rexroth.
Bosch Rexroth has also done research and given answers to some open questions of you.
Bosch Rexroth writes:
OPC UA allows specifying two related rates:
A sampling rate - that's how often the OPC Server should acquire the data, and publishing interval - that's how often the data is sent to the client. With update of the data is the server used? By default, with EasyUAClient, we just specify the sampling rate, and we determine the publishing interval automatically?
• The sampling rate can be configured for every monitored item. It’s independent from the publish Interval. We recommend the double sampling rate as the publish Interval.
Did the server pass the OPC compliance test (certification) by OPC Foundation?
• The Server SDK we use is compliance tested.
Regarding the discussed Problem:
We strongly assume that the combination of requested publishrate/MaxkeepAliveCount on client side leads to the observed behavior:
If the server internal MaxLifetime (30s) is reached, the Lifetimecount will be computed as Lifetimecount = MaxLifetime/PublishInterval
In your case: Lifetimecount = 30000/7500, Lifetimecount = 4
Since MaxkeepAlivecount (the factor that determines the time, after an empty server response is generated in case there has no value change whit in the requested variable) is set to 4 we get as result
LifetimeCount = MaxKeepAlive
Which could lead to the corresponding subscription being removed.
(We observed from the WireShark capture that the notification result with in the publish had a timeout. Regarding our Stack, this means that the subscription has been removed)
We are now aware of the incorrect negotiation result that is computed using your actual communication settings.
Therefore, we will check our server routine and get in contact with the provider of our SDK, if necessary.
Meanwhile please try to change the communication settings in order to have different values of LifetimeCount and MaxKeepAlive
Publishate: 1000
LifetimeCount: 30
MaxKeepAliveCount 5
to check if subscriptions still will be removed on server side.
This is the status on this moment from Bosch Rexroth.
In a telephone discussion whit Bosch Rexroth we changed the parameter KeepAliveInterval to 30 * 100 -> "EasyUAClient.AdaptableParameters.Session.KeepAliveInterval = 30 * 1000;" and testing this chaning.
If I have more information, I will inform you.
Yours Sincerely
Alex
Please Log in or Create an account to join the conversation.
22 Jul 2015 14:43 - 22 Jul 2015 14:44 #3454
by support
Replied by support on topic The OPC-UA subscription publishing has stopped.
Thank you. Just to clarify, unless you specify both intervals, normally with QuickOPC you just specify the sampling interval, which is how often the server should obtain the data - that is, the *logical* measure, based on how often you *need* the data in your app. QuickOPC then determines the publish interval, which a *physical* (transport) measure, specifying how often the server sends the data to the client. Leaving outside border cases, QuickOPC sets the publish interval to be twice as fast as the sampling interval. Therefore, with sampling interval of 250 milliseconds, the publish interval of the corresponding subscription would be 125 milliseconds, i.e. the server won't be allowed to send data to the client any faster than that.
The problem you are trying to resolve ("The OPC-UA subscription publishing has stopped...") comes from the keep-alive mechanism on the UA subscription level. This mechanism requires the server to either send fresh data to the client, *or* - if no new data is available - send a keep-alive message. The clients detects a problem when the server does not send any of these responses for a period that is longer than a keep-alive interval. The keep-alive interval is a multiple ("keep-alive count") of the subscription's publishing rate. There is negotiation mechanism between the server and the client that determines the keep-alive count. Following entries in the log refer to the negotiation of maximum keep-alive count:
The client proposes a keep-alive count of 10; the servers has revised it to 4. This is somewhat suspicious; there is nothing fundamentally wrong with it, but it is kind of dangerous. With maximum keep-alive count of 4, the maximum allowed period of subscription "silence", (e.g.) for a subscription with publishing interval 125 milliseconds, is 500 milliseconds. That's not too long; I can easily imagine that for whatever reason, the server or the network may not be able to continuously keep that pace. On the client side, however, we need to stick to the value revised by the server, i.e. 4. You should ask the server provider why they revise the keep-alive count to such small count, and whether it is possible to increase it.
BTW, is the server on the same computer, or a different one?
The setting you are trying to influence in the code you have provided:
is actually for a session-level keep-alive mechanism, which is a different thing, therefore this setting should have no relevance to the issue at hand.
In the log files you have sent, there are also signs of several *other* problems, which may or may not be related.
Example other problem:
This is about a different resiliency feature (lifetime count), but the server's behavior appears to be against the OPC specs: Revising our proposed count of 1000 to 4 is not allowed per OPC spec, because the lifetime count must be at least 3 times higher the keep-alive count, and the keep-alive acount is 4, therefore the lowest valid lifetime count value is 12.
Best regards
The problem you are trying to resolve ("The OPC-UA subscription publishing has stopped...") comes from the keep-alive mechanism on the UA subscription level. This mechanism requires the server to either send fresh data to the client, *or* - if no new data is available - send a keep-alive message. The clients detects a problem when the server does not send any of these responses for a period that is longer than a keep-alive interval. The keep-alive interval is a multiple ("keep-alive count") of the subscription's publishing rate. There is negotiation mechanism between the server and the client that determines the keep-alive count. Following entries in the log refer to the negotiation of maximum keep-alive count:
21-7-2015 9:29:59 General 2 1 Information EasyUAClient: The requested maximum keep-alive count of 10 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.1:4840" to a different value, 4. Further such warnings on this session will not be logged.
21-7-2015 9:29:59 General 2 1 Information EasyUAClient: The requested maximum keep-alive count of 10 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.1:4840" to 4, which is below the tolerance range. The subscription will still be used. Further such warnings on this session will not be logged.
The client proposes a keep-alive count of 10; the servers has revised it to 4. This is somewhat suspicious; there is nothing fundamentally wrong with it, but it is kind of dangerous. With maximum keep-alive count of 4, the maximum allowed period of subscription "silence", (e.g.) for a subscription with publishing interval 125 milliseconds, is 500 milliseconds. That's not too long; I can easily imagine that for whatever reason, the server or the network may not be able to continuously keep that pace. On the client side, however, we need to stick to the value revised by the server, i.e. 4. You should ask the server provider why they revise the keep-alive count to such small count, and whether it is possible to increase it.
BTW, is the server on the same computer, or a different one?
The setting you are trying to influence in the code you have provided:
uaClient.IsolatedParameters.Session.KeepAliveInterval = 60 * 1000;is actually for a session-level keep-alive mechanism, which is a different thing, therefore this setting should have no relevance to the issue at hand.
In the log files you have sent, there are also signs of several *other* problems, which may or may not be related.
Example other problem:
21-7-2015 9:30:00 General 2 1 Information EasyUAClient: The requested lifetime count of 1000 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.2:4840" to 4, which is below the minimum of three times the maximum keep-alive count 4 negotiated by the server. Further such errors on this session will not be logged.
21-7-2015 9:30:00 General 2 1 Information EasyUAClient: The requested lifetime count of 1000 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.2:4840" to a different value, 4. Further such warnings on this session will not be logged.
21-7-2015 9:30:00 General 2 1 Information EasyUAClient: The requested lifetime count of 1000 has been revised by the OPC-UA server on endpoint URL "opc.tcp://172.17.1.2:4840" to 4, which is below the tolerance range. The subscription will still be used. Further such warnings on this session will not be logged.
This is about a different resiliency feature (lifetime count), but the server's behavior appears to be against the OPC specs: Revising our proposed count of 1000 to 4 is not allowed per OPC spec, because the lifetime count must be at least 3 times higher the keep-alive count, and the keep-alive acount is 4, therefore the lowest valid lifetime count value is 12.
Best regards
Last edit: 22 Jul 2015 14:44 by support.
Please Log in or Create an account to join the conversation.
- Alex-Derksen
- Topic Author
- Offline
- Elite Member
-
Less
More
- Posts: 16
- Thank you received: 1
22 Jul 2015 07:54 #3453
by Alex-Derksen
Replied by Alex-Derksen on topic The OPC-UA subscription publishing has stopped.
The answer on your questions:
1. What are the sample intervals (out of the properties.xlsx)
a. The interval is in milliseconds for each tag.
b. In the file “HMI-trace.txt” you see the ServerUri, NodeID, Interval, ReadOnly (example):
o 337; 21-7-2015 9:29:59 General 2 1 Information ServerUri : opc.tcp://172.17.1.1:4840
o 338; 21-7-2015 9:29:59 General 2 1 Information NodeId: ns=2;s=Thallo_MainController.MAINHMI.arMachHmiInterface[1].rHighSpeedSetting
o 339; 21-7-2015 9:29:59 General 2 1 Information Interval: 500
o 340; 21-7-2015 9:29:59 General 2 1 Information ReadOnly: False
c. The fastest rate we used are the tags: wMode, wStatus and wMessage with an interval of 250 milliseconds. This tags we subscribe as a publishing interval 250 millisecond in a new UCAclient object.
2. We using the public interval for update the data. The server changed that depends of the process. We ask Bosch Rexroth DE about the update rates of the server.
a. In the client (HMI) we are only inters how quick we can get the data if it is changed (this depends on the PLC Process). What is the best suggestion for publishing interval or publishing interval automatically?
3. We have asked Bosch Rexroth DE about OPC compliance test (certification) by OPC Foundation.
The questions I have not been able to answer, I will send you if we get an answer from Bosch Rexroth.
Please let us know your feedback in any case,
Thank you
1. What are the sample intervals (out of the properties.xlsx)
a. The interval is in milliseconds for each tag.
b. In the file “HMI-trace.txt” you see the ServerUri, NodeID, Interval, ReadOnly (example):
o 337; 21-7-2015 9:29:59 General 2 1 Information ServerUri : opc.tcp://172.17.1.1:4840
o 338; 21-7-2015 9:29:59 General 2 1 Information NodeId: ns=2;s=Thallo_MainController.MAINHMI.arMachHmiInterface[1].rHighSpeedSetting
o 339; 21-7-2015 9:29:59 General 2 1 Information Interval: 500
o 340; 21-7-2015 9:29:59 General 2 1 Information ReadOnly: False
c. The fastest rate we used are the tags: wMode, wStatus and wMessage with an interval of 250 milliseconds. This tags we subscribe as a publishing interval 250 millisecond in a new UCAclient object.
2. We using the public interval for update the data. The server changed that depends of the process. We ask Bosch Rexroth DE about the update rates of the server.
a. In the client (HMI) we are only inters how quick we can get the data if it is changed (this depends on the PLC Process). What is the best suggestion for publishing interval or publishing interval automatically?
3. We have asked Bosch Rexroth DE about OPC compliance test (certification) by OPC Foundation.
The questions I have not been able to answer, I will send you if we get an answer from Bosch Rexroth.
Please let us know your feedback in any case,
Thank you
Please Log in or Create an account to join the conversation.
21 Jul 2015 18:58 #3452
by support
Replied by support on topic The OPC-UA subscription publishing has stopped.
Hello, thank you for the detailed information. There are some interesting/suspicious things in it, and I will describe them later; for now, can you please answer this:
1. What are the sampling intervals that you specify for your tags? Are those the rates under "Interval Msec" in properties.xlsx ? What is the fastest rate used?
2. OPC UA allows to specify two related rates: A sampling rate - that's how often the OPC Server should acquire the data, and publishing interval - that's how often the data is sent to the client. By default, with EasyUAClient, you just specify the sampling rate, and we determine the publishing interval automatically - is that the approach you are using?
3. Did the server pass the OPC compliance test (certification) by OPC Foundation?
Thank you
1. What are the sampling intervals that you specify for your tags? Are those the rates under "Interval Msec" in properties.xlsx ? What is the fastest rate used?
2. OPC UA allows to specify two related rates: A sampling rate - that's how often the OPC Server should acquire the data, and publishing interval - that's how often the data is sent to the client. By default, with EasyUAClient, you just specify the sampling rate, and we determine the publishing interval automatically - is that the approach you are using?
3. Did the server pass the OPC compliance test (certification) by OPC Foundation?
Thank you
Please Log in or Create an account to join the conversation.
Moderators: support
- Forum
- Discussions
- QuickOPC-UA in .NET
- Reading, Writing, Subscriptions
- The OPC-UA subscription publishing has stopped.
Time to create page: 0.088 seconds