semi合集-English.pdf - 第1320页

SEMI E5-1104 © SEMI 1982, 2004 262 equipment. Because special programm ing would be required at the host to und erstand the equipment’s unique data fo rmat, the proc ess program i s most likely generated at the machine a…

SEMI E5-1104 © SEMI 1982, 2004 261

form as S6,F3-4 but does not require the value name in

the data set. Instead, the order of the values is fixed

format for the particular DSID in that particular

equipment.

R1-3.3.5 When either of the above data messages is

long enough to require multiple blocks, it must be

preceded by S6,F5-6 to gain permission to send a

multiple block message.

R1-3.3.6 The last data control transaction is S6,F7-8,

which is initiated by the host and causes a specified

DATAID to be sent to the host. The implementation of

this function is highly equipment-dependent. In

essence, it is equivalent to the host causing an event

that triggers the sending of the data. Since the

equipment may be generating the data, the actual data

sent depend upon the equipment implementation. The

equipment can respond with a zero length item if no

data can be sent.

R1-3.4 Event Reporting

R1-3.4.1 The third major type of data reporting is

similar to that described in A3.3 above, with the

following enhancements:

1. Contents of data reports are not limited to

DVVALs, but may include SVs or even ECVs.

2. Contents of data reports are user programmable.

R1-3.4.2 It is assumed that the equipment vendor

supplies a list of all “events” identified within a

particular piece of equipment. A Collection Event

Identifier (CEID) must be specified for each of these

events. It is further assumed that the vendor supplies a

list of all available variables within the machine. This

includes Status Variables (SVs) and their identifiers

(SVIDs), Equipment constants (ECVs) and their

identifiers (ECIDs), and Data Values (DVVALs) and

their identifiers(DVNAMEs). Each of the identifiers

must be unique. The term VID (Variable Identifier)

encompasses all SVIDs, ECIDs, and DVNAMEs.

Likewise, the term V (Variable Data) encompasses all

SVs, ECVs, and DVVALs.

R1-3.4.3 Note that a Variable (V) may be a list (format

code 0). This provides for referencing a group of

related data values with one identifier. Consider the

following:

VID

= 1 zone 1 temperature ID Format 32

zone 1 temperature value Format 52

VID

= n zone n temperature ID Format 32

zone n temperature value Format 52

VID

= x all temperatures ID Format 32

L,n Format 0

1. L,2

1. <VID

2. <V

n. L,2

1. <VID

2. <V

Any V in a list may also be a list (for nesting).

R1-3.4.4 In a typical initialization sequence, the host

would define all the desired programmable data reports

with S2,F33/S2,F34 (Define Report) transactions. Then

S2,F35/S2,F36 (Link Report/Event) transactions would

be used to define which reports are to be made by the

equipment upon specific events (CEIDs). An

individual report may be linked to more than one event.

At this point the host may request reports with the

S6,F15/S6,F16 (Report Request) transactions to obtain

initial report data and/or to verify reports as defined and

linked. Finally, the desired reports would be enabled

by the host with S2,F37/S2,F38 (Enable/Disable Event

Report) transactions.

R1-3.4.5 There are two methods for the equipment to

send event reports to the host. S6,F13 includes the

Variable Identifier (VID) with each Variable Data item

(V). S6,F11 is a shorter form, without the identifiers;

some users prefer this form to reduce message size.

R1-3.4.6 When any message is long enough to require

multiple blocks, it must be preceded by an inquire/grant

transaction.The DATAID parameter is used only to link

the inquire/grant transaction with a multiblock message.

This linkage is to alleviate problems in the case of

interleaved messages. A unique value for DATAID

must be used for each Inquire/Grant/Send/Ack-

nowledge conversation (similar to the use of

SYSBYTES in SECS-I). The DATAID parameter

should not be used for any other purpose.

R1-4 Process Programs

R1-4.1 Introduction

R1-4.1.1 Two forms of process programs are supported

by SECS-II: unformatted and formatted. The contents

of an unformatted process program conform to no set

standard. The format of the program is defined by the

vendor of the equipment and probably bears no

similarity to the format used by other vendors for their

SEMI E5-1104 © SEMI 1982, 2004 262

