Bad_Timeout - Could not init TypeDictionary, decoding custom Structures might not work | OPC UA SDK for JavaProsys Forum

Please consider registering
guest

Forum

OPC UA SDK for Java
sp_ArrowRight

Bad_Timeout - Could not init TypeDictionary, decoding custom Structures might not work

Topic RSS

Bad_Timeout - Could not init TypeDictionary, decoding custom Structures might not work

January 29, 2021
11:18, EET

rocket science

Member

Members

Forum Posts: 77

Member Since:
March 16, 2017

Offline

Hi all,

I have noticed following exception when connecting to a special OpcUa server. The connection itself works, and also reading values from the server, but I like to find out from where this problem comes exactly – so is it a wrong implementation in the server, or is this a normal behaviour if e.g. the server does not use any custom types?
I’m using SDK version 4.3.0

UaClient |WARN |Could not init TypeDictionary, decoding custom Structures might not work
com.prosysopc.ua.typedictionary.TypeDictionaryException: Cannot init typedictionaries
at com.prosysopc.ua.typedictionary.TypeDictionary.init
at com.prosysopc.ua.client.UaClient.connect
Caused by: com.prosysopc.ua.ServiceException: Bad_Timeout (code=0x800A0000, description=”The operation timed out.”) ServiceResult=Bad_Timeout (0x800A0000) “The operation timed out.”
at com.prosysopc.ua.client.AddressSpace.browse
at com.prosysopc.ua.client.AddressSpace.b
at com.prosysopc.ua.client.AddressSpace.a
at com.prosysopc.ua.client.AddressSpace.b
at com.prosysopc.ua.client.InternalAddressSpaceAccessHelper.internalBrowseWithNodeIds
at com.prosysopc.ua.client.InternalAddressSpaceAccessHelper.internalBrowseAllDataWithNodeIds
at com.prosysopc.ua.typedictionary.TypeDictionary.asc
at com.prosysopc.ua.typedictionary.TypeDictionary.init
… 81 more
Caused by: com.prosysopc.ua.stack.common.ServiceResultException: Bad_Timeout (code=0x800A0000, description=”The operation timed out.”)
at com.prosysopc.ua.stack.transport.impl.AsyncResultImpl.waitForResult
at com.prosysopc.ua.stack.transport.tcp.io.SecureChannelTcp.serviceRequest
at com.prosysopc.ua.stack.transport.tcp.io.SecureChannelTcp.serviceRequest
at com.prosysopc.ua.stack.application.SessionChannel.serviceRequest
at com.prosysopc.ua.stack.transport.ChannelService.Browse
at com.prosysopc.ua.client.AddressSpace.browse
… 88 more

Thank you!

January 29, 2021
15:25, EET

Bjarne Boström

Moderator

Moderators

Forum Posts: 983

Member Since:
April 3, 2012

Offline

Hi,

We read all Types on connect now by default (it is a long explantion of why; which I’ll skip in this post), seems the server didn’t respond to one of our Browse calls, thus it timeouted thus the TypeDictionary could not be initialized.

While maybe not exacly the same, these post might give more info:
https://forum.prosysopc.com/forum/opc-ua-java-sdk/siemens-s7-1500-problems-initializing-typedictionary/
https://forum.prosysopc.com/forum/opc-ua-java-sdk/bad_encodinglimitsexceeded-could-not-init-typedictionary/

Please check does the server define OperationLimits, i.e. does it define the max amount of operations to e.g. Browse and Read calls (we will literally use those max amounts now to optimize the number of calls to be made during connect, previously we typically ended up doing like 100 calls later which are now avoided)? They were added as optional in OPC UA 1.02. If no limits found then by default UaClient uses 10000 operations as a limit. There was a bug which prevented (manual) setting of lower-client side limits which was fixed in https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html#version-4-4-0 so please try with latest if you need to change those.

Generally I would expect the server to respond at least with some message in this case, but maybe it just fails if the data to send back would be too large to encode (in which case the OperationLimits of the server should be lowered maybe). Does the server logs etc. indicate what would have happened?

All RSS

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 518

Currently Online:
10 Guest(s)

Currently Browsing this Page:
1 Guest(s)