11-14-2017 09:04 AM
Just like variants I guess, Waveforms flattened to string (they containt attributes as variants so...) are not backwards compatible with previous versions of LabVIEW 😞
Now, I have a software made in LabVIEW 2015 that I do not want to change...which expects to be able to unflatten a 2D array of waveforms...This works when the waveforms it receives was flattened in LabVIEW 2015 as well, but now I need it to receive data from an application that has to be made in LabVIEW 2017...Now, I can alter the 2017 version to be backwards compatible *if* there is a way to do so, but is there?
For variants we have the VariantFlattenExp.vi function in vi.lib that will generate a flattened version that is compatible with previous versions, but is there any such thing for waveforms?
11-20-2017 07:01 AM
Hi Mads,
I have included examples of how you can approach your problem. It is possible to use the "Flatten to String" function as this should be compatible with LabVIEW 2015. It is also possible to convert your waveform to a variant, then use the "Variant to Flattened String" function and convert the variant back to a waveform by using the "Variant to Data" function. This is another way that you could transfer the data. The "VariantFlattenExp.vi" function is for LabVIEW 2012 therefore it do not believe that you will require this as you are using LabVIEW 2015 and LabVIEW 2017.
In LabVIEW 2017, you can save your VI to be compatible with another version of LabVIEW by selecting File»Save for Previous Version and navigating to the version of LabVIEW that you require.
Saving for a Previous Version
http://zone.ni.com/reference/en-XX/help/371361N-01/lvhowto/saving_for_the_previous_ve/
Please let me know if this helps.
Kind Regards,
Christian
11-20-2017 08:16 AM - edited 11-20-2017 08:17 AM
Converting the 2017 VI to 2015 is not an option as this is a VI that needs to run in an application which has to be built in 2017 (due to other requirements which exclude 2015).
Secondly the solution with flatten/unflatten does not work when the flattening is done in 2015 (which is a second requirement here), and the unflattening is done in 2017. That is the origin of the question.
Changing the way the flattening is done is not an option (unless this will also be backwards compatible with other 2015 applications which expect the old format too), only how it is handled at the 2017-based receivers (unflattening).
11-20-2017 08:44 AM
The short answer is that you can't. Flatten to string outputs the internal binary representation of the data, which is not guaranteed to be stable between versions, and is in fact one of the things you can rely on not being stable across versions. Instead, you should consider using something more robust to change, like the flatten to XML VI.
11-20-2017 03:32 PM - edited 11-20-2017 03:35 PM
I suspect that they haven’t actually changed the real flattened format between 2015 and 2017 for any of the data types you care about, so you should try flattening in 2017 format, then change the leading 4 bytes from 0x17008000 to 0x1500800, and see if it works in 2015.
Added later>> actually, it’s more tricky because you’re dealing with the embedded ‘attributes’ variant, but you might be able to make it work somehow.
11-21-2017 01:38 AM
"The short answer is that you can't. Flatten to string outputs the internal binary representation of the data, which is not guaranteed to be stable between versions, and is in fact one of the things you can rely on not being stable across versions. Instead, you should consider using something more robust to change, like the flatten to XML VI. "
Sure. I guess I have just grown accustomed to expecting that NI will provide mostly seamless compatibility, or at least workarounds for compatibility between versions of their own product (and its special data types, like the waveform). As they have done for variants with the mentioned VI for example...Luckily this is the only place I've run into this issue.
11-21-2017 06:53 AM
NI does do as you say for certain utilities that are designed for this sort of thing. TDMS, for example, gives you the speed of binary with the backwards compatibility you might expect. The problem is that people abuse things like Flatten to String without truly understanding the limitations of the output, then complain when those exact limitations come back to bite them.