equipment. Because special programming would be

required at the host to understand the equipment’s

unique data format, the process program is most likely

generated at the machine and the host is only used as a

data repository, saving the foreign data for later

retransmission to the equipment. S7,F3 and S7,F6 are

the SECS-II messages used to move unformatted

process programs between host and equipment.

R1-4.1.2 Unformatted process programs were the

original accepted means for moving processing

instructions between host and equipment under SECS-

II. However, the inability of a host to generate process

programs for its subordinate machines was quickly

recognized as a severe problem. As a result, the

formatted process program and its associated

transactions were added. Five transactions are provided

under SECS-II for handling formatted process

programs: S7,F23-24, S7,F25-26 allow movement of

process programs between host and equipment; S7,F21-

22 originates at a machine and provides a host with the

information it needs to generate a process program for

that machine; S7,F27-28 allows the equipment to tell

the host whether or not the contents of the formatted

process program received from the host are valid; and

S7,F31-32 provides the host with the ability to ask the

equipment to check the validity of a process program

without actually downloading the program into the

machine for production use.

R1-4.2 Normal Sequence of Operations

R1-4.2.1 Formatted process programs may be

generated at a host or machine. The actions taken to

generate one in a machine are left to the equipment

manufacturer. If the process program is created at a

host, a sequence of operations is assumed.

R1-4.2.1.1 Once the host’s process program generator

has been invoked and has been told for which machine

a process program is to be created, the host editor must

obtain a copy of the process capabilities data for that

machine. The information may already be available on

the host or it may be obtained directly from the

machine. In either case, the information originates at

the equipment and is obtained using S7,F21-22. (See

Section R1-4.4 for additional information.)

R1-4.2.1.2 With the machine’s process capabilities in

its possession, the process program editor may proceed

with creating the desired process program. At the

conclusion of the editing session, the new machine

process program will either be saved at the host or sent

directly to the machine for storage and/or use.At this

point, the process program is known to satisfy a number

of constraints, but it is not necessarily completely

acceptable to the machine due to interrelationships of

the process program data which are too complex to be

described in the machine process capabilities data. The

host at any time may verify that a process program is

truly valid by sending the process program to the

machine and asking it to check the process program and

tell the host whether or not the process program is, in

fact, correct. If not correct, the equipment is expected

to provide information on what data in the process

program is unacceptable. This action is accomplished

through S7,F31-32. This transaction is equivalent to

S7,F23-24, with one important exception, the machine

is not to do anything with the process program received

under S7,F31 except acknowledge that it got the

message (S7,F32) and, as soon as it is able, respond

with S7,F27, which provides the host with information

on the validity of the process program. In this way, a

new version of a process program already held by a

machine may be checked for validity without affecting

the operation of the machine (i.e., a newer version of a

particular process program may be checked while an

older version is simultaneously being used by the

equipment for material processing).

R1-4.2.1.3

At some point, a host resident process

program will be required by the equipment for material

processing. Transfer of a program may be

accomplished in either of two ways. First, the host may

initiate transfer by transmitting S7,F23. In this case,

immediately upon reception of the message, the

equipment is required to respond with S7,F24, which

tells the host that the process program arrived and

whether or not the process program is accepted for

further processing by the equipment. The second

means is for the equipment to initiate the transfer by

asking for a process program using S7,F25. In this

case, the host will send the process program to the

equipment or tell the equipment it is unable to satisfy

the request. S7,F23 may also be used by a piece of

equipment to transfer a process program to its host for

archiving. In this case, the host will respond with

S7,F24 and an appropriate completion code. Likewise,

a host may request a process program transfer from its

machine using S7,F25. The machine will respond with

S7,F26, which will contain the process program or an

error indication.

R1-4.2.1.4 Following reception by the equipment of

the process program, it is the machine’s responsibility

to check the contents of the process program for

validity and respond to the host with a S7,F27 message

formatted with the appropriate information about the

just received process program. To complete the process

program exchange transaction, the host will

acknowledge the S7,F27 message with S7,F28. What is

done with the process program once accepted and

checked for validity is dependent on the state of the

process equipment.

SEMI E5-1104 © SEMI 1982, 2004 263

