semi合集-English.pdf - 第1323页

SEMI E5-1104 © SEMI 1982, 2004 265 vector of val ues. When default values are to be included in a pr ocess program , the entry of the default vector in the sam e ordinal position as the param eter entry requiring the def…

SEMI E5-1104 © SEMI 1982, 2004 264

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

SEMI E5-1104 © SEMI 1982, 2004 265

vector of values. When default values are to be

included in a process program, the entry of the default

vector in the same ordinal position as the parameter

entry requiring the default is used. If the parameter is

allowed to have N entries but only M defaults are

provided, the last N-M parameter entries will have no

defaults.

R1-4.3.16 If the numeric or Boolean vector parameter

is required to be entered, PDFLT will contain no default

data values, but dummy values must be provided so that

the length of the item specifies the minimum number of

entries the equipment expects to receive for the

parameter. If this minimum number of entries exceeds

the maximum number of entries allowed for the

parameter (PMAX), then only PMAX entries will be

provided in the process program.

R1-4.3.17 Numeric parameters may be any of the

SECS recognized floating point or integer data types.

PDFLT identifies the particular type. ULIM and LLIM

will be of the same data type and specify the range of

legal values for the parameter (LLIM  x  ULIM).

UNITS is a character string formed according to E5,

Section 12, which specifies the expected units of

measure of the numeric value. RESC specifies whether

the resolution of the data item to be entered is to be in

terms of a fundamental increment or significant digits.

In the case of the former, RESV will be of the same

type as the expected parameter and will specify the base

increment. In the case of the latter, RESV will be an

integer and will specify the number of significant digits

to accept for the parameter.

R1-4.3.18 In addition to the standard fields described

above, string parameter descriptors have one unique

field. This field provides a set of template strings. A

text parameter will be assumed valid by a host process

program generator if it matches one of the template

strings. A match occurs if the input string is at least as

long as the corresponding template and each position of

the template and data strings match. A null string

specified as a template will result in a match with any

data string. A null data string will match only a null

template string. A null template list indicates all strings

are acceptable to the equipment.

R1-4.4 Equipment Capabilities Descriptor Availability

R1-4.4.1 Ideally, each piece of equipment should be

able to respond to a host PCD request at any time.

However, inasmuch as an equipment’s PCD may be

rather large and the equipment may have limited

storage capacity, constant availability may be

impossible. In these cases, some compromise will have

to be made such as making it available only at machine

initialization or when idle. In extremely severe cases,

an equipment manufacturer may have to provide the

PCD data with the rest of the machine documentation,

requiring his customer to manually enter the data into

his host system.

R1-4.4.2 In light of this difficulty, host systems should

maintain copies of PCD’s for each piece of equipment

under its control and not expect to be able to obtain the

PCD from the machine whenever it is required. Doing

so, in fact, will permit more flexible process program

development in the host, allowing creation of process

programs even when equipment is not online and

encourage the use of formatted process programs by

equipment manufacturers.

R1-5 Suggested Baseline SECS Equipment

Implementation

R1-5.1 Purpose and Scope

R1-5.1.1 This document provides a recommendation

prepared by the Rigid Disk Subcommittee for

generating a baseline implementation of the SECS

(SEMI Equipment Communication Standard) standards

on production process and test equipment. This

document is not a tutorial to aid in understanding SECS

but rather serves as an introduction to the requirements

of SECS, and a brief guide to the selection of SECS

messages for equipment. Actual system requirements

of many implementations are beyond the scope of this

document. The full standards, SEMI Equipment

Communications Standard I (SECS-I), SEMI E4 and

SEMI Equipment Communications Standard II (SECS-

II), SEMI E5 should be consulted by all users.

R1-5.2 Introduction

R1-5.2.1 The SECS standards are an existing and

developed set of communication standards currently

used by the semiconductor and other industries to

support automated production. The standards provide a

means for communicating information and control

between production equipment and a “host” computer.

This transfer of information and control can be used to

provide production tracking and location of WIP

(Work-In-Process), scheduling of WIP and control of

material transfer at the equipment. The process

measurements and records can be used to provide

