电子发烧友App
0917 【万泉河】关于PLC中UDT和FB的迷思
我在上个月写过一篇文章《0820 【万泉河】就是要为不用UDT而不用UDT》，文章题目看起来挺绕的，挺烧脑的吧？
嗯， 不光题目烧脑，内容对大部分同行来说也相当烧脑。
我在写文章的时候就预料到了，会有大批的同行看不懂。但我也提醒了，暂时看不懂没有关系，只要你持续不断地学习，未来十几年的时间里，定期回来重复阅读，总有一天有可能会有理解。然后你的编程水平就会有一个大幅度的提升。
我也在其他一些场合多次提到过一条认知上的基本的道理，就是一个人，对于自己认知之外的新见到的知识和道理不要随意妄加评判。
有人会说了， 难道讨论也不行吗？你可以去私下讨论，可以请教，但不要先下结论。至少，长久以来，我自己是这样做的。
有兴趣的读者可以在阅读完本文后去稍微围观一下。但不建议阅读本文之前先去围观，因为容易被带跑偏了。
我原本就多次说了，我关于UDT的话题是超前的话题，任何人看不懂也没有关系，也不影响你完成现在的程序设计。我只是提前把一个理论放在这里而已。然而这位宝冬网友非但要讨论，而且还指责我误导他人，而在我看来他的那些乱七八糟的说法才是恰恰起到了误导的作用，所以为了避免这种流毒，摘一点他的核心观点评判一下。
（注意观察什么是正确的评判姿势？就是你说的这些我都懂，都听说过，但我知道它不合理，所以反对这样的说法。而不是你说的对我全都是新的，但因为和我习惯不同，我就要按照我原有的理论框架来论证推翻它。）
宝冬的主要观点原文中两句话：
一个UDT应该被理解成一个接口。一个FB应该被理解成一个类。
我全文就只评价这2句话了。
首先，这是一个病句。
你首先要知道UDT和FB是所有PLC甚至计算机系统中都有的概念。而不唯独西门子PLC，也不仅仅S7-1200中有。
你可能会辩解说， 废话！我帖子发在S7-1200的版区，当然指的是S7-1200了。然而，即便加上S7-1200的限定语，也仍然是远远不够的。你还忘记了PORTAL软件的发展历史， 没有看到在PORTAL软件从V10.0到现在V18.0不断升级过程中UDT和FB性能的变化升级过程，更没有想到，未来，西门子在对软件升级过程中有可能对这两者的性能做升级。
而我不仅仅看到了其过去的升级， 也一直在期盼未来它们在某些细节功能方面的改进。比如我讲过多次，我做PLC标准化编程是从PORTAL V15开始的，就是因为它实现了我长久以来所期盼的功能升级。而我目前也仍然有期盼，如果能实现，也能帮助我们实现很多功能，效率有很多提升，细节就不提了。
所以，这个观点中对UDT和FB的理解，都是有偏颇的。
UDT是什么？用户自定义数据类型。所以，它更应该和系统已经内置的简单数据类型和复杂数据类型（如DTL,LTD等）功能一样，能实现同样的功能。
所以如果你认为UDT是接口的话， 那么是不是一个普通的数据类型， BOOL , INT， WORD都可以理解成接口呢？
这显然是不能的咯！所以可想而知， 本质上你还是对UDT有些恐惧，觉得它神秘莫测，所以才非要给它规划一些特殊技能。
而叫我说的话，UDT本质上是数据类型，而FB本质上也是数据类型。
有没有被惊讶到？
这一点， 由于PLC平台之间变量命名空间的规划设计不同，在PORTAL中不太容易展现。那么我先在倍福的TC2中即CODESYS中做个举例。
比如我有一个模拟量AIW001， 我要对它做数据处理， 做个FB块叫做FB_ANALOG，同时按照你们的习惯，还要做一个UDT，放在FB的管脚上，便于数据的交互，那么这个UDT可以起名字为UDT_ANALOG。
那么在一个模拟量的情况下，需要为上述建立3个变量标签，分别为AIW001, AIW001_IDB, AIW001_UDT。
看到没， 不管是FB的名字还是UDT的名字，都是列在TYPE一列的， 与INT数据类型同列。
而我们在按下shift+F2新建变量的时候，所弹出的输入助手对话框中：
可选的类型中， User defined Types即UDT， 与User defined Function Blocks即我们制作的FB，赫然并列。
而回过头来看PORTAL编程环境中， 就有一些不同， 当然其中主要原因是西门子传统上有全局数据块和背景数据块导致的， 而其它厂家因为没有这两者，而一概统称为标签，就没有了区别。
区别如下：
在当下所见到的PORTAL版本中，全局数据块中可以建立UDT类型数据，但不可以建立类型为FB的数据。
在全局变量表中，只可以建立指向变量地址的基本数据类型和UDT数据类型，但不可以如CODSYS般直接建立UDT的数据变量标签（只能在全局数据块中）。
而在PORTAL的全局变量表中，也不可以建立FB类型的变量（即IDB）。但其实在旧的STEP7 V5.X中，是可以的。即STEP7V5中，是把IDB当作一类数据的。 PORTAL之后只不过把IDB当成文件在文件列表中显示，而不在变量表中展示了。但其实两者仍然共享的同一个变量命名空间。比如你如果建立了一个AIW001的INT数据类型，用于接到AI模块的通道，就不再可以建立FB的IDB也叫做AIW001， 提示名称冲突。
但在PORTAL中有一种命名空间可以允许上述的三者数据类型INT , UDT和FB共存，那就是IDB， 即在定义一个大的FB时，其数据的命名空间可以同时容纳三种数据类型， 与演示的倍福中接近。
而且，可以看到，不仅仅在静态变量中可以建立这些数据类型的实例，在接口的INOUT中，也同样可以。
即，从接口的角度看，UDT可以作为接口，FB也可以作为接口，这两者是几乎等价的
我们再从宝冬所关心的类的角度看UDT和FB。
在任何PLC中， 如果UDT和FB都只是建立了而不使用，则二者都完全不起作用。所以必须建立以它们为类型的数据变量，即实例化。在CODESYS中这一点描述比较简单， 就是在全局变量表中建立实例。而在PORTAL中描述稍微复杂，如前文所述。但简单来说，就是都需要实例化。
而这两者并没有什么不同。
所以，站在面向对象编程的角度， UDT和FB都可以作为对象的类来使用。在一个功能不够的使用， 祭出来另一个打辅助。而如果1个够用的时候， 则另一个完全可以靠边站，让它失业都没问题。
所以总结全文， 针对宝冬同学的观点：
一个UDT应该被理解成一个接口。一个FB应该被理解成一个类。
我的结论是：
从接口的角度，UDT和FB同样都可以作为接口。
而从类的角度，UDT和FB也都同样可以作为类。
当你认为这两者有区别的时候，原因有2个，一是系统平台提供的功能还不够完善，二可能是你掌握的理论基础和编程技能还不够全面。
当然， 目前看， 第一条， 至少SIEMENS PORTAL系统平台在这方面是完全及格够用的。
而第二条的话， 这也不能全怪你。PLC行业原有的编程理论原本就非常少，大多数人都还只能从厂家的手册中学习基础技能，而你能从网上能检索到的理论和技能文章都非常少，除了我的专著、专栏和公众号。
编辑：黄飞
工商网监
评论