Viewpoint Systems, Inc.
800 West Metro Park
Rochester, NY 14623
Phone: 585.475.9555
Fax: 585.475.9645
Viewpoint Data Management, LLC.
800 West Metro Park
Rochester, NY 14623
Phone: 585.475.9555
Fax: 585.475.9645
Viewpoint News, Summer 2008 LabVIEW has what seems to be an ever growing set of File I/O options. In the early versions of LV, binary and text files were the only options available. With subsequent releases of LV, support for Configuration management and various XML options have appeared.
As of version 8.5, which I will use in this article, LV has built-in tools for the following file types:
The first 2 types have been available for many versions (at least LV 3), but the Datalog option was available only as a way to save\recall control values on a front panel during execution. Text and Spreadsheet were introduced in LV 4. LVM appeared in LV 7, and TDM arrived in 7.1. The ability to read\write Datalog files for arbitrary clusters appeared in LV 8, as did ZIP and XML support.
I’ll assume that the usual binary, text, ZIP, and spreadsheet file types are well known, so let’s focus on the others file types.
Datalog files allow an arbitrary cluster to be written to file in a binary, LV-specific format. Each cluster is termed a record and multiple clusters of the same type can be written to the datalog file created with this cluster type.
This file format is mainly useful only within LV, since the binary content contains header and data type information which LV natively recognizes. Developers using other languages would need to understand LV data types to parse these files.
The Datalog VIs allow specification of the record number so that you can jump around within the file from record to record.
Except for the fact that this is a non-standard filetype, it is very handy since it accommodates any type of structured data with ease.
These VIs are found under ‘Programming >> File I/O >> Advanced File Functions >> Datalog’.

Configuration files are a generalization of the standard Windows INI file type. Just like an INI file, you can write elemental data in a tree formed by Section \ Key information.
A Section can hold many Keys. Each Key is an elemental LV datatype and the options are as illustrated below in the dialog showing the polymorphic options in the ‘Write Key.vi’.

Note that a Configuration file has some differences from an INI file, so beware if you try to use standard INI tools on these files. For example, in a Configuration file, a path appears as: Path=“/C/Temp/temp.txt”, whereas in an INI file it appears as: Path=“C:\Temp\temp.txt”
My recommendation is to use XML instead since it is a superset of the functionality available with Configuration files.
These VIs are found under ‘Programming >> File I/O >> Configuration File VIs’.

LVM files are files that are useful for storing multiple waveforms (or 1-dimensional arrays) along with descriptive information about the data in the file, in general, and each waveform, in particular.
Writing an LVM file is done via the ‘Write to Measurement File’ express VI, the dialog of which is shown below. Note that this dialog also allows the output file type to be TDM or TDMS.

The contents of a sample LVM file are shown below. Note that the LVM is a standard ASCII file.
LabVIEW Measurement
Writer_Version 0.92
Reader_Version 1
Separator Tab
Multi_Headings Yes
X_Columns No
Time_Pref Relative
Operator jac
Description test LVM file
Date 2008/09/01
Time 13:32:47.26115
***End_of_Header***
Channels 4
Samples 3 3 3 3
Date 2008/09/01 2008/09/01 2008/09/01 2008/09/01
Time 13:32:47.26115 13:32:47.26115 13:32:47.26115 13:32:47.26115
X_Dimension Time Time Time Time
X0 0.000000000000E+0 0.000000000000E+0 0.000000000000E+0 0.000000000000E+0
Delta_X 1.000000 1.000000 1.000000 1.000000
***End_of_Header***
X_Value Untitled Untitled 1 Untitled 2 Untitled 3 Comment
1.100000 11.000000 111.000000 1111.000000
2.200000 22.000000 222.000000 2222.000000
3.300000 33.000000 333.000000 3333.000000
The segment holding the data (at the bottom of this file) can be duplicated so that multiple segments can be appended to a single LVM file.
Reading an LVM file is accomplished with the ‘Read from Measurement File’ Express VI, the dialog of which is shown next.

Also note that an LVM file is structured such that it is easily imported into Excel as an ASCII tab-delimited file.
These VIs are found under ‘Programming >> File I/O’.
TDM files originated with DIAdem. You can write to a TDM file using the ‘Write to Measurement File’ Express VI as above, or you can use the Storage Express VIs in the Storage menu palette under File I/O.
The concept of a TDM file is a tree of groups of signals. Each group can hold multiple signals and each TDM file can hold multiple groups. Each signal can have associated descriptive information, some of which is standard and some which is user define. Each group also has descriptive information, some standard and some user defined. Plus, the overall TDM file has descriptive information. Thus, the contents of TDM files are much better defined than many other types. For more information on these descriptors and the overall structure of the TDM file, please visit http://zone.ni.com/devzone/cda/tut/p/id/3727 or http://zone.ni.com/devzone/cda/tut/p/id/3539, where this latter link explains the TDMS streaming version of the TDM file.
When writing a TDM file, two files are created, one with a TDM extension and another with a TDX extension. The TDM file is XML and holds information about the binary TDX file. Thus, the TDM file is a header file and the TDX is the data.
The Storage VIs allow much more flexibility than presented in the ‘Write to Measurement File’ Express VI when the TDM option radio button is selected. For example, you can set group and channel.
Another useful feature of these Storage VIs is their ability to run queries on a TDM file based on search criteria about their descriptors. For example, the following code snippet locates all the channels with minimum values greater than 23.

