Method and apparatus for automated testing of circuit boards

[0002] A portion of this patent disclosure is material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

[0003] This invention relates generally to testing of units such as electronic circuit boards and, more particularly, to computerized systems for automated testing of such units.

[0004] Over the years, as integrated circuits have become progressively more complex and sophisticated, electronic circuit boards which use these integrated circuits have also become progressively more complex and sophisticated. Consequently, in order to accurately test these electronic circuit boards, more and more sophisticated techniques have been required. In particular, circuit board manufacturers have decreased the use of manual testing techniques in favor of automated and computerized testing techniques. A resulting problem is the efficient development of test definitions, which are stored by the test system and which are then automatically carried out in order to effect testing.

[0005] A traditional approach has been to prepare a custom computer program which implements a test definition, and to then compile the program into an executable object code file, which is executed in order to carry out the required sequence of test operations. While this approach has been generally adequate for its intended purposes, it has not been entirely satisfactory in all respects. For example, in order to prepare a test definition, a test developer must be highly proficient in a sophisticated computer programming language such as assembly language, and there is thus a steep learning curve and a significant amount of training required in order for a person to obtain the minimum skills required to develop even a simple test definition. Further, each test definition may require the development of auxiliary routines, such as special low-level instrument drivers, special data logging routines, and so forth. Different test developers may prefer different languages, which makes it difficult for one test developer to quickly comprehend a program developed by another test developer, even when the source code is readily available.

[0006] Test definitions written in a selected language will typically require certain hardware-specific characteristics, such as device addresses, to be embedded therein. This limits the portability of a given test definition between various different test systems that are theoretically capable of testing the same circuit board, at least without significant time and effort to effect revisions. Because the programs are compiled, it is difficult to debug and troubleshoot the programs during development, and it is relatively cumbersome to adjust the test definitions when faced with a uniquely elusive problem in a particular circuit board. Due to the steep learning curve and the significant training time required to become proficient in a computer programming language, the operators who ultimately use the test system to test production boards will typically not be given such training. Consequently, they will simply run the specified test definitions without fully understanding what the tests are doing.

[0007] Another consideration is that it is difficult to train an operator to accurately conduct tests on a variety of different types of units, because it becomes more and more difficult for the operator to remember each of the various sequences of manual steps which must be carried out for each of the respective different types of units. For example, it may be necessary to connect an optical cable to one type of unit, but not to connect any such cable to a different type of unit. It is possible for an operator to inadvertently select the wrong test definition for use in testing a given circuit board. In a situation where a circuit board .has a programmable part which must be programmed, it is possible for an operator to inadvertently select the wrong information for use in programming the programmable part. There is also a need to be able to easily switch between a normal level of testing and a more rigorous level of testing, without necessarily requiring the operator to select one of two different test definitions, and without requiring a test developer to develop two entirely separate test definitions for the same unit.

[0008] From the foregoing, it may be appreciated that a need has arisen for automated test techniques in which test definitions are represented in a form that is intuitive and requires minimal training, which has features facilitating debug and dynamic alteration of test definitions, which can provide an operator with step-by-step instructions for manual acts required by each test definition, which permits a single test definition to selectively carry out different levels of testing, which automates the selection of test definitions, and/or which automates the selection of information that is to be programmed into a programmable part on a unit under test.

[0009] According to one form of the present invention, a technique is provided to address this need, and involves a test station which includes: a coupling portion operative to facilitate a detachable operative coupling of the test station to a unit to be tested; a memory portion which stores a program and a test file, the test file containing a test definition which specifies at least one test operation to be carried out by the test station through the coupling portion, the test definition being in the form of at least one command which is in an operator perceptible, uncompiled format; and a processor portion operatively coupled to the memory portion and the coupling portion, the processor portion being operative to execute the program, and the program causing the processor portion to process commands in the test file in an interpretive manner so as to cause the test definition to be carried out.

[0010] Another form of the invention involves a test station which includes: a coupling portion operative to facilitate a detachable operative coupling of the test station to a unit to be tested; a memory portion which stores a program and a test definition, the test definition including a first portion and a second portion, the first portion specifying a first test operation to be carried out by the test station through the coupling portion and the second portion specifying a second test operation to be carried out by the test station through the coupling portion; and a processor portion operatively coupled to the memory portion and the coupling portion, the processor portion being operative to execute the program, wherein the program causes the processor portion to permit an operator to selectively specify one of a first operational mode and a second operational mode, and causes the processor portion to access and process the test definition, wherein in the first operational mode the processor portion processes both the first portion and the second portion of the test definition so as to carry out both of the first and second test operations, and wherein in the second operational mode the processor portion processes only the first portion of the test definition to the exclusion of the second portion thereof so as to carry out only the first test operation without the second test operation.

[0011] Yet another form of the invention involves a test station which includes: a coupling portion operable to facilitate a detachable operative coupling of the test station to a unit to be tested; an output portion through which information can be communicated to an operator; a memory portion which stores a test definition; and a processor portion operatively coupled to the coupling portion, the memory portion, and the output portion, the processor portion being operative in response to the test definition to use the output portion to successively communicate to an operator each of a plurality of different manual steps which are needed to carry out the test definition.

[0012] Still another form of the invention involves a test station which includes: a coupling portion operable to facilitate a detachable operative coupling of the test station to a unit to be tested; an output portion through which information can be communicated to an operator, the output portion including a video display; a memory portion which stores a test definition; and a processor portion operatively coupled to the coupling portion, the memory portion, and the output portion, the processor portion being operative in response to the test definition to display on the video display a graphic depiction of how to perform a manual step required by the test definition.

[0013] A further form of the invention involves a method of operating a test station which can be detachably operatively coupled to a test unit to be tested, including: storing a test definition; and causing the test station to respond to the test definition by automatically carrying out on the test unit a sequence of test operations specified by the test definition, and by presenting on a display a graphic depiction of how to perform a manual step required by the test definition.

[0014] Yet another form of the present invention involves a test station which includes: a coupling portion operative to facilitate a detachable operative coupling of the test station to a test unit which has indicia thereon; a reader portion which can read the indicia on the unit; and a control portion which is operatively coupled to the coupling portion and the reader portion, the control portion being responsive to information obtained through the reader portion for carrying out through the coupling portion at least one operation which is selected as a function of the information.

[0015] A better understanding of the present invention will be realized from the detailed description which follows, taken in conjunction with the accompanying drawings, in which:

[0016] FIG. 1 is a block diagram of an apparatus which includes an automated test system that embodies the present invention;

[0017] FIG. 2 is a block diagram of part of a directory structure for a hard disk which is a component of the test system of FIG. 1;

[0018] FIG. 3 is a diagrammatic view of a main screen provided on a visual display which is a component of the test system of FIG. 1;

[0019] FIG. 4 is a flowchart showing a sequence of operations carried out by the test system of FIG. 1;

[0020] FIG. 5 is a diagrammatic view of a display screen similar to the screen of FIG. 3, but showing an operator log-in operation;

[0021] FIG. 6 is a diagrammatic view of a display screen which includes a window presenting both a graphic image and related alphanumeric information to an operator of the test system;

[0022] FIG. 7 is a diagrammatic view of a display screen similar to FIG. 3, but also displaying information which documents the results of tests conducted by the test system;

[0023] FIG. 8 is a diagrammatic view of a special display screen used for certain special modes of operation of the test system of FIG. 1;

