This tutorial briefly discusses the differences in file structure between Phar Lap, VxWorks and Linux Real-Time and details recommended programming practices for file access to create a seamless customer experience across platforms.

Note: NI will remove support for Phar Lap for cRIO in the NI 2020 Software Release and for PXI in the NI 2022 Software Release. For more information, please see the Phar Lap RT OS EOL Road Map.

File paths and structure vary somewhat depending on the target operating system. This document discusses recommended LabVIEW coding practices for designating file paths so that an application can be moved seamlessly from target to target.
 

Real-Time OS Options

All NI Real-Time controllers run one of three different operating systems; Phar Lap, VxWorks, or NI Linux Real-Time (RT). On a target running the Phar Lap operating system, the file paths work very similarly to Windows file paths with the root directory at C:\ and backslashes as delimiters between directories. VxWorks targets have a Unix style file structure and therefore use forward slashes as delimiters between directories with /c/ as the root directory. However, in LabVIEW the user will notice very little difference between working with Phar Lap file paths and VxWorks file paths. This is because all path constants, controls, and indicators display VxWorks file paths using the same format as Pharlap (or Windows) in LabVIEW. Therefore, when building file paths as recommended in this document, the user shouldn’t notice any difference between working with Phar Lap and working with VxWorks.

On NI Linux Real-Time targets, the root file path is / and forward slashes serve as delimiters between directories. NI Linux Real-Time targets do not have a C drive. However, for convenience, the directories /c and /c/ni-rt exist, and /c/ni-rt/startup redirects to /home/lvuser/natinst/bin which is the recommended path for startup applications on NI Linux Real-Time targets.

The pictures below show simple code for creating a text file called test.txt in the target’s root directory on each real-time target:

Phar Lap

VxWorks

NI Linux Real-Time

Dynamically Built Paths

When dynamically building file paths, NI recommends using a file path constant or control for the root directory and using Build Path VIs with individual path elements (folder of files names) to build the full path as shown below.  This ensures that the correct root directory and slash types are used. The images below show the paths returned when this code is run on different operating systems.

Pharlap and VxWorks

NI Linux Real-Time

Alternatively, relative paths can be built using the location of the deployed VI as a reference. The code below demonstrates how to do this using the Current VI’s Path constant, Strip Path, and Build Path functions. As with the first technique, this also prevents the need for reworking the path if the VI is moved to a controller with a different operating system or to a location with a different file structure. The images below show the paths returned when this code is run on different operating systems.

Pharlap

VxWorks

NI Linux Real-Time

File Path Constants

File path constants and controls dynamically change paths based on target context.  For example, a file path constant containing C:\ when saved for a Pharlap or VxWorks target, will automatically update to /c/ when moved to an NI Linux RT target. File path constants and controls are the preferred method for specifying static paths on Real-Time targets.

However, file path constants will generally be unable to correct invalid file paths. If you type an invalid path into the constant, it may attempt to correct that path for the current operating system, but will probably fail, producing an incorrect result.

Below are a few examples of how the file path constant will correct/attempt to correct the input.

1) The user types /c/Applicaton/SubVIs/Example.vi into the path constant on a Windows machine. The path constant recognizes this as a valid file path for a Linux Real-Time operating system. It successfully corrects it to a Windows style path:

2) The user types \c\Application\SubVIs\Example.vi into a path constant in the Windows context. This is the same path as in Example 1, but with backslashes. This is an invalid file path because it contains slashes that are the wrong direction for Linux RT, but does not start with a drive letter as a Windows style path would. The path constant tries to add in the drive letter as if it were a Windows style path:

3) The user types C:/Application/SubVIs/Example.vi into a path constant in the Windows context. This would be a Windows style path except for the forward slashes. The path constant recognizes that it starts with a drive letter and adds a backwards slash:

The user must be responsible for recognizing when an invalid path has been entered and has therefore been corrected erroneously.

Static File Paths

However, NI does not recommend this option because the String to Path function does not dynamically change the root directory or slash direction when moving between targets. Care must be taken to ensure that any strings converted to file paths contain only the correct slashes for the target operating system.  For example, if your file path string contains backslashes and you try to run the VI on a Linux Real-Time target, the program will fail to locate the correct location on disk. This is because Linux Real-Time fails to recognize the backslash as a delimiter; on NI Linux Real-Time, a file name could contain a backslash in it.

Note: Most real-time targets use letters to indicate different drives. Paths that begin with C are stored on the real-time target’s internal memory. External Compact Flash drives are mapped starting with the first available driver letter after C and external USB hard drives are mapped starting with  U.  

Note: The folder that you specify to write to has to exist on the target drive before you write to it or your VI will not work correctly.
 

File System Permissions