Simple File Output in LabVIEW
The scope of this article shows one method of writing data to a file using LabVIEW software, and when this type of data acquisition and recording is appropriate.
LabVIEW by NI is useful as a data acquisition tool. As such, it is available for writing data to the file continuously, collecting data, and recording it directly to text. While files can be read into a LabVIEW virtual instruments (VI), the most common course of action is recording data and writing it to a file, rather than reading a file and inputting data into LabVIEW. Even so, some VIs are written so that a configuration file is read and parameters are changed based on data from a file.
Choosing a File Type
Files can be written in several formats while using LabVIEW. The three most common include binary, technical data management streaming (TDMS), and ASCII.
Figure 1. A comparison of file formats. Image used courtesy of NI
Binary files are efficient in terms of space and can be written quickly to a file. For large data sets, this is a real advantage. However, binary files are not human-readable, and so quick error checking is not convenient.
TDMS files are binary-based, but are searchable like a database, and exchangeable among platforms. TDMS is an NI file format, so it is built into certain LabVIEW packages, though some functions might require an add-on module or tool kit.
ASCII files are human-readable, exchangeable between platforms, and relatively simple to implement. They are not the most efficient for space usage or file writing speed, so their use should be limited to lower sampling rates (under 10 Hz) and shorter times (scale of hours or days). However, it is nice to view the data with a simple text viewer, or have the files imported into a spreadsheet program without any complicated data conversion.
Figure 2. A *.csv file generated from a LabVIEW VI.
The most common ASCII data files are comma-separated-values, or *.csv files. The data in these files is separated (delimited) by a comma, and most spreadsheet programs will interpret the commas as different columns of data.
Using File Commands
Files must be opened, written to, and then closed in that order. Based on this format, a typical VI will open a file once, write to it many times, then close it once. Therefore, the open and close operations should be outside the loop, and the write-to-file operation should be placed inside the loop. All of the file writing tools are found in the functions palette under “File I/O.”
Figure 3. A simple file-writing routine opens the file and records the loop iteration and knob position every time the loop executes.
In figure 3, when the stop button is pressed, the file closes. Numbers are converted to strings and then concatenated into one big string for each loop iteration. The “open file” function must be configured for use. The top left terminal can either be hardwired to a filename or, if left blank, will ask the operator for a file name when the VI runs.
The next important option is choosing whether the file will be opened, created, or both. The default option is to open the file, so if the file does not exist, this will throw an error. To choose how this open file behaves, right-click on the second terminal down on the left-hand side and choose “create constant.” The most versatile option is “open or create,” which forces the VI to create a new file if it does not already exist.
Figure 4. This open file function will ask the operator for a file.
As mentioned, the operator will either select a file or type in a file name where the data will be saved. The top-right wire contains a file number that must be wired to each file function afterward, and the bottom-right wire contains an error cluster that can handle any errors that occur throughout the VI.
Write To File
The write-to-file function will accept the file number from the open file, as well as the error cluster. It also accepts a string input that will be written to the file.
Figure 5. The write to file function.
The close file function is simple in its configuration. It requires only the “refnum” terminal to be wired. This way, it knows which file needs to be closed. Wiring the error cluster to the “error in” terminal is also a good programming practice.
Figure 6. The close file function releases the memory used by the file writing routine.
Building a Usable Text String
The caveat to writing a text string is that everything must be formatted into a string data type. The first step is to convert all numerics into a string. To perform this function, use the fractional number to string converter, found in the functions palette, under strings, then number to string.
The numeric input is accepted at the top-left terminal, and the center-right terminal is where the string is outputted. The other two terminals can specify the number of places after the decimal point, or the overall width of the string created.
Figure 7. The fractional number to string converts the double-precision floating-point number from the knob into a string.
The concatenate function is simply an addition tool for strings. The strings will be added together in the order they are placed (top to bottom) in the concatenate function. However, the programmer should place a delimiter between each string to delimit between data, which will show up as different columns in spreadsheet software. This could be a tab, space, or comma (the most common).
Figure 8. This concatenate function inputs data from the two fractional number to strings, separated by a comma. The last character is an “end of line” constant.
After all of the strings have been wired to the concatenate function, place an “end of line” constant as the final string. This will drop the cursor to the next line for the next loop iteration. Without it, the data won’t be arranged in neat columns.
While this is not the only way to write data to a file, it is a good way to get set up quickly. This method is easy to set up and troubleshoot. The data is written at every loop execution, meaning data loss is minimal in the event of a computer crash, power outage, or other data interruption.