[0024] FIG. 9 is a diagrammatic view of a special window which can be presented on the display screen by the test system of FIG. 1, in order to permit an operator to observe a plurality of different variables and their values;

[0025] FIG. 10 is a diagrammatic view of a further window which can be presented on a display screen by the test system of FIG. 1, in order to display information regarding a particular variable, and to permit dynamic alteration of the contents of that variable; and

[0026] FIG. 11 is a diagrammatic view of a display screen which has several windows, including a window for the operating system, a window similar to FIG. 7, and two additional windows which each display information passing to and from a test unit through respective ports of the test system of FIG. 1.

[0027] FIG. 1 is a block diagram of an apparatus 10 which embodies the present invention, and which includes a test system 12 capable of testing a unit under test (UUT), one exemplary UUT being shown at 13. The exemplary UUT 13 shown in FIG. 1 is a telecommunications circuit board of a type commonly known as an optical board. However, the system 12 is also capable of testing a variety of other types of circuit boards.

[0028] The test system 12 includes a server 16 which is coupled through a network 17 to a network printer 19 and a plurality of test stations 21-23. The network 17 may be any of several different types of networks which are commercially available, and is therefore not described here in detail. The test stations 21-23 are equivalent to each other, and therefore only the test station 23 is illustrated and described in detail.

[0029] The server 16 includes a processor 27, which in the disclosed embodiment is a commercially available microprocessor. The server 16 also includes a hard disk drive 28. The hard disk drive 28 stores an operating system to be executed by the processor 27, as well as application programs which can be executed by the processor 27. In addition, and as indicated in FIG. 1, the hard disk drive 28 stores a database file, an archive file, at least one log file, and a MAC address file, the operational purposes of which are addressed later.

[0030] The test station 23 includes a tester connector 36, to which can be releasably coupled a UUT connector 37 that is provided on tile UUT 13. The test station 23 further includes a workstation 41, which in the disclosed embodiment is a commercially available computer of the type commonly known as a personal computer. It is coupled to a cathode ray tube (CRT) display 42, a keyboard 43, and a mouse 46, which permit a human operator to interface with the workstation 41, and to conduct tests in a manner described in more detail later. A bar code reader 47 is coupled to the workstation 41. In the disclosed embodiment, the bar code reader 47 is a hand-held unit which is coupled to the workstation 41 by a cable that is several feet long. However, the bar code reader 47 could alternatively be a stationary device.

[0031] The workstation 41 includes a processor 51, which is a commercially available microprocessor, and includes a hard disk drive 52. The directory organization of the hard disk drive 52, and certain files stored thereon, are discussed in more detail later with reference to FIG. 2. The processor 51 executes a commercially available operating system, which in the disclosed embodiment is the operating system available from MicroSoft Corporation of Redmond, Washington under the tradename WINDOWS 95. The operating system is not shown in the drawings, but is stored on the hard disk drive 52. The workstation 41 includes a network interface card 53, which is a commercially available part, and which couples the workstation 41 to the network 17.

[0032] The workstation 41 has a standard RS232 serial port 61, which is coupled to a serial-to-parallel conversion circuit 63 disposed in the test station 23. The circuit 63 is in turn coupled to a plurality of bidirectional drivers 64 that are coupled to the test connector 36. The workstation 41 also includes a digital input/output (I/O) card 67, which is a commercially available plug-in card.

[0033] The test station 23 includes a plurality of electronic switches, two of which are shown at 68 and 69. The test station 23 includes a plurality of the switches 68 and also a plurality of the switches 69, but for clarity and convenience only one switch 68 and one switch 69 are shown in FIG. 1. The switch 69 has one end coupled to ground, and the switch 68 has one end coupled to a pull-up resistor 72, the other end of the resistor being coupled to a supply voltage. The opposite end of each of the switches 68 and 69 is coupled to a respective terminal of the tester connector 36. The switches 68 and 69 are each operatively controlled by the digital I/O card 67, as shown diagrammatically by broken lines in FIG. 1.

[0034] The workstation 41 includes a standard bidirectional parallel port 76, and the test station 23 includes a parallel cable 77 which is coupled at one end to the parallel port 76, and which can be releasably coupled at its other end to the UUT 13. The workstation 41 further includes standard circuitry providing a network port 78, such as that commonly known by the tradename ETHERNET. The test station 23 includes a network cable 79 which has one end coupled to the ETHERNET port 78, and which can be releasably coupled at its other end to the UUT 13.

[0035] The workstation 41 includes a circuit 81, which is a General Purpose Interface Bus (GPIB) interface circuit, and which interfaces the workstation 41 to a GPIB bus 82. The GPIB bus 82 and the interface circuit 81 conform to an industry standard specification known as the General Purpose Interface Bus specification. Accordingly, bus 82 and circuit 81 are not described here in detail.

[0036] The test station 23 includes a power supply 83, which is coupled to the GPIB bus 82, so that the power supply 83 can be controlled by the workstation 41 through the GPIB bus 82. The power supply 83 has outputs which are coupled to the tester connector 36, so that the power supply 83 can supply power to the UUT 13.

[0037] The test station 23 also includes an optical power meter instrument 86, which has inputs coupled to the GPIB bus 82, so that the workstation 41 can control the optical power meter instrument 86 through the GPIB bus 82. The optical power meter instrument 86 includes an optical pattern generator portion 87, and an error detection portion 88. The test station 23 further includes an optical attenuator 93, which has inputs coupled to the GPIB bus 82, so that the workstation 41 can control the attenuator 93 through the GPIB bus 82. The attenuator 93 is operably coupled to the error detection portion 88 of the optical power meter instrument 86. An optical cable 96 has one end coupled to the optical pattern generator 87, and its other end can be detachably coupled to the UUT 13.

[0038] A further optical cable 97 has one end coupled to the attenuator 93, and its other end can be detachably coupled to the UUT 13.

[0039] The UUT 13 is a circuit board, which has thereon a header 101, to which an end of the parallel cable 77 can be releasably coupled, and circuitry 102 defining a network port which includes a connector to which one end of the network cable 79 can be releasably coupled. The UUT 13 further includes an optical connector 103 to which one end of the optical cable 97 can be releasably coupled, and a further optical connector 104 to which one end of the optical cable 96 can be releasably coupled. The UUT 13 has circuitry 107 thereon, which is electrically coupled to the UUT connector 37, the header 101, and the network port 102. The circuitry 107 includes one or more electro-optical devices, which operatively couple the circuitry 107 to the optical connectors 103 and 104.

[0040] The circuitry 107 includes a processor 111 which is a microprocessor of a commercially available type. The circuitry 107 further includes three programmable devices 112, 113 and 114. In the disclosed embodiment, the device 112 is a flash memory, the device 113 is a lattice device, and the device 114 is an Electrically Erasable Programmable Read Only Memory (EEPROM), but the devices 112-114 could alternatively be other types of programmable devices. The UUT 13 has thereon a label 117, which has indicia in the form of a bar code on it, and possibly some other indicia. The bar code on the label 117 provides information such as a board number and part number, and also a serial number. The board number and part number have a one-to-one relationship to each other, and define a particular type of board. In contrast, the serial number is a unique number provided for each board of a particular type. If the part number of the manufacturer is different from the part number of a customer, the bar code on label 117 could also optionally include the customer part number, as a convenience to the customer.

