semi合集-English.pdf - 第2327页

SEMI E82-0705 © SEMI 1999, 2005 23 10.2 Alarm List Table 10.2.1 The alarm list table contains exam ples of alarms that pertain to various c o nfiguratio n aspects of equipment. These examples are intended to illustrate t…

100%1 / 7923
SEMI E82-0705 © SEMI 1999, 2005 22
Variable Name Type Description Class Format Comment
UnitStatus
Clearable
CV When a UnitStatusOccured
event is generated this flag
indicates if the equipment is
going to generate a
UnitStatusCleared event
when the status is corrected.
DVVAL A[1] ‘Y’ – A UnitStatusCleared
event will be generated.
‘N’ – A UnitStatusCleared
event will be NOT be
generated.
UnitStatusID CV The identification of the
status.
DVVAL A[1–64] This is generally a vendor
determined id which
identifies the status. For
example it could be
“LostCommunication” or
“SensorMalfunction” or
“1234”.
UnitStatusText CV Vendor specific information
relating to the UnitStatusID
DVVAL A[0-80] Information that may be
helpful to an operator. This
could include more precise
location information or other
related information.
VehicleID CV Unique identification of a
vehicle associated with an
event.
DVVAL A[1–32]
VehicleID
i
CV Unique identification of the
ith vehicle.
SV A[1–32]
VehicleInfo CV Information associated with a
particular vehicle.
DVVAL L,2
1. <VehicleID>
2. <VehicleState>
VehicleInfo
i
CV Information associated with
the ith vehicle.
SV L,2
1. <VehicleID
i
>
2. <VehicleState
i
>
VehicleLocation CV Location of the vehicle. DVVAL A[0–64] The vehicle’s port location.
The data is only valid if the
vehicle is Parked, Acquiring,
or Depositing.
VehicleLocation
i
CV Location of the vehicle. SV A[0–64] The vehicle’s port location.
The data is only valid of the
vehicle is Parked, Acquiring,
or Depositiong.
VehicleState CV The state of the vehicle. DVVAL U2 1 = Removed
2 = Not Assigned
3 = Enroute
4 = Parked
5 = Acquiring
6 = Depositing
VehicleState
i
CV The state of the ith vehicle. SV U2 See VehicleState above.
#1
Current location (port or vehicle id) of the carrier is reported in ‘CarrierLoc’. This may be used as a source port in a following transfer
command.
10 Alarm List
10.1 Since each model of IBSEM equipment differs in configuration, it is not practical to provide an exhaustive list
of all possible alarms. Instead, the IBSEM is requiring the two tables provided as described in SEMI E30
(Document Section). Alarm List Table which is intended to provide for equipment configuration specific alarms
and Alarm ID, Alarm Set/Cleared Event Table. Any alarm that is displayed locally at the equipment, if enabled, is
required to be sent to the host. To be compliant, Tables 9 and 10 must be completed by the supplier, documenting
all alarms.
SEMI E82-0705 © SEMI 1999, 2005 23
10.2 Alarm List Table
10.2.1 The alarm list table contains examples of alarms that pertain to various configuration aspects of equipment.
These examples are intended to illustrate that alarms pertain to situations in which there exists a potential for
exceeding physical safety limits associated with people, equipment, and material being transported as per the SEMI
E30 definition of an alarm. See SEMI E30 for further reference. The supplier is responsible for supplying
documentation associated with these alarm definitions. Each alarm will have an associated alarm text (ALTX) and
alarm identifier (ALID). Table 9 contains example alarm list information that is intended to be augmented when the
IBSEM equipment supplier documents its interface. Examples highlighted by (*) are required by IBSEM.
Table 9 Alarm List Table
Danger Affected
Equipment Cfg. Alarm Text ALID
Potential Imminant Operator Equipment Material
vehicle obstruction*
(exceeded timeout)
X X
transport system
equipment failure*
X X X
Carrier Handoff
Parallel I/O failure*
X X X X
OHT, OHS, RGT,
AGT, and DWC
database error* X X
10.3 Alarm ID, Alarm Set/Cleared Event Table
10.3.1 The Alarm ID, Alarm Set/Cleared Event table documents the association of each ALID to a set and cleared
event as required by SEMI E30. See SEMI E30 for further reference. The supplier is responsible for supplying
documentation associated with these alarm definitions. Each alarm will have associated alarm set and cleared
collection event identifiers (CEID
set
and CEID
clear
). Table 10 contains example alarm event information that is
intended to be replaced when the IBSEM equipment supplier documents its interface.
Table 10 Alarm ID, Alarm Set/Cleared Event Table
Alarm ID (ALID) Alarm SET Event (CEID
set
) Alarm CLEARED Event (CEID
cleared
)
11 Remote Commands
11.1 The purpose of this section is to identify remote commands, command parameters, and valid commands versus
states pertinent to the SEM. All remote commands identified in this section follow the format of the S2,F41 Host
Command Send SECS-II message except for the TRANSFER and STAGE commands, which follow the S2,F49
Enhanced Remote Command Send SECS-II message.
11.2 Requirements
The equipment shall support the SEMI E30 (according to the GEM capabilities required per §13) required
remote commands.
All the remote commands defined by IBSEM are required to be implemented as specified.
The alphanumeric strings defined by IBSEM for RCMD and CPNAME are required.
A completed table must be generated where an “X” is placed in the table for each state that a given command is
valid.
SEMI E82-0705 © SEMI 1999, 2005 24
If additional remote commands are supported then a “remote commands versus valid states” matrix must be
generated for these additional commands.
For additional commands, a table must be generated similar to the remote command descriptions summary.
11.3 Remote Commands Description
11.3.1.1 ABORT — This command terminates the activity of a specific TRANSFER command based on
CommandID while the command is in the ACTIVE state. This command may not be accepted due to mechanical
issues if the vehicle is in a specific condition (e.g., depositing a carrier). The exact conditions surrounding when the
ABORT command is not accepted by the TSC must be documented by the IBSEM equipment supplier.
11.3.1.2 CANCEL — This command terminates the activity of a specific TRANSFER command based on
CommandID while the command is in either the QUEUED or WAITING state. This command must always be
accepted by the TSC when in the QUEUED or WAITING state.
11.3.1.3 PAUSE — This command puts the TSC in the PAUSING state.
11.3.1.4 RESUME — This command puts the TSC in the AUTO state.
11.3.1.5 TRANSFER — This is a SECS-II Enhanced Remote Command instead of a SECS-II Host Command Send
(S2,F49 instead of S2,F41). See the examples in Related Information 1 for details.
11.3.1.5.1 This command is used to perform the entire transfer command for the carrier(s) to be transferred between
transfer ports. The execution of this command will include allocation of a vehicle, acquiring the carrier(s), moving
the carrier(s) to the destination port(s), depositing the carrier(s), and returning the vehicle for other use. The number
of carriers in the TRANSFER command is less than or equal to the number of carriers in the transfer unit (see ¶5.2
for definition of the transfer unit). It is recommended that the Carrier already be at the SOURCEPORT upon the
issue of the TRANSFER command, otherwise, it is possible that the TRANSFER command can fail on “empty
acquire” when no carrier is present on the SOURCEPORT when the acquire is started.
11.3.1.5.2 This command shall not be rejected or denied for the sole reason that a STAGEID in the STATEIDLIST
parameter does not reference the STAGEID of any current STAGE command. The TRANSFER command shall be
processed as if the invalid STAGEID was not present in the message.
11.3.1.6 INFOUPDATE — This is used to associate information with a carrier while in the TSC database. This
command is an optional feature and is not required for compliance. If this command is not supported, then a
HCACK of ‘1’ (Command does not exist) shall be returned. If the carrier does not exist in the TSC database, then a
HCACK of ‘3’ (At least one parameter is invalid) shall be returned.
11.3.1.7 STAGE — This is used to inform the TSC that a transport will be requested in the future. This command
allows, but does not require, the TSC to perform Transfer optimizations. This command is an optional feature and is
not required for compliance. If this command is not supported, then a HCACK of ‘1’ (Command does not exist)
shall be returned. It is also permissible for the command to be accepted and no action taken. The Host is not
required to send this command prior to a TRANSFER. Multiple valid STAGE commands for the same
SOURCEPORT can exist at the same time. A STAGE command becomes invalid once the subsequent TRANSFER
command is received, once the WAITTIMEOUT has expired, or once it has been deleted with STAGEDELETE.
The use of this command may cause premature blocking of sections of the transport system based upon the values of
the timers along with the TSC software and hardware implementations.
11.3.1.8 STAGEDELETE — This command is used to delete STAGE commands. If a STAGEID is specified, then
that STAGE command shall be deleted. If the STAGEID is not specified, (STAGEID cpname parameter is not
included in the message), then all STAGE commands shall be deleted. It can be used in anomaly situations when a
TRANSFER command will not be sent, or prior to sending an updated STAGE command, or during recover
scenarios.