At its heart, LINX is a hardware abstraction layer that allows you to have a single LabVIEW interface to a variety of different hardware devices. Depending on the device, you can access it in one of two ways: Remote or Local I/O.

Remote I/O works by running LabVIEW VIs on the development PC. In this configuration the LINX VIs send commands to LINX firmware running on a device connected to the development computer by a USB, WiFi, or ethernet connection. These commands tell the firmware to perform pre-defined actions such as reading an analog input or setting a digital output high. Devices that use Remote I/O are arduinos, chipKITs, ESP8266s, and many others. Details on how the protocol works and information on specific commands is available here.

The LINX firmware (source code available here) can be built for many different devices. A list of the currently supported devices and their IDs is available here. A reference to many of the functions in the firmware source code is available here.

Custom commands can be added to the LINX firmware. This is useful if you want to make a new firmware library available for use by LINX. A guide to creating custom commands in the LINX firmware is available here.

Local I/O is used on devices that can execute LabVIEW VIs directly without help from a development PC. Devices that use Local I/O are Linux-based devices like myRIO, Raspberry Pi 2/3, and BeagleBone Black.

In this configuration, VIs are written on the development PC, then deployed and run on the target via a TCP connection with the LabVIEW run-time engine running on the target. While the VIs are running on the target, debugging information and front panel values is transferred between the target and the development PC. When a VI is running on the target with live front panel data on the dev PC, this is called Interactive Mode.

The LabVIEW run-time engine on the target runs inside a chroot, which is a Linux construct that is similar to a virtual machine. This allows the LV run-time to be installed and run safely on many different Linux operating systems.

The LabVIEW run-time chroot can be controlled via a systemd service, labview.service. Systemd is also responsible for starting the LabVIEW chroot when the target boots.

A utility server called the NI System Server runs outside of the chroot. This server script performs several utility functions such as allowing the LabVIEW run-time to be restarted remotely via HTTP requests.

LabVIEW VIs running on the target utilize the LINX firmware, compiled as a Linux shared object liblinxdevice.so, in order to access I/O on the target. The LINX shared object contains the logic necessary to access I/O on the specific target board.

Local I/O has a final mode it can be used in via a startup executable. As shown in the diagram above, a development PC is no longer needed in this configuration, since the startup executable is run automatically when the target boots. This tutorial demonstrates how to create a startup executable.

The only difference in this mode is that the front panels are no longer visible since the development PC is not controlling the execution of the application's VIs. This mode is “headless” in the sense that there is not a built-in user interface. It's usually best used after the initial debugging and development of the application is complete.

Note that although startup executables are called “executable” they do not function like normal Linux programs and can't be invoked from the command line. Creation and deployment of the startup app is controlled from the development PC.