#GCKC 色谱主板协议（命令/帧格式）说明（源码整理版）

目标：像“Modbus 寄存器说明”一样，把色谱主板（GC 主板）与工作站之间的 GCKC TCP 协议整理成可查的“命令字典 + 报文格式 + 字段说明”。
范围：仅覆盖主板↔工作站主站链路（TCP 25001/8000，帧头 GCKC）。不包含 502/503 的从站 Modbus-like 协议（见 SLAVE_STATION.md 与 MODBUS_STANDARD_MAP.md）。
数据来源：以旧版 WinForms 工作站 IBrainChrom2018 的协议实现（TcpServerSocket）与当前 Go Collector 的协议实现（src/edge/internal/protocol/gckc、chromsend143）为依据。若某些字段在源码中未被使用/未解码，会明确标为“未知/待抓包验证”。

#1. 传输与端口

• 工作站作为 TCP Server，主板作为 TCP Client 连接。
• 监听端口：
  • 25001/TCP：主端口（主站 Main Server）
  • 8000/TCP：同协议的额外监听（旧版兼容）
• 关键实现与入口：
  • 旧版收包：TcpServerSocket.OneDataReceive → AnalyseReceivedData
    • TcpServerSocket.cs
  • Go 收包：gckc.StreamDecoder → gckc.Decode → processFrame
    • stream.go / frame.go

#2. 帧格式（固定外壳）

#2.1 总结构

Frame = Header(4) + Len(2) + Body(Len) + CRC(1)
Header = ASCII "GCKC"
Len    = uint16 big-endian，表示 Body 的字节数
CRC    = uint8，对 Body 逐字节查表累积校验（见下）

Body 固定前缀：

参考实现：

• Go 编解码：frame.go
• 旧版说明：MASTER_STATION.md

#2.2 CRC（校验算法）

• CRC 为 1 字节，对 Body 逐字节滚动查表：
  • 旧版：IBrainConvert.BitByBitNo(body, idxSt=0, length=bodyLen)
    • IBrainConvert.cs
  • Go：gckc.CRC(body)（同一张 256 表）
    • crc.go

#2.3 设备 ID 特殊兼容

旧版对 DeviceID=="709131284A484845" 有占位替换逻辑（把占位 ID 替换成当前连接 ID），联调时抓包可能遇到：

• MASTER_STATION.md

#3. 常见字段编码约定（payload 内部用得多）

#3.1 整数与端序

• Len、Seq：big-endian
• payload 内多处出现 u16 = b[i]*256 + b[i+1]（big-endian）

#3.2 BCD（十进制压缩）温度/数值

旧版多处用 BCD（例如温度）：

• 2 字节 BCD → d1 d2 d3 . d4（一位小数），并支持负号编码
  • 旧版 IBrainConvert.ByteArray2Float / Go bcd2Temp1（实现等价）
  • Go 版温度解析在 parseTemps143

#3.3 “655.35”无效值

旧版 EPC 上报中把 655.35 视为无效（显示 --）：

• Answer159

#4. 命令总览（命令字典）

#4.1 旧版内置“命令号→名称”字典（基础集）

旧版在 GC08_GCs.lsItems 内维护了一份“常用命令/应答”的对照表（建议作为阅读入口）：

• GC08_GCs.cs

这份表覆盖了 0~67、以及常见应答 128~195，但不包含全部扩展命令（例如 249253、234239、216~218 等）。

#4.2 命令分类索引（建议按域理解）

• 采集/分析流程：16/17/18/19/22/23（及应答 144/145/146/147/150/151）；循环参数 4/12（及应答 132/140）
• 实时数据流：143（温度+检测器点列）、159（EPC 气路实测）
• 控温/程序升温/事件表：0/1/2（查询）与 8/9/10（设置），应答 128/129/130/136/137/138；事件表1 101/228/229
• EPC 参数/名称/控制：33/34/36/37/38/39/40/41（及应答 161~169）
• 网络/名称/使能：48/49/64/65/66/67（及应答 176/177/192~195）
• 扩展/专项：249253（点火门限/高压），48/50（查询/设置点火时长，及应答 178/181），250/251（查询/报警），234/236（保护温度），238/239（多位阀使能），216218（液相泵）等

#5. 详细命令说明（表格）

说明：下表把“发送/接收格式”写成 Body.Payload 的结构（Frame 外壳固定不再重复）。
如果 payload 在源码中只是透传 InsDeviceManager.GetXXX()，这里先给“结构来源/用途”，后续需要再补“字段逐项解释”（这通常需要结合 InsDeviceManager 的字节布局或抓包逐字节对照）。

#5.1 采集/分析流程命令

通道字段说明：

• SendCmd(byte cmd, byte channelMask) 的 payload 规则：默认 1 字节，22/23 会写入 sglNumberStart/sglNumberEnd，其他命令直接回传 {mask}
  • method_15

