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

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

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

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

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

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

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

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

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

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

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

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

前后不过半小时。 

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

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

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

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

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

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

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

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

这苦不苦，痛不痛？

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

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

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

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

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

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

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

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

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

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

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

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

简单到什么程度？ 

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

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

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

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

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