Differences

This shows you the differences between two versions of the page.

--- secs_gem_lessons_and_concepts [2020/10/07 14:03]
wikiadmin [Concepts of SECS/GEM]
+++ secs_gem_lessons_and_concepts [2021/10/11 17:49] (current)
wikiadmin [Tool Control]
@@ Line 9: / Line 9: @@
 ==== Concepts of SECS/GEM ====
-The purpose of SECS/GEM is to send messages with data, instructions, recipes, commands, events, and alarms    to and from process tools and fab or factory hosts which collect data and monitor the fab production and processes. So there are a few basic messages and data types which are widely used in SECS/GEM applications.
+When you read the SECS/GEM manual it's a confusing set of messages defined by streams and functions so you'll see references to S1F3, S2F35, S6F11, etc.
-===Data===
+These messages do represent the underlying protocol, but can be, for the most part, transparent to a SECS/GEM implementation.
-From a fab Host point of view, data is gold. The only way a Host is going to be able to monitor the processing of lots and wafers in the fab is to collect data from the tools. The fab host is also responsible to send the tools instructions, commands, and recipes to run for the specific lots.
+At its core, SECS/GEM is about ID/Value pairs. In the GEM standard, the ID is numeric.  If you're building a host application, the manual will list these IDs.  If you're building a tool interface, you get to assign suitable values.  When building a host you can also use the
+[[https://ergotech.com/files/guides/TransSECSGEMHostToolCharacterizationGuide.pdf|"Tool Characterization"]] function of TransSECS to pull all the IDs live from the tool, saving hours of reading manuals and typing and ensuring the information is accurate.
-Data in SECS/GEM messages are specific types as defined in the SEMI standard, such as Strings (type 20), Floats (type 44, 45, etc.), unsigned integers (type 51, 52, 54, etc.) and signed integers (31, 34, etc.), as well as boolean (type 10) and bytes (type 11).
+The primary IDs are VIDs - value IDs.  These just represent values that can be read from the tool (and sometimes written).
-IDs in SECS/GEM are the base unit data container and are one of the specific types described above. IDs in SECS/GEM come in several types used for different purposes: VIDs (Value IDs), which are SVIDs (Status Variables), ECIDs (Equipment Constants), and DVIDs (Data Variables). Also there are ALIDs (Alarms), CEIDs (Collection Events), and RPTIDs (Reports).
+Two other fundamental IDs are ALIDs - Alarm IDs.  These are pretty self explanatory - a high value indicates and alarm state, when the alarm is reset (low) to clear the alarm.
+CEIDs are "Collection Event Ids" .  A collection event, or simply an event, is something of interest that happens in the tool.  Examples, might be lot loaded, process started, process ended, etc.  Tool vendors are free to create as many events as they wish to allow the host to follow operation of the tool.  At a minimum there should be sufficient events to allow the host to track product through the tool, usually events like load, start, end unload.
+Host application can enable and disable events and alarms essentially choosing which they want to "listen" for.  From the equipment vendor standpoint this generally means that it's better to add more alarms and events and allow the host to choose only those of interest rather than have too few and limit the hosts ability to track the tool and collect data.
+The host can associate "reports" with events - this is the RPTID.  A report is a collection of VIDs.  Each time the tool triggers an event the reports, and so the values associated with the event are sent to the host as part of the event message.
+A "report" is a fundamental part of data collection.  The challenge is that reports contain only values, not the original IDs so the host has to map from the original configuration to the values to understand the significance of each value.
+When you configure reports in TransSECS and link them to CEIDs, TransSECS will do this work for you.  Of course, you can do much more with the data.  TransSECS can perform automatic mapping of reports to SQL. Using the names of the variables TranSECS will dynamically control the schema of the database and store the contents of the report each time it is received from the tool.  You can go from nothing to full data collection with a few keystrokes and in a matter of hours.
+{{ :pasted:20210403-104129.png?400|Drag-and-Drop Reports}}
+There are subsets of VIDs.  SVIDs, which are values that are written by the equipment and read by the host.  Similar to SVIDs are DVIDs.
 ===SVIDs vs DVIDs===
@@ Line 26: / Line 41: @@
 DVIDs are designed to be used by event reports, and are often described as "associated" with an event. The data value sent in the associated event message is guaranteed to be "fresh", updated at the time of the event trigger. If an S1F3 sometime later requests this DVID value (known as a DVVAL), it will probably contain the same values as it did for the last event, not necessarily updated since that time.
-===SECS/GEM Data Types===
+====Tool Control====
-===Messages===
+Data collection - from zero to data in a database can be accomplished directly by TransSECS with a few key presses.  You can even use our pre-configured system with a web-interface for data collection.{{ :config.png?400|Web-configured}}
-From a TransSECS point of view, SECS/GEM messages are containers for data but some also require action when received. TransSECS allows you to connect data to the items in a message, and also respond to these messages either automatically (for most GEM messages) or, if needed, run a script (see examples of message handling). The items in a message can be either a source or sink for the data values. In other words, message data items are updated from data sources for an outgoing message, or for an incoming message the data can be captured and stored or processed. One of the most important message groups for TransSECS host applications are the event report messages from the tool. Since events signal an important process stage for the tool, the associated event messages contain not only the signal that the event has occurred, but also important associated data.
+Tool control, the ability to start and stop the tool take a little more effort, but not too much.  Tool control, sending "Remote Commands" is also based around ID/Value pairs.  The S2F41 and S2F49 messages contain lists of CPName/CPVal pairs.
-Messages usually expect a reply, which can be a simple acknowledgement or a complex response with requested information, from the recipient to complete the handshaking between the tool and host. If the recipient does not understand the message (the message is not defined, for example), the reply might be a generic S9Fx message. TransSECS will automatically handle responses to unknown messages.
+Creating and using these messages in TransSECS is fairly simple, but it does depend on where you're getting the data.  TransSECS supports getting data from everything from MES systems, [[usingdatabaseserverbeansinscripting|databases]], [[opcda_server_integration_guide|OPC]] (servers and clients) to small controller and PLCs [[devices|small controller and PLCs]].
-====Message Handling====