semi合集-English.pdf - 第1321页

SEMI E5-1104 © SEMI 1982, 2004 263 R1-4.3 Equipment Process Capa bilities Data R1-4.3.1 The underl ying assum ption of SECS-II formatted pr ocess programs is that processi ng instructions for e quipment can be expressed …

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

a TEST command immediately before it, subject to the

block checking limitations described elsewhere.

CNAME = TEST

CCODE = 10

BCDS = 5,6,8

IBCDS = 3

BCDS = none

ACDS = 100.2

IACDS = none

ACDS = 20

Figure R1-1

R1-4.3.10 Associated with before/after checking is the

concept of a block which allows setting of limits on

before/after checking. A block consists of a start block

command, a block terminator command and possibly

body commands, commands which are included

between the start and terminator commands. There are

no specific command codes for start, or terminator

commands in SECS-II formatted process programs.

Instead, being a start block, terminator block, or body

command is merely an attribute of each command

defined in the PCD. The field BLKDEF defines this

attribute for each command. A positive one indicates

the command starts a new block. Zero indicates that

the command is a body command and neither starts nor

terminates a block. A value of negative one indicates

that the command is a terminator command.

R1-4.3.11 Before/after checking for a particular

command is performed only with other commands

within the same block. To be within the same block, a

command must have the same nesting level as the

command of interest or the command must be a

contained block.

R1-4.3.11.1 The example data in Figure R1-2 shows

six grouping of commands for before/after checking:

(A,B',N), (B,C,D',G',M), (D,E,F), (G,H',L), (H,I',K),

(I,J). A letter followed by an apostrophe (') indicates a

block which has been collapsed to a command and has

the before/after attributes of its start block command.

Note that body and terminator commands occur in only

one grouping, while block start commands occur in

two. Also, note that the outermost block is assumed to

begin with the first command of the process program

and to end with the last command.

Figure R1-2

R1-4.3.12 Each command’s parameter list defines the

parameters required by the equipment to carry out each

particular command. The order in which each

parameter descriptor appears in the PCD parameter list

also defines the order in which parameters will appear

in a process program command parameter list. Each

parameter is one of three possible types: numeric, text,

or Boolean.

R1-4.3.13 Regardless of parameter type, the first four

elements of any parameter descriptor list are the same.

The first field, PNAME, specifies the text string which

names the parameter. This data will be displayed by a

host when prompting a human for the parameter data.

The second field, RQPAR, specifies if the value must

be specified at the time the process program is

generated (true) or if specifying the data is optional

(false). The third field, PDFLT, identifies the type of

data to be accepted for this parameter as well as

providing default values to include in the process

program if the RQPAR is false and no data is input for

the parameter when the process program is generated.

PDFLT will have zero length if no default value is

provided.

R1-4.3.14 The final field, PMAX, specifies the

maximum length of the parameter data placed in a

process program. For numeric and Boolean data, it

specifies the maximum number of data entries in the

SECS-II item. For a string parameter, it specifies the

maximum number of characters acceptable to the

machine. In either case, negative values are invalid and

a value of zero indicates there is no length restriction.

R1-4.3.15 For numeric and Boolean parameters which

are multi-valued items, usage of PDFLT becomes a bit

more complex. In these cases, PDFLT may also be a