PLC编程标准化的重要性分析

　　这俩问题我今天尝试用一篇文章讲清楚。

　　先说一个结论， 前一个问题是后一个问题的基础，没解决前一个问题，就不可能实现后一个问题。

　　即要搞PLC编程标准化， 一个重要的前提是程序中不要用M和T。实现逻辑的时候，不要使用全局变量的M和T来作为其中的状态传递和功能实现。

　　M和T的本质是全局变量，这是德系PLC中常用的代号，那么换到日系， 会是D，H等等，以及纯标签编程的，就是人为定义的字符。都是全局变量，都在要避免的范围内。

　　如果程序中用了M和T ，那么这个程序就只能用于当下这个项目，当下这个PLC模块私有，就无法重复使用到以后的项目中，以后的项目中哪怕功能和这里一模一样， 你也不能直接使用，而是至少要做一些变量的冲突审查。然后3个4个…。.100个项目， 只要需要你重新做程序，而不是直接拿一套现成的程序直接下载就是用的项目，都需要审查，调试，都需要你细心不要遗忘。只要遗忘了就要你好看，就会让你吃尽苦头。

　　所以，这两个问题的答案是同一个，即：痛点。

　　因为使用中感觉到痛了， 不舒服了，所以就要想办法找到避免痛的方法，而不是一辈子这么忍着，即便痛点苦点，也这么一直忍下去。

　　讲一个亲身经历的故事。

　　大约3-4年前，我一直给做顾问的公司，一个工程师辞职了，然后新的工程师还没招上来，他曾经干过的项目，已经交付运行了1-2年的设备，出问题了。客户反映某一部分功能不好用，自动运行时设备乱跳。

　　这个项目，这个类型的设备工艺 ，是他们公司的传统，其中的主要逻辑， 是我在N年前帮他们做了一个项目后的样板，后来的十几年，他们就一直使用我那套样板改过来改过去的用，已经用到了上百套设备上面了，所以工程师的能力绝对不会有问题，不至于做烂。

　　因为人手紧张， 老板就求我帮忙跑一趟，项目在天津郊县，然后我就买了机票直奔天津，到了机场直接租了个车，开过去了。

　　到了现场，了解了一下具体的功能，故障现象，又问下主事的设备主管， 这个功能以前有没有用过，是否好用？主管回答设备验收后一直在用其他的模式，唯独这个功能从来没用过，这是最近生产计划改变，才需要用到，然后用了就发现不能用。

　　然后我就问，全工在当时调试的时候， 这部分功能有没有验证过？答：好像没有。

　　然后我就明白了。因为这部分功能不是主要的功能，就有可能调试时没有注意到里面的变量使用，留下了bug。

　　打开程序， 找到相关的程序块，顺着逻辑捋了一下，再查一下变量的交叉引用，很快就找到了一个使用冲突的M变量。改了一下，再让客户开机验证， 立马好了。

　　前后不过半小时。

　　然而天色已晚，工厂还在远郊区，客户给我安排了宿舍， 让我住了一晚，第二天买了机票回家了。

　　花费两天时间，往返机票费租车费近2000元， 就解决了一个M点的疏漏问题。什么叫痛？这就叫痛。

　　前面的工程师为什么离职？常年出差，常年除了干工程项目，其余的时间就是天南海北没完没了处理这些类似的问题。基本上来说，一年当中，就很少有老老实实呆在家里朝九晚五上班的时间。因为公司的运转离开了你， 所以也不能给你晋升的机会，所以就只能十几年几十年如一日的无限重复这样的工作。

　　换谁谁不痛？如果还不能理解其中痛点的，我们接着往下看。

　　有人会质疑说，这不就是一个粗心的问题吗，只要小心一点，仔细一点，现场调试的时候别偷懒每一个功能都顾及到，都测试到，就不会出这样的问题了。

　　我只能说，这样的想法太幼稚了。客户生产系统一旦有可能运行，就会全力保障生产，就没有机会配合你做全方位调试。如果要调试辅助功能？等条件吧， 十天半个月的，生产有了条件，再给你机会试。然后怎么办，项目正常的调试也就十天， 你在哪儿再干等10天等条件？像我去天津处理的这个功能，客户放了快两年才用得到，才发现。你猜他们会给你机会？

