即要搞PLC编程标准化，一个重要的前提是程序中不要用M和T。实现逻辑的时候，不要使用全局变量的M和T来作为其中的状态传递和功能实现。
M和T的本质是全局变量，这是德系PLC中常用的代号，那么换到日系，会是D,H等等，以及纯标签编程的，就是人为定义的字符。都是全局变量，都在要避免的范围内。
如果程序中用了M和T，那么这个程序就只能用于当下这个项目，当下这个PLC模块私有，就无法重复使用到以后的项目中，以后的项目中哪怕功能和这里一模一样，你也不能直接使用，而是至少要做一些变量的冲突审查。然后3个4个…..100个项目，只要需要你重新做程序，而不是直接拿一套现成的程序直接下载就是用的项目，都需要审查，调试，都需要你细心不要遗忘。只要遗忘了就要你好看，就会让你吃尽苦头。
所以，这两个问题的答案是同一个，即：痛点。
因为使用中感觉到痛了，不舒服了，所以就要想办法找到避免痛的方法，而不是一辈子这么忍着，即便痛点苦点，也这么一直忍下去。
讲一个亲身经历的故事。
大约3-4年前，我一直给做顾问的公司，一个工程师辞职了，然后新的工程师还没招上来，他曾经干过的项目，已经交付运行了1-2年的设备，出问题了。客户反映某一部分功能不好用，自动运行时设备乱跳。
这个项目，这个类型的设备工艺 ，是他们公司的传统，其中的主要逻辑，是我在N年前帮他们做了一个项目后的样板，后来的十几年，他们就一直使用我那套样板改过来改过去的用，已经用到了上百套设备上面了，所以工程师的能力juedui不会有问题，不至于做烂。
因为人手紧张，老板就求我帮忙跑一趟，项目在天津郊县，然后我就买了机票直奔天津，到了机场直接租了个车，开过去了。
到了现场，了解了一下具体的功能，故障现象，又问下主事的设备主管，这个功能以前有没有用过，是否好用？主管回答设备验收后一直在用其他的模式，唯独这个功能从来没用过，这是Zui近生产计划改变，才需要用到，然后用了就发现不能用。
然后我就问，全工在当时调试的时候， 这部分功能有没有验证过？答：好像没有。
然后我就明白了。因为这部分功能不是主要的功能，就有可能调试时没有注意到里面的变量使用，留下了bug。
打开程序， 找到相关的程序块，顺着逻辑捋了一下，再查一下变量的交叉引用，很快就找到了一个使用冲突的M变量。改了一下，再让客户开机验证，立马好了。
前后不过半小时。
然而天色已晚，工厂还在远郊区，客户给我安排了宿舍， 让我住了一晚，第二天买了机票回家了。
花费两天时间，往返机票费租车费近2000元， 就解决了一个M点的疏漏问题。什么叫痛？这就叫痛。
前面的工程师为什么离职？常年出差，常年除了干工程项目，其余的时间就是天南海北没完没了处理这些类似的问题。基本上来说，一年当中，就很少有老老实实呆在家里朝九晚五上班的时间。因为公司的运转离开了你，所以也不能给你晋升的机会，所以就只能十几年几十年如一日的无限重复这样的工作。
换谁谁不痛？如果还不能理解其中痛点的，我们接着往下看。
有人会质疑说，这不就是一个粗心的问题吗，只要小心一点，仔细一点，现场调试的时候别偷懒每一个功能都顾及到，都测试到，就不会出这样的问题了。
我只能说，这样的想法太幼稚了。客户生产系统一旦有可能运行，就会全力保障生产，就没有机会配合你做全方位调试。如果要调试辅助功能？等条件吧，十天半个月的，生产有了条件，再给你机会试。然后怎么办，项目正常的调试也就十天，你在哪儿再干等10天等条件？像我去天津处理的这个功能，客户放了快两年才用得到，才发现。你猜他们会给你机会？
完全细心的人有没有？有。这位工程师的主管领导，我的徒弟。那就是个非常极度细心的人，比我要细心100倍。他做项目的时候，每个项目，每个点位，他都要重复4-5遍的审核，校对。多少次不无得意的跟我吹嘘，他干过的项目juedui稳定可靠，很少有离开后再次去第二次的。赢得了客户极大的信任。
然而这其中的代价呢，他媳妇时常抱怨，为了做项目，他十几年每天都是熬夜到后半夜1-2点。年纪虽然还不大，然而十多年前就早就满头白发了。
这苦不苦，痛不痛？
然而痛点结束了吗？没有。
像上面离职的工程师的工作状态应该是大有人在吧？然后大家工作十几年如一日，觉得辛苦，就希望老板涨工资，涨一两次还不行，zuihao是年年涨，每年涨一次，翻倍。这种要求非常合理，可以理解。
然而，站在老板角度， 十年前的你和十年后的你，工作内容是一样的，工作量是一样的，为公司的贡献也是一样的，而十几年下来，市场形势可能已经逆转， 采购成本大幅度提高，项目竞争厉害，拿到项目的利润已经今非昔比了。简单说你为公司创造的效益并没有提高，反而有可能有所减少，十几年老板肯定已经为你涨过几次工资了，你这儿还狮子大开口，还不满足，还继续翻倍的要， 老板那儿都想开了你，换个刚毕业的年轻人来呢！人家工资要求可没你那么高。
你可能会说，切！新毕业的大学生啥都不会，怎么能赶上我一个十几年工作经验的老工程师？然而你好像忘了，十几年前，你也刚毕业，老板重用你，还不是照样顶下来干到现在？
更何况，前面的设备工艺没那么成熟，现在早成熟的透透的了，根本用不上这样富有经验的dingji高手了。
所以你如果为工资收入感到痛， 老板同时还为你收入高，贡献不匹配也在痛。如果现在还不痛，那就终有一天被裁员了，才真的感到痛吗？
要解决Zui后这个痛点,可不仅仅是减少bug就够的。通常在职场上，这唯一的途径是升职。工作中做出一定的业绩，被领导赏识，然后有机会提拔，上升到管理层，就可以极大程度跳离出差长工资低的苦海。然而对大部分纯粹的技术人员来说，通常不谙人情世故，因而很难有机会做管理的。那么唯一的途径是提高自己的工作效率。
比方说， 如果你是车间的车工， 你原本一小时能加工10个零件， 如果你肯动脑，善钻研，设计一个好的工装，一小时能加工100个零件了，不光自己的效率提高了，别的车工使用了你的工装后，效率也提高了，这些所有人的提高的效率，都是你的业绩。 那么公司为你涨工资提待遇是水到渠成的事。
而对于自动化工程师的工作来说，这个工装就是程序标准化。而其实对于有机会升职到管理层的，其zuihao的业绩也是为公司打造一个标准化体系。
通过建立公司设备程序的标准化体系，可以大幅度的提高工作效率，减少出差时间。
然而很多朋友暂时还没有能力建立标准化，有些可能连标准化的意思都不知道。我们所指的PLC编程标准化，不是去跑到PLC厂家为他们制定一套通用的标准化工具，直接嵌入到PLC厂家发布的软件系统中，从而限制PLC的使用者的编程方式， 以逼迫他们不能任性的使用全局变量， 不能写垃圾程序，没办法写出低效率的程序，被逼无奈只能设计出来高效率的标准化程序。
我们所说的PLC标准化编程方法，是指工程师把PLC作为工具，在所产出的作品，即你的设备程序，使用标准化模块化的方法搭建而成。如何叫做标准化模块化，不是你程序中把功能分成了若干个模块单元就可以的， 而是这些模块要能重复使用。即一旦开发完成，在本公司，本行业将来的大多数项目中，都可以直接简单使用。
简单到什么程度？
简单到Zui高jizhi，完全按照高内聚低耦合的目标，留给组装环节的工作量只剩下简单耦合，这种耦合没有任何技术含量，任何一个没有设计基础的电工，应届毕业生，办公室文员，都可以通过30分钟的培训，就可以完成。
那么，在Zuijizhi的情况下，一旦对某个工艺设备的逻辑开发成熟，后面的工程就不再需要工程师到现场出差，现场的安装工人按照设计部门给付的设计资料，稍微整理下装程序即可。下装后程序逻辑即可可靠运行，不再需要试车， 不再需要现场调试。
当然，上面所述是zhongji目标。在zhongji目标达到之前，工程师可能还需要偶尔出差，有可能只是为了到场安抚客户，让习惯上看着工程师调试动辄一个月的客户心理有些安全感。然而这时候的出差，对工程师来说基本上就是商务旅游了，没有什么压力， 去了以后大部分时间也就协调配合。时间也极短，原本一个月两个月的调试时间， 现在3-5天就完成了。
然后， 原本一个工程师，一年能干5-6个项目的，现在一年干20-30个也不在话下。而且劳动强度还降低了。这种情况下，这样的高效率，老板如果不给涨工资，合天理吗？
标准化编程方法，其实不是一种什么思想，他的实现方法很简单， 4个字，面向对象。如果懂的人自然早就已经懂了。
