S6f11

S6F11/S6F12 is the SECS-II message pair that actually delivers collected report data to the host — the payoff of the entire define/link/enable setup chain (S2F33/S2F34, S2F35/S2F36, S2F37/S2F38), and the single most frequently exchanged message pair in most GEM-compliant SECS/GEM sessions once a tool is running production. Every time an enabled Collection Event ID (CEID) occurs on the equipment, the equipment spontaneously sends S6F11 (Event Report Send) to the host, carrying the CEID that fired and the data from every report linked to it; S6F12 (Event Report Send Acknowledge) is the host's simple acknowledgment that the report was received, with no substantive reply content of its own.

S6F11 is equipment-initiated and unsolicited, which is a structurally different pattern from most of the request/reply pairs elsewhere in SECS-II where the host asks and the equipment answers — here the equipment decides when to speak, based entirely on its own internal event firing, and the host's only job is to receive and acknowledge, never to request a specific S6F11. This is exactly why the three-step setup chain matters so much in practice: since S6F11 traffic is driven by equipment-side event firing rather than host polling, a host has no way to directly ask "did anything happen" — it can only wait for whatever the define/link/enable configuration was actually set up to deliver, which is why misconfigured reporting setup silently produces missing data rather than an obvious query failure.

S6F11/S6F12 is where the whole GEM300 equipment-automation lineage comes together — the Equipment Performance Tracking standard (SEMI E116) rides on top of this exact mechanism to report E10 state transitions, Substrate Tracking (SEMI E90) uses collection events to signal wafer location changes, and nearly every other GEM-family standard that needs to notify the host of something happening ultimately does so through an S6F11 report carrying whatever CEID that event corresponds to.