Ignition 8.1
Ignition 7.9
Ignition 7.8
Sepasoft - MES Modules
Cirrus Link - MQTT Modules
Inductive University
Ignition Demo Project
Knowledge Base Articles
Forum
IA Support
SDK Documentation
SDK Examples
The SECS/GEM (SEMI Equipment Communications Standard/Generic Equipment Model) Module enables Ignition projects and third-party applications to communicate with semiconductor fab equipment. The module is an implementation of the GEM standard (SEMI E30-0307), the SECS-II standard (SEMI E5-0712) and the HSMS standard (SEMI E37-0308).
The module is implemented as a host that can talk to one or more tools via equipment connections configured within the Gateway. While it has some built-in simulation functionality to aid with initial setup, the module serves as a host only, and cannot respond as if were equipment.
Communication with equipment is in the form of messages defined by the SECS-II standard and referred to as SECS messages or just messages. By use of a simple definition file, any SECS message (including custom ones) can be supported.
Once the module is installed, a new header is available under the Config section of the Gateway Webpage that allows you to configure connections to the equipment, or setup simulators that are used for testing.
| On_this_page |
|---|
The equipment connections are what allow Ignition to communicate with the specialized semiconductor fab equipment. Equipment connections are setup within the Configure section of the Gateway Webpage. Connections can be made over Ethernet using TCP/IP (HSMS protocol) or over a direct serial connection (SECS-I protocol) using a RS-232 cable. Note, that the direct serial connection requires that the equipment be connected directly to the Ignition Gateway server, and that the Serial Support Gateway Module be installed. The equipment connections also require the use of a database, which will store sent and received messages for audit purposes, and to hold some configuration data. Each equipment connection connects to one tool and one database and transfers SECS messages between the Gateway to the tool. Any number of equipment connections can be configured in the Gateway as long as your license allows it, and different equipment connections can be configured to use the same database connection or different database connections.
The SDL file is where SECS messages are defined. Any SECS message defined in this file can be sent and received. All SECS messages that are sent and received are validated against this file. If a message is not defined or doesn't match a definition then it is not sent, and it is instead inserted into the Errors table as a validation error along with information about why it didn't validate.
Each Equipment Connection has one SDL file and a default SDL file will be used if an alternate is not specified. The SDL file definitions are based on the GEM and SECS standards.
The SECS/GEM Module includes the capability to create and configure equipment simulators. The simulators are not a full implementation of the GEM standard. Equipment Connections can connect to simulators and they can exchange various messages. A range of SECS messages are supported by the simulators. This capability exists for getting started with the SECS/GEM Module and for testing applications.
Once a connection has been properly configured to a tool, messages can be sent between Ignition and the equipment. These messages are often complex, which is why SECS messages are often in the form of a JSON string, which can contain any number of lists and name/value pairs. The messages are typically sent and received using specialized scripting functions within Ignition, such as system.secsgem.sendRequest and system.secsgem.getResponse, that the SECS/GEM module adds. To send a message, a user calls the system.secsgem.sendMessage function in a Python script within an Ignition Gateway or client, and passes the SECS message as JSON text to the function. A transaction id is returned, which can then be passed to the system.secsgem.getResponse function. This function returns the response from the tool as JSON text. However, some SECS messages can be handled differently, such as those that are sent repeatedly from the equipment like status variables. Those messages can be configured to fire Message Handler scripts in the Gateway or Client when the message is received, which can handle the constant flow of messages in a consistent manner. Alternately, the messages can be configured to create Tags with their values, updating the Tags anytime a new message comes in.
The SECS/GEM Module uses some unique terms that are not used in the rest of Ignition:
| Term | Description |
|---|---|
| SECS/GEM | The SECS/GEM Module is named after two standards the SECS-II standard (SEMI E5-0712) and the GEM standard (SEMI E30-0307). The SECS-II standard defines messages that can be exchanged between a host and an equipment. SECS stands for Semi Equipment Communications Standard. The GEM standard defines ways for equipment to implement functionality using SECS messages. GEM is short for Generic Model for Communications and Control of Manufacturing Equipment. |
| HSMS Protocol | A TCP/IP based message transfer protocol for sending SECS messages. The SECS/GEM Module uses HSMS or SECS-I for sending messages. |
| Equipment | A semiconductor device that sends and receives SECS messages. This is also called a tool. |
| Equipment Connection | An Equipment Connection enables a database interface to an equipment. An Equipment Connection has a connection to an equipment and a connection to a database and transfers SECS messages between them. Ignition projects or third-party applications can insert SECS messages into a database table to send them to an equipment, and query database tables to retrieve SECS messages from an equipment. |
| Stream | A category of SECS messages. |
| Function | A specific SECS message in a stream. |
| Request Message | Also primary message. A SECS message having an odd numbered function that originates a communication and may require a response message. |
| Response Message | Also reply message. Also secondary message. A SECS message with an even numbered function that is a response to a request message. |
| SDL File | Also SECS Definition Language file. A file consisting of definitions of SECS messages and definitions of items used in SECS messages. This file is used to validate SECS messages that are sent and received and to add various functionality having to do with them. |
| SECS-1 | A serial-based message transfer protocol used for sending SECS messages. The SECS-I standard is SEMI E4. |
| SECS Message | Also just message. A communication message in the format specified by the SECS-II standard that is used to communicate with an equipment. |
| Transaction | A request message and its response message if required. |
| TransactionID | Also TxID. Every request message has a unique 32-bit integer identifier that identifies the transaction. Every response message has the same TransactionID as the request message it responds to. In the HSMS and SECS-1 protocols, this is called System Bytes. |
| Next_link |
|---|