Keysight i3070 In-Circuit Test System

Release to Production

Final Steps for Optional Test Methodologies 2

Implement Optional Features 12
Support Production Testing 25
ECO Process on the UnMux System 31
ECO Process on the Mux System 33

This guide provides instructions to:

• Release the test and fixture to production.
• Support production testing.
If the target test system is an i3070 Series 5i inline system,
also see Production Setup and Testing for the system.

Before using this guide, you should already have:

• Completed any unfinished (setup-only) tests.
• Evaluated and debugged all tests.
• Used the Board Test Grader to evaluate how well the tests are working and to
determine fault coverage of your test.
Once you have successfully evaluated and debugged the
tests, it is recommended that you back up the board directory
after removing any unnecessary files and directories from the
directory.
Final Steps for Optional Test Methodologies
Before releasing the test and fixture to production, note the additional concerns and
steps if using these optional test methodologies:
• Multiple Board Tests
• Multiple Board Versions
• VTEP/TestJet
• Connect Check

2 Release to Production
 Multiple Board Tests
Additional considerations exist when using statistical quality control and for
Dual-Well Shared Wiring.

Using Statistical Quality Control

For Panel Test and Throughput Multiplier, the testplan maintains separate
information for each individual board and for the panel itself. It does this with the
board number is statement. The board number for the panel is always zero (0).
Individual board boards are numbered sequentially from 1 to 256. The following
information is maintained under each board number:
• datalogging buffers
• list of failing devices for probe failures
• report buffers
There is a BATCH record and a BTEST record in each board's buffer and also in the
panel's buffer. Panel data is logged to the panel buffer; board data is logged to the
corresponding board buffer.
The log board statement is enhanced to include parameters for the panel type and
the panel type revision. These parameters are added to the BATCH log record to
specify that the board is contained in a panel, and to identify the panel that contains
the board.
The log board start statement is enhanced to include the panel id. The panel id
is added to the BTEST record to identify the panel that contains the board.
Datalogging is described in Information Management.

Dual-Well Shared Wiring

It is important to train operators to be careful when changing boards on the test
fixture while another board is being tested. A board being removed from, or placed
on the test fixture must not contact the fixture probes. The operator should examine
the board to be sure there are no long leads or device pins protruding from the
bottom (circuit side) of the board. The operator should not press down on the board
being removed or added.
If a board being removed from, or placed on the test fixture contacts the fixture
probes while another parallel-wired board is being tested, tests fail and the
boards and testhead may be damaged.

When performing an ECO be sure that the change is made to all applicable board
locations on the fixture. If you need to remove a wire, be sure to remove all parallel
occurrences of that wire.

Release to Production 3
 Multiple Board Versions
Before releasing the test and fixture to production testing, adapt the following
procedures for multiple board versions:
• Operator Prompting
• Datalogging
• PushButton Q-STATS

Operator Prompting
The test program will prompt the operator for the version of the board to be tested.
You can specify either of two prompting methods with the Version_Prompting
parameter in the Set_Custom_Options section of the testplan. They are:
• Version_Prompting = Per_Board
Asks the operator to enter the board version before each board is tested. Use
this command when the boards arrive at test in random versions.
• Version_Prompting = Per_Run
Asks the operator to enter the board version only after the testplan is first
loaded. Use this command when boards arrive at test in batches of a single
version. To change to another version, the operator presses STOP and then
RUN to reload the testplan and specify a different board version.

Datalogging
Datalogging for multiple board versions requires that board serial numbers be
unique between versions.
Use the version label parameter with the log board statement to specify a board
version. Do not confuse this version parameter with the revision parameter. The
log board statement adds the version label to the @BATCH log record for PushButton
Q-STATS as shown below.

Example 1 log board statement format

log board <UUT_Type>, <ProcStep>, <BatchID>, <Operator>,
<UUT_TypeRev>, <TestplanID>, <TestplanRev>, <ParentPanelType>,
<ParentPanelTypeRev>, <Version_Label>

Example 2 @BATCH log record format

{@BATCH|UUT type|UUT type rev|fixture id|testhead number|testhead
type|process step|batch id|operator id|controller|testplan id|testplan
rev|parent panel type|parent panel type rev|version label}
For example:
{@BATCH|9984-14|A|2550|1|btest|5|8911|pete|achilles|MaxWell|7|Panel_2|
B|Version_3}

4 Release to Production
 See Log Record Format in Data Formats for complete information about the @BATCH
log record.

PushButton Q-STATS
PushButton Q-STATS uses the version label in the @BATCH log record to track the
data for base boards and version boards. The version label identifies the version,
while a null version label identifies the base board.
Each tested board is listed in the PushButton Q-STATS database as a separate
board. The base board is listed as the board name, and each version board includes
the version label. For example:
memory
memory:version_1
memory:version_2
Pushbutton Q-STATS cannot generate a histogram or failure pareto across versions
of boards because the test limits might vary between versions.

VTEP/TestJet

Set up Datalogging
If you are using datalogging in production testing, be aware of a new data logging
record that describes the results of TestJet tests. When pin logging is in effect, the
record includes an @DPIN subrecord indicating which device pins failed.
The datalogging record format is as follows:

Table 1 @TJET datalogging record

{@TJET|test status|pin count|test designator}

Field Type Defaul t Comments
test status int 00 00 = pass
01 = fail
07 = fatal error
pin count int 0000 number of failing pins
test designator str ““

Subrecords:
@DPIN — Generated when logging pins to list the failing device pins.

For more information on datalogging records see Log Record Format in Data
Formats.

