This paper describes available methods for interfacing LabVIEW RT for Linux to third-party software.” and will discuss common ways to interact with code, but please note that this list is not comprehensive. For more information about building and deploying third-party software onto the NI Linux® Real-Time target, see our paper here.
Given the vast ecosystem of Linux based tools, NI offers very limited support and cannot provide much assistance with specifics of 3rd party community tools in Linux. Note that AE support will require a factory reset, which will eliminate any Linux customizations. You should still feel empowered to innovate and explore the NI Linux Real-Time based hardware platforms and the NI Linux® Real-Time operating system. You can always reformat your hardware and revert to factory-default state. We recommend you revalidate your application after modification to the system to ensure your application still meets your requirements.
The simplest method to use the System Exec VI which will allow you to execute system commands or shell scripts in your LabVIEW program. This new functionality is available only on NI Linux Real-Time targets. System Exec VI calls are a simple way to interact with the operating system or other software from within your LabVIEW application. They may not be the best solution given their limitations, including having to happen in-line, not very performance optimized (should be called during initialization, or will introduce jitter during main application execution).
Beyond the System Exec VI, another way to interact with external software is through the Call Library Function Node. The Call Library function node is another way to interact with the operating system and external software from within a LabVIEW application. The Call Library Function Node can make calls into C APIs which are asynchronous more often than executables used with System Exec. This allows you to execute functions in Linux shared libraries (*.so files).
Another way to interact with external code may be through TCP/IP communication over the loopback network interface (a.k.a. 127.0.0.1, a.k.a. localhost). The external code runs as a separate daemon and services requests over a TCP/IP socket bound to the loopback interface; LabVIEW RT code communicates with this daemon using TCP/IP nodes.
Suppose that you need to periodically run a particular script or application, either at particular intervals. In such a case one should use cron to schedule these tasks. More information about the Unix cron facility is available online, for example at http://linux.die.net/man/8/cron. For the 2013 release, the cron facility is supplied by BusyBox 1.19.4. Important caveat about cron for the 2013 release: you will need to manually redirect the standard error output to a file. Otherwise error output from cron-executed commands or scripts will be unavailable.
Finally, for on-demand services which could execute on user login, a network accessed implementation over SSH is also possible. However this will require an understanding of how user accounts and permissions work on the system with NIAuth.