process engineers with a database for statistical process

control. SECS messages are appropriate to a wide

variety of applications, including measurement,

processing, and material transport equipment.

R1-5.3 SECS-I Standard

R1-5.3.1 SECS-I defines the lower protocol layers of a

point-to-point interface between equipment and a host

computer system. The standard requires a simple, well

understood physical interface, RS-232. The SECS-I

protocol allows the equipment control over the

SEMI E5-1104 © SEMI 1982, 2004 266

protocol: the equipment is the master of the link and

can initiate the transfer of a message to the host.

Likewise, the equipment can regulate the receipt of a

message by its response to a handshake to receive the

message. Thus, the interface takes place at the

convenience of the equipment, and equipment with very

limited computer resources can still support the

standard.

R1-5.4 SECS-II Standard

R1-5.4.1 SECS-II defines the higher layer in the

protocol, including message content, structure, and data

types and their formats. SECS-II defines messages in

sets with related functions called Streams. The actual

content of the messages are specific to an application,

but it is possible for a properly designed host software

system to unpack a message and present the data in a

meaningful way with no prior definition as to the

content. Equipment need only implement those

messages appropriate to meet its system requirements;

thus, very simple equipment will require

implementation of few messages.

R1-5.4.2 Application Note A2 contains some

suggestions for message utilization, including some

information on minimum message sets. It is the intent

of this report to expand in a somewhat different

direction, to identify those messages which typically

constitute a sufficient set given a selected equipment

function.

R1-5.4.3 To select a message set, the requirements for

the equipment must be identified. This requirement, in

turn, determines a message set. Identified below are a

number of types of equipment requirements and a

baseline set of messages supporting those requirements.

The message sets identified are baseline

recommendations. Actual equipment implementations

may need more messages than those specified here to

satisfy all system requirements. The published

standards should be consulted for all applications.

Issues such as handling of multi-block messages,

optional replies, and others are described in detail in the

SEMI specifications and are not a topic of this baseline

recommendation.

R1-5.4.4 The implementation for a specific equipment

type begins by specifying which tasks that equipment is

required to perform from the following list, and then

studying the expanded descriptions for those tasks

chosen in the SECS-II implementation section.

Typical Tasks for Measurement and Process:

1. Measurement or Action Reports

2. Equipment Alarm Reports

3. Remote Request for Equipment Condition or State

4. Operator Interface to the Host

5. Remote Access to Process Programs

6. Remote Commands

Typical Tasks for Material Control and Transport:

1. Material Status Information

2. Material Transport Control

Additional Tasks for Special Situations:

1. File Transfer

R1-5.5 Baseline SECS Implementation Recommenda-

tions: SECS-I

R1-5.5.1 The baseline SECS-I requirement for

equipment is to fully implement the SECS-I protocol as

defined in SEMI E4. This requirement applies to all

SECS compatible equipment independent of the

equipment’s function. The flow chart (Figure 2 of

SEMI E4) illustrates the block transfer protocol of

SECS-I. The body of the SECS-I standard describes

protocol timeouts and other requirements that are

essential components of the specification.

R1-5.6 Baseline SECS Implementation Recommenda-

tions: SECS-II

R1-5.6.1 The SECS-II implementation begins with a

choice or selection of messages for the equipment. In

order for equipment to meet the baseline requirements

for a viable SECS-II interface, the equipment must be

capable of generating a certain set of messages and

recognizing another set. The messages required for

either set will depend on tasks of equipment and on

system requirements for production and process control

by the host. Equipment must accept S1,F1 and send

S1,F2. Note that implementation in the reverse

direction is optional. In order to ensure a viable data

communication link, certain messages are required:

Messages for All Equipment — Required by SECS-II

a. Messages Generated by the Equipment

S1,F2:On Line Data

S9,F1: Unrecognized Device ID

S9,F3: Unrecognized Stream Type

S9,F5: Unrecognized Function Type

S9,F7: Illegal Data

b. Messages Recognized by the Equipment

S1,F1: Are You There Request

R1-5.6.2 In addition to those messages which are

required, the following are strongly recommended.

These messages are used for diagnostic purposes: