早在2008年左右,我就在产品中使用Modbus协议与其它设备进行通信。记得第一款是智能马达保护器,其作为Modbus从,与Modbus主设备进行通信。这么多年来,一直都没有使用开源的Modbus协议代码,而在在不断在自己编写的Modbus协议代码上进行优化,发现问题并解决。 自己写的代码用起来比较得心应用可以针对不同的平台进行优化,将处理器的性能发挥到极致。在此期间,也踩过一些坑,现在做一些总结: 串口数据接收完之后,到通过IO口重新使用接收的时间间隔。
发送完成之后切换接收的延时时间 如上图所示的Td,按照Modbus协议的规定,接收完数据之后,必须要间隔3.5个字符对应的时间才能发送。 如果是9600bps的波特率,8位数据位,1位起始位,1位停止位,无奇偶校验位,则1个字符为10个 bit,对应1.04ms,3.5个字符对应3.5ms。 考虑到总线上的电容对传输延时的影响,建议在发送完数据1.7个字符的时间之后再使能接收。对于这个时间,可能会犯一些错误,比如:
-
在发送完最后一个字节的发送完成中断中,直接将控制IO口使能485芯片的接收。殊不知,由于电容导致的信号延时,串口数据还没有完全发送到总线,485芯片就被置为接收状态,导致最后几个bit的数据误码;
-
没有正确理解发送完成中断以及发送缓存器空中断之间的差别;
-
发送完成中断一般是指串口数据已经从移位寄存器从端口送出。但是并不说明已经被送到RS485总线。从MCU的IO口到RS485总线还需要考虑隔离光耦、电容、RS485芯片的延时;
-
发送缓存器空中断是指腾出了缓存的位置,可以缓存数据。此时,上一个数据可能还在移位寄存器中被紧张有序地按位移出到IO口,此时把RS485芯片置为接收。还正在移位的数据就嗝屁了。
因此
-
一定要搞清楚选用的中断是发送完成中断还是缓存器空的中断;
-
在发送中断中,不能立即切为接收,应当延时一段时间,我现在的做法是不管三七二十一,在发送中断中,如果判断为最后一个byte,则延时1.7ms将RS485设置为接收;
-
不应该启动定时器进行延时,定时器资源很宝贵,应该在100us左右的定时器中断中,通过变量计数来进行1.7ms左右的延时;
MODBUS从设备多少时间会应答
Modbus是问答式的通信,主设备发送完数据之后,从设备会做出响应。按照Modbus协议规定,从设备3.5个字符时间之后做出响应都是合法的。不同的传感器应答响应时间各不相同。 有些差的传感器可能到几十ms才响应,有些3.5ms左右就立即响应了。 有些甚至没有按照Modbus的协议出牌,还没有到3.5ms左右的时间就响应了。 这就要求主设备在将RS485接收使能之后,立即进行接收状态。 如果是用串口中断进行接收,则应该注意在主程序中是否有关中断的操作,关中断的操作是否影响接收。 每一个串口数据之间的时间间隔
Modbus根据数据之间的时间间隔来判断一桢消息的结束,需要保证一桢消息内的前后数据之间的间隔不超过3.5个字符。 而数据一般在发送中断中发送,有些人为了保证数据完整性,保证数据访问的互斥,很喜欢关中断来保护现场。这种做法一不小心就会使发送两个数据的间隔超过3.5个字符。 特别是当波特率比较高时,更容易出现这种情况。比如,当波特率为38400时,3.5 个字符仅为850us左右,在发送串口数据的时间内,中断关闭850us,Modbus通信就嗝屁了。 如果MCU支持DMA,建议使用DMA+定时器进行数据收发。 作为Modbus从设备时,收到数据之后,多少时间应答
按照Modbus协议要求,3.5个字符之后就可以应答。有些Modbus主设备可以是为了保证实时性,对这个应答时间要求比较苛刻。比如我们前一段时间跟西门子的工控屏对接时,就碰到过这样的问题,总线的波特率为19200bps,我们的设备在收到西门子的命令之后大概在5ms左右做出了应答。但是西门子工控屏却判为错误。之后,我们将应答时间缩短到2ms左右,与西门子的通信才变得正常。 建议在3.5个字符之后,立即应答。 来源:头条号-IT自动化交流
原文链接:https://www.toutiao.com/i6894161680406675981/
免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!