Release to Production 5
 Prepare the testjet File (Mux Systems)
1 Provide failure messages with the failure message statement. Failure
messages must be placed outside the device/end device blocks. Failure
messages are in effect until another failure message is specified, or until the
failure message default statement is executed. The failure message
default statement instructs the system to resume using the failure messages
from the board file.
Use the report limit statement in the testjet file to limit the number of
failing pins listed on the report is device. For example, if you are testing a
device with a large number of pins, you might want to limit the report in case
the device is missing. The syntax of the report limit statement is:
report limit <number of pins>
In Example 3, the report limit is set to 5. The failure message for U101 is
overridden with a failure message statement. Just before the test for U102,
the failure message default statement instructs the system to resume using
failure messages from the board file.
VTEP: The failure message and report limit are not copied to the new test
source. They still work if the user enters them manually and re-compiles. These
changes will be lost if ADB is run again.

Example 3
default threshold low 20 high 10000
default throughput adjustment 1
report limit 5
failure message "U101 also tested with digital library test."
device "u101"
test pins 1
test pins 2,3
test pins 4,5,6
! test pins 7 ! Ground pins commented by IPG.
. . .
! test pins 14 ! Fixed pins commented by IPG.
end device
failure message default
device "u102" bottom
test pins 1
test pins 2
test pins 3,4
test pins 5
test pins 6
! test pins 7 ! Ground pins commented by IPG.
test pins 8,9,10
. . .
! test pins 14 ! Fixed pins commented by IPG.
end device

6 Release to Production
 2 Enable throughput adjustment to increase test throughput by instructing the
system to make faster TestJet measurements.
If throughput adjustment is enabled and the pin being tested measures well
within the test limits, the test moves to the next pin to be measured; if the pin
being tested measures near, or outside, the test limits, the test measures the
pin again with a standard, longer measurement.
IPG enables throughput adjustment for all TestJet measurements. You can
specify throughput adjustment for an entire test with the default throughput
adjustment statement; you can override the default for specific devices or
pins. See Example 4.
For details on the throughput adjustment flag, see test pins (VTEP) in Syntax
Reference.

Example 4
default threshold low 20 high 10000
default throughput adjustment 1
! Specifies throughput adjustment for all devices.
device "u101"; throughput adjustment 0
! Turns off throughput adjustment for U101.
test pins 1
test pins 2
test pins 3
.
.
.
! test pins 14 ! Fixed pins commented by IPG.
end device
device "u102"
test pins 1
test pins 2; throughput adjustment 0
! Turns off throughput adjustment for pin 2 only.
test pins 3
.
.
.
! test pins 14 ! Fixed pins commented by IPG.
end device

3 If you edit the testjet file, be sure to resave and compile the file.
re-save "testjet"
compile "testjet"

Release to Production 7
 Connect Check
When you are ready to release the test and fixture to production testing, there are
three additional concerns for Connect Check.
1 Prepare the connectcheck file.
a Add failure messages.
When a device fails, the test system processes the failure message that is
specified in the board file. You can override the failure messages with the
failure message statement. Failure messages must be placed outside the
device/end device blocks. Failure messages are in effect until another
failure message is specified, or until the failure message default
statement is executed. The failure message default statement instructs
the system to resume using the failure messages from the board file.
b Limit the number of failures reported.
Use the report limit statement in the connectcheck file to limit the
number of failing pins listed for each device. For example, if you are testing
a device with a large number of pins, you might want to limit the report in
case the device is missing. The syntax of the report limit statement is:
report limit <number of pins>
In Example 5, the report limit is set to 20. The failure message for U101 is
overridden with a failure message statement. Just before the test for
U102, the failure message default statement instructs the system to
resume using failure messages from the board file.
c Re-save and compile the file.
re-save "connectcheck"
compile "connectcheck"

Example 5
guard "Vcc", "+5V"
reference return "GND"
learn threshold 1000
test limit multiplier 0.33
response voltage 0.9
stimulus voltage 1.2
report limit 20 ! Failure report limited to 20 pins.
failure message "Connect Check test failed."
device "u101"
no test pins 7,14 ! Pins tied to fixed nodes
no test pins 4,11 ! Pins have no node associated
no test pins 5,6 ! Pins are (in)directly tied to
! the same node
test pin 1
stimulus pin 9, 1839
stimulus pin 5, 1568
stimulus pin 10, 1382
stimulus pin 3, 1283
stimulus pin 6, 1189
stimulus pin 13, 1009

8 Release to Production
 end test
.
.
.
end device
failure message defaul ! Set failure message back to default
device "u102"
.
.
.
end device

2 Set up datalogging.
The format of the @CCHK datalogging record for Connect Check tests is as
follows:

Table 2 @CCHK datalogging record

{@CCHK|test status|pin count|test designator}

Field Type Defaul t Comments
test status int 00 00 = pass
01 = fail
07 = fatal error
pin count int 0000 number of failing pins
device designator str ““

Subrecords:
@DPIN — Generated when logging pins to list the failing device pins.

For more information on datalogging records see Log Record Format in Data
Formats.
3 Maintain the fixture.
As the test fixture is used in production testing, it needs periodic maintenance.
Because Connect Check is sensitive to contact resistance, you need to be sure
that you maintain clean and sharp probes in the fixture.

Release to Production 9
 Polarity Check

Set Up Datalogging
If you are using datalogging in production testing, you should be familiar with the
datalogging record that describes the results of Polarity Check tests.
The @PCHK datalogging record is used with Polarity check.

Table 3 @PCHK datalogging record format

