西門子代理商-PLC伺服電機驅動變頻器代理-吉林一級代理

商業控制器

CoDeSys

很多機器人控制軟件都是借助CoDeSys實現的，那么CoDeSys是什么呢？　

CoDeSys是德國3S公司推出的一款付費的軟PLC開發軟件，簡單來說，它包括兩部分：Development System和Runtime System。Development System就是用來編程的軟件界面（就像Visual Studio、Eclipse等軟件，也可以稱為IDE），設計、調試、編譯PLC程序都在IDE中進行，這部分是用戶經常打交道的；程序寫好了以后，就要把它轉移到硬件設備中執行。可是這時生成的PLC程序自己是無法運行的，它還要在一定的軟件環境中才能工作，這個環境就是Runtime System（也叫運行核），這部分是用戶看不到的。二者安裝的位置通常不同，IDE一般安裝在用戶的開發計算機上，Runtime System則位于起控制作用的硬件設備上，程序通過網線或串口線下載到Runtime中運行。　　

CoDeSys為什么要分成兩部分？Zui主要的原因是CoDeSys主要運行在嵌入式系統中，例如ARM或者DSP芯片。這樣的系統資源有限，不可能在其上建立龐大、復雜的開發環境，因而其開發環境和運行環境相互分離。因此，嵌入式軟件的開發方式一般是，在宿主機（Host）上建立開發環境，進行應用程序代碼的編寫和交叉編譯，然后宿主機與目標機（Target）建立連接，將應用程序下載到目標機上進行交叉調試，經過調試和優化，Zui后將應用程序固化到目標機中實際運行。當然，隨著芯片的性能越來越強大，如果選擇資源豐富的芯片，那么CoDeSys的開發環境和運行環境放在一起也沒什么問題。我們自己的個人電腦不就是編譯和運行程序都能完成嗎。 

CoDeSys在工業控制領域的應用非常廣泛，上面提到的很多機器人公司都使用了它的產品，例如KEBA、倍福、固高、臺達、廣州啟帆機器人、新時達機器人。3S公司只賣底層軟件，不賣硬件和上層應用程序，應用程序和硬件電路需要由用戶自己設計，3S公司負責將Runtime System移植到客戶的硬件上。Runtime System可以裸跑在硬件上，但一般是運行在操作系統上，配置操作系統也是客戶的工作。如果客戶要求，CoDeSys的IDE可以定制，換成客戶的logo和外觀，這就是為什么你會發現不同廠家的開發平臺長得不一樣，但風格又比較相似。當然，用戶也可以使用其它IDE，例如倍福就使用了Visual Studio，而背后的編譯器等內核功能以及函數庫仍然采用CoDeSys的方案。CoDeSys的Runtime具有強大的適應性，支持絕大多數的操作系統和芯片類型。

CoDeSys的IDE部分是免費的，你可以從官網下載體驗。真正收費的是運行系統Runtime System以及一系列的通信、運動控制組件。

CoDeSys采用.Net技術開發，其在設計之初就將功能劃分為若干組件模塊，例如總線協議棧、可視化界面、運動控制、安全控制等等，用戶可以像搭積木一樣選購必需的模塊搭建自己的系統，Zui后形成一個定制化的控制軟件平臺。一些初次接觸軟PLC的用戶可能對這部分感到陌生，但其實這種設計方式非常普遍。舉幾個例子，MATLAB Simulink的實時工具箱（Real-Time）就是這樣的工作方式，用戶在Simulink的圖形界面里通過拖拽設計控制程序，然后下載到真實的硬件中跑，可以在這里了解。還有像倍福也是這樣的使用方式，用戶在TwinCAT IDE里進行編程，然后下載到倍福的控制器中，控制器里面其實已經預裝了一個Runtime。西門子的STEP7也是一款IDE，它的PLC中也存在一個配套的Runtime。只不過西門子（包括日系PLC）的系統封閉而保密，外人不知道他的系統架構。

　　用戶編寫的PLC程序就像我們電腦里的應用程序，它運行在Runtime System上，而Runtime System又運行在操作系統之上。由于Runtime System位于應用程序和操作系統中間，所以又被稱為中間件（Middleware）。簡單來說，你可以把中間件看成是由驅動程序、基本的函數庫等等模塊組成的軟件系統。因為這些程序模塊主要與硬件或者底層軟件打交道，與用戶關系不大，所以被組織成了單獨的一塊。這些軟件呈現給用戶的是函數調用接口，也就是說你只需要會使用就行了，不用操心具體怎么實現，因為這些是驅動工程師和算法工程師的活兒。當然，大多數時候你也看不到這部分的具體實現，因為它們是以編譯后的二進制文件的形式提供給你的，根本無法閱讀，你頂多能看到一些頭文件，其中只是一些函數和變量定義，沒有什么干貨。在機器人軟件里面，處于同樣地位的還有ROS、OROCOS等。

1、開發層

      CODESYS Development System（具有完善的在線編程和離線編程功能）、編譯器及其配件組件、可視化界面編程組件等，同時供用戶可選的運動控制模塊可使其功能更加完整和強大。

      IEC 61131-3 編輯器。CODESYS提供了所有IEC 61131-3所以定義的五種編程語言：如結構化文本（ST）、順序功能圖（SFC）、功能塊圖（FBD）、梯形圖（LD）和指令表，此外還支持連續功能圖（CFC）的編程語言。

      編譯器：負責將 CODESYS 中的應用程序轉換為機器代碼并且優化可編程控制器的性能。當用戶輸入了錯誤的應用程序代碼時，立刻會接收到編譯器發出的語法錯誤警告及錯誤信息，讓編程人員可以迅速做出相應糾正。用戶可以不必改變編程方式，就可以使用不同的基于 CODESYS 編程的硬件裝置（系統）進行工程開發。

