LabVIEW File Types

 

This article describes some key file types supported in LabVIEW

Background

LabVIEW supports a large number of file types for reading and writing data. In addition, through the use of DataPlugins, LabVIEW can read a huge number of file types. These DataPlugins are mostly courtesy of efforts to enable DIAdem to retrieve data from many file types. This article describes some key file types supported in LabVIEW.

Here is a list of supported files found by entering the keyword “file” into the NI Example Finder:

  •      INI (Configuration)
  •      ZIP
  •      Datalog
  •      XML
  •      Binary
  •      ASCII
  •      WAV
  •      XLSX (for waveforms)
  •      Waveforms
  •      LVM
  •      TDM
  •      TDMS
  •      AVI

Note that this list is missing a few common types that are variations on a theme, such as tab-delimited ASCII files. I tried to concentrate on some basic types and share some twists on using these file types in LabVIEW.

DataPlugins

This list contains file types that can be both read and written. Please be aware that there are many file types that can be read (but only some can be written) with LabVIEW via DataPlugins. The DataPlugins are designed to read from the supported file types and then write as TDM type files. More information about using DataPlugins with LabVIEW can be found here: https://www.ni.com/en-us/support/documentation/supplemental/10/using-dataplugins-with-labview.html.

To TDM or Not To TDM?

I’m going to split the files types in the list above into two groups: non-TDM and TDM. Why? Because the TDM file type is special to NI and NI is spending a lot of effort on making TDM more useable. An obvious example is the TDMS type file, which is wonderful for streaming data. And, if you review the files types in the list above, there are a couple subgroups that I’d like to highlight before moving to TDM type files.

Non-TDM Type Files

Reviewing the list of file types, I think they can be grouped into Unstructured, Configuration, Waveform, and Record.

Unstructured

The Unstructured file types are ASCII and Binary. These types accept any type of data, leaving the management of the content completely to the programmer. Anyone not knowing the structure of the file contents typically will have a difficult, if not impossible, job to reverse engineer the file structure.

Besides being hard to interpret without a document of the structure, binary file types can suffer from being machine specific due to the endian of the numbers handled in the CPU. LabVIEW allows control of the endian type in the binary file I/O VIs, so files can be transported across OSs. A similar situation can occur with ASCII files when text needs to be read and written as Unicode, as can happen with non-English languages. ASCII is by definition not Unicode, but you may have to deal with Unicode text someday. This article on reading and writing Unicode characters to ASCII may be interesting to you.

Configuration

The well-known Configuration file types are INI and XML. New to LabVIEW 2013 is JSON, which stands for JavaScript Object Notation. These types are very useful for managing structured information about the configuration of your application, such as startup conditions or the last channel plotted. INI files in the Windows OS have a structure that was defined by Microsoft and consists of “sections” and “properties” within each “section”. An example is:

[Acquisition] Rate=1000
NumberSamples=10000

For LabVIEW programmers, INI type files have generally given way to XML type files. The XML structure is more flexible than INI since it allows general hierarchical structure. The top-most node in an XML file defines other sub-nodes. Each node is an “element” defined by a start and end construct of some specific “tag” and the contents, or properties, between the start tag and end tag. An element can contain either endpoint content or other elements, hence the hierarchical structure. The example of the syntax is:

<Acquisition>
<Rate>1000</Rate>
<NumberSamples>10000</NumberSamples>
</Acquisition>

A complexity allowed in XML, and not in INI, is the idea that a tag can have attributes in the form of a parameter-value pair, such as <Acquisition Rate=”1000″ NumberSamples=”10000″/>. Thus, an XML tag with attributes and no element data is essentially the same as an INI section. Note that other tools have been written for LabVIEW that, in my opinion, do a better job with XML that the built-in tools. Specifically, the LabVIEW flatten and unflatten to XML tools error if the cluster does not match the contents of an XML file created from a prior version of the cluster, as often happens when application versions update configuration information.

Other tools handle these version changes more gracefully. For example, look at the GXML Reference Library from NI. This Reference Lib handles changes in the cluster content if you read into a cluster with additional elements than the XML contains, but errors when the XML has more elements than the receiving cluster. Plus, the label on the cluster needs to match the XML, since the cluster label is part of the XML content. The JKI EasyXML toolkit handles both directions without errors and does not require clusters to have the same label.

Support for JSON is new to LabVIEW 2013, although JSON has been supported in LabVIEW for a while. The JSON VIs follow the simple flatten-to and unflatten-from XML that have been in LabVIEW for a few version. They are located in the ‘Programming >> String >> Flatten/Unflatten String’ palette. JSON is popular because of its support in JAVA. An example follows.

{
“Acquisition”: {
“Rate”:  1000,
“NumberSamples”:  10000,
“ChannelName”:  “Vibration”
}
}