#5.2 实时数据推送：Cmd=143（ChromSend）

方向：GC→WS（主板主动推送）
用途：同时承载：

• 温度（至少 6 路 BCD 温度；旧版还从 payload 尾部解析额外 2 路温度）
• 检测器数据块（点列）——每个数据块包含 detectorType、采样频率、点列

#5.2.1 payload 结构（基于 Go chromsend143.ParseAll 与旧版逻辑一致）

固定头（最少 20 字节，旧版要求 len>=20）：

每个 detector block：

对应实现：

• Go 解析：parse.go

#5.2.2 通道映射（detType → channel）

见 channelFromDetectorType。

#5.2.3 点值换算（raw → pA）

Go 版当前实现了旧版一致风格的变换（平方/衰减系数/放大），用于把 4B BCD 小数转换成最终曲线值：

• transform

#5.2.4 旧版额外温度（payload 尾部 2 路）

旧版会从 payload 末尾解析两路温度（AUX3/COL2），公式 (u16 - 10000)/100：

• AnalyseReceivedData_ChromSend 末尾解析

注：这两路温度在不同固件可能并非总存在；建议以抓包确认 payload 尾部是否固定带 4 字节。

#5.3 EPC 气路实测推送：Cmd=159

方向：GC→WS（主板主动推送）
用途：推送多路 EPC（压力/流量/状态）。旧版显示为 EPCControl 的“输入/实测(psi)/实测(sccm)”等列。

#5.3.1 payload 结构（基于旧版 Answer159）

每个条目（按旧版读取顺序）：

#5.4 专项扩展：点火时长与 IP 地址（重要避坑）

安全红线：由于点火时长的应答指令与 IP 地址配置极易混淆，上位机必须严格区分解析，绝对禁止“盲写”测试，防止将错误数据覆盖到主板 EEPROM（例如将 IP 段 192 写入点火时长导致 192 秒极限异常）。

对应实现：

• Answer159

#5.3.2 当前 Go/重构侧处理方式

当前 Go Collector 为了让 UI 可配置映射（载气/氢气/空气索引不固定），会在 telemetry 事件中带出：

• epc[]：[{psi,sccm}, ...]（按条目序号 0..n-1）
• 并保留旧的 carrier/h2/air 三路字段作为兼容（默认取前 3 路）

实现见：

• telemetryEvent.Epc： main.go
• Cmd=159 处理： processFrame

#5.4 控温/程序升温/事件表（查询/设置）

这组命令的特点是：请求 payload 可能为空（查询）或为一个结构体字节块（设置）；应答 payload 为同结构体字节块。结构体的字节布局由 InsDeviceManager.GetXXX() 与 SetXXX(byte[]) 决定。

注：上表的“结构体字节布局”如果你确实需要做到“寄存器级别逐字段”，建议下一步把 InsDeviceManager 的 GetTempSetedList/GetTempSettingList/GetEventTable0/... 的实现逐字段拆解并补充到本文件（这部分工作量较大，但可以做到完全对照）。

#5.5 EPC 参数/名称/控制（查询/设置）

对应入口（旧版 payload 组包）：

• SendCmd_Convert 的 33/36/37/39/41 分支：TcpServerSocket.cs

#5.6 网络/名称/使能

#5.7 扩展/专项命令（旧版实现中出现）

#6. “完整协议”落地建议（把未知字段补齐到可发布程度）

如果你要做到“像 Modbus 寄存器文档一样，字段级 100% 明确”，建议按下面顺序补全（每步都有明确产出）：

1. 按命令号抓包对齐
   • 抓一轮完整流程：上电→查询参数→开始分析→143/159持续→停止→出数→再次循环
   • 每个 Cmd 保存 3~5 条样本帧（包含不同通道/不同状态）
2. 把所有“结构块 payload”解码逐字段落表
   • 目标类：InsDeviceManager 的 Get*/Set* 相关方法（控温/程序升温/事件表/EPC配置/网络参数/控区名称/使能位等）
3. 把 EPC(159) 的条目结构彻底校准
   • 当前旧版实现对 Byte2ToInt 的步进疑似不一致，需要用抓包确认 “unknown 字段”到底是 2B 还是 1B
4. 建立版本标识
   • 在文档首页增加“固件版本/硬件版本号 Cmd=5/133 的样本”，把协议差异归档为“版本差异表”

#7. 参考入口（源码）

• 主站协议总览：MASTER_STATION.md
• 旧版收发与命令分发：
  • TcpServerSocket.cs
  • 命令字典：GC08_GCs.cs
• Go 协议实现：
  • GCKC 编解码：frame.go
  • 143 数据块解析：parse.go

#附录 A：命令号清单（源码枚举）

本清单用于回答“有哪些命令号存在”。名称来自 GC08_GCs.lsItems + TcpServerSocket.AnalyseReceivedData/SendCmd_Convert 的实际出现情况；未命名的标记为“（未命名/待补充）”。