plc编程培训之通信与诊断

通信与诊断——黑盒跑通就算完，故障时两眼一抹黑

错误现象
两台S7-1200之间用Put/Get通信，配置完连接后测试能传数据，项目就封包发货了。半年后客户报修：设备随机丢包，有时数据几个小时不更新。现场工程师打开程序，没有通信状态监控，没有故障代码输出，不知道是网络闪断还是CPU停机。

错误后果

• 故障定位耗时占整个维修时间的80%。

• 非专业人员反复断电重启，损坏设备。

• 客户对品牌技术能力产生质疑。

根本原因

• 通信编程只关注数据收发，不关注通信质量。

• 不知道系统数据类型（如TCON、TSEND、TRCV）的状态字含义。

• 缺乏工业网络基础知识，混淆TCP、PROFINET、ISO-on-TCP。

避免方法

1. 强制加入通信状态监控
   使用TCON、TSEND、TRCV指令时，必须将状态输出字（STATUS/ERROR）存入DB，并在HMI上显示。一旦通信失败，立即输出“通信故障_线体A”而非“数据为0”。

2. 利用系统诊断缓冲区
   编程习惯：发生严重故障时，触发RDREC读取CPU诊断缓冲区，将近十条故障存入归档DB。维护人员可通过HMI查看PLC历史停机原因。

3. 定期心跳检测
   主从站约定一个DWord作为心跳计数器，从站每周期加1，主站监控。若心跳停止超时，主动报警并进入安全状态。

4. 标准化通信模板
   不要每次重写通信程序。建立封装好的FB_Client、FB_Server，参数化IP地址、数据长度、超时时间。确保每次调用都包含错误处理逻辑。

小结
通信程序写完只完成了一半，另一半是让故障“可见”。