回复:不使用UDT的设备FB封装---ModbusRTU通信的温控器的例子

已锁定

万泉河

  • 帖子

    10900
  • 精华

    132
  • 被关注

    1009

论坛等级:至圣

注册时间:2003-06-06

钻石 钻石 如何晋级?

发布于 2020-07-24 09:35:37

18楼

展开查看
以下是引用Zane在2020-07-23 00:26:14的发言 >16楼

      本来想专门写篇文章来说明UDT的使用,因为发展到现在,对IO的直接访问也可以使用UDT了,我想今后的博途版本还会赋予UDT更多的灵活性与应用场景的,今天先简单的说一下。


主要的依据是出自于手册《 Programming Styleguide for S7-1200/1500 》 的第3.6.4节与第3.6.5节


在编程中使用结构化数据已然成为博途编程的一种大的趋势,这一点是毋庸置疑的。


结构化数据在博途中存在两种形式,一种是STRUCT(结构变量),另一种是UDT(PLC数据类型),显然后者的层面要远高于前者。STRUCT是无法全局存在的,但UDT可以,基于此两者之间的应用就产生了很大的差别。


首先,STRUCT每一个FB/FC/DB中的使用都是新建,虽然可以拷贝,但仍旧属于新建范畴,而UDT是直接的引用;

其次,如果多个FB/FC/DB使用了相同定义的STRUCT,一旦发生修改的需求,就需要逐一到调用的FB/FC/DB中去修改,大项目中调用众多,容易发生遗漏;而UDT则是集中更改,全局自动更新。


结构化数据的使用,一定会涉及到数据的传递,既然是数据传递,就一定有数据传递的双方,也即是说同样的结构数据一定会被使用两次以上;如果是STRUCT则使用多少次,我就要定义多少次,同样发生修改的话,就需要修改多少次;而 UDT则只要定义一次,多次的引用即可,修改也是只要修改一次,自动全部更新。


第三,UDT可以添加到全局库中,实现项目间的重复使用,STRUCT则无法实现;当然,有人会说FB/FC/DB都是可以添加到全局库的,STRUCT在这些块里面,就不用再去操心了,但这只是应用的一个方面而已,实际应用还存在很多其他的可能性,比如功能完全不同的多个块,共同需要使用同一个结构数据。

所以我说,UDT解决的是一个结构变量的重复定义的问题,同时也解决了重复修改的问题,其使用效率要远高于STRUCT




观点我全部都支持。 


其中前两条,论证了STRUCT完全可以实现所有UDT的功能, 无非在重复数量大的时候,麻烦些。当变更的时候, 需要做重复性工作。  

我一直也是这么认为的。 


然后最重要的是第三条,讲到了使用UDT的前提:比如功能完全不同的多个块,共同需要使用同一个结构数据。


这里面,几个算多?如果只有2个, 你需要建立一个UDT TYPE, 然后生成2个实例, 是3步工作。 而如果用结构,是两步工作。 修改的时候也是2步。 


所以,我认为至少要5个以上的程序块,使用了同样的数据结构,才有价值。 而且不能是INPUT和OUTPUT,因为暂时IO本身还不支持结构, 还需要另外做前处理, 又多了一步。而且这还是面对具体实例的时候。


我的意思是如果我做项目, 遇到同一个数据结构需要重复使用5次以上的时候,我会选择使用UDT, 除此之外不会考虑。


而不幸的是,在我的认知里,工业控制里面用到的数据结构都还算叫简单,我的经历中也基本没遇到过这样的需求。 


前面有一个程序框架,配方部分原本有可能使用UDT的,那倒是顺着控制逻辑使用了3-4回,但我暂时没用UDT,还是用结构做的,打算做好了以后再统一改的。可等到调试的时候,  发现数据类型不能通用,有一个块里结构改掉了,增减了内容,所以计划的改造为UDT的设想也泡汤了。 


因为,不值得。





微信公众号:PLC标准化编程,ZHO6371995

精华帖版主置评:信息量挺多呀。-yming

评论
编辑推荐: 关闭

请填写推广理由:

本版热门话题

SIMATIC S7-1200系列

共有15117条技术帖

相关推荐

热门标签

相关帖子推荐

guzhang

恭喜,你发布的帖子

评为精华帖!

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

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

  • 分享

  • 只看
    楼主

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