[0041] The particular UUT 13 shown in FIG. 1 is one particular type of circuit board, which has been selected for the sake of example. In particular, and as mentioned above, the UUT 13 is a telecommunications circuit board of a type commonly known as an optical board. However, the test station 23 is designed to be capable of testing a variety of different types of circuit boards, which may each have a larger or smaller number of components than the UUT 13 shown in FIG. 1. For example, other boards may lack the optical connectors 103 and 104, or may lack programmable devices such as those shown at 112-114. Each operator has an identification badge or card, one of which is shown at 121. The badge 121 has a bar code label 122 on it. The bar code label 122 includes information which identifies the particular operator, such as a name and/or employee number. Although it would be possible for each operator to manually enter this information, use of a machine-readable card or badge reduces the chance of-inadvertent errors by the operator.

[0042] FIG. 2 is a diagrammatic view of a directory structure 131, which is a portion of the overall directory structure present on the hard disk drive 52 of the workstation 41 (FIG. 1). The directory structure 131 includes a HostSoft subdirectory 133. The HostSoft subdirectory 133 has several additional subdirectories associated with it, including a Programs subdirectory 136, a Macros subdirectory 137, a PrgDevs (programmable devices) subdirectory 138, a Tables subdirectory 139 and a LogFiles subdirectory 140.

[0043] The term “HostSoft” is used herein as the name of a subdirectory, and as the name of an executable program file. However, the term HOSTSOFT is also a trademark of the assignee of the present application, for use in commerce in association with products disclosed herein.

[0044] FIG. 2 identifies some of the most relevant files which are stored in the subdirectories 133 and 136-140, but it will be recognized that each of these subdirectories may include additional files. The subdirectory 133 includes a file HostSoft.EXE, which is a compiled program that is executed by the processor 51 of the workstation 41 in conduction with execution of the resident operating system, and which provides underlying control for test operations carried out by the test station 23. The subdirectory 133 also includes a file HostRun.INI, which is an initialization file described in more detail later. The subdirectory 133 includes several additional files which each include a graphics image in a standard “bit-map” format, and which are each identified by a respective filename ending in the common extension “BMP”.

[0045] The subdirectory 133 also includes several lattice configuration files, which each have a respective filename that ends with the common extension “LAT”, and includes several file transfer protocol (FTP) configuration files, which each have a respective filename that ends with the common extension “FTP”. Specific examples of a LAT file and an FTP file are described later. The subdirectory 133 further includes several library files, which have respective filenames that end with the common extension “LIB”, and several dynamic link library files which have respective filenames that end with the common extension “DLL”. The LIB and DLL files are compiled object-code files, as discussed later.

[0046] The Programs subdirectory 136 includes several program files, which each have a respective filename ending in the common extension “PRG”. The Macros subdirectory 137 includes several macro files, which each have a respective filename ending in the common extension “MAC”. Specific examples of a PRG file and several MAC files are discussed later. The PrgDevs subdirectory 138 includes several binary files, which each include binary information that can be loaded into a programmable device, such as one of the programmable devices shown at 112-114 in FIG. 1. The Tables subdirectory 139 includes a database file, which is discussed in more detail later. The LogFiles subdirectory 140 includes at least one log file, which is used to store the results of certain test operations, in a manner described later.

[0047] As mentioned above, the Programs subdirectory 136 includes a plurality of PRG files, and the macro subdirectory 137 includes a plurality of MAC files. Each type of unit to be tested is associated with a respective PRG file, which defines the sequence of test operations that are to be conducted on each unit of that type. The PRG file may call one or more MAC files, in a manner somewhat similar to the manner in which a subroutine is called by a computer program. Each MAC file can call one or more other MAC files in a similar manner. There is no significant difference between a PRG file and a MAC file. A PRG file is simply a MAC file which contains the top level of the test definition, and each MAC file contains a portion of the test definition at a greater level of detail.

[0048] The PRG files and the MAC files are all maintained in an uncompiled operator-perceptible format. In more detail, each PRG file or MAC file in the disclosed embodiment is an ASCII text file, which contains a command sequence that includes one or more commands drawn from a predefined set of commands. Table 1 lists all of the commands in this predefined command set, and provides a brief summary of each command. To avoid unnecessary duplication, the various commands are not all described again in detail here. However, some specific comments are offered in the interest of clarity.

[0049] First, some of the commands in Table 1 refer to a “MAC address”, which is an industry-standard type of network address. It is not necessary to discuss the MAC addresses in detail here. However, it is important to point out that the present discussion refers to macro files, and some macro files have filenames which end with the extension “MAC”, and which are referred to herein as MAC files.

[0050] References to the MAC files should not be confused with references to the MAC addresses, because they are entirely different.

[0051] Second, the commands set forth in Table 1 can support different types of variables, including integer variables, floating point variables, and string variables. The 3G HostSoft.EXE program is written so as to effect automatic conversion between variable types. Thus, for example, if one of the commands in Table 1 is expecting a variable value of a floating-point type, but receives a variable value of an integer type, it will automatically convert the integer value to a floating-point value, and then continue.

[0052] Third, some of the commands in Table 1 refer to a “generic message” or a “generic result”. The format for each such command ends with one or more parameters which are disposed within square brackets in the command definition. The square brackets indicate that the parameters within them are optional. Depending on whether or not these parameters are present in a given command, the command will be carried out in either a data mode or a measurement mode.

[0053] The measurement mode is in effect if the optional parameters are present. The optional parameters include a “test flag” parameter, which affects how the command operates. More specifically, if the test flag parameter is a “P” for “pass”, then the system will display a specified message and the word “PASS” on the display 62 if the specified operation is successful, but will display nothing if the specified operation fails. If the test flag parameter is an “F” for “fail”, then the system will display the specified message and the word “FAIL” if the specified operation fails, but will display nothing if the specified operation is successful. If the test flag parameter is an “A” for “always”, then the system will always display the specified message, and will also display either the word “PASS” or the word “FAIL” in dependence on whether the specified operation was successful or not.

[0054] If the optional parameters are not provided, then the command is carried out in the data mode. Data mode is used to collect information from a device for the purpose of either displaying it or evaluating it later. That is, the command simply returns data to the screen or to a variable. Table 2 sets forth one specific example of a PRG file, which, has the name “3MR1.PRG”. This specific PRG file was prepared to test an optical board of the type shown at 13 in FIG. 1. This PRG file calls several MAC files, some of which call other MAC files. In total, processing of the PRG file in Table 2 requires ten related MAC files, which are respectively set forth in Tables 3-12. Tables 2-12 are self-explanatory when read in conjunction with the definition of the command set provided in Table 1. Nevertheless, an overview explanation of these files is given later for purposes of convenience.

[0055] When the compiled program HostSoft.EXE is interpreting the PRG file of Table 2, or one of the MAC files of Tables 3-12, it reads a line, and then parses and processes that line on the fly in an “interpretative mode”, in order to implement the command. The HostSoft.EXE program then reads the next line, and processes that next line in the interpretative mode. The present invention is not limited to the specific set of commands set forth in Table 1, nor to the specific PRG and MAC files set forth in Tables 2-12. Instead, Tables 1-12 are provided to show one example of a test definition according to the present invention, in order to facilitate a better understanding of the present invention. The PRG and MAC files in Tables 2-12 are discussed in more detail later.

[0056] When the workstation 41 is turned on, it will automatically initiate execution of the resident operating system, which as mentioned above may be the window-based operating system available under the tradename WINDOWS 95. Then, through use of the keyboard 43 or mouse 46, the operator can instruct the operating system to cause the processor 51 to begin execution of the compiled HostSoft.EXE program located in the HostSoft subdirectory 133.

