Multiple axis modular controller and method of operating same

A multiple axis modular controller and a method of operating the controller in a system comprising input devices receiving indications of system conditions and output devices performing tasks affecting the system conditions. The controller includes input connectors connectable to the input devices and output connectors connectable to the output devices. A processor executes a series of sequential commands of an application program. A command can be executed in response to completion of one sequential command of the series of sequential commands regardless of a next sequential command in the series of sequential commands or in response to a specified input received at one of the input connectors or in response to a specified output sent to one of the output connectors. The processor does not execute the command, minimizing processor delays.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates in general to a controller used to control multiple motors, each associated with an axis of movement, wherein the controller is a modular controller, and a method of operating such a multiple axis modular controller.

2. Description of the Related Art

In conventional controllers for a system including multiple subsystems, such as a wafer inspection system, each subsystem is provided with a control unit. For a large system controlling motors along multiple axes of movement, not only must the control units for each subsystem communicate with the motors to which they are connected, they must be able to communicate with each other. For example, in a wafer inspection system, a robot that is transferring a wafer to an inspection stage must know when the stage has secured the wafer so that the robot can stop its motion and release its hold on the wafer.

Conventionally, the position, movement, power level, and other parameters for control of each subsystem of a system are coordinated by a central control unit. The individual pieces of information required by each actuator, such as a servo motor of a robot, are conveyed through the control unit to the central controller, which sends actuating signals to the individual actuators through the appropriate control unit of a subsystem. This can result in a substantial processor burden on the central controller, resulting in slow operation of the system controlled. Further, the more complex the system controlled, the more complex the electrical connections due to the extensive wiring and cabling to the central controller.

Efforts to speed up these operations using faster processor in control units have been made, but they fail to address the resulting complex electrical connections. Also, the complexity of desired operation of systems controlled by these controls units progresses at pace with the increased speeds, with the result that processing delays are still experienced. The combination of speed and processing delays can cause errors in the operation of the system. Increased complexity also increases the risk that the failure of an individual control unit will cause failure of the operation of the entire system, potentially damaging any product in the system.

SUMMARY OF THE INVENTION

This desire for the reduction of processing delays in operating a system is addressed by the present invention, in which the first aspect is a multiple axis modular controller for use in a system comprising input devices receiving indications of system conditions and output devices performing tasks affecting the system conditions. The output devices include at least a first motor and a second motor where the first motor and the second motor are operable to cause movement of a first axis and a second axis. When movement of an axis is discussed, it means movement of a tool, workpiece or product along an axis. The controller includes a plurality of input connectors, each of the plurality of input connectors connectable to a respective one of the input devices, and a plurality of output connectors, each of the plurality of output connectors connectable to a respective one of the output devices. The controller also includes a processor operable to execute a series of sequential commands of an application program and means, separate from the processor, for executing a command in response to completion of one sequential command of the series of sequential commands regardless of a next sequential command in the series of sequential commands, or in response to a specified input received at one of the plurality of input connectors, or in response to a specified output sent to one of the plurality of output connectors. Thus, one or more commands can be executed without incurring processor time.

A second aspect of the invention is a method of operating a multiple axis modular controller in a system comprising input devices receiving indications of system conditions and output devices performing tasks affecting the system conditions. Again, the output devices include at least a first motor and a second motor, the first motor and the second motor operable to cause movement of a first axis and a second axis, respectively. The method comprises connecting each of a plurality of input connectors to a respective one of the input devices and connecting each of a plurality of output connectors to a respective one of the output devices. The method also includes executing a series of sequential commands of an application program using a processor and executing, using means separate from the processor, a command in response to completion of one sequential command of the series of sequential commands regardless of a next sequential command in the series of sequential commands, or in response to a specified input received at one of the plurality of input connectors, or in response to a specified output sent to one of the plurality of output connectors.

Additional features of the present invention are contemplated and are described herein.

DETAILED DESCRIPTION

Referring now to the drawing, one embodiment of the multiple axis modular controller of the present invention is shown in FIG.1and described with reference toFIGS. 1-18. As shown inFIG. 1, the controller10includes a distribution card12and a processor card14connected through a connector interface16. AlthoughFIG. 1shows the controller10as including two cards12,14, one card can include all of the functionality to be discussed hereinafter. Also, the components of each card12,14can be further separated onto additional cards, resulting in a controller10of three or more cards. The connector interface16is an interface incorporated for communications between cards12and14. Preferably, the connector interface16is a 4×30 interface to accommodate the inputs and outputs of the embodiment shown in FIG.1.

Because of its modular design, the controller10is well-suited to control one subsystem of a larger system, such as a robot or gantry in a wafer inspection system. To provide power to the controller and an interface with other controllers of a system, the controller10preferably includes one power connector port28, three IEEE 1394-1995 compatible (IEEE 1394) ports70(only one shown) and two RS232 serial ports74(only one shown), each to be discussed hereinafter. Together, these ports28,70,74interface the controller10with a system in which it is incorporated.

