Adapt Automated Instruments to Production Test

A fiber-optic discrete-transceiver test example demonstrates the fixturing and actuator programming requirements necessary for a high-throughput test process.

Nancy Holland, Optek Technology, Carrollton, TX -- Test & Measurement World, 12/1/2000

In a recent article, I described how to develop a simple test and datalogging system for making benchtop measurements.¹ In this article, I expand the concept to cover production test. My example covers the testing of a fiber-optic transceiver, but you can extrapolate the technique to other types of production tests.

In a production environment, speed is usually much more critical than it is in a lab. The speed of a production system is limited by several factors whose associated delays would seem insignificant at the bench:

• DUT settling times—the delay between application of a test stimulus by the tester and the time at which DUT responses become valid,

• delays inherent in your instrumentation, and

• the speed of the mechanical actuators or human operators who insert DUTs into and remove them from a test fixture.

With regard to DUT settling times, you might need to experiment at the bench to determine how long you must wait after applying a stimulus for your DUT to develop a stable output. If you don’t allow an adequate settling time in your production system, the system might reject many good parts whose outputs would have fallen within your programmed “pass” range had the test lasted a fraction of a second longer. If you allow more than enough time, you’ll reduce throughput or perhaps risk false rejections because of DUT self-heating effects.

Instrument settling times, too, come into play. For instance, if your instrument drives a light source such as an LED to develop a DUT stimulus, you might need to wait for the transducer to stabilize before allowing your instrument to read the resulting DUT output. You can evaluate the required settling time using an oscilloscope.

In addition to potential delays in their abilities to generate appropriate stimulus levels, test instruments have a variety of housekeeping settings that affect test speed. Autoranging is one culprit. If you set all of your source and measurement ranges manually or with a command from your PC-resident test program, you can drastically increase test speed.

If you allow the instrument to autorange (that is, automatically determine the optimum full-scale range based on a measured signal), your tests will take much longer.

Review your instrument’s documentation carefully to identify other settings that can affect speed. Keep in mind, though, that sometimes increases in instrument speed come at the cost of measurement accuracy. Once again, experiment at the bench to determine the optimum speed/accuracy tradeoffs.

Automated Fixtures

For low-volume production runs, you might find it most cost-effective to have a technician insert DUTs into a fixture, initiate tests, and place tested DUTs in “pass” or “fail” bins. For high volumes, you’ll most likely want to automate the process to increase test throughput. This automation includes the use of solenoids or stepper motors to control part placement, sensors to determine if a part is in place, relays to switch in any test loads your test program might require, and binning to sort parts into pass, fail, or category bins in response to test results. To control these actuators and to monitor fixture sensors, you can use a computer plug-in digital I/O card.

I generally use one of the readily available cards that emulate an industry-standard 8255 programmable-peripheral-interface chip, which provides three 8-bit I/O ports. To use such a card, you plug it into your PC and hardwire your I/O devices to the 8255-compatible I/O ports. Keep in mind that you’ll be controlling and monitoring a variety of devices that could require driver and signal-conditioning circuitry in addition to that which resides on the I/O card. You’ll probably want to place that circuitry and its associated power supplies in a chassis separate from your PC.

Figure 1. You can use a virtual debug panel such as this one to monitor the condition of digital inputs and outputs. This panel displays outputs to a stepper motor plus inputs arriving from test-fixture sensors.

This external chassis can handle the various voltage and current levels required to perform the work of manipulating your test fixture and DUT. Within the programming environment of your PC, however, those voltage and current levels reduce to well-behaved logic levels such as those depicted in the virtual panel of Figure 1, which I generated using TestPoint, a test-program-development package from Capital Equipment Corp. (CEC; Billerica, MA).

Test-program-development packages let you control I/O states.² You make appropriate bit assignments in accordance with how you hardwired your I/O board to external actuators and sensors. Your test program sends out a control word that designates your input- and output-port combinations. It then writes control signals to designated output ports and reads sensor responses on input ports.

Figure 1 illustrates a generic TestPoint routine, handy for test-system setup and debug, that allows you to change the output of one bit while keeping the other bits in their current state. Similarly, the routine can read in the status of an input bit.

In Figure 1, output bits control a stepper motor that brings a fiber-optic cable in position to test a DUT. The ability to call external code from TestPoint can also solve some production speed problems when a Windows environment is not fast enough. Originally, I controlled the stepper motor from TestPoint to find its home position. That was fine for one-time initialization, but I found that to run at production speed, I had to call an external DLL from TestPoint to test each DUT.

Figure 2. In addition to performing electrical tests, an automated production-test system must control the operation of test-fixture components. The program segment represented here brings a DUT into position, tests it, and deposits it in a pass or fail bin.

Output bits also control other devices such as solenoids that bring test probes in contact with the leads of a DUT (“DUT Contact”) and that deposit a tested DUT into pass (“Good Bin” bit equals 1) or fail (“Good Bin” bit equals 0) bins. The input bits report sensor readings such as those signaling whether the stepper motor is in its home position (“Home” input bit), whether a DUT is in place for test (“Part in Place” input bit), whether the tester chute is jammed (“Chute Clear” bit), and whether the chute is in proper position for depositing the part in the appropriate pass or fail bins. The program-segment example diagrammed in Figure 2 illustrates a test sequence that makes use of these I/O bits.

If you wish to add a bit or change a bit to fit your particular application, all you have to do is assign the designations you want to the proper port and bit, then make sure you hardwire your devices with the same bit assignments. You can then use these bit values in your program. The “Air Blow” output bit in Figure 2 represents one such alteration I employed in one of my programs. I added it in response to test-yield problems caused by fiber-optic-tip contamination. This bit activates an air jet that clears the contamination before the cable tip mates with the DUT.

The need for features such as an air jet that blows away contamination isn’t something you can learn in the classroom. Universities don’t offer courses such as “IEEE 488 Programming for Every Production-Test Eventuality.”

Fortunately, programmable instruments and test-program-development software are sufficiently easy to use and flexible enough so you can adapt to changing test requirements on the fly. Don’t worry about not knowing up front how to best test a particular device—dive right in and enjoy the ride along the way. Suffice it to say that test-program-development packages will allow you to build a digital I/O software interface that you can use over and over again to rapidly develop new test applications. T&MW

FOOTNOTES

1. Holland, Nancy, “Automated Instruments Smooth Rapid Test System Development,” Test & Measurement World, August 2000. p. 49.

2. Nelson, Rick, “Blend Text and Graphics to Create Test Programs,” Test & Measurement World, October 15, 2000. p. 6. 

ACKNOWEDGEMENT

The author would like to thank Norris Lauer, senior engineer at Optek Technology, for his comments on this article.