大家有没有人觉得 MODBUS 不好用

只看该作者 · 2015-9-4 15:07

jing43 发表于 2015-9-4 14:57
INFO 内部有完整的数据帧，这种情况基本上是不存在的，同时又出现同步出错，那就更加难得了，你说是不是 ...

有某种应用上, 经常在数据段里出现完整的协议包, 就是当节点是包监听器时, 他的数据就是监听到的某类型包. 上位需要将其监听到的包数据上传.

只看该作者 · 2015-9-4 15:13

acguy 发表于 2015-9-4 15:04
理想的协议, 只要遵守这个协议, 即使某些节点是恶意节点, 也不影响其它设备的运行.

一般情况下INFO内部 ...

我们这个就是不连外网的，总线上所有节点应该不大于 128 个，这个不为网络安全做考虑的，运行于单片机上，以实现通信为目的，越简单越好。话说，485 总线上的，还没有人会考虑恶意节点这个问题吧？当恶意节点检测到读取某些信息时，在正常从机应答时直接驱动总线使总线数据错乱，然后发出遵守协议的恶意信息，这样不管什么协议都白搭吧？

只看该作者 · 2015-9-4 15:35

"当恶意节点检测到读取某些信息时，在正常从机应答时直接驱动总线使总线数据错乱，然后发出遵守协议的恶意信息"
这种行为遵循协议吗?

我指的是:
主机每次重复问: 张三活干得如何?
张三可以回答: 什么狗屎活, 没呢.

但是张三每次故意回答: 什么狗屎活, 没呢, 为什么不让李四去吃屎.
你不能说他错, 只能说张三这个设备设计很差.

李四刚上线, 前面没听到. 如果是Modbus RTU, 他要等大家都不说话一段时间后, 才开始听. 所以他听到开头, 主机是找张三说话的.

但是你的协议不是这样: 听到李四, 就以为是说给自已听的, 于是你的李四去吃屎了.

只看该作者 · 2015-9-4 15:37

所以设计严谨的协议, 包头包尾标志字节, 如果出现在包中间, 必须进行转义.

只看该作者 · 2015-9-4 15:46

acguy 发表于 2015-9-4 15:35
"当恶意节点检测到读取某些信息时，在正常从机应答时直接驱动总线使总线数据错乱，然后发出遵守协议的恶意 ...

你说得这么复杂，有点晕了。
我的意思是，如果有张三和李四在，你本想问张三：活干好了没有？
接下来的时间，应该由张三回答：还要20分钟就干好了。
但是李四不守规矩（恶意节点），在张三说话时，他也说，导致你没有听到，张三还以为自己完整回答了。
等张三的回答完全结束时（中途李四也在说话，所以你听不到有用信息），李四用张三的地址标签回答：活干好了。
结果，你问的问题得到了错误的答案：活干好了。

只看该作者 · 2015-9-4 15:50

acguy 发表于 2015-9-4 15:37
所以设计严谨的协议, 包头包尾标志字节, 如果出现在包中间, 必须进行转义.

进行转义，这会让数据结构变得复杂，像 JPEG 的压缩算法，里面就有用到转义，然后数据要筛一遍才能用，数据长度也增大了。

只看该作者 · 2015-9-4 15:57

本帖最后由 acguy 于 2015-9-4 15:59 编辑

jing43 发表于 2015-9-4 15:46
你说得这么复杂，有点晕了。
我的意思是，如果有张三和李四在，你本想问张三：活干好了没有？
接下来的时 ...

不遵守规矩, 就是不遵循协议. 这样所有的责任都是他承担了. 所有的费用就有地方算了.

怕就怕所有人都遵守协议, 协议有漏洞, 这样大家都没责任.

只看该作者 · 2015-9-4 16:10

acguy 发表于 2015-9-4 15:57
不遵守规矩, 就是不遵循协议. 这样所有的责任都是他承担了. 所有的费用就有地方算了.

怕就怕所有人都遵守 ...

如果要讨论安全问题，你这个就想得太简单了。
如果整个系统就不应该存在李四，他就是偷偷进来搞破坏的，就针对你发出的特定的问题进行侦听，然后伪装别人给你错误的答案。
所以，我们还是不要做那么多保护措施，简单够用就好。
你提到的，有某种应用上, 经常在数据段里出现完整的协议包, 就是当节点是包监听器时。这种情况，既然整个信息塞到了 INFO 里，那这肯定是一条约定的命令，那我们可以将这个数据包（INFO）中的包头和包尾换掉，接收方接到后还原。

