Log In
Register
Topic RSS
17:25, EEST
March 26, 2021
Offline
Hello,
Faults of this type are indicated on the OPC UA client side (KepServerEx 6):
Date Time Level Source Event
29/04/2025 21:09:25 Warning OPC UA Client Unable to use registered read/write for tag ‘ns=2;s=10.0.21.1!MIK_OEE.AWAITINGMAINTENANCE.STATUS’. | Status description = ‘The operation cannot be completed because the object is closed’, Status code = 80AF0000.
On our UA server side, there are no exceptions or errors, and when the problem occurs, the number of connections and subscriptions indicated remain the same. Same tags read with UaExpert remains “good”.
The problem occurs very quickly if the subscription mode used by the client is “exception”, but it still occurs in “polling” mode.
Would you have any advice on how to solve this problem?
Thank you in advance
Denis
9:51, EEST
Moderators
February 11, 2020
Offline
Hello,
Has the Server you’re connecting to been developed with Prosys OPC UA SDK for Java or Prosys OPC UA SDK for Delphi? If it has been, can you tell us which SDK (Java or Delphi) it has been developed with and what is the version number (e.g. 5.3.0) of the SDK used to develop the Server?
If the Server hasn’t been developed with on of our SDKs, we can’t help you debugging the Server and you should direct this question to Kepware and/or the developers of the Server.
17:17, EEST
March 26, 2021
Offline
Hello Matti,
Sorry, I’d lost the habit of giving this basic information in my previous exchanges with Jouni.
I’m currently using the Prosys SDK for Delphi, version 7.5.1.
18:08, EEST
December 21, 2011
Offline
Hi Denis, Thanks for the info. Since you picked the “OPC UA” forum, I believe we were also not able to know this.
This error (BadInvalidState, 0x80AF0000) is probably related to the communication channel, which is handled by the UaStack32.dll.
You could try to enable stack level tracing, which I think was enabled in version 7.5.0.
Either one, should create a uaStack.log next to your executable and maybe it reveals more about that.
TUaStack.TraceLevel := stlDebug;
You can send that to our support email, if you don’t find anything useful out of it yourself.
But, I would also recommend to update to the latest version, just in case. There hasn’t been much changes to the stack according to the Release Notes, though, but you never know…
12:40, EEST
March 26, 2021
Offline
Hi Jouni,
Thank you very much for your support.
Our server works quite well with different clients, but this problem with kepServerEx has been going on for a few weeks. I’m going to set up the log as you indicate.
I haven’t found in the doc I have what the different enumeration values for TraceLevel do. Is the content of the log targeted at different parts, or is there a gradation in the level of detail of the information provided? With stlDebug, it’s quite difficult to analyse the contents of the log.
Denis
19:08, EEST
December 21, 2011
Offline
Yeah, it’s not very well documented, if at all, but they define the level of detail. stlContent gives the most detail and since we need more detail for this case, maybe you should just use that. But the log is not easy to interpret – mainly I would just look for the error code in question and see if we find out why it is given out. It will be enough to get a hint where it is happening, so I can look at the code and try to figure out the rest, if the log is not very obvious.
1 Guest(s)
