semi合集-English.pdf - 第1064页

SEMI E5-1104 © SEMI 1982, 2004 6 permission is granted, th e originator sends the data and the interpreter replies appropriately. This is the inquire/grant/send/ackno wledge conve rsation. Between the inquire and the sen…

SEMI E5-1104 © SEMI 1982, 2004 5

1 6 3 6 4 1 27

25 5

Ava ilable

for use r

definition

Re se rve d

for t his

st a nda rd

Figure 1

Stream and Function Allocation

7.3.2 The reserved codes assigned by this standard are

listed in Section 10. It is recognized that there will be

user needs beyond the specific definitions given in this

standard. In these situations, the streams and functions

reserved for user definition should be used subject to

the guidelines for minimum compliance outlined in

Section 8.

8 Transaction and Conversation Protocols

8.1 Intent — For an implementation to be in

compliance with SECS-II, it must meet the minimum

transaction requirements outlined in this section. The

conversation protocols serve to further define the use

and interaction between transactions.

8.2 Transaction Definition — A transaction forms the

basis for all information exchanges in SECS-II. A

transaction consists of either a primary message for

which no reply is requested, or a primary message

which requests a reply together with its corresponding

secondary message. Secondary messages cannot

request a reply.

8.3 Transaction Level Requirements — The following

are the requirements to comply with the SECS-II

protocol at the transaction level:

1. Respond to S1F1 with S1F2 as described in

Section 10.5.

2. For any received message that cannot be processed

by the equipment, send the appropriate error

message on Stream 9. As described in Section

10.13, S9F1, F3, F5, F7, or F11 are possible.

3. Format any other supported messages according to

Section 10.

4. Upon detection of a transaction timeout at the

equipment, send S9F9 to the host.

5. Upon receipt of function 0 as a reply to a primary

message, terminate the related transaction. No

error message should be sent to the host by the

equipment.

8.4 Conversation Protocols — A conversation is a

series of one or more related transactions used to

complete a specific task. A conversation should

include all transactions necessary to accomplish the

task and leave both the originator and interpreter free of

resource commitments at its conclusion.

8.4.1 Conversation Timeout — A conversation timeout

is used to indicate that a conversation has not

completed properly. A conversation timeout is

application-dependent, and the methods used for

detecting conversation timeouts are not covered as part

of this standard. A conversation timeout will terminate

further action on the conversation, and will allow for

the clearing of any committed resources. Upon

detection of a conversation timeout at the equipment,

S9F13 should be sent to the host.

8.4.2 Types of Conversations — There are seven types

of conversations which characterize all information

exchanges in SECS-II:

1. A primary message with no reply is the simplest

conversation. This message must be a single-block

SECS-II message. The originator must assume that

the interpreter responds to the message. This

conversation is used where the originator can do

nothing if the message is rejected.

2. If the interpreter has data that the originator wants,

the data are requested with a primary message and

the data returned to the originator as a reply

message. It is assumed that the originator

requesting the data is prepared to receive the

amount of data returned. This is the request/data

conversation.

3. If the originator wishes to send data in a single-

block SECS-II message to the interpreter, then the

originator sends the data and expects an

acknowledgment from the interpreter. This is the

send/acknowledge conversation.

4. If the originator has a multi-block SECS-II

message to send for a particular exchange, then the

originator must receive permission from the

interpreter prior to sending the data. The first

transaction requests permission to send, and the

interpreter either grants or denies permission. If

SEMI E5-1104 © SEMI 1982, 2004 6

permission is granted, the originator sends the data

and the interpreter replies appropriately. This is

the inquire/grant/send/acknowledge conversation.

Between the inquire and the send, the interpreter

may commit some resources in preparation for the

data. Consequently, a conversation timeout may be

set by the interpreter at a time dependent upon the

application, at which time the interpreter will free

its resources and send an S9,F13 error message to

the originator. Note that under the definition of

S9,F13 in this standard, only the equipment should

generate an error message to the host under these

conditions.

5. There is a conversation related to the transfer of

unformatted data sets between equipment and host.

This conversation is described in detail in Stream

13. (See Section 10.17)

6. There is a conversation related to the handling of

material between equipment. This conversation is

described in detail in Stream 4. (See Section 10.8)

7. The originator may request information from the

interpreter which requires some time to obtain

(e.g., operator input is required). The first

transaction requests the information and the

interpreter responds in one of three ways: 1) the

information is returned, 2) the interpreter indicates

that the information cannot or will not be obtained,

or 3) the interpreter indicates that the information

will be obtained and returned in a subsequent

transaction, as specified for this conversation. For

case number 3, the interpreter will initiate the

subsequent transaction when the information is

available.

8.4.2.1 Case 3 is the request/acknowledge/send/

acknowledge transaction.

8.4.2.2 The originator of the request/acknowledge/

send/acknowledge conversation may commit some

resources in anticipation of the send/acknowledge

transaction. Consequently, a conversation timeout may

be set by the originator at a time dependent on the

application. On timeout, the originator will free its

resources and restart the conversation with the

‘request’, or send an S9,F13 error message. Note that

under the definition of S9,F13 in this standard, only the

equipment should generate an error message to the host

under these conditions.

8.4.3 The key words, request, data, send, acknowledge,

inquire, and grant are used in the function names as an

aid to understanding the relationship between the

messages and the conversation. Single message trans-

actions do not use these words.

9 Data Structures

9.1 Intent — All information transmitted according to

this standard will be formatted using two data struc-

tures, items and lists. These data structures define the