In addition to the controller10possibly interfacing with other controllers in a larger system, the controller10must interface with the devices and components that make up the subsystem the controller10controls. Generally, the distribution card12contains the hardware, such as input and output connectors, that physically perform this integration, while the processor card14includes the hardware and firmware that control the subsystem and its relationship with other controllers. An application program issues software commands described herein to the controller10and is preferably run by a separate host personal computer (PC). However, the CPU66of the processor card14optionally runs the application program. It must be noted that although the controller10is ideal in controlling a subsystem that is part of a larger system, the controller10can also be used in a system containing only one subsystem, that is, a system where the controller10has enough connectors to accommodate all of the input and output devices that make up the system without requiring the interconnection of another controller.

A functional block diagram of the controller10incorporated into a portion of a wafer inspection system is shown in FIG.2. The host PC200is shown connected to the controller10. The host PC200is typically connected to the controller10through one of the IEEE 1394 ports72on the processor card14and the host PC's own IEEE 1394-compatible port and interface. The host PC200is a standard PC with a central processing unit (host processor), read only memory, random access memory, and input/output control circuitry. The host processor is capable of running the application program by providing any number of available commands, many of which are described hereinafter, to the controller10. Only one host PC200is used, regardless of the number of interconnected controllers.

The controller10receives inputs from various sources, such as sensors202, an optional joystick203, an aligner204and at least one encoder206. For example, one sensor202could be a proximity switch indicating that a wafer cassette is at a particular point along a conveyor208. In any system for handling or inspecting wafers, one device that is part of such a system is typically an aligner204, which finds the rotational center and angular orientation of a semiconductor wafer. An encoder206outputs a signal indicating the position of a component of a system, usually along a linear or rotary axis. Here, only one encoder206indicates the position of the conveyor208, however, an encoder is associated with the motor for each axis X, Y and Z of an arm of a robot210.

The controller10, as stated, receives these inputs and, in turn, controls outputs212based upon its programming. One output controlled by the controller10includes, for example, a status light214indicating a fault when the input from the proximity switch sensor202does not activate within a certain time window. Another output212controlled by the controller10can be a toggle switch activating, for example, an inspection laser (not shown) when a wafer is in place for inspection. The controller10also controls movement along an axis. As shown, the controller10controls three axes of an arm of the robot210using an X-axis motor216, an Y-axis motor218and an Z-axis motor220. The controller10also controls an axis of a conveyor208on which wafer tray (not shown) is mounted using a conveyor motor222. Thus, for example, when the conveyor motor222moves the wafer tray into the appropriate position, the controller10instructs the motors216,218and220of the robot210to remove a wafer from the wafer tray. Note that controller10is described in reference to subsystems of a wafer handling and inspection system for illustrative purposes only; its modular design is well-suited to many applications.

Controller Initialization

The ability of the controller10to utilize the commands from the application program run either on-board the controller10or by a host PC, such as host PC200, requires an initial set up of the controller10. This initialization of the controller10starts with the programming of a complex programmable logic device (CPLD)60incorporated on the processor card14. As shown inFIG. 1, the CPLD60is a blank controller programmed with the interface functions as shown in FIG.3through an IEEE Standard 1149.1 (JTAG) port (not shown). Upon power-on or reset, the interface functions of the CPLD60cause it to decode and coordinate access to the functionality of the other components of the processor card14. As shown inFIG. 3, the CPLD60provides interface functions for flash memory62, a field-programmable gate array (FPGA)64, a central processing unit (CPU)66, static random access memory (static RAM or SRAM)68, the IEEE 1394 (FIREWIRE®) Interface72, and the RS232 (UART) Interface76. The alphanumeric display interface shown inFIG. 3is not used in the described embodiment as the use of an alphanumeric display (not shown inFIG. 1) is optional.

For the controller10to function correctly after power-on or reset, additional steps must be completed after programming the CPLD60. Valid programs must be downloaded from the application program into the flash memory62. Code for the field-programmable gate array (FPGA)64and the embedded code for the central processing unit (CPU)66is downloaded into the flash memory62through a flash programming port (not shown), which is a parallel interface to the CPLD60. Preferably, the flash memory62is 8 Megabit non-volatile memory that may be erased electrically at the block or chip level and programmed on a byte-by-byte basis.

Upon power-on, the CPLD60, flash memory62, FPGA64and CPU66, together with the static RAM68, bring the controller10to an operating state. First, the CPU66initializes using control tables in the flash memory62, as is standard, and performs a random access memory (RAM) integrity test. The code for the FPGA64is loaded from the flash memory62, programming the FPGA64with certain logic functions, shown inFIGS. 4-9and to be discussed hereinafter. After the code for the FPGA64is loaded, the controller10will begin operating in accordance with the embedded code of the CPU66, shown inFIGS. 10-17. The CPU66is preferably a 32-bit CPU with a 16K instruction cache and a 4K data cache that can then execute software commands of the application program. The embedded code and the software commands will be discussed hereinafter in more detail.

