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