TDMS Set Properties - allow saving Cluster (Variant) data type

[Blokk]

Motivation: in my recent project I have got a request from the end user that it would be nice to store configuration data in the same TDMS file where we store measurement results. Of course, we can create this feature programmatically, like we parse through the typdef cluster, using label names and different data types, we can create a kind of API for a TDMS Cluster read/write. However, it is difficult to make it generic, and this is an extra work anyway.

So it would be nice to save my complex Typdef cluster into TDMS, where I store measurement results in a user readable manner (via the Excel plugin) inside different groups and channels. The stored configuration cluster does NOT need to be user readable!

Since TDMS does not have this feature, as a dirty and simple workaround, I will always produce two files during measurement/data processing sequences: a TDMS, and an INI file (via the OpenG Write INI Cluster), then programmatically ZIP them into a single file for data backup (for future reference, it is safer this way).

Would not be nice if we could just write a Typdef cluster to and read from a TDMS file directly?

Like what we can do with the OpenG Read/Write INI Cluster VIs. I understand there is a strong reason why TDMS files limit the data types we can write to them, and it is not allowed to use undefined data sizes, like Variants, strings. Well, we can write strings to TDMS files, but there are some issues/difficulties with this approach if we want to go through a Typedef Cluster->String->TDMS file storing route. Hoovahh had a post about these challenges 2 years ago, where he mentioned he might make it into an Idea, but I could not find it in this forum board, so I make it an Idea: https://forums.ni.com/t5/LabVIEW/Read-Write-Variant-to-TDMS/m-p/3334203 

I imagine, NI could implement such feature into TDMS in a similar way, like there would be an "internal part" of the TDMS file where the Cluster is stored as a Variant in binary format. I do not know how the internal things work in a TDMS file, but I imagine such new feature implemented as an extra data type for the TDMS Set Properties would not hurt the speed performance of the Group/Channel level things...?

[Hooovahh]

For those that like this idea, there is a solution involving VIMs that I posted here, but I am a fan of NI expanding more TDMS functionality.

[cbutcher]

I had some luck using the Flatten to XML nodes - is the difficulty you're referencing to do with needing to keep the typedef? Perhaps you could store the path in the TDMS file too and load the typedef for the unflattening, but that makes you dependent on having the same path to the typedef on any computers you use. With relative paths, it might be ok? (Probably I've forgotten something obvious).

I initially tried to do this with the Flatten to String, or Variant to Flattened String nodes - both gave me corrupted data... Not sure why, but maybe that was the problem you mentioned.

[bean123]

I know there was an OpenG VI llb that would take any input and flatten it out to TDMS properties:

OpenG Variant to TDMS (older version)

I modified this slightly and have used it in various projects with pretty good success, but I haven't looked at in 5 years or so.  I agree a native solution would be better.  

pm me if you want my modifications of the llb