Learn common ways to debug TestStand test programs, including how to control and inspect sequence execution by using breakpoints, watch expressions, and execution tools. Also learn how to debug code modules and related files—such as LabVIEW VIs, packed libraries, DLLs, and .NET assemblies.

Consider the following common approaches to debug the following components of a TestStand test program.

Sequence Execution

Sequences can be in a running or suspended testing state. Testing runs when continuously testing DUTs. When testing runs, each test socket executes tests for one DUT. TestStand suspends testing when one or more TestStand test socket executions suspends at a breakpoint. One test socket can suspend while other test sockets run. The Execution window background changes to yellow to indicate a suspended execution. You can examine sequence variables only in suspended executions.

Use the following techniques to debug sequence execution:

  • Set Sequence Breakpoints—To suspend testing at a specific step, set a breakpoint on the step. To set a Sequence breakpoint:
    1. In the Steps pane of the Sequence File or in the Execution window, click in the column to the left of the step name.
    2. Right-click the breakpoint stop sign icon and select Breakpoint » Breakpoint Settings. The Breakpoint Settings dialog box launches.
    3. In the Breakpoint Setting dialog box, specify an expression to set a conditional breakpoint.
    Testing suspends when the execution reaches the step breakpoint. A yellow arrow icon, called the execution pointer, appears on the left of the step. The execution pointer indicates the next step to execute when testing resumes. Click the breakpoint icon to remove the breakpoint.
  • Set Data Breakpoints—You can suspend testing when the value of a variable changes or when it has a specific value. In this scenario, use the Watch View pane to enter an expression for the variable. Then, edit the watch expression to specify a break condition. TestStand evaluates these break conditions when each step executes. TestStand then suspends the testing if the variable meets the break conditions.
    Note Delete unneeded watch expressions. Unnecessary watch expressions can negatively affect execution performance.
  • Control Test Program and Step Execution—You can control test program and step execution in one of the following places during testing suspension:
    • The Debug menu or Debug toolbar
    • The Steps pane context menu in the Execution window
    • Debug Menu/Toolbar
      • Step Into—Enters and suspends inside the code module associated with the step to which the execution pointer points.
      • Step Over —Executes the step to which the execution pointer points and suspends execution on the next step in the sequence.
      • Step Out—Resumes execution through the end of the current sequence and suspends execution on the next step in the calling sequence.
    • Steps Pane Context Menu
      • Run Mode » Skip (temporarily skips step)—Select Skip to prevent the step from executing in the current execution. Changing the step run mode in an execution does not persist the setting to the step in the sequence file. Consequently, after execution ends, the setting reverts to the original run mode that preceded the change. Change the run mode on the step in the Sequence File window to persist the setting in the sequence file.
      • Set Next Step to Cursor —Moves the execution pointer to point to a different step to change which step executes next.
      • Run Selected Steps—Select one or more arbitrary steps in the sequence to execute before resuming normal execution. TestStand executes the selected steps in the order the steps appear in the sequence. If a breakpoint suspends execution of the selected steps, the Steps pane displays the interactive execution pointer. The interactive execution pointer differs from the normal execution pointer.
  • View and Modify Variable and Expression Values —Use the following techniques to view or modify variable values and to monitor expression values:
    • When testing is suspended, use the Variables pane to view and modify the values of any variables and properties that are accessible in the current execution context.
    • To monitor the value of an expression while testing, enter the expression in the Watch View pane when testing is suspended. You can also use the Edit Breakpoints/Watch Expression dialog box to enter expressions when testing is not in progress. When you enable tracing, the sequence editor updates the values after each step executes.
  • Display Debug Messages—To display messages to the Output pane while testing, use the OutputMessage expression function in a Statement step.
  • Use Execution Profiler—The Execution Profiler records the following types of data:
    • Event data
    • Operation data
    • Item data
    • Thread data
    • Execution data—This data includes the duration of steps, code modules, and other resources a multithreaded TestStand system uses over a period of time.
    event, operation, item, thread, and execution data, .

Code Modules and Related Files

The TestStand Sequence Editor integrates with common code module development environments to help streamline debugging tasks.

LabVIEW

When executing VIs in the LabVIEW Development System, you can debug the VI code modules loaded in memory. To debug using this method, set breakpoints and probes in the VIs. When setting these breakpoints and probes, you must use the same version of LabVIEW in which the VIs are executing. After the TestStand execution reaches the VI, the first breakpoint is triggered in a new instance of the VI. Add additional breakpoints or probes to this instance of the VI, if necessary. To make changes to the VI after debugging, right-click the front panel of the debugging instance of the VI and select Remote Debugging » Quit Debug Session.

The LabVIEW Development System can also debug applications that execute VIs using the LabVIEW Runtime. Such applications include VIs executed using the TestStand LabVIEW Adapter and LabVIEW-built DLLs executed using the TestStand C/C++ DLL Adapter.

