作者 | 主题 |
---|---|
宝冬 至圣 ![]() ![]() 经验值:10453 发帖数:1699 精华帖:26 |
楼主
![]() 主题:关于UDT和FB的优缺点 ![]() 刚看了万泉河发帖关于UDT缺点和用FB替代UDT的论述。觉得有些地方的理解不妥,甚至误导,说一下自己的看法。
符合IEC 61131-3的程序,应该通过SCL文件来分享。 所有存在依赖性关联的OB、DB、FB、FC、UDT,都会一起被自动打包成单个SCL文件。在新项目中用这个SCL文件生成程序的时候,这些聚合对象都会自动生成展开。这是使用SCL的重要优点之一。 在SCL文件中会看到,在IEC 61131-3的理念中,所有元素都是作为不同类型存在的。从这个角度理解,FB和UDT,是作为平等的主体被设计出来的。
一个UDT应该被理解成一个接口。一个FB应该被理解成一个类。 UDT是把静态属性集合,定义成与bool和int一样受到开发环境平台支持的新数据类型。 UDT不含动态属性,也就是高级语言中所说的方法。这可以通过与FC的结合去做到。
FB开销大,UDT开销少。UDT的load memory占用比FB低,它没有in、out、inout、static、temp这些结构开销。UDT完全不占用work memory。
如果把FB当作数据类型用,它只能存在于实例IDB中。因此使用上受限多,远没有UDT灵活。最关键的是,UDT在IEC 61131-3中是基本存在,不是另类。 UDT可以解耦化多层嵌套,且没有副作用,而FB如果多层嵌套,则很笨拙。
至于说耦合关联,UDT有的,FB一样都有。 设计模块,接口应该都是在界面上的,而不是去IDB中衔接。数据对象,因为模块功能的解耦,而存在位于interface中和core中的选择之分。 提到接口思想的灵活性,为什么说设计接口比直接设计类更好呢? 从叙事的角度看,类的继承不如实现接口更纯粹。尤其是面对越来越复杂的故事需求演化。 实际上在现今的IT开发中,人们所说的面向对象思想,在真实项目中,都是以高度抽象的框架形式呈现的。 框架几乎全部是由接口集合搭建。面向对象最终成了面向抽象。 具体实现某种功能的对象,完全是遵循设计模式,在需要的场合,按照接口规格,动态生成。 因此一个项目的核心工作,就成了设计接口集合。用接口体系去说清故事的本质,具体对象的任务则是落地实现接口的意图。 同样的,在工控开发中,比如特斯拉在中国建设工厂的项目。美国人早就把接口体系和命名规则的框架设计做完了,现场PLC工程师就是按照规矩,往里拖拽实例对象,搭建具体工厂实体。 欢迎各位切磋。 |
'Razor 至圣 ![]() 经验值:21345 发帖数:2960 精华帖:27 |
37楼
![]() ![]()
Less is more……
|