Automated Instruments Smooth Rapid Test System Development
Do you manually take measurements and record data at a bench? For even a small number of measurements, you can benefit by rapidly configuring a test and datalogging system.
Nancy Holland, Optek Technology, Carrollton, TX -- Test & Measurement World, 8/1/2000
As a test engineer for a semiconductor company, I am often asked by product engineers to develop a test system for their new devices. Test-system projects vary widely, requiring disparate combinations of AC and DC sources and instruments, ranging from programmable power supplies to pulse generators and from simple DMMs to digital oscilloscopes. In this two-part series, I present an example that focuses on DC parametric test to explain how to rapidly develop such a system. You can expand on this example to add additional DC, as well as AC, tests. In a future article, I will cover production test.
You can, of course, perform DC parametric tests on the bench by collecting data manually. Engineers have traditionally employed manual testing when a dedicated automated test system for a specific part is unavailable and time is a pressing factor. With the availability of PC-controllable automated test-and-measurement instruments, you can rapidly develop an automated test system that’s cost-effective for even limited-volume bench tests as well as high-volume production tests. The computer control that such a system affords reduces the operator subjectivity and error that can plague manual bench measurements. View article figures in a new window.
Engineering or Production?
When building a test system, the first question to answer is whether the system is for engineering or production. Unlike an engineering system, a production tester must be optimized for speed. If I have the luxury of time, I will optimize for speed without regard to the system’s ultimate use. Even with rapid development techniques, however, development time is often limited, and I can sacrifice speed for a bench test without compromising the application.
After all, an operator will manually insert the device under test into the test fixture, manually remove it, and manually place it in the proper bin (for example, "pass," "within 5%," "within 10%," or "fail"). The system need only be faster than the operator’s reaction time, and this requirement is generally easily met. In a production environment, however, part placement and binning is automated, and test speed becomes much more critical as a computer controls these tasks through digital I/O and implements them at a much faster rate.
When selecting the hardware and software for an engineering test system, I ask myself these questions:
• What voltage and current levels must the instrumentation source to meet requirements of the DUT?
• What are the required instrumentation resolution and accuracy?
• When my DUT changes, will I have a good chance of reusing my instrumentation in a new test setup?
• Are my instruments SCPI (Standard Commands for Programmable Instruments) compliant? (Although not necessary, SCPI compliance will help the job proceed faster. SCPI is an IEEE command standard, defined in IEEE Std 488.1-1987, that eliminates the need to program each instrument in its own device-dependent language.)
• Will I need additional capabilities such as external triggering and onboard digital I/O?
• How will I connect my test fixture to the selected instruments?
• Will I perform four-wire sensing?
• What is my budget?
For my engineering example, I have selected a test system with datalogging capability for diode testing (Fig. 1). For this example, a hypothetical product engineer has provided these instructions for making two tests:
• Test the forward voltage drop of the diode by placing a positive 20-mA drive on the anode and grounding the cathode; then, measure the voltage drop VF across the device. For this particular device, the test limits for VF are 1.0 V to 1.2 V.
• Test reverse current of the diode by placing –2 V on the anode and grounding the cathode. Measure the reverse leakage current, IR, flowing through the diode. IR for this particular device has no minimum limit but has a maximum limit of 5 mA.
The engineer would like to view the data on the computer screen, and he would also like it saved to an Excel file, along with pass and fail results.
Choosing Instruments
The next step is to select instruments that meet the requirements. For the first test, I need an instrument that can source 20 mA and read a voltage up to 2 V. The second test requires an instrument to source a negative voltage and read a current in the microamp range. Although I could use multiple instruments and a relay matrix to switch in the desired instrument at the appropriate time, I want to keep the test set as simple as possible so I can develop it quickly and then easily maintain it once it is running.
The backbone of my test racks are instruments called SMUs (source-measurement units), which can source a voltage and read a current, or source a current and read a voltage. SMUs allow me a tremendous amount of diversity in a variety of test situations with one instrument type; I needn’t juggle many separate meters and sources. In this diode test system, I employ an IEEE 488-compliant Keithley Instruments Model 2400 digital source meter. This meter is a 22-W instrument with four-quadrant source or sink operation. It can source/sink w 21 V at w1.05 A and w210 V at w105 mA. It includes a 200-mV range with 1-mV resolution as well as a 1-mA range with 10-pA resolution, which more than meets my requirements; it is also flexible enough to adapt when test requirements change. Because the Model 2400 can both source and measure in the required ranges, I will not need any additional instrumentation.
I will need an IEEE 488 interface card for the computer to communicate with the SMU and any other IEEE 488 instruments I may decide to add for future projects. Although IEEE 488 is a standard, there’s no guarantee of compatibility between programming software, an IEEE 488 interface card, and instrumentation. Unless you buy your instruments and interface card from the same manufacturer, you may find it necessary to purchase additional drivers to create a compatible system.
After selecting the hardware, the next step is to determine how to connect it to the DUT. In keeping with our simple example, I will provide electrical connections by inserting the DUT into a socket with two leads. I will connect the anode lead to the positive (high) output of the SMU and the cathode to the negative (low) output.
The fixturing for more complex devices and test sets may require other elements, such as shielding to cope with electrically noisy environments, four-wire sense lines for precision low-level measurements, or relays to switch in resistors to simulate various load conditions.
Designing the Software
When does the product engineer need the test set? Yesterday, of course! He also wants to view test data on the computer screen, which should also provide additional information such as percentage yield, and "gee, a histogram would be nice, and oh, could we automatically send the data to an Excel spreadsheet with headers, pass and fail text fields, and date and time stamps, and . . ."
The list is always endless, and you have to determine when to silence the engineer (the product engineer, not the test engineer, of course!) and start writing the test program. A variety of software environments will do the job, but my major concerns are these:
1. Rapid development.
2. Cross-platform-compatibility with Windows 3.1/95/98/NT.
3. Datalogging capability with dynamic data-exchange (DDE) support for linking to spreadsheets or with the ability to write directly to a data file.
My software of choice for test and measurement applications is TestPoint, a Windows package from Capital Equipment Corp. (CEC). The objects in TestPoint allow me to accomplish whatever task I need to complete, and when the Windows environment presents a limitation such as its lack of real-time support, I can use a DLL written in another language such as C and call it with TestPoint’s code object.
TestPoint provides a DDE object that allows me to send my data to, or pull test parameters from, an Excel spreadsheet. I can also send my data directly to a data file. I can use TestPoint objects to create a visual display during test that shows readings, pass or fail results, histograms, or other visual aids that the engineer requires.
Setting Up the System
The first step in setting up the system is to install the IEEE 488 interface card into a computer, according to the card manufacturer’s instructions. I install my card into a 386 or later Windows PC with at least 8 Mbytes of available RAM. (The computer will act as an IEEE 488 controller and is addressed through the IEEE 488 interface, often designated as address 21. When setting up a system, make a note of the controller address so you don’t assign it to any other device in your test system.) After installing the interface card, I connect the source meter to it with an IEEE488 cable. If my system required other instruments, I would daisy chain them with additional IEEE 488 cables.
Next, I install my programming software into the computer. If my plan calls for the system to log data to a spreadsheet, I need to ensure that Excel is also installed. In such cases, it’s a good idea to provide plenty of RAM (in addition to the 8-Mbyte minimum mentioned above) so that the DDE link runs faster.
Before beginning programming, I answer questions such as these (the answers for my example are shown in parentheses):
1. What tests do I need to perform? (Two tests: measure the forward voltage and the reverse current of a diode.)
2. What do I want to display? (Part count, test data for VF and IR with a pass/fail indicator for each, and percent yield.)
3. How do I want to log the data? (Send the data to a spreadsheet.)
4. Do I want to hard-code the test conditions, set them from a menu-driven operator input, or pull them from a spreadsheet file? (Pull them from a file.)
After answering these questions, I create a test flow, which can take the form of written notes or an actual flow chart. If I have an existing library of routines and one already defines a flow that is close to what this program requires, I may simply set out to modify it by listing the changes it will require.
Figure 2 shows a flow chart for this application. The initialization stage brings in test conditions from the spreadsheet and establishes the initial operator interface (Fig. 3). When the operator clicks the Test button, the program asks whether he or she wants to log data; if yes, the program prompts for a name for the file that will store the data.
The program flow proceeds with tests for VF and IR, with each parameter displayed on the computer screen with a virtual LED indicator glowing green (for pass) or red (for fail). If the operator selected datalogging, the spreadsheet receiving the data is updated in each routine as well.
After each test cycle, the program updates the results and yield display. When the operator has clicked the EndTest button, the program halts (after saving the spreadsheet file if datalogging had been selected).
Based on a flow chart such as the one in Figure 2, you can start writing an instrument-control program. In my case, I do much of my programming in TestPoint before I ever turn on the instrument. I first select the demo mode in the instrument object’s settings.
Using the objects I have available, I create my GUI displays and test routines to execute the tests and log data. I make sure to include compliance values in my program to ensure that when it talks to an instrument it prevents the instrument from generating voltage or current levels that could accidentally cause any damage if I have something miswired between the instrument and the DUT.
Before trying out the program, I need to set the IEEE 488 address of the digital source meter in the instrument object and make sure I have deselected the demo mode in the object’s settings. This address is changeable from the front panel of the instrument. Any number from 0 to 30 is acceptable, except 21, because in this application 21 is the controller address.
Finally, it’s time to run the program and debug it. I initially run it from within the editor so I can take advantage of TestPoint’s debug features—including single stepping, data viewing, and breakpoint insertion—and change my code "on the fly," if necessary. I count on trying a few iterations or different approaches to make the program work, but then that’s the fun and the challenge of this job.
Of course there are plenty of options you can add, from error-message boxes to help, but the program I have described here can provide a base that you can improve upon. You may need additional instruments as new test parameters arise. Each one will have its own address that your controller can access across the IEEE 488 interface. In a subsequent issue, I will explain how to adapt the test system I have presented here for production testing. T&MW
Nancy Holland is a test engineer for a semiconductor manufacturer that specializes in standard and customized sensors. She is also a certified TestPoint application specialist. E-mail: nhollandte@cs.com.
