NI_DataType vs Datatype properties

[bienieck]

What is the difference between NI_DataType and Datatype properties?

Thanks to Excel Importer I can check the Datatype properties and see e.g. that my channel is of type DT_DOUBLE.

However, when I try to read this property it can't be found.

I need to create the tool in LabVIEW which loads TDMS file, alter it and then save it preserving the original file structure (data types). Now I'm a bit confused about what property should be used to accomplish my task.

I have two groups: One with waveform channels and second with numeric channels. If I read waveform channel NI_DataType I'm getting 10 (which can represent DBL, Analog waveform or Dynamic data). If I read my numeric channel NI_DataType I'm getting 0 which is not correct.

Excel returns DT_DOUBLE Datatype property for both channels.

So how to properly determine the data type?

[bienieck]

In the attachement, you can see the example showing the weird behavior.

[bienieck · Accepted solution]

I have got some unofficial response from support. So in case, someone in the future will face the same problem, here are some useful pieces of information.

NI_DataType is a virtual property, evaluated based on the channel data, specific to LabVIEW and it is loosely coupled to the Datatype property of the TDMS channel object. The value is an integer that corresponds to a LabVIEW type code and is READ ONLY - basically, it is a descriptor of the data within a channel and it is set based on the data which are written into a channel. This implies that it will always be found, for all of the defined channels, and that's why NI_DataType was always present in my example (TDMS_Test.zip). Whether or not it will return a valid datatype value, will depend on whether or not the respective channel was initialized. The reason why uninitialized arrays also sometimes work is unknown. For some data types, it works for some not. The array of strings is an example which does not work and that's one of the visible inconsistencies (see TDMS Test2.vi).

So one might use NI_DataType to create data converter however, the problem is that there are some inconsistencies regarding the datatype codes returned by the TDMS Get Properties function and the LabVIEW codes. This can be seen in the TDMS Test.vi. We can clearly see inconsistent type descriptors. This problem was supposedly escalated to R&D.

About the Datatype property:

NI Diadem does not use the same TDMS API as LabVIEW. DIAdem/TDMS DataPlugin expose this information through other API members and there are differences between the LabVIEW and the Diadem metadata stored within a .tdms file. If I open the "File0.tdms" (TDMS_Test.zip) in Diadem and if I check both the Base or the Extended Properties of the channel, there is no "datatype" property. It is created in the background by the Diadem TDMS API as an auxiliary property to store the information about channel datatype however, it is not meant to be "visible".

This is a poor idea IMO. I thought that the power of NI is a "platform approach", in the sense that all the tools are compatible and the exchange of data is transparent/natural. This case shows it's not true because it seems that the proper tool for data exchange between LabVIEW and DIAdem does not exist (yet?).

[doyles]

I know this is an old thread, I'm primarily adding this post for future viewers, not a resurrection.  Your TDMS Test.vi and the TDMS Test2.vi both work for all the included data types if you add a TDMS Flush in between the TDMS Write and the TDMS Get Properties - with the exception of the empty string array in TDMS Test2.vi. 

All types work when the Build Array is used within the TDMS Test.vi, just not an empty string array constant.

I attached the updated TDMS Test.vi

[Sastry]

I didnt see any difference. For boolean it was still incorrect. Can you provide some screenshots?