Field Type Defaul t Comments

test status int 00 00 = pass
01 = fail
07 = fatal error
test designator str ""

For more information, see Datalogging.

Prepare the polarity File (Mux Systems)

When a device fails, the test system processes the failure message that is specified
for that device in the board file. You can override the failure messages with the
failure message statement. Failure messages are in effect until another failure
message is specified, or until you execute the failure message default statement.
The failure message default statement instructs the system to resume using the
failure messages from the board file.
If you edit the polarity file, you must re-save and compile the file. Use the
following statements to accomplish this:
re-save "polarity"
compile "polarity"

10 Release to Production
 DriveThru
Failure tickets indicate the pin on the DUT, the series component, the node, and
BRC used to perform the test.
The repair operator should:
• Inspect both the DUT and the series component for obvious problems. Some
potential defects could result from an open, a missing part, or an incorrect
part. Repair or replace the problem and retest.
• If the DUT is expensive and/or the replacement process is expensive, replace
the inexpensive series device and retest.
• If the retesting is more costly than replacement, replace both the series device
and the DUT.
• Verify that tests are stable, repeatable, and not producing false failures or
passing faulty parts.
• Examine the data logging reports in Pushbutton Q-Stats. These log files and
identify VTEP/DriveThru test failures.

Release to Production 11
Implement Optional Features
Before releasing the test and fixture to production, implement the optional features
you may require.
• Enable Optional Test Features
• Customize Operator Interface and Output
• Display Board Graphics

Enable Optional Test Features

Table 4 lists the optional test features that can be enabled for production testing.
To set these features, edit the Usage Flags and Other Parameters sections in the
testplan (Example 6).
1 Load the testplan in a BT-Basic window.
2 You can locate the custom section by typing:
find "sub Set_Custom_Options"

3 Set the options.

4 After setting the options, be sure to save the testplan.

Table 4 Optional test features

Option Description
Datalogging Datalogging is the process of collecting board test data as boards are tested. The data is
used by the Pushbutton Q-STATS software to generate SQC (Statistical Quality Control)
reports.
To turn on datalogging, do the following:
1 Set the QSTATS_Mode flag to No_Histo or Histo.
2 In the Other Parameters section, set the Analog_Sample_Rate parameter to a
non-zero value.
For more information, see Datalogging.
CHEK-POINT CHEK-POINT determines if the board under test is making contact with the fixture.
• To set CHEK-POINT to be executed every time, set the Chek_Point_Mode flag to
Pretest.
• To execute CHEK-POINT on failed devices only, set the flag to Failures.
For more information, see Ensure fixture is making contact with testhead.
Repair Tool If you intend to use the Repair Tool, set Using_ART to True.
Failure Reporting The Using_Buffered_Reporting flag determines whether failures are reported
during board handling. It is enabled by default.
Flash and Device To enable Flash and device programming, set Programming to True.
Programming

12 Release to Production
Table 4 Optional test features

Option Description
Intelligent Yield To enable Intelligent Yield Enhancement Test (IYET), set Using_IYET to True and, if
Enhancement Test necessary, modify the IYET parameters.
IYET re-tests only failing tests, unlike standard testing. On testplan failure, it saves the
failing tests, cycles vacuum and re-tests the failing tests only. This is repeated N times, or
until all failing tests pass. You can set the number of re-test attempts (N) for different test
types, for example, IYET_Shorts_Attempts = 3. See Example 6 for the test types.
• If IYET_attempts is set to 0, IYET is not used for the test. The test is executed once
and the result is logged.
• If IYET_attempts is set to 1, the test is executed, then repeated once. Only the last
re-test result will be logged.
Worst Probe Report To report on probes connected to failing tests (pins, shorts, unpowered analog tests, and
VTEP/TestJet tests), set Using_WPR to True. See Worst Probe Report (WPR) for a
sample of the report.
Other parameters
Report_Printer$ Choose whether to send reports to the strip printer or to the operator screen.
Testrev$ Specify the revision number for the testplan.
Analog_Sample_Rate Used for datalogging.
Serial_Length Specify the length of the board ID number (for barcode scanning).
Version_Prompting For multiple-version board testing only. Specify when to prompt the operator for the board
version to test - for every board, or only at the beginning of every run.

Release to Production 13
Example 6 Setting optional test features
!##############################################################################
sub Set_Custom_Options
! All variables likely to need to be changed are initialized here.
! The Usage flag(s) can be set True or False to selectively enable or
! disable the code needed for each indicated subsystem or feature.
global Using_ART, QSTATS_Mode, Testrev$
global Analog_Sample_Rate
global Serializing, Serial_Length
global Chek_Point_Mode
global Report_Printer$, True, False, Using_Buffered_Reporting
global Off, Pretest, Failures, No_Histo, Histo
global Per_Run, Per_Board, Version_Prompting
! IYET, WPR
global Using_IYET, IYET_Shorts_Attempts, IYET_Analog_Tests_Attempts
global IYET_Report_On, IYET_VectorlessTest_Attempts, IYET_Preshorts_Attempts
global Using_WPR

! Usage flag(s)

QSTATS_Mode = Off ! Choose {Off, No_Histo, Histo}

