11:56, EET
October 4, 2013
Hello,
We are currently integrating towards a production OPC UA server, until now we have been using a mock-server. The mock-server is written using the Prosys SDK, while the production server is not. When subscribing to a specific event in the address space of the production server, we experience the following error:
at com.prosysopc.ua.client.Subscription.a(Unknown Source) [Prosys-OPC-UA-Java-SDK-Client-Server-Binary-1.4.6-8021.jar:1.4.6.8021]
at com.prosysopc.ua.client.Subscription.handleNotificationDatas(Unknown Source) [Prosys-OPC-UA-Java-SDK-Client-Server-Binary-1.4.6-8021.jar:1.4.6.8021]
at com.prosysopc.ua.client.UaClient$a.b(Unknown Source) [Prosys-OPC-UA-Java-SDK-Client-Server-Binary-1.4.6-8021.jar:1.4.6.8021]
at com.prosysopc.ua.client.UaClient$a.run(Unknown Source) [Prosys-OPC-UA-Java-SDK-Client-Server-Binary-1.4.6-8021.jar:1.4.6.8021]
at java.lang.Thread.run(Thread.java:724) [na:1.7.0_40]
For the mock-server, the relevant address space paths for the specific event, MyEvent, is as follows:
Address space path | Class type | contains EventNotifierClass.SubscribeToEvents
——————————————————————————————–
/Objects/Devices/MyEvent | com.prosysopc.ua.client.nodes.UaObjectImpl | true
/Objects/Devices/Device1 | com.prosysopc.ua.client.nodes.UaObjectImpl | false
/Objects/Devices | com.prosysopc.ua.client.nodes.UaFolder | true
/Objects/Server | com.prosysopc.ua.client.nodes.UaObjectImpl | true
/Objects | com.prosysopc.ua.client.nodes.UaFolder | false
For the production server, the relevant address space paths for the specific event, MyEvent, is as follows:
Address space path | Class type | contains EventNotifierClass.SubscribeToEvents
——————————————————————————————-
/Objects/Devices/Device1/MyEvent/MyEvent | com.prosysopc.ua.client.nodes.UaObjectTypeImpl | N/A (Not a UaObject)
/Objects/Devices/Device1/MyEvent | com.prosysopc.ua.client.nodes.UaObjectImpl | true
/Objects/Devices/Device1 | com.prosysopc.ua.client.nodes.UaFolder | false
/Objects/Devices | com.prosysopc.ua.client.nodes.UaFolder | false
/Objects | com.prosysopc.ua.client.nodes.UaFolder | false
/Objects/Server | com.prosysopc.ua.client.nodes.UaObjectImpl | false
I guess the extra level of MyEvent should not directly be a problem. However, would it be a problem that /Objects/Devices/Device1/MyEvent/MyEvent is of type UaObjectTypeImpl, and therefore does not contain EventNotifierClass.SubscribeToEvents?
13:27, EET
December 21, 2011
13:30, EET
December 21, 2011
9:28, EET
October 4, 2013
Thanks! After hours of stumbling around in Wireshark we figured the server actually sent events as DataChangeNotifications. The problem is now fixed at the server-side.
However, we are now facing a new challenge. The server sends the event as an extension object. In the usual callback for event data:
…
}
eventFields now contains a single item of type ExtensionObject (instead of each field represented as an item of a primitive type). How do we decode this data? Is the following blog post representative for how this should be done?
– http://www.prosysopc.com/blog/2012/07/12/otso/using-complex-datatypes/
As far as I understand, in the blog post the serializer is setup at both the server- and client-side. In our case, we have no control over the server, and it does not use the Prosys SDK, will this be a problem? Are we still able to use the same approach on the client-side? Is the approach in the blog post the only way to handle extension objects in the Prosys SDK?
Moreover, we experience the following stack trace right before the onEvent() callback:
org.opcfoundation.ua.encoding.DecodingException: Bad_DecodingError (code=0x80070000, description="Cannot decode null")
at org.opcfoundation.ua.encoding.utils.SerializerComposition.getEncodeable(Unknown Source) [opc.ua.stack-1.01.330.14.jar:1.01.330.14]
at org.opcfoundation.ua.builtintypes.ExtensionObject.decode(Unknown Source) [opc.ua.stack-1.01.330.14.jar:1.01.330.14]
at org.opcfoundation.ua.builtintypes.ExtensionObject.decode(Unknown Source) [opc.ua.stack-1.01.330.14.jar:1.01.330.14]
at org.opcfoundation.ua.builtintypes.Variant.<init>(Unknown Source) [opc.ua.stack-1.01.330.14.jar:1.01.330.14]
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getVariant(Unknown Source) [opc.ua.stack-1.01.330.14.jar:1.01.330.14]
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getVariantArray(Unknown Source) [opc.ua.stack-1.01.330.14.jar:1.01.330.14]
at org.opcfoundation.ua.core.EncodeableSerializer$179.getEncodeable(Unknown Source) [opc.ua.stack-1.01.330.14.jar:1.01.330.14]
at org.opcfoundation.ua.encoding.utils.AbstractSerializer.getEncodeable(Unknown Source) [opc.ua.stack-1.01.330.14.jar:1.01.330.14]
at org.opcfoundation.ua.encoding.utils.SerializerComposition.getEncodeable(Unknown Source) [opc.ua.stack-1.01.330.14.jar:1.01.330.14]
at org.opcfoundation.ua.encoding.binary.BinaryDecoder.getEncodeableArray(Unknown Source) [opc.ua.stack-1.01.330.14.jar:1.01.330.14]
at org.opcfoundation.ua.core.EncodeableSerializer$178.getEncodeable(Unknown Source) [opc.ua.stack-1.01.330.14.jar:1.01.330.14]
at org.opcfoundation.ua.encoding.utils.AbstractSerializer.getEncodeable(Unknown Source) [opc.ua.stack-1.01.330.14.jar:1.01.330.14]
at org.opcfoundation.ua.encoding.utils.SerializerComposition.getEncodeable(Unknown Source) [opc.ua.stack-1.01.330.14.jar:1.01.330.14]
at org.opcfoundation.ua.builtintypes.ExtensionObject.decode(Unknown Source) [opc.ua.stack-1.01.330.14.jar:1.01.330.14]
at org.opcfoundation.ua.builtintypes.ExtensionObject.decode(Unknown Source) [opc.ua.stack-1.01.330.14.jar:1.01.330.14]
at com.prosysopc.ua.client.Subscription.a(Unknown Source) [prosys-opc-ua-java-sdk-client-server-binary-1.4.8-8731.jar:1.4.8.8731]
at com.prosysopc.ua.client.Subscription.handleNotificationDatas(Unknown Source) [prosys-opc-ua-java-sdk-client-server-binary-1.4.8-8731.jar:1.4.8.8731]
at com.prosysopc.ua.client.UaClient$a.b(Unknown Source) [prosys-opc-ua-java-sdk-client-server-binary-1.4.8-8731.jar:1.4.8.8731]
at com.prosysopc.ua.client.UaClient$a.run(Unknown Source) [prosys-opc-ua-java-sdk-client-server-binary-1.4.8-8731.jar:1.4.8.8731]
9:43, EET
December 21, 2011
9:53, EET
December 21, 2011
Or having another look at the stack trace, maybe the problem is indeed that there is a field that cannot be decoded. However, the server may be encoding all the fields in one ExtensionObject, although it should send them as separate values. Which is not correct. After all, you define in the client which fields you want, and should know that they have known data types, e.g. ‘LocalizedText Message’, etc.
6:17, EET
March 18, 2014
The latter seems to be the case. The event data is returned as one item, the ExtensionObject. The ExtensionObject is marked with the node id of a complex type defined within Types/EventTypes on the server. We have successfully decoded the object by registering a serializer for this type, and “manually” extract the data in the correct order from the BinaryDecoder that is passed into the “getEncodable” method. However, I would expect this to be done automatically by the SDK since the type of the object is known already. Why is this not the case? It appears to my that having to do it this way kind of defeats the purpose of the type definition.
If this is because the event data is not sent as the SDK expects it to, is there some reference to the OPC UA specification that describes the “proper” way of emitting events?
Most Users Ever Online: 1919
Currently Online:
9 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 88
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 732
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1529
Posts: 6471
Newest Members:
susannahdingle7, inilarythikibia, rickykennion, PromotionToold, HypromeImpupe, toneylapham544, rondawolinski7, Marypof5711, roycedelargie91, kourtneyquisenbeModerators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1032, Jimmy Ni: 26, Matti Siponen: 349, Lusetti: 0
Administrators: admin: 1