After the CPLD60and the FPGA64are configured, and all of the embedded code is input into the CPU66, the controller10functions correctly after power-on or reset in response to the software commands of the application software. Subsequent downloading of new code for the FPGA64or embedded code for the CPU66can be done using configuration software commands transmitted from the host processor. Specifically, a special high level host interface command can be used to download an application program, boot program or FPGA configuration file to the controller10. The host processor can also program all controllers in a system simultaneously by broadcasting the command over the entire network of controllers. Preferably, one configuration command gets or sets the name of the controller10on the network it is connected to through its IEEE 1394 connector70in order to more easily identify to which controller a command is addressed.

Certain of the commands available for use in an application program are described herein. However, many standard commands are omitted. For example, those related to reading and writing values from or to the static RAM68and/or the flash memory62are not included. Further, commands such as those that merely report the states of digital inputs and outputs, the encoder counts for each axis, etc., and commands that configure data such as axis setup parameters and digital input setup parameters are omitted as these are within the level of skill in the art, provided with the teachings herein. As it should also be understood, the specific commands used and their order in an application program depend upon the devices and components attached to the controller10and the desired operation of the subsystem. Provided with the teachings herein, one of skill in the art can prepare an application program to perform desired functions using standard commands and the software commands described herein.

Distribution Card

The distribution card12, as mentioned, generally integrates the controller10into a subsystem. The distribution card12performs this function using connectors allowing input signals from input devices that monitor the subsystem and connectors providing output signals to output devices that make up the subsystem. Because of its modular design allowing incorporation into a variety of subsystems, operation of a controller10in a particular subsystem may not require all of the input and output connectors provided herein. In any case, the numbers of input and output connectors shown and described are by example only.

The distribution card12contains digital input buffers18receiving input signals from digital input connectors20. Digital input signals to the controller10may include, by example, output signals from such digital input devices as limit switches or proximity detectors. Although only one digital input connector20and its associated input buffer18is shown inFIG. 1, more than one is preferred. In the embodiment shown inFIG. 1, twenty-four digital input connectors20with buffers18provide the digital input signal INP[0:23] to the processor card14. The digital input connectors20are optionally 5-pin connectors.

A software command of the application program samples a selected digital input at a digital input connector20. Digital inputs from each digital input connector20are buffered through an associated digital input buffer18, which isolates the digital input device from the electronics of the controller10and vice versa. Any standard digital buffer can be incorporated, such as one including a photocoupler. To enable the controller10to interface with input devices operating at various voltage levels, the input buffer18can include jumpers allowing the optional supply of different operating voltages to the digital input connectors20. The different operating voltages will be discussed hereinafter with respect to the digital output buffer32of the distribution card12.

The distribution card12contains analog input connectors22allowing the controller10to monitor parameters of the subsystem from such analog input devices as a thermocouple, a rheostat or a joystick. As with the digital input connectors20, only one analog input connector22is shown inFIG. 1, but a preferred embodiment includes more than one. By example, the analog input connectors22are four 5-pin connectors supplying eight single-ended or four differential analog input signals. InFIG. 1, the four analog input connectors22provide analog input signal IoAD[0:7] to the processor card14. Of course, prior to providing the analog input signals to any component of the processor card14, they are converted from analog to digital. Although not shown, analog-to-digital (A/D) converters are preferably mounted on the processor card14for this purpose. Another software command causes an A/D conversion of a signal from a specified analog input connector22, sampling an analog input from a monitored device.

In a preferred embodiment, an output signal MapStrobe# from the processor card14replaces the ground of one pin of an analog input connector22of the distribution card12to provide a unique delayed sampling function. This function allows an analog input to be received for a period of time before the A/D conversion is initiated to coordinate the A/D sampling and conversion with the occurrence of the peak of the input signal. For example, the input connector22can be set up so that when the MapStrobe# signal goes active, it causes a sensor connected to the input of that analog input connector22to produce an input signal. After a programmable period of time set by a software command, the MapStrobe# signal goes inactive, causing the FPGA64of the processor card14to initiate an A/D conversion to sample the peak of the input signal. This feature is particularly useful when used with a sensor used to detect the presence of, for example, a wafer in a transport cassette. If the peak of the input signal received from the sensor in the predetermined time period in which MapStrobe# is active does not match an expected value, it is likely that the wafer is not present.

Other commands can be included for particular input or output devices attached to the controller10. One example of this is an optional joystick attached to the controller10at an analog input connector22. Special commands for the joystick can include a command to set or get the joystick parameters for the individual joystick axes, where the parameters include, for example, the joystick identification number, the analog input connector22to which the joystick is attached, each value when the joystick is in its maximum negative, center or rest, and maximum positive positions, and the time period between joystick data samples, among others. One particularly useful feature is a command to turn on or off a scan mode for the joystick. When the scan mode is on and the joystick is enabled, the joystick position information is periodically broadcast to all controllers on the network. This allows the position of the joystick attached to one controller10to be used to control the position or velocity of an axis attached to a different controller.

