2026年10月第四周 · 2026 · W44

本周推进

本周主要围绕LXN05液冷机组做现场通信调试，梳理配置文件里的控制参数和设备动作，同时结合现有通信协议与代码，为客户使用Qt开发上位机整理接口文档。

区分了RW控制配置与RO监控配置，核对工作模式、开关机使能、温控测点、目标温度、回差和水泵转速的含义。明确哪些字段是控制请求，哪些是实际状态或驱动器反馈，避免只看到写入成功就认为设备已经运行。

现场先按以下顺序检查通信与供电条件：

调试步骤	检查内容
1. 485线的正负接口	核对A/B定义和实际接线，确认连接主控对BMS或上位机的外部485口，不能只凭A/B字母判断正负
2. 485转USB转换器	确认转换器类型、驱动和COM口，检查是否存在本地回显或回环，必要时替换转换器对比
3. 低电压开关	确认开关状态及控制器低压供电正常，再进行通信和设备动作测试

通信参数按当前代码核对为Modbus RTU、9600、8位数据、无校验、1位停止位，从站地址为1。先只读版本、状态和现有参数，通信正常后再依次验证水循环、制冷和制热。

对照45kW液冷机组双系统通信协议与当前C代码，整理了一份15页接口文档，覆盖串口参数、寄存器地址、数据类型与变比、告警位、读写报文、控制流程和异常处理。

交付内容包括Word文档、便于维护的Markdown，以及Qt6只读示例工程。示例采用异步请求，先读版本和参数，再轮询状态；区分串口打开与有效通信，不自动下发开机命令，也不在重连后自动重放运行指令。

文档中的示例报文已核算CRC，并逐页检查了表格和代码排版。Qt示例尚未编译或连接实机验证，客户环境下的联调仍需继续。

现场遇到RO、RW都报Timeout的情况，之后通过Bus Hound抓包进一步查看收发内容。软件打开COM口，只能说明电脑端串口打开成功，不能证明主控已经收到并正确处理请求。

抓包时又出现了两种错误：RO提示接收字节不足，RW提示校验错误。对照报文发现，接收内容与发送请求高度重复：03读取应当返回寄存器数据，10写多个寄存器应当只返回起始地址和数量，但收到的内容更接近原请求。

现场排查已确认，本次回显及通信异常的原因是低压开关和USB转485转换器问题。调试时应先确认低压开关及控制器供电正常，再检查转换器和485链路，并通过抓包核对设备的有效应答。

现场不能联网时，预先安装好驱动的Modbus Poll和Bus Hound仍可配合使用。重点是保存发送帧、接收帧和时间信息，方便离线核对，不能只记录软件最后显示的错误文字。

这次对照发现，参考协议、旧配置标签与当前代码之间存在差异，需要在客户文档中明确说明。

项目	当前LXN05代码的实际行为
水泵速度写0	制冷和制热模式会回退到默认90%，水循环模式回退到50%，不能靠0泵速停机
215号水循环泵速	原始值就是百分比，50表示50%，不乘10
205号温控测点	1取回水温度，其他值走出水温度；协议中的监控温度模式未实际接入
204号除雪及300～302号温度	虽有协议或存储定义，当前没有相应的业务控制逻辑
21号本地远程状态	当前是曾收到485报文的标志，不能直接判断实际控制权

不同固件版本的同一个寄存器可能有不同含义。例如本次LXN05的泵速0语义，就不能与其他版本的手动停泵逻辑混用。接口文档需要绑定对应代码和发布固件，不能只靠配置文件名或软件版本字判断一致。

代码中还确认了一个需要重点验证的行为：485通信超时约30秒后，控制器会进入自动控制，并可能主动设置上高压，与参考协议中保持原开关机使能的描述存在差异。

因此，关调试软件、停止轮询或拔485线都不能作为可靠停机方式。上位机需要分别显示控制请求、实际模式和设备反馈；正常停机应下发停止与关机请求，并继续核实状态。

另外，HMI接管后，当前主循环会停止处理外部485从机请求，读写都可能超时。这种情况需要与接线故障、控制器掉电等原因区分。通信失联和本地接管的实际表现，后续仍需在受控现场验证。