S1f17

S1F17/S1F18 is the SECS-II message pair the host sends to ask equipment to transition into the Online control state, the state in which the host has supervisory authority and the equipment will act on host commands — distinct from the communications-level handshake of S1F13/S1F14, which only establishes that messages can be exchanged at all, not that the host is actually in control. A tool can be fully communicating (S1F13/S1F14 succeeded) while still sitting in Local control, where an operator at the equipment retains supervisory authority and ignores host commands; S1F17 is the host's explicit request to change that — "please go online" — and S1F18 is the equipment's acknowledgment, which can grant the request or refuse it depending on local conditions.

The acknowledge code carried back in S1F18 is doing real work, not just confirming receipt, because equipment is allowed to refuse the online request — a tool mid-maintenance, a tool an operator has deliberately locked to Local for safety, or a tool in an equipment-specific state that doesn't permit remote control can all legitimately return a denial code rather than granting the host's request. This is why host software cannot simply assume an S1F17 request will succeed and must branch on S1F18's actual acknowledge code — treating every S1F17 as automatically successful is a common integration shortcut that works fine until the first time equipment legitimately refuses, at which point the host's internal state tracking silently diverges from the tool's actual control state.

S1F17/S1F18 is the operational counterpart to S1F15/S1F16 (Request Offline), which the host uses to deliberately return a tool to Local control, and both pairs depend entirely on the S1F13/S1F14 communications handshake having already succeeded — control-state transitions are meaningless to request over a link that isn't yet confirmed to be communicating.