semi合集-English.pdf - 第1534页

SEMI E32-0997 © SEMI 1994 , 1997 29 5 Mi cro Level 5.1 Micr o Level Concepts — The m i c ro level of material movement is defi ned below to allow for interaction between trans fer partners on a step–by–step basis during …

SEMI E32-0997 © SEMI 1994, 1997 28

4.5.2 TransferJob Object — The attributes of the TransferJob object are defined in Table 4.6. A TransferJob is

created by the equipment when it accepts a transfer job create request from the host, and its attributes are based upon

that request.

Table 4.6 TransferJob Object Definition Table

Attribute Name Definition Access Requirement Form

ObjType Object type. RO Y Text = “TransferJob”

ObjID Textual version of TRJobID. RO Y Text

TRJobID Identifier assigned by the equipment. RO Y Unsigned integer

TRJobName Host-created job identifier. RO Y Text

TRJobState Current state. RO Y Enumerated:

TRJobQueued,

TRJobActive,

TRJobComplete

TRAtomicList List of (TRAtomicID). RO Y List of unsigned integers

4.5.3 AtomicTransfer Object — The attributes of the AtomicTransfer object are defined in Table 4.7.

AtomicTransfer objects are created by the equipment when it accepts a transfer job create request from the host, and

its attributes are based upon that request.

Table 4.7 Atomic Transfer Object Definition Table

Attribute Name Definition Access Requirement Form

ObjType Object type. RO Y Text = “AtomicTransfer”

ObjID Textual version of TRAtomicID. RO Y Text

TRAtomicID Identifier assigned by the equipment. RO Y Unsigned integer

TRAtomicState Current state. RO Y Enumerated:

TRAtomicActive,

TRAtomicComplete

TRLink Assigned by the host to identify an atomic transfer. RO Y Unsigned integer

TRPort Material I/O Port identifier. RO Y Unsigned integer

TRObjName Textual identifier of transfer object. RO N Text

TRObjType Material type of transfer object. RO N Enumerated

TRRole Equipment’s role. RO Y Enumerated:

Primary or Secondary

TRRecipe Recipe identifier for transfer recipe. RO N Text

TRPartner Name of equipment’s partner. RO Y Text

TRPartnerPort Identifier for partner’s port. RO N Unsigned integer

TRDirection Indicates whether the equipment will send or receive. RO Y Enumerated:

Send

Receive

TRType Indicated the equipment is to be active or passive. RO Y Enumerated:

Passive

Active

TRLocation Identifies location on the equipment of the source (or

destination) of the transfer object.

RO N Unsigned integer

TRAutoStart Indicates whether the equipment may automatically start

the handoff without waiting for a StartHandoff

command.

RO Y Boolean:

Automatically start (TRUE).

Wait for StartHandoff (FALSE).

SEMI E32-0997 © SEMI 1994, 199729

5 Micro Level

5.1 Micro Level Concepts — The micro level of

material movement is defined below to allow for

interaction between transfer partners on a step–by–step

basis during a handoff. It was designed to be used in

conjunction with the macro level defined above but

may instead be used with some other transfer

coordination mechanism.

5.1.1 Micro Level Definitions

Handoff — The process by which the transfer object

moves from the sending transfer partner to the receiving

transfer partner. The terms “handoff” and “micro level”

refer to the same transfer activity.

Micro Move — One of a sequence of moves required

during a micro level process to effect the transfer of an

object. This is normally associated with physical

activity within the transfer envelope.

5.1.2 Micro Level Description — While the macro

level of material movement deals with coordination and

preparation for a transfer, the micro level addresses the

physical synchronization between two transfer partners

during an atomic transfer. To control these physical

interactions properly, communication between the

transfer partners is required. Using these

communications, the partners shall ensure that both are

ready to perform the same specific transfer, that both

agree on the mechanism, and that movement within the

transfer envelope is properly coordinated.

There are three parts to the micro level interaction

between transfer partners. Each of the three parts must

occur in some form for the micro level to integrate

properly with the macro level.

1. The first part is the exchange of “I'm ready” type

messages, so that the partners can be sure that

starting the transfer is appropriate.

2. The second part of the micro level interaction is the

coordination of the physical transfer. During a

transfer, control of the transfer envelope may

belong to only one partner at any time. Joint or

parallel movement is never allowed in this space

The transfer itself is a series of steps called micro

moves. Each step typically contains all the

activities one partner can perform before the other

must act. If the secondary partner is passive during

