|Download Help (Windows Only)|
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:
|Note Delete watch expressions when you no longer need them because they can negatively affect execution performance.|
The TestStand Sequence Editor integrates with common code module development environments to help streamline debugging tasks.
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.
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.
To debug a DLL TestStand calls, first create the DLL with debugging enabled in the 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.
To debug a .NET assembly, first create the assembly with debugging enabled in the ADE. Then, launch the sequence editor or user interface from Microsoft Visual Studio or attach to the sequence editor or user interface process from Visual Studio.
You cannot view any TestStand sequence variables while suspended at a breakpoint in Visual Studio.
You cannot modify .NET assemblies while TestStand has the assemblies loaded. 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 in TestStand by completing the following steps:
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.
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.
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.
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.