Professional OPC
Development Tools

logos

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.

"The OPC-UA subscription publishing has stopped."

More
10 Aug 2014 09:21 - 10 Aug 2014 09:22 #2149 by support
Please give this a deep thought before going forward. Specifically, I suggest that you do not try to implement any re-connections of your own.

Here is the information you may need:

OPC-UA implements various kind of checks to assure that the client-server connection is truly working. These checks include a bi-directional keep-alive mechanism, and it is this mechanism that is responsible for the error you are seeing.

The checks are time-based, meaning that there is a certain time period during which (I am simplifying here) the server has to respond to the client and the client to the server. While the idea of these checks sounds great and actually does work well in production, it causes a BIG PROBLEM once you start debugging. Debugging often involves pausing the program, and the keep-alive checks then start failing. That's what they are supposed to do, right...?

The sad fact is there is no 100%-guaranteed way around it.

We have a special logic in our component, which works as follows: When we detect that the program is being run under the debugger, and a new OPC-UA session is being created, we modify the usual keep-alive timings on the client side to a very large value (days). This sometimes helps - but not always. There are various reasons why this workaround may fail, for example:

a) The program may be started and the session created without the debugger, and later the debugger is attached and the program paused.

b) (This is probably what happens in your case): The keep-alive checks are bi-directional, and the actual timings used are subject to upfront "negotiation" between the client and the server. Therefore, even if we detect the debugger, and propose a keep-alive several days long, the server may - and often does - revise this value to something that it considers reasonable, bringing us back to where we were.

The bottom line is that the only way out of this may be to devise and use debugging techniques that do NOT involve pausing the program.

And, in case of session-level errors, QuickOPC already has a mechanism to reconnect. All it needs it that its process must be actually given a time to run. If you start trying to do reconnections on your own, you will not help anything, as the debugger has the absolute power over the program, and when it pauses the program, it basically creates a condition that goes against what OPC UA specification imposes on the client behavior. So it is the fact of using the debugger (or, to be more precise, pausing the program) that is ultimately "guilty" here, and not anything else.
Last edit: 10 Aug 2014 09:22 by support.

Please Log in or Create an account to join the conversation.

More
09 Aug 2014 12:42 #2147 by giles
I get this error when setting a break point in my code and waiting on it for a little while.

I'm implementing a way of reconnection - it means you have to have an Isolated client and basically make a new one.

I am wondering whether you could be doing this in the background much as you do when a server goes down and comes back up

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.043 seconds