Introducing Debug Driver Session Technology
Overview
Contents
- Introduction
- How does it work?
- How to use it?
- Additional benefits of Debug Driver Session
- Considerations and Recommendations
- Next Steps
Introduction
Test Engineers involved in creating automated V&V or functional test systems need the flexibility to quickly prototype and debug their test code during test system development. In both the test creation and test deployment stages the ability to debug the test code is very crucial to successfully building a test system.
Figure 1 : Typical Test Development and Deployment Flow
With PXI based automated test systems, engineers experienced multitudes of improvement in test time, test system development and management. NI Soft Front Panels (SFP) presented a familiar experience for interacting with modular instruments but the debugging experience continued to remain a challenge due to the inability of the SFPs to run concurrently with automated test code.
The NI Debug Driver Session technology now brings the familiar box instrument debugging experience to the modular instruments with several additional productivity enhancement features that will allow test developers to program their test systems with enormous flexibility.
The Debug Driver Session technology allows the test developers to make use of soft front panels when instruments are being accessed by LabVIEW or TestStand or other ADEs to perform concurrent run-time monitoring of the instruments or take control and make changes to the instrument settings. The technology also provides several advantages over the traditional box debugging experience.
Following sections of this white paper describe this capability and how to use it.
How does it work?
The Debug Driver Session Technology relies on a client-server architecture. When using application code written in LabVIEW, the Soft Front Panel shares data directly from the same process as the application code.
Figure 2 : Debug Driver Session Implementation with LabVIEW
When using C/C++ or .NET, the Debug Driver Session Technology creates an Out of Process server from which the data is shared to the SFP and application code. This is done because breakpoints in C, C++ and .NET suspend the process and prevent access to the hardware.
Note: Using Breakpoints in C,C++ and .NET do have some performance issues as there is considerable overhead when an Out of Process server is used.
Figure 3 : Debug Driver Session Implementation with C, C++ and .NET
How to use it?
The Debug Driver Session is enabled by default in the drivers for the modular instruments. It can be accessed in the Soft Front Panel of the particular instrument. Click on Utility > Configure Debugging on the top of the Soft Front Panel window to Enable or Disable Debug Sessions for the instruments. If you plan to use breakpoints while debugging a C/C++ or .NET application, remember to click the check box appropriately to enable debugging.
Figure 4: Configure Debugging
Figure 5: Configure Debugging Window
Once the Debugging is configured, you can now click on Debug Driver Session check box on the top of the soft front panel to connect to the particular instrument. You have two options that you can select in the drop down box: Monitor and Control.
- Control: Select this option after you have hit a breakpoint in the code and if the instrument is not being accessed by your test sequence. You have access to all the options in the Soft Front Panel when this mode is enabled. After the debugging process, the soft front panel gives the option to apply/revert the changes made and also offers code generation.
- Monitor: Select this option to concurrently monitor the instrument during the run-time. Use the measurement options and Property Viewer to quickly view all the properties for the instrument.
Figure 6: Debugging Experience
Additional benefits of Debug Driver Session
Change Tracking
Track all the changes that have been made during the debug process. Once the debugging process is complete, the soft front panel pops up a window with all the changes. Developers can also choose to accept or discard the changes that were made.
Figure 7: Session Changes Window
Automatic Code Generation
The soft front panels track all the changes and allow developers to accept or discard the changes. If the developers accept changes and choose to modify the test code, the soft front panel offers to generate LabVIEW VIs for the changes that can be included in your test code and also provides an option to export the changes as text.
Figure 8: Automatically generated LabVIEW code
Debug Multiple instruments simultaneously
With the Debug Driver Session technology, developers have the ability to simultaneously open up multiple soft front panels to monitor and control several instruments.
Considerations and Recommendations
- Using Session Close in TestStand
When debugging with TestStand, the recommended practice is to open session to the device, perform all operations and close the session only at the end of the test program. This will ensure that the Soft Front Panel has continuous access to the instrument, when it is monitoring
- Enabling/Disabling Debug Driver Session programmatically
To prevent inadvertent access to the devices deployed in a test system, there are VIs available to programmatically disable debugging for all devices in the system. This is done by creating a filter using the System API.
The System API can be found at <LabVIEW>\vi.lib\Utility\MITools\niMI Set Debug Session Configuration.vi
*<LabVIEW> is the default install directory
Currently supported SFP: NI-SWITCH, NI-SCOPE 14.1 and later, NI-DCPower 14.1.1 and later, NI-DMM 15.1 and later, NI-RFSA 2.9 and later (Debug control capability only)
[Last updated: May 2016]