When LabVIEW developers added support for INI files some years ago, the decision was made to make these INI VIs be OS independent. That’s why LabVIEW labels these VIs as Configuration File VIs. And, while the contents of the file are in the proper INI-style Section and Property structure, the data is not formatted precisely correctly for the Windows OS. For example, file paths use the forward slash character rather than the native backward slash.

By the way, other common configuration file types exist that LabVIEW does not (yet?) support, such as YAML.

Waveform

The Waveform file types are WAV, XLSX, LVM, and Waveforms. Of course, the TDM type files can also handle waveforms, but TDM files will be reviewed later.

The WAV file is a standard in the Windows environment and is typically used to store audio waveforms. Don’t use this type of file storage for general waveform file storage since there are better ones, such as the TDM type, especially since WAV files are scaled to +/- 1 and then integerized to either 8- or 16-bits.

The LVM type file is an ASCII file with header information about the waveform(s) prior to the numerical data. This type file is most easily accessed with the Measurement File Express VIs, which take as I/O the LabVIEW Signals type data, commonly associated with the Express VIs. The Waveform type data also works when cast as a Signal.

New to LabVIEW 2103, the ‘Write To Measurement File Express VI’ has the capability of outputting waveform data directly into an XLSX file using the Office Open XML file format. For more info, look here. Note that the ‘Read from Measurement File Express VI’ is not able to read these XLSX files.

The Waveforms type file deals with the LabVIEW Waveform data type. A nice feature of the Waveform data type is the ability to label waveform data with attributes, which are parameter-value pairs. Thus, the file read and write VIs associated with Waveforms allow the management of extra information about the Waveform data. The VIs for managing the attributes are in the ‘Programming >> Waveform’ palette. Note that there are attributes with reserved names used by DAQmx to set values for the acquisition, if the Waveform was acquired via a DAQmx task. See the help entry on the ‘Set Waveform Attribute Function’ VI.

Record

The Record file type is Datalog. I suppose you could stretch and include ZIP too, especially since there’s nowhere else to include it! It is a file of a list of files, after all.

The Datalog type file is nice for managing a list of clusters. For example, suppose an experiment runs over a long sequence of environmental conditions, or a test system measures many parameters on several parts a day. Then, the Datalog record can be a convenient way to catalog the results. Each cluster in the Datalog file is accessible by specifying an index via the ‘Set Datalog Position’ VI. Then the ‘Read Datalog’ VI retrieves the associated record into a cluster, which must be of the same type as was written in the Datalog record. The Datalog file VIs are found under the ‘Programming >> File I/O >> Adv File Funcs >> Datalog’ palette.

These Datalog VIs can also read the records saved into the specified file while operating a VI in the “data logging” mode, activated with the ‘Operate >> Data Logging >> Log …’ menu item on each VI. This mode is sometimes great for debugging fleeting or intermittent bugs.

TDM Type Files

The TDM type files include TDM and TDMS, the ‘S’ means streaming. TDM file contents include descriptive information in a hierarchical format. The ‘root’ is at the top of the hierarchy, with properties defined in parameter-type-value triplets, with type indicating the datatype of the property, such as string or numeric. Next is a list of Channel Groups, each with its own parameter-type-value property triplets. Then, for each Channel Group, a list of Channel properties is available, again as parameter-type-value triplets. Each level of this hierarchy can accept an unlimited number of attributes. Note that LabVIEW includes some pre-defined attributes as well when a TDM type file is created, such as a creation timestamp.

TDM files can be managed with the “Measurement File Express VIs” and the “Storage/DataPlugin” VIs. The former are in the ‘Programming >> File I/O’ palette and the latter are one level down in the ‘Programming >> File I/O >> Storage/DataPlugin’ palette.

TDMS files can be managed with the VIs on the ‘Programming >> File I/O >> TDM Streaming’ palette. A nice feature of TDMS is that it can handle storing waveforms acquired at different rates. For example, you can put all the fast channels in Channel Group “Fast” and the others in Channel Group “Slow”.

TDMS are preferred in many instances because they offer improved performance when writing data to disk. The TDM Streaming type file was designed to stream data to disk at high speeds and with a small disk footprint. If you had to choose one type to use exclusively, choose TDMS, since it has a superset of TDM capabilities.

A nice comparison of TDM vs TDMS files is here.

Finally, since TDM type files have this hierarchy of attributes, search capabilities are available. Waveforms with certain properties and desired values can be located within a single TDM type file. Likewise, searches can be done across many TDM type files to locate a list of files with interesting data. NI provides the NI DataFinder to do such searching, and it is available as a LabVIEW Toolkit and a Server Edition. Of course, you can use the attributes without DataFinder simply by using the appropriate “read attribute” VIs and crawl through the files yourself.

Summary

LabVIEW offers many types of files. Some have been around since the dawn of LabVIEW, such as binary. Others have emerged as LabVIEW and file standards have matured, such as JSON. For more information, look here. If you’re project is getting more complicated than you originally thought and you’d like some help, check out our capabilities and reach out if you want to chat.