引用7楼详细内容：

        实际监控发现，在MSG指令不出错的情况下，1000ms等待时间下延迟值很高，而100ms下会好很多。

我查了手册，从站无反应，主站会连续发三次，1000ms下三次大约就是3s，在这3s时间内，从站做出了响应,主站就不会报警。。但是实际操作会感到延迟。。。

        100ms下也不报警，甚至10ms报警的次数都很少，响应应该是没有问题，我就在想轮询的时候我指令是逐条发送，不可能会有别的通信请求还没执行玩的情况吧，感觉解释不通

引用5楼详细内容：

你不出错绝对这个超时影响不到你。你想想是不是？我上面说了，一定不要出错。查查什么回事出错。

115200我感觉只比38400快了一倍（这只是我当时试验的环境），但是危险性却大了很多（出错）。

一出错啊，很多事情你都不知道是不是当前问题造成的了，因为淹没了。你怎么继续查以下的事情？

一个事情你明知道掩盖真相的30%那么有另一个事情掩盖了真相的5%，那么你将发现不了。

这回我猜，你的从站反应有点慢，它刚向你回复了信息没有那么快的反应来得及听你下一道信息。从而错过了对你的信息的反应。所以plc报告从站没反应，然后再次发送。

这只是我猜的啊。是否驱动器有这个默认的延时时间设定？

引用详细内容：

        季侠好，按照您的指导。。对轮询流程做了优化  读1》写1》读2》写2》读3》写3 ,其中写任务做请求标志，无写任务直接跳转下一步，然后系统通讯比特率选择支持的最高波特率115200，实测按钮按下电机反应大约2秒钟。。。

        然后我突发奇想改了系统的“参数“超时”(Timeout”，由原先的1000ms典型值，改为100ms，效果实测基本感觉不到延迟了？

       因此在这有个问题问季侠，是超时参数影响了系统的通讯速率吗？