[0057] During this turn-on or initialization process, information will be downloaded from the server 16 to the test station 23. More specifically, the database file on the hard disk drive 28 of the server 16 will be downloaded to the Tables subdirectory 139 on the hard disk drive 52 of the test station 23. Further, the archive file on the hard disk drive 28 of the server 16 will be accessed, and appropriate files therefore will be extracted from the archive file and downloaded to appropriate subdirectories 113 and/or 136-138 on the hard disk drive 52 of the test station 23. This may include any or all of the above-discussed INI, BMP, LAT, FTP, DLL, LIB, PRG, MAC and binary files. In the disclosed embodiment, some of these files are downloaded in conjunction with start-up of the operating system, and others are downloaded if and when the HostSoft program is started. However, it will be recognized that all files could be downloaded at the same time.

[0058] As soon as the HostSoft.EXE program is started, it will generate and present on the display 42 a window containing a main screen, which is shown at 146 in FIG. 3. The main screen 146 is a window having at the top a title bar 147, which has an industry-standard format. In particular, the icons at the right and left ends of the title bar 147 may be used to resize or to close the window which contains the main screen 146. Immediately below the title bar 147 is a menu bar 148, which is described in more detail later. Below the menu bar 148, on the left side of the screen, is a workspace 151, which can be used to display information to the operator, including information received from the operator. At the right side of the workspace 151 is a scroll bar 152 of standard format, which permits the operator to scroll up and down through the information present in the workspace 151.

[0059] Below the menu bar 148, on the right side of the screen, is a Test Busy indicator 153. The Test Busy indicator 153 is a portion of the screen which is selectively presented at different times in one of two different colors, such as gray and red, in order to indicate that the indicator is respectively off and on. Adjacent the Test Busy indicator 153 is a PASS indicator 154, which can also be displayed in one of two different colors, such as black and green, to show that the indicator 154 is respectively off and on. The Test Busy indicator 153 is turned on when the test station 23 is conducting a test on a unit such as the UUT 13. If the unit passes all of the tests conducted on it, then at the completion of the test sequence, the PASS indicator 154 is turned on in order to indicate to the operator that the unit successfully passed all tests.

[0060] Below the indicators 153 and 154 is a region 157, where the name of the current operator is displayed, and a region 158, which displays the privilege levels enjoyed by the current operator. Some operators will have a wider range of privileges than other operators. For example, one operator may be permitted to run predefined tests on units which are to be tested, but may not have the privilege to make any changes to those tests. In contrast, an operator with a higher privilege level may be able to not only run the predefined tests, but to also dynamically alter them.

[0061] Below the regions 157 and 158 are three further regions 161-163, where the system displays information regarding the unit which is currently being tested. In particular, in region 161, the system displays an alphanumeric “Test Board” name for the specific type of unit currently being tested. In the region 162, the system displays a part number for that type of unit. In general, there will be a one-to-one relationship between the test board name and the part number. In region 163, the system displays a serial number, where there is a unique serial number for each unit of a given type. That is, if there are one hundred units of the same type, they will each have the same test board name and part number, but each will have a different serial number.

[0062] Below the part number region 162 are three drop-down lists 167, 168 and 169, which can be used by the operator to selectively control certain aspects of system operation. The drop-down list 167 is used to select the “Print Mode”, which determines what information, if any, will be printed on the network printer 19 (FIG. 1) by the test station 23. The three available options for print mode are “Don't Print”, “Print On Errors” and “Always Print”, which are self-explanatory.

[0063] The drop-down list 168 is used to select the “Test Mode”. The two available Test Mode options are “Stop On Errors” and “Continue On Errors”, which specify whether or not the system is to continue if it detects an error while conducting a test.

[0064] The third drop-down list 169 is used to select the “Test Items”, which allows the operator to specify how rigorously a particular unit should be tested. The two available options are “Normal” and “Sample Base”. The “Sample Base” option is typically used to cause more rigorous testing to be carried out than the “Normal” option, in a manner which is described in more detail later. Units will usually be tested under the “Normal” option. The “Sample Base” option might be periodically selected in order to effect more rigorous testing of a few units for quality control purposes, for example once per week or once per month. Alternatively, if a particular unit has exhibited problems in the field but appears to pass all tests conducted under the “Normal” option, the “Sample Base” option might be selected in order to effect more rigorous testing of that particular unit, in an attempt to identify and localize the problem.

[0065] Two buttons 172 and 173 are provided below the drop-down list 169. The button 172 is a “Start Test” button, which can be actuated in order to initiate a selected test, in a manner described later. The button 173 is used to toggle between “Log On” and “Log Off” modes of operation, in which test results are and are not saved to a log file in the LogFiles subdirectory 140 (FIG. 2), as discussed later.

[0066] Turning now in more detail to the menu bar 148, the menu bar identifies five drop-down menus, which are the File Menu 176, Options Menu 177, Test Menu 178, Tools Menu 181, and Help Menu 182. The Help Menu 182 provides on-line help in a generally standard manner, and is not described in detail here. As to the other drop-down menus, the most pertinent options from each menu will be described, but it will be recognized that these menus may each have additional options which are not described here. The File Menu 176 has an “Open Macro” option, which opens a special window that will be described in more detail later in association with FIG. 8. The File Menu also has “Exit” option, which causes the test station 23 to terminate execution of and exit from the HostSoft.EXE program.

[0067] The Options Menu 177 has a “View Pictures” option, which toggles on and off a view pictures capability, which is described in more detail later. The Options Menu also has a “Debug Mode” option, which toggles on and off whether the system is operating in a special debug mode, which will be described in more detail later. The Options Menu also includes a “Step Mode” option, which toggles on and off a special mode of operation which is called the step mode, and which is described in more detail. Further, the Options Menu includes a “Log Test Results” option, which is a toggle that determines whether or not the test station 23 saves certain test results to a log file located in the LogFiles subdirectory 140 (FIG. 2). The “Log Test Results” option is functionally equivalent to the button 173, which was discussed above.

[0068] The Test Menu 178 includes a “Start Test” option, which is equivalent to the above-discussed Start Test button 172. The Test Menu further includes a “Cancel Test” option, which immediately terminates a currently running test prior to normal completion thereof. Further, the Test Menu includes a “Select Macro To Run” option, which is discussed in more detail later.

[0069] The Tools Menu 181 has an “RS232 Spy” option and a “GPIB Spy” option, each of which toggles on and off a special facility that can be used to view information going to and from a unit being tested, in a manner discussed later.

[0070] FIG. 4 is a flowchart showing the general sequence of operations in the portion of the HostSoft.EXE program which carries out testing of a given unit under test. With respect to this portion of the program, execution begins at block 191, at which point the HostSoft.EXE program is presenting on the display 42 (FIG. 1) the main screen 146 shown in FIG. 3. Control proceeds from block 191 to block 192, where the system makes sure that the PASS indicator 154 (FIG. 3) is off, for example by setting the letters “PASS” to a subdued color such as black. Then, at block 193, the system waits for an operator to use the bar code reader 47 to scan the bar code label 122 on the badge 121 of that particular operator. The bar code label provides the name of the operator, or an operator number from which the name of the operator can be determined. The bar code label 122 may optionally provide information regarding the privilege level of that particular operator, although the privilege level may alternatively be obtained by using the operator name or number to access a table of privilege information stored on the hard disk drive 52.

