Oh, I see.

There are 2 options (I haven't actually tried them, but the principles should work):

1) You need to "tell" the compiler that it is dealing with an ExtensionObject, by typecasting the received value to Opc.Ua.ExtensionObject, and then you will get the data from its Body property. In order to make the type cast, however, you will need to reference the Opc.Ua.Core assembly, and here is where the necessity to select the installation of Embedded Assemblies comes to play. And, as a third execution step, you will need to type cast the value from Body to Byte[], because Body is an 'object'.

2) Or, you can do an equivalent of that, but without referencing the Opc.Ua.Core assembly, using .NET reflection: locate the "Body" property getter on the received value, and invoke it.


( A third option, for VB users only: It will probably work, with late binding, by simply accessing .Body property, because VB is not strong-typed as C#).

Regards

OK, then the 10 bytes are 4 bytes for each of the Float fields, and 2 bytes for the Int16 field.

According to OPC UA spec Part 6,

All floating point values shall be encoded with the appropriate X200 : ITU-T X.200 – Open
Systems Interconnection – Basic Reference Model
www.itu.int/rec/T-REC-X.200-199407-I/en

and

All integer types shall be encoded as little endian values where the least significant byte
appears first in the stream.

With .NET class BitConverter (msdn.microsoft.com/en-us/library/system.bitconverter(v=vs.110).aspx) and methods like ToSingle() and ToInt16(), it shouldn't be too difficult to decode it.

Please post the XML description here.

You will need to read in, or otherwise obtain from the server side, the actual XML that described the data type. Having that, use OPC UA Spec Part 3 Annex 3, and Part 6 Mappings, to decode.

I should add one more things: If you only have one, or a handful of data types you need to deal with, and you need them upfront (i.e. you are connecting to an OPC server/configuration that you know), the recommended steps can be made much easier (and you wouldn't even need the extra assemblies).

Let's say you are dealing with one custom data type, which is represented by 10 bytes inside the ExtensionObject. As part of you development (i.e. not directly in the program you are writing), you can read the DataType and determine the DataTypeDescription using my hints - but just once, manually. You will end up with an XML fragment that describes the fields of the custom data type. You will then write a custom decoding algorithm (into the actual project you are developing) that would take these 10 bytes and interpret them accordingly to the data type description - that should be just couple of lines of code. If you have just one data type or a handful of them, this approach is *much* simpler than trying to write a generic solution, which is what I assumed in my hints.

Best regards