Error Loading VI With TestStand Using the LabVIEW Run-Time Engine Adapter

Issue Details

Unable to load VI <VI_name> with the LabVIEW Run-Time Engine version <LabVIEW Version>. The version of the subVI might not match the version of the run-time engine or a VI dependency might be missing.

The error message looks similar to the screenshot below:
 

Solution

As suggested in the document TestStand System Deployment Best Practices we recommend to deploy the LabVIEW code modules using a source distribution or a project packet library.

To handle much of this process automatically, you can use the TestStand Deployment Utility to deploy your sequence files that call LabVIEW code modules. The TestStand Deployment Utility saves all VIs in a single LabVIEW version and includes any required dependencies that are part of the LabVIEW ADE. The deployment utility can also optionally generate a Packed Project Library (PPL). For more information, refer to Deploying VIs in LabVIEW Packed Project Libraries.

• The VI called by the step contains a subVI that is saved in a different version of LabVIEW than the top-level VI. Mass compiling your VI's directory or the VI itself may take care of this problem. Mass compiling the top-level VI can save all of the subVIs in the same version of LabVIEW. For more information, see How to Mass Compile in LabVIEW. 
• There is a dependency that the LabVIEW Run-Time engine cannot find. Ensure that all dependencies for any VIs can be found by the engine by trying these different steps:
  • Put all of your VIs and subVIs within one directory, if possible. 
  • If the directory for the VI or its subVIs is not in the TestStand search directories, first add the directory to the TestStand search directories. This can be done at Configure»Search Directories... and clicking Add to browse for your directory.
  • If your VIs or their dependencies have the compiled code separated option enabled, it is not possible to execute the VI in the LabVIEW Run-Time Engine. The LabVIEW Run-Time does not have access to the compiled object cache of the LabVIEW Development Environment.
• If the bitness of the LabVIEW Run-Time engine does not match the bitness of TestStand, then this error will occur. If this is a requirement, refer to Using 64-bit TestStand to Execute 32-bit LabVIEW VIs.
• There could be a naming conflict due to LabVIEW Application instances. For more information on this error, please see the section labeled "Errors Related to Naming Conflicts" in the article, How TestStand Interacts with LabVIEW Application Instances. The method for fixing this error will differ based on the use case, for instance:
  • If you do not intend to share VI instances between the sequence and the user interface, follow these steps:
    1. In the Build Specifications of your Operator Interface, with the Dependencies item selected, check the Apply prefix to all selected items option in the Source File settings tab of the Build Specifications Window.
    2. Specify a prefix to use. This will ensure that the user interface and the sequence do not conflict. 
  • If you do intend to share memory, you can prevent this error by deselecting the Modify project library file after removing the unused members option in the Additional Exclusions tab of the Build Specifications Window.  Note that this change can lead to larger executables due to the inclusion of unnecessary VIs.
• Make sure the version of the Run-Time Engine matches the version of LabVIEW you are using. You can check what software is installed by using NI MAX.
• If you are accessing the VI from a Packed Project Library (PPL) try rebuilding the PPL again and call the TestStand sequence after reloading it. Note: After you create a project library in a LabVIEW project, create a separate LabVIEW project for the project library before you build the packed library. If you build the packed library in the same LabVIEW project where you create the project library and you replace the project library with the packed library, you cannot rebuild the packed library.

Additional Information

• Narrow down the source of the error by eliminating subVIs until the error goes away. You can use diagram disable structures to incrementally disable subVIs until you find the source of the error.  
  • If you are able to determine the VI or VIs that are causing problems, try recreating the VI and saving it in place of the VI causing the problem. 
• Build a Source Distribution or a Packed Project Library to ensure that all dependencies are linked properly and that the code is compiled in the same version. Building a TestStand Deployment will accomplish this.