Chek_Point_Mode = Failures ! Choose {Off, Pretest, Failures}
Using_ART = False ! Repair Tool.
Serializing = False ! Will get set True if Using_ART.
Using_Buffered_Reporting = True ! Report failures during board handling
Programming = False ! Execute Flash and device programming.
Using_IYET = False ! Intelligent Yield Enhancement
! Test (IYET)
IYET_Report_On = True ! Create & display report on breaks
IYET_Preshorts_Attempts = 3 ! Preshorts re-test attempts
IYET_Shorts_Attempts = 3 ! Shorts re-test attempts
IYET_Analog_Tests_Attempts = 3 ! Analog unp. re-test attempts
IYET_VectorlessTest_Attempts = 3 ! VectorlessTest re-test attempts
Using_WPR = True ! Worse Probe Report (WPR)

! Other parameters

Report_Printer$ = btgetenv$("RPR"&th$) ! Final report destination

!Report_Printer$ = "/dev/tty" ! Send reports to the screen
Testrev$ = "RevA" ! Update this faithfully
Analog_Sample_Rate = .10 ! Meaningful if QSTATS_Mode = Histo
Serial_Length = 28 ! Board Id Length (0 = no checking)
Version_Prompting = Per_Board ! Choose {Per_Board, Per_Run}
! Used only on multiple version board
subend

14 Release to Production
 Customize Operator Interface and Output
Figure 1 shows the default Operator Interface. You can customize the following
features to suit your test environment:
• Display Setting for FPY/Worst Probe Report
• First Pass Yield (FPY)
• Worst Probe Report (WPR)
• User-Defined Buttons
• Text Output Formatting
• Parts of the Operator Interface and testplan can also be localized. For
information, see User Interface Localization.

Figure 1 Operator Interface: customizable features

Release to Production 15
 Display Setting for FPY/Worst Probe Report
To show or hide the FPY/Worst Probe Report display area upon the launch of the
Operator Interface, change the display setting in the properties file to true (show)
or false (hide).
The properties file can be found at:
$AgilentICT_ROOT\lib\properties\com\agilent\mtd\agt3070\application\oper

Example 7 Hiding the FPY/Worst Probe Report display area

############### Names and Labels ###############################
# To select FPY/WPR view each time Operator GUI is launched
Operator.mBar.FPYnWPR.show = false
####################

This display setting is for the initial launch of the Operator Interface only. The
operator can then change it from the View menu.

First Pass Yield (FPY)

The First Pass Yield (FPY) information displayed in the Operator Interface (Figure 1)
is based upon specific events from the execution of a testplan.
The testplan updates the FPY display based on the number of boards tested and
passed. The data is also recorded to a file FirstPassYield\first_pass_yield.txt
located in the board directory.
By default, a testplan generated using the i3070 In-Circuit Test Software will
contain the commands to display the FPY information (see Example 8 and
Example 9).
first pass yield 1,1 – boards tested, passed
first pass yield 0,1 – boards tested, failed

See also:
Clearing the FPY Counters
Changing FPY Parameters

Example 8 Code to display FPY information: Single board

if boardfailed then
if not Using_BtBasic then first pass yield 0, 1
! FPY: not passed, tested
print " ** ";Fail_Msg$;" **"
copy Fail_File$ over "/dev/tty"
if Status = Failed_Pin_Test then
print " ** ";Pin_Msg$;" **"
end if
if learning then Status = Failed_In_Learn
if Serializing then report Serial_Nr$ & Serial$
report using Eject_Ticket
if Using_Buffered_Reporting then report out

16 Release to Production
 else
if not Using_BtBasic then first pass yield 1, 1
! FPY: passed, tested
print " ** ";Pass_Msg$;" **"
copy Pass_File$ over "/dev/tty"

Example 9 Code to display FPY information: Multiple board panel

or I = 1 to Number_Boards_On_Panel
board number is I
if Status(I) <> Xed_Out then
if boardfailed then
if not Using_BtBasic then first pass yield 0, 1
! FPY not Passed and Tested
if Using_Graphics then
board graphics highlight fail board I, Err
else
Err = True
end if
if Err then print "Board "; I; " failed"
if Status(I) = Failed_Pin_Test then
print But$, I, " ** ";Pin_Msg$;" **"
end if
if learning then Status(I) = Failed_In_Learn
if Serializing then report Serial_Nr$ & Serial$(I)
else
if not Using_BtBasic then first pass yield 1, 1
! FPY Passed and Tested
if Using_Graphics then
board graphics highlight pass board I, Err
end if
end if
end if

Clearing the FPY Counters

The command first pass yield 0,0 will reset the counters for the number of
boards passed and tested to zero.
From the Operator Interface, the counters can be reset by selecting View >
Operator > Clear First Pass Yield.

Release to Production 17
 Changing FPY Parameters
If you wish, you can customize the first pass yield warning and alarm levels and
thresholds. Follow the steps below.
1 Change the parameters in the Operator_en_US.properties file as shown in
Example 10.
The contents of these scripts are user defined, not predefined. A typical action
would include notification of support personnel using email. If the script is
missing, no action will be taken for a warning or alarm level transition. The
scripts can be stored in any location within the user’s search path, for example,
$PATH.
Since any process can move up and down through a given alarm threshold,
care must be taken to provide a certain amount of hysteresis to prevent
multiple triggers from annoying the recipient of alarms. For example, if a value
drops below an alarm threshold of 90% it will not be re-armed until the value
exceeds 92% if the hysteresis is set to "2". Modify this value to meet your
process needs. For example:
fpy.hysterisis: 2
When a low number of boards have been tested it is too easy to reach alarm
levels. For example, if five boards have been tested and one has failed, the first
pass yield percentage would be 80%. This is below the default alarm level and
would trigger an alarm unnecessarily. A threshold, based on the number of
boards tested, defines when alarm triggers will be armed or enabled. Modify
this value to meet your process needs. For example:
fpy.armTriggers: 20
2 Save the Operator_en_US.properties file.
3 Restart the Operator Interface to test it and make sure the changes were
implemented correctly.

