GEM Is Not GEM300: Which SECS Streams E87, E40 and E90 Actually Use
One socket, four primaries: S1F13 answered, S3F17, S14F1 and S16F11 all came back SxF0. What SECS/GEM support does and does not include.
The MES wants a carrier bound to the tool. You open SEMI E87, build an S3F17 Carrier Action and send it. T3 expires. Or a short frame with no body comes back, and that frame is S3F0.
The spec sheet says "SECS/GEM supported". That sentence covers SEMI E30 and stops there. E87, E40 and E90 are separate standards layered on top of E30, each living on a stream E30 never uses. They are bought and implemented separately too.
Four primaries down one socket
The capture below is not a hand-written example. A socket was opened against an HSMS passive listener on 127.0.0.1:5501 and the bytes ran from Select.req to Separate.req. Session ID 11. Framing per SEMI E37, item headers per the E5 format-code table.
First primary after Select is S1F13.
TX S1F13 00 00 00 0C 00 0B 81 0D 00 00 00 00 03 E9 01 00
RX S1F14 00 00 00 37 00 0B 01 0E 00 00 00 00 03 E9
01 02 21 01 00 01 02 41 15 "VX-9000 Plasma Etcher" 41 0D "SECSGEM-1.4.1"
Header byte 2 is 81. Top bit is the W-bit, the remaining seven bits are Stream 1. Byte 3 is 0D, Function 13. The body is 01 00 — a List of zero items.
Unpacking the reply body:
01 02— L,221 01 00— B[1]00. COMMACK 0, communication accepted.01 02— L,241 15— A[21]VX-9000 Plasma Etcher(MDLN)41 0D— A[13]SECSGEM-1.4.1(SOFTREV)
Plain E30 so far. Now change nothing but the stream.
TX S3F17 00 00 00 0C 00 0B 83 11 00 00 00 00 03 EA 01 00
RX S3F0 00 00 00 0A 00 0B 03 00 00 00 00 00 03 EA
TX S14F1 00 00 00 0C 00 0B 8E 01 00 00 00 00 03 EB 01 00
RX S14F0 00 00 00 0A 00 0B 0E 00 00 00 00 00 03 EB
TX S16F11 00 00 00 0C 00 0B 90 0B 00 00 00 00 03 EC 01 00
RX S16F0 00 00 00 0A 00 0B 10 00 00 00 00 00 03 EC
All three went out with the same empty List body. The equipment cuts them off at the stream, before it reads the body at all.
SxF0 does not say "not supported"
The three returned frames are all 00 00 00 0A long — ten header bytes and nothing else.
| byte | S3F0 | meaning |
|---|---|---|
| 0-1 | 00 0B | SessionID 11 — same as the request |
| 2 | 03 | Stream 3, W-bit clear |
| 3 | 00 | Function 0 |
| 4-5 | 00 00 | PType 0, SType 0 — a data message |
| 6-9 | 00 00 03 EA | SystemBytes, copied from the request |
Function 0 is the abort. The stream comes back as sent, so you can tell which request was refused, and the SystemBytes match, so your transaction table pairs it up. That is the whole of it. There is no reason code. Nothing in the frame separates "that stream is not implemented" from "not right now" from "your body was wrong".
E5 has messages for exactly this. An unimplemented Stream is S9F3, an unimplemented Function is S9F5. This listener sent neither. That is common enough that I wrote up why a host cannot count on getting an S9 at all.
The thing that actually bites host code: treat SxF0 as "no reply" and you wait out T3 and retry. The retry comes back SxF0 too. The log fills with timeouts, and the cause is not a timeout.
Which standard lives on which stream
E30 does not use every SECS-II stream. The GEM300 standards sit in the ones it leaves empty, which is why a GEM-only tool does not know those streams exist.
| standard | what it does | stream |
|---|---|---|
| E30 GEM | communication setup, state models, events, alarms, remote commands, recipes | S1, S2, S5, S6, S7 |
| E87 Carrier Management | carriers and load ports | S3 Materials Status |
| E39 Object Services | the common get/set services for object attributes | S14 Object Services |
| E40 Process Job Management | creating and running process jobs | S16 Processing Management |
| E94 Control Job Management | control jobs — a bundle of process jobs | S14 |
| E90 Substrate Tracking | the location and state of one substrate | no stream of its own |
The stream numbering is E5's. E87 on S3, E39 on S14 and E40 on S16 all follow from that table.
The empty cell on the E90 row is not an omission. E90 adds no new stream. It defines an object per substrate and pushes the state changes through the collection events E30 already has. Host-side, asking whether a tool "does E90" is not asking whether S90 works — it is asking whether those CEIDs and those variables are defined on the tool. Linking reports to events in the right order is the same procedure that answers it.
Two things below come from the standards documents and I have not verified them against a tool. S3F17 is the E87 carrier action request, and S16F11 is on the E40 process-job creation side, as far as I know. What the capture proves is not the meaning of those function numbers — it is that streams 3, 14 and 16 are closed on this equipment, whole. Response codes like CAACK and ACKA are absent from this article on purpose. I have never checked their values.
"Is communication up" and "does the stream exist" are different questions
The order gets muddled during bring-up, because three separate layers fail with symptoms that look alike.
- Is HSMS SELECTED — if not, data messages never leave at all.
- Is E30 communication open — did S1F13 return COMMACK 0. Before it does, everything except S1F13 is SxF0. What the communication gate blocks ahead of S1F13 is its own write-up.
- Is that stream implemented — fail here and no amount of staring at the first two will show it.
The third one is this article's SxF0. Layers one and two are healthy and layer three is not, and the log cannot tell you that apart from a layer-two failure. The way to separate them is the capture above. On the same socket that just returned a real S1F14, throw the stream in question once. S1F14 arrives and S3F0 arrives: communication is alive and the stream is missing.
What to ask before you order the tool
"SECS/GEM supported" is not an answer. Three sentences to look for in the quote:
- Which GEM300 standards are implemented — E87, E40, E90, E94, named one at a time. "GEM300 compliant" is a label, not a specification.
- The implemented stream and function list — usually a table in the vendor's GEM compliance statement. If there is no table, that is the answer.
- Which objects are exposed over S14 — the E39 object services have to be open before anything on the E94 control job side will attach.
Run the capture above before the tool ships and the gap between the spec sheet and the socket shows up on day one. Six frames does it.
The bytes here came off the passive listener in the SECS/GEM HSMS simulator. Open a socket in the same order and you get the same frames.