国(敏感词)庆(敏感词)节前去江苏常熟给一家工厂里做了一场西门子PLC, PCS7, 以及伺服传动系统等的应用培训,历时一周。
培训到第二天的时候,下面的一个工程师,要求给讲一讲UDT。这是原本培训计划中没有的内容。我愣了一下,当即表示拒绝:UDT能做的事情,别的方法也都同样能实现,而即便使用UDT的方法,也不能有任何效率的提高。
所以,在我的认识里,即便是PLC高级编程,也没有必要用到UDT,我在PLC标准化编程的培训训练营里,一直的主张也都是,不要使用UDT。
但工程师说了,没办法,设备供应商给提供的生产线程序里面大量使用了UDT,所以不管老师认为是否管用,还是想了解一下,请给讲一讲。
好吧。然后我只好凭自己的理解,把UDT的概念,使用方法,应用场合讲解了一遍。
UDT的本质, 是把一组简单数据类型的数据, 以一定的规律顺序组合为一个复杂数据类型。
我所知晓的使用场景:
1, 可以用UDT直接建立数据块,过去主要用于给某些FM模块快速建立专用的数据。
2, 可以建立全局数据块的数据,甚至包括数组。
3, 可以用作FB的管脚,在程序调用的时候,减少管脚数量。改变过去大程序块的调用管脚几十个,导致窗口都显示不过来的弊病。
当然啦, 以我的直率性格,当然要在讲解中不断的夹杂坏话, 每一步, 都把其缺点给原原本本的交代清楚。
比如,所有用UDT的场合,原本用STRUCT结构也都可以实现同样的功能的。无非, 多个同样的STRUCT,如果需要修改元素, 就需要逐个修改。 而UDT则只需要修改一次其原本的数据类型定义。
但对UDT的使用点,还需要或者手动更新(STEP7 v5),或者编译(PORTAL ),来同步这种修改。而且在STEP7 V5的时代里,如果使用了UDT,而源程序丢失,那么对于从PLC上载来的程序,要修改的时候,简直是灾难。根本无法改动, 即便知道UDT的定义结构, 手动建立一个都不成, 咋搞都是红字,错误。
这是我曾经使用过UDT的痛苦记忆。
当然啦,我也知道,现在很多PLC编程工程师偏爱使用UDT,是用于变频器/伺服驱动器的通讯,把接收来的或者要发送的数据,统一整理到UDT中,对于多台变频器通讯的时候,比较方便。
但在我所推行的标准化编程框架里,所有设备都是以FB设备类型的形态出现,根本不需要用到UDT,而如果非要把FB的管脚定义为UDT ,那么在FB被调用之前,还需要专门的篇幅来整理UDT数据。甚至,即便数据传到WinCC之后,也要拆分后,每个数据单独处理。毕竟,本质上, WinCC其实还不支持UDT。
课程这一章节讲完,课间休息时间,我突然意识到了一个问题:我把我自己推入了一个尴尬的境地!
在大多的PLC初学者看来, UDT属于比较高深的知识,因为不懂UDT才不会用他。而我这种大张旗鼓的宣扬反对UDT,分明是不懂么!你既然都不懂UDT ,还有什么资格来给广大的工程师们做培训?
就好比,我不喜欢喝咖啡的苦,有人会嘲笑我,那是你不懂。
我不喜欢抽烟和喝酒,人家嘲笑我人生没有深度,不懂得烟酒能给人带来思想境界的提升。
还有我没觉得八爪鱼非常好吃,我媳妇嘲笑我不懂得八爪鱼的鲜美,不懂得把它塞到嘴里时带来的那种丰富的味道的层次感。
总之,不懂=不会,不会=不懂。
由此,我明白了,为啥总见到有教程在教人使用UDT,而没见过有人和我一样在教人不要使用UDT。
因为,无异于在承认自己不懂。这对常人来说, 这是一件很危险的事情。
我当然不懂得UDT的奥妙,我承认我确实没有理解到UDT带来的优越。
所以我需要成立一个反UDT的同盟,欢迎跟我一样认识的同行,勇敢地站出来,大家一起说:UDT,我拒绝!
同时,当然更希望有使用UDT有高度心得的大佬,教给我们,更深奥的UDT的使用方法。让我们能真正学到些有用的知识。
当然,前提是不在我上面抨击的内容内。比如常熟的那家工厂的工程师后来承认我猜的对,项目中大量使用UDT的原因,果然是因为系统里有众多的V90。而我们如果对FB封装得好的话,完全可以在FB内部就处理好所有数据格式。而暂时的,即便在PORTAL系统中一些功能还只支持UDT,不能支持FB,那也只是系统不够成熟,不认为是UDT的优点。因为,我们随时可以期待系统升级后FB可以更好的支持所有功能。
好了,现在可以站队了。
愿意加入我反UDT同盟的,请回复1;
支持UDT的,请回复2。