New instruments need a range of software support
23 January 2014
Creating a successful test and measurement instrument is a team effort: the hardware in the box is only one piece of the overall solution.
Modern source measure unit (SMU) instruments can offer different types of support for differing test settings and for users of varying levels of testing sophistication.
The demand for higher functionality in consumer electronics means that testing the components is more challenging every year. That often means that the instrumentation used for characterising the current-voltage (I V) characteristics of a device may lack the capabilities necessary to support emerging test challenges.
Embedded test programs
One of the responses to the demand for greater functionality has been the growing use of embedded microcontrollers/script processors and embedded software, which allow for local control of an instrument’s operation, rather than running a control program on a host controller and communicating commands to the instrument via GPIB, USB, LXI or other interface. A test script is a collection of instrument control commands and/or program statements. These statements control script execution and provide facilities like variables, functions, branching, and loop control. Scripts are often written using a scripting language, such as Lua, which allows creating powerful, high-speed, multi-channel tests with significantly reduced development times.
Test scripts can be downloaded into the volatile or non volatile memory of an instrument with an embedded script processor, to allow the instrument to control itself, independent of the system controller. This frees the system controller to interface with other instruments in the rack more frequently, boosting overall system throughput.
Embedding complete test programs and the microcontroller to run them within the instrument itself virtually eliminates the time-consuming bus communications to and from the PC controller, dramatically improving overall test times. Some instruments with an embedded script processor can control multiple instruments from a single master by connecting to each other via a high-speed trigger synchronisation/inter-unit communication bus. A single test script runs on the script processor on the master instrument and controls both the master and any connected slave instruments, which is much faster than sending commands and trigger signals back and forth between the controller and the individual instruments over a traditional communications bus. Systems based on this kind of architecture also offer reduced programming complexity and allow easy system re-configuration as test requirements change.
Embedding test software in an SMU instrument allows users to start making measurements far sooner than if they had to write and debug an external test program. For example, TSP Express, an embedded Java-based test software compatible with the latest Keithley SMU instruments, allows users to begin characterising new devices almost immediately, with no need for software installation or programming. Software approaches like this support true plug-and-play I-V characterisation through any browser, on any computer, from anywhere in the world. Test engineers can connect these instruments to the Internet via a LAN cable, open a browser, type in the instrument’s IP address, and begin testing. Data can be downloaded to a spreadsheet program for further analysis and formatting or for inclusion in documents (see Figure 1).
Manufacturers often provide free scripting software with new SMU instruments, such as Test Script Builder, which creates, modifies, debugs and stores test scripts. They can also store and organise test scripts, create and modify test code, and there are tools to send commands to and receive data from the instrument.
When configuring systems to test new components, test system builders often want the flexibility to combine existing hardware and software components with new elements. For example, the Series 2600B and Model 2450 SourceMeter SMU instruments are compatible with test code originally developed for the Model 2400 SMU instrument, which was introduced in 1995. Compatibility provides a migration path from the SCPI programming used to develop the original application to Keithley’s TSP technology, which when implemented can improve test times still more.
For simpler benchtop applications, less experienced SMU instrument users may prefer to avoid having to create test scripts or write control code altogether. Novice users often look for software tools that can walk them through the process. KickStart start-up software (Figure 2) is an example, it provides a simple, customisable user interface for the Model 2450 SourceMeter SMU Instrument.
KickStart supports automatic discovery of compatible instruments on a network and communicates with instruments connected to an external controller through the GPIB, USB, and Ethernet remote interfaces. Test-type plug-ins allow users to employ more advanced testing functions without any knowledge of programming languages. A flexible graphing function displays test results in real time; a spreadsheet view reveals individual data points. Test setups can be saved and used on other compatible instruments.
More experienced test system builders often want to create customised application software, typically incorporating instrument drivers supplied by the instrument manufacturer. Drivers control the instrument at a higher level and make it unnecessary to learn the commands specific to individual instruments. For example, the Model 2450 SMU instrument comes with native National Instruments’ LabVIEW drivers, IVI-C, and IVI-COM drivers. Different types of drivers make this option easier, whether the test system builder is working in C/C++, Visual Basic, C#, LabVIEW, or another programming environment.
Free or inexpensive tools are available to simplify creating applications intended for lab environments. For example, LabTracer 2.0 software allows configuring and controlling up to eight SMU channels quickly and easily via GPIB for curve tracing or device characterisation. A powerful graphical development environment integrates different instruments into a single test or building test scripts.
Similarly, the Windows-compatible ACS (Automated Characterization Suite) Basic Edition development environment provides control and analysis tools for high power device characterisation. The software’s “trace” mode allows users to control the voltage and current levels sourced interactively and observe how the power device responds in real time. The parametric mode provides a fill-in-the-blanks GUI to configure a test precisely and a comprehensive set of tools for precise parameter extraction.
No single software solution can address the needs of every instrument user or test system builder and every test environment. Identifying the best one for a particular application requires a clear understanding of the test requirements, as well as an honest assessment of the user’s programming abilities.
Figure 1: Built-in, Java-based test software can run directly from any web browser to boost productivity.
Contact Details and Archive...