Tech
Note

Therefore, please consider each of the following techniques that I use to bring high-quality programs and fixtures to completion.

Technique #1 - Using the Default ICT.TST File

Customizing the default ICT.TST file can assist the efficiency in generating test programs.  The default ICT.TST file in Teradyne’s Z18XX environment is in the \TPD\(SKEL) directory, and it is the file that is used when a new test program is generated.  Teradyne sets this file up as an empty shell that holds the test worksheets like MicroSoft would set up an empty Excel file.  There is no data in the file except for the Header and the Trailer.  As you probably learned on the first day of Z18XX training, this file is write protected, but it can be modified if the Attributes are changed.

Several items can be customized by setting them to default, such as:

Fixing the Header to show common Displays such as the Board’s Part Number, the Board Name, a list of untested devices, and a list ‘no-load’ parts.

Enabling datalogging and other PRGMVARS setting per your designs.

Checking the ID Resistors in the fixture.

Enabling the Board’s test time or other data to be displayed at the Trailer.

Turning on the Power Supplies to a default state.and much more.

Go to the Drive where the Teradyne software resides.

CD \TPD\(SKEL)

ATTRIB -R ICT.TST

What I do is create a special version of the ICT.TST file in the (SKEL) directory which is customized with my favorite options and settings.  Since many of my Customers have facilities in Mexico, Texas and Florida, I have found it convenient to give the Operator the option of working in Spanish.  I use Option 7 to determine this;  if it is set, all information to the CRT and Printer is done in Spanish;  if it is not set, the information is in English. 

Please see the adjoining captured Z18XX  screens to see how this is done.

Another example of the usefulness of customizing the default ICT.TST file is to add a test step in the Discharge Section that confirms that the Operator has properly set up the test.  Did the Operator:

Put the proper fixture on the test head?

Select the correct test program?

Vacuum down the fixture?

Correctly loaded the appropriate board to be tested?

Selected either ‘Auto’ or ‘Manual’ for vacuum fixtures?

A simple means of testing a small resistance is to use the Stim V Meas V mode.  By applying a test voltage (using 200mV through a 10 Ohm buffering resistor) on one side of the device, measuring the same side of the device, and guarding the other side of the device (per the attached worksheet), a low resistance will usually measure 25mV.  A large resistance will measure 200mV (since there will be no voltage drop across the buffering resistor).  This measurement technique is a good way to measure a low or high impedance.  This is done in lieu of a standard resistance measurement because a missing part will read “Over Range”;  this way a missing part will read a standard 200mV.

I write a test called VACUUM that will check our five (5) items above.  This is a two-page test, and failures are ignored to allow the Operator to correct the problem without starting over.  On the first page, I find it convenient to communicate (in I/O Control under “Pre”) to the operator the UUT’s name and part number.  Then I perform the test on the small resistance, and, under “Post”, I will jump to the Next Step if the test passed.  If it fails, it will naturally go on to the Next Page, where I enter an endless loop repeating the test from Page 1 and waiting for the operator to correct the mis-match.  When the test is passing, the Operator can merely strike START.  I clear all failure flags, and continue the test with everything matching.  They can press CANCEL if there is a mis-match that needs to be corrected.

The point is that is takes but a few moments to set these tests up since they are already built into the default ICT.TST, so when PGEN was run, this test is already there.  All I have to do is change the node numbers and write into the Description field the name of the device being checked.
 

The Z18XX in-circuit testers have the capability of measuring frequencies with a digital pin.  It has become increasingly important to test crystals and oscillators for the proper frequency, not just for presence.  One reason for this is the use of Surface Mount crystals, which are easily misplaced, and have a tendency to physically break during the wash cycle of SMT manufacturing.  The oscillating device is very fragile, so if the tubes of crystals/oscillators are jolted, or if the board is handled roughly, the output may be dead.  When the oscillator is dead, a microprocessor-based board will not boot, and it is sometimes difficult to discern between no clock and a stuck-at bit on a data or address line.

Another important reason to check for proper oscillation is that the Motorola 68000 family of Microprocessors will burn themselves up without a clock.  (Refer to the warning regarding the clock input in Motorola’s 68XXX manuals.)

Although it is quite convenient to be able to measure frequencies with a digital pin, there are some "tricks" in achieving consistent results.  Anyone that has attempted to correctly measure frequencies knows that it is very difficult, even with IEEE counters.

If the following three (3) approaches are used, you may have good results on measuring frequencies:

