semi合集-English.pdf - 第1543页

SEMI E32-0997 © SEMI 1994 , 1997 38 and continue to retry at intervals. Note that a disconnect may be n ormal in some cases where the link is only made when th e transfer partners are in close proximity. 2. TRLink's…

100%1 / 7923
SEMI E32-0997 © SEMI 1994, 199737
are important issues that should be dealt with
elsewhere.
A1-3 Error Handling — This section addresses some
common problems that may occur during the transfer
process. This is not intended to present hard and fast
rules for error handling, but rather to raise potential
issues and suggest possible solutions. Several primary
error or interrupt types are covered. For state model
representations of hardware faults, see Section A1-1.
NOTE: Transfer errors are not completely communicated
between transfer partners. The host may be responsible for
pausing or aborting (as needed) the activities of the partner or
equipment with an error condition.
A1-3.1 Macro Level Error Handling
1. Transfer Specification Error
This would consist of an error in the data contained in
the Transfer Job Create request. Some examples might
include specification of a static port as an active
transfer partner or the use of a non–existent port on the
equipment. Such an error should result in rejection of
the Transfer Job Create request.
2. Setup Error
It is during the setup for an atomic transfer that many
prerequisites are typically checked. A setup error may
be either a hardware or a transfer specification problem.
Hardware problems might be such events as cassette
elevator fault, door fails to open, etc. If a hardware
problem occurs, the transfer job is paused and the
hardware state model makes a transition to the FAULT
state (see Section A1-1). When the problem is
corrected, the host may resume the activity or stop the
transfer job.
A transfer specification problem would typically relate
to the presence or absence of material at specified
locations. If there is a transfer specification problem
found, a transition to the RESTORE state is made
(transition #5) and the transfer job is terminated.
3. Restore Error
A restore error occurs when the port cannot be brought
back to its desired physical condition for the NOT
ALLOCATED state. This would be a failure of a
hardware mechanism. The hardware should then
transition to the hardware FAULT state (see Section
A1-1). The “completeness” of the transfer job may not
be hindered by problems in the restore activities.
However, the next transfer job may be affected.
4. Transfer Error
Transfer errors may be of many types and of varying
levels of severity. Any error that occurs must be
reported to the host. If the error is caused by failure of a
port mechanism, a transition to the hardware FAULT
state should occur (see Section A1-1). The problem
might also stem from a problem with the transfer
specification or in the transfer recipe (i.e., specification
is legal, but does not match that of the partner). If
failure in the transfer hardware has occurred, the
transfer job should transition to the PAUSED state and
report it to the host. The host may choose to abort the
transfer job, or correct the problem and resume the
transfer job.
5. Timeouts
To ensure that all transfer problems are detected, the
host should implement a process for timeout monitoring
of transfer jobs. The timeout periods need only be very
rough estimates of the actual times required for the
transfer job (e.g., 2× or 3× actual). The host might
choose to monitor individual atomic transfers if tighter
tolerances are required. The goal is to ensure that
problems are not left undetected over extended periods.
To determine the proper time to allow for a transfer job,
the host would sum the estimated maximum times
needed for the individual atomic transfers which make
up the job
14
. The atomic transfer time estimates would
typically be determined by experience, since they rely
on the interactions of two different transfer partners. A
doubling or tripling of the average observed transfer
time would be a good estimate. In some cases, suppliers
of dedicated transfer equipment may be able to supply
reasonable estimates.
Transfer job timeout monitoring should begin with the
receipt of the “Transfer Job Started” message and end
with the “Transfer Job Complete” message (both via the
TRJobAlert service). If the host is monitoring the
atomic transfers, monitoring should begin at the
“Atomic Transfer Started” event and end at the
“Atomic Transfer Complete” event (both via the
TRJobEvent service). The host must ensure that
reporting of these events is enabled in this case.
If a transfer job exceeds the timeout period, the host
may either pause the transfer job or attempt to end it
with the stop command. The former may be preferred,
since human intervention is required in either case and
may enable a resume command to continue the transfer.
A1-3.2 Micro Level Error Handling
1. No Communication With Transfer Partner
If a transfer partner attempts to communicate with its
transfer partner and finds that the communications link
is not responding, it should inform the host via an event
14 This assumes that atomic transfers proceed sequentially. If they
may proceed in parallel, the sequence for each port may be summed
and the longest total chosen as the estimated time.
SEMI E32-0997 © SEMI 1994, 1997 38
and continue to retry at intervals. Note that a disconnect
may be normal in some cases where the link is only
made when the transfer partners are in close proximity.
2. TRLink's Not Matched
If two transfer partners are attempting different
handoffs using the same physical resources (locations,
mechanisms, etc.), the host should be informed via an
event. The partners shall continue to await an
appropriate HOReady message—allowing the host to
“fix” one or the other of the partners. If an equipment
has no current transfer and it receives a HOReady
message, it should hold that message until a transfer job
is defined for it.
3. HOCommand Not Accepted
If the secondary transfer partner cannot accept a micro
command from the primary partner, it should use the
HOCommand Response message to inform the primary
partner that the command was rejected. The primary
partner may affect some recovery or inform the host
that the transfer has failed.
4. HOCommand Failed in Execution
If the secondary transfer partner fails in the execution
of an HOCommand, it should notify the primary partner
of the problem. The primary partner may affect some
recovery or inform the host that the transfer has failed.
5. Transfer Not Confirmed
If the secondary transfer partner sends a negative
HOVerify Response message saying that the transfer
object has not been properly transferred, the primary
partner should not attempt recovery, but inform the host
that the transfer has failed.
6. Timeout Awaiting Partner Readiness (HOReady)
Timeout Awaiting Micro Command Completion
(HOCommand Response)
Timeout Awaiting Transfer Verify Response
(HOVerify Response)
In some cases, action may be required if a transfer
partner has been awaiting communication from its
partner. The equipment should monitor timeout periods
for each of the three cases. The factory user may need
to customize the timeout periods for his/her factory.
When a timeout occurs, the equipment should notify the
host (via a TRJobEvent message) that the situation has
occurred, reset the timer, and continue to await the
partner. The host is responsible for taking any further
action which is required (e.g., Stop or Pause command).
A1-4 Practical Applications — This section provides
examples of practical applications of the material
movement services as presented in this document. Four
examples are provided below. Within these are
presented some major variations expected in a factory
situation. These are not exhaustive in scope, but the
expectation is that reviewing these examples will help
the reader understand how to apply these concepts to a
real application. These examples are also not intended
to represent a cohesive implementation strategy, but
rather some alternatives that might be considered.
AGVs are used in the examples below because they are
familiar to most readers, not because they are favored
over other transfer agents. To simplify the explanation,
the examples below deal only with movement of
cassettes.
A1-4.1 Passive Transfer — In this example, a transfer
is to be performed between an AGV with robot arm and
a piece of processing equipment. A cassette is to be
picked up by the AGV for later delivery to another
piece of equipment. The equipment has a cassette
indexer and a port door, but no other port-related
mechanism that would either aid or hinder transfer. The
chosen transfer mechanism provides for the equipment
to act as a passive transfer partner with no micro level
communications required. This is called a passive
transfer. The primary transfer partner is the AGV.
The setup for the equipment is to check to make sure
that the correct material is in the specified port, drive
the cassette elevator to the home position (if not already
there), and open the port door. Note that the first two
setup activities could have been designed to occur as a
part of the micro level transfer if desired. The setup
operations for the AGV are to ensure that its receiving
port is empty and to drive to the transfer position in
front of the designated equipment.
The transfer proceeds in the following steps:
1. The host sends a Transfer Job Create message to
each transfer partner.
2. The partners each accept the transfer job.
3. The equipment both have the needed available
resources so the transfer job immediately. Thus,
Transfer Job Started messages are sent to the host
by each.
4. Each partner in turn completes its setup activities
for the atomic transfer, sends a “Committed To
Transfer” event to the host, and then sends an
HOReady message to its transfer partner (via the
host).
5. Each partner sends the “Atomic Transfer Started”
event to the host as soon as it determines that it has
both sent and received an HOReady message for
this handoff.
SEMI E32-0997 © SEMI 1994, 199739
6. The AGV (as primary transfer partner) begins the
transfer.
7. The AGV performs the transfer. Notice that no
HOCommand messages are needed since this is a
passive transfer.
8. The AGV sends an HOVerify message to the
equipment via the host.
9. The equipment ensures that the cassette is no
longer sensed in its port and then sends an
HOVerify Response message (via the host) to the
AGV, followed by an “Atomic Transfer Complete”
event to the host.
10. Upon receipt of the HOVerify Response message,
the AGV sends an “Atomic Transfer Complete”
event to the host.
11. Each partner completes its RESTORE operations
and then sends a Transfer Job Complete message to
the host.
The transfer is now complete. The host may now direct
the AGV to deliver the cassette to a new destination.
A1-4.2 Active Transfer/Exchange of Cassettes — This
example addresses the situation where the factory
control system needs to remove a processed lot from an
equipment and immediately replace it with an
unprocessed lot. The assumptions are that the
processing of the lot on the equipment is nearing
completion and that the AGV has already acquired the
unprocessed lot that will next be placed on the
equipment. Direct micro level communications exist
between the AGV and the equipment. This will be an
interactive transfer.
The setup operations for the equipment are opening the
port door, driving the cassette indexer to the home
position, and checking for the presence of the proper
cassette. AGV setup is movement to the transfer
location for that equipment. During the transfer, the
equipment acts as the primary transfer partner, and will
unclamp/clamp the cassette (clamps hold the cassette in
the proper position). The AGV will interact with the
equipment as the secondary transfer partner.
The transfer proceeds as follows:
1. The host sends Transfer Job Create requests to the
equipment and to the AGV. The timing is chosen
so that the time required for the AGV to travel to
the equipment is approximately equal to the time
left to complete processing of the lot to be
transferred. The Transfer Job Create message to
each contains two atomic transfers, the first dealing
with the removal of the processed cassette from the
equipment and the second dealing with the loading
of the unprocessed cassette onto the equipment.
2. The AGV accepts the transfer job and begins the
first atomic transfer immediately, sending a
Transfer Job Started message to the host. Setup
begins — the AGV begins traveling toward its
transfer partner. The equipment accepts the transfer
job and retains it for later execution.
3. When processing completes on the lot, the
equipment begins the transfer job. It sends a
Transfer Job Started message to the host and
begins its setup operations for the first atomic
transfer.
4. The AGV completes its setup activity and sends a
“Committed To Transfer” event to the host. It also
sends a HOReady message to the equipment.
5. The equipment completes its setup, then sends a
“Committed to Transfer” event to the host and an
HOReady message to the AGV.
6. Since the AGV had previously declared itself
ready, the equipment sends an Atomic Transfer
Started event to the host and starts the transfer.
7. The equipment begins by sending an HOCommand
that results in the AGV reaching out and grasping
the cassette.
8. Upon receiving the Command Complete message
from the AGV, the equipment unclamps the
cassette, allowing its removal.
9. The equipment sends an HOCommand that results
in the AGV removing the cassette from the
equipment. The material sent and material received
events are sent to the host by the respective
partners.
10. When the equipment receives the Command
Complete message from the AGV, it considers the
transfer to be complete. It sends the HOVerify
message to the AGV.
11. The AGV sends the HOVerify Response message
to the equipment.
12. Each of the transfer partners now determines that
another atomic transfer is required in order to
complete the transfer job.
13. Each transfer partner now transitions to the second
atomic transfer. They each send “Atomic Transfer
Complete” events.
14. Each transfer partner now begins the new setup
phase. The AGV determines that it has already
reached the transfer point and has the unprocessed
cassette to be transferred. The equipment
determines that the port is now empty, and that the
door is open. This setup time was saved.