Hello. There is a plenty of material to respond to, not just the specific questions you have. For this reason, I have copied below your whole post, and interspersed my responses into it.


Hello,

Let me start by introducing myself. I am Erik a colleague of Alex and will be taking over from now on. I am “reviving” this thread as the problems are still there and this is the best starting point.

To summarize the situation as the thread was left:

1. The server is setting the KeepAliveCount and LifeTimeCount values to the same value of 4.
2. The server is setting the KeepAliveCount and LifeTimeCount to a low value of 4.
3. Trying to set the OPC client to match the server is “a waste of time”.

So almost a year later this is our current status:
1. The server is setting the KeepAliveCount to 4.
2. The server is setting the LifeTimeCount to 12.
3. Some settings we try to make as our “wish” settings are as good as ignored by the EasyUAClient.
a. IE: Setting a LifeTimeCount of 30 results in the client requesting a LifeTimeCount of 1000.
4. Settings related to KeepAliveCount, LifeTimeCount and SamplingInterval are changed by the server.

In our current situation the problems have diminished compared to last year. Right now we don’t lose connection a couple of times a day for 3min but instead lose connection up to a couple of times an hour for 3s. Logs for a situation this accoes are included:
File Attachment:
File Name: 20160601Logs.7z
File Size: 2,982 KB

Now I have send to following request to our server provider Bosch Rexroth:
1. Can you increase the keep-alive count on the server? It would be great if the counts could be greater than 4 and 12 so we can run our software while debugging and not lose connection all the time.
2. I explained and pointed to your explanation of the different uses of the OPCLabs EasyUAClient. And, if their only viable option would be for us to run Isolated instance, that I would like them to answer the following:
I would like to have a list of your server’s desired settings. This so I can set our clients properly and to ask OPCLabs for a recommendation on how to move forward. It would also help if you could describe why this might be our only solution, so that I can better understand the situation and explain the situation to OPCLabs.

In my view, you are improperly focusing on the values of various settings , in hope that tweaking them will resolve the issue. In the current situation, I do not see, however, a direct indication that any of the settings is wrong. What is wrong is that either the server does not respond for extended periods of time, or that the client for some reason does not "see" these responses. Whether the fault is on the server or the client side would be possible to determine by correlating the Wireshark logs (of the actual OPC UA communication) with the QuickOPC LogEntry-s taken during the same time. That is the route recommended by me at this point - after ruling out some client-side problems as per questions below. From what I could tell from the log files, it is more likely that the problem is on the server side - because there are signs of proper client activity (PublishRequest) but no (PublishResponse) responses from the server being logged for some time; but the Wireshark capture PLUS the same logs on client side should give a clear answer as to which side is responsible.

I have some questions that may help in guiding the investigation:
A. What is the CPU usage on the client side?
B. What is your code doing in the event handler for data changes? Is it just manipulating in-memory data, or is it e.g. writing files, communicaing with the database, - or what it is doing? Is there a possibility that it requires relatively long time to complete? (compared with the rate of incoming changes?)

If you truly wanted to insist on tweaking the parameters, then I will work with you to achieve the desired values - but at this moment I recommend against doing it. In general, it should be possible to specify parameters in such a way that you get you desired KeepAliveCount and LifeTimeCount (as long as they are OPC UA compliant and generally meaningful), but as I described earlier, there are boundary conditions that take precedence over your settings, and therefore you do not always get what you have specified. The boundary conditions are complex, and we are not going to publicize them in their entirety, because they belong to our "know how". But to give you an example, we have a requirement that the keep-alive interval is not faster than 5000 ms. The interval is computed from a publishing rate and a keep-alive count. Therefore if the publishing rate is fixed, and you specify a keep-alive count that is too small and would result in a keep-alive interval faster than 5000 ms, your keep-alive count would be increased.
Some parameters that define the boundary conditions can again be tweaked, and some not.

Now I also have a couple of questions for you (OPCLabs):
1. Can we access what an EasyUAClient does with the adaptable parameters we set? (Does it accept them? Ignore them? Perhaps some logging?)
Not directly. Some of it might be found in the LogEntry-s (as you can already see in the messages you are posting here).
2. Can we access the current settings an EasyUAClient uses? IE: What is the current keep-alive count? Keep alive interval? Lifetime count?
Not directly. Some of it might be found in the LogEntry-s (as you can already see in the messages you are posting here). The OPC server has final say in determining these parameters, so as long as the OPC server responds with revised parameters that do not violate the OPC UA specs, QuickOPC will use the numbers given by the server.

What triggers these questions are the following 2 log entries:
 EasyUAClient: OPCLabs-UAEngine, The requested maximum keep-alive count of 10 has been revised by the OPC-UA server subscription ID 21828 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.
I found out that in the version you are using, this particular message is issued incorrectly by QuickOPC in many situations, and should be ignored. We will fix it in a future version.
 OPCLabs-UAEngine, The OPC-UA subscription ID 24592 publishing has stopped on the client session with connect sequence number 1 to endpoint URL "opc.tcp://172.17.1.2:4840" for approximate current duration of 8361.7072 milliseconds. The current keep-alive count is 40 and the current publishing interval is 125 milliseconds. Further such errors on this session will not be logged.
