S1f15

S1F15/S1F16 is the SECS-II message pair the host sends to deliberately take equipment out of Online control and return it to Local, the opposite transition from S1F17/S1F18's Request Online — the host is voluntarily giving up supervisory authority, not losing it due to a communications fault. This distinction matters because a tool going offline unexpectedly due to a dropped link or an equipment-side fault is a different, more serious event than a host intentionally issuing S1F15 to release control — S1F15/S1F16 is the clean, acknowledged version of going offline, used for planned maintenance windows, operator handoffs, or whenever a fab deliberately wants local supervisory authority restored to the tool.

Equipment currently Online, host in control
Following a successful S1F17/S1F18 transition earlier
S1F15/S1F16 offline transition requestHost voluntarily releases control
S1F15 sent by host
Request Offline
S1F16 returned by equipment
Acknowledge — offline transition accepted
Equipment now in Local control
Operator at the tool has supervisory authority again

Unlike S1F17's request-online transition, which equipment can legitimately refuse, S1F15's offline request is generally expected to always succeed — a host asking equipment to release control back to local operators is not something a tool normally has a valid reason to deny, since relinquishing authority is strictly less restrictive for the equipment than taking it on. This asymmetry is worth knowing precisely because it means host software should treat an unexpected S1F16 denial (where the SECS standard allows for one) as a genuinely abnormal condition worth investigating, rather than the routine, expected refusal path that exists for S1F18.

S1F15/S1F16 — Request Offline, Host-Initiated the host voluntarily gives up control — not a fault condition Host Equipment S1F15 (Request Offline) S1F16 (acknowledge) S1F15 vs. S1F17 — asymmetric expectations S1F15 (give up control): normally always granted S1F17 (take control): can be legitimately refused unexpected S1F16 denial is abnormal, unlike routine S1F18 denial

S1F15/S1F16 and S1F17/S1F18 are the matched pair that moves equipment between Local and Online control, both built on top of the S1F13/S1F14 communications handshake that has to succeed first — together these three message pairs form the complete control-state lifecycle every GEM-compliant tool goes through, from link establishment through host supervisory control and back.

Take S1F15 further

Ask the copilot about this term, or have our engineers assess it against your process.

Ask CFSGPT about this → Request a technical assessment → Open the CFS app