作爲在工控自動化行業侵淫已久的工程技術人員，無論在程序編寫，抑或現場處理都會總結出自己的一套，本文作者周舟，2001年開始接觸PC控制和運動控制，先後就職於海天集團、施耐德電氣、倍福自動化，寧波致迪自動化，以技術人員和市場人員的身份經歷了浙江機械製造的重要發展階段，也總結出自己的一套PLC編程經驗，與大家分享。
上次看了鄧李老師的文章《如何編寫優質的PLC/PAC程序？大神的這份作業建議你抄一下》頗有些感受。工作快20年，多少寫了些程序，大多是和機器相關的，記得本科的畢業設計是用VB+數據採集卡寫了一個拖拉機發動機噴油嘴的彈簧測試，碩士課題用C在Linux下做了一些代碼，而畢業後在海天，和師傅一起，繼續在Linux下用C和QT堆了一臺注塑機的控制器出來。
01
第一次接觸PLC，是在海天公司給一臺雙色注塑機增加一個轉軸功能，這個功能注塑機電腦上沒有，所以外加了一個PLC，記得當時用的是三菱FX，這是我接觸的第一個PLC，當時因爲供應商提供了PLC、伺服電機、減速機等一套產品，所以程序也就讓供應商寫了。
到了倍福之後，由於整個辦事處就我一個人，處於什麼都乾的狀態，所以除了銷售工作，也做技術支持。記得第一個項目是上海的同事寫的代碼，同事來現場一次，後面的維護我接過來。所幸TwinCAT2這軟件比較簡單，一來二去自己就上手了。
後來慢慢地也給客戶寫一點DEMO，用來給客戶解釋爲啥IEC61131-3是一個簡單的東西，不像想象的那麼難，不要一想到ST語言就想到高級語言，等等諸如此類的問題。寫着寫着，也有了一些心得。
在聊聊這些心得之前，先說點題外話。我做過兩件和工作不太相關的學習，一次是讀研究生時，一個培訓班來學校推銷ISO內審員的培訓，當時因爲好奇去報了名，花了幾百塊錢聽了一堆ISO的知識，記得講課的是一位老幹部。另一次是剛上班時，去報了一個計算機高級程序員的考試，看了幾個月書，離及格線差了那麼一大點（不是一小點）。但這兩個事情，對我的影響比較大，ISO的學習，讓我理解了凡事要有流程，流程要有標準，標準要有數據，數據要可追溯，這爲後來理解工業4.0打下了基礎，而高級程序員的考試，讓我學到不少IT的知識，尤其是軟件工程方面的知識，對於構建一個大的程序，還是有幫助的。
下面的心得，和這兩件事情，有比較大的關係，說穿了，就是多做紙面工作。
02
在寫代碼之前，我會先建個EXCEL表格，大約有這麼幾項（這裏我虛擬了一個立體車庫的項目，因爲每天到辦公室都會和立體車庫打交道）：
1、IO表，輸入輸出的模塊型號，模塊的位置，每個模塊上每個點的定義，以及外面接的是什麼元器件。對於一些電氣CAD軟件，會自動生成這個表，但我們還是建議用EXCEL做一份，以便存檔。
2、變量表，一部分變量是有地址的，比如需要和上面提到的IO表進行對應，比如Modbus通訊。Modbus通訊需要定義變量地址，而IO對應的不需要在程序中指定，只要在系統配置中和硬件進行連接。另一部分變量是沒有地址的，但也不能隨便定義，要有一定的規則，以便閱讀。
3、結構體（Structure），結構體的設計，可以放在變量表之前，爲了提高效率，我們會設計一些結構體來做數據類型，比如一個氣缸，就可以設計一個結構體來表述，這個結構體會包含氣缸的方向，磁性開關狀態，以及兩個方向的超時報警時間。在使用到氣缸時，就可以用這個結構體類型來直接定義氣缸，而無需去定義每個氣缸設計的變量。
必要的話，可以設計枚舉變量，用來表述機器的狀態。
4、POU名稱（Program Organization Unit程序組織單元）。POU有三種類型：程序（Program）、功能塊（Function Block）、函數（Function）。在規劃階段，程序和功能塊的構建是很重要的，功能塊會降低很多重複工作，從而避免一些普遍性的錯誤（當然，錯了也就都錯了），程序的調用、狀態的切換是否清晰可控，則決定了整個項目是否足夠強壯，並可持久改進及維護。
5、工藝說明，包括各個工作步驟、步驟的銜接、條件的轉換等。這個步驟，可以在EXCEL中做，也可以用word、PPT，但相比之下，EXCEL可能是個更好的選擇，因爲EXCEL的紙面是沒有限制大小的，而word和PPT很容易遇到編輯範圍太小的問題。
當然，也可以在紙張上來畫。我個人建議每個項目備一個A4的本子，和EXCEL配合使用。
做完這個表格之後，我習慣將變量表直接複製到TwinCAT中，因爲在EXCEL中，很多重複工作可以直接選中表格單元進行拖拉複製，比如註釋的“（* ”和“*）”，以及末尾的“；”，都是直接複製單元格的，而對於一些帶序號的變量，如X0-X7，順序複製即可，這會在大幅度減少工作量的同時，降低變量編寫出錯機率。
在程序編寫過程中，除了用於for循環的累加數，以及用來調試時的一些標誌之外，如果要增加有實際意義的變量名，必須先在EXCEL裏增加，再複製到程序中。這有點強迫症，但事實證明，這個有用。
接下去就是建立各個POU，對於功能塊，要寫好輸入變量和輸出變量，而函數只需要有參數即可。寫完了每個POU，記得在每個POU的主體敲個"；"，這樣，即使我們一句代碼也不寫，也是可以編譯通過的。如果這時候編譯不通過，可以看看是不是哪裏有手誤了，因爲這時候能錯的地方都是系統保留字，或者是忘記敲"；"，註釋的括號少了之類。
接下來是不是寫代碼？不是的，是先寫註釋，而且是全面註釋，即在各個功能塊中，先寫好註釋。在TwinCAT中，一個程序塊只需要一個“；”，即可編譯通過，我們上面已經敲好了"；"，所以不用擔心沒有代碼會造成程序不能編譯。
我們回到前面第4點，如果流程圖已經畫好，那我們就把流程圖搬到編程環境中，還是按照從大到小的原則，我們先把步驟編好，具體每一步裏面做什麼，可能遠不如步驟之間怎麼切換銜接來得重要。所以，在這個過程中，我們還可以用註釋來替代代碼，但別忘了在各種for、case中加上“；”。
最後一步，讓我們在所有註釋的地方，把代碼寫上。然後，編譯一下。
如果有人可以把PackML的文檔看一遍，會發現裏面就有關於狀態切換的圖表，如果有興趣，可以去找下PackML的文檔。
如果你用的是TwinCAT或者Codesys的環境，我建議在寫EXCEL表格和畫流程圖的時候，順帶把人機界面的草圖也畫了，我覺得集成人機界面的開發環境就是自動化工程師的大救星。人機界面和PLC在同一個環境內，意味着可以隨時看到工程師想看到的內容，比如在調試時，需要看多個變量，那建在人機界面上會方便很多，不需要在程序中在線觀察。
人機界面和PLC的集成，除了大大提高自動化工程師的幸福感之外，也會極大激發自動化工程師的創作慾望。比如有些DEMO，我會將邏輯動作的條件和輸出狀態都放在畫面中，這樣可以很清楚看到一個邏輯動作沒有執行的原因，比如某幾個動作有先後，那做個定時器或者多個定時器，將這些定時器的輸出放在同一個畫面，就可以明察秋毫了。
寫完了程序，機器也動了，我們再來做一張表，就是修改記錄，在這張表裏，我們寫下，某年某月某日，爲了什麼原因，我們改了哪個程序，怎麼改的，修改後我們怎麼測試的，測試的效果如何。
而修改的程序，不建議直接在原程序上改，可以建一個新的POU，也可以在POU裏寫一個新的action，在對應的調用處改掉調用名字即可。這樣，即使新的程序出了問題，也很容易改回（RollBack）到原來的程序。而新的代碼中，記得在頭部寫好註釋。
03
至此，我們回過頭來看看，我們獲得了哪些好處：
1、我們有了一個清晰的名字列表，包括變量的、IO的、程序的
2、我們有了一個清晰的結構
3、所有的問題會有據可查。
上面這幾點是針對程序本身的益處，而對於項目和企業而言，則有更大的意義：
1、通過分解，將代碼部分的工作量比例降低了，這種逐步聚焦的方式，可以讓工程師把精力放在最關鍵的地方。
2、便於溝通，在代碼之前的這些工作，都可以和其他人共享，比如IO表部分可以和電氣工程師以及電工溝通，程序流程部分可以用來和工藝工程師溝通。
3、便於維護，在移交給其他工程師，或者多人開發同一項目時會方便很多。如果沒有註釋，基本上工程師自己都會忘記原來寫的什麼。
4、便於更換平臺，當需要更換一個控制器平臺時，會發現，大部分工作是相通共用的，這會在切換平臺時節約大量的時間。
本文用了一些IEC61131-3的概念，關於IEC61131-3的書很少，推薦彭瑜老師和何衍慶老師的那本《IEC61131-3編程語言及應用基礎》，機械工業出版社出版，這本書我買了應該不下三十本，用來送人。記得在倍福10週年慶典那天，公司邀請了彭瑜老師，恰好慶典在人民廣場附近舉辦，席間跑步前進到福州路的上海書城，居然買到了那本《IEC61131-3編程語言及應用基礎》，請彭瑜老師簽了個名，留作紀念。
另外推薦林銳博士寫的《高質量程序設計指南 C++/C語言》，這本書有人不喜歡，覺得這本書水份太多，乾貨太少，但讀起來還是比較輕鬆的，這本書出到了第三版，目前在網上有很多二手的在銷售，也有一些電子版的，建議找來讀一讀。
後記
寫這篇文章的原因，一方面是看了鄧李老師的文章，也想談談自己的心得，另一方面，也是看到隨着工業4.0的普及，以及我國OEM製造業正在向高端發展，PLC程序方面，也慢慢向IT方向發展。
相比於PC或者網絡軟件，自動化程序有幾個特點：
1、使用對象比較窄，這造成了對程序的質量要求、功能要求都不是太高，機器能開就行。
2、代碼量小，因爲1的原因，以及機器本身的特性，PLC的代碼量是很小的。
3、協作性很低，很多公司只有一個自動化工程師負責PLC程序，而且對程序質量要求很低，只要求機器能跑。
這些特點，造成了自動化行業，尤其是離散自動化行業，對於代碼的質量基本是沒有要求的。我記得大學時候買過一本《軟件工程》的書，開頭有個例子，是一個科幻電影裏的飛船計算機艾爾出了軟件故障的故事，隨着現在機械設備製造業的發展，機器的銷售越來越多，客戶的需求也變得越來越定製化，這種軟件的故障，在將來會慢慢出現，如何應對這個事情，唯一的道路，只能是從計算機行業去借一些經驗來。
我作爲一個銷售來寫這個文章，會有很多漏洞，但還是期望我的文字可以引起自動化工程師的共鳴，起到拋磚引玉的作用，大家一起爲未來做些事情。
--END--