More on this elsewhere in my reply, but this is at the core of the problem. For a subscription with publishing interval 125 ms and a keep-alive count 40, the server must respond no later than in 5000 ms. It either has not responded for quite a long time, or there is some other problem (in the communication, or also at the client side) that has prevent QuickOPC from receiving or recognizing the response in time.

So our maximum keep-alive count is 4. Yet we are using a keep-alive count of 40? Could this be causing issues?
No. It is not a different keep-alive count on the same subscription. These counts (4 and 40) are on different subscriptions, and are thus unrelated.

It would be great if I could see/log this information as well when the subscription publishing has stopped.

Another question coming from Rexroth:
1. Is it possible to set a KeepAliveTimeOut (to twice the keep alive time)?
I could not find this specific setting. Is it under a different name?
I have no idea what setting they are talking about. To my knowledge, KeepAliveTimeOut appears neither in OPC UA specs nor in QuickOPC.


I thank you for your time and look forward to your reply,

Erik

Received - working on an answer.
Best regards

There can be several possible causes of this issue. In the previous posts, the cause was the OPC UA server that was not compliant with the specification. It can be same, similar, or a different reason in your case.

Can you please provide following additional information:

1. Which OPC UA server are you connecting to?
2. Is the server on the same computer as the client, or on a different computer on LAN, or elsewhere (WAN, internet)?
3. Which protocol? opc.tcp, or http, or https?
4. What kind of project is your code (e.g. Windows Forms app, Console app, Windows Service, Web app, Web service, etc.)?
5. How often does the problem appear? Always, often, seldom? How long does it typically take since the start of the app?
6. If you wait and let the application run further, does it recover (and start receiving valid data)?
7. Are you running your program in a debugger, or standalone? If under debugger, are you using breakpoints?

Thank you

As a preamble, anything that you describe in the recent post does not pose a problem (at least not a problem on the client side), and if you are still having communication issues, they are most likely coming from a different area, or caused by the server problem that we already know about. According to the recent logs, the server still sometimes revises both the keep-alive and lifetime counts to 4, so please fix that first.

The server should be able to cope well with client requests that are OPC compliant. What you are focusing on, is trying to tweak the client so that it

fits what you think the server will accept. That's not the right way to go, for several reasons, and not a good use of our time.


Ad 1, Ad 2: The situation in which you are seeing very high "counts" is probably when you are running the program under the debugger. When we detect such situation, we use different, *very long* minimum intervals. This is because it is otherwise impossible to place breakpoints into a running client program: When the intervals are several seconds (or minutes - depending on how quickly you debug) long, the OPC UA resiliency mechanisms (keep-alive, lifetime) naturally still work, and the communication breaks down, when the program is paused in the debugger. For this reason, with debugger detected, we enforce minimums that default to 1 day. This can be changed from the code, using other parameters, as well.


Ad 3. I have not told you to worry about this log message, therefore you do not have to. It is just a warning with no consequences. It does *not* say that the server behavior is against the OPC UA specification. The reason it exists is because the OPC compliance certification (that is, the process of obtaining the logo for the product) requires the client to detect what it considers as "suspicious" revisions of the "counts". And, the client must report (log) these, in order to obtain the UA certification logo, whether we think it is a good idea or not. Therefore we have this detection and the warning in the software, but it does not necessarily mean any problem. Notice that in the log, the entry is classified as "Information" (which basically means
no problem at all), whereas the spec violation is classified as "Warning".

Specifically, in the "UA Client Test Case Specification", Version 1.02.334.200, it is under Subscription Services -> Subscription Client Basic:

Err-005

CTT

CreateSubscription

Inject the following RevisedMaxKeepAliveCount error codes:
1. revisedMaxKeepAliveCount returned decades larger than the requestedMaxKeepAliveCount*10.
2. revisedMaxKeepAliveCount returned decades smaller than requestedMaxKeepAliveCount, e.g. requested / 10 (or a reasonable difference).

a.Client checks the revised value and if it is different to the requested then it logs a message.
b.Client logs a message that the requested and revised value differs.

Here, the revised count (4) was decades smaller than the requested count (11520). If you do not like this log entry, the proper addressee of your complaint should be the OPC Foundation.


Note that the server always has final say in the negotiation. That's why its revised counts need to be compliant wit the spec. But also, if the server would "stubbornly" revise the counts to small values, then in the scenario with the debugger attached to the client (Ad 2, log b), the well-proposed parameters we have requested from the client will be lost, and the communication will inevitably break with any breakpoint that would suspend the client process.


Best regards

Before I can answer this, please clarify: What has changed between logs a) and b) ? Are you saying that nothing has changed that you are aware of? Or, have they been made different settings on the client or server side (if so, how did they differ?)

I see.

One additional comment, just to make sure there is not a misunderstanding: I have noticed that we have used different approaches when providing examples to set the parameters.

It is possible to use either
or
The first approach sets the static parameters, used by all EasyUAClient objects in their default state (with Isolated = false, and these objects share the same connections to the server). The second approach sets the parameters for just one specific EasyUAClient object (which makes its own server connections, as given by isolated = True).

You will probably use just one of these approaches in your project - select the one that is appropriate, and use it consistently. I recommend *against* using multiple EasyUAClient objects with Isolated = true, because that leads to inefficiency (multiple connections to the same server). The first approach is therefore normally better (and therefore you may have to modify my example from the previous post to fit this approach).

Best regards