0820 【万泉河】就是要为不用UDT而不用UDT

在我新提出的PLC编程方法中， 提出过PLC编程拒绝使用UDT的概念。 但涉及此方面的文章并不多。

翻了一下历史记录，只有如下几篇：

【万泉河】PLC编程：反UDT同盟

【万泉河】一个UDT的绝佳应用场景

【万泉河】PLC编程烟台方法UDT后遗症

然而，就总有网友加我微信后来问我：万老师，你所有其他关于标准化编程的技能方法观点的文章都能看得懂，咋关于UDT的看不懂呢？找不到共同的认同点。

我只好跟他们解释：不用是因为压根用不到。 好的PLC平台， FB块的功能可以涵盖UDT的所有功能。这里包括了TIA PORTAL , CODESYS 2/3 , B+R , ROCKWELL等，而一些性能稍微逊色的平台， 如日系的三菱， 欧姆龙， 以及台达等，FB块本身支持的功能不够强大， 那迫不得已就只好借助UDT来辅助了。

即在日系PLC里1个FB + 1个UDT的组合可以大约实现PORTAL中一个FB的功能。

那么你如果使用西门子PLC， 如果是最新的PORTAL平台， 原本用FB即可以轻松实现的功能， 还非要画蛇添足FB+UDT来实现，是不是有些多此一举？

我这里当然指的只是程序架构要实现模块化标准化的场合， 不包括一些配方数据传递，生产信息传递等原本就需要UDT来实现的工艺。

所以，如果你拿到一套样板程序， 甚至是所谓什么行业标准的程序， 如果大量使用了UDT，甚至UDT多层嵌套，而这些UDT压根与配方，生产数据无关，那在解读时心里就要放个问号，是不是原作者在滥用UDT。

当然啦，我也从来没有主张过要你不需要学会用UDT，以为看我说PLC编程中可以不用UDT就彻底撒手不学了， 连它是什么功能原理，都不去了解掌握了。 这些只是基本功的知识，你只有掌握了所有基本功，知道它们各种技能方法各自的优缺点，才可以灵活运用收放自如，才可以有的放矢，根据工艺需求决定使用或者不用某一功能。

我从开始就知道，设计标准化程序中不使用UDT是一个太超前的概念，甚至比起不用M和T都令人难以理解。 也就只有参加了烟台方法的学员， 真正学习领教了烟台方法的魅力之后才会真的相信。

而除此之外的大部分同行，应该是根本看不懂我说了什么，甚至在很多自诩的高手的认知里标准化几乎可以和UDT划等号，把相关联的数据打包成一个个的UDT，就实现了标准化。 或许我应该在20年后才逐渐把话题引领到这个方向。然而我又等不及，不可能有话憋上20年不说。万一我半路挂了呢， 我还把这份思想理论带进棺材里不成？

所以我能做的， 只能是尽量少涉及。 只把结论抛出来，让大家知道有这么回事就可以了。而如果你暂时看不懂，或者不能理解，可以先把文章做个记号，后面过一段时间就再翻出来看一看。 指不定到哪一年，你就突然看懂了呢！反正我敢肯定的是，烟台方法的学员全都看懂了。 因为我现成的应用案例里面就没有使用UDT。而且相反是，假设有人非要加点UDT练练手，也会发现完全无用武之地。加不上。只要添加了， 添加的部分就只能是垃圾，而不会带来任何正向收益。  

然而也有一些自以为是的大佬，分明是看不懂。 却又无法从技术上面予以反驳，就玩起逻辑概念来了。说什么：不能为了不用UDT而不用UDT。

然后我就不高兴了，这种话看起来中庸全面，然而是不折不扣的屁话。 比如我们要改革开放发家致富财务自由，难道也要否定，以不能为改革开放而改革开放，不能为发家致富而发家致富，不能为财务自由而财务自由？只要目标是对的， 那目标就是对的。

如果按照相同的逻辑套路，那我们是不是更应该说的是不能为了使用UDT而使用UDT呢？

同样的系统，不同的设计方法，假设能实现同样的功能，其中一种方法使用了某个道具，而另一种方法未使用，那哪一种方法更先进呢？显然是后者咯！而实际上多使用了道具的方法反而会带来额外的缺陷。

因为奥卡姆剃刀定律早就说的很明白了："如无必要，勿增实体"。

做不到就说做不到，做不到就承认自己能力道行还不够，还需要不断学习。 而不是通过扯这种屁话来彰显自己的小聪明。

我来举一个例子来比喻UDT。 UDT是把一组有规律的相同或者不同的数据打包成一个集合，便于以后重复使用。 这像极了汽车中大量使用的线束。汽车厂中的大量的引线都会集合成线束，配以标准插头插座，然后汽车厂只需要批量外购定做这些线束，拿回来到组装线上简单插接即可。 给整个汽车行业配套的附件工厂中，有一大波是做线束的，我也知道有很多同行的公司就是做线束设备的，这是一个细分行业。 而线束的本质就是UDT。

