Startup Executable Does Not Launch on NI Real-Time (RT) Target

Issue Details

I am experiencing one of the following issues:

• I have a real-time (RT) system with a startup executable (.rtexe) embedded on the controller.  When I reboot the controller, the .rtexe does not seem to be running at all or is running incorrectly.  
• I have developed an application for my RT controller that works correctly when I run it interactively from LabVIEW. However, when I build a .rtexe and deploy it on my controller, the application doesn't seem to work. 
• My Real-Time executable appears to be crashing, and when I check the Error Logs I see the following:

Solution

There are a number of problems that can result in an executable not running on start-up. Follow the troubleshooting steps below for the settings that are applicable for your system.

• Ensure that the Real-Time Application is set as the start-up application.
  1. Right-click on the application within the LabVIEW project, and select Set as startup as shown in the image below. Once an executable has been set to run at start-up, you will notice that the specified build is enclosed in a green box.
  2. If you choose Run as startup , LabVIEW will inquire as to whether you want to restart the device. When the controller is rebooted, your application should load on start up.

• Ensure Disable RT Startup App is not selected in NI MAX under the target's System Settings. Consider the following:
  • Some devices use hardware DIP switches, while others use the configuration set in System Settings for the device in NI MAX. Check the manual  for your device to determine the method your device uses.
  • While not all PXI controllers are equipped with a DIP switch option, those that do have it feature the switch internally, making it not visible from the outside.

• Check the IP settings of your device. If the device in question is not connected to a network, the device should not be set to obtain an IP address from DHCP server.
  • Note: This is only relevant for Phar Lap ETS and VxWorks controllers.
  • To set a static IP address for your controller:
    1. Detect the device under Remote Systems in National Instruments Measurement & Automation Explorer (MAX). 
    2. Open System Settings, and disable Halt on IP failure.
    3. Open Network Settings, and assign a static IP address.
  • If your controller is set to obtain its IP address from a DHCP server, the .rtexe will only launch when the controller is able to obtain a valid IP address. If the system must start on boot up without a network connection you can set a static IP. The .rtexe should then start when the controller is reset regardless of the availability of a network connection.

• Check that your NI-RT.ini (configuration/initialization file) and the lvrt.conf (for Linux RT) are set correctly. RTTarget.LaunchAppAtBoot in NI-RT.ini or in lvrt.conf must be set to true.
  • If you are deploying the application using WebDAV or SFTP, ensure you followed the instructions to Deploy a LabVIEW Real-Time Startup Executable Without the LabVIEW Development Environment.

• Make sure that you do not have NI VeriStand Engine installed on your RT Target. NI VeriStand Engine is a special Real-Time executable that takes priority over your custom Real-Time Application. Since only one executable can be designated as a Startup Executable, your custom Real-Time Application will not run. If this is installed, open NI MAX, select your RT Target under Remote Systems, right-click Software and select Add/Remove Software to uninstall NI VeriStand Engine from the target.

• Add error logging to your code. This way you will be able to capture any errors that may be occurring while the .rtexe is running, and address them accordingly. To add error logging, you can use the Crash Logger VI. 

• Remove all property nodes that reference front panel objects or properties from the VI. In most cases, property nodes that reference front panel objects and properties (such as window position), if used, will prevent a real-time application from executing because a VI's front panel is removed when a real-time executable is compiled. 
  • For some supported targets, it is possible to use property nodes that reference front panel objects if you Enable Embedded UI .
  • If it is not possible to remove property nodes that reference front panel objects and you cannot enable embedded UI, you can enable debugging to include the front panel in the build:
    1. Right-click on your Build Specification and select Properties.
    2. Navigate to the Advanced tab.
    3. Check Enable debugging as shown in the image below. Note: This will increase system resource utilization on your real-time controller due to the additional processing required to include and run the application's front panel.

​​​

• • If your device works when Debugging Tools are Enabled, see if there is an error code by remotely debugging the executable using LabVIEW. To verify sources of errors, ensure that you are wiring errors from points of interest into loops, otherwise, they could be cleared. Please review the image below for more information:

• Ensure that the Real-Time Operating System is able to start all required services before the start-up application attempts to execute by including a Wait function of 30-60 seconds in the application’s start-up sequence, example in the figure below. This is a good step when using R Series cards with older PXI controllers, as some of their processes take time to start up.

Note: This behavior can also occur in large applications that require multiple background processes to load before execution can begin. In these situations, it is possible that the RT OS cannot start all required services before the application attempts to execute (generally the first part is the Open FPGA VI Reference), causing a system to hang or crash. This is commonly seen when utilizing a RIO in hybrid mode and a call is made to the FPGA when before the scan interface has finished loading. A solution in this situation is to include a Wait function in the application's start-up sequence, which should allow the controller to finish loading without overloading the CPU.  

• If you are using a Linux RT target, delete all special characters in the name of elements running on the target including:
  • VIs
  • Libraries
  • Shared Variables
  • Files
  • Folders

• Remove type definitions from the RT application.
  1. Open the Application Properties by right-clicking on the EXE in the LabVIEW project. 
  2. Navigate to the Additional Information tab, and check Disconnect type definitions as seen in the image below.

Note: Type definitions are used to preserve source code - however, when building/running an executable, this is not a priority. In this case, type definitions can be disconnected to preserve memory usage. The disconnect option is also used as a troubleshooting step when LabVIEW perceives conflicts among different type definitions.

​

• If you are using SSE2 Optimization in your compilation, ensure that your target supports SSE2 instructions. If not supported by your target, disable this option in your build specification:
  1. Right-click on your build specification and select Properties. 
  2. Navigate to the Advanced category, and uncheck Enable SSE2 Optimization as shown below.

Note: As of LabVIEW 2017, SSE2 optimization can no longer be disabled. You can no longer deploy real-time executables to targets that do not support SSE2 in LabVIEW 2017 and later.

• If you are using VxWorks targets, be careful when using polymorphic VIs, as these VIs sometimes prevent deployment of the project and cause the cRIO to crash.
• Ensure that all dependencies (eg. subVI, library, configuration file etc) are included in the RT executable’s build specification. If error handling is not implemented properly, missing dependencies or files in the startup executable cannot be detected.