這倆問題我今天嘗試用一篇文章講清楚。

先說一個結論， 前一個問題是后一個問題的基礎，沒解決前一個問題，就不可能實現后一個問題。

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

然而標準化編程，其實是一種能力。 

拿我自己來說， 我在十幾年前就開始研究琢磨標準化編程的方法，然而自己一直沒能全部打通。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廠家沒有任何關系。企業是否做到標準化， 與工程師個人的效率，工作量，出差辛苦程度，薪資水平這些所有加起來的痛點有關系，而與我并沒有多少直接關系。 

像Zui開始的故事里， 那位離職的工程師， 在外面飄了2年之后，又回來跟老板聯系，有意再回公司工作，繼續出差也愿意。然而被老板很冷淡的拒絕了。他當初是和另一個工程師幾乎同時辭職的， 現在，這樣的崗位不缺人了。因為他們實現了標準化設計，就那些老是大同小異的重復性的工程項目，一個工程師足夠了。有一些小項目，電工在現場也就干了。都不需要工程師去了。

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