西门子参数板

西门子参数板

国（敏感词）庆（敏感词）节前去江苏常熟给一家工厂里做了一场西门子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可以更好的支持所有功能。 

S7-200的子程序SUB，一旦写好，用在程序中之后， 是不可以修改其输入输出管脚的。 因为你一旦动了管脚接口，调用这个子程序的地方，就会报错。报错以后还没法和STEP7一样可以通过更新只更新改动部分。

正常处理的只有把原本的调用删掉， 从头重新调用，并为每个接口逐个分配变量。

这相当讨厌。

比方说我一个底层的设备，如果调试中发现需要增加些功能，实在不可避免决定要增加接口。而我主程序中已经对这个设备调用了几十次， 那就必须几十个实例都重来一遍。

而这还不算完。

谁敢保证这一次接口的变更就是最后一次了呢？下一次如果还需要修改，就需要原样再来一次。

估计换谁， 都受不了这种折腾。

而这也是标准化编程的大忌。

貌似许多人对标准二字有误解，看到我提出的标准化，就有些不服气。你万某有何德何能提出标准，俺们智力才艺都不比你差，凭什么要遵循你提出的标准，凭什么用你的标准而不是我自己的标准？我们国家历史上因为技术标准落后一步而受制于人，吃的亏大了去了。可不能重蹈这样的覆辙！

而另外有一些人，则强调没有办法做到整齐划一的标准。理由是设备配置千差万别，没有一模一样的设备， 所以做不到标准化。

错啦！都是属于对标准化的误解。 我们追求的标准化，是把系统做成搭积木一样的标准模块，每个模块自成体系，逻辑互不干扰。 通过接口与其他系统模块对接，不同的系统设计， 在接口不变的情况下，只需要更换相应的模块，即可以实现快速组装。

而接口，也不是一尘不变的，可以根据需要随时改进，而在接口改动的时候，也只是对接的模块之间局部变更， 不要影响到整个系统。 不会因为接口的改动，而需要系统重新调试。

甚至，我现在推广了二期标准化示例项目之后，下一步的计划就是对接口的优化升级。过去，我在开发阶段，采用的接口只是借用的别人以前做的， 现在终于有精力，腾出手来，把接口改造为我满意的样子。

而我和我的团队成员，丝毫不需要担心接口的更改会导致影响到已有逻辑模块的运行， 甚至带来bug。

这就是标准化设计的优势。心不累。不需要和以**样，程序中改动一点点就紧张万分，就担心把整个系统原本正常运行的功能搞崩溃。  

所以，我在开发SMART 200标准化架构的时候，首先就意识到子程序（库函数）接口不能更改的这个问题很严重。并认为有可能是众多人都不愿意投入精力在SMART 200系统做标准化的主要原因。

所以首当其冲必须解决这个问题。

我在写文章《【万泉河】SMART200也能做标准化》时， 提到了我解决了其中一些关键细节，其实其中**个便是搞定了子程序可修改的问题。原本是我打算在培训课上首先传授给学员的**课的内容。 趁这次征文机会，写出来， 与大家分享。

而实现方法，其实很简单。

即利用程序块的导出功能，把调用被改动的子程序导出为AWL的文本文件：

然后在文本文件的调用中，修改到符合新版本的函数的语法，再重新导入即可。

这里存在的问题是，不管是导入还是导出，操作之前软件都会自动编译，编译通过后才可以进行。 所以导出必须在修改接口之前，而在修改接口之后，导入之前， 需要把相应的SUB内发红的段落先删除。

因而实时的存盘备份非常重要。 千万不能上来就改接口改子程序的逻辑，改过之后发现既不能导出又不能导入，那就尴尬了。

由于AWL文件中是**值寻址的，所以界面非常不够友好。 我通常是在文本修改阶段，只管语法正确，比如增加的数值变量，就先填上AC0，如果是离散变量，则暂时输入L0.0，等导入成功之后，在梯形图界面下，根据实际需求，更改为正确的变量。

当然啦，如果有可能，尽量直接用搜索替换比如把原有的”AC0”替换为“AC0,AC0”。速度会快很多。

所以，在使用标准规范中也包含了同一个类型的设备对象，尽量在同一个SUB中调用。 这样导出修改接口的时候只搞这一个文件即可。 而不必在整个程序范围去找，去把整个程序的SUB都导出来手工修改。

那样儿，仍然会很累。