Nevar pievienot vairāk kā 25 tēmas
Tēmai ir jāsākas ar burtu vai ciparu, tā var saturēt domu zīmes ('-') un var būt līdz 35 simboliem gara.
3.1 KiB
3.1 KiB
不需要把所有底层 Modbus 细节都自己补一遍。基于当前项目的业务目标，建议分成“必须完善”和“暂时不用做”两类。
必须确认或完善的部分
1. 确认功能码和地址映射
必须用 XDH-60T4-E 手册确认：
M 区是否对应 Coils
D 区是否对应 Holding Registers
M 区读写功能码是否支持
D 区读写功能码是否支持
地址是否使用 0 开始的原始地址
当前代码的方向是：
M 区 -> Coils
D 区 -> Holding Registers
只要和设备手册一致，就不需要重新设计。
2. 确保 Qt 错误能正确转换成业务状态
当前已经能处理：
连接失败
PLC 不响应
超时
串口断线
协议错误
读取失败
写入失败
这部分已经满足核心业务。
建议后续补充测试：
每种 Qt 错误都能映射到正确的 PlcCommunicationError
错误后会停止轮询
错误后会撤销首读资格
真机运行时会退出编辑态
UI 能收到错误通知
3. 需要明确写入异常后的业务反馈
当前写入错误会进入 Faulted，这是安全的。
但最好确认 UI 能明确显示：
写入请求失败
PLC 拒绝写入
写入后未读回目标值
也就是说，不要只显示“通信错误”，而要让用户知道是“写入失败”。
当前不必自行实现的部分
1. 不需要自己写 CRC 校验
Qt Modbus 已经负责：
CRC 计算
CRC 校验
RTU 帧解析
异常响应识别
自己再写一套容易和 Qt 的通信流程冲突。
2. 不需要自己测量 3.5T 帧间隔
3.5T 是 Modbus RTU 底层帧边界规则，Qt 串口和 Modbus 层负责处理即可。
当前业务代码只需要处理：
请求成功
请求超时
协议错误
读取失败
3. 不需要自己解析帧头、帧尾垃圾数据
除非现场经常出现：
线路严重干扰
串口收到大量乱码
设备协议不标准
Qt 无法判断具体原因
否则没有必要把原始串口字节全部接管过来分析。
可以作为增强项的部分
如果以后要提升现场调试能力，可以增加：
1. 保存 Qt 返回的 errorString()
2. 显示具体 Modbus 异常码
3. 记录请求区域、起始地址、数量和读写方向
4. 记录最近一次成功通信时间
5. 记录连续超时次数
6. 记录最近一次读失败地址
7. 区分“PLC 拒绝”与“线路超时”
8. 提供通信诊断日志
这些属于“诊断体验增强”，不是当前系统能否正常运行的基础功能。
结论
当前不建议为了“国际 Modbus 标准完整”而大改通信底层。
建议保持现在的分层：
Qt Modbus：
负责 RTU 帧、CRC、3.5T、底层协议
PlcCommunicationService：
负责异步读写、轮询、超时、状态和恢复
业务层：
负责首读资格、缓存有效性、真机运行安全和 UI 反馈
目前最值得补的是：
设备手册功能码和地址映射确认
Modbus 错误分类测试
写入失败和读回失败的清晰提示
通信诊断日志
而 CRC、3.5T、帧头帧尾这些，不需要在当前业务层重复实现。