Example 10 First Pass Yield parameters

The following lines set the percentage at which a warning and an alarm level will be
indicated as being reached. Modify these values to meet your process needs:
fpy.warningLevel: 94
fpy.alarmLevel: 90

As the First Pass Yield drops below the warning or alarm level, individual Korn shell
scripts will be executed. The names of the scripts follow the ":" in the following lines.
fpy.warningDownTransitionAction: warningDownTransitionAction.ksh
fpy.alarmDownTransitionAction: alarmDownTransitionAction.ksh

As the First Pass Yield rises above the warning or alarm level, individual Korn shell
scripts will be executed. The names of the scripts follow the ":" in the following lines.
fpy.warningUpTransitionAction: warningUpTransitionAction.ksh
fpy.alarmUpTransitionAction: alarmUpTransitionAction.ksh

18 Release to Production
 Worst Probe Report (WPR)
The Worst Probe Report display area in the Operator Interface (Figure 1) lists the
probes connected to failing tests. It reports on pins, shorts, unpowered analog
tests, and VTEP/TestJet tests.
The worst probe report is turned on by setting the Using_WPR flag to True (see
Enable Optional Test Features for instructions). This adds the following command
to the testplan:
probe report on

i3070 In-Circuit Test Software releases prior to 07.00p adds the command before
the load board command. From release 07.00p, the probe report on command is
added after the load board command.
The generated report will be saved in the worst probe report subdirectory under
the board directory. Each row shows the failure type and number of failures (in the
Usage column), together with details of the probe and device.

Example 11 Worst probe report

Failure type |Probe |Usage |Node Name |Device Name |Date/Time |
----------------------------------------------------------------------------
Shorts Failure |P223 |1 |/U205-13 |tp605 |050317100805 |
Analog Failure |P50 |1 |/EEPROM_CLK |tp656 |050317100807 |
Analog Failure |P296 |1 |DCOM |tp787 |050317100807 |
Shorts Failure |P223 |1 |/U205-13 |tp605 |050317100815 |
Analog Failure |P50 |1 |/EEPROM_CLK |tp656 |050317100817 |
Analog Failure |P296 |1 |DCOM |tp787 |050317100817 |

Release to Production 19
 User-Defined Buttons
The Operator Interface allows you to define custom control buttons to suit your test
environment. The buttons that you can customize appear at the bottom left of the
operator screen (USER2, USER3, and USER4 in Figure 1).
1 Locate the Operator_en_US.properties file in
%AGILENTICT_ROOT%\lib\properties\com\agilent\mtd\agt3070\application\oper
2 Edit the user defined buttons section of the Operator_en_US.properties
file.
Example 12 shows how to label and set the USER2 button to run the Windows
calculator program.
3 Restart the Operator Interface to test it and make sure the changes were
implemented correctly.
4 Repeat this process until you are satisfied with the changes you have made to
the Operator Interface.

Example 12 Edit user control buttons

#################### user defined buttons #####################################
# user defined buttons
# If userControlActionListener is used as the actionListener, the command
# should be BT-Basic command.
Operator.opFM.mPnl.userDefinedPnl.user1Button.label: Browser
Operator.opFM.mPnl.userDefinedPnl.user1Button.actionListener: \

com.agilent.mtd.agt3070.application.oper.OperatorPanels.showBrowserActionListener
Operator.opFM.mPnl.userDefinedPnl.user1Button.enabled: false

Operator.opFM.mPnl.userDefinedPnl.user2Button.label: Calculator
Operator.opFM.mPnl.userDefinedPnl.user2Button.command: exec
"c:/windows/System32/calc.exe"
Operator.opFM.mPnl.userDefinedPnl.user2Button.actionListener: \

com.agilent.mtd.agt3070.application.oper.OperatorPanels.userControlActionListener
Operator.opFM.mPnl.userDefinedPnl.user2Button.enabled: true

Operator.opFM.mPnl.userDefinedPnl.user3Button.label: USER3
Operator.opFM.mPnl.userDefinedPnl.user3Button.command:
Operator.opFM.mPnl.userDefinedPnl.user3Button.actionListener: \

com.agilent.mtd.agt3070.application.oper.OperatorPanels.userControlActionListener
Operator.opFM.mPnl.userDefinedPnl.user3Button.enabled: false

Operator.opFM.mPnl.userDefinedPnl.user4Button.label: USER4
Operator.opFM.mPnl.userDefinedPnl.user4Button.command:
Operator.opFM.mPnl.userDefinedPnl.user4Button.actionListener: \

com.agilent.mtd.agt3070.application.oper.OperatorPanels.userControlActionListener
Operator.opFM.mPnl.userDefinedPnl.user4Button.enabled: false

20 Release to Production
 Text Output Formatting
HTML tags can be used in the report and print commands as shown below. The
supported HTML tags are listed in Table 5.

Example 13 Using HTML tags

print "<font color='green' style='background-color:yellow'>
<BIG>PASSED</BIG>"

report "<b>PASSED</b>"

The print statement formats the text in the Output panel as shown below:

Figure 2 Formatted text

Table 5 Supported HTML tags

HTML Tag Description

