引用33楼详细内容：

你的做法只是符合你自己的事业场景和你的需求。

而使用UDT的潜台词就是：不再使用不兼容IEC 61131-3的老式平台。

我根本不会去用200smart这类老式PLC。因为工控只是辅助手段，而我是在做对客户有使用意义的完整产品，最终的核心是技术性服务。

所以根源在于：对于不同的人，没有统一的生涯事业场景。而工控设计永远是以客户价值实现为第一目标。

程序员很可能喜欢沉浸在代码设计，自己塑造的大一统规范世界之中。但事实上只不过是千差万别需求的客户脚下的石块。

客户花钱买服务，并不会围绕程序员的自我世界去转圈。所以程序员没必要把自己的理想空间放太高，这不符合世界的真相。

至于技术的价值，那得站在最终客户的而角度，而不是程序员自我陶醉的世界去评价。而且是所有代价细节的深入骨髓的优劣和性价比代价分析才能真实体现。

往往听起来很漂亮的表面形式，都是隐含很多的代价和坑，这些通常是不会事先对人言说的。这是世上常见的套路，拣好听的先说。

真能包含这世上千差万别的随时随地变化的各种挑肥拣瘦的真实个性化客户需求吗？很多东西都只是最初说起来好听，屁股后面的瑕疵还没暴露罢了。

不要说小小的PLC领域，整个IT领域中汇集成千上万人才的各种曾经的逻辑大作，最后软件工程崩塌的比比皆是。

在真实世界中，想要凭某种招数，一劳永逸获利，是技术人的歪路。框架技术并不新奇，都是用旧了的套路，优劣都得走着瞧。

引用31楼详细内容：

说这么多理论， 千方百计为自己使用UDT做辩解。

而我只告诉你一个事实就可以了。 

烟台方法做的项目程序里面， 没有使用1个UDT，就把项目完成了。 而且还极为简洁高效。

然后也可以移植套用到没有UDT功能的PLC里， 比如SMART 200。 

你们总不会把UDT多好多好的理论再搬到SMART去吧？然后抱怨同样功能SMART里面实现不了？

当然， 再补充一个信息， 烟台方法样板工程原始项目里面其实是有UDT的， 因为那里面有配方和报表。 我在N年前分享的报表专题中就有列出过。 只不过当专注于标准化编程的时候， 与配方和报表无关，而且也涉及工艺敏感信息。  我就在分享之前把这些内容给裁掉了。 于是UDT也被减没了。