Store name-value parameter pairs in TDMS - best practice (and some strange things regarding to TDMS VIs)

[Blokk]

Hello,

I recently play a bit with TDMS files, because I need to store lots of measurement settings and results in such file. First of all, since I want to make the TDMS human readable as much as possible, I decided not to store measurement settings as "properties", but in Channels, at the different Groups (I will have several Groups, one will contain a 2D array of I32s, all the other Groups settings and measurement results, but mostly as name-value pairs).

I started to play with a test VI, see its snippet here (I also attached the result TDMS file):

Spoiler

I have got several questions, maybe some people can give better ideas for what I want to do, and explain some certain strange things I see and not clear why 🙂

So, the list:

1. So I decided to store the settings and mesurement results as two columns per Group: first column (Channel) is the Name string array, the second are the values. If I have multiple data types, I will use extra Name/Value column pairs. The reason is that, this is more "human readable" than using the "TDMS Set Properties" and see the values there. Moreover, there is a recent bug(?) (still in LV 2017 SP1): when the user imports the TDMS file into Excel/DIAdem, the special characters are overwritten by "_" character! This can cause problems, like this: https://forums.ni.com/t5/DIAdem/Character-replacement-in-custom-property-names-results-in/m-p/332945...
2. I can easily read out a single Property value using the "TDMS Get Properties" VI, see the snippet, last step. However, when I try to get all the Properties for a certain Group (see the step before the last), I see a strange behavior: my VI runs happily without any inputs (except the ref, Group name, and error in), and gives me the Property names of the Group and values as a Variant. Should I use it this way, and convert the Variants as I know the expected data types???
3. When you drop a "TDMS Get Properties" VI on your BD, the "data type" input appears as a string. This is contradictory with the isomorphic nature of these VIs: it should show up as a variant, no? At least, this is the case for the TDMS Read.vi ! See screenshots below:

[Hooovahh]

Crap, I typed a long reply and NI lost it some how.  Checkout my XLSX conversion which can have custom things done for properties so they are more human readable.  Run the batch demo in it to see.  As for 2, and 3 I agree. With 2 I'd iterate over all properties with a for loop, but I'd expect it to work or return an error.  And 3 would be more intuitive if it was a variant.

[Blokk]

Thanks much! I will check out this conversion tool tomorrow, looks very useful! 🙂

[Intaris]

AFAIK, wiring up to read a single property of a TDMS file (wiring Property Name, Group and Channel) allows you to specify a datatype via the "Datatype" input and it will return a single element of that type, not variant.

I can't remember how it behaves when returning multiple properties, I suppose it always defaults to Variant there.