Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
learn:libraries:linx:misc:linx-internals [2016/04/24 22:36] sharpk |
learn:libraries:linx:misc:linx-internals [2016/06/01 16:58] sharpk |
||
|---|---|---|---|
| Line 16: | Line 16: | ||
| 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. | 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 engine on the target runs inside a [[https://en.wikipedia.org/wiki/Chroot|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 chroot is located at ''/srv/chroot/labview/'' on the target. |
| - | 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. | + | The LabVIEW run-time chroot can be controlled via a [[https://en.wikipedia.org/wiki/Systemd|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. | 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. | ||
| Line 29: | Line 29: | ||
| 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. [[:learn:tutorials:libraries:linx:3-0:deploy-startup-exe|This tutorial]] demonstrates how to create a startup executable. | 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. [[:learn:tutorials:libraries:linx:3-0:deploy-startup-exe|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 since 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. | + | 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. | 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. | ||