<B>text</B> Displays the text in bold.
<BIG>text</BIG> Displays the text in a larger size than the default.
<CENTER> text</CENTER> Centers the text on the screen.
<CODE>text</CODE> Displays the text in a fixed width font.
<EM>text</EM> Emphasizes the text by displays it in italics.
<FONT attribute>text Changes the font size, color, or face. The attributes are:
• SIZE=value, where value = integer from 1 to 7.
• COLOR=’value’, where value = hexadecimal value or color name.
For example, <FONT COLOR=’#0000FF’>text or <FONT COLOR=’blue’>text.
• FACE=’font1, font2, ...’ lets you specify one or more preferred fonts; the system uses
the first font in the list that is installed on the user’s system.
<H1>text</H1> Defines a level 1 heading. May contain the following:
• ALIGN=value, where value = left, right, or center
Sets the horizontal alignment of the heading.
• CLEAR=value, where value = left, right, or all.
Determines the position of text after an image; it specifies the margins to clear.
• NOWRAP prevents the system from automatically wrapping a long heading; use the
<BR> tag to insert line breaks where you want them.
<H2>text</H2> Defines a level 2 heading. May contain the same attributes as the <H1> tag.
<H3>text</H3> Defines a level 3 heading. May contain the same attributes as the <H1> tag.

Release to Production 21
Table 5 Supported HTML tags

HTML Tag Description

<H4>text</H4> Defines a level 4 heading. May contain the same attributes as the <H1> tag.
<H5>text</H5> Defines a level 5 heading. May contain the same attributes as the <H1> tag.
<H6>text</H6> Defines a level 6 heading. May contain the same attributes as the <H1> tag.
<I>text</I> Displays the text in italics.
<P>text</P> Starts a new paragraph. May contain the following:
• ALIGN=value, where value = left, right, or center
Sets the horizontal alignment of the paragraph.
• NOWRAP prevents the system from automatically wrapping the paragraph; use the
<BR> tag to insert line breaks where you want them.
<SMALL>text</SMALL> Displays the text in a smaller size than the default.
<STRONG>text</STRONG> Emphasizes the the text by displaying it in bold.
<STYLE=attribute> Changes the display attributes. Currently the only attribute allowed is the background
color:
• ‘background-color:value’ where value = hexadecimal value or color name.
For example, <style='background-color:yellow'>.
<SUB>text</SUB> Displays the text in subscript.
<SUP>text</SUP> Displays the text in superscript.
<U>text</U> Underlines the text.

Displaying Special Characters

To display special characters, use the following syntax:

Table 6 Special characters

Character Syntax
< &lt
> &gt

For example:
print "&lt;KEYSIGHT&gt;"

will display:
<KEYSIGHT>

22 Release to Production
 Display Board Graphics
You can invoke the display of board graphics to help the board test operator. When
the testplan is run from the default Operator Interface, any highlight device/nodes
statements automatically launches the ICT Browser, which presents a list of the
highlighted devices and nodes with the corresponding graphics display.
If the testplan is run from BT-Basic, use the statements in Table 7 to invoke a board
graphics viewer and highlight devices or nodes. See Example 14.

BT-Basic Statements for Board Graphics

For more information about these statements, refer to Syntax Reference.

Table 7 BT-Basic statements

Statement Description
board graphics Invokes a read-only version of the board graphics viewer to graphically display
features on boards.
board graphics display Switches from displaying a multi-board panel to displaying a single board on the
board panel.
board graphics display Switches the from a board view to a panel view (if the board is on a multi-board
panel panel).
board graphics end Terminates the board graphics viewer.
board graphics highlight Switches the board graphics viewer to a panel view and highlights a specified
board board in a color that denotes the board’s status (active, fail, or pass).
board graphics highlight Selectively clears highlighting (all, active, fail, or pass) in the board graphics
clear viewer.
board graphics highlight Highlights a specified device or pin on a device (device.pin) in a color that denotes
device the device's status as active, fail, or pass.
board graphics highlight Highlights all locations on a specified node. The highlighting can be in a color that
nodes denotes the node's status as active, fail, or pass.

Release to Production 23
 Example 14 Using board graphics to draw attention
! Beginning of the testplan
. . .
. . .
board graphics ! Invoke board graphics viewer.
. . .
. . .
wait for start
board graphics highlight clear all ! Remove any previous highlighting
. . .
. . .
if boardfailed then
if not Using_BtBasic then first pass yield 0, 1
! FPY Tested, not Passed
if Using_Graphics then
board graphics highlight fail board I, Err
else
Err = True
end if
. . .
. . .
. . .
! End of the testplan

24 Release to Production
Support Production Testing
This section describes the tasks that may be performed by the engineer during
production testing, and the tools provided on the i3070 In-Circuit Test System to
assist in these tasks.
• Monitor and improve your manufacturing processes.
Use the SQC tools described in Pushbutton Q-STATS.
• Verify the fixture and wiring.
Use the following tools during production testing and troubleshooting.
• find pins
Use to help verify the fixture before and during production testing. It finds
the connections to the node or device.pin that you touch with the guided
probe. See Using the find pins Feature in Verify the Fixture.
• probe
Use to check connections to a device during production testing. It displays
the pins of a device and indicates if there is a connection to each pin when
you touch it with the guided probe. This can be used interactively with the
testplan to check contact to a device if it fails. See Check connections to all
used pins of a device.
• CHEK-POINT
Use during production testing to determine if the board under test is
making contact with the fixture. This is a fast, coarse check, and should not
be used to determine shorts and opens. See Ensure fixture is making
contact with testhead.
• Debug and fine-tune tests.
When the testplan is idle, engineers can log in and access the Engineer Test
Interface to debug failing tests. (Press F9 to display the login dialog box.)
When you switch from the Operator Interface to the Engineer Test Interface,
note the following:
• For Pins, Shorts, and VTEP/TestJet, the status of passing tests will display
correctly in green.
• However, for Analog In-Circuit tests, passing tests are shown as not run.
The status of failing tests will display correctly in red.
For help in debugging, see Debug Flowchart.
• Maintain the test fixture
Test fixtures require maintenance and possibly repair after prolonged use.
Common problems include:
• worn or bent probes
• worn gasket material
• vacuum leaks around the board under test
• bent tooling pins