[0071] With reference to FIG. 5, the system superimposes on the main screen 146 a log-in window 196, and displays the name of the operator, as determined from the badge, in a region 197 of the window 196. The window 196 also includes a region 198 for the operator to enter a password. The display of the window 196 in FIG. 5 corresponds to block 201 in FIG. 4, where the system requests a password from the operator. At block 202 in FIG. 4, the system waits for the operator to enter the password in the region 198 of window 196, and then checks to make sure that the entered password is the correct password for the particular operator. The system uses the operator name or number to access a table stored on the hard disk drive 52, in order to obtain the current password for that particular operator. If the password entered by the operator does not match the password from the table, the operator may be allowed to try entering the password a second time. However, if the operator is not able to enter the correct password after a reasonable number of attempts, control is returned to block 193, to wait for a different operator to scan the bar code label on his or her operator badge.

[0072] Once the correct password has been entered, control proceeds from block 202 to block 203, where the system waits for the operator to authorize the system to begin a test, either by actuating the Start Test button 172 or by selecting the Start Test option from the Test Menu 178. Once the operator starts a test, control proceeds from block 203 to block 206, where the system prompts the operator to use the bar code reader 47 to scan the bar code label 117 on the UUT 13 which is to be tested. The system waits for the bar code label to be scanned at block 207. The information obtained from the bar code label 117 may include the board name, the board part number, and a serial number, which the system will then display in the regions 161-163 (FIG. 3) of the main screen 146, for example as visible at 161-163 in FIG. 7.

[0073] After the operator scans the bar code label, the system proceeds to block 208, where it prompts the operator to couple the connector 37 on the UUT 13 to the tester connector 36 of the test station 23, and then waits for the operator to do so at block 209. The operator does not yet connect to the UUT 13 any of the other cables 77, 79, and 96-97, as there will be separate prompts later for any or all of these cables. When the operator has coupled the connectors 36 and 37 together, the operator responds to the prompt by pressing the ENTER key on the keyboard 43, or by some other similar action, which causes the system to proceed from block 209 to block 212.

[0074] At block 212, the system turns on the Test Busy indicator 153, in particular by changing this portion of the screen from a subdued color such as gray to a more pronounced color such as red. Then, a search is made of the HostRun.INI file which, as discussed in association with FIGS. 1 and 2, is stored in the HostSoft subdirectory 133 of the hard disk drive 52. An excerpt from this file is shown in Table 13. It includes a “[BOARDS]” section, which lists the part number of each known board, followed by an equal sign and a unique code. In the case of the specific UUT 13 which is the subject of this example, and as shown in Table 13, the part number is “H16B-1023-H362”, and the corresponding unique code is “3MR1”. The HostRun.INI file also includes a number of additional sections, each of which corresponds to a respective one of the unique codes. As shown in Table 13, there is a section “[3MR1]”, which corresponds to the particular UUT 13. Each such section contains certain standard items of information, including the name of the board, the name of the PRG file which is provided to test the board, the names of the subdirectories which include the PRG and MAC files used to test the board, and an indication of whether the system should have the operator verify the revision number of the board. It will be noted that the specific PRG file identified in Table 13 for the UUT 13 of FIG. 1 is “3MR1.PRG”, which is the specific PRG file set forth in Table 2.

[0075] In FIG. 4, control then proceeds from block 212 to block 213, where the system checks to see whether the “RequireRevision” parameter in the HostRun.INI was “Yes”. If so, control proceeds to block 214, where the system prompts the operator to enter a revision number which is visible on the UUT 13, and the system then stores this revision number for later use. Control ultimately continues at block 217, where the system uses the “ProgramDir” parameter of the HostRun.INI file to identify the subdirectory containing the specified PRG file, which in this case is the Programs subdirectory 136 of FIG. 2. The system then retrieves from this subdirectory the PRG file which is specified by the “ProgramFile” parameter of the HostRun.INI file, which in this case is the “3MR1.PRG” file shown in Table 2.

[0076] Control then proceeds to block 221, where the HostSoft.EXE program being executed by the processor 51 processes the 3MR1.PRG file shown in Table 1 in an interpretative manner, as already discussed above. As this is carried out, this PRG file will directly and indirectly invoke ten macro files, which are the MAC files shown in Tables 3-12. Based on the “MacroDir” parameter in the HostRun.INI file (Table 13), the system knows that these MAC files are all located in the Macros subdirectory 137 of FIG. 2. As discussed above, these MAC files will also be processed in an interpretative mode.

[0077] As explained above, the PRG and MAC files shown in Tables 2-12 are provided primarily by way of example, and are self-explanatory when considered in conjunction with the command set forth in Table 1. Thus, a detailed discussion of every step which occurs during interpretation of these specific PRG and MAC files is not necessary. However, a brief overview will be provided as a convenience, and certain selected steps will be discussed in more detail.

[0078] More specifically, the following is an overview of what happens in block 221 during processing of the specific exemplary PRG and MAC files which are set forth in Tables 2-12. It is important to recognize that these correspond directly to testing of one particular type of unit to be tested, which is the optical telecommunications board 13 shown in FIG. 1. Substantially different PRG and MAC files might be used to test other units. The 3MR1.PRG file of Table 2 is primarily a sequence of calls to various MAC files.

[0079] More specifically, and with reference to Table 2, the 3MR1.PRG file begins by calling the InitializeEquipment.MAC macro, which is shown in Table 3. This macro then calls the Power.MAC macro shown in Table 4, which turns on and configures the power supply 83 (FIG. 1) for the UUT 13. Then, the InitializeEquipment.MAC macro of Table 3 interprets several commands that initialize the optical power meter instrument 86, followed by commands that initialize the optical attenuator 93 and the serial port 61.

[0080] Control then returns to the 3MR1. PRG file of Table 2, which calls the FirmwareDownloadTest.MAC macro shown in Table 5. In general, this macro effects programming of the lattice device 113 on the UUT 13, by downloading into it a file of binary information. In this regard, the second command in the macro includes a reference to an identifier “IC34”, which may be an integrated circuit number of the part to be programmed, and which will be used as a search parameter within the database file located in the Tables subdirectory 139 (FIG. 2). In this regard, the database file in the subdirectory 139 includes a programmable device database, an excerpt from which is shown in Table 14.

[0081] With reference to Table 14, each record in the database includes six fields, the first of which is a board part number such as “H16B-1023-H362”, a board revision number such as “002A”, an identifier such as “IC34”, the name of a configuration file such as “OptBd.LAT”, a first checksum value such “05FE” and a second checksum value such as “F97D”. At this point in time, for the particular UUT 13 which is to be tested, the system has already obtained the board part number (for example at blocks 206-207 in FIG. 4), has already obtained the board revision number if there is one (for example at blocks 213-214 in FIG. 4), and has obtained an identifier (for example “IC34” from the macro in Table 5). The system then searches the database of Table 14 in an attempt to find a record with a matching part number, revision number and identifier. If the test station 23 does not find a matching record in the database of Table 14, which is stored on the local hard disk drive 52 of FIG. 1, then the test station 23 will interact with the server 16 in order to search the database file stored on the hard disk drive 28 of the server 16. The database file in the server 16 may be more up to date, and may thus include a record that matches the search parameters. In the instant example, it is assumed that a match is found in the database of Table 14, so that the system obtains the lattice configuration filename “OptBd.LAT”, and the two associated checksums.

