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.
SECS Definition Language (SDL) File
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.
SECS/GEM Message Basics
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:
|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.|