S2f35

S2F35/S2F36 is the SECS-II message pair the host uses to link an already-defined report (from S2F33/S2F34) to the specific Collection Event ID (CEID) that should trigger it — this is the step that answers "when should this report actually get sent," which the report's own definition never specifies on its own. A report defined by S2F33 just describes a bundle of variables under an RPTID; it has no inherent connection to any event until S2F35 (Link Event Report) tells the equipment "when CEID_X occurs, send report RPTID_Y," and S2F36 (Link Event Report Acknowledge) confirms that link was accepted — one CEID can trigger multiple linked reports, and one report can be linked to multiple different CEIDs, so this is a many-to-many relationship, not a strict one-to-one pairing.

The many-to-many flexibility S2F35 allows is what lets a single process-complete event drive several different reports simultaneously — a fab might link the same "process step complete" CEID to one report containing process-chamber conditions for engineering review and a completely separate report containing just lot/wafer identifiers for MES tracking, both firing off the same underlying event without the equipment needing two separate trigger mechanisms. This flexibility is also why S2F35's link step has to be managed carefully during integration — a report accidentally linked to the wrong CEID, or left linked to a CEID it should have been unlinked from after a configuration change, silently changes what data arrives when, which is exactly the kind of mismatch that surfaces as "the host is getting data at the wrong time" rather than any explicit error.

S2F35/S2F36 is the middle step between S2F33/S2F34 (Define Reports, which describes what data a report contains) and S2F37/S2F38 (Enable/Disable Event Reporting, which turns a linked report's actual transmission on or off) — all three steps have to be correctly configured before S6F11/S6F12 (Collection Event Reporting) ever delivers the intended data to the host automatically.