Modbus RTU有完全开放和经济的特点，但显然不是一种完全实时的协议，需要用户程序来驱动。

但是感觉Modbus速率在S7-1200下实在是太慢了，作为主站100ms才能更新一次，如果使用嵌入式系统就好很多，测量方法是通过1200内置的trace功能，

而且Modbus超时时间最短为1s,而好多嵌入式系统超时时间是100ms，请问大家遇到过吗？

我监测的是modbus master的背景DB （Modbus_Master [FB641] 3.2）

按照这个速率，读写一次相关Modbus从站就需要200ms左右了 有些相对精确的控制就需要换成别的通讯方式了。

波特率我已经调整到最高了，这个参数和波特率似乎没有太大关系。

大家Modbus轮询周期一般是多久？

更新：

有网友提示done 和req等待时间太长，我之前确实加了延时，因为考虑到周期采集。更新无等待一个截图。

模块是CM 1241 (RS422/485) S7-1200 中

截图是57600,No parity, 8 bits, 1 stop。

只有一个从站 直连 因从站配置无终端电阻困难，DP总线头终端电阻未启用。

为保证测试正确，使用了计算机模拟Modbus Slave（Modbus Slave 7.3.1 ）效果相似 相同

通信速度的快慢与下列因素有关

1） 通信波特率的高低

2） 通信数据的的多少

3） 扫描周期的长短，因为通信是异步执行的，实际通信完成到查询到DONE标志位的时间是有一定间隔的

4） 通信的逻辑控制

5） 从站的响应速度

6） 线路上的干扰

通讯正常前提下：主要看从站数量、通讯数据长度。

通讯波特率我之前还真的单独测试过，比如用9600与19.2K比较，并不能够理解为通讯速率快一半的概念，频率越高通讯数据交换越快，但不是与通讯频率呈线性关系的。

看trace图，人家库运行没任何问题啊。

1、你的Req并不是Done的下一个周期触发？或者主程序周期过长？反正趋势图很明显的看到主要就是这两个原因造成的通讯事务过慢。

2、根据串口通讯波特率与Modbus RTU数据帧计算，9600波特率下，100ms是否读/写超过35个保持寄存器？ 120ms是否读/写超过40个保持寄存器？320ms是否读/写超过120个保持寄存器？从Busy可以看出很长的时间都是消耗在通讯事务上了，要么是操作寄存器太多，要么是波特率太低。

最后，感觉都是你的问题啊。。。。

感谢回复

回应1.

更新了一下截图，done结束后立即req。

只调用Modbus程序，不调用用户程序了。

之前有延时是因为既然时间差这么多，那我相对固定一个周期采集把。

只有一个从站。

回应2.

读取Modbus 10个words，这个应该不算数据量大吧？

当然为了保证测试无干扰，用PC软件模拟主站（Modbus Slave）效果相同。

如果谁手头有1500 的模块，可否一起测试一下1500的Modbus RTU速率？

感谢回复

现场不具备两个485 通讯的条件，等有空回到办公室可以测试。

用计算机测试的时候计算机是win7. USB转串口用的还是不错的，工控机也自带串口，我暂时未测试。

USB转串口同样曾用于与嵌入式设备直接通讯，速率远低于50ms。

今天测量了Smart200与Modbus Slave 7.1.3、单片机 做9600通讯测试读取6个保持寄存器、写3个保持寄存器。

从测试中可以看出，用Modbus Slave模拟从站与PLC通讯，PLC每秒能够进行13～14次通讯；

而与实际的单片机做通讯，PLC每秒能够进行22～23次通讯；

从这可以看出来，Win7系统的串口通讯Api是做不到每1ms中断接收处理数据的。所以，PLC与PC通讯的时间是不可能达到modbus rtu协议中定义的最小间隔时间的。

这是PLC与PC仿真的通讯次数，每秒大概13～14次：

这是PLC与单片机的通讯次数，每秒大概22～23次: