semi合集-English.pdf - 第1540页

SEMI E32-0997 © SEMI 1994 , 1997 35 AP P L I C AT I O N N OT E S A1 -1 Transfer -Related Mechanisms — A transfer job interacts very clo sely with p ort-related hardware. This may i nclude a variety of mechanisms such as …

100%1 / 7923
SEMI E32-0997 © SEMI 1994, 1997 34
Cmd Description
Pick Commands the secondary partner to take all
actions necesary to remove the transfer object
from the primary partner's port.
Place Commands the secondary partner to take all
actions necesary to place the transfer object in
the primary partner's port.
Extend Commands the secondary partner to reach into
the primary partner's port area in close proximity
to the material location.
Acquire Commands the secondary partner to acquire
control of the material.
Release Commands the secondary partner to release
control of the material.
Retract Commands the secondary partner to withdraw
from the primary partner's port area.
Store Commands the secondary partner to place the
transfer object in its final location.
Retrieve Commands the secondary partner to pick up the
transfer object from its initial location.
MoveTo Commands the secondary partner to move its
transfer mechanism (e.g., robot gripper) to a
specified position (given as a parameter).
The Pick command might actually be an equivalent of
the sequence:
Extend, Acquire, Retract, Store.
The Place command might be an equivalent to the
sequence:
Retrieve, Extend, Release, Retract.
HOCancelAck — Conveys the response to the
HOCancelReady request. Possible values are:
0 — Accept Cancel.
1 — Atomic Transfer Unknown.
2 — Reject Cancel—Transfer Begun.
HOHaltAck — Conveys the response to the HOHalt
request. Possible values are:
0 — Accept Halt.
1 — Atomic Transfer Unknown.
SEMI E32-0997 © SEMI 1994, 199735
APPLICATION NOTES
A1-1 Transfer-Related Mechanisms — A transfer job
interacts very closely with port-related hardware. This
may include a variety of mechanisms such as port
doors, cassette indexers, robot arms, carrier restraints,
etc. The state models for the transfer job and atomic
transfers shown above relate to this port hardware, but
do not define hardware behavior directly. Therefore, an
additional state model is needed for the port hardware.
A1-1.1 Example Port State Model — Figure A1-1
provides an example of a state model for a port. It is
divided into three AND substates: MECHANISM,
AVAILABILITY, and PAUSE. These substates
represent the three most common areas of interest to the
host.
Below, the states shown in Figure A1-1 are described,
followed by a transition table. This is presented as an
example. The actual model is implementation-
dependent.
Figure A1-1
Example Port State Diagram
MECHANISM
This state pertains to the port's overall ability to
function. It has three substates: INIT, NORMAL, and
FAULT.
INIT
This is the default state upon powerup or reset of the
port. It includes some unspecified operations to ensure
that the port is ready to operate.
NORMAL
When in this substate, the port is in normal working
order.
FAULT
In this substate, a problem has been detected with a port
mechanism.
AVAILABILITY
This state pertains to the availability of the port to
perform a function. This state has two substates: NOT
ALLOCATED and ALLOCATED.
NOT ALLOCATED
In the NOT ALLOCATED state, neither the equipment
nor the host has allocated the port. The port is waiting
to be allocated to either a transfer job or to some
process-related task. This is the default state upon
equipment system startup.
ALLOCATED
In this state, the port is allocated to either the equipment
(typically process-related) or to the host for a transfer
job.
NOTE: If the port is allocated to an equipemnt function and
the host does not wish to wait for the equipment to release the
port, it must take some other action to force the port to
become available. One possibility is a “Pause for Transfer”
remote command that might be used during a processing
cycle.
IDLE
Port is allocated to a task (e.g., processing or transfer
job), but activity on the task has not yet begun.
PAUSE
This state pertains to the pausing of current port
activity. Pausing of the port is different than pausing a
transfer job which might be using the port.
NOT PAUSED
The port defaults to NOT PAUSED upon system
startup. In this state, port activities are not hindered by
the pause function.
PAUSING
In this state, the port has received a directive to pause
and is in the process of bringing the current activity to a
halt.
PAUSED
All port activity has ceased. The port is awaiting a
directive to resume activity.
Table A1-1 describes the transitions for the example
port state model. In the application-specific
implementation, events should be defined for all
significant occurences related to the model.
SEMI E32-0997 © SEMI 1994, 1997 36
Table A1-1 Extended Atomic Transfer State Transition Table
# Current State Trigger New State Action Comment
1 (Undefined) Entry into PORT Model. INIT None. None.
2 INIT Port mechanisms found to be functional. NORMAL None. None.
3 NORMAL A malfunction of the hardware occurs. FAULT None. None.
4 FAULT The malfunction is “fixed.” This may be a manual re-
initialization of the port.
INIT None. None.
5 INIT A problem occurs during initialization. FAULT None. None.
6 (Undefined) Entry into PORT Model. NOT ALLOCATED None. None.
7 NOT
ALLOCATED
The port is allocated to transfer or process job. ALLOCATED None. None.
8 ALLOCATED Port is released from current job. NOT ALLOCATED None. None.
9 (Undefined) Entry into PORT Model. NOT PAUSED None. None.
10 NOT PAUSED Directive issued to pause port. PAUSING None. None.
11 PAUSING Port activity has ceased. PAUSED None. None.
12 PAUSED Directive issued to resume activity. NOT PAUSED None. None.
13 (Undefined) Entry into ALLOCATED state. IDLE None. None.
14 IDLE Task activity begins. BUSY None. None.
15 BUSY Task activity ends. IDLE None. None.
A1-1.2 Additional Related Mechanisms — Many
equipment material ports have additional related
mechanisms that can aid or interfere with a transfer.
These mechanisms can be represented as parallel (or
orthogonal) states within the port state model. Most
such state models will be simple two–state instances
(e.g., open/closed, on/off).
In some circumstances, the host will have a need to be
able to understand the status of these mechanisms and
may wish to be informed of state changes. This is
especially true if the host is to do error handling and
preliminary diagnosis of problems. The host also may
need some level of remote commands to manipulate
these mechanisms. Some possible transfer-related
mechanisms are discussed below.
Port Material Sensors: These sensors detect the
presence or absence of material in a port. The change in
this status is important, and an event should be provided
to report change in this condition.
Port Doors: Some equipment closes the environment
internal to the equipment, except during material
transfer. The applicable states are normally
open/closed.
Port Elevator: Port elevators have multiple states such
as HOME, MOVING, SLOT 5 ACCESS, or interlocks
such as BLOCKED BY INTERNAL TRANSFER
ARM.
Robot Arm: The transfer arm may be in motion, may
be holding material, etc.
Carrier Restraints: On some ports, carriers are clamped
in place and cannot be removed unless the restraints are
released. There would be a clamped/unclamped state
model.
A1-2 WIP Tracking — WIP tracking refers to the
ability of an entity (host or equipment) to keep accurate
track of the material within its domain. Typically, the
equipment is expected to track the material's location
within its modules and subsystems, while the host may
take a more global view, knowing at which equipment
(or storage area) a specific transfer object resides.
The process of material movement crosses the
boundary of the equipment domain. Therefore, there
must be information exchanged between host and
equipment about what material is being transferred and
what the plans are for the material (e.g., when and how
processed).
It is outside the scope of this standard to define WIP
tracking capabilities, either at the host or equipment
level. However, it is critical for the material movement
function to supply enough information that WIP
tracking is feasible. Specifically, the material
movement messaging must identify the object being
transferred. WIP references are kept at a minimum. For
example, for a carrier containing wafers, the material
movement process would need to know the carrier
identifier, but need not be concerned with the specific
lot contained within. It is also outside the scope of this
standard to be concerned with the detailed contents or
status (e.g., processed or not) of a transfer object. These