Change in Ctrl.Val.Get or Binary write format from LV8.5 to 2014

[cbudtz]

Hi,

I recently upgraded from LV8.5 to 2014 and have run into a backward compatability issue. I have used the Crl.Val.Get All Method to get an array of values and save them to a binary file:

to read them later with a binary read:

My problem is that files generated in this way with LV2014 (64bit) cannot be read by LV8.5 (32bit) - it results in either a "LabVIEW:  Unflatten or byte stream read operation failed due to corrupt, unexpected, or truncated data" error or an application crash.

Has the write binary file VI changed from LV8.5 ro 2014? Is this a 32/64 bit problem? Oddly enough LV2014 reads files generated with LV8.5 without issue. Is there a way for me to program this in LV2014 to ensure backward compatability with LV8.5 (something I will need for a prolonged transitional period).

Regards,

Casper

[GerdW]

Hi cbudtz,

the problem here is probably some change in the cluster structure/definition. When saving clusters LabVIEW also has to save some internal information on the cluster structure - and that information is subject to change with each LabVIEW generation…

Doing such a big jump from 8.5 to 2014 will be sensitive to such internal changes!

[crossrulz]

The variant is what has changed over the years.  When you get the control values, they are as variants.  And since that structure has changed over the years, you lost backwards compatibility.  The LabVIEW version is actually saved as part of the variant, so newer versions of LabVIEW can read the older version of the variant.

[cbudtz]

So I guess I can pretty much forget about creating a backward compatible version?

[Sam_Sharp · Accepted solution]

Pretty much, unless you define the binary file format exactly (e.g. define how you store the data in the file down to the byte level) I would be dubious about the file being readable in newer/older versions of LabVIEW - particularly when using complex data types like clusters.

For dealing with backwards compatibility I would either define the binary file format and work to that or use a string based file format (e.g. JSON, XML, INI) for which you can write a parser which is forwards/backwards compatible. The OpenG library has VIs for saving/loading a VI's front panel controls to an INI file, for example (even if OpenG stop supporting it, it's a string based format so you can always write your own parser if you have to in future). I know that doesn't help you in your current situation but maybe something to bear in mind for the future.

[cbudtz]

Thanks. Using the OpenG INI file solution is a good idea. Sadly, the amount of data in my case is so vast that this takes about 30 secs where the "dirty"  version I use is instant. 

Thanks everyone for your input!!

[crossrulz]

Since you are already using OpenG, why not just use the Write Panel To INI VI and its counterpart, Read Panel From INI.