The channel refnums returned by this ‘Read Data’ Express VI are handles to details about the returned signals. The following configuration dialogs is associated with the ‘Get Properties’ Express VI. Note also that DAQmx properties can be associated with the channel data for acquired data.

Here’s the DAQmx one, with some of the tree expanded showing AI details:

The TDM Storage VIs are found under ‘Programming >> File I/O >> Storage’.

Note that this menu palette has VIs to convert a TDM file to a TDMS file and visa versa. For more information about using the Storage VIs, please visit http://zone.ni.com/devzone/cda/tut/p/id/3538.
TDMS files are essentially the same as TDM files, but they are optimized for streaming, or, in other words, writing to the same files multiple times. In addition, there is a more free-form property-value set and get capability, since you can create group and signal properties with any name and basic data types, including numeric arrays. The acceptable property data types are:
The only downside is that you need to know what types were written so they can be retrieved (the data type is wired into the ‘Get Properties’ VI).
The TDMS Streaming VIs are found under ‘Programming >> File I/O >> TDM Streaming’.

XML files have grown increasingly popular and are seemingly everywhere today. For the typical LV developer, XML files are used as enhanced INI files for managing configuration information. The contents are hierarchical in a tree structure (similar to folders on a harddrive). They are hardly ever used for storing large quantities of data, since they are very verbose relative to raw binary.
A good place to read about XML is http://www.w3schools.com/xml/default.asp. The tree structure is described at http://www.w3schools.com/xml/xml_tree.asp.
The XML File I/O VIs are not in the File I/O menu palette, but instead are in the String palette. (I bet someday they are moved to File I/O.) The standard usage for writing is to convert a piece of LV data to an XML string and then write that string to file with the ‘Write to XML File’ VI. The LV data is converted to XML via the ‘Flatten to XML’ VI which produces a string containing the XML text.
These strings can be concatenated to produce combined XML text similar to the result of bundling the LV data into a cluster prior to the call to ‘Flatten to XML’, but this approach can get you into trouble if you don’t keep track of the location of individual data elements, since they are notated by type and not by name. The best approach in these situations is to apply a cluster bundle prior to writing the data to file. See below for details.
For example, suppose we have a numeric double, a string, and a cluster which contains a numeric and a string. Each individual control can be merged (using the sequence, numeric, string, and cluster) as:
<DBL>
<Name>MyNumber</Name>
<Val>23.00000</Val>
</DBL>
<String>
<Name>MyString</Name>
<Val>Hello World</Val>
</String>
<Cluster>
<Name>MyCluster</Name>
<NumElts>2</NumElts>
<DBL>
<Name>ClusterNumber</Name>
<Val>46.00000</Val>
</DBL>
<String>
<Name>ClusterString</Name>
<Val>Hello World Again</Val>
</String>
</Cluster>
Whereas if you combine the three elements into a cluster first using a cluster bundle (unnamed) prior to passing into ‘Flatten to XML’, the result is:
<Cluster>
<Name></Name>
<NumElts>3</NumElts>
<DBL>
<Name>MyNumber</Name>
<Val>23.00000</Val>
</DBL>
<String>
<Name>MyString</Name>
<Val>Hello World</Val>
</String>
<Cluster>
<Name>MyCluster</Name>
<NumElts>2</NumElts>
<DBL>
<Name>ClusterNumber</Name>
<Val>46.00000</Val>
</DBL>
<String>
<Name>ClusterString</Name>
<Val>Hello World Again</Val>
</String>
</Cluster>
</Cluster>
The only difference is the extra surrounding <Cluster> and </Cluster> pair. This difference is important.
Retrieving data from an XML file does the reverse process: ‘Read from XML File’ VI followed by ‘Unflatten from XML’ VI.
The ‘Read from XML File’ VI has two polymorphic types. The first retrieves the XML as a single string. The second type returns the base level parts in the XML as a string array with each element being a base level item. Use the former type to retrieve the single cluster, use the latter to retrieve the multiple data items when the individual XML string as concatenated into a single string prior to writing.
In either case, the ‘Unflatten from XML’ VI needs to know the exact datatype as input since it fills the data contents from the XML. The names of the individual elements are not used as guidance in the unflattening, even though the names of the LV controls are in the XML content.
NOTE: Beware of numeric roundoff in the XML string. For example, if ‘MyNumber’ in the example above is set to 23.0000000001 in the control, the XML text will not contain that least significant 1 digit.
The XML VIs are found under ‘Programming >> String >> XML’.

This article discusses various File I/O options available in LV 8.5. We have not discussed databases and other file types supported in LV’s toolkits, so there are even more options if the built-in ones are not enough! Certainly, tab-delimited ASCII is here to stay due to its easy portability, but the other file types offer advantages that warrant consideration.
Enjoy!