A serial interface connector24mounted on the distribution card12allows inputs to and receives outputs from a peripheral device. For example, when the controller10is incorporated into a subsystem used in handling or inspecting wafers, one device that would be a part of the system is the aligner previously mentioned with respect toFIG. 2, which finds the rotational center and angular orientation of a semiconductor wafer. By example only, the embodiment inFIG. 1shows the inputs and outputs where the serial interface24is connected to such an aligner. It is worth noting that whatever peripheral device is connected to the serial interface24on the distribution card12, commands for such device are typically incorporated into the application program. In the case where the serial interface24is connected to an aligner, as shown inFIGS. 1 and 2, a typical command sent to the aligner acquires a single sample of aligner data as an input, where the data represents the position of the first pixel on the aligner array that is shadowed or covered.

In subsystems and systems in which the controller10is incorporated, one or more encoders are generally included. As mentioned, an encoder outputs a signal indicating the position of a component of a system, usually along a linear or rotary axis. In addition to the example previously provided with respect toFIG. 2, an encoder can be used to indicate, for example, the position of a camera inspecting a product. The controller10incorporates encoder input connectors26, which supply encoder inputs to the processor card14. Like the digital and analog input connectors20,22, only one encoder input connector26is shown inFIG. 1, but more than one is usually included. In fact, an encoder is typically associated with each axis controlled by the multiple axis modular controller10. For example, five 8-pin encoder connectors24whose inputs are fed through differential line receivers (not shown) can provide the inputs EncA[0:4], EncB[0:4] and Index [0:4]. Of course, certain software commands are associated with encoders. For example, commands exist to set or read the encoder position register for a specified axis or the current position for a specified motor encoder, capture the encoder count when an encoder index signal occurs, and compare one or more positions against the actual axis position. The use of the inputs from encoders and incorporation of the inputs into the functions of the controller10will be discussed in more detail herein.

As shown in general inFIG. 1, the power connector port28on the distribution card12provides V_UNSWTCHD to the processor card14and an operating voltage Vdd, typically about 5 volts DC, to both the distribution card12and the processor card14through a power cable (not shown). The 8-pin power connector port28also provides switchable voltages Vsa, Vsb and Vsc to a power switch30. In one embodiment, Vsa is 12 volts, Vsb is 24 volts and Vsc is 42 volts. The power switch30is designed to receive a signal from the processor card14to determine which, if any, of the switchable DC voltage sources is enabled for use by either the controller10itself, a device or component to which an input or output of the controller10is connected, or both.

A software command turns the power switch30on to allow the different operating voltages onto the distribution card12and processor card14of the controller10. In the embodiment shown inFIG. 1, the signal Pwr[0:2] from the processor card14to the power switch30indicates which, if any, of Vsa, Vsb or Vsc is enabled at any particular point in the operation of the controller10. By example, a signal Pwr[00] indicates no switchable voltage is enabled, a signal Pwr[01] indicates Vsa is enabled, a signal [10] indicates Vsb is enabled, and a signal Pwr[11] indicates Vsc is enabled. Although only three switchable voltage sources are provided as an example, additional DC voltages are possible. The ability to switch voltages that control subsystem actuators or motors permits power to be applied to these devices in a controlled sequence so that unexpected physical events that could cause damage can be avoided. This is especially important following the initial power-up of the system where the functioning of the control logic must be established before power is applied to the subsystem actuators. It should be noted that although the power switch30is not shown in detail, its design is within the level of skill of one in the art given the teachings herein.

In addition to these sources of input signals to the controller10, the distribution card12also provides means for output signals from the controller10to reach components of the subsystem. One has previously been mentioned. Specifically, the serial interface24, in addition to providing inputs to the processor card14, also supplies signals from the processor card14to the aligner previously discussed. One such signal includes a software command setting the scan rate for the aligner sensor.

The distribution card12contains digital output buffers32receiving signals from the processor card14and sending buffered digital output signals through digital output connectors34in response to a software command to write a digital output value to a specified digital output connector34. Such digital output signals can operate solenoids, actuators, gates, lights, indicators, etc. The digital output connectors34are optionally 3-pin connectors. Each output signal is buffered through a conventional digital output buffer32, which isolates the outputs from the electronics of the controller10and vice versa. Each output buffer32preferably incorporates the capability of using any one of the available switchable voltages to provide a supply voltage for the output connectors34through the incorporation of jumpers (not shown) to the switchable voltages, Vsa, Vsb or Vsc in the example previously provided. This feature, and a similar feature on each input buffer18, allows easy incorporation of the module controller10into a variety of subsystems with devices and components operating at different voltage levels. InFIG. 1, only one digital output connector34with its associated digital output buffer32is shown; however, more than one connector34is preferable. By example, twelve digital output connectors34with buffers32provide the output signal Out[0:11] to the subsystem.

Any of the twelve digital output signals may be configured via the FPGA control register, shown inFIG. 4, to operate in a pulse width modulated (PWM) mode by another software command. The command causes a specified digital output connector34to convert to PWM mode with a variable duty cycle. This feature allows a digital output signal to produce an average analog output level when integrated over a period of time. For example, one implementation allows the on-time of the digital output to be adjusted from 0% to 100% for every one millisecond time interval. When applied to the control of a light-emitting diode (LED), for example, this technique allows the average brightness of the LED to be adjusted from 0% to 100% of its full brightness. In the embodiment represented byFIG. 4, four digital output signals are configured to operate in PWM mode.

