Ensure that you prepared the source components as suggested because you can eliminate many issues by following the recommended guidelines and best practices. Use the following suggestions to troubleshoot issues with , , and .

Mass Compile Log

When you mass compile VIs, enable the Log Results option in the Mass Compile dialog box in LabVIEW and specify a destination for the log file. Review the mass compile log for broken VIs or read-only VIs.

Open broken VIs in LabVIEW and click the broken Run button to launch the Error list window, which includes details about the error. If no errors exist in the Error list, press the <Ctrl> key and click the Run button to force LabVIEW to recompile the VI, which updates the error list.

Resolve the reported errors before you include the VI in a deployment and ensure that the deployment also includes other files or drivers the VI requires.

Including Dynamically Called VIs

You must explicitly add VIs that code modules call dynamically, such as by using VI Server, to the TestStand workspace or to the directory from which you create the deployment. Additionally, you must manually add to the deployment any VIs or project libraries custom step types or other sequence elements require.

Even if a deployment builds without errors, validation tests on the test station computer can return Error 7 with the similar text "Open VI Reference in <VI Name> VI Path: <Path to VI>" to indicate missing VIs called dynamically. Confirm that you included the dynamically called VIs in the deployment with the correct destination and verify the path of the dynamically called VIs for each dynamic call. Typically, you place dynamically called VIs in the same directory as the calling VIs.

Redeploying Previously-Deployed VIs

NI does not recommend deploying VIs that were previously deployed using the TestStand Deployment Utility. When the deployment utility packages VIs, the deployment utility includes all subVIs and creates partial project libraries that contain only the required VIs from the project libraries. If possible, use the original source files to create the new deployment.

When you attempt to redeploy VIs, the build in the deployment utility might fail with the LabVIEW error "This VI claims to be part of a library, but that library does not claim to own this VI". This error typically occurs due to conflicts between vi.lib VIs, which are included by the LabVIEW development system, and the copies of these VIs, which are included in the support VIs folder or LLB in the deployment. The deployment utility includes these copies so that the deployed files will successfully run on a machine without the LabVIEW development system installed. For more details about this error, refer to the "Encountering Broken VIs With Partial Project Libraries" section of the Partial Project Libraries topic. This issue can also occur when you deploy custom LabVIEW-based step types to a development system and then attempt to include the step types in a new deployment.

To work around this issue, you must remove the duplicate VIs and partial project libraries from the test system and relink any callers of the duplicate VIs before you create a new deployment.

Complete the following steps to remove duplicate VIs and relink their callers:

  1. Create the deployment and review the VIs the deployment utility reports as duplicates in the status log.
  2. Remove any duplicate VIs and partial project libraries the deployment utility reports from the SupportVIs LLB or directory. Do not remove VIs from the vi.lib folder of the LabVIEW development system.
  3. Load all top-level VIs included in the previously deployed files in the LabVIEW development system and re-save the VIs. LabVIEW prompts you to browse for any missing subVIs and relinks the VIs to the selected subVI path. In the Sequence Editor, select Tools»Update VI Calls to run the Update VI Calls tool to ensure that the LabVIEW steps use a valid path for the VI code module, since some steps may point to removed duplicate VIs.
  4. Rebuild the deployment and verify that no library errors occur. If the errors persist, contact NI for support.

To prevent this issue in new deployments, consider enabling the Output VIs to a packed project library option to generate packed project libraries that contain the VIs the test system requires. All files in a packed project library, including project libraries, use qualified names that begin with the name of the packed project library to avoid conflicts with filenames already in memory, such as partial project libraries.