技术论坛

 • 产品分类
 • 咱工程师的故事
 • 培训与认证答疑专区
 • 服务合作伙伴专区

 关于UDT和FB的优缺点

返回主题列表
作者 主题
宝冬
至圣

经验值:10453
发帖数:1699
精华帖:26
楼主    2023-08-30 08:01:42
主题：关于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楼    2023-09-07 22:55:29
精华帖  主题：回复：关于UDT和FB的优缺点

比简洁，在UDT面前都是小儿科。





简洁吧？

数据通过UDT打包，在最上层，控制逻辑绝对隔离，在最底层。



Less is more……
您收到0封站内信：
×
×
信息提示
很抱歉！您所访问的页面不存在，或网址发生了变化，请稍后再试。