An analog output connector36provides an analog output signal from the processor card14and through the distribution card12to a subsystem component such as a heater. In one embodiment, the analog output connector36is a 3-pin connector. Like the digital output connector34, only one analog output connector36is shown inFIG. 1, but more than one is preferred. By example, four analog output connectors36provide the output signal IoDac[0:3] to the subsystem. One of skill in the art recognizes that at some point prior to supplying the output signal to the analog output connector36, the signal must be converted from digital to analog. Either the distribution card12or the processor card14can incorporate the necessary digital-to-analog (D/A) converters. Yet another software command causes the D/A conversion of a signal sent to a specified analog output connector36.

The four motor driver circuits38included in the controller10and shown on the distribution card12in the embodiment shown inFIG. 1will be discussed in further detail after the discussion of the processor card14.

Processor Card

FIG. 1shows a block diagram of the major components of the processor card14, along with the connections between them and the distribution card12. Although each component of the processor card14has been previously mentioned with respect to the initialization of the controller10, more details are described below. It should be initially noted that, in general, the components of the distribution card12utilize the supply voltage Vdd. However, if other components of the processor card14require a different supply voltage, the processor card14can incorporate any standard power converter (not shown).

Access to the various components of the processor card14, such as the SRAM68, flash memory62, the FPGA64, the IEEE 1394 Interface72, and the RS232 Interface76, are preferably controlled by the CPLD60. As mentioned, the CPLD60is programmed in the initial set up of the controller10with the interface functions ofFIG. 3, which, upon power-on or reset, decode and coordinate access to the functionality of the other components of the processor card14. Once initially programmed, the CPLD60stays in its programmed condition until it is reprogrammed, even if power is lost. This feature of the CPLD60is a distinct benefit where the controller10is incorporated into a system with other controllers and, for example, the CPU66fails. In this case, the interface provided by the CPLD60still functions, allowing communications between the failed controller10, the host PC and the remainder of the controllers of the system through the external interfaces72,76and the respective connectors70,74of the controller10.

Although the CPLD60is described as being a complex programmable logic device, the CPLD60could be a standard programmable logic device, or several interconnected programmable logic devices. What device is chosen depends, in part, upon the number of devices and components with which the controller10is designed to interface. One suitable CPLD60for the controller10is the XCE95288XL from Xilinx, Inc. of San Jose, Calif.

The FPGA64is programmed with certain logic functions, shown inFIGS. 4-9, and acts as a buffer for the signals passing through the connector interface16either from the distribution card12or to the distribution card12. These logic functions speed up the operation of the controller10, as the FPGA64logic functions are performed once the FPGA64receives inputs without the need for further intervention by the CPU66. The logic functions implemented in the FPGA64, while preferably programmed into one integrated chip (IC) such as the XC2S150-FG256 from Xilinx, Inc., can be implemented in more than one gate array or in individual logic chips. Because the programmed logic functions of the FPGA64can be implemented with logic chips, the FPGA64logic functions are sometimes referred to as hardware functions herein.

The logic function shown inFIG. 4has been mentioned previously. It shows the inputs and outputs of the control and mode registers of the FPGA64. The digital input interface of the FPGA64is shown inFIG. 5, which, among other things, performs data integrity checks of the digital input data received from the input buffers18of the distribution card12.FIG. 6shows the interface for a serial peripheral device. Specifically, and in accordance with our example,FIG. 6shows the interface for an aligner, along with the inputs to and outputs from the interface.FIG. 7shows the digital output interface of the FPGA64. The digital output interface receives the output signals from the remainder of the controller10and supplies them to the output buffers32, which in turn supplies the buffered signals to the digital output connectors34.FIG. 7also shows the logic by which a digital output connector34receives signals that cause it to operate in PWM mode.

The encoder interface of the FPGA64shown inFIG. 8illustrates several unique features of the present invention. When the controller10is operational, each encoder of the subsystem produces a quadrature (phase) output to the encoder input connectors26. By example toFIG. 1, one encoder produces EncA2and EncB2, while another produces EncA0and EncB0. A proper phase transition of the inputs occurs when only one state of one input changes at a time. Again by example, if the first phase output is (0/1), that is, EncA2is 0 and EncB2is 1, then the next phase output, if correct, is either (1/1) or (0/0). Occasionally, something goes wrong with a particular encoder due to broken wires or misalignment. When this happens, it is likely that an incorrect phase transition of the inputs occurs. According to the example above, if the phase output started at (0/1), a next phase output of (1/0) is incorrect. Such invalid encoder inputs can cause the motion control loop of a motor to incorrectly drive the motor, potentially causing damage to the system or the product being handled, such as a semiconductor wafer.