[0082] The system will then retrieve the OptBd.LAT configuration file from the HostSoft subdirectory 133 (FIG. 2), exemplary contents of which are shown in Table 15. The information in this lattice configuration file includes the term “PrgDevs\7503H999.jed”, which is an identification of a binary file named “7503H999.jed”. This binary file is located in the PrgDevs subdirectory 138 (FIG. 2). The system retrieves this binary file, and supplies it through the connectors 36 and 37 (FIG. 1) to the processor 111 on the UUT 13, which in turn programs the contents of this binary file into the lattice device 113. It will be noted that, in this manner, the test station 23 ensures that the lattice device 113 on the UUT 13 is correctly programmed with the most up-to-date version of the firmware associated with the particular part number and revision number for the UUT 13. This is all handled automatically, without operator involvement, thereby substantially avoiding the possibility of error.

[0083] Then, the processor 111 on the UUT 13 uses the checksum information from the database (Table 14) to verify that the download of information into the lattice device 113 has been accurately and successfully completed. The macro of Table 5 receives a return value from the command which effected the firmware download, and the macro checks the return value in order to determine whether the download was successful. Control then returns to the PRG file of Table 2, which calls the OpticalPowerTest.MAC macro of Table 6. This macro in turn calls the MeasureOpticalPower.MAC macro of Table 7, which interacts with the optical power meter instrument 86 (FIG. 1) so as to carry out an optical power measurement. The results are then evaluated, and control ultimately returns to the PRG file of Table 2.

[0084] Then, the 3MR1.PRG file of Table 2 carries out a command which displays a message telling the operator to “Connect the optical cables as shown in the picture”, while simultaneously displaying a picture showing how to do this. The displayed picture is obtained from the bit-map graphics file “Optical.BMP”, which is one of the BMP files located in the HostSoft subdirectory 133 (FIG. 2). In more detail, and as shown in FIG. 6, the system superimposes a special window 226 over part of the main screen 146, the upper portion of the window 226 being a direct display of the Optical.BMP file, and the lower portion of the window containing the specified message at 228, along with an “OK” button 229. In the disclosed embodiment, the BMP information displayed in the upper portion of the window 226 is a digitized photograph, but it could alternatively be a comparable diagram.

[0085] In FIG. 6, the BMP image displayed in the upper portion of the window 226 is an accurate view of the test station 23 and the UUT 13 as they actually appear to the operator. This image shows the operator where the optical connectors 103 and 104 are physically located on the UUT 13, and shows how the optical cables 96 and 97 should properly be routed to and coupled to these connectors 103 and 104. The image itself includes a legend 232, which says “Connect optical cables here”, and includes an arrowhead pointing to the optical connectors. This image helps an inexperienced operator to remember to connect the optical cables, to do so at the proper point in the test sequence, and to easily and correctly connect the cables, all without extensive training. Given that the test station 23 is capable of testing a number of different types of units, a new operator can accurately and reliably conduct tests on a wide range of units, without undergoing an extensive training process.

[0086] While the particular BMP image, message 228 and legend 232 in FIG. 6 all have to do with the connection of optical cables, it will be recognized that a sequence of equivalent windows containing other images and messages could be used to lead an operator through the manual steps needed in order to effect testing of a particular type of unit. It will also be recognized that a window similar to window 226 could be used to request an operator to provide input information. For example, if a particular type of circuit board has a light emitting diode (LED), the system could display a BMP image showing the board and the location of the LED thereon, with a request that the operator actuate one of two displayed buttons in dependence on whether the LED is currently on or off.

[0087] It was mentioned above that the Options Menu 177 (FIG. 3) has a “View Pictures” option. This option permits an operator to selectively permit or suppress the display of the BMP image in each window of the type shown at 226 in FIG. 6. That is, if the operator enables the “View Pictures” option, the BMP image will be displayed in each such window, in a manner similar to window 226 of FIG. 6. On the other hand, if the operator has disabled the “View Pictures” option, the BMP image would not be displayed, and thus the window 226 of FIG. 6 would present only the message 228 and the button 229, without any BMP image.

[0088] When the operator has properly connected the optical cables, and has thus complied with the request presented by the window 226, the operator actuates the “OK” button 229, in order to indicate to the system that the requested manual task has been completed. The system then removes the window 226 from the screen. Thereafter, the PRG file carries out a call to the macro PhysicalInventoryCheck.MAC, which is shown in Table 8. This macro begins by retrieving from the HostSoft subdirectory 133 (FIG. 2) a library file “PhyInv.LIB”, which is a compiled file. The system loads and in due course executes this library file, which requests information from the HostSoft program regarding what board is being tested, then writes physical inventory information through the processor 111 to the EEPROM 114 of the UUT 13, then verifies that the information was stored correctly, and then returns a result back to the HostSoft program.

[0089] Control returns to the PRG file of Table 2, which then calls a MemoryTest.MAC macro. The MemoryTest.MAC macro is shown in Table 9, and performs a memory test. This macro includes loading and execution of a compiled library file “MemTest.LIB”, which requests information from the HostSoft program to determine what board is being tested, then writes pattern information to all locations of testable memory on the UUT 13, then reads all such testable memory locations and to verify that the contents are correct, and then returns a result back to the HostSoft program.

[0090] Next, the PRG file of Table 2 calls a PowerConsumptionTest.MAC macro, which is shown in Table 10. This macro interacts with the power supply 83 in order to determine the current level of power consumption of the UUT 13, and then evaluates this current level of power consumption.

[0091] Thereafter, the PRG file of Table 2 calls a production software download macro ProdSoftwareDownload.MAC, which is shown iii Table 11. This macro effects programming of the flash memory 112 on the UUT 13, using a file transfer protocol (FTP) download. This is carried out in a manner which, in general, is similar to the above-described sequence by which the lattice device 113 is programmed. In brief, the system takes the board part number, the board revision number (if any), and the identifier “IC3, IC4” obtained from the macro of Table 11, and searches the database of Table 14. If necessary, the database in the server 16 is also searched. When a match is found, the system obtains the name of an FTP configuration file such as “OptBd.FTP”, and two checksum values.

[0092] The system retrieves the FTP configuration file OptBd.FTP from the HostSoft subdirectory 133, the exemplary contents of which are shown in Table 16. The information in this FTP configuration file includes parameters which will control the FTP transfer, as well as a path identifying a binary file which is to be downloaded into the flash memory 112. The system then transfers the binary file to the processor 111, which programs it into the flash memory 112. From the point of view of the calling macro file, the primary difference between the commands which respectively program the lattice device 113 and the flash memory 112 is that the former automatically evaluates the checksums, whereas the latter does not. Thus, if checksum evaluation is desired in the case of the FTP transfer, it must be done by providing additional commands within the macro.

[0093] After completion of the ProdSoftwareDownload.MAC macro shown in Table 11, the PRG file of Table 2 calls the ShutDown.MAC macro of Table 12, which simply calls the Power.MAC macro of Table 4 in order to turn off the power supply 83. Then, the PRG file of Table 2 concludes by providing a window similar to that shown at 226 in FIG. 6, except that the BMP image and the message instruct the operator to disconnect the optical cables 96 and 97 from the UUT 13.

[0094] As the test station 23 is processing the PRG and MAC files of Tables 2-12, these files output successive messages to the workspace 151 of the main screen 146 (FIG. 3), to indicate whether each test operation conducted on the UUT 13 has passed or failed. Assuming that all the test operations conducted by the PRG and MAC files of Tables 2-12 are successful, then when processing of all these files reaches completion, the information displayed in the workspace 151 will be that shown in FIG. 7. In particular, this information identifies successive tests which were conducted, and the fact that the UUT 13 passed each such test. If the UUT 13 had failed any test, the information displayed in workspace 151 would indicate this.

