4. T6定时器触发场景：S1F13/S1F14与S1F1/S1F2中的触发机制
T6定时器在设备初始化流程中扮演着关键的角色，它主要用于监控控制会话（Control Session）的建立过程。在SECS/GEM协议中，T6定时器主要在两个核心的握手交互中被触发：S1F13/S1F14（建立通信请求/响应）和S1F1/S1F2（查询设备ID）。理解这两个场景下的触发机制，是诊断初始化超时故障的基础。
4.1 在S1F13/S1F14中的触发机制
S1F13（Establish Communication Request）是主机（Host）向设备（Equipment）发起的第一个正式会话建立请求。当主机发送S1F13后，T6定时器立即启动，等待设备回复S1F14（Establish Communication Acknowledge）。这是初始化流程中最关键的握手，任何一方响应超时都会导致连接失败。
下表列出了S1F13/S1F14交互中T6定时器的关键参数与行为：
| 参数/行为 | 描述 | 典型值 |
|---|---|---|
| 触发事件 | 主机发送S1F13消息 | — |
| 停止事件 | 主机收到有效的S1F14消息 | — |
| 超时动作 | 主机重发S1F13（最多重试3次）或断开连接 | — |
| T6超时值 | 等待S1F14响应的最大时间 | 45秒（可配置） |
| 常见故障原因 | 设备未启动、网络延迟、设备消息队列满 | — |
下图展示了S1F13/S1F14交互中T6定时器的启动与停止流程：
4.2 在S1F1/S1F2中的触发机制
S1F1（Are You There?）是主机用于查询设备是否在线以及获取设备ID的轻量级消息。虽然S1F1/S1F2交互通常发生在S1F13/S1F14之前（作为连接探测），但在某些实现中，主机也会在初始化流程中或之后使用S1F1来验证设备状态。当主机发送S1F1后，T6定时器同样会被触发，等待设备回复S1F2（On Line Data）。
S1F1/S1F2交互中T6定时器的触发机制与S1F13/S1F14类似，但具有以下特点：
- 触发时机：主机发送S1F1消息时启动T6。
- 停止时机：主机收到有效的S1F2消息时停止T6。
- 超时处理：主机通常重发S1F1，重试次数由系统配置决定（通常为3次）。
- 典型超时值：45秒（与S1F13/S1F14一致，可独立配置）。
下表对比了S1F1/S1F2与S1F13/S1F14中T6定时器的差异：
| 对比维度 | S1F1/S1F2（查询设备ID） | S1F13/S1F14（建立通信请求） |
|---|---|---|
| 消息用途 | 探测设备在线状态与设备ID | 建立正式控制会话 |
| 消息长度 | 短（通常仅包含设备ID） | 长（包含版本、功能列表等） |
| 处理复杂度 | 低（设备只需回复ID） | 高（设备需验证并建立会话） |
| T6超时常见原因 | 设备离线、网络中断 | 设备忙、消息解析失败、状态异常 |
| 重试策略 | 通常重试3次后放弃 | 重试3次后断开连接 |
下图展示了S1F1/S1F2交互中T6定时器的完整生命周期：
4.3 两种场景的故障诊断对比
在实际的半导体设备调试与运维中，T6定时器在S1F13/S1F14和S1F1/S1F2中的超时故障具有不同的诊断方向。下表总结了两种场景下的典型故障模式与排查建议：
| 故障场景 | 典型现象 | 排查方向 | 优先级 |
|---|---|---|---|
| S1F1/S1F2 T6超时 | 主机无法获取设备ID，初始化流程卡在第一步 | 1. 检查物理网络连接 2. 检查设备电源与启动状态 3. 检查设备SECS/GEM服务是否运行 |
高 |
| S1F13/S1F14 T6超时 | 主机发送S1F13后无响应，通信建立失败 | 1. 检查设备消息队列是否阻塞 2. 检查设备状态机是否处于正确状态 3. 检查防火墙或端口配置 |
最高 |
| 两者均超时 | 初始化流程完全无法进行 | 1. 检查TCP/IP连接是否建立 2. 检查设备IP与端口配置 3. 检查主机与设备之间的路由 |
紧急 |
通过以上分析可以看出，T6定时器在S1F1/S1F2和S1F13/S1F14中的触发机制虽然相似，但故障诊断的侧重点不同。S1F1/S1F2的超时更多指向底层连接问题，而S1F13/S1F14的超时则可能涉及更复杂的应用层状态问题。掌握这两种场景的差异，是高效诊断设备初始化故障的关键。