0926 【万泉河】关于UDT，只怪自己脑洞不够大

0926 【万泉河】关于UDT，只怪自己脑洞不够大

上一篇文章《0917 【万泉河】关于PLC中UDT和FB的迷思》，是针对更早一篇文章
《0820 【万泉河】就是要为不用UDT而不用UDT》所引发的网友争论所写。

文中主要的结论：

* UDT本质上是数据类型，而FB本质上也是数据类型。
* 从接口的角度，UDT和FB同样都可以作为接口。
* 而从类的角度，UDT和FB也都同样可以作为类。

文章发出后，这回的反响就比较好了，没了那么多反对争论的声音，连带那个讨论的帖子，过程也不那么激烈了。

因为我一再表示，我发表这些观点不是抛砖引玉供大家辩驳的，而是立下个标志，供大家可以在很长时间里学习理解的。我根本没有要和同行讨论的意思。 所以不需要来和我讨论乃至争论。 除非有人能和我一样写出来系列文章，并且发表出有理有据的更深刻的观点。

然而有群友读懂了之后就在群里问我， 既然UDT和FB都是数据类型， 那么FB是否可以作为UDT的数据元素呢？

我以多年西门子PLC的经验，做出的第一反应是，不能，绝不可能！

然后说出口之后立马感觉自己有些唐突了。 这要是说错了话， 这要是被整天跟在脚后跟后面盯着咬脚后跟的家伙抓着了把柄， 不得兴奋跳脚好几年啊！当然， 以他们的智力水平，这一段的技能已经远远超越了他们的认知上限，即便放个破绽给他们，他们也没那么容易叼到。

所以，说完之后，我赶紧在PORTAL V17里面验证了一下，先松一口气，当然是不可以。 在UDT中建立数据元素的时候，可选的数据类型有各种基本数据类型，也有已经存在的UDT，但已经存在的FB却并没有出现在可选列表中。

注意看这个时候的表达，是要严谨包括软件版本的。 更新版本的V18我还没有用过，所以暂时无从验证。 而未来保不齐在哪一个版本中会支持，在当下这还是悬而未决的悬案，需要未来验证。

然后，我就顺手在正在使用的倍福TC2的软件中试了一下， 惊掉下巴的事情出现了： CODESYS中竟然可以！

CODESYS中的UDT的数据类型，竟然可以选择系统FB和自定义的FB作为其数据元素。

而且，当天也就有了报应。

我承接的一个公司的非标设备的PLC程序的标准化改造，他们的PLC主要使用倍福，所以我还在逐字逐句解读他们原来的TC2程序。 然后当天下午，在阅读到某一数据类型的数据结构时，赫然发现了其中定义的R_TRIG ,  就是相当于SFB啊

TYPE ST_calcpointw :
STRUCT

limitswitch:BOOL;
point1:BOOL;
point2:BOOL;

rise_tf:R_TRIG;
rise_fs:R_TRIG;
rise_cs:R_TRIG;
rise_fw:R_TRIG;

END_STRUCT
END_TYPE

怎么说呢， 对我来说，只能怪自己脑洞不够大了！

我们这儿还各个角度各种理论论证各种数据类型的区别呢，殊不知早有人在用着了。 当然，我相信他们老大即便无意中发现了这个功能可以使用就顺手用的时候， 也完全没有想到在屋子外面有众人会因为其背后的理论吵吵闹闹，扭作一团。

也当然啦， 他们的老大虽然早就掌握了在UDT数据元素中使用FB的技能，写程序的方法仍然基于传统方法的，虽然一直在谋求实现设备规格的标准化，但最终结果却离标准化模块化越来越远，去年他们出厂的非标设备类型统计下来达到了50个机型之后，PLC程序版本管理就完全失控了，设计人员开始疲于奔命，被一个接一个的项目推着走。 公司严重缺人手， 然而新招的人手短时间内还不能承担起工作任务，完全恶性循环中。所以想到了要我来辅导实现设备程序设计的标准化。 对倍福的PLC，调试细节我不够熟悉，但由于我N年前已经完成了倍福PLC的标准化，所以对其标准化架构还是比较了解的。 这是我敢承揽的主要原因。

同时也做一个预告，《三菱PLC标准化编程烟台方法》的书稿已经通过了出版社审核，预期会在年底之前出版发行。 而我计划的下一本书，就会是针对倍福和CODESYS的。会在辅导的倍福标准化项目有点眉目的时候就同步开始攥写。

书名会叫做《倍福/CODESYS  PLC 标准化编程烟台方法》， 既然倍福PLC是基于CODESYS平台的， 那么在写倍福时也就顺便将CODESYS的内容一起包含了。 如果还有其它的使用CODESYS平台的PLC厂家希望搭便车， 在书中同时体现， 请私下与我联系。