The present invention specifically detects errors in phase transitions between the encoder input signals in the FPGA64. As shown inFIG. 8, input signals from the encoder interface26are filtered in digital filters80and supplied to a decoder with error detection82that detects such errors. If an error is detected, an encoder fault bit is set in the FPGA64control register (Encoder Fault). This is input into the motor driver interface of the FPGA64as shown inFIG. 9, and the motor output drive is immediately terminated. Then, the motor control routine of the CPU66takes over, as to be hereinafter discussed. The motor driver interface shown inFIG. 9is discussed in more detail hereinafter with the discussion of the motor driver circuits.

FIG. 8also illustrates the encoder wrap function of the present invention. With reference to a device or motor whose movement is measured by a rotary axis, an encoder interface26may be supplied with rotary position inputs that reflect many revolutions about the axis over a period of time. The counter for the affected encoder channel continues to count until the counter reaches its maximum count. Then, the next count causes the encoder counter to change to its maximum negative value, with a loss of true position. One known solution to this problem is to perform a check before every move to see if the encoder count value is near its upper limit. If the possibility exists that the encoder counter might overflow during the move, the counter can be reset to a lesser value by the embedded software of the CPU66. The current control position and target positions are then adjusted. This solution has the disadvantage that the new position for the encoder must be computed based on the current encoder position, requiring that the encoder not change its value during the time from when the value was sampled until when the new value is written.

The present invention solves this problem by programming the encoder counter84to wrap back to a count, usually a zero count, at a specified encoder count. A wrap value for each encoder is preset and provided to the encoder wrap position register86. An encoder wrap position comparator88compares the wrap value with the value of the encoder counter84. If the comparator88shows that the counter value has reached the wrap value, the encoder counter is reset. An encoder wrap event register90also records the wrap event in an encoder wrap bit. The embedded code of the CPU66then uses the encoder wrap bit in its motor control routine, as will be discussed herein. Thus, the wrap event can occur anytime while the axis is moving without losing or missing any encoder counts.

FIG. 8also shows the hardware function of the FPGA64that allows an output strobe signal to be generated at an exact encoder position specified by a user. This function will be discussed in more detail with the discussion of the embedded code of the CPU66.

As mentioned, after the FPGA64is operational, the embedded code of the CPU66makes the controller10operational. Specifically, the embedded code is loaded from flash memory62into static RAM68. Then, the software objects that support all the hardware functions on the controller10are created. Next, the operating system kernel is created, which is the high-level executive routine for the CPU66shown in FIG.10. The communications and command decoder tasks are created and added to the kernel to be executed, and the board interrupts for communication, motion control, input/output (I/O), etc., are enabled. After all of the these routines are enabled, the CPU66preferably issues a reset to the IEEE 1394 Interface72, which is detected by other modular controllers so connected, if any, including the host PC. The CPU66is then able to start receiving software commands for the controller10, preferably from the host PC as previously discussed.

The command task creation and queuing routine of the embedded code is shown in FIG.11.FIG. 12shows the general command task structure. The embedded code for the communication response of the CPU66is shown in FIG.13. Interrupt routines of the embedded code shown inFIGS. 14 and 15include an input interrupt and a communication interrupt, respectively. The embedded code represented byFIGS. 10-15is not described in detail as the functions listed are well known to those of skill in the art.

A motor control routine of the embedded code of the CPU66shown inFIG. 16uses the encoder wrap bit, previously mentioned in the discussion of the FPGA64. Upon a motor service interrupt at91, the encoder position of the channel associated with a motor selected at92is read at94. Then, that encoder wrap register is read at96. If the encoder wrap register reflects that the encoder has wrapped at98, then the target position is updated at100, the control position is updated at102, and the encoder wrap bit is reset at104. Then, real velocity is computed at106. If the encoder wrap register, at98, reflects that the encoder has not wrapped, the routine advances directly to106, where the real velocity is computed.

Next, at108, if the move is active, then the control values are updated for position, velocity and acceleration at110. The routine at112then queries whether the move is not active and has timed out. If so, an error condition is recorded at114, and additional moves are stopped at116. If the move had not timed out, i.e., it was completed, the position error is computed at118. Returning now to108, if the move is not active, the code advances to118to compute the position error.

After the position error is computed at118, the routine next checks to see if a series of limits have been reached. The hardware limit, soft position limit and stall limit are checked, respectively, at120,122and124. If any of these limits are exceeded, the routine proceeds to114, where the error condition is recorded, and116, where additional moves are stopped.

As mentioned, if there is an error detected in the phase transitions between an encoder's input signals, an encoder fault bit is set in the FPGA control register, shown in FIG.4. This register is read during every motor service interrupt to determine the status of the encoder fault bit at126. If the error condition is present, the error condition is recorded as an error code at114and the move is stopped at116. This error code is passed along to any commands attempting to use that motor, and the error must explicitly be reset in order for motor drive operation to continue.

