JZGKCHINA
工控技术分享平台
前 言：
组态软件和现场的Modbus设备通信缓慢、丢包，这个是大家多多少少都会遇到的问题。产生问题的原因千奇百怪，今天和大家分享一个前些天遇到的挺有意思的一次故障排查。
本文约2700字，预计阅读时间15分钟。
A． 故障现象：
有个朋友在厂里做FMCS厂务监控系统的项目，需要对YORK空调面板上的一些参数进行采集和设置，上位机软件采用Intouch 2014R2SP1。现场有百余个YORK的面板，面板上带有RS-485 Modbus RTU协议接口，通过MOXA的MB3180网关分为多路把Modbus RTU转为Modbus TCP协议供上位机采集。现场每个MB3180下大约有20个面板需要采集。网络拓扑示意如下：
在调试中，用户发现在Intouch上虽然可以读取到所有面板上的数据，也能通过Intouch修改面板上的设定参数，但是数据更新非常缓慢，一般都在20秒以上，而且有时通过Intouch下发的控制命令会有丢失。用户现场排查过物理链路，均采用120欧姆特征阻抗屏蔽双绞通信电缆，RS485网络没有星型节点，网络两端有120欧姆终端电阻。
B． 思路：
在电话里听到朋友描述时，感觉上像是干扰造成的485通信故障，然而到现场后，发现朋友已经可以在办公室复现这个问题。他使用1个MB3180连接了4台面板，面板Modbus ID从1到4，9600波特率，ODD/8/1，在办公室里使用笔记本上的Intouch工程仍可重现通信缓慢的问题。这是一个非常好的消息，意味着我们不用再去现场检查物理线路的问题。
于是，笔者先找他要了这个面板的手册，下面是大致要采集和控制的数据内容。（当天时间较紧，忘记拍照了，而且也没找到这个电子版手册，下图是从别的渠道获取的地址数据。）
由上图可知，获取的数据比较简单，但是像TempSP,Fan_Mode,Status,Mode这些参数都是在保持型寄存器中，上位机会进行读/写操作。所以，笔者有了第一个猜想：
1.
会不会是上位机写入的数据超过了这些参数的范围？
在以往的工程经验中，见过很多由于Modbus主站向下写入的数据超过从站变量数据范围导致的通信问题。比如，向某变频器发送整数7表示启动，发送15表示停止，如果你发了一个16，但变频器里没有对应的动作，如果变频器协议机制比较完善，它会返回主站一个功能码为0x83的异常响应报文，主站也就知道是自己发的数据超出了从站该变量的范围。
但是，如果从站设备的软件编写不够严谨或者存在问题，它有可能不会回复主站。由于Modbus在大多数情况下是主站对配置数据逐条轮询，并设有超时时间和重试次数，如果对某一参数写入失败且设备没有返回异常响应报文，主站会等到超时时间后再重发本次数据（即重试Retry），如果重试几次之后仍未收到正确的从站响应报文，主站才会跳过执行下一条或者放弃该从站转到另一从站ID进行数据轮询。在超时等待和重试中，会浪费大量时间。再者，极其个别的设备，如果写入了超过范围的数据，可能会造成设备通信程序甚至整机的死机或重启。
判断通信缓慢是不是由这个造成的也很简单，把软体里的写入操作全部屏蔽掉，看看还有没有这个问题。如果没有了，仔细研究从站手册，看看哪些参数会有此问题。如果看不出来，则把屏蔽掉的写入操作逐条恢复，直到发现问题再仔细甄别数据范围。
不过，在屏蔽了对上述所有变量的写入操作后，通信仍未改善，看来不是这里的问题，于是笔者有了第二个猜想:
2.
会不会是上位机软件组包导致的？
在组态软件中，为了提高读写效率，一般会对数据进行组包。比如在本例中，当读取以下5个数据时，如果组态软件的组包长度比较大，比如100，那么组态软件一般会使用03功能码直接读取从40003开始的连续10个字来获取数据。如果组包长度设的比较小，比如设成5，那么组态软件会分成2次03功能码操作分别读取从40003开始的连续4个字和从40012开始的1个字。
设置较大的组包数值可以让软件减少一个轮询周期内的会话次数,提高通信效率和速度。但可能会有两个潜在的问题:一是某些设备因为软件限制不能处理超过一定长度的Modbus报文，比如设备可能最大只能处理数据域不超过10个字的报文，但是你发了一个读连续50个字的报文，设备可能会不回复或者出各种问题。二是如果在连续数据包中，比如上面从40003开始到40012这10个地址，在从站设备中只存在表上列出的5个，中间40007-40011这些不存在，则设备响应也可能会有问题。
这种问题判断很简单，使用Modscan或者Modbus Poll这类工具软件，尝试读取连续数据看看有没有问题就行。如果发现是此问题，可以缩小组态软件的组包长度进行解决。
可是，在用Modscan做了几组对上面的不同寄存器进行的读写测试后，发现数据读写都很正常，一点问题都没有。但是我们发现了一些有意思的现象，在只连接Modscan的时候，4个实验设备读写完全正常，一次无效应答都不存在。可是如果换成Intouch, 通信立刻就出现了问题。有啥区别? ModScan轮询速度慢,是1秒钟才读取一次数据，可Intouch快了很多。于是第三个猜想涌上心头：
3.
会不会是报文间隔时间太小导致的？
“在之前的工作中，笔者遇到过一些从站设备对通信的处理能力比较弱，或者是程序编制不完善，当485总线繁忙时，由于其处理器计算能力或者程序编制不合理，出现较总线不繁忙时通讯响应迟缓，设备动作卡顿，通讯中断，甚至设备重启等情况。仅在今年，笔者就遇到过一个特气集控器，主站03报文询问过快之后设备显示器停滞不刷新数据；某家电一线品牌的中央空调集控器，速度快后不定时通讯中断，必须重启设备才可恢复;某模拟量模块，速度快后模拟量读数失真；某压力表，速度快后直接重启。
想到这里，笔者在PLC主站的轮询逻辑中增加了100ms的延迟时间，即当主站收到从站的正确响应后，等100ms之后再发送下一条请求。验证，问题得到解决。”（见作者在剑指工控之前发的文章《流量积算仪Modbus通信的一些小问题》）。
考虑到上述情况，笔者拿了一个随身带的HORNER XLE控制器做了个测试。在XLE里配置了4台温控器后，如果使用默认的Slave Speed Fast，XLE会在收到从站设备响应后只等待3½个字符时间后，就会进行下一次数据请求，此时监控XLE的通信状态，会发现从站出现了很多无效报文返回，数据交互异常缓慢，和Intouch故障现象相同；在把XLE的响应速度设为Slow后，XLE会在收到报文后等待100ms才发送下一组报文，此时通信状态就完全正常了。
在基本确认问题后，剩下的就是如何在Intouch的轮询中增加这个延迟时间。笔者对Intouch不是专家，在查询手册和咨询了几位朋友后，也没在Intouch中找到在哪里能增加这个报文间隔时间，所以就只能把目光盯向了Intouch和设备之间的MB3180网关。
在查询了网关的说明书后,发现其有如下参数-帧间延迟(Inter-frame Delay),其说明如下: In Modbus RTU slave mode, user can determine the time-delay to transmit the data frame received from the slave device to the upstream. The MGate MB3000 will automatically determine the time interval if it is set to 0. 即在RTU模式下, 用户可以修改此参数设定MB3180网关转发从站响应报文的延迟时间.默认情况下该参数为0,这里我们把它修改成100. 然后测试,问题得到解决。
C. 后记:
现场通信缓慢是个非常令人头疼的问题, 除了软件因素,硬件问题如终端电阻不接/接错位置, 屏蔽层触碰数据线, 通信接头接触不良等都可能造成类似的故障现象。不过,再复杂的问题,只要有心,一步一步假设、试验、排除, 终归是可以解决的。
作 者 简 介
张伟宁
就职于浩纳尔（天津）自动化科技有限公司，负责美国HORNER一体化控制产品的应用和支持工作，对HORNER全系产品有深入了解。
