GEM capabilities

SEMI E30 defines the capabilities that GEM equipment offers. This page explains each one, the messages it uses and how you handle it with PDComm. The linked tutorials let you try each capability hands-on.

At a glance

Capability	Main messages	PDComm	Tutorial
Status and data variables	S1F3, S1F11, S1F21, S1F23	Built-in API	Data collection
Event reports	S2F33, S2F35, S2F37, S6F11, S6F15–S6F22	Built-in API	Reports and events
Alarms	S5F1–S5F8	Built-in API	Alarms
Remote commands	S2F41, S2F49	Built-in API	Remote commands
Equipment constants	S2F13, S2F15, S2F29	Built-in API	Data collection
Process programs	S7F1–S7F6, S7F17–S7F32	Built-in API	Process programs
Spooling	S2F43, S6F23	Built-in API	Spooling
Trace data collection	S2F23, S6F1	General functions
Clock	S2F17, S2F31	General functions
Terminal services	S10	General functions

Variables and identifiers

GEM equipment publishes its values as variables, and the host refers to them by numeric ID:

Identifier	Name	Meaning
SVID	Status variable ID	A current value you can read at any time, such as the equipment state or the number of wafers processed.
DVID	Data variable ID	A value that only means something when a particular event happens, such as the ID of the lot that just finished.
ECID	Equipment constant ID	A setting the host can read and change.
CEID	Collection event ID	Something that happens on the equipment, such as process start or process end.
RPTID	Report ID	A group of variables sent along with an event.
VID	Variable ID	A variable inside a report; covers SVIDs, DVIDs and ECIDs.

The host reads status variable values with S1F3 and their names and units with S1F11. S1F21 and S1F23 return the namelists of data variables and collection events.

PDComm equipment registers status variables with RegisterStatus and data variables with ConfigureDataVariables. You register them before you start the endpoint. Values can change while the endpoint runs, but each keeps the format it was registered with. If a request names an unknown ID, an empty list takes its place in the reply; an empty list on its own doesn’t prove that the variable is unknown.

Event reports

Event reports are the heart of GEM data collection. The host tells the equipment in advance: “when this event happens, send me these values.”

Host                                             Equipment
  |  S2F33 Define Report   RPTID 100 = [VID 1, 2]  ->  |
  |  <- S2F34 DRACK 0                                  |
  |  S2F35 Link Event      CEID 10 -> [RPTID 100]  ->  |
  |  <- S2F36 LRACK 0                                  |
  |  S2F37 Enable Event    CEID 10                 ->  |
  |  <- S2F38 ERACK 0                                  |
  |                                                    |   event 10 happens
  |  <- S6F11 Event Report DATAID, CEID 10,            |
  |          RPTID 100 = [value 1, value 2]            |
  |  S6F12 ACKC6 0                                 ->  |

1. Define reports (S2F33): give a report ID and the variable IDs it contains.
2. Link events (S2F35): attach report IDs to a collection event ID.
3. Enable events (S2F37): switch on the events that should send reports.
4. Report events (S6F11): when the event happens, the equipment sends the current values of the linked reports. The host acknowledges with S6F12.

The enable state of an event and its report links are independent. If an event is disabled, no S6F11 arrives when it happens. If it is enabled but has no linked reports, the equipment sends an S6F11 with an empty report list. S2F37 is rejected with ERACK 1 only when it names a CEID the equipment doesn’t have, and redefining or relinking reports leaves the enable state as it is. The host can also query report values directly with S6F15 (by event), S6F19 (by report) and S6F21 (annotated report).

In PDComm, the host uses DefineReports, LinkReports and EnableEvents. The equipment sends S6F11 with PublishEvent, or with PublishEventWithData when it adds data variable values. If the equipment must run a fixed report setup instead of accepting remote configuration, install it before start with ConfigureFixedCatalog. Each VID in a report binds to a status variable, a data variable or an equipment constant.

Alarms

Alarms tell the host about abnormal equipment conditions (SEMI E30, alarm management):

Item	Meaning
ALID	Alarm ID
ALCD	Alarm code. The top bit says set or cleared; the other seven bits give the category.
ALTX	Alarm text

Message	Purpose
S5F1/F2	The equipment reports that an alarm was set or cleared.
S5F3/F4	The host enables or disables alarm reports.
S5F5/F6	The host requests the alarm list.
S5F7/F8	The host requests the list of enabled alarms.