If no limits have been reached and the encoder fault bit does not indicate the presence of an error, the routine advances to128where the updated motor drive is computed. If the motor drive limit is exceeded at130, then the motor drive is set to zero at132. The hardware motor drive is then updated at134. If the motor drive limit has not been exceeded at130, the routine proceeds directly to134to update the hardware motor drive. Then, a check is made as to whether all of the motors have been serviced at136. If they have not, the routine repeats for the next motor starting at92. If all motors have been serviced, the routine returns from interrupt at138.

FIG. 17, showing the embedded code for the generation of the strobe signal, has previously been mentioned with reference to the encoder interface of the FPGA64, shown in FIG.8. The use of the strobe signal can be illustrated by an example in which a robot is moving a wafer from one position to another ten inches away, and it is desired to operate a camera to capture an image of the wafer at the six-inch position. In conventional firmware or software implementations, the processor may cause a delay in capturing the image past the intended six-inch position due to a delay in processing the command. The embedded code for the generation of a position strobe signal shown inFIG. 17enables and disables the hardware function shown inFIG. 8by a signal sent to the output strobe encoder comparator144. The code also specifies a starting encoder position and a number of counts until the output strobe to the encoder position register140of the FPGA64. Once supplied with this information, the FPGA64generates a strobe signal, i.e., supplies an enabling signal to an appropriate digital output connector34, without intervention of the CPU66. The FPGA64does this by comparing the output of an encoder multiplexer142, whose input is the output of the encoder counter84, to the output of the encoder position register140using the encoder comparator144. When the encoder comparator144indicates a match, the output strobe triggers. Then, the FPGA64notifies the CPU66, which sends the next encoder position and number of counts until the next output strobe. The encoder comparator144is disabled when no additional strobe positions exist.

As previously mentioned, the processor card14includes serial connectors in the form of three IEEE 1394 ports70and two RS232 serial ports74. Each IEEE 1394 port70is connected to the other components of the processor card14through an IEEE 1394 Interface72. The IEEE 1394 Interface72is a standard IEEE 1394-1995 compatible interface including a transceiver/arbiter interfaced to a standard high-speed serial-bus link-layer controller (not shown). Each RS232 serial port is connected to the other components of the processor card14through an RS232 Interface76. The RS232 serial interface is a standard RS232 compatible interface including a dual universal asynchronous receiver-transmitter and an RS232 driver (not shown). In general, the IEEE 1394 ports72are used to interconnect the controller10with other controllers of other subsystems of a larger system and the host PC, while the RS232 serial ports74are used to interconnect the controller10with peripheral devices. Although these ports70,74and interfaces72,76are preferably IEEE 1394 and RS232 compatible, respectively, other communications protocols such as RS485, CAN, Ethernet and USB are possible.

These serial connectors allow peer-to-peer communication between controllers and allow parallel operation of devices connected to and/or controlled by the controller10. For example, a sensor input received by one modular controller10can cause a series of actions of an device, such as a heater, receiving output signals from another controller. This feature is taken advantage of in the present invention by event software commands.

The controller10, and other controllers with which it is interconnected, can be set up for a number of command event sequences using these event software commands. In a command event sequence, the host PC sends certain event commands to the controller10so that upon the completion of the command, an event identification signal (ID) is broadcast to all other controllers. This broadcast ID indicates that a certain event has occurred. The other controllers are set up to execute a command when a specific event ID is received. If the event ID matches any waiting command at the receiving controller, the waiting command is immediately executed. Completion of that command may in turn send another event ID to other waiting commands. This allows sequences of actions to be set up and, once initiated, allows the execution of a simple or a complex sequence of commands among the controllers with no host processor intervention. This reduces the communication latencies in executing the sequential commands in the processor of the host PC and enhances real-time performance.

An example of one command broadcast sequence demonstrates its usefulness. A robot placing a wafer onto a receiving stage has its own modular controller. When the receiving stage senses the presence of the wafer, it needs to communicate to the robot to halt its motion and let go of the wafer. In this case, the robot can be set up with two commands to execute on an event occurrence: (1) stop its motion; and (2) release its grip on the wafer. The receiving stage is set up with a command that sends an event ID on the occurrence of the input associated with its vacuum sensor. When the receiving stage senses the wafer, the event ID is broadcast. The robot receives the event ID, determines that it is a match to its two waiting commands and starts execution of the two commands. The conclusion of each command is returned to the host PC so that it can synchronize the completion of the entire command sequence. Without this command sequence, the software of the host PC could introduce indeterminate latencies, possibly resulting in stress or damage to the wafer. For example, the motion of the robot might not be stopped or the wafer released quickly enough to prevent the wafer from being stressed during its placement on the receiving stage.

Motor Driver Circuits

One particularly useful feature of the controller10is the inclusion of four motor driver circuits38, each connected to a motor connector40. The motor driver circuits38and motor connectors40are included on the distribution card12in the embodiment shown inFIG. 1(only one of each shown). Each motor driver circuit38receives inputs from and provides an output to the processor card12and drives a motor, usually a servo motor, through the motor connector40. A bypass is also provided whereby instead of a motor driver circuit38driving a particular motor through the motor connector40, TTL level signals are sent directly to the motor connector40to control an external driver or a stepper motor, as mentioned below.

