PLC編程四大注意事項

作者 |?Jon Breen

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

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

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

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

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

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

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

且不加任何標注

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

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

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

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

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

不要忽略程序結構

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

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

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

“通過使用數據結構、一致的命名規則和描述性注釋，可以為PLC編可維護且靈活的代碼。”

不要過于樂觀

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