PDComm equipment installs its alarm definitions with ConfigureAlarms. ObserveAlarm only changes an alarm’s active state; it sends nothing. To tell the host, send S5F1 with PublishAlarm, choosing per call whether to wait for a reply (the W-bit). The host uses EnableAlarm and RequestAlarmList.

Remote commands

Remote commands let the host tell the equipment to do something, such as START, STOP or PP-SELECT.

• S2F41 Host Command Send carries a command name (RCMD) and a list of parameter name and value pairs (CPNAME/CPVAL).
• S2F49 Enhanced Remote Command adds a target object (OBJSPEC) and parameters that can be nested or repeated.
• The equipment replies with HCACK and per-parameter errors (CPACK).

HCACK	Meaning
0	Accepted; the command was performed.
1	The command doesn’t exist.
2	Can’t perform now.
3	At least one parameter is invalid.
4	Accepted; completion is reported later by an event.
5	Rejected; already in the desired condition.
6	No such object.

HCACK 0 or 4 only means the command was accepted, not that the equipment finished the work. Equipment usually reports completion with a separate collection event.

PDComm equipment installs its command catalog with ConfigureCommands. A definition can specify each parameter’s format, count, range and whether it’s required, whether the command needs ON-LINE REMOTE, and a completion event. PDComm validates each request against the catalog, and your application decides the final reply with RespondCommand. The host uses RemoteCommand and EnhancedRemoteCommand.

Equipment constants

Equipment constants are equipment settings that the host may change, such as a retry interval or a process limit.

Message	Purpose
S2F13/F14	Read constant values.
S2F15/F16	Change constant values. An EAC of 0 in the reply means accepted.
S2F29/F30	Read each constant’s name, units, minimum, maximum and default.

PDComm equipment installs its constant store with ConfigureConstants. Your application answers each change request (S2F15) with RespondConstants: apply (0), can’t perform (2) or out of range (3). Even after an accepted change, read the value back to confirm it took effect.

Process programs

A process program is the recipe that tells the equipment how to process a product. Programs are identified by a PPID, and the content is the PPBODY.

Unformatted programs travel as bytes or text that only the equipment interprets:

Message	Purpose
S7F1/F2	Ask whether the peer can accept a large program before sending it (load inquire and grant).
S7F3/F4	Send a program.
S7F5/F6	Request a program.
S7F17/F18	Delete programs.
S7F19/F20	Request the equipment’s program directory.

Formatted programs travel as structured commands and parameters, so both sides can validate them. S7F21 through S7F32 cover querying the equipment’s process capabilities, sending and requesting formatted programs, verification reports, verification negotiation and verification requests.

PDComm supports both kinds. Either the host or the equipment can send S7F1 through S7F6; the host sends delete and directory requests. Formatted programs go through the GemEndpoint.FormattedPrograms service, which adds application-side tools: a local program store, program selection, dry runs and execution step tracking. Your application still implements what the equipment physically does.

Spooling

Spooling lets the equipment keep the messages it couldn’t send while communication was down and send them later:

1. The host chooses which streams and functions to spool with S2F43.
2. While communication is down, the equipment stores those messages in the spool.
3. Once communication is back, the host asks with S6F23 to transmit (0) or purge (1) the spooled data.
4. The equipment sends the stored messages in order.

PDComm equipment sets up its spool with ConfigureSpooling; give it a file path to keep the spool on disk. Messages enter the spool through CaptureSpool, CaptureSpoolEvent and CaptureSpoolAlarm, and leave with SendNextSpool. The host uses RequestSpoolConfiguration and RequestSpooledData. PDComm also provides a request that reads the current spool selection (S2F59/S2F60). Accepting a send, the peer receiving it and removing it from storage are separate steps, so check each result on its own.

Capabilities you handle with the general functions

Your application implements these GEM capabilities by exchanging their SECS-II messages through the HSMS endpoint’s general functions (pdcomm_tcp_request and pdcomm_tcp_reply):

• Trace data collection: periodic sampling set up with S2F23, with values sent in S6F1.
• Clock: reading the time with S2F17/S2F18 and setting it with S2F31/S2F32.
• Terminal services: showing operator messages with S10.

Both functions return PDCOMM_LIMIT_EXCEEDED when a body exceeds item_limits or doesn’t fit in one frame (max_frame_bytes). SECS-II messages explains the message structure.