Release to Production 25
 You may need to replace and repair VTEP or TestJet probes and mux cards. If it
is necessary to remove the top side of the fixture, you can disconnect the
ribbon cable on the top-side mux cards to separate the two sides of the fixture.

Check connections to all used pins of a device

The probe function can be used during production testing to check the connections
to any failing device. If a device was not soldered well or if the board under test has
marginal probing areas, such as vias on a dense SMT device, use the probe function
to check connections to this device, if it fails. This determines if it is truly a bad part
or if one or more pins did not make contact during testing.
The probe function has two forms: probe <device> and probe failures.

Using probe <device>

The probe function checks the connections to all used pins of the specified device.
It checks devices that have up to 650 pins. The probe function displays the pins of
the device on the screen. The display indicates the pins that are used with an *
(asterisk), and the pins that are not used with a . (period).
To use the probe function, type probe "<device>" such as:
probe "U14"
As you probe each pin with the guided probe, the * changes to a p. After you remove
the guided probe the p changes to a T. If no contact is detected to a used pin, the
* remains on the screen. Example 15 demonstrates this.
This process does not require the use of the foot switch. You can probe the pins in
any order and repeat any that you want. Probe the devices carefully so that you do
not damage any device leads, especially on SMT devices.
The probe function applies 0.1 volt through a 10 ohm resistor to the point you touch
with the guided probe. It uses a 10 ohm threshold to determine a short.

26 Release to Production
Example 15 Probe report of a 28-pin device with 5 unused pins

Before probing the screen looks like this:

Probing Device: U14
Pins> 1 1111111112 2222222223 3333333334 4444444445 T Tested
1234567890 1234567890 1234567890 1234567890 1234567890 p Probe
------------------------------------------------------ * Untested
0 + ********** ****.***** **....**.. .......... .......... . Unused
As each pin is probed the * changes to a p:
Probing Device: U14.7, "CLOCK"
Pins> 1 1111111112 2222222223 3333333334 4444444445 T Tested
1234567890 1234567890 1234567890 1234567890 1234567890 p Probe
------------------------------------------------------ * Untested
0 + TTTTTTp*** ****.***** **....**.. .......... .......... . Unused
After each pin is probed the p changes to T. No connection was found for pin 10:
Probing Device: U14.28, "VCC"
Pins> 1 1111111112 2222222223 3333333334 4444444445 T Tested
1234567890 1234567890 1234567890 1234567890 1234567890 p Probe
------------------------------------------------------ * Untested
0 + TTTTTTTTT* TTTT.TTTTT TT....TT.. .......... .......... . Unused

Many times, more than one pin of a device is connected to the same node. When
you probe any of these pins a "p" appears for all pins that are on that node. The
report lists the lowest numbered pin. Note that since the threshold is 10 ohms, any
impedance less than 10 ohms looks like a connection.
For devices with more than 50 pins the display is repeated. The 0 + in the last row
increases by 50 each time. This indicates how much to add to the pin number. For
the first display, add 0 to the pin number. In a second display you would add 50 to
the pin number.
In Example 16, the first row displays pins 1 through 50, and the second row displays
pins 51 through 100 (50 plus the pin number). Since this is a 75 pin device the
display indicates that pins 76 through 100 are not used. In this example, pins 1
through 18 have been tested with no contact being found for pin 15. Pin 19 is being
probed, and the rest have not been tested yet.

Example 16 A probe report for a 75 pin device

Probing Device: U14.5, "CLOCK"
Pins> 1 1111111112 2222222223 3333333334 4444444445 T
Tested
1234567890 1234567890 1234567890 1234567890 1234567890 p
Probe
------------------------------------------------------ *
Untested
0 + TTTTTTTTTT TTTT.TTTp* **....**.. ********** *****.**** .
Unused
50 + ********** *....***** **..*..... .......... ..........

Release to Production 27
 Using probe failures
The probe failures function invokes the probe function on devices which failed
during testing. This determines if a failed device is defective, or if it was not
contacting the fixture properly.
1 Add the following line to the testplan before the device or devices you wish to
check:
save failures on
2 Add the following line to the testplan after the device or devices you wish to
check:
save failures off
3 Add the following line at the end of the subroutine to initiate probing of the
devices that failed while save failures was on:
probe failures

Softkeys for the probe function

Table 8 Softkeys definitions for the probe function

Softkey Command Description

F2 Abort Device Stop the probe function for the displayed device.
F3 Re-try Device Re-probe the displayed device.
F4 Next Device Move to the next failed device. This softkey is used only with the
probe failures statement.
F5 Hardcopy Printer Copy the screen to the printer is device.
F6 Report Untested List the untested pins on the report is device.
F8 Quit Probe End the probe function.

28 Release to Production
 Ensure fixture is making contact with testhead
