IEC 104 Slave Simulator 开发与调试记录
- 方案设计 工作需要测试 IEC 104 通讯协议，重点实现数据发生功能。我打算用 C# 编写一个 IEC 104 的 Slave Simulator 。首先使用 Claude Code 做方案设计，与它反复确认后形成了一份详细的方案文档。
- 初次编程 方案确定后，我将文档交给 Cursor 进行第一次编码。我是 Cursor 的付费用户，但当时额度已用完，只能使用 Auto mode。生成代码后，用真实的 IEC 104 Master 连接测试，结果可以连上，却读取不到任何数据。奇怪的是，仿真器界面上数据显示是在变化的。
- 优化调试 遇到问题后，我改用 Claude Code + Deepseek V4 Flash 进行调试（开启了 thinking mode ，未用 Pro mode ，也未开 1M 上下文）。AI 只修改了一次代码，大约花了 10 分钟，问题就解决了。Master 成功读到数据，整个调试过程花费极低。 最主要的是 deepseek 几乎是完全重构了最关键的 IEC104 的 lib60870 库的使用。
DS 的输出反馈： ● Root Cause SlaveServer.cs 使用了原始 TcpListener 接收 TCP 连接，但完全没有实现 IEC 104 协议栈：
收到报文后只打印 Hex 日志，不做任何协议响应（不回复 STARTDT CON 、S 帧、I 帧） PublishPoint 只做 TxCount++，从不发送数据 引用了 lib60870.NET NuGet 包，但 从未调用任何库方法 架构文档中提到了 lib60870 层，但实际代码跳过了整个协议栈
所以 IEC 104 Master 可以建立 TCP 连接，但收不到任何 IEC 104 协议报文，显示"已连接"但无数据。 修改内容
Services/SlaveServer.cs — 完全重写
用 lib60870.CS104.Server 替换原始 TCP 逻辑（关键发现：CS104.Server 继承自 CS101.Slave ，天然具备全套协议处理能力）：
协议栈完整实现：TCP 连接、APCI 层、STARTDT/S 帧/U 帧/I 帧 全部由 lib60870 自动处理 总召唤响应 (C_IC_NA_1)：收到 interrogation 后按 TypeID 分组发送所有数据点，最后发 ACT_TERM 遥控命令 (C_SC_NA_1)：收到单点遥控后发 ACT_CON → 执行 → 发 ACT_TERM 设点命令 (C_SE_NC_1)：收到浮点设点后发 ACT_CON → 执行 → 发 ACT_TERM 时钟同步 (C_CS_NA_1)：接收并确认 数据发布：PublishPoint 实际编码为 ASDU （ MeasuredValueShort/SinglePointInformation ），通过 Server.EnqueueASDU() 发送 APCI 参数：K/W/T1/T2/T3 从配置加载 连接管理：最大客户端限制、连接跟踪、收/发统计
Form1.cs — 新增一行
添加 _slaveServer.SetPoints(_runtimePoints.ToList()) 传递数据点引用，使总召唤时能读取当前值。 建议测试步骤
构建并启动程序，加载 station_01.json 用 IEC 104 Master 连接 127.0.0.1:2404 预期：总召唤后应收到所有数据点值，周期上送正常 测试遥控：对 IOA=400 下发 C_SC 命令 测试设点：对 IOA=401 下发 C_SE_NC 命令
- 总结与展望 目前尚未涉及非常复杂的 task ，后续我会持续更新这个案例。这次经历让我感到：国产 AI 模型替代 Claude Code 、替代 ChatGPT 的那一天总会到来，我由衷期待这一天早日来临。