logical divisions of the message, as distinct from the

physical divisions of the message transfer protocol.

They are intended to provide a self-describing internal

structure to messages passed between equipment and

host.

9.2 Item — An item is an information packet which

has a length and format defined by the first 2, 3, or 4

bytes of the item. These first bytes are called the item

header (IH). The item header consists of the format

byte and the length byte(s) as shown in Figure 2. Bits

one and two of the item header tell how many of the

following bytes refer to the length of the item. This

feature allows for long items without requiring the byte

overhead for shorter items. The item length refers to

the number of bytes following the item header, called

the item body (IB), which is the actual data of the item.

The item length refers only to the item body not

including the item header, so the actual number of bytes

in the message for one item is the item length plus 2, 3,

or 4 bytes for the item header. All bytes in the item

body are in the format specified in the format byte.

No. of

len

th b

tes

item format code

len

length

MSB

LSB

8 7 6 5 4 3 2 1 bit

MS b

LS b

{

Format

Length

tes

No. of Length bytes

0 = Illegal, data format error

1 = One binary length byte (max = 255)

2 = Two binary length bytes (max = 64k)

3 = Three binary length bytes (max = 7.99M)

Length refers to the number of bytes except in a list format where it

refers to the number of elements

(

items or lists

)

in the list.

Figure 2

Item and List Header

9.2.1 A zero-length in the format byte is illegal and

produces an error. A zero-length in the item length

bytes has a special meaning as defined in the detailed

message definitions.

9.2.2 Bits 3 through 8 of the format byte of the item

header define the format of the data which follows. Of

the 64 possible formats, 16 are defined as shown in

Table 1. Format code 0 is called a list and is defined in

Section 9.3. Format code 22 (octal) is called a localized

string and is defined in Section 9.4. The remaining 14

item formats define unspecified binary, code 10 (octal);

Boolean, code 11 (octal); ASCII character strings, code

20 (octal); JIS-8 character strings, code 21 (octal)

SEMI E5-1104 © SEMI 1982, 2004 7

signed integer, codes 30, 31, 32, 34 (octal); floating

point, codes 40, 44 (octal); and unsigned integer, codes

50, 51, 52, 54 (octal). These formats are used for

groups of data which have the same representation in

order to save repeated item headers. In signed integers,

negative values will be two’s complement values.

Floating point numbers will conform to the IEEE

standard 754. Boolean values will be byte quantities,

with zero being equivalent to false, and non-zero being

equivalent to true.

9.3 List — A list is an ordered set of elements, where

an element can be either an item (Section 9.2) or a list.

The list header (LH) has the same form as an item

header with format type 0. However, the length bytes

refer to the number of elements in the list rather than to

the number of bytes. The list structure allows grouping

items of related information which may have different

formats into a useful structure.

9.3.1 A zero-length in the format byte is illegal and

produces an error. A zero-length in the list length bytes

has a special meaning, which is defined in the detailed

message definitions.

Table 1 Item Format Codes

Format Code

(Bit 876543)

Meaning

Binary Octal Data after the heading has the following

form

000000 00 LIST (length in elements)

001000 10 Binary

001001 11 Boolean

010000 20 ASCII

010001 21 JIS-8

010010 22 2-byte character

2, 4

011000 30 8-byte integer (signed)

011001 31 1-byte integer (signed)

011010 32 2-byte integer (signed)

011100 34 4-byte integer (signed)

100000 40 8-byte floating point

100100 44 4-byte floating point

101000 50 8-byte integer (unsigned)

101001 51 1-byte integer (unsigned)

101010 52 2-byte integer (unsigned)

101100 54 4-byte integer (unsigned)

Non-printing characters are equipment-specific.

Most significant byte sent first.

IEEE 754. The byte containing the sign bit is sent first.

The code for Multi-byte character must be specified in the data in

the first 2 bytes of the TEXT item.

NOTE: Changes in integer format codes may conflict with earlier

implementations.

9.4 Localized Character String Items — A localized

character string is an item which is used for repre-

senting a string of multi-byte characters. Because there

are many different encoding schemes and the informa-

tion could be in any one of a number of languages,

these characteristics must also be included in the item.

Thus for localized character strings which use item

format code 22 (octal), there is an additional localized

string header (LSH) .

9.4.1 This localized string header follows the item

header and precedes the string. The localized string

header is part of the item data, thus the length of the

header (2 bytes) is included in the length in the item

header. The length of the localized string itself is the

number of bytes that it occupies, regardless of the

number of characters that represents the string. The

localized string header followed by the string together

comprise the localized string item. For example, a 2

byte localized string (which may represent a single

character), because of the 2 byte length of the localized

string header, will have a 4 byte length in the item

header.

9.4.2 The LSH is a 16 bit number which specifies the

encoding method used for the string. Defined values

for the encoding are as follows:

Table 2

Encoding

Code

(Decimal)

Encoding Scheme Notes

0 none reserved

1 ISO 10646 UCS-2 Unicode 2.0

2 UTF-8 Transformation of

ISO 10646 UCS-2

3 ISO 646-1991 ASCII, 7-bit

4 ISO 8859-1 ISO Latin-1,

Western Europe

5 ISO 8859-11 (proposed) Thai

6 TIS 620 Thai (will be

supported by ISO

8859-11)

7 IS 13194 (1991) ISCII

8 Shift JIS

9 Japanese EUC-JP

10 Korean EUC-KR

11 Simplified Chinese GB

12 Simplified Chinese EUC-

13 Traditional Chinese Big5

14 Traditional Chinese EUC-