只看该作者 · 2015-9-4 16:14

jing43 发表于 2015-9-4 16:10
如果要讨论安全问题，你这个就想得太简单了。
如果整个系统就不应该存在李四，他就是偷偷进来搞破坏的， ...

怎么说呢?
这样的设计是链路层与应用层耦合.

如果你的QQ告诉你, 消息中带有;字符的不能发, 因为以太网;当作包头字符, 你会不会很无语.

协议的设计往往是需要妥协的. 可能你觉得协议的完备性是可以被妥协的.

只看该作者 · 2015-9-4 16:21

acguy 发表于 2015-9-4 16:14
怎么说呢?
这样的设计是链路层与应用层耦合.

有一点妥协，这个我是认可的。我之前就说了，这个协议，出错的可能是有的，但不致于进入死锁。
还有，我这个协议加入 CRC 后，就比 MODBUS 有了更多的约束，显然可靠性不比它低。
当有敏感数据需要传送时，就加 CRC。

只看该作者 · 2015-9-8 17:04

没有包头包尾这个问题最让人头疼了，

只看该作者 · 2016-9-2 15:07

只看该作者 · 2017-8-24 16:21

你这好快的速度

只看该作者 · 2018-10-22 17:06

其实modbus最大的好处是通用，无数的设备;上位机都兼容。

只看该作者 · 2018-10-27 12:42

同意 acguy 的看法，加帧头帧尾的意义不大，只增加不出错概率，但做不到绝对即无意义。
区分帧的东东如果和数据无法区分，那么数据一定要转义，然而转义太恶心，数据搞不好大一倍，转换也很低效。
我的另一个思路，使用 break 来做区分，break 是连续超过 10 个 bit 数据都为低电平，常用于 Linux 系统的魔法键，不会和数据冲突。
但 break 无法像普通数据一样保存在 ram 中，它更像是一个事件，所以使用空闲事件也是完全没有区别的，只是要求数据之间不能有超过一个字节的空缺。
然而使用空闲事件又回到 modbus 的方式，只是把长度改为一个字节，这样 STM32 这些 MCU 都方便通过空闲中断来区分帧。

最后，建议大家看一下 CDBUS 和其上的 CDNET, 支持主动上报、出错重传等特性，最重要是简单，协议本身没有过多限制。

只看该作者 · 2018-10-27 13:01

jing43 发表于 2015-9-4 13:57
不会一直等的，一包数据在发送时，中间不允许停顿大于 10ms，下位在收到了部分的数据包时，如果总线上持 ...

正常情况下收到的第 1 个字节就是包的首字节，不加包头，仅通过长度和校验就可以保证数据正确性。

当检测到错误，清除所有缓冲，等待接收新的数据更加高效和稳健，完全没有必要加帧头、逐个字节在缓冲中扫描帧头。帧尾就更加没有必要。

只看该作者 · 2018-12-27 11:20

dukedz 发表于 2018-10-27 13:01
正常情况下收到的第 1 个字节就是包的首字节，不加包头，仅通过长度和校验就可以保证数据正确性。

当检测 ...

正解，楼主明显没看过modbus协议，大于19200波特率时，帧与帧间隔1750us。modbus RTU模式最小帧是4字节，最大帧是256字节，再通过CRC校验即可。两个条件不通过，丢弃数据重新接收。

只看该作者 · 2018-12-27 15:14

大于19200，帧与帧间隔是1750us

只看该作者 · 2018-12-31 11:37

modbus 有多组协议供选择，对速度有要求的可用MODBUD TCP协议，一定要用串口的，也可以用串口服务器，自己建系统的可以随便写个协议也可以，MODBUS更多是考虑系统的兼容性，做芯片级的就不是它考虑的范围。

只看该作者 · 2019-1-8 11:47

有标准协议不用???

大家有没有人觉得 MODBUS 不好用

技术奇才奖章

伴坛终老

技术新星奖章

经常做客

社区建设奖章

甘甜之泉水

常驻人口

技术高手奖章

缘定三生