本文接《為什么我離開了PLC編程行業(上)》內容。
在截止日期前一周，當大部分故障排除工作完成時，外部工程公司的項目經理提出要求，在PLC程序中實現手動模式：必須能夠在顯示屏上輸入代碼，選擇電機、泵、閥門，將這些設置為手動模式，并切換這些執行器的輸出。這是一個巨大的變化，為了實現這一點，我必須將所有輸出執行器移出單個步驟，并在將位輸出到實際執行器之前，將其與條件自動/手動模式位相結合。更改這將非常耗時。我當然提出了反對意見，但項目經理堅持要求必須加入這個手動模式。我正考慮給高級工程師打電話。
為什么我沒打呢？我在想……這種整個編程方法根本毫無意義。中央步進控制FB寫得非常緊湊，雖然你可能會在PLC中使用極端智能的編碼來節省空間，并允許使用更小的PLC型號，但節省空間就會寫出無法閱讀的代碼，然后又浪費更多空間去寫冗余代碼，這是沒有意義的。我不得不花費數月時間輸入所有這些條件和執行器的列表，這既令人沮喪又耗時，而且最終證明在需要更改時非常不靈活，就在我要做的第一個項目中就遇到了這個問題。中央步進控制FB沒有按預期工作，這非常奇怪，因為如果它到處都在使用，那么它應該能夠正常工作。在截止日期前一周才提出手動模式的要求，這完全出乎意料。如果這種編程方式到處都在使用，項目經理怎么可能不知道這個請求將意味著需要更改編程呢？現在我知道，我應該要求把這些要求的更改寫在紙上，這樣就不會有任何爭議了，但請記住，我剛從大學畢業，我不知道該如何處理這種情況。但回到問題上：為什么我沒有給高級項目經理打電話？再想一想……這五個月來，我一直在輸入這些無聊的條件和執行器的列表……我真的想把這個作為職業嗎？
我記得我在大學期間參加的PLC課程。我們有做過這些PLC編程練習。因為我在高中時就已經做過一些PLC編程，所以我知道有一種簡單的方法可以避免復雜的梯形圖邏輯編程：只需使用標記定義狀態，當滿足下一個步驟的條件時設置下一個標記，并使用反轉標記來重置前一個步驟的標記，很容易做到。我們的小組是所有小組中最快完成這些練習的。當老師發現我使用這種方法時，她給我布置了特別的作業，要求我不能使用這種狀態編程方法，以讓我改掉這種編程習慣！現在，兩年后，我在這里，面對著這一大堆復制的代碼，根本沒有更改的余地，因為如果我需要在一個步驟FB中更改某些內容，為了保持一致性，我必須在所有步驟FB中都進行更改……這不是很諷刺嗎？這顯示了基于狀態的編程實際上是多么低效和不靈活。我必須做出決定。
我評估了更改以允許集成手動模式而無需重寫所有內容的可能性。有一個解決方案：你可以在當前掃描周期中再次重寫輸出，因為緩沖輸出只有在掃描周期結束時才會寫入到實際輸出中。這是一個糟糕的設計，因為現在你必須跟蹤PLC程序中哪個輸出是實際寫入的。這可以避免重寫所有的步驟FB，但有一個問題：我必須避免程序在手動模式下跳轉到下一步。不運行中央步驟控制FB是不行的，因為有些輸出依賴于步驟FB內的輸入：這是一個Mealy型狀態機，而不是Moore型。還剩下兩個選項：在每個步驟FB的下一步中添加手動條件，但這樣做我必須更改每個步驟FB。因此，重寫中央步進控制FB的代碼以避免在手動模式下步進是剩下的最后一個選項。這花了一天時間，實施后我沒有遇到任何問題。
然后是對最新代碼的測試，因為我必須添加這個手動模式代碼，而且我們只剩下一周時間了，我們必須熬夜進行測試和故障排除，直到每天凌晨三四點。這包括在比利時奧瓦爾附近阿爾登地區冬季可能最冷的酒店房間里夜間編寫代碼。請注意，如果外部工程公司的項目經理沒有要求手動模式，這個項目上周就已經完成了。周日下午，也就是截止日期的前一天，它準備好了，在短短5周多一點的時間里，它已經完全編程、實施并測試完畢。
周一早上，我所在公司的部門主管給我打電話，詢問項目的進展情況。我回答說我們遇到了很多問題，但項目已經完全實施并投入使用了。他要求我明天到現場去。第二天他并沒來現場，這讓我感到奇怪。那天我還與外部公司的項目經理通了電話，那次通話中并沒有提到什么緊急的情況。
那天晚上，我被叫到了人力資源部。人力資源部的人說他們聽到了關于我的一些不好的事情，說我很固執己見。之后我一直在問自己這些問題：難道我沒有向外部公司的項目經理抱怨過他們沒有提前要求手動模式，導致我不得不重寫步驟控制功能塊(FB)嗎？難道我沒有向她解釋過我必須更改步驟控制FB才能讓手動模式正常工作嗎？為什么部門主管沒有問我對發生的事情的看法？為什么截止日期剛好設定在我6個月試用期結束的前一天？為什么部門主管一開始就沒有為這個項目指派項目經理呢？
一些觀察：我很確定部門主管沒有看過我的代碼，因為：我是在巨大的時間壓力下決定重寫這個步進控制FB的，而且這些更改可以很快恢復。我說的只是一頁AWL代碼！我沒有告訴他，所有的更改都只在我的筆記本電腦上，直到他不在辦公室的最后一天。此外，我還記得有一次部門主管非常粗略地審查了我的代碼，只花了最多10秒鐘，還有另一次他處理了一個5周的工作，他說他可以在一個周末完成。這絕對是我職業生涯中遇到過的最糟糕的雇主。他沒有提供任何指導，只是利用我來輸入成千上萬行枯燥的代碼。
這些事件讓我重新考慮了我的職業生涯。很可能我只是被雇來做那些枯燥的錄入工作，以減輕他們的工作負擔。顯然，這種編程方式的真正意圖是為了讓某人能夠輕易地被替換，這在PLC編程中是非常容易的。自動化領域是一個非常保守的領域：公司對PLC技術的主要擔憂是其可靠性和可用性。公司寧愿堅持使用已經證明可靠且不僅替換零件容易獲得，而且程序員數量也眾多的昂貴PLC技術(提示：西門子)。很多PLC程序員只是技術人員，只是用于現有基礎設施的維護。這意味著我必須與很多愿意接受更低工資的人競爭。這顯然不是一個最好的工作環境，所以我決定換一個領域。
我決定換到網絡領域。互聯網剛剛開始興起并變得流行起來，這是一個充滿新技術且正在成為主流的令人興奮的新領域：TCP/IP、思科、網絡瀏覽器、防火墻、Linux、Windows NT、代理服務器、Exchange、電子郵件。
我申請了一家翻譯公司的初級職位，負責管理公司的網絡和服務器。兩周內我就找到了新工作，而且薪水更高。我記得我去應聘的那天，當我走進大樓的門廳時：我看到大樓是這家公司與另一家公司共享的。左邊是翻譯公司的標志，但右邊竟然是我過去五個月一直在為其工作的那家外部工程公司的標志！……
說真的……(想想看，我們國家有十幾萬家公司！)
所以你可以想象，一年后，我遇到了去年一起工作的項目經理。我問她項目后來怎么樣了，我寫的代碼是不是都被扔掉了？她說：“沒有沒有，你的代碼里有很多非常棒的想法！”
如今，當我再次審視自動化行業時，我看到了這些工業PC，它們在Windows機器上運行著實時內核，速度比PLC快得多。但當我檢查編程環境時，發現同樣的編程技術仍然適用。雖然實施了一些改進(比如IEC 61131-3、面向對象編程等……)，但當我嘗試屏幕編程時，我想起了在SCADA工作時那種同樣的恐懼：處理GUI元素是多么的不靈活。
如今，當我審視專業的IT世界時，我看到了所有這些技術正在以非常結構化的方式改變著這個領域：大規模葉脊數據中心、虛擬化、融合、去重、Docker、軟件定義網絡、微分段、軟件應用、Puppet、云網絡等等，不一而足。在編程方面，Python正在向前發展，并推動著像lambda、列表推導式、生成器、裝飾器等函數式編程概念。新的數據庫概念如NoSQL已經出現。非常快速的開發和交付流程被廣泛應用。下一代網絡技術物聯網(IoT)將更進一步改變格局：現在你將得到所有這些內置無線網絡的設備。然后還有數據科學和機器學習……
與IT行業相比，PLC行業缺乏新的PLC編程概念，而這些概念本可以極大地改變這個行業。原因顯而易見，維護和保養現有設備的優先級高于嘗試一些新的技術，并且需要冒著這種技術失敗時沒有支持的風險。它仍然是一個非常代代相傳的行業。所以，如果問我我還愿意回到自動化行業嗎？不，我不打算再回到PLC編程了，但對于那些愿意進入這個行業的人，請三思：“軟件正在吞噬世界”。這種情況會持續多久，我不知道。
后續
自從我寫下這篇文章后，我一直在問自己，我究竟在什么時候能夠意識到這種微觀管理其實是為了控制，而不是為了支持管理。第一件奇怪的事情是，項目工程師在逆向工程狀態圖，因為他本可以向外部工程公司索要這些圖，但這僅僅表明了一次遷移。我收到的第一個實際暗示是在我前往設施之前與經理的最后一次通話中。在解釋完我要做的事情后，他突然跳到另一個話題上。他說在這個項目之后，他會繼續和我一起工作，將他基于狀態的S5編程方案遷移到新的S7編程語言。當他在解釋這件事的時候，我問自己：“為什么你現在要談這個？”S7語言大多是向后兼容的，所以他可以在10分鐘內遷移他那只有20行的步驟控制塊。不幸的是，我在測試期間忘記了這次簡短的對話。回想起來，現在很清楚這次遷移工作是多么微不足道，這也直接表明他只是想讓我相信他在項目結束后還想繼續雇用我。這件事發生在我職業生涯的早期，當時我以為發生在我身上的事情都是正常的。現在，隨著我的工作經驗越來越豐富，我可以說我的第一直覺大多是正確的，而自我懷疑往往是我背叛自己的原因，換句話說：當事情不合邏輯時，背后一定是有原因的。
現在，這些事情給我上了一堂人生課。看看這些事情：經理真的從這種策略中受益了嗎？實際上沒有：他不僅解雇了正在從事他項目的工程師，而且最可能的結果是項目經理接替了這個角色，不得不“糾正”一切。我知道這件事的結果，他在我被解雇后的第二個月就決定離開公司了。所以項目經理只是看了看我的工作就決定離開了。巧合嗎？我認為不是。對我來說，這開啟了我職業生涯中的一條新道路，我再也不會僅僅根據事情呈現給我的樣子來假設它們了。
作者：Jurgen Kobierczynski
