Use the following best practices for test system development before you create a full or patch deployment:

During Development

  • Filenames—Use unique filenames in a test system to avoid file conflicts and to avoid including the wrong file in a deployment. Rename duplicate filenames, even if the files exist in different directories. Using files with the same name can cause sequences or the TestStand Deployment Utility to locate the wrong files, which can result in incorrect behavior. Using unique filenames ensures that TestStand locates the correct file even when you make changes to the search directories.
  • Paths—Avoid using absolute paths because the paths might not exist on test station computers that use different operating systems, logical drive configurations, or other configuration settings, such as read-only settings. Using paths that are relative to the sequence file or to a search directory ensures that sequences locate required code modules even if you install the files to different directories on the test station computer from where the files exist on the development computer. Additionally, using relative paths avoids the use of complex file structures, which makes validating the deployment more complicated. Using absolute paths also prevents you from validating test sequences from the deployable image directory on the development computer because absolute paths point to the source files, not to the files in the deployable image directory. Additionally, the deployment utility attempts to replace absolute paths with relative paths while creating a deployment, which increases the deployment build time. To use absolute paths, you must ensure that the entire test system file and directory structures are identical on all development computers and test station computers that use the test system.
  • DLLs—Use DLLs or LabVIEW packed project libraries to store code you share among different parts of the test system, such as code modules, or among different test systems that run on the same test station computer.
  • Workspaces—Use a TestStand workspace during development to organize the files and static dependencies a project requires, which can simplify the deployment process. You must explicitly add dynamic dependencies to the workspace for the deployment utility to include. Additionally, you can use a workspace with a source code control system, which can aid the development and deployment process when multiple developers work on the same test system.
  • TestStand Versions—Write all test sequences using the minimum version of TestStand the test system supports to avoid saving sequences with features or in a format the test system does not support.
  • Sequence Files—Select Tools»Update Sequence Files to launch the Sequence File Converter tool, which you can use to ensure that you save the sequence files in the test system in the format you want with the correct version of TestStand and that the sequence files use the correct versions of custom data types and step types. If the test system dynamically loads and unloads a significant number of sequence files, use the binary file format to improve execution performance.
  • Analysis Tools—Use the TestStand Sequence Analyzer in the TestStand Sequence Editor or the stand-alone sequence analyzer application to analyze sequence files and resolve any issues the analyzer might report before you use the TestStand Deployment Utility to create a deployment.
  • Troubleshooting Tools—Use the Debug Options dialog box, the Sequence Hierarchy window, and the TestStand File Diff and Merge utility as debugging tools to troubleshoot issues with sequence files.
  • Drivers—As you develop code modules, maintain a list of any NI drivers or components or third-party installers with version numbers the code modules require so you can easily determine which drivers the test system requires.

Before Deployment

  • If you use the Insert Code Modules context menu item in the Workspace Browser dialog box or the Insert Code Modules context menu item in the Workspace pane for any of the included workspaces, delete the code modules and insert them again to refresh any code modules that might have been added or removed.
  • Search Directories—If the deployment includes a SearchDirectories.cfg file, ensure that the file does not disable the sequence file directory and workspace file directory search paths in the test system. If the deployment utility cannot find the files in the image directory through search directories, which can happen if a search directory points to the source files, the utility attempts to create relative paths from the sequence file or workspace file, which might break the deployment.