When the TestStand LabVIEW Adapter loads a VI code module, it reserves the VI in LabVIEW to prevent edits to the VI. To edit a reserved VI, you must first unload the step code module. Click the Unload and Open VI button on the LabVIEW Module tab to unload a LabVIEW step code module and open the VI for editing. The button is enabled only if all executions are suspended. If the button tooltip is disabled due to actively running executions, use the Break All button on the Debug toolbar to suspend all executions.

You can also use the LabVIEW Desktop Execution Trace Toolkit to collect various types of trace data from LabVIEW applications.

Packed Libraries

LabVIEW packed libraries, or .lvlibp files, contain compiled LabVIEW code that you can execute from TestStand. By default, you cannot debug VIs in packed libraries as these VIs do not contain any source code. To create a packed library that you can debug, select the Enable Debugging option in the Advanced page of the Packed Library Properties dialog box. You can debug VIs in a debuggable packed library the same way you debug stand-alone VIs. To debug these VIs, execute the VIs using the Development System option in the TestStand LabVIEW Adapter Configuration dialog box.

LabVIEW, LabWindows/CVI, and .NET DLLs

To debug a DLL TestStand calls, first create the DLL with debugging enabled in the application development environment (ADE). Then, launch the TestStand Sequence Editor or TestStand User Interface executable from the ADE. You can also attach the DLL to the sequence editor or user interface process from the ADE, when supported.

.NET

To debug a .NET assembly, first open the source code project in Microsoft Visual Studio and ensure the output assembly is configured and built with debugging enabled. Then, use Visual Studio to launch the sequence editor or user interface as the Start action for the project. Alternatively, use Visual Studio to attach to an in-progress instance of the sequence editor or user interface process.

You cannot view any TestStand sequence variables or interact with the TestStand Sequence Editor user interface while suspended at a breakpoint in Visual Studio.

Visual Studio 2019 version 16.11 and later provides a feature called Hot Reload. The Hot Reload feature enables you to edit code modules and apply the code changes immediately to a running application. Once Visual Studio applies the code changes, the new code is in effect the next time your application executes the code. To use this feature with Visual Studio 2019, NI recommends starting the debugging process from Visual Studio. To use this feature with Visual Studio 2022, use either of the options in the following table:

Table 2. Attaching Visual Studio to an Application
Starting the Process from Visual Studio Attaching to an In-Progress Process
  1. Open the project to debug in Visual Studio.
  2. Set the Start action for the project to Start external program. Then, enter the file path of the executable for the sequence editor or user interface you are debugging, including the .exe file extension. Refer to Configuring Sequence Editor and User Interface Startup Options for more information.
  3. Press F5 or select Start Debugging to start the application and attach Visual Studio.
  1. Before you start the debugging process, create an environment variable named COMPLUS_ForceENC with a value of 1.
  2. Open the project to debug in Visual Studio.
  3. Select Attach to Process in the Debug menu to attach Visual Studio to an in-progress process.
Note When attaching to an in-progress process, the COMPLUS_ForceENC you must set the environment variable before the process initially loads the assembly. If COMPLUS_ForceENC is not set, you can still use Hot Reload to apply code changes if you attach Visual Studio to the process before the process loads the assembly. Unload any loaded assemblies to allow code changes.
You can implement immediate changes to .NET code at any time after attaching Visual Studio to a process by selecting one of the following toolbar actions:
  • Hot Reload (Visual Studio 2022)
  • Apply Code Changes (Visual Studio 2019)
Note You cannot detach Visual Studio from an application after attaching it using Hot Reload. Visual Studio displays a warning if you attempt to detach. However, if you select Stop Debugging or attempt to close Visual Studio, Visual Studio terminates the debugging process without warning. Instead of terminating the debugging process, return to the TestStand application you are debugging. Then, end all executions and exit In the TestStand application to ensure that cleanup code executes correctly.

If you are not using Hot Reload, you cannot modify .NET assemblies while TestStand has the assemblies loaded. TestStand typically loads assemblies automatically when starting executions. These assemblies might remain loaded after execution completes unless you explicitly unload them. Before you can successfully rebuild a .NET assembly loaded by TestStand, you must unload the assembly and all other assemblies the .NET Adapter is using from within the TestStand Sequence Editor. Closing the TestStand process unloads all assembly references.

Unloading an Assembly

  1. End and close all execution windows.
  2. Clear any references to .NET objects stored in station globals.
  3. Select File » Unload All Modules.

To unload .NET code modules, TestStand must unload the .NET appdomain that it uses with the .NET Adapter and can do so safely only when the .NET appdomain is no longer in use.

Analysis and Rule Configuration Modules

If you use the TestStand Sequence Analyzer, you can debug custom analysis modules and rule configuration modules by setting a breakpoint in the module and then calling the module from the TestStand Sequence Analyzer.

Memory Management

Visit ni.com/info and enter the Info Code tsmemory to access the tutorial. This tutorial provides information about efficiently managing memory in test sequences and code modules.

Deployments

Ensure that you have followed the suggested deployment process to plan, design, implement, execute, and validate a full or patch deployment for a TestStand-based test system.

The TestStand Deployment Utility generates several errors and warnings specifically related to debugging patch deployments. Additionally, you can use the Build Status tab of the deployment utility to view information about the patch deployment.