Modbus通讯的运行逻辑：

modbus通讯的工作方式是请求/应答，每次通讯都是主站先发送指令，可以是广播或者单播。从站响应指令并按要求应答或报告异常。主站不发送请求信息时，从站不会自己发出数据，从站与从站之间无法直接通信。modbus通讯工作模式是一主多从，各个从站需要分配各自的从机地址。modbus通讯协议定义了PDU协议数据单元 (Protocol Data Unit)，为了适应多种传输模式，又在PDU前后增加了必要的前缀（地址域、TCP报文头等）和后缀（CRC差错校验）共同形成了ADU应用数据单元(Application Data Unit)。主站发送含从机地址、功能码、数据请求的报文给从站。从站根据报文内容进行对应操作后，将响应报文反馈给主站。

Modbus通讯的异常工作情况怎么解决？

如果从站发现主站发送来的报文发生与请求功能有关的差错，响应报文的功能码位置会包括一个异常码。Modbus 通讯最常用的通信介质（虽然Modbus也支持TCP/IP和各种现场总线），但绝大多数现场问题都出在这几件事上。

接线，必须用屏蔽双绞线，不要用普通电源线或者电话线。双绞的目的是抵消电磁干扰，屏蔽的目的是阻挡高频噪声。护套上印有‘RS485专用’字样的线虽然贵一点，但省下来的调试时间绝对划算。二、接地，屏蔽层必须在PLC柜侧单点接地（也就是一端接地，另一端浮空），绝对不能在两端都接。两端接地会形成地环路，反而把干扰引入总线。更不要不接地。

第三、终端电阻，在总线的两个最远端并联120欧电阻，匹配线路特性阻抗，消除信号反射。注意是最远端两端各一个，不是在每个设备上都加。第四，拓扑。RS485必须用总线型拓扑——从一个设备串到下一个设备，不允许星形或者树形分支。如果现场走线确实需要分支，分支线长度不要超过1米。

物理层没问题、程序写得也对，还是通讯不上？按这个顺序排查，基本跑不掉。

第一步：确认硬件接线—AB线有没有接反？A(A-)接A(A-)，B(B+)接B(B+)。这一步用万用表量就能确认。

第二步：确认从站地址—从站面板上设的地址和程序里写的是不是一个数？地址有没有被不小心改成重复的？

第三步：确认波特率和校验参数—9600 8N1？还是19200 8E1？两边必须完全一致。少查一次校验位就能浪费半天。

第四步：看串口报文—用串口工具挂在总线上，主站有没有发出请求帧？请求帧的CRC对不对？从站有没有回复？回复的是正常数据还是异常码？

第五步：测试最小系统—把从站单独接到PLC旁边，用最短的线直连，排除线路太长和干扰的问题。最小系统能通说明总线或布线有问题。

第六步：验证从站本身—用一个串口调试工具直接模拟主站发报文，看从站能不能正常回复。能把从站打通，说明从站是好的。六个步骤走完还不行？大概率是设备本身有问题。这种情况我只遇到过两次：一次是一个国产温控表的Modbus协议实现有bug，一次是一个变送器的RS485芯片出厂就是坏的。

做自动化这行，通信调试是躲不过去的坎。从最基础的RS485接线，到Modbus报文的解析，再到PLC程序的具体实现，每一层都有它的坑。但把这几层搞清楚了，90%的现场通信问题你都能独立解决。记住这几条金句：最贵的线是便宜的那根。屏蔽层不接地等于没屏蔽。不看报文调通信约等于盲人摸象。先测最小系统法，别急着换设备。我见过太多工程师在通信问题上浪费好几天甚至一两周的时间，归根结底是没有把问题拆解清楚。下次现场通信不通的时候，别急，按这六步走，一步步排除，问题自然浮出水面。如果你有更奇葩的通信排故经历，欢迎来评论区分享。

你在现场调Modbus通信遇到过什么奇葩问题？是接线还是地址还是协议？如果遇到现场问题欢迎补充交流，有Modbus通讯问题咨询或帮助就随时联系我的。