即要搞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個字， 面向對象。如果懂的人自然早就已經懂了。