【摘要】
设备通信不通的时候，最浪费时间的做法是"从头查"。正确做法是分层：先确认 TCP，再确认 HSMS 会话，再确认 GEM 配置，最后才查业务逻辑。
这篇文章把现场最常见的七个坑按层级排好，每个坑给判别方法和修复路径。看懂这一篇，EAP 对接类问题的平均定位时间能从 2 小时压到 20 分钟。
【核心要点】
- 排查顺序永远是：网络层 → 会话层（HSMS）→ 消息层（SECS-II）→ 业务层（GEM 配置）
- "TCP 能连"不等于"通信正常"，HSMS 要经过 Select 才建立会话
- 事件采集不全，90% 是 CEID/RPTID/VID 三者配置不匹配
- 配方下发是最危险的环节，必须做内容校验 + 回读确认
- 时钟不同步会让所有时间序列分析失效，且极难发现
---
一、先建立分层模型（30 秒讲完）
设备 ── RS-232 / TCP ── HSMS 会话 ── SECS-II 消息 ── GEM 行为 ── 业务逻辑
(物理/网络层) (会话层) (消息层) (应用层)- HSMS 是传输层协议，负责在 TCP 上建立会话（Select/Deselect）、心跳（Linktest）、分离（Separate）。
- SECS-II 是消息格式，S1F1、S2F41、S6F11 这些。
- GEM 是"设备该支持哪些行为"的标准，包括事件上报、报警管理、配方管理、远程命令。
FDE 只需要记住：不通时按层往上查，别跳层。
二、坑一：TCP 通了，但 HSMS 会话没建立
现象：telnet 能连上 5000 端口，EAP 显示"已连接"，但收不到任何数据。
原因：TCP 三次握手成功只说明端口开着。HSMS 会话需要 Host 发 Select.req，设备回 Select.rsp（状态 0 才是成功）。中间任何一方没实现、或 Passive/Active 模式配反了，会话都建不起来。
判别：看 EAP 日志有没有 Select.req sent 和 Select.rsp status=0。如果只有前者没有后者，八成是设备侧 HSMS 版本或模式问题。
修复：确认设备侧是 Passive（监听）还是 Active（发起），两端不能都 Passive；检查 Device ID 是否一致（不一致时 Select.rsp 会返回非 0）。
三、坑二：CEID 没注册，事件永远收不到
现象：设备状态明明变了，EAP 一条 S6F11 都收不到。
原因：GEM 的事件上报是"订阅制"。Host 必须先用 S2F33（定义报告）和 S2F35（链接事件与报告）把 CEID → RPTID → VID 的关系告诉设备，设备才会在事件发生时发 S6F11。少一步，设备就"沉默"。
判别：查 EAP 启动日志里有没有 S2F33/S2F35 的发送记录与 S2F34/S2F36 的 ACK。设备侧可以查 Event 使能状态。
修复：重新下发定义；注意多数设备在断连后会清空订阅，重连后必须重新注册——这是"断连自愈"必须实现的一环。
四、坑三：RPTID 绑错 VID，字段全是 0 或错位
现象：事件收到了，但里面的值不对：温度显示 0、状态码乱跳。
原因：RPTID 里绑的 VID 顺序与 EAP 解析顺序不一致，或者 VID 定义与设备实际不符（比如设备用 VID 1001 表示腔体温度，EAP 按 1002 解析）。
判别：拿一条原始 S6F11 报文，逐字段对设备的 Variable List 表。
修复：以设备手册为准重建 VID 映射；建议在 EAP 里加一层"字段校验"，值超出物理范围（如温度 0 或 9999）时直接告警，而不是静默入库。
五、坑四：S6F11 事件漏采，数据断断续续
现象：一天的产能数据，某些机台缺 10%–20% 的记录。
三个常见原因：
- 采集频率与设备能力不匹配：设备侧 T3（回复超时）很短，EAP 处理慢就丢消息
- 消息洪泛：一台机台每秒上报大量事件，EAP 队列积压后丢弃
- 断连期间的事件没补采：设备缓存有限，断超过一定时间就丢失
判别：对比设备侧计数器与 EAP 入库条数；查 EAP 日志有无 T3 timeout 或队列溢出记录。
修复：EAP 侧做批量入库 + 异步处理；关键事件（如 Lot 开始/结束）要求设备端重发或通过查询补采（S1F11/S1F12 或设备专有接口）。
六、坑五：S7F3 配方下发，没有校验就是定时炸弹
现象：配方下发成功了，但设备执行的是旧版本，或者参数被截断。
原因：S7F3（Process Program Send）只管把内容送过去，不管内容对不对。常见问题：
- 编码问题：PPBODY 的格式（ASCII/Binary）与设备不一致，中文/特殊字符被截断
- 版本没校验：设备不返回 PPID 版本，回读（S7F5）才发现不一致
- 单位不一致：EAP 传秒，设备按分钟解释
正确做法（这条必须写进方案）：
- 下发前计算内容校验值（Checksum/MD5），随报文一起传（部分设备支持）
- 下发后强制
S7F5回读，逐字段比对 - 比对不一致就阻断生产并报警，不要"重试一次看看"
- 所有下发记录留档：谁、什么时候、下发了什么、校验结果
七、坑六：时钟不同步，所有时序分析失真
现象：Lot 在 MES 的时间与 EAP 采集的时间差几分钟甚至几小时，追溯时对不上。
原因：设备时钟漂移、时区配置不一致（UTC vs 本地）、EAP 服务器与数据库时间不同步。
判别：取同一事件在设备日志、EAP 日志、MES 记录中的三个时间戳做差。
修复：设备侧启用 NTP 或通过 S2F31 校时；EAP 入库统一转 UTC 并保留原始时区；报表层再转本地时间。这条不做，后面所有 FDC/SPC 的时序分析都不可信。
八、坑七：消息洪泛导致周期性断连
现象：每天固定时段断连几次，重连后恢复正常。
原因：某类事件在特定时段高频触发（比如批量加工结束），EAP 处理不过来，TCP 缓冲区打满，链路被判超时。
修复：
- 按事件类型分级：关键事件实时处理，非关键事件合并/降频
- 增加 Linktest 间隔并合理设置 T6/T7/T8 超时
- EAP 侧引入背压机制，队列满时明确丢弃策略并记录
九、一张现场排查速查表
| 现象 | 先看哪层 | 第一动作 |
|---|---|---|
| 完全无数据 | 网络 | telnet 端口 / ping |
| 连接但无消息 | 会话 | 看 Select.req/rsp |
| 有消息但没事件 | GEM 配置 | 查 S2F33/S2F35 是否下发成功 |
| 事件有但值错 | 消息字段 | 对 VID 映射 |
| 数据断断续续 | 性能/队列 | 看 T3 超时与队列积压 |
| 配方下发异常 | 内容校验 | S7F5 回读比对 |
| 时间对不上 | 时钟 | 三方时间戳做差 |
下一篇讲数据排查：拿到一个"良率掉了"的问题，怎么用 EAP 日志、Lot 流、FDC 时序、SPC 记录、数据库快照五路数据在半小时内缩小到根因。