Each parameter results in a different command string sent to the instrument. Therefore, verify each command string. Test different VI combinations, calling orders, and dependencies. Invalid calling orders or dependencies should be handled robustly by the driver. Test parameters as part of a test framework or test them interactively. Test VIs can be saved and executed on future driver versions. If you test VIs interactively, combine the testing with a final front panel review. This type of testing should be executed throughout development and after the driver is complete.
Test both valid and invalid test conditions. Testing failing conditions validates the error handling mechanisms. Send out of range parameter values, call dependent VIs in the incorrect order, or use other methods to produce instrument errors. Refer to the instrument documentation for a complete list of command, execution, device, and system error messages to test. Test the following conditions to ensure the Error Query VI executes appropriately based on instrument or VISA errors:
The Initialize VI should clear all instrument errors and place the instrument in a known good state so that the driver can execute properly. Abort an instrument driver example during execution and verify that the example can be run again without error.
There are many possibilities for different behavior when supporting multiple buses. First, the instrument itself might have different behavior for each bus type. Then the actual bus protocol might introduce differences, including time delays. Third, VISA defines different behavior for some functions and properties. Take these differences into account as you develop your instrument driver VIs. Thoroughly test the driver with each interface. The majority of testing can be executed on one interface bus. The most common use cases, like the instrument driver examples, should be tested with various parameter selections on all supported buses. Test driver VIs that transfer large amounts of data to or from the instrument. Verify the timeout is appropriate for typical transfers on slow buses. All interface specific code should also be tested.
The instrument driver Readme should include detailed information about any known issues found in the driver. Include information about test coverage for testing performed on the driver. Instrument functionality not supported by the driver should also be documented in the Readme. All of this information can be useful to users of the driver, particularly if problems are encountered.
Timing issues can often be difficult to identify and troubleshoot. A majority of timing issues occur with the serial interface or with poorly designed instruments. Developers should use Wait VIs only as required to work around timing issues. This workaround should be documented in the driver code and also in the Readme. This type of documentation can be denoted with a keyword so that a user can search for and identify all instances of this workaround in the driver.
Before submitting the driver for certification, mass compile the driver to ensure that the instrument driver VI Library contains only runnable VIs. In addition to mass compiling the library, review all the VIs in the VI Library. Sometimes temporary or testing VIs appear in the VI Library unintentionally. Mass compile the VIs on a separate computer running LabVIEW to ensure that there are no dependencies to other VIs not installed on the end-user computers. Do so especially if you create a new instrument driver from an existing instrument driver.
Validate that default values in each VI are appropriate for the most common use cases. Instruments often require stimulus to perform measurements. Set examples to use instrument on-board test signals, such as the probe compensation signal available on most oscilloscopes. This provides users with a good out-of-the-box experience when using both the instrument and instrument driver. If no on-board test signals are available, clearly document the required system setup and stimulus needed to perform the operation. Include these instructions on the front panel of the instrument VI.
The LabVIEW Instrument Driver VI Analyzer Plug-in contains additional tests and configuration based on the Instrument Driver Guidelines. This plug-in prioritizes instrument driver tests for driver architecture and API design, VI names and properties, controls and indicator properties, front panels, block diagrams, icons and connector panes, documentation, palette menus, and examples.
Ensure no hard coded paths exist anywhere in the VIs. Test links to the online help on a computer with a different file structure than your development machine.
Change the system font for your computer, then check the front panel and block diagram for overlapping objects.