然而汽车中使用线束/UDT，取决于2个前提条件，其一，汽车是标准品，一辆汽车里一个线束类型哪怕只用一根，那么只要这个车型一年卖出10万辆，那么订单就可以有10万根，就值得定做，值得外包。 其二，汽车的内部空间狭小，控制线往往跟随着机身就地排布， 散装的单线不利于敷设。

而我们做工控行业，要么工程项目，要么非标设备。即便非标设备，也做不到一个机型一次性下单采购几万件。所以通常的控制柜内，都是单线接线的，极少有自定义成标准线束的。

而如果你一个单台的控制柜，柜内的接线动辄设计成线束，下单给采购，让采购出去外协定做，纵然现在的出图软件可以精确地帮你规划出线束长度，但采购员问你采购几件？你回答说一件，那采购员会让你去。

标准线束啥时候使用呢？标准设备与标准设备连接的时候。比如编码器到伺服控制器的接线。 这些因为厂家有标准产品， 你不需要订做，只需要按照型号采购来即可。 而至于线的内部是怎么设计的，咱其实都不需要知道。 只知道买来了两边一插就能用。

这才是标准线束的正确应用姿势。

从中观察其应用场景，在标准模块内部衔接的时候。 对于使用这套标准系统的使用者来说，完全可以不需要知道它们的存在。顶多需要模块更换的时候，就整体全部更换。

那么对于软件系统，其内部的接口对接设计， 也完全可以不被外部知晓。 倒不是为了加密，而是为了不给系统添加负担，也是为了减少使用中的复杂程度。

模块化的设计， 你设计一套模块单元，就应该设计好了以后持续永远使用。 不需要再做任何调整修改。 而如果你设计了使用比如UDT001的一个自定义数据类型，那么就需要在模块交付时，声明：我模块中使用了UDT001，你们注意不要再使用这个UDT名字啦！

而如果另一个时空里的另一个你，设计了完全不相干的另一套模块单元，因为手法相同习惯相同， 好死不死，也使用了UDT001，而且也模块化封装加密了，那么到了使用者手里时，就悲剧了。 2个UDT干扰，名字相同但数据结构不同。总有一个模块不能使用。 除非去打开源程序做个小小的修改。-----又是一场失败的标准化闹剧。  

据我所知，绝大部分的PLC平台，UDT数据类型都是PLC范围内共享的。有例外情况是S7-1500的软件单元，给每一个软件单元都分设了单独的数据类型，不怕冲突。  所以读者们发现了嘛， UDT的本质也是一种全局资源。与我在5-6年前倡导的PLC编程不用M和T其实是一套逻辑，使用他们都会带来资源的冲突，都会严重影响标准化的进程。 只不过UDT原本用的就少， 太多人还没来得及领悟而已。

有人会问，如果我在模块单元就是要使用数据结构怎么办？我可以给你的建议是使用结构STRUCT，而不要使用UDT。STRUCT的本质是一次性的UDT， 现定义现使用，用完即放弃，并不占用系统资源。 以往老的STEP7系统中，结构的修改不容易，如果数据接口后面要修改，就要在所有使用场合逐个修改。所以那个时候都还建议使用UDT，然而会带来更多的坑，这里不提。  而PORTAL中结构的整体复制很简单， 你只需要复制了，到应用之处逐个覆盖，然后更新界面，即可。 当然， 如果你发现同一个结构使用场合太多， 你也需要再审视一下自己是否又滥用了。

而在PORTAL中，更好的建议是使用FB。我就曾经不止一次的使用FB，只为了用其来定义数据接口，替代UDT的功能，这样的FB， 内部甚至连一句程序逻辑都没有。

比如我做的MODBUS轮询库GML， 其中就有这样的FB。 然而使用者只需要将整个文件夹中的所有程序文件复制到自己的CPU中即可使用， 而完全不需要再额外关注有没有遗漏了UDT。 自然更没有UDT的冲突。

最后再用生活中的场景打一个比方，对家庭来说，UDT就相当于一个套装。 比如你一家三口，有可能会去买一个迪斯尼的家庭套票，酒店订一套家庭房，继而会不会更进一步要求银行开设账户也给我开设UDT家庭套装便于管理？如果银行同意了， 那么一家四口，两大两小的，一家六口，四大两小， 或者三大三小的套装要求都会出现。 更有甚者， 你一个科室17个员工，也要求银行给开设17个数据的UDT， 理由是便于工资统一发放，数据一步传送即可。 银行会说，去你的吧！拿一个完整的工资表来！你这个月17个员工，下个月15个了， 银行还跟着你每月重新定义数据结构不成？