To determine if the board under test is making contact with the fixture, invoke
CHEK-POINT in a BT-Basic window by typing:
test "pins"
You can also run the pins file from the Engineer Test Interface. For details, see
Debug Pins Tests.
1 In the testplan, turn CHEK-POINT on and off in the Usage Flags section.
• To set CHEK-POINT to be executed every time, set the Chek_Point_Mode
flag to Pretest.
• To execute CHEK-POINT on failed devices only, set the flag to Failures.
2 Modify CHEK-POINT to work on problem areas only, such as large SMT
programmable gate arrays.
To do this, modify the pins file or write a new one to include the nodes
corresponding to the problem area of the board or the device.
As shown in Figure 3, CHEK-POINT applies a 2.5 volt source to each node
through a 10K ohm resistor. As the source is applied to one node, all other
nodes are connected to ground. CHEK-POINT expects a leakage path through
the board under test. The resistance of the path is calculated by the current
through the 10K ohm resistor. Any resistance less than or equal to 1M ohms is
considered a connection.
In some cases the 2.5 volt source will reverse bias a diode. If this diode is the
only possible leakage path, CHEK-POINT sees an open. To avoid invalid
failures, any time CHEK-POINT sees an open it reverses the polarity of the
source. This would forward bias the diode and there would be a current path.
Problems can occur with small capacitors with one lead not connected to
anything or with resistors greater than 1M ohms with one end not connected
to anything. See C1 and R2 in Figure 3. To correct this problem, remove these
nodes from the pins file.

Figure 3 CHEK-POINT
100pF 10k 10uF 12M
U1
C1 R1 C2 D1 R2

A B C D E F G

10k

2.5V

Release to Production 29
 3 Add a report limit <#> statement as the first line in the pins file to instruct
CHEK-POINT to stop listing failures after the specified number.
This prevents a very long report when the entire board is not contacting the
fixture.
The failure report for CHEK-POINT shown in Example 17 lists the failure, brc,
node name, and all device.pins on that node.
4 When you edit the pins file you must save it.

Example 17 CHEK-POINT report

-----------------------------------------
CHEK-POINT Report for "pins".
Thu Dec 29 12:41:34 1988
07980-66521 11/03/87 Rev A3 BOARD
Tue Nov 03, 1987 10:08 am
-----------------------------------------
Failed Open #1
(20476) C68-2
C68.2
C69.1
R22.2
-----------------------------------------
Failed Open #2
(21410) U30-3
U30.3
-----End, 2 Problems Reported-----

30 Release to Production
ECO Process on the UnMux System
The ECO (Engineering Change Order) process is very similar to the new board
development process, except for the constraint that a fixture has already been built
and the i3070 In-Circuit Test Software should re-use as much of the current fixture
information as possible, in order to minimize any changes to the fixture.
It is wise to work with your design department closely when designing ECO
changes to the board. By sharing knowledge such as probe locations you can
minimize difficult changes to the fixture and save time in implementation.

These are the steps to follow in the ECO process:

1 Determine the extent of changes. These may include:
a Component values changed
If you are just changing component values, most likely there will not be any
fixture changes but there could be changes to additional tests other than
the changed parts, for example, due to guarding analysis. This can cause a
new shorts and pins test to be generated.
b Component addition or removal
This usually has an effect on surrounding parts and will cause a
regeneration of the tests affected. It will also generate a new shorts and
pins test.
c Nodes added
Adding nodes to the board/fixture will require that fixture modifications be
made or alternative test methods be employed to test the circuit. Fixture
modifications are difficult when it comes to drilling new probe locations.
Usually it is best to mark the new node as no access and to define some
type of node library test around the new nodes.
d Probe locations changed
This is the most difficult of all ECOs and should be avoided if possible. As
with adding nodes, fixture modifications are difficult when it comes to
drilling new probe locations. Sometimes it is best to mark the new locations
as no access and to define some type of node library test around the new
nodes.
2 Make changes to the board data using the Developer Interface.
a Unlock the development tasks.
b Make changes to the data in the Data Input phase.
c In the Fixture Generation phase, ensure that the fixture tasks are unlocked
and in ECO mode when you perform the tasks.
Failure to ensure that ECO mode is selected could make the
fixture unusable.

Release to Production 31
 3 Redo the test development tasks that do not have a checkmark next to them.
4 Check the output files for changes to the fixture.
a Review the fixture details.
b Make the changes to the fixture.
c Verify the fixture changes.
5 Debug the board.
6 Release to production.

32 Release to Production
ECO Process on the Mux System
1 Implement necessary changes.
You might need to modify the test, fixture, or both, due to engineering changes
during the life of the board. Some of the changes that can be required are:
• Changing the value of a device.
• Adding or removing a device.
• Moving an existing device to a new board location.
• Removing a probe location.
• Cutting a PC trace, possibly creating two nodes from one.
To implement these changes, edit the proper files and run the Develop Board
Test function of IPG Test Consultant.
2 Mark custom and modified tests as permanent.

To prevent IPG from over-writing your custom and modified tests in the future, you
should mark them as PERMANENT in the testorder file. If you need to run IPG
incrementally, you can easily specify which tests to re-generate and update the
ipgtc.tests and testorder files.
a Run Develop Board Test from IPG Test Consultant.
b Click on the Generate Tests Using Agilent IPG task to display the action list
and select Modify List of Tests to be Re-generated.
c Move the tests to the appropriate fields.
d Click SAVE to update the ipgtc.tests and testorder file.
e To prevent IPG from over-writing your modified testplan, add the testplan
generation off statement as the first line in the testorder file.
IPG Test Consultant and Board Consultant not only generate new tests and
fixtures, they manage any changes you need to make either before or after the
fixture is built. Anytime you modify a file, execute Develop Board Test to
update all files and reports affected by your modification.

Release to Production 33