作者 |?Jon Breen

有時為了解決眼前問題，可能需要對可編程邏輯控制器（PLC）進行編程，但從長期來講這可能會帶來問題，在原程序員不在的情況下更是如此。

生產停滯讓客戶每小時損失10萬美元，他們已經打電話給可編程邏輯控制器（PLC）程序員，以盡快解決問題。在查看最近的航班后，程序員啟動了一個虛擬專用網絡（VPN）。一個小時后，程序員看到了一個“全新”的程序（對他們來說是新的），數千行梯形圖邏輯沒有標記描述，命名規(guī)則不清晰，代碼已經復制粘貼了上百次，而這一切都在一個龐大的例程中。這可能會導致該程序員弄不清楚，原來的編程人員究竟想做什么。

一般來說，PLC程序員傾向于用自己熟悉的方法編寫代碼以便立即解決當前的問題。人們很容易忽略未來必須維護這些代碼的“可憐蟲”。如果不注意，屏幕前被罵的可能就是我們。以下四個建議可以幫助你避免成為抱怨對象。

01

不要復制和粘貼重復的邏輯

比方說，有兩個線圈需要依次激活。一個用來打開第一個梯級，也許是一個定時器，然后是另一個梯級，用于開啟下一個。除了將標簽名稱從“CoilOne”更改為“CoilTwo”之外，梯級內容都是相同的。我們都用使用這樣的代碼，因為事情總是這樣的，但那是只有幾個梯級的情況。但如果你有50個線圈，看看會發(fā)生什么事情？在你開始敲擊Ctrl+V之前，可以先仔細思考一下。

尋找重用代碼的機會。回路是個好幫手。AOI、子例程，甚至是基本數組都可以加快開發(fā)時間，使代碼更簡潔，并讓未來的維護更容易。如果遇到邏輯變更？您不必粘貼50個修復程序，只需對子例程進行更改，一個小時既可完成?？蛻粝氚?50 個線圈改成 100 個？如果做得對，您通常只需將 "Coil_Count "或其他類似的標簽從 50 改為 100 即可。

02

切忌使用難以辨認的標簽名稱，

且不加任何標注

“tmrdelay”–“Timer”和“delay”是多余的。該延時的功能是什么？是用它來點燈，還是等待一段安全時間后再放下重壓機？

很顯然，“AB_XGI:I.Data[1]”是一個用于某些連接設備的數據結構，但在主例程中如果這樣引用，代碼就不清晰?！癴ireRobotMove”，這是指哪個機器人？哪一個動作？我需要滅火器嗎？這些標簽名稱本身并不是無用的，但如果沒有情境信息，它們就沒有多大意義。

應當使用描述性標簽名稱。名稱應該說明標簽的用途。此外，還應注意格式。即使是“tmrDelay”或“tmr_delay”也許會更好。沒有人需要去猜測如何分割這個詞。

在標簽和梯級中添加說明。一個簡單的緩沖區(qū)例程或別名，可以將“AB_XGI:I.Data[1]”轉換為更有用的東西，如“partX-Pos”?！皌mrdelay”可以變成“tmrDriverReady”。更好的做法，是在標簽或橫檔上添加描述，解釋它的用途。

應當使用合適的拼寫。有沒有試過搜索所有處理位置數據的標簽，看看其中是否有一個名為“poision”的標簽？

03

不要忽略程序結構

沒有人愿意看到一個名為“Main”的例程有200個梯級，它涵蓋了從輸入/輸出（I/O）到工藝流程的所有內容。

使用例程和用戶自定義的數據類型（UDT）（或“結構”，具體取決于制造商）來保持代碼組織有序。只需將代碼分解為幾個名為“Camera”、“InputBuffer”和“Faults”的例程，就會使代碼更具可讀性。不需要篩選50級不相關的邏輯——如果你需要Camera邏輯，請直接搜索Camera例程。

UDT非常有用。它們允許您對數據進行分組和命名，即使是在數組中也是如此。例如，如果你的視覺系統返回了很多位置數據，你可以創(chuàng)建一個帶有“X”、“Y”和“Z”標簽的“位置”UDT，來保持代碼組織有序。帶子標簽的“point1”遠遠優(yōu)于“point1X”、“point1Y”和“point1Z”。更容易重命名、交叉引用和填充到數組中，并進行迭代。

“通過使用數據結構、一致的命名規(guī)則和描述性注釋，可以為PLC編可維護且靈活的代碼?！?/p>

04

不要過于樂觀

“這個項目只需要幾個月的時間。客戶確切地知道他們想要什么。除了我，沒有人會看到這個”。或最容易出現的想法：“我會記得為什么這么做。”

▲圖：通常，PLC 編程人員都傾向于為自己編寫代碼以獲得即時解決方案，但這可能會帶來長期問題。

記住墨菲定律：“任何可能出錯的事情都會出錯。”這一點實際上是為了強調所有其它事情的必要性。積極的態(tài)度很少是壞事，但如果沒有任何問題，我們可能就沒有工作了?？蓴U展、可讀和可維護的代碼是墨菲定律的致命對頭。

為迎接未知的未來，我們能做的最好的事情就是注意上述PLC編程該做的事情。通過使用數據結構、一致的命名規(guī)則和描述性注釋，有助于編寫易于維護和靈活的代碼。這樣，未來每個人都可以更輕松讀懂程序。

當您的客戶需要添加新的按鈕時，他們會向您表示感謝。你的同事會感謝你有一個易于遵循的結構。但根據我的經驗，受益最多的人可能是你自己。因為說實話，當我抱怨代碼時，發(fā)現50%都是我自己編寫的代碼。

不要只是能運行就好?；c時間把事情做好?，F在越聰明地工作，以后的維護就更輕松。

關鍵概念：?

■?PLC程序員傾向于編寫代碼解決眼前問題，而不是制定長期解決方案，這對那些后來介入工作的人來說可能是個災難。

■?PLC編程要避免的一些事情，包括復制/粘貼重復的邏輯和使用不帶標簽的無法識別的標簽名稱等。

編輯：黃飛

?