1. For Crystals, the probes must be removed or isolated.  (To be “isolated” means that a relay is in the fixture that will remove the tester Nodes from the pin during the frequency measurement.)  For Oscillators, the test will work better if the probes are isolated or removed. 
2. When possible, the measurement should be made at a point in the circuit that can drive the signal to the tester, such as the ALE (Address Latch Enable, such as the Intel 80C31,32,48,51 family) or the /AS (Not Address Strobe from the Motorola 68000 family) signals from a Microprocessor or the output of a divide-by circuit.  If there are no on-board devices to use, then add a buffer (such as a 74'244 driver) to the fixture.
3. Use the Gray Code test as shown below.  Notice how tight the tolerances can be for stable circuits. 

Non-multiplexed testers feature the convenience of allowing the node assignment to occur before the test program is designed for efficient debug.  On GenRad and Hewlett-Packard Testers, you cannot assign nodes until the digital guarding is completed!  Yuk!  So on the Z18XX, when I generate a test program, I always assign nodes semi-randomly, and perform a series of steps that will enhance my efficiency during Debug.  I call this process “Pre-Debug”.  This enhances my efficiency because this can be done while I am waiting for the fixture to be built.

During the Node Assignment stage, I like to assign nodes per the following list:

Ground is Node 1.

+5V is Node 5.

-5V is Node 8.

-12V is Node 10.

+12V is Node 12.

Delta-Scan and Kelvin Ground is 16.

-48V Return is Node 47.

-48V is Node 48.

Following are the steps that I go through during Pre-Debug:

1. Double-check PRGMVARS in Header to ensure that all setting are correct for this board, including the VACUUM setting, the node numbers for Ground Reference and Delta-Scan are correct, etc.
2. Change the displays to the Operator for the Board Name, the Board’s Part Number, the Untested Devices, the Devices that are Not Installed, and how to set Switches/Pots/Jumpers.
3. Customize my VACUUM test in Discharge section to use the correct Node Numbers and to display what device is used to perform the VACUUM test.
4. Change the ID Resistor section, if needed.
5. For the Passive Section PGEN will usually do a good job, so I just ensure that any unusual tests (like strange Resistor-Packs) are valid, and that Kelvin Measurements are set as 6-wire.  I also enhance PGEN’s documentation of parallel tests such as when resistors are in parallel with capacitors.
6. PGEN also does a good job for the Semi Section, except I always change the Leakage Test current to 10?A instead of the default 1?A.  I also change the Zener test to be a three-page test, including a forward drop test on page 1 (jumping to the Next Step if failed), then testing the Zener clamp voltage, and finally performing a discharge.
7. In the Analog Section, tests need to be written for Transformers, Opto Isolators, Relays, and any other unpowered device that is not tested elsewhere.
8.  The Bd_Power section is customized from the test that came from the Default (SKEL) ICT.TST file.  If the UUT has any on-board Power Supplies or Voltage Regulators, I would  add a Power Bus test to check the output voltages, and also I would add the Description fields to describe which devices to repair for failing tests.
9. Linear tests would be written for Op Amps where possible to check for linearity.
10. Digital Disables would be written to ensure all digital devices are either set to a known state or tri-stated.  PGEN does a fine job for devices in their Library, so I always ensure that all possible devices are disabled.
11. Digital Section is verified to ensure all devices have a proper and thorough test routine.  If not, it is either written or flagged to be written when the fixture is available.

We often see cases where boards are built in a Panel, where the automatic placement machines are loading several boards at once.  It is sometimes convenient to test them when they are panelized since it removes the cost burden in labor for the handling time.  Some boards are panelized with as few as two boards on a panel (which is termed “2-up”),  and I have seen as many as sixty-three to a panel (“63-up”).  There are several guidelines which need to be considered when testing panelized boards, which include:

The Teradyne Software has an outstanding tool for Multipanel Boards under the Files menu.  You would typically have a directory for each board on the panel, and an extra program directory (often called MASTER) that will call the test program for each board using the CHAIN command.  The Chaining can be from the Header or the Trailer.  The test programs for each board on the panel should be written so that the START and other functions are used only when you are not in a sub-program.

Realize that your yield will be lower.  If you are running a 10-up panel, and if the individual board has a yield of 97%, then your yield for the panel will be 0.9710, which is only 73.75%.  Therefore, instead of 3% of your boards being kept for repair, 24% are kept as panels in the repair loop!

Boards tend to break out of their panels, so it is important to ensure your fixture can test an individual board.  A good means of doing this is to have your fixturing vendor make a special well for the individual board, and wire it in parallel with the first board in the panel.  The first test program can then be executed if a single board test is needed.

Realize that the raw card vendors will have manufacturing defects, and these boards will usually have an X drawn over the board.  The automatic insertion machines will pick up this X with Optics telling the machine not to load parts on that board.  A term that is used for this is an “X-Out”.  The Test Engineer needs to be aware of X-Out possibilities by providing a means of skipping a test if a board is not loaded.  Two means exist for solving this:

1. Let the Operator enter the board number(s) that have X-Outs.  Use Option or User Flags to skip the test from the MASTER Program.
2. Automatically test to see if parts are loaded by using Ignore Failure, and testing a few parts to determine if they are present.  If several devices are not present, report an X-Out;  if at least one is present, continue the test.

If a board fails the test, it is wise to re-test the entire panel.  The basic reasoning is that the board has been touched with a soldering iron, and perhaps more than the failing board was modified!

Some Users have found it awkward to use a different directory for each board, so be aware that these can be merged into one program.  This has another advantage of a faster test time if all devices are tested together.  For example, on a 16-up panel, if all the R1 devices are tested together, then the autoranging hardware is set for all 16 tests, and the test will be faster.  It is cumbersome to generate a program this way because somehow you have to distinguish the board number being tested.  Some Users will use a nomenclature in the ID field like “R1 (1)” for R1 on the first panel;  other Users will have the board number under the Name or the Description.  It would also be necessary to handle X-Out Boards with the Flow Control for every test.  This is a myriad of work, but can be useful in high-volume applications to simplify changes and to reduce test time.

Power wiring can be difficult for panelized boards.  It is obvious that power should not be wired in parallel for each board, or all the Power Capacitors will be in parallel.  I would usually wire power through User Relays (K1 - K12 on the RAB) for panels that are 12-up or less.  You can usually wire all the grounds together for all the boards on the panel.  For boards that are 12-up or more, you will usually need to add fixture relays to compliment the User Relays.

Care should be taken to easily identify the failing board(s).  This is most easily done by changing the Report Prefix in PRGMVARS to reflect the board number. 

Lastly, be aware that panelized boards will take a larger number of tester pins, so be sure that the number of nodes on each board times the number of board on the panel are less than the tester pins available.  Notice also that is very convenient to allow the offsets to be in even numbers, so a four-up panel could have the first board starting at Node 0, the second at Node 200, the third at Node 400, and the fourth at node 600 (remembering you will need a tester with about 800 Nodes for this).