　　完全细心的人有没有？有。这位工程师的主管领导，我的徒弟。那就是个非常极度细心的人，比我要细心100倍。他做项目的时候， 每个项目，每个点位，他都要重复4-5遍的审核，校对。多少次不无得意的跟我吹嘘，他干过的项目绝对稳定可靠，很少有离开后再次去第二次的。赢得了客户极大的信任。

　　然而这其中的代价呢，他媳妇时常抱怨， 为了做项目，他十几年每天都是熬夜到后半夜1-2点。年纪虽然还不大，然而十多年前就早就满头白发了。

　　这苦不苦，痛不痛？

　　然而痛点结束了吗？没有。

　　像上面离职的工程师的工作状态应该是大有人在吧？然后大家工作十几年如一日，觉得辛苦，就希望老板涨工资，涨一两次还不行， 最好是年年涨，每年涨一次，翻倍。这种要求非常合理，可以理解。

　　然而，站在老板角度， 十年前的你和十年后的你，工作内容是一样的， 工作量是一样的，为公司的贡献也是一样的，而十几年下来，市场形势可能已经逆转， 采购成本大幅度提高，项目竞争厉害， 拿到项目的利润已经今非昔比了。简单说你为公司创造的效益并没有提高，反而有可能有所减少，十几年老板肯定已经为你涨过几次工资了，你这儿还狮子大开口，还不满足， 还继续翻倍的要， 老板那儿都想开了你，换个刚毕业的年轻人来呢！人家工资要求可没你那么高。

　　你可能会说，切！新毕业的大学生啥都不会，怎么能赶上我一个十几年工作经验的老工程师？然而你好像忘了，十几年前，你也刚毕业，老板重用你，还不是照样顶下来干到现在？

　　更何况，前面的设备工艺没那么成熟，现在早成熟的透透的了，根本用不上这样富有经验的顶级高手了。

　　所以你如果为工资收入感到痛， 老板同时还为你收入高，贡献不匹配也在痛。如果现在还不痛， 那就终有一天被裁员了，才真的感到痛吗？

　　要解决最后这个痛点， 可不仅仅是减少bug就够的。通常在职场上，这唯一的途径是升职。工作中做出一定的业绩，被领导赏识，然后有机会提拔，上升到管理层，就可以极大程度跳离出差长工资低的苦海。然而对大部分纯粹的技术人员来说，通常不谙人情世故，因而很难有机会做管理的。那么唯一的途径是提高自己的工作效率。

　　比方说， 如果你是车间的车工， 你原本一小时能加工10个零件， 如果你肯动脑，善钻研，设计一个好的工装，一小时能加工100个零件了， 不光自己的效率提高了，别的车工使用了你的工装后，效率也提高了， 这些所有人的提高的效率，都是你的业绩。 那么公司为你涨工资提待遇是水到渠成的事。

　　而对于自动化工程师的工作来说，这个工装就是程序标准化。而其实对于有机会升职到管理层的，其最好的业绩也是为公司打造一个标准化体系。

　　通过建立公司设备程序的标准化体系，可以大幅度的提高工作效率，减少出差时间。

　　然而很多朋友暂时还没有能力建立标准化，有些可能连标准化的意思都不知道。我们所指的PLC编程标准化，不是去跑到PLC厂家为他们制定一套通用的标准化工具，直接嵌入到PLC厂家发布的软件系统中， 从而限制PLC的使用者的编程方式， 以逼迫他们不能任性的使用全局变量， 不能写垃圾程序，没办法写出低效率的程序， 被逼无奈只能设计出来高效率的标准化程序。

　　我们所说的PLC标准化编程方法，是指工程师把PLC作为工具， 在所产出的作品，即你的设备程序，使用标准化模块化的方法搭建而成。如何叫做标准化模块化， 不是你程序中把功能分成了若干个模块单元就可以的， 而是这些模块要能重复使用。即一旦开发完成， 在本公司，本行业将来的大多数项目中，都可以直接简单使用。

　　简单到什么程度？

　　简单到最高极致，完全按照高内聚低耦合的目标，留给组装环节的工作量只剩下简单耦合， 这种耦合没有任何技术含量，任何一个没有设计基础的电工，应届毕业生，办公室文员，都可以通过30分钟的培训，就可以完成。

　　那么，在最极致的情况下，一旦对某个工艺设备的逻辑开发成熟，后面的工程就不再需要工程师到现场出差，现场的安装工人按照设计部门给付的设计资料，稍微整理下装程序即可。下装后程序逻辑即可可靠运行， 不再需要试车， 不再需要现场调试。