the move, no micro level communications are

needed for part two, since the primary partner shall

control the transfer envelope during the entire

physical transfer.

13 The space outside the transfer envelope is not restricted, and some

preparations for the next micro move may be possible in this space.

3. The third part of the micro level interaction is the

verification that the transfer is complete.

The micro transfer mechanism assumes that the

secondary partner will recognize and respond to some

list of micro commands known to the primary partner.

These commands might range from the very specific

(e.g., “reach out and grasp the transfer object”) to the

very general (e.g., “perform the next step in your

sequence”).

5.2 Micro Level Behavior

5.2.1 Micro Level Communications — This section

provides baseline definitions of the communications

needed by the micro level of material movement. More

detailed definitions of the messaging services can be

found in Section 5.4 below. Refer to Figure 5.1 while

reading the message definitions. In the figure, the

messages in italics are macro level messages provided

for reference. The bolded messages are the micro level

messages.

The prefix “HO” (for HandOff) is appended to the

names of micro level messages to differentiate them

from the “TR” transfer messages.

HOReady — Upon completion of any setup operations,

each transfer partner shall declare to the other that it is

prepared for the specified atomic transfer. Either

partner may make this declaration first. When the

HOReady exchange has been made, the primary partner

shall start the transfer. The HOReady messages include

a transfer identifier (see TRLink), which the partners

match up. Looking back at the macro level atomic

transfer state diagram (Figure 4.6), the combination of

having sent and received a HOReady message for the

specific transfer will spur the transition from the

SETUP to AWAITING TRANSFER PARTNER states.

It is possible that an equipment will receive a HOReady

message from its partner before it has received the

corresponding Transfer Job Create request from the

host (e.g., setup is instantaneous). An equipment shall

be able to retain such a received message for a time to

allow the host to deliver the corresponding Transfer Job

Create request.

HOCommand — The HOCommand is the mechanism

by which the primary transfer partner orchestrates the

sequence of micro moves necessary for the transfer.

The primary transfer partner shall successively perform

its own micro move, then direct its partner to perform

its next move. Thus, the partners may alternate control

of the transfer envelope during the transfer. If the

secondary partner is passive during the entire transfer

and the primary performs all physical activity, no

HOCommands are required — they are implicitly

executed by the primary partner. Only one

HOCommand may be active at any time.

The list of commands to execute may be included in a

transfer recipe. See Section 4.2.4 above for more detail.

Figure 5.1

Micro Level Message Flow

When the secondary partner is passive, no

HOCommands need be issued. In this case, all micro

moves are conceived of and executed by the primary

partner. The HOReady and HOVerify portions are still

required in this case.

HOCommand Complete — Once the secondary partner

has completed the task defined in the HOCommand, it

uses the HOCommand Complete response message to

alert the primary partner. If an HOCommand cannot be

accepted or fails, this message shall be used to convey

that information.

HOVerify — The primary transfer partner, believing all

micro moves complete, shall check its port to ensure

that the transfer object has been sent (or received) and

that all mechanisms are in a safe position. Next, it shall

send the HOVerify message to the secondary partner,

asking that it perform the same check.

HOVerify Response — The affirmative response from

the secondary partner confirms that the transfer was a

success. This message may alternatively signify

(through a data field) that the secondary partner does

not consider the transfer to be complete. This message

coincides with the transition for both partners from the

macro level TRANSFERRING state to the ATOMIC

TRANSFER COMPLETE state.

5.2.2 Micro Level Messaging via Host — As

mentioned above, all three parts of the micro level of

communications must be carried out in some form. If a

direct link from equipment to equipment exists, they

should occur via that means, whether using SECS–I,

Parallel I/O, or another protocol. If no direct link exists,

there is a means by which the host may relay micro

level messages from one transfer partner to the other.

This is illustrated in Figure 5.2.

Figure 5.2

Micro Level Message Flow via Host

In this situation, the host may act as a surrogate of each

equipment's transfer partner. A piece of equipment

would send the same defined micro level message as

before, but would deliver it to the host via the standard

host link. The equipment would treat the host as its

transfer partner, expecting the same response as if it

were talking directly to its true transfer partner. The

host is responsible for managing the relay of messages

from one partner to the other as necessary.

The equipment shall provide the ability to pass micro

level messages through the host. If a direct peer–to–

peer link is available, the user shall be able to configure

the path for the messages (directly to partner or through

the standard host link).

5.3 Extended Behavior — This section discusses two

micro level messages which may be exchanged