Log In
Register
Forum
Topic RSS
10:17, EET
January 27, 2022
Offline
Hi everyone,
we are using the prosys-opc-ua-sdk-client (version 4.4.0-1240 if it matters) for connecting (and making subscriptions for PLC updates) from our application to a Tani OPC server (https://www.tanindustrie.de/en/Download.php?page=opcserver). However, every now and again we receive errors when doing the subscription, receiving updates or pulling data directly from the OPC server. The errors are as follows:
“`
Bad_NotConnected (0x808A0000) “The variable should receive its value from another variable, but has never been configured to do so.
“`
“`
Bad_CommunicationError (code=0x80050000, description=”2147811328, Connection reset”)
“`
“`
Bad_CommunicationError: Retrying
“`
“`
Bad_ConnectionRejected (code=0x80AC0000, description=”2158755840, Connection refused (Connection refused)
“`
“`
Bad_ConfigurationError (0x80890000) “There is a problem with the configuration that affects the usefulness of the value.
“`
I looked into the documentation but there seems to be very little (if anything) written about this error codes. Can someone please explain in more detail what exactly they mean? How should we handle such errors?
And also a related question – we have not updated our prosys library for quite a while. Can we expect that the number of such subscription errors will decline if we update to the latest version? Will updating somehow help reducing the data loss in the connection between our app plcs?
Thanks,
Martin
10:56, EET
Moderators
February 11, 2020
Offline
Hello,
In general, I would advice you to contact the manufacturer of the Server and ask them how their Server is using the StatusCodes you listed.
Bad_NotConnected is not used by the SDK internally, so you will need to contact the manufacturer of the Server to explain the use of this StatusCode. The specification says that it is used when Variables are not connected to their data sources so perhaps the OPC UA Server is not properly connected to its data sources when you get this code.
Bad_CommunicationError typically refers to low level errors in communication between the Client and the Server. It is a very generic code so it could refer to various things. However, the messages in your codes are “Connection Reset” and “Retrying” so perhaps the Server has restarted itself without closing the application or something similar. I would need more information on the context in which you received this code for more accurate speculation on what could have caused it. And I would also advice trying to figure out what is happening on the Server side when you get this code.
Bad_ConnectionRejected is used when the Server rejects a connection, but it is also used on the Client side when attempting to connect and there is no response from the Server. If the Server is not online, you are expected to get this code. Otherwise, it depends on the Server why you got this code.
Bad_ConfigurationError is not used by the SDK internally either, so again you will need to contact the manufacturer of the Server to explain the use of this StatusCode. The specification says that there is “a problem with the configuration that affects the usefulness of the value” so perhaps it refers to value source of a Variable being misconfigured and making the Value Bad.
SDK version 4.4.0 was released in 2020 so it is already very old at this point. The latest version of the SDK is 5.0.2. There have been several security fixes between these two SDK versions, so updating to the latest version is highly recommended.
Subscription errors typically happen on the Server side so updating the SDK version might not have any effect on that. Though, there have been some fixes and improvements to Subscriptions and MonitoredItems since version 4.4.0, so updating the SDK to the latest version shouldn’t make things worse and it is anyway recommended due to the security fixes.
11:50, EET
January 27, 2022
Offline
Hi Matti,
Thanks a lot for the reply! We get most of these – Bad_NotConnected, Bad_CommunicationError, Bad_ConfigurationError – in our `onMonitoredDataItemChange` callback which we supply when creating the subscription and is called each time a subscribed item changes. How should we handle these errors? So for example, if we get `Bad_NotConnected` because the PLC is i.e. shut down will things start working out of the box when the PLC is turned on again? Do we need to do something additional (i.e. recreate the subscription, retry?)
Best,
Martin
12:23, EET
Moderators
February 11, 2020
Offline
Hello,
I’m not sure what you mean with “onMonitoredDataItemChange”. There is no such method in the SDK. Are you referring to “onDataChange” method of SubscriptionNotificationListener, “onDataChange” of MonitoredDataItemListener or something different?
In the context of a MonitoredItem reporting these StatusCodes, there really isn’t anything that can be done on the Client side. The Node corresponding to the MonitoredItem is in some type of error state on the Server side. You will need to contact the manufacturer of the Server for more information on such error states.
If the connection between the Client and the Server breaks, the automatic reconnect will handle recreating Subscriptions and MonitoredItems. Recreating MonitoredItems should work even if the Server hasn’t added the Nodes into its AddressSpace as long as it responds with Bad_NodeIdUnknown as defined in the specification. If it uses a different StatusCode for missing Nodes, recreating MonitoredItems won’t be attempted automatically periodically and you will need to recreate them manually after a connection break.
13:10, EET
January 27, 2022
Offline
I meant the `onDataChange(Subscription subscription, MonitoredDataItem item, DataValue newValue)` method of the `AbstractSubscriptionNotificationListener`, sorry for the confusion.
With regards to: If the connection between the Client and the Server breaks, the automatic reconnect will handle recreating Subscriptions and MonitoredItems – how does this automatic reconnect work? We currently have logic in place where every 10 seconds we check the connection and if it is down we reconnect manually and resubscribe for all PLCs. Is this redundant?
I just noticed that in another app our team used to develop we have both set UaClient.setAutoReconnect(true) and are doing the manual reconnect/resubscribe every 10 seconds. Can this lead to any issues?
13:37, EET
April 3, 2012
Offline
Hi,
The version you are using (4.4.0) is almost 3.5 years old, updating is recommended. The latest is 5.1.0 (that was released today).
Yes, that is redundant. It is the job of the SDK by default to handle the reconnects. The SDK will by default periodically read the ServerStatus node of the server, if it fails (or the state is not ‘Running’) it will go to a “reconnect mode” explained by Matti above. Reading the status servers also another purpose: it will keep the Session from timing out.
Thus, UaClient.reconnect must not be called manually if UaClient.setAutoReconnect(true) is used (the default). Doing so can cause race-conditions (as both the manual code and the automatic would try to reconnect) and has been the source of many issues in the past; it was only intended to be called manually when AutoReconnect is false. Newer versions (4.10.0 or newer) of the SDK will throw IllegalStateException if .reconnect is called manually while AutoReconnect is true.
14:18, EET
January 27, 2022
Offline
Thanks a lot for the replies!
What happens if the session times out? Does the subscription stop working? How should session timeouts be handled? Is there any benefit to disabling the auto reconnect/resubscribe and doing it manually?
Best,
Martin
14:59, EET
April 3, 2012
Offline
Many questions. We cannot exactly cover everything related to OPC UA in depth in the context of forum support. If you need help in learning OPC UA or some advanced use-cases, we have https://www.prosysopc.com/services/quickstart/ and https://www.prosysopc.com/training/opc-ua-workshop/ (talk with sales@prosysopc.com).
If a Session times out, no service calls (such as Read/Write etc.) to the server work and they will timeout and you will get Bad statuscodes and/or some SDK methods throw.
Subscriptions lifespan is separate from the Sessions, but their lifetimecount will be reached by the server internally if the Session is not sending PublishRequests (thus the server will eventually close them). After reconnect the SDK will try (via TransferSubscriptions service call, automatically) to transfer them to the current Session (or it recreates them if this fails).
In normal cases there is no benefit to doing the reconnect manually. You would just do the same things the SDK can already do for you automatically.
15:23, EET
January 27, 2022
Offline
Thanks Bjarne,
is there more information on how the auto reconnect works? How many retries it will do in order to reconnect? Will it use some kind of a backoff?
15:50, EET
April 3, 2012
Offline
It will retry forever until the connection is formed again (or you call disconnect()). Typical OPC UA Client Applications are continuously connected to the server (always, i.e. 24/7). A connection break is kinda an abnormal scenario and shouldn’t happen under normal operation. Of course the world out there is big and there are a lot of use-cases for OPC UA, but this is the typical one. If you have some odd case where this wouldn’t apply (though in this case it would be nice to hear what it is), then turning off the automatic one might make sense.
Most Users Ever Online: 518
Currently Online:
14 Guest(s)
Currently Browsing this Page:
2 Guest(s)
Top Posters:
hbrackel: 135
pramanj: 86
Francesco Zambon: 81
rocket science: 77
Ibrahim: 76
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
fred: 41
Member Stats:
Guest Posters: 0
Members: 683
Moderators: 16
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1467
Posts: 6261
Newest Members:
Kickbiche, karrimacvitie5, graciela2073, sagarchau, elviralangwell4, Donnavek, Eddiefauth, DonaldPooma, fidelduke938316, Jan-PfizerModerators: Jouni Aro: 1010, Otso Palonen: 32, Tuomas Hiltunen: 5, Pyry: 1, Petri: 0, Bjarne Boström: 983, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 26, Teppo Uimonen: 21, Markus Johansson: 42, Niklas Nurminen: 0, Matti Siponen: 321, Lusetti: 0, Ari-Pekka Soikkeli: 5
Administrators: admin: 1