[0095] Referring again to the flowchart of FIG. 4, when the system has completed interpretative processing of the PRG and MAC files of Tables 2-12, control proceeds from block 221 to block 241, where the system checks to see whether logging is enabled. As discussed above, the operator can selectively toggle logging on and off, using either the button 173 (FIG. 3), or the “Log Test Results” option of the Options Menu 177. If logging is enabled, then control proceeds from block 241 to block 242, where the test station 23 stores certain test results in a log file which is located in the LogFiles subdirectory 140 (FIG. 2) of the local hard disk drive 52 (FIG. 1).

[0096] In the disclosed embodiment, the information which is logged includes at least the board number, part number, serial number, operator name, and an indication of whether or not the board passed each of the tests which were conducted on it. This system could optionally log more information or less information. The server 16 of FIG. 1 is programmed to periodically use the network 17 to interrogate the log files located in the LogFiles subdirectory 140, and to transfer.information from these files to a log file located on the hard disk drive 28 of the server 16.

[0097] From blocks 241 and 242, control ultimately proceeds to block 243, where the system turns off the Test Busy indicator 153, in particular by changing this portion of the screen from a noticeable color such as red to a subdued color such as gray. Then, at block 246, the system checks to see if the UUT 13 passed all of the tests which were conducted on it. If so, control proceeds to block 247, where the system turns on the PASS indicator 154, for example by changing the letters “PASS” from a subdued color such as black to a noticeable color such as green. In either case, control ultimately proceeds to block 248, which represents completion of the testing of the UUT 13.

[0098] As mentioned earlier, the system has a special debug mode, which can be toggled on and off by selecting the Debug Mode option from the Options Menu 177 (FIG. 3). When debug mode is not enabled, then the system will test the UUT 13 by carrying out the entire test definition set forth in the PRG and MAC files without stopping, except in certain limited circumstances. In particular, it will temporarily stop when a PRG or MAC file requests an action by or some input from the operator, for example a request that the operator effect connection of the optical cables as discussed above in association with FIG. 6, or a request that the operator read and input the current state of an LED on the unit under test. In addition, if the operator has used the Test Mode drop-down list 168 to select the “Stop On Errors” mode of operation, the system will stop if it detects any error during the test.

[0099] In contrast, when the debug mode is enabled, it provides some special capabilities which permit greater operator interaction while a test is being carried out. This can be used to develop and/or debug a PRG or MAC file, or to make temporary modifications to a PRG or MAC file for the purpose of isolating an elusive problem in a particular unit being tested. As soon as the debug mode is turned on, a special prompt will appear in the workspace 151 of the main screen 146 (FIG. 3). This debug prompt is “Debug>”. Following the debug prompt, the operator can type any proper command from the command set of Table 1, and that command will immediately be interpreted when the operator ends the command by pressing the ENTER key on the keyboard 43. Alternatively, the operator can type the name of a macro file after the debug prompt, and that macro file will be immediately interpreted. Similarly, the operator can type the name of a PRG file, and the PRG file, along with any associated MAC files, will be immediately interpreted. During the debug mode, the operator can also use the “Select Macro To Run” option from the Test Menu to specify a macro, which will be immediately interpreted. The “Select Macro To Run” option works only when the debug mode is enabled.

[0100] In the debug mode, the operator can alter a PRG or MAC file. In particular, at the debug prompt, the operator may type “MACRO name”, where the name of macro of interest is “name.MAC” or “name.PRG”. This causes HostSoft.EXE to open a special window with editing capabilities, in which is displayed an ASCII text listing of the specified MAC or PRG file. In the disclosed embodiment, the HostSoft.EXE program does this by invoking a special window which is an inherent feature of the resident operating system, and which permits a file to be opened, edited, saved, and closed. Since this special window is an inherent feature of the resident operating system, it is not illustrated and described here in detail. However, it will be recognized that the HostSoft.EXE program could be written to provide such a window on its own, rather than by invoking a window feature of the resident operating system.

[0101] When the operator is done modifying the selected PRG or MAC file, the operator saves the modified file and then closes the special window. When the modified macro is saved, the modified version thereof is located only on the local hard disk drive 52, and not in the master definition of that macro in the archive file on the hard disk drive 28 of the server 16. If the operator ultimately wants to replace the master definition of the macro with the modified version from the local disk drive, the operator must effect a standard file transfer operation in order to copy the modified macro file from the local hard disk drive 52 to the server hard disk drive 28.

[0102] When the debug mode is enabled, the operator also has the capability to set one or more breakpoints, or in other words to identify any command in a PRG file or MAC file as a breakpoint. When the system is processing a PRG or MAC file and reaches a command which has been designated as a breakpoint, the system stops and waits for operator authorization to proceed with processing of the breakpoint command. In the disclosed embodiment, the operator sets or clears a breakpoint in the following manner. The operator selects the “Open Macro” option from the File Menu 176 (FIG. 3), which then presents to the operator a illustrated window containing a list of macro files located in the Macros subdirectory 137 (FIG. 2). The operator selects from this list the macro of interest, and the system then opens a special Open Macro window 261, which is shown in FIG. 8 in a manner superimposed over the entirety of the main screen 146. Across the top of the Open Macro window 261 is an industry standard title bar 260, and under the title bar 260 is a button bar 262. The button bar 262 has a GO button 266, a STOP button 267, a STEP THROUGH button 268, a STEP OVER button 269, and an INSPECT VARIABLES button 270. The buttons 266-270 are each discussed in more detail later.

[0103] Below the button bar 262, the Open Macro window 261 has a workspace 276, along the right side of which is a vertical scroll bar 277. Along the left side of the workspace 276 is a breakpoint column 278. The ASCII text from the selected macro file is displayed in the workspace 276. In order to specify that a particular command is to be a breakpoint, the operator selects the line which contains that command, for example by clicking on that line through use of the mouse 46 (FIG. 1). The system responds by displaying a check mark (✓) in the breakpoint column 278 and immediately to the left of the selected line, for example as shown at 279. If the operator clicks on that same command line again, the command will be deselected as a breakpoint, and the check mark 279 will be removed.

[0104] After setting or clearing a breakpoint, the operator can close the window 261 or leave it open. If the window 261 is left open, then when that particular macro is being processed in an interpretative mode by the system, a highlighted region such as that shown at 282 will be moved from command to command in order to identify the command which is currently being interpreted. While the macro is being interpreted, the operator can halt the interpretation at any point by actuating the STOP button 267. To thereafter continue execution, the operator can actuate the GO button 266. If the system automatically stops at a particular command because that command has been specified as a breakpoint, then the operator can thereafter cause the interpretation to continue by actuating the GO button 266.

[0105] As previously mentioned, the Options Menu 177 (FIG. 3) also includes a “Step Modie” option, which is used to toggle a step mode capability on and off. The step mode is a further feature of the debug mode. When step mode is enabled, and when the system is interpreting a given macro file, the system will stop before interpreting each command, and will wait for authorization to proceed to interpret the command. Thus, the operator can step through the command sequence in that given file, one command at a time. More specifically, the operator does this by actuating either the STEP THROUGH button 268 or the STEP OVER 269. If the command in question is any one of the commands from the command set shown in Table 1, then the buttons 268 and 269 will both have the same effect. In particular, the system will proceed to interpret that command, and then will stop before interpreting the next command.

