故事作者:万泉河

最近创作

看看TA的故事

【万泉河】MODBUS并行通讯实现

已锁定

万泉河

  • 帖子

    10885
  • 精华

    132
  • 被关注

    893

论坛等级:至圣

注册时间:2003-06-06

钻石 钻石 如何晋级?

【万泉河】MODBUS并行通讯实现

2011

0

2019-10-14 19:40:26

在工业控制领域, MODBUS通讯永远是个热点。

 

先看几篇文章:


【万泉河】MODBUS轮询中的坑

 



基于任务轮询机制的Modbus-RTU主站通讯程序的实现



详解S7-1500PLC 实现 Modbus-RTU 通信



Modbus RTU 通讯之西门子Smart 200




 

这是我今年初写的,和ZANE在2年前写的,以及最近从朋友圈连续看到的技术文章。



每一位技术编程的工作者,做项目时只要遇到有MODBUS通讯,都要费一些脑筋。像我和zane,玩自动化都分别已经玩了二十年了,还时常要挂在口边。还时不时的要与人交流。可想而知,这玩意有多重要。

 

同时也相当令人厌烦。

 

一个底层通讯的问题,不管你搞多久, 多懂,多熟练,每次遇到新应用,都要从头搞起。即便有过去做好的代码可以使用,但每次仍然都要把整个逻辑都捋一边,每次都要重新编写,调试。

 

怎能不烦?

 

相比之下,PROFIBUS DP通讯就没有这样的困扰。比如DP主站带DP从站的通讯,从站的数据直接作为I/O变量进入系统,程序中直接对这些I/O进行读写操作即可。所谓的通讯,根本没有什么工作量。因而也谈不上有什么技术含量。

 

而即便有,比如过去CP342-5可以做主站,我也只是做过测试,用DP_READ/DP_WRITE两个通讯块分别调用一下,即可实现了通讯。然后就把这个成果扔一边去了。以后有项目需要这样的应用,就已经有了技术储备。当时做实验的程序甚至都不需要保留。反正大概记住了,就是2个块,调用一下。就够了。

 

好多年没玩CP342-5的DP通讯,前年偶然一次机会别人的项目中遇到,发现,CP模块上带的从站,也一样可以映射为I/O点,可以直接使用了。那么,这一块的技术储备,又没有必要了。因为没有技术含量了。

 

没有技术含量,也体现在,相关话题已经无人关心,也无人针对此话题写些技术文章了。而MODBUS通讯的文章,你无论啥时候,从网上搜索,都能搜来一大片。

 

也正常的。大多数人做完一个项目,要总结一下经验的话,会发现,整个项目中最有难度,最有心得的还是其中的MODBUS通讯,也就这个值得写一些。不管水平高低,应用程度如何,只要实现了,总算实现了通讯,就是一件值得庆贺的事,就值得一述。但仍然摆脱不了,下个项目遇到,还要再做一次。

 

究其原因,还是因为MODBUS通讯采用的轮训机制。

 

其实各种串行通讯,PROFIBUS, MODBUS, DIVENET,本质上也都是轮询的。但那些厂家都把轮询机制做到操作系统里面了。而施耐德自己的PLC,在调用MODBUS站的时候,也内部实现了轮询,呈现给用户的也直接是I/O地址。一些网关产品,如DP/MODBUS的网关,其核心也是帮你实现了轮询,导致可以把MODBUS的数据直接映射到DP/PN从站,最终直接体现为I/O。

 

但唯独,我们用非施耐德的PLC做MODBUS通讯的时候,要用轮询机制。即便系统给做了通讯函数,也只是针对1次数据通信的小应答循环。哪怕只有一个站,只要你读和写的功能都需要,那就需要轮询。不可以两个指令同时运行。

 

轮询机制导致了通讯功能块不能完整封装,不能项目之间简单复用。因为每个项目站点数目不一样,需要采集的数据类型也不一样。

 

这是标准化编程的大忌,也一直是我心头之大患。



 


一直想有没有办法可以解决它。

 

能不能用并行的方法实现需要轮询的通讯功能?

 

我的理想目标是:做一个完全封装的标准的库函数,系统中,有一个站的数据要采集,那么库函数调用1次,有2个站,调用2次,有10个站,调用10次。站数不受限制,数据也不受限制。只要调用足够的次数,并在管脚中把需要的数据地址信息输入,输出存放的地址输入,就OK了!

 

甚至,如果我可以把读来的DI数据直接放到I映像区,相当于

40001--à IW0

也可以仅仅通过调用一次函数来实现。项目的应用程序,直接和DP/PN从站数据一般,直接使用符号表I/O,就好了!

 

 

至于轮询、优先级、掉站、超时那些破事,块的进程之间互相协调,函数里面自己调度实现去吧!外面应用的时候不再管了。不再烦了。

 

这个样子:


 

这是我设计的接口模式,也已经做了一些编程工作,还没有完全实现。

 

说实话,难度相当大,很烧脑。这段时间开始动手做了,实现的方法计划了好几种方案,在各种方案之间犹豫,抉择,废了不少脑筋,连续几个晚上,睡觉时老想这个事,想到睡不着。以为是在做梦,但一翻身就又醒了。

 

现在最新的进展,有眉目了!确信一定可以实现。程序已经写完,只剩下调试工作。调试虽然会有些难度,但已经不存在不可逾越的鸿沟了。

 

所以提前把动向告诉大家。

 

有兴趣的同学,可以按我的思路,也尝试自己做一下,看看能不能实现。能不能比我做的更好,更简洁。也更早实现。

 

而我也打算在这个库函数完成后,作为标准产品出售。以往推行标准化编程方法的时候,有人理解为我在售卖库函数。我一直明确告诉大家,我推广的是实现方法,不是库。甚至我都没自己写过底层库函数。很多库函数都是借用的,最多是拿来改造一下。

 

现在开始,我也要有自己的库函数产品了。

 

源代码不会提供,为技术保护,甚至会提供绑定到卡号的专用块。但同时也会提供服务和质量保证。

 

有兴趣购买的可以提前报名咨询,共同探讨销售策略。

 

现在起步,是在PORTAL V15下实现,只针对MODBUS RTU。搞定后,会争取在SMART 200中也如法炮制实现。另外,MODBUS TCP通讯,也一样存在轮询机制,将来也要实现它们。

 

我希望这是我针对MODBUS写的最后一篇技术文章。

 

(以后就只推广,不技术了。遇到技术咨询,直接抛一个完全封装的块即可。 )

 

也希望终止MODBUS通讯这个困扰业界多年的难题。


【万泉河】MODBUS并行通讯实现 已锁定
编辑推荐: 关闭

请填写推广理由:

本版热门话题

网友专栏

共有3227条技术帖

相关推荐

热门标签

相关帖子推荐

guzhang

恭喜,你发布的帖子

评为精华帖!

快扫描右侧二维码晒一晒吧!

再发帖或跟帖交流2条,就能晋升VIP啦!开启更多专属权限!

top
您收到0封站内信:
×
×
信息提示
很抱歉!您所访问的页面不存在,或网址发生了变化,请稍后再试。