现场Modbus RTU硬件响应延迟不正确

Question

我们在该领域有硬件，可以使用RS-485/Modbus RTU(1200，9600，一直到115200）以各种不同的波特率进行通信。

在我们的设备上运行的固件有一个小错误，其中Modbus RTU响应延迟是固定的，并根据运行在115200波特计算。这个问题一直没有被注意到，直到最近我们的一个客户开始使用1200波特率。看来115200的响应延迟对9600以下的所有事情都足够了。

但是，在1200波特率下，响应包的第一个字节被遗漏了（我假设是由于在1200波特率下从发送切换到接收所需的时间）。如果请求的是一个大数据包，情况就可以了（因为设备将数据包放在一起所花费的时间弥补了延迟的不足），尽管大多数数据包都被破坏了。

不幸的是，升级这些设备上的固件以使用正确的/更长的响应延迟并不是一个选项。有没有人有任何想法，关于我们如何可以取回完整的包在1200波特？（响应延迟不正确，当前导致错过1个字节）

我唯一能想到的想法是，每次请求都从软件中请求过多的寄存器，从而导致延迟增加。

Answer 1

如果我正确理解你的问题，我曾经有过同样的问题。

我被叫去解决一个非常不可靠的Modbus链接的故障，这个链接经常出现故障，但在很短的一段时间内，它都正常工作。

事实证明，从服务器上的固件有一个问题：它在收到查询的停止位后立即触发其Modbus答案。于是部分答案在主人来得及解脱大巴之前就传了出来（图中黄色箭头）。

当时，我们对更新固件的前景并不满意，所以我们首先探索了其他选择。我们想出的最好的办法是在主控器（施耐德电气的PLC）上设置了一个设置，允许调整主控器在停止位后断言总线的时间。

手册中是这样定义的：

我隐约记得我们能够改善这种情况，但有一个看门狗触发一个警报的地方，每次有一个错误，所以这个解决方案被认为是不可接受的，我们必须更新固件。

不知何故与你的问题有关，我曾经测量过使用硬件方向控制和软件解决方案释放总线所需的时间。你可以在这里看到一些细节。如果更新固件对你来说是不可能的，我想摆弄收发器也不会是一个选择...在这个问题的最后，我连接了一个电路来自动切换RS485链路的方向控制线。如果你的主人不能更快地切换，这可能是一个（不可否认的）解决方案。