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 is running when continuously testing DUTs. When testing is running, each test socket is executing tests for one DUT. Testing is suspended when one or more TestStand test socket executions are suspended at a breakpoint. One test socket can be suspended while other test sockets are running. The background of the Execution window changes to yellow to indicate that the execution is suspended. You can examine sequence variables only in executions that are suspended.

Use the following techniques to debug sequence execution:

  • Set Sequence Breakpoints—To suspend testing at a specific step, set a breakpoint on the step by clicking in the column to the left of the step name in the Steps Pane of the Sequence File window or in the Execution window. You can right-click the breakpoint stop sign icon and select Breakpoint » Breakpoint Settings to launch the Breakpoint Settings dialog box, in which you can 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, to the left of the step indicates the next step to execute when testing resumes. Click the breakpoint icon to remove the breakpoint.
  • Set Data Breakpoints—To suspend testing when the value of a variable changes or when it has a specific value, use the Watch View pane to enter an expression for the variable and edit the watch expression to specify a break condition. TestStand evaluates these break conditions when each step executes and suspends the testing if the break conditions are met.
    Note Delete watch expressions when you no longer need them because they can negatively affect execution performance.
  • Control Test Program and Step Execution—When testing is suspended, use the following options in the Debug menu or toolbar or in the Steps pane context menu of the Execution window to control test program and step execution:
    • 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. As a result, once execution ends, the setting reverts to the original run mode before you made 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 that you want to execute before resuming normal execution. TestStand executes the selected steps in the order they appear in the sequence. If a breakpoint suspends execution of the selected steps, the Steps pane displays the interactive execution pointer, which 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 of the variables and properties accessible in the current execution.
    • 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 event, operation, item, thread, and execution data, such as the duration of steps, code modules, and other resources a multithreaded TestStand system uses over a period of time.

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 using the same version of LabVIEW in which the VIs are executing by setting breakpoints and probes in the VIs. Once the TestStand execution reaches the VI, the first breakpoint is triggered in a new instance of the VI. To add additional breakpoints or probes, add them to this instance of the VI. 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 as 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 indicates that it is not enabled because there are executions that are actively running, 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, VIs in packed libraries do not contain any source code and cannot be debugged. 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 when you 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 or attach 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 has been 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 that enables you to edit code modules and apply the code changes immediately to a running application. Once the code changes are applied, the new code is in effect the next time it is executed by your application. 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 and 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 environment variable must be set 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 Hot Reload (Visual Studio 2022) or Apply Code Changes (Visual Studio 2019) in the toolbar.

Note You cannot detach Visual Studio from an application after attaching it using Hot Reload. A warning is generated if you attempt to detach, but 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, end all executions, and exit the 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, and assemblies may 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 will unload 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 NI tutorial, Troubleshooting Memory Growth Issues in TestStand Systems, for 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.