[0106] On the other hand, if the current command is a call to a macro file, the buttons 268 and 269 produce different results. In particular, if the operator actuates the STEP OVER button 269, the system will interpret all applicable commands in the called macro and in any macros which it calls, and will not stop in any such called macro except for a reason which would cause a stop if the step mode was disabled. When all pertinent commands in the called macros have been processed the system will then stop before executing the next command in the calling macro. In contrast, if the operator actuates the STEP THROUGH button 268, the system will open an additional similar window for the macro being called, and single step through each of the commands in that called macro. When the system is in step mode and completes interpretation of the last command in a given macro file, the system will automatically close the window for that macro if the window was automatically opened by the system, but will leave the window open if the window was manually opened by the operator.

[0107] A further feature of the debug mode involves the capability to change the values of variables, which include not only internal variables used by PRG and MAC files, but also variables containing data which has been received back from the UUT 13 during the testing process. There are two techniques which the operator can use to inspect and/or change a variable. The first technique is to switch to the main window 146 of FIG. 3, and to type at the debug prompt a proper command which is from TABLE 1, and which has the effect of changing the value of the variable of interest.

[0108] The second technique is to actuate the INSPECT VARIABLES button 270 in the Open Macros window 261 of FIG. 8, which causes the system to open a special View Variables window, an example of which is shown at 291 in FIG. 9. This window 291 includes a list 292 of all global variables, and a further list 293 of all local variables maintained by the current macro. Each list includes the name of the variable, the variable type (for example, “Int” for an integer variable), and the current value of the variable. If the operator wishes to change the value of a particular variable, then the operator can select that variable from the appropriate one of the lists 292 and 293, for example by using the mouse 46 to click on that name of that variable. In response, the system will open an Evaluate Variable window 301, an example of which is shown in FIG. 10. The window 301 is specific to a single variable, and displays for that variable the same information which was shown in the View Variables window 291 of FIG. 9, including the variable name, the variable type, and the current value 302 of the variable. However, the window 301 also includes a region 303, where the operator can enter a new value for that variable, which then replaces the current value.

[0109] As previously discussed, the Tools Menu 181 (FIG. 3) includes “RS232 Spy” and “GPIB Spy” options. Selecting either option toggles on or off the associated feature, each of which involves a special window. More specifically, FIG. 11 shows a window 311 corresponding to the operating system, show the window 146 in a partially minimized size, and shows two additional window 312 and 313. The window 312 is the RS232 Spy window, which provides a scrolling visual display of input and output data passing through the serial port 61 (FIG. 1), for example in a hexidemical format. Similarly, the window 313 is the GPIB Spy window, which provides a scrolling visual display of input and output data passing through the GPIB interface 81. The windows 312 and 313 each appear when the Tools Menu is used to toggle the associated feature ON, and each disappear when the Tools Menu is used to toggle the associated feature OFF.

[0110] Logging of data to a log file in the LogFiles subdirectory 140 (FIG. 2) is not permitted when the system is operating in the debug mode. Accordingly, if logging is enabled when the operator turns on the debug mode, the system will automatically suppress logging so long as the debug mode is enabled, and will then automatically resume logging as soon as the debug mode is disabled.

[0111] As discussed above, the drop-down list 167 for the Print Mode determines whether information will be printed at all and, if so, whether all appropriate information will be printed or only that information associated with errors. In this regard, information which is considered appropriate to print includes all information which is sent to a log file if logging is enabled, and the information which is shown in workspace 151 of FIG. 7.

[0112] In the foregoing discussion of how the PRG and MAC files of Tables 2-12 are interpreted, it was explained that it is possible for these uncompiled files to load and initiate execution of a compiled file, such as the library routines PhyInv.LIB and MemTest.LIB. In a similar manner, it is possible for these uncompiled files to load and run a compiled Dynamic Link Library (DLL) file, which is one of the types of files stored in the HostSoft subdirectory 133. When this occurs, it is possible for the DLL file to continue to run after it returns control to the calling PRG or MAC file, such that some subsequent commands in the PRG or MAC file are interpreted in parallel with execution of the DLL file. Thus, two or more routines or “threads” can be running at the same time. These threads can pass information back and forth between each other through variables. This allows simultaneous testing of different parts of a unit under test.

[0113] As mentioned above, the Test Items drop-down list 169 (FIG. 3) can be used to select either a Normal mode of operation or a Sample Base mode of operation. Table 17 shows an excerpt from a macro file, which includes two groups of macro commands that are respectively designated in Table 17 as Group A and Group B. The commands of Group B are located between an “if” command and an “endif” command, the “if” command being conditional on whether the Sample Base mode is enabled. The commands of Group A will always be always be interpreted, regardless of whether the system is operating in the Normal mode or the Sample Base mode. In contrast, the commands of Group B will be interpreted only if the Sample Base mode is enabled, and will be ignored if the system is operating in the Normal mode. Thus, in this example, more testing will be carried out in the Sample Base mode than in the Normal mode.

[0114] The present invention provides a number of technical advantages. One such technical advantage is that substantially all of the test definitions are set forth in the form of uncompiled files, which are processed in an interpretative mode, and which include commands that are easily readable and intuitive, with a high level syntax. This reduces the time and effort required to develop and troubleshoot test definitions, provides greater portability of a given test definition between different test systems, and reduces the learning curve and amount of time involved in training a new operator or test developer. Due to the portability, it also permits a test developer or test operator to more easily move between different test systems, without extensive cross-training unique to each of the test systems. As to a given test system, it reduces or eliminates the use of different languages by different test developers.

[0115] A further technical advantage involves the provision of the debug mode in a test system, in order to simplify the debugging of new test definitions, and in order to permit quick and easy modification of existing test definitions, for example for the purpose of troubleshooting a particular elusive problem in a specific unit under test. Among other things, the debug mode includes the capabilities to selectively run portions of an overall test, to easily set and remove breakpoints within a test definition, to single step through the commands in a test definition, to inspect or change variables involved in testing, and/or to monitor input and output data traveling through certain ports of the test station. A related technical advantage is the capability to dynamically modify an existing test definition during processing of that test definition, either temporarily or permanently.

[0116] Another technical advantage results from the fact that the uncompiled commands have the capability to initiate execution of a compiled file, so that a particular test operation which is unusually complex or which involves special real-time considerations can be realized. Another technical advantage involves the capability to provide step-by-step instructions to an operator regarding each manual act which the operator needs to do in order to carry out a given test definition. This may include the capability to display a photograph or diagram depicting exactly what the operator should do. This permits an operator to accurately and reliably conduct tests on a variety of different products with only a limited amount of training.

[0117] Yet another technical advantage results from the use of machine-readable indicia on parts which are to be tested, for example in the form of a bar code, in order to accurately identify the particular part. This ensures that any programmable devices on the part can be loaded with the correct version of information necessary to program them, so that the parts will be correctly programmed when they are later sent into the field. Further, it ensures that the correct test definition will be used for testing each part, especially where different revisions of the same part may require different test definitions. Moreover, this selection of information to download into programmable parts, and selection of the correct test definition, is effected automatically, thereby substantially eliminating the possibility of an operator error.

[0118] Although one embodiment has been illustrated and described in detail, it should be understood that various substitutions and alternations can be made therein without departing from the spirit and scope of the present invention, as defined by the following claims.