LabVIEW

  • Packed Project Libraries—Use LabVIEW packed project libraries to store code you share among different parts of the test system, such as code modules, or among different test systems that run on the same test station computer.
  • VIs—Save VIs in a single version of LabVIEW to reduce the time required to create a deployment. If the test system requires multiple versions of LabVIEW, use packed project libraries.
  • LabVIEW Versions—Mass compile all VIs with the active version of LabVIEW to avoid recompiling VIs each time you create a deployment, which slows deployment build times. Review the mass compile log file to identify any issues with compiling the VIs. The compiled code for 32-bit VIs and 64-bit VIs is not shared. If you are creating a 32-bit deployment and a 64-bit deployment, consider using LabVIEW packed project libraries or enabling the Separate compiled code from source file option on the General Settings page of the Project Library Properties dialog box in LabVIEW.
  • Shared Variables—LabVIEW must create shared variables in the Shared Variable Engine before a test system can access the shared variables. The test station computer also requires a .alias file located in the same directory as the TestStand User Interface executable. The .alias file contains the IP address of the test station computer for LabVIEW code modules to use to resolve the references to the shared variable. When you call VIs in the context of a LabVIEW project, configure the LabVIEW Adapter to automatically deploy and undeploy shared variables or use the Deploy Library LabVIEW Utility step type to deploy shared variables. If any code modules in the deployment reference a shared variable outside the context of a LabVIEW project, the deployment will build successfully, but the shared variables will not be deployed on the target system, and the code modules will not run. To prevent this issue, ensure that the owning libraries of any shared variables are contained within a LabVIEW project, and that you include all such LabVIEW projects in the deployment.
  • Bound Shared Variables—TestStand can deploy a shared variable bound to another shared variable only when you use an NI Publish-Subscribe Protocol (NI-PSP) URL to bind the shared variable to deploy to another shared variable. If you attempt to use a Deploy Library step to deploy a shared variable to a variable in a LabVIEW project, the deployment fails. Refer to the LabVIEW Help for more information about deploying shared variables and NI-PSP URLs.
  • VI Calls—Select Tools»Update VI Calls to launch the Update VI Calls dialog box, in which you can verify that you compiled embedded Express VIs with the active version of LabVIEW and that all LabVIEW steps use the correct prototypes. Resolve any errors or warnings the Update VI Calls dialog box reports.

Validation

  • Development Computer—Ensure that the test system software executes without errors on the development computer to reduce the time you spend diagnosing issues on the test station computer.
  • Installed Software—Install the NI software the test system requires on the development computer, including the necessary patches or updates, the test system requires because the deployment utility can redistribute only the NI software installed on the computer you use to create the deployment.
    • Many NI driver installers provide different installation types that you can redistribute for development purposes or for only run-time purposes. The Full installation type is the most complete installation type. Installation types that support development consume more space in the installer and on disk after installation. Run-time-only installation types might exclude dependencies required to redeploy the development installation type. Distributions that NI builds, such as the NI Device Drivers DVD, always contain the full installation type for all products.
    • In most cases, you can install only one version of a hardware driver on the computer at a time. When you update drivers, validate that the latest version of the driver supports the existing hardware and executes correctly with the test system.
    • You can install multiple versions of some components, such as the LabVIEW Run-Time Engine (RTE) and LabWindows/CVI RTE, on the same computer. However, NI recommends using only one version of the LabVIEW RTE in a single test system to simplify deployment. When you build an installer with the deployment utility, the utility compiles all the LabVIEW files with the active version of LabVIEW, and you can run the VIs with the equivalent LabVIEW RTE. The LabVIEW Adapter can execute VIs faster using the LabVIEW RTE, but the LabVIEW RTE does not support debugging.
  • Source Code Control System—Use a source code control system or other mechanism to ensure that you have the latest versions of the files the test system requires because the deployment utility includes only the files installed on the computer you use to create the deployment.
    • Verify that the required support files, such as limit files, images, and operator instructions, exist in the correct locations. Delete earlier versions of limit files to avoid including the incorrect version of the file. Receiving a File Not Found error is typically preferable to using incorrect limits. Because the deployment utility cannot detect support files that steps do not statically reference, you must manually add these types of dynamically referenced files to the TestStand workspace for the deployment utility to include them in the deployment.
    • Ensure that you include the latest build of binary files, such as executables or DLLs for user interfaces, code modules, code module dependencies, and support files. Combining earlier and later versions of executables or DLLs might create errors that are difficult to track down. Using a dedicated build computer can minimize these types of issues.
  • Configuration Files—If you deploy configuration files, validate that the files use the correct settings. For example, the following settings can affect execution speed and the functionality of the test system:
    • When you enable execution tracing, user interfaces can provide additional information about the execution, such as the current execution step, the status of steps, and so on, but test systems execute faster with tracing disabled.
    • Incorrect search directories can cause the test system to locate the wrong files or can prevent the test system from finding the files at all.