好，那我们进入最关键的一讲——
第十二讲：完整事件通知流程全景图——CEID 触发到主机接收的全过程
关键词：CEID 事件上报、S6F11 报文、事件触发流程、数据驱动机制、Report Dispatch、主机解析流程
本讲目标
你将彻底理解：
- 设备是如何触发一个事件上报的？
- 报文（S6F11）结构是怎么设计的？
- 主机是怎么解析报文、提取变量、派发处理？
- 报文中包含的信息是怎么匹配你之前定义的 CEID/RPTID/VID？
- 这个流程中，主机和设备的职责分界线是什么？
一、设备上报事件的标准流程
回忆我们前面几讲提到的核心关系：
事件（CEID）
→ 对应报告（RPTID）
→ 报告中包含变量（VID）
那么，当设备内部某个事件触发时（比如开始加工一个 Lot）：
- 设备查找：这个 CEID 被绑定了哪些 RPTID？
- 查找每个 RPTID 中的变量（VID）清单
- 获取当前这些变量的值
- 构造一条 S6F11 报文
- 发送给主机
所以说，S6F11 是 GEM 通信里 最关键、最常见、最“内容丰富” 的报文。
二、S6F11 报文结构详解（设备 → 主机）
格式如下：
S6F11
- DATAID (U4) // 数据编号，可选
- CEID (U2) // 事件编号
- Report List (L)
- RPTID (U2) // 报告编号
- VIDs... // 变量值，顺序与之前定义保持一致
举个例子：
假设你之前定义了：
S2F33:
RPTID = 101 → [3001, 3002]
RPTID = 102 → [3003]
S2F35:
CEID = 1 → [101, 102]
当设备触发 CEID = 1，报告 101 和 102 被激活。
此时报文内容可能长这样：
S6F11
- DATAID = 12345
- CEID = 1
- List(
List(U2(101), List(ASCII("LOT123"), ASCII("PRODUCT_X"))),
List(U2(102), List(U1(5))) // EQ_STATE = 5
)
主机只要一看 CEID = 1，就知道：
- 报告 101 = LOT_ID + PRODUCT_ID
- 报告 102 = EQ_STATE
三、主机收到 S6F11 后该怎么办？
流程如下：
- 解包：获取 CEID → 确定事件类型
- 遍历 RPTID → 找到其绑定的 VIDs
- 解析每一个变量
- 根据 CEID 和数据内容，进入具体业务逻辑
这一步是你主机代码的主战场！
在 SECS4NET 中大概是这样：
public override Task<S6F11> OnS6F11(SecsMessage msg)
{
ushort ceid = msg.SecsItem[1].U2Value;
var reports = msg.SecsItem[2].Items;
foreach (var report in reports)
{
ushort rptid = report[0].U2Value;
var vars = report[1].Items;
// 你需要建立一个“RPTID→VIDs映射”表
var vids = GetVidsForRptId(rptid); // 自己缓存的
for (int i = 0; i < vids.Length; i++)
{
ushort vid = vids[i];
var value = vars[i];
// 做解析、记录、存库、触发业务
}
}
return Task.CompletedTask;
}
四、主机端缓存机制（必须有）
你必须维护一个本地缓存表：
Dictionary<ushort, List<ushort>> rptidToVids;
Dictionary<ushort, List<ushort>> ceidToRptid;
Dictionary<ushort, string> vidToName;
这些内容来自你前面发的：
- S2F33（定义报告）
- S2F35（绑定事件）
设备不会再告诉你它报文里是哪些 VID，所以你要记住之前的定义结构。
五、主机应该如何组织代码逻辑？
建议你将事件处理流程拆成这几层：
S6F11 事件处理器
└── 解析 CEID
└── 映射到事件名（如：StartLot）
└── 加载每个报告内容
└── 提取每个变量值
└── 分派给业务处理模块
比如：
if (ceid == 1) // Start Lot
{
var lotId = GetValueFrom(vid=3001);
var productId = GetValueFrom(vid=3002);
DoStartLot(lotId, productId);
}
你也可以设计一个通用 Dispatcher，配置式地绑定 CEID 与处理方法。
六、S6F11 报文还可以嵌套 Alarm、RemoteCommand 等事件
CEID 只是个编号，厂商可以定义任何含义：
- CEID = 3 → 表示发生 Alarm
- CEID = 7 → 表示 RemoteCommand 执行完毕
你只需要做到 根据 CEID 进入对应业务流，剩下就靠你主机的逻辑。
七、事件流程与 GEM 其他机制协作的全景图
主机 设备
↓ ↑
S2F33：定义报告（RPTID → VIDs）
↓ ↑
S2F35：绑定事件（CEID → RPTID）
↓
等待设备触发事件 ← 设备内部逻辑触发事件
CEID = 1
↓ ↑
收到 S6F11 (CEID, RPTID, VIDs...)
↓
解析事件 → 派发处理 → 存库、提示、更新UI等
这个完整流程你一定要熟！
第十二讲 · 小结
| 步骤 | 内容 |
|---|---|
| CEID 触发 | 设备内部事件激活 |
| 查找 RPTID | 查找绑定报告 |
| 填充变量 | 每个 RPTID 包含哪些 VID，就去填值 |
| 构造 S6F11 | 报文包含 CEID、报告列表 |
| 主机解析 | 解包、提取、处理 |
你已经掌握了 GEM 通信中最重要的一环：事件触发上报 + 主机响应处理。
这一块理解透了，你面对任何设备、任何 CEID/RPTID/VID 结构都能应对自如。
下一讲预告：
第十三讲：Alarm 报警机制详解（S5F1/S5F2 + S5F3/S5F4）——报警通知、注册机制、报警恢复
设备怎么通知你报警了？报警信息从哪来？你怎么知道报警恢复了？下一讲来拆透报警系统。
继续？我们接上。