　　当然，上面所述是终极目标。在终极目标达到之前，工程师可能还需要偶尔出差，有可能只是为了到场安抚客户，让习惯上看着工程师调试动辄一个月的客户心理有些安全感。然而这时候的出差，对工程师来说基本上就是商务旅游了， 没有什么压力， 去了以后大部分时间也就协调配合。时间也极短，原本一个月两个月的调试时间， 现在3-5天就完成了。

　　然后， 原本一个工程师，一年能干5-6个项目的， 现在一年干20-30个也不在话下。而且劳动强度还降低了。这种情况下，这样的高效率，老板如果不给涨工资， 合天理吗？

　　标准化编程方法， 其实不是一种什么思想，他的实现方法很简单， 4个字， 面向对象。如果懂的人自然早就已经懂了。

　　然而标准化编程，其实是一种能力。

　　拿我自己来说， 我在十几年前就开始研究琢磨标准化编程的方法，然而自己一直没能全部打通。10年前在S7-300中已经做到了程序中不使用M和T，然而系统还是需要长时间的现场调试，因为疏忽造成的bug显著减少， 返厂次数少了。然而总体效率提高并不明显。

　　这个时候我整体技能还不成熟， 同时也缺少一个关键点的推力。然后在5年前开始使用S7-1500， V13， V14， V15。到V15的时候， 突然发现它可以比以前更好的支持面向对象了！然后如开挂一般，除了搞出了S7-1500标准化应用， 甚至还倒回去在S7-200 SMART中实现了标准化架构。

　　按说S7-200的标准化与S7-1500根本没有关系。S7-200早就存在了20年，我早用的滚瓜烂熟，为啥之前我搞不出呢， 为啥在S7-300时搞不出呢？还是自己能力不够嘛！

　　我在上一个公司上班时，公司别的部门成立项目组要搞标准化，那个时候公司用的是S7-300。我自己既然没有这个能力， 自然也帮不上什么忙。我认为搞不出，他们也不相信。然后就由他们自己搞了。

　　上个月， 我问了一下以前的那位同事，你们当年搞的标准化，怎么样了啊？

　　回答说， 搞了一堆函数库，但根本没人用。废弃。

　　我说， 这很正常。以我当年的认知，都自认为没有能力搞成， 我也顶多给公司做个样板工程， 给同事们打个样，以后同样工程可以参考而已。你们技术部都没有现场调试经验的， 仅凭临时学一下STEP7，不会的地方还要逐步向我请教的，就能一步到位做出标准化开发？天方夜谭呢！

　　所以看出来了吧， 能力以及能力的成长才是第一主要的。

　　标准化的程序架构，在整个行业前面发展的40年里， 是从来没有出现的。所以，所有同行，之前并没有见过这样的项目案例，所入门学习的参考资料， 全都是过去传统模式的架构。所以自然有很多很多人持怀疑态度。

　　怀疑者的心态，我猜有两种。

　　第一种，不相信在PLC行业能做出标准化的程序， 甚至有的人都一直不相信可以做出不使用全局变量的程序。

　　第二种，相信客观世界能，但不相信我有这个能力做出来，或者不相信我所做的标准化程序和他们以往所做的和见到过的程序有什么不一样。

　　这两拨人，总是一副挑战的心态， 以激将法来问我要程序。说什么你敢拿出个例子程序来吗，除非你拿出来给我看了我才相信你。

　　经过本文的分析，大家现在应该都明白了吧，标准化是企业的标准化，是每位自动化同行所在的公司的标准化，与PLC厂家没有任何关系。企业是否做到标准化， 与工程师个人的效率，工作量，出差辛苦程度，薪资水平这些所有加起来的痛点有关系，而与我并没有多少直接关系。

　　像最开始的故事里， 那位离职的工程师， 在外面飘了2年之后，又回来跟老板联系，有意再回公司工作，继续出差也愿意。然而被老板很冷淡的拒绝了。他当初是和另一个工程师几乎同时辞职的， 现在，这样的岗位不缺人了。因为他们实现了标准化设计，就那些老是大同小异的重复性的工程项目，一个工程师足够了。有一些小项目，电工在现场也就干了。都不需要工程师去了。

　　所以，这其中效率提高了多少， 大家都能基本有数了吧！

　　编辑：黄飞