→歡迎點選上方進入 FOTOUS工業平台
CoDeSys介紹
1、CoDeSys的組成
你會發現，很多的機器人控制軟體都是借助CoDeSys實作的，那麼什麼是CoDeSys呢？
CoDeSys是一款付費的軟PLC開發軟體，簡單來說，它包括兩部分：Development System和Runtime System。Development System就是用來程式設計的軟體界面(就像Visual Studio、Eclipse等軟體，也可以稱為IDE)，設計、調試、編譯PLC程式都在IDE中進行，這部分是使用者經常打交道的；
PLC程式寫好了以後，就要把它轉移到硬體裝置中運作。可是這時生成的PLC程式自己是無法運作的，它還要在一定的軟體環境中才能工作，這個環境就是Runtime System，這部分是使用者看不到的。
二者安裝的位置通常不同，IDE一般安裝在開發電腦上，Runtime System則位于起控制作用的硬體裝置上，二者一般使用網線連接配接，程式通過網線下載下傳到Runtime中運作。
CoDeSys在國内知名度不高，但是在歐洲久負盛名，尤其在工業控制領域。我們上面提到的很多機器人公司都使用了它的産品，例如KEBA、倍福、固高，還有幾乎所有的移動機器人控制器廠家。
設計CoDeSys的3S公司隻賣軟體，不賣硬體。硬體電路需要由使用者自己設計，3S公司負責将Runtime System移植到客戶的硬體上。Runtime System可以裸跑在硬體上，但一般是運作在作業系統上，配置作業系統也是客戶的工作。
如果客戶要求，CoDeSys的IDE可以定制，換成客戶的logo和外觀，這就是為什麼你會發現不同廠家的開發平台長得不一樣，但風格又比較相似。
當然，使用者也可以使用其它IDE，例如倍福就使用了微軟的Visual Studio，而背後的編譯器等核心以及函數庫仍然采用CoDeSys的方案。
CoDeSys的Runtime具有強大的适應性，支援絕大多數的作業系統和硬體晶片架構。
2、CoDeSys Runtime原理
CoDeSys的IDE部分是免費的，真正收費的是運作系統Runtime System。
CoDeSys在設計之初就将功能劃分為若幹元件子產品，例如總線協定棧、可視化界面、運動控制、安全控制等等，使用者可以像搭積木一樣選購必需的子產品搭建自己的系統，最後形成一個定制化的控制軟體平台。
一些初次接觸軟PLC的使用者可能對這部分感到陌生，但其實這種設計方式非常普遍。舉幾個例子，MATLAB Simulink的實時工具箱(Real-Time)就是這樣的工作方式，使用者在Simulink的圖形界面裡通過拖拽設計控制程式，然後下載下傳到真實的硬體中跑。
還有像倍福也是這樣的使用方式，使用者在TwinCAT IDE裡進行程式設計，然後下載下傳到倍福的控制器中，控制器裡面其實已經預裝了一個Runtime。西門子的STEP7也是一款IDE，它的PLC中也存在一個配套的Runtime。
使用者編寫的PLC程式就像我們電腦裡的應用程式，它運作在Runtime System上，而Runtime System又運作在作業系統之上。
Runtime System位于應用程式和作業系統之間。是以可以被稱為中間件(Middleware)。在機器人軟體裡面，處于同樣地位的還有ROS、OROCOS(Real-Time Toolkit)等等。
機器人的控制，像數控機床一樣，對實時性有要求，是以我們選擇的作業系統最好是實時作業系統(RTOS)。遺憾的是，我們經常用的作業系統都不是實時的，例如Windows和Linux。但幸運的是，有人對它們進行了改造，也就是加入實時更新檔。
常用的實時作業系統有：VxWorks、QNX、Windows RTX、Xenomai、RT Linux、Linux RTAI、WinCE、μC/OS、SylixOs等等。考慮到Windows和Linux這兩款作業系統的使用者較多，CoDeSys推出了相應的實時更新檔(RTE)，為使用者免去了改造的煩惱。
3、CoDeSys的缺點
CoDeSys給我們開發控制器帶來了便利，省去了從零開始的麻煩，但是依靠CoDeSys這類商業軟體開發自己的控制器産品也存在不少的缺點：
3.1 底層算法不公開
CoDeSys內建的運動控制元件、總線協定棧都是封裝好的，使用者無法了解其内部細節，也無法針對自己的具體需求進行定制優化，隻能簡單地調用。使用者隻能依附于CoDeSys平台，難以形成自己的核心技術。
3.2 功能有限，難以擴充
現在以機器視覺、人工智能、自動駕駛等為代表的新技術突飛猛進，而工業控制上的很多技術仍然停留在20年前。以移動機器人中的導航場景為例，基于視覺或者雷射的導航方法需要采集大量的資料并對其進行處理，其中涉及相當多的矩陣計算。
而現在PLC隻能進行落後的一維數字計算，難以實作複雜的算法。與人工智能圈子喜歡開源的風格正好相反，工業控制圈子互相封閉，誰都不肯開放自家的函數庫，開源函數庫極少(OSCAT)，就連最基本的濾波算法、矩陣計算都要自己從頭開始寫。而且，國際标準提供的基本函數太過有限，完全無法适應新的場景，急需擴充。
3.3 難以更新
由于完全依賴CoDeSys，客戶自己産品硬體的更新換代需要重新定制移植，導緻成本增加。
4、開源方案
目前存在一些開源的控制系統方案，例如Beremiz、Orocos、OpenPLC、OpenRTM、ORCA。
開發機器人控制器是個繁重的工作，要明确一系列性能要求，首先是實時性。
實時性對于工業機器人來說一般是必須的，對于服務或娛樂機器人則未必。一般人很容易錯把“實時性”了解為處理或者響應速度快，但是其實“實時性”表示時間上的“确定性”，例如實時作業系統(RTOS)中的中斷響應或者程序切換的延遲時間一定是在一個時間範圍内。
我們常用的作業系統(Windows、Linux)都不是實時作業系統，因為它們設計的初衷是吞吐量，不能保證每個事件都在一定範圍内得到處理。再比如，标準以太網的傳輸速度比實時工業以太網快多了，但是它也卻不是實時的，因為它同樣不能保證資料在給定的時間内完成傳輸。
了解實時性不太難，可是機器人哪些的任務需要實時運作呢？如何根據機器人的性能要求确定程式運作的時間間隔呢(是1ms還是10ms)？實時性取決于硬體還是軟體呢？
如何根據實時性選擇具體的軟硬體呢(該選擇ARM還是X86、Linux RTAI還是VxWorks)？網上缺少這方面的深入讨論，各大機器人廠家也不會公開自己的測試和試驗結果，似乎這方面主要依靠經驗和試錯。
這裡小福也隻能提供幾個名額，目前工業機械臂的控制周期是1ms左右，性能較高的伺服驅動器位置環的控制周期可以達到125[Math Processing Error] mu sμs。
PLCopen定義了伺服和運動控制的一些标準，包括程式設計語言、運動控制基礎函數塊(Function Block)、輸入輸出接口的參數等[Math Processing Error] ^{[3]}
具體的實作代碼細節，這個是由各個廠家提供的。
招募作者
FOTOUS工業正在招募内容創作者和專欄作家
有意向者請将履歷和原創作品投至郵箱：[email protected]
我們對職位、所在地等沒有要求，歡迎有興趣有能力的朋友成為我們的兼職合夥人