硬件/現場總線配置器：針對不同制造商的硬件設備及不同現場總線協議，該部分負責在CODESYS中對相應參數進行設定。

      可視化界面編程：直接在 CODESYS 中即可實現可視化編程（人機界面HMI），系統已經集成了可視化編輯器。

      運動控制模塊：運動控制功能已經集成在CODESYS中，形成了 SoftMotion(CNC)軟件包。基于PLCopen的工具包可以實現單軸、多軸運動；電子凸輪傳動；電子齒輪傳動；復雜多軸CNC控制等。

2、通信層

      應用開發層和硬件設備層之間的通訊是由CODESYS中的網關服務器來實現的，CODESYS網關服務器中安裝了OPC服務器。

      CODESYS 網關服務器。作用在應用開發層和硬件設備層之間，可以使用TCP/IP協議或通過CAN等總線實現遠程訪問，是CODESYS開發工具包不可分割的一部分。

CODESYS OPC服務器。對基于CODESYS進行編程的控制器，無需考慮所使用的硬件CPU，已經集成并實現了OPC V2.0規范的多客戶端功能，且能同時訪問多個控制器。

3、設備層

      在使用基于IEC 61131-3標準的編程開發工具CODESYS對一個硬件設備進行操作前，硬件供應商必須要在設備層預先安裝CODESYS的實時核（CODESYS Runtime）。同時，也可以通過使用CODESYS的可選組件：如CODESYS目標可視化編程模塊或網絡可視化編程模塊來實現功能上的擴展。

4、CODESYS軟件架構中各層關系

      CODESYS代碼執行機制是編譯執行，用戶在開發層編寫完成的IEC程序通過集成的編譯器編譯為二進制代碼，再通過以太網或串口下載至設備層中，Zui終該應用程序中的文件已經被轉為二進制代碼存放在目標設備中，根據用戶設定的執行方式循環執行對應程序。

　　機器人的控制，像數控機床一樣，對實時性有要求，因此我們選擇的操作系統zuihao是實時操作系統（RTOS）。遺憾的是，我們經常用的操作系統都不是實時的，例如Windows和Linux。實時操作系統有兩種實現方式：
　　1. 放棄通用的操作系統，從底層重新開始設計，代表性的有VxWorks、QNX、WinCE、μC/OS、LynxOS等；這種方式的缺點是所有的任務都是實時的，即使任務本身沒有實時的必要，例如網絡訪問、文件系統訪問，因此你得專門開發適用于這種操作系統的應用程序，工作量可能比較大。VxWorks在軍事和工業應用較多，例如被應用于戰斗機和火箭上。VxWorks留下了一個空白，這就是車載領域，現在這個市場被QNX占據了。
　　2. 通過對通用的操作系統打補丁（添加擴展），使其具備實時性，代表性的有Windows RTX、Xenomai、RT Linux、RTAI，這種方式的缺點是，對實時任務的支持（資源）沒有第一種方式多；
　　考慮到Windows和Linux這兩款操作系統的用戶較多，CoDeSys推出了相應的實時補丁（RTE），為用戶免去了改造的煩惱。想了解更多的CoDeSys Runtime信息可以閱讀官方的文檔。
　　CoDeSys runtime如果不安裝在操作系統之上，則需要其自己備有簡單的調度程序。CoDeSys自帶的調度程序比較簡單，有兩種：
　　1　Embedded Scheduler 這種是簡單的輪詢，一個任務結束前另一個任務不能運行，任務之間不能搶占，實際上這種方式并不是實時的；
　　2　Timer Scheduler 為每個任務分配一個定時器，定時觸發；
　　CoDeSys給機器人廠家開發控制器帶來了便利，但是依靠CoDeSys這類商業軟件打造自己的控制器產品也存在不少的缺點：
　　1　底層算法不公開
　　CoDeSys集成的運動控制組件、總線協議棧都是封裝好的，用戶無法了解其內部細節，也無法針對自己的具體需求進行定制優化，只能簡單地調用。用戶只能依附于CoDeSys平臺，難以形成自己的技術。
　　2　功能有限，難以擴展
　　現在以機器視覺、人工智能、自動駕駛等為代表的新技術突飛猛進，而工業控制上的很多技術仍然停留在20年前。以移動機器人中的導航場景為例，基于視覺或者激光的導航方法需要采集大量的數據并對其進行處理，其中涉及相當多的矩陣計算。而現在PLC只能進行落后的一維數字計算，難以實現復雜的算法。與人工智能圈子喜歡開源的風格正好相反，工業控制圈子相互封閉，誰都不肯開放自家的函數庫，開源函數庫很少，就連Zui基本的濾波算法、矩陣計算都要自己從頭開始寫。而且，guojibiaozhunIEC提供的標準函數太過有限，完全無法適應新的場景，急需擴展。
　　3 成本高、難以更新
　　商業軟PLC成本動不動幾十萬，這還不包括各種總線通信庫、運動控制庫、可視化庫，這些仍需單獨購買，而且需要從售出產品上提成，對于小團隊來說成本難以接受。由于完全依賴CoDeSys，客戶自己產品硬件的升級換代需要重新定制移植，導致成本增加。這讓筆者想起來曾經微軟給手機打造的操作系統Windows Phone，微軟在移動端是如何一步步作死的呢？其中關鍵的一條就是向手機廠商收取高額的授權費，可能微軟當大爺當慣了，而且更不要臉的是給用戶設置障礙，同一款手機系統不能連續升級。

　　GEB Automation也推出了與CoDeSys類似的軟PLC，支持編程、調試、仿真，面向OEM的產品售價9500美元，比CoDeSys好的是一次性付費不再收取單機提成，可以移植到常用的硬件平臺，其IDE基于Eclipse開發。