恭喜,你发布的帖子
发布于 2020-07-24 09:35:37
18楼
本来想专门写篇文章来说明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的设想也泡汤了。
因为,不值得。
精华帖版主置评:信息量挺多呀。-yming
请填写推广理由:
分享
只看
楼主