How to store custom properties in tdms to be able search them in diadem?

[Andras Ferencz]

Hi,

I have stored some custom properties in tdms files like UUTSerialnumber, Operator and so on.

I can see them on the top of the top of the data portal only. If multiple files are loaded I cannot see these properties only for the first one.

What do I do wrong?

I would like to select certain channels which are associated to the specific UUTSerialnumber and Operator and made prior to a specific date for instance.

Any advice or example would help,

Thanks,

Andras

[Walter_Rick]

Hello Andras,

The TDM model provides three different levels to store user specific comments (properties) together with the data: the root (or file) level, the channel group level and the channel level. Of course it is up to you which information you store on which level. But in practice it seems to be useful to use the different level as follows:

On root level you typical store more global and rare used information like a brief description. Please keep in mind that only the root properties of the first file can be loaded directly.

On channel group level it is helpful to store all global measurement specific information like UUT, Operator and environmental temperature. If you load a file or a selected channel group all the group properties will be loaded.

On channel level you can store channel specific information like the sensor type or the calibration date of this sensor. Every time a channel will be imported all its properties are loaded.

But after all it depends on the application and/or your own favor which property you store on which level.

Greetings
Walter

[Andras Ferencz]

Thank you Walter,

Which one do you think it is more practical?

Put general properties in one of the groups that actually contains measured values or create a separate group for these global properties?

Could you explain the drawbacks for each?

Thanks again,

Andras

[Walter_Rick]

Hi Andras,

It is not possible to give a general recommendation - it's more depending on the application and your own favors. In example if you often compare channels from different files and you need the global properties then it is useful to store them on each group. The advantage is that you can load all necessary channel groups and all information's are available directly.

On the other site, if you have lots of channel groups and tons of global properties it could be a good idea to have a channel group used only to manage the global properties which are the same for all groups. And only the properties which are different are stored group specific.

Both cases have assets and drawbacks. The first case is more flexible for the DataFinder and the second case saves more disk space. If you are using the DataFinder to find certain channels it could make sense to have the same properties several times on each group because the DataFinder currently links each query with "and". Example:

Group property A = XY
Channel property B = AZ

That means find all channel groups with a property A = XY ÁND all channels in this group with property B = AZ

Greetings
Walter

[JeffGrimes]

Only being able to identify 1 file-level, and showing the properties of only the first File loaded just doesn't make any sense.  This essentially limits the user to two real levels of traceability.

For arguments sake, I want to compare the results of two different data sets.  One was produced on a test stand, with UUT A, and its associated channel list.  The second, produced on a CAE workstation represented UUT B, and its associated channel list.

Two test procedures, Two UUTs, and the same channels for both.

Based on what's described here, there is little to no use for the "File level" Properties, right?  I'm forced to do the properties at the GROUP level, because the File-level properties default to those of whichever file is loaded into the portal first (i.e. the CAE file or test stand file). 

This forces the file properites to be so generic as to be USELESS, does it not?  meaning TDMS only provides two levels of abstraction, and not three as advertised.

[Brad_Turpin]

Hi Jeff,

I agree that the only-one-file-level-property-display limitation in DIAdem is very frustrating, but it's not likely to go away any time soon.  Note that LabVIEW does NOT share this problem, since each file opened becomes an opened file reference, and you can read off file properties from any file reference you want at any time.  Note that the DataFinder aIso does NOT share this problem.  You can query file properties with perfect accuracy in the DataFinder.  The only rub is when you load multiple files into DIAdem.

You do have the ability to programmatically retrieve the file properties from loaded channels in the Data Portal, but you will not see those properties in the Data Portal, and you will also not be able to directly reference the properties of the second or third file in REPORT layouts.  Let me know if you are interested in looking into how to programmatically dig out the file properties from loaded Data Portal channels.

In practice I usually bite the bullet and duplicate the global information as identical properties in all of the Groups.  If my users are timid, I often also duplicate them on the file level as well, since the simple search in the DataFinder only displays properties from the file level, and since the file level is the default level when specifying conditions in the advanced search.

I would NOT recommend creating a group that only contains global properties-- this makes it impossible to use those properties in DataFinder queries.

Ask as you have further questions,
Brad Turpin
DIAdem Product Support Engineer
National Instruments

[JeffGrimes]

Thanks, Brad.  Good to know they're still searched on.  Not good, that they can't be referenced in custom reports, though.  Have you had success programmatically accessing them, and utilizing them in reports?  Duplicating is possible...I'll have to play around with it some before I can fully grasp the report generation issues that result.

Our file sizes are large enough as it is, I'd hate to be duplicating all that meta-data.

Jeff

[Brad_Turpin]

Hi Jeff,

If you have channels (arrays) of acquired data values, then you can pretty much ignore the descriptive properties' contribution to the file size.  Some customers have ONLY descriptive properties or predominantly descriptive properties with channel lengths of 10 or so values, but if you're not one of them it's very unlikely that duplicating your file properties at each group is going to significantly increase your file size.  Still, that's your call.

For data loaded into the Data Portal the file path information is stored at each channel in the following two properties:

Display name in Data Portal          Programming name          Example
-----------------------------------------          ----------------------------          ------------------------
"Source file"                                 "sourcedatafilename"        "EXAMPLE.TDM"
"Source file path"                          "sourcedatafilepath"          "C:\Data\"

In a VBScript, you can retrieve the parent file path of a given channel and then query that file's properties (if it's still in the same location) by creating a DataFileHeader object from that file path:

Set oMyDataFileHeader = DataFileHeaderAccess("C:\Data\EXAMPLE.TDM", "TDM", False)

In order for these properties to show up in a report, you would then need to set report variables in the VBScript, or save the file properties you retrieved from the DataFileHeader object to new file or group or channel properties in the Data Portal, then reference those in the report layout.

Ask if you have further questions,
Brad Turpin
DIAdem Product Support Engineer
National Instruments