讓我們先認識到這是一個複雜且有時充滿爭議的話題。我還沒有遇到一個人對「最好的」程式語言以及可程式邏輯控制器（PLC）的學生應該知道和不應該知道什麼沒有強烈的看法。
這篇文章是我盡力提供平衡介紹的嘗試。我們將非常感謝您的幫助。您可以透過在下面的空白處留下您的意見和建議來幫助改進本文。
圖 1：具有整合顯示器的 Crouzet EM4 PLC 正在運行經典的「Hello World!」程式
什麼是 PLC？
PLC 是一種工業計算機，旨在控制工業設備和製程。PLC 內部是由中高階微控制器控制。使用光耦合器、堅固的半導體輸出驅動器和繼電器將這種精密緻的邏輯與惡劣的工業環境隔離。
PLC 可以是緊密的一體式或模組化設計，具有輸出、輸入和類比等功能的專用模組。這些 PLC 中最大的將包括偶爾向右擴展的模組，從而形成近 2 英尺長的 PLC。在所有情況下，PLC 都會根據 CPU 的速度和運算能力以及要控制的機器或流程的特定輸入/輸出（I/O）需求來與任務相符。
這個定義原則上仍然成立，但越來越過時。問題，或者我們應該說，未來，是 PLC 的跨學科方面以及現代處理所需的更強的網路功能。可以說，「工業 4.0」正在改變 PLC 的使用方式和類型，因為需要增加網路功能。我們還必須考慮增強處理能力的可用性。這使得視覺能力在最初的定義誕生時是聞所未聞的。我們也應該考慮使用例如 TensorFlow 這類需要進行深度學習的工具應用。
由此得出的 PLC 定義可能更合適：PLC 是一種智慧網路平台，旨在控制工業設備和製程。簡單的獨立機器與用於協調工廠的聯網 PLC 集合之間存在巨大差異。
有哪些語言可用？
傳統上，黃金標準 PLC 語言是由 IEC 61131-3 定義的。這包括：
- 梯形邏輯（LL）
- 功能框圖（FBD）
- 順序流程圖（SFC）
- 結構化文字 （ST）
- 指令表（IL）
帶有 LL 和 FBD 的圖形介面受到技術人員的歡迎，他們可以透過觀察圖示快速確定 PLC 的狀態。圖 2 顯示了代表性的梯形邏輯代碼。此 Modicon PLC 程式用於製程的單一按鈕控制。換個角度來看，從不同的角度來看，圖 3 展示了一個混合了 FB 和 SFC 區塊的 Crouzet PLC。
圖 2：在 Schneider Modicon PLC 上實現的梯形邏輯程式。
圖 3：Crouzet PLC 的除錯窗口，具有組合的 FB 和 SFC 區塊。
處理能力的變化加上網路和強大的視覺技術允許或可能要求程式語言的變化。我們還需要認識到，PLC 程式設計師通常是從電腦科學程式中誕生的。這些程式設計師對工業電腦應該做什麼和不應該做什麼有自己的一套期望。
Revolution Pi （Kunbus）提供了一個與傳統 PLC 不同的有趣的反例。該設備當然符合 PLC 的傳統定義，正如在深入了解 PLC 硬體展示中所探討的那樣。它也符合我們修訂後的彈性網路定義。最後，它對於電腦科學專業的學生來說是一個有吸引力的平台。
顧名思義，Revolution Pi 是圍繞著流行的 Raspberry Pi 處理器構建的。由於對延遲有一些限制，最終的機器具有廣泛的應用範圍。作為一個具有諷刺意味的例子，請考慮影片 1。在影片時間約 7分25秒，我們看到基於 Raspberry Pi 的 Kunbus PLC 用於製造額外的 Pi。
技術提示：延遲是一個術語，用於描述 PLC 對現實事件的反應速度。具有高速 I/O 的傳統 PLC 與內部高性能中斷驅動微控制器相結合，並經過適當編程，可能是高速機器控制的最佳解決方案。然而，這是一個小眾應用。許多機器和工業控製過程的延遲在 10 到 100ms範圍內都是可行的。此外，專用模組可能更適合高速製程的控制。一個例子是帶有編碼器來控制旋轉速度的馬達驅動器。 PLC 只需要向驅動器發送高級（網路）命令，而不需要處理逐ms的控制。
如果我們允許 Revolution Pi 被歸類為 PLC，我們的語言選擇就會大大增加。像 Revolution Pi 這樣的 PLC 現在幾乎可以用任何在 Linux 作業系統上運行的語言進行程式設計。這包括 C 和 Python 等傳統語言。 61131-3 語言可使用 CODESYS 等擴充來使用。有一些類似 Arduino 的程式可以在 Pi 上運行。 MATLAB 等程序是可行的。除此之外，還可以使用 Docker 等軟體環境管理工具。
影片 1 基於 Raspberry Pi 的 Kunbus PLC 用於生產額外的 Raspberry Pi 電腦。
哪些 PLC 程式語言被認為是強制性的？
讓我們換個方向，用一些確切的事實來緩和對軟體的過份熱情：
-
了解 PLC 是一個工具。它專為工業控制和自動化而設計。因此，它與公司的盈利直接相關。
-
事情可能會出現問題，需要技術人員將基於 PLC 的系統恢復到全部功能。
-
當技術人員對系統進行故障排除時，停機就會產生金錢損失。生產線每停機一分鐘，就會損失製造小部件的機會、勞動力的閒置時間、重新啟動流程所需的時間和材料的浪費，以及可能需要加班來彌補生產損失。您還面臨失去客戶善意的風險。
最重要的是，任何 PLC 採購或程式決策都必須全面做出，並適當地關注目前和未來維護系統的員工隊伍。
很明顯，程式設計師的宏偉願望與可靠的日常操作的底線要求之間存在著緊張關係。我絕不建議我們放棄先進的能力，但我們確實需要認識到系統和系統的數十年生命週期。
所有程式設計師都必須精通梯形邏輯！
讓我們仔細看看技術人員以及他們如何與工廠中的設備互動。假設我們有基於 PLC 的系統，該系統已經調試並運行了足夠長的時間來解決錯誤。您是否同意技術人員的大部分故障排除時間都專門用於解決電線、連接、感測器和執行器問題？您是否也同意軟體在可能的故障清單中排名靠後？
假設您同意前面的兩個陳述以及前面的底線約束，那麼您必須同意像技術人員一樣思考是重中之重。
技術人員根據梯形邏輯進行思考，因為這是他們生活和工作的世界。他們大部分的時間都花在解決 PLC 外部的問題上。
在我看來，任何想要成為 PLC 程式設計師的人都必須了解梯形邏輯。這是一個實際的現實，需要了解如何將 PLC 物理地連接到更大的系統中。與系統服務人員建立共同的思維方式（書寫語言）也是必要的。
技術提示：知識產權（Intellectual Property ，IP） 和責任的概念使程式設計爭論變得複雜。在理想的情況下，每個技術人員都可以使用 PLC 和軟體開發工具。這不是一個合理的假設，因為有時您作為程式設計師會保護您的智慧財產權。對於某些 PLC 開發平台，此程式碼鎖定功能是啟動新程式的第一步。有時，出於責任和保固的原因，您不想放棄「代碼修改的密鑰」。因此，PLC 對於技術人員來說就變成了一個黑盒子。他們擁有的唯一資訊是內建 LED 指示燈（非通用）或故障代碼、文字或編碼到 PLC 中的內建測試 （Built-In-Test）。這種限制進一步增強了學習梯形邏輯並與技術人員擁有共同語言的論點。你的底線取決於它。
產業趨勢是什麼？
這個 PLC 討論讓我想起了微控制器的情況。隨著所有新奇的 32bit 和 64bit 設備的出現，人們預測 8bit 設備將會消失。
不。
8bit 微控制器仍然充滿活力。事實上，新設備的技術進步倒推到了舊的 8bit 設備。結果是 8bit 微控制器速度更快，功耗更低。軟體工具的可用性提高還有一個額外的好處。
相同的條件也適用於 PLC。可以肯定地說，傳統的獨立 PLC 不會消失。它性能穩定，將陪伴我們數十年，並可從原始設備製造商（OEM）或第二來源獲得替換零件。
同時，我們需要認識到計算能力的增強和深度學習的可能性已經改變了格局。可以肯定地說，新的程式語言和網路軟體部署技術將變得越來越普遍。
結論
顯然，PLC 程式設計需要考慮許多因素。對於適合所有程式語言的「最佳」一種尺寸，不可能有簡單的答案，就像不可能有一種適合所有 PLC 的尺寸一樣。相反，每個應用程式都有細微差別的考慮。
我可以鼓勵您與我們的讀者分享您的想法嗎？您遇到過哪些挑戰？你是怎麼堅持下來的？
哦，別忘了 - 透過學習如何用梯形邏輯進行編程，與未來的技術人員使用相同的語言。