R1-4.3 Equipment Process Capabilities Data

R1-4.3.1 The underlying assumption of SECS-II

formatted process programs is that processing

instructions for equipment can be expressed as

sequences of commands with parameters. Commands

are integer codes which tell the machine what to do.

The parameters of each command are numeric (integer

or floating point) values, Boolean values, or text strings

which specify how to carry out the particular command.

This provides a very flexible structure for building

process programs but does not provide the specific

information (code values, types and number of

parameters, legal parameter values, etc.) required by a

host system to generate a process program for a

particular piece of equipment. Under SECS-II, this

information is provided to a host via the machine’s

Equipment Process Capabilities Data or PCD.

R1-4.3.2 A PCD provides three levels of information

global data pertaining to the entire process program;

definition of each possible command understood by the

machine; and definition of each command parameter.

Global process program definition data consist of

MDLN, SOFTREV, CMDMAX, BYTMAX, and the

list of command descriptors.

R1-4.3.3 MDLN and SOFTREV provide the same data

to the host as the equipment’s response to the S1,F1

host interrogative, “Are you there?” They are included

in the PCD to provide a means of distinguishing

between PCDs for different machines and revisions of

PCDs for the same piece of equipment. Also, when a

process program is generated, the MDLN/SOFTREV

values of the PCD are provided in the process program

to allow the machine an unambiguous method of

determining if the process program was generated from

a PCD it understands.

R1-4.3.4 BYTMAX and CMDMAX are two integer

values which allow the equipment to limit the size of

the process program which will be generated.

BYTMAX specifies the maximum number of bytes a

process program may occupy. CMDMAX specifies the

maximum number of commands which may appear in

the process program. Either value may be zero, which

indicates that no maximum limit is being imposed by

the equipment.

R1-4.3.5 The PCD command list identifies (in no

particular order) each of the unique operations its

associated machine is capable of performing. These

operations may correspond to processing operations of

the equipment (bake, spin), initialization of equipment

components (set beamline controls), definition of data

values referenced by later commands (define bond

coordinates or inspection points), or even “pseudo-

operations,” which allow conditional execution of the

process program (go to X; if temperature out of range,

then go to y; repeat ramping until speed 200; etc.).

R1-4.3.6 Each command in the PCDlist has a number

of data values associated with it which provide the host

with the command’s personality. These are CCODE,

CNAME, RQCMD, BLKDEF, BCDS, IBCDS,

NBCDS, ACDS, IACDS, NACDS, and the commands

parameter list.

R1-4.3.7 CCODE defines the unique numeric code

which the equipment recognizes as representing the

command being defined. CNAME is a text string

which hopefully describes the function of the

command. The string must be unique for each

command since humans generating process programs at

the host will use them, and the host process program

generator will translate the CNAME to the

corresponding CCODE.

R1-4.3.8 RQCMD. This Boolean value allows

equipment to specify whether or not a command must

appear at least once within their process program. If

true, the command must be used. If RQCMD is set

false, the command may or may not be used in the

process program at the discretion of the person creating

the process program.

R1-4.3.9 In addition to the information the PCD

provides on allowed data content within a process

program, it also can provide information to the host on

possible interdependencies between the commands.

Specifically, through the PCD the host can know such

things as: command code A must appear before

command code B; command code A must come after

command code D; command code A must immediately

precede command code X; command code A must not

come before command code E; command code A must

not come after command code F; and/or command code

A must immediately come after command code T.

Each of the PCD entries, BCDS (before codes), ACDS

(after codes), IBCDS (immediately before codes),

IACDS (immediately after codes), NBCDS (not before

codes), and NACDS (not after codes), is a SECS item

which may contain one or more command codes. Each

particular item defines the relation to be satisfied. The

elements of the item identify the command codes which

are to satisfy the relation with the command being

defined. A zero length item indicates that no

restrictions apply for that type of checking. For

example, if the values of the various fields take on the

values shown in Figure R1-1, the host process program

editor will assure that the TEST command (code 10)

will occur before commands with codes 5, 6, and 8; that

it will come after commands with codes 100 and 2; that

TEST will not appear after the command with code 20;

and that each occurrence of command code 3 will have