Format of the variant in binary file

[andrej]

Hi,

I would like to read waveform, that is saved in binary file (using Write to binary file.vi), with other programming language. I was able to read timestamp, dt and Y of the waveform cluster, but I do not know how to read attributes (variant type). I used information on http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/how_labview_stores_data_in_memory/ to determine the format of the file, but there is to little information on variant format and I do not know how variant is formatted. Any suggestions?

Thanks,

andrej

[srikrishnaNF]

Hi Andrej,

  A waveform data type by default contains the attributes field which will be variant..You can extract /format that variant using the "variant to data" function..

Regards,

SrikrishnaNF

[andrej]

SrikrishnaNF,

this is in case if i will be using labview to read binary file, but i am using other programing language and I would like to know the binary format of the variant.

[srikrishnaNF]

Hi Andrej,

  Can you tell me which language are you using to read the cluster?May be you can create a dll using LabVIEW to read the cluster and use it in your programming language.

Regards,

Srikrishna.J

[andrej]

Currently I am using C#, but I will use also other languages in the future. I am aware that I can create dll using Labview, but I would like to have the binary format of the variant in memory (or in binary file), like it is specified for other types in http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/how_labview_stores_data_in_memory/. I think that I saw the thread in which the format of the waveform in memory (or in binary file) was described, but I can not find it.

[Pete.Dunc]

Hi andrej,

Having a look at the hex for an arbitrary waveform.. you have the cluster data stored in order.  The timestamp (I64 and U64), dt (double precision numeric) and Y (array of double precision numerics) - from your description it sounds that you have been able to extract this information successfully.

Following this you will have the variant data.  Having a look at an arbitrary waveform this data will appear similarly to the following:

0012 0080 0400 0000 0100 0E40 30FF FFFF FF04 6E61 6D65 0000 0100 0000 0000 0453 696E 6500 0000 0000 0000 144E 495F 4578 7049 7352 656C 6174 6976 6554 696D 6512 0080 0400 0000 0100 0400 2100 0100 0000 0000 0000 0000 0014 4E49 5F45 7870 5374 6172 7454 696D 6553 7461 6D70 1200 8004 0000 0001 0010 4054 0006 0954 696D 6573 7461 6D70 0001 0000 0000 0000 CC46 A014 09EB F800 0000 0000 0000 0000 0000 000F 4E49 5F45 7870 5469 6D65 5374 616D 7012 0080 0400 0000 0100 1040 5400 0609 5469 6D65 7374 616D 7000 0100 0000 0000 00CC 46A0 1409 EBF8 0000 0000 0000 0000 0000 0000 104E 495F 4578 7058 4469 6D65 6E73 696F 6E12 0080 0400 0000 0100 0E40 30FF FFFF FF04 6E61 6D65 0000 0100 0000 0000 0174 0000 0000 

The sections in bold appear to be common to each attribute (my waveform has 5 attributes) - the bytes which follow again appear to map to type descriptors for data - you could potentially map the descriptor to a data type, which will tell you how many bytes to read, and how to interpret them.

It would be easier (rather than manually specify each type descriptor) to use the functions in LabVIEW and wrap in a DLL as per the previous post 🙂

[andrej]

Thanks for all help.

I would still like to know how to interpret the variant data. Here is an example of the string "ABC" converted to variant that gives the hex output "1100 8008 0000 0001 0008 0030 FFFF FFFF 0001 0000 0000 0003 4142 4300 0000 00" (source code is below). The same sequence of bytes also appears in waveform for the attributes variable.

I was able to decode that:

0008 0030 is length and type descriptor for the string

FFFF FFFF is length of the data which is of variable length

0001 is number of type descriptors types

0000 is index of the type being used

0000 0003 is the length of the string

4142 43 is string data ("ABC")

But I am not able to decode:

1100 8008 0000 0001 - at the start

00 0000 00 - at the end (it is probably padding)

[Pete.Dunc]

Hi andrej,

After some further investigation I think we are getting closer.  By testing multiple strings we can start to see how this data is stored on disc..  take a look at the attached spreadsheet and example.  Feel free to extend this test to further data types as needed - the "?" section are the codes which I am not entirely sure of - however they are consistent between all strings (and the data can still be read back).

These values can be seen using the Variant to Flattened String function - although it is not clear (to me at this point ) just exactly what they refer to.

[rolfk]

Actually the type descriptor length does normally include the two bytes for itself. So your length indication would slide 2 bytes to the front. The question mark section is the control name as Pascal string and a typedescriptor is alwasy padded to an even number of bytes. xx are internal flags that indicate if it is a control or indicator, etc.

[andrej]

I added additional cases to the file That Peter prepared. The only think that I can not decode is what are the 9 bytes in waveform that are after Y array bytes and before attributes bytes.

110080080000000100060054000B00010000000000009876D1A3C28F5C28F5C28F53F50624DD2F1A9FC0000000105000000000000000000110080080000000100080030FFFFFFFF00010000000000034142430000000000000000

green - Y array length (00000001) and data (05)

red - unknown

blue - start of the attribute section (variant pointer)