TDM (TDMS) files for Configuration info?

[dthomson]

I was wondering if anyone had tried using TDM or TDMS files for reading and writing configuration information. My current solution is a variation on the NI Config File VI's. This provides a human-readable (and editable) file that can easily support newly-defined values as a project evolves. It has difficultities with arrays, and structures (clusters) must be parsed out rather tediously.

I haven't played with TDMS files much, but it seems like this API would provide an easy way to create flexible files. It would lose the human-readable aspect (which could be an advantage), but would maintain the flexibility of allowing new variables (properties) as the project changes. Arrays would be easier too, since it directly supports them as channels. (Well, at least flat arrays of numbers.) Clusters would still have to be parsed apart. One potential problem is that I don't see a TDMS VI for listing what properties are in a file. I think you can list channels and groups, but I don't see how to get a list of properties programmatically. That probably wouldn't be a huge issue for configuration files, but it would be a nice option. (Maybe it is there but I just haven't found it yet.)

I am aware of the OpenG Variant solution, and would be interested in opinions on how it compares as well. Or other solutions you might be using.

Regards,

Dave T.

[Ton Plomp]

I think you can list channels and groups, but I don't see how to get a list of properties programmatically. That probably wouldn't be a huge issue for configuration files, but it would be a nice option. (Maybe it is there but I just haven't found it yet.)

Yes there is, use TDMS Get Properties, from the help:

property name indicates which property to return the property values of. If this input remains unwired, the function returns the property values for the specified group name, channel name, or the entire .tdms file.

Ton

[Neville D]

I was wondering if anyone had tried using TDM or TDMS files for reading and writing configuration information. My current solution is a variation on the NI Config File VI's. This provides a human-readable (and editable) file that can easily support newly-defined values as a project evolves. It has difficultities with arrays, and structures (clusters) must be parsed out rather tediously.

I haven't played with TDMS files much, but it seems like this API would provide an easy way to create flexible files. It would lose the human-readable aspect (which could be an advantage), but would maintain the flexibility of allowing new variables (properties) as the project changes.

I am aware of the OpenG Variant solution, and would be interested in opinions on how it compares as well. Or other solutions you might be using.

Regards,

Dave T.

Hi Dave,

Why re-invent the wheel? You can use the Read/write to XML file VI's to automatically read/write any LabVIEW structure to file.

I know, I know, people complain it isn't "human readable".. but I really don't understand how text readable you could make a complicated LV structure (cluster of Cluster of arrays of enums for example) without a picture.

The OpenG VI's (when I last tried them) had some issues with LV 8.0 and a complicated structure with type-def'd enums. The exact same VI's worked fine with LV 7.1.x. Don't know if they are fixed, but once I moved to the xml format, I haven't looked back to ini files again.

Neville.

[torekp]

If you use classes and datalogs, as mentioned in this thread, you get the advantage that whenever you add to your list of configuration conditions, you can still read older configuration files. The new items that do not exist in the old files will be assigned their default values, when you read from an older file.