One possible design for the motor driver circuits38can more clearly be seen in FIG.18. Only one motor driver circuit38and its associated motor connector40is shown, but each driver circuit38is similar in design. The motor connector40is a three-pin connector by example. The motor driver circuit38includes an N-channel MOSFET driver integrated circuit (IC)50configured as a PWM mode switcher through the use of four power MOSFETs52and four Schottkey barrier rectifiers54. The MOSFET driver50for motor/actuator3receives input Mebl#3, which is a disable signal that, if high, overrides all the other inputs, and Ali3and Bli3, which together determine which outputs of the MOSFET driver50are enabled when Mebl#3is low. One suitable MOSFET driver50is the HIP4082 driver from Harris Semiconductor (Intersil Corporation) of Palm Bay, Fla. The outputs of the MOSFET driver50are provided to pins1and3of the motor connector40. Optionally, the logic level signals Drv3and Dir3may be connected to the pins of motor connector40in order to provide TTL level signals for controlling an external motor driver amplifier or stepper motor controller. In this case, the Mebl#3signal is high to disable the on-board MOSFET drivers50.

A lead to a node between the power MOSFETs52and rectifiers54of each motor driver circuit50is connected to jumpers that optionally supply a different operating voltage to motor3, here one of switchable voltages Vsa, Vsb or Vsc, as discussed with reference to the power switch30.

Monitoring of the current through the MOSFET drivers50is provided by a small sense resistor56. The signal produced by the sense resistor56is buffered and amplified by an operational amplifier (op amp) whose output is connected to the input of a comparator. The other input of the comparator receives an input reference voltage, here MotDac3from the processor card14, and the output of the comparator is a signal MotCmp3provided to the processor card14, along with similar signals from the remainder of the motor driver circuits38. The signal MotCmp[0:3] indicates whether or not the current to each motor/actuator has exceeded a limit established by the value of the comparator input reference voltage. Although the op amp and comparator can be hardware devices, preferably they are contained on one IC op amp/comparator58as shown in FIG.18.

Operation of a motor controlled by either a motor driver circuit38or directly by signals through a motor connector40has been touched upon at various points in the description. For example, the use of switchable operating voltages, such as Vsa, Vsb and Vsc, which are shown at the jumpers in the motor driver circuit38, has been mentioned. In addition, the motor control routine of the embedded code of the CPU66shown inFIG. 16has been described herein. The motor driver interface of the FPGA64shown inFIG. 9has also been mentioned briefly. This digital logic interface of the FPGA64receives signals indicating a particular command for a motor and transforms them into input signals for the motor driver circuit38based upon whether the on-board driver is to be used or whether an external driver or stepper motor is receiving direct TTL level signals.

The axis software commands for the controller10relate, in general, to the position and movement of each axis. When referring to the position of an axis, this means the position of a tool, component or workpiece along an axis. Similarly, when referring to the movement of an axis, this means the movement of a tool, component or workpiece along an axis. The software commands for the position and movement of an axis thus relate to the motor associated with the axis. For example, one command downloads or uploads the motor parameters for a specified axis. The motor parameters include, among other things, the position at which the encoder will wrap, the encoder connector26to which the encoder is connected, the motor acceleration and current limits, and the maximum and minimum position limits for the motor. Other commands include a command to enable or disable the drive to a particular axis, and a command causing power to be applied to a motor in an open loop fashion. Another command is used to get the error status for a motor and is used to reset any or all of the error flags.

Many commands control the moyement of an axis. One command causes the axis to repeatedly cycle back and forth between two specified positions. Another command the axis to a new position by either specifying the new position or specifying a change from its current position. Of course, standard commands such as that establishing the zero, or home, location of an axis are also included.

Preferably, the controller10includes commands to minimize the need for the sequential processing of commands by the CPU66and the host processor, thus speeding up the operation of the controller10. The broadcast commands have previously been discussed. In addition, a linking command enables an axis, i.e., the linked axis, to be electronically linked to another axis, i.e., the parent axis. The linking command can, for example, make the linked axis linearly dependent on the parent axis. Thus, a command to move the parent axis 22 cm could also cause the linked axis to move 11 cm.

Another command coordinates movement of several axes through a number of spatial coordinates along the motion path by specifying one axis as a master control axis and with at least two slave axes. For this command, the master axis can be a non-physical, or virtual, axis. The path distance of the move through all the spatial coordinates is computed and treated as a one-dimensional distance by the virtual axis. The encoder resolution of the virtual axis is computed as the multidimensional diagonal of the encoder resolutions of the individual slave axes. The motion control parameters associated with the master axis, jerk, acceleration, and velocity, for example, will control the jerk, acceleration and velocity of the control point as it moves through the spatial coordinates. This technique allows the dynamics of the control point to be set as though a single axis is being moved.

The modular controller presented can control multiple axes and allows peer-to-peer communications between outputs, especially motors, including motors connected to another controller, that minimize the need for sequential processing of commands through the CPU66and any host processor of a host PC.