Ez a cikk két ipari robot, a manipulátor és a mobil robot vezérlőrendszer-megoldásait hasonlítja össze, és ismerteti azok jellemzőit.
A fenti besorolás az alkalmazás objektumon alapul. Ezenkívül vannak a piacon általánosabb mozgásvezérlők, vagyis olyanok, amelyek nem szabványos berendezéseket vezérelnek.
1 Vezérlő alsó szintű megoldás 1.1 Manipulátor típus A korábban kifejlesztett, viszonylag kiforrott manipulátor típusú vezérlő. Vessünk egy pillantást a meglévő vezérlőrendszer alsó szintű megoldására. 1.2 Mobil robot típus A mobil robot vezérlője viszonylag új irányzathoz tartozik. Az ipari mobil robotok AGV, pilóta nélküli mérnöki gépek stb. formájúak. A vezérlőrendszer alsó szintű megoldása a következő:
1.3 Összehasonlítás
A manipulátor magas követelményeket támaszt a pontosság és a mozgásstabilitás tekintetében, ezért a számítási mennyiség nagy és a ciklus rövid, ami általában 1-2 nagyságrenddel magasabb, mint a mobil robotoké. A mobil robotok általában nem támasztanak magas követelményeket a szinkronizálási pontossággal szemben, és konfigurációjuk is viszonylag alacsony.
A manipulátor általában fix területen működik, vezérlője általában az alvázban van elhelyezve, így a védelmi szint nem magas, általában IP20. A mobil robotoknak víz- és porállóknak kell lenniük, mert gyakran kell mozogniuk, különösen a kültéri gépészeti gépeknél, ezért fontolóra kell venniük a víz- és porszigetelést. Védettségük magasabb, általában IP67.
2 A CoDeSys bemutatása 2.1 A CoDeSys összetétele
Látni fogja, hogy sok robotvezérlő szoftvert a CoDeSys segítségével valósítottak meg, tehát mi is az a CoDeSys?
A CoDeSys egy fizetős soft PLC-fejlesztő szoftver. Egyszerűen fogalmazva, két részből áll: Fejlesztőrendszerből és Futórendszerből. A Development System a programozáshoz használt szoftver interfész (akárcsak a Visual Studio, az Eclipse és más szoftverek, amelyeket IDE-nek is nevezhetünk). A PLC-programok tervezése, hibakeresése és fordítása mind az IDE-ben történik, amely az a rész, amellyel a felhasználók gyakran foglalkoznak;
A PLC program megírása után a működéshez át kell vinni a hardvereszközre. A generált PLC program azonban jelenleg nem futhat önmagában. Egy bizonyos szoftverkörnyezetben kell működnie. Ez a környezet a Runtime System, amely nem látható a felhasználók számára.
A kettő telepítési helye általában eltérő. Az IDE általában a fejlesztő számítógépre van telepítve, a Runtime System pedig a vezérlő szerepet betöltő hardvereszközön található. A kettőt általában hálózati kábelek kötik össze, és a program a hálózati kábelen keresztül letöltődik a Runtime-ba működéshez.
A CoDeSys Kínában nem ismert, de Európában már régóta ismert, különösen az ipari irányítás területén. Számos fent említett robotgyártó cég használja termékeit, mint például a KEBA, a Beckhoff, a Googol és szinte minden mobil robotvezérlő gyártó.
A 3S, a CoDeSys-t tervező cég csak szoftvereket árul, hardvert nem. A hardver áramkört a felhasználónak kell megterveznie, és a 3S feladata a Runtime System portolása az ügyfél hardverére. A Runtime System futtatható a hardveren, de általában az operációs rendszeren fut, és az operációs rendszer konfigurálása is az ügyfél feladata.
A vevő igénye szerint a CoDeSys IDE-je testreszabható a vevő logójának és megjelenésének megváltoztatására, ezért azt tapasztaljuk, hogy a különböző gyártók fejlesztői platformjai eltérően néznek ki, de a stílusok viszonylag hasonlóak.
Természetesen a felhasználók más IDE-ket is használhatnak. Például a Beckhoff a Microsoft Visual Studio-ját használja, míg a fordító mögötti kernel és függvénytár továbbra is a CoDeSys megoldását használja.
A CoDeSys futási ideje erős alkalmazkodóképességgel rendelkezik, és támogatja a legtöbb operációs rendszert és hardverchip architektúrát.
2.2 CoDeSys futási elve
A CoDeSys IDE része ingyenes, és letöltheti a hivatalos webhelyéről, hogy megtapasztalhassa. Az igazi töltés a futásidejű rendszer Runtime System.
A tervezés kezdetén a CoDeSys a funkciókat több komponens modulra osztotta, mint például buszprotokoll-verem, vizuális interfész, mozgásvezérlés, biztonsági vezérlés stb. A felhasználók kiválaszthatják a saját rendszerük felépítéséhez szükséges modulokat, például építőelemeket, végül testreszabott vezérlőszoftver-platformot alkotnak.
Néhány felhasználó, aki még nem ismeri a soft PLC-t, úgy érzi, nem ismeri ezt a részt, de valójában ez a tervezési módszer nagyon gyakori. Például a MATLAB Simulink valós idejű eszköztára (Real-Time) így működik. A felhasználók a Simulink grafikus felületén húzással tervezik meg a vezérlőprogramokat, majd letöltik őket a valódi hardverre, hogy futtassák őket. Itt tájékozódhat róla.
Van olyan felhasználási mód is, mint a Beckhoff. A felhasználók TwinCAT IDE-ben programoznak, majd letöltik a Beckhoff vezérlőjére. Valójában egy futási környezet előre telepítve van a vezérlőben. A Siemens STEP7 szintén IDE, és a PLC-je is rendelkezik megfelelő futási idővel.
A felhasználó által írt PLC program olyan, mint a számítógépünkben lévő alkalmazás. A futásidejű rendszeren fut, a futásidejű rendszer pedig az operációs rendszeren fut.
A futásidejű rendszer az alkalmazás és az operációs rendszer között található. Tehát köztes szoftvernek nevezhető. A robotszoftverben a ROS, OROCOS (Real-Time Toolkit) stb.
A robotvezérlés a CNC szerszámgépekhez hasonlóan valós idejű teljesítményt igényel, ezért az általunk választott operációs rendszer lehetőleg valós idejű operációs rendszer (RTOS) legyen. Sajnos az általunk gyakran használt operációs rendszerek nem valós idejűek, mint például a Windows és a Linux. De szerencsére valaki módosította őket, azaz valós idejű javításokat adott hozzá.
Az általánosan használt valós idejű operációs rendszerek a következők: VxWorks, QNX, Windows RTX, Xenomai, RT Linux, Linux RTAI, WinCE, μC/OS, SylixOs stb. Tekintettel arra, hogy sok Windows és Linux operációs rendszer felhasználója van, a CoDeSys elindult. egy megfelelő valós idejű javítás (RTE), amely megkíméli a felhasználókat a módosítási nehézségektől.
A CoDeSys Runtime-ról további információért olvassa el a [Math Processing Error] [1][2][1][2] hivatalos dokumentumot.
2.3 A CoDeSys hátrányai
A CoDeSys kényelmesebbé teszi vezérlőink fejlesztését, és megkímél minket attól, hogy a nulláról kezdjük. Azonban számos hátránya is van a saját vezérlőtermékeink fejlesztésének olyan kereskedelmi szoftvereken, mint a CoDeSys:
(1) Az alapul szolgáló algoritmus nem nyitott
A CoDeSys által integrált mozgásvezérlő komponensek és buszprotokoll-veremek mindegyike be van zárva. A felhasználók nem érthetik meg belső adataikat, és nem tudják azokat egyedi igényeik szerint testreszabni és optimalizálni. Csak egyszerűen hívhatják őket. A felhasználók csak a CoDeSys platformra hagyatkozhatnak, és nehezen tudják kialakítani saját alaptechnológiájukat.
(2) Korlátozott funkciók és nehezen bővíthető
A gépi látás, a mesterséges intelligencia és az autonóm vezetés által képviselt új technológiák ma ugrásszerűen fejlődnek, miközben az ipari vezérlés számos technológiája még mindig 20 éves. Példaként a mobilrobot navigációs jelenetét vesszük figyelembe, a látáson vagy lézeren alapuló navigációs módszernek nagy mennyiségű adatot kell összegyűjtenie és feldolgoznia, ami rengeteg mátrixszámítással jár.
A PLC ma már csak visszafelé, egydimenziós digitális számításokat tud végezni, ami megnehezíti az összetett algoritmusok megvalósítását. Ellentétben a mesterséges intelligencia közösségének nyílt forráskódú stílusával, az ipari vezérlőközösség zárt egymáshoz. Senki sem hajlandó saját függvénykönyvtárat megnyitni. Nagyon kevés nyílt forráskódú függvénykönyvtár (OSCAT) létezik. Még a legalapvetőbb szűrési algoritmusokat és mátrixszámításokat is a semmiből kell megírni. Ráadásul a nemzetközi szabványok által biztosított alapvető funkciók túlságosan korlátozottak, és egyáltalán nem tudnak alkalmazkodni az új forgatókönyvekhez. Sürgősen bővítésre szorulnak.
(3) Nehéz frissíteni
A CoDeSys-re való teljes támaszkodás miatt az ügyfelek saját termék hardverének frissítését testre kell szabni és át kell ültetni, ami megnövekedett költségeket eredményez.
3 Nyílt forráskódú megoldások
Jelenleg létezik néhány nyílt forráskódú vezérlőrendszer-megoldás, mint például a Beremiz, az Orocos, az OpenPLC, az OpenRTM és az ORCA.
A robotvezérlők fejlesztése nehéz feladat. Tisztázni kell egy sor teljesítménykövetelményt, amelyek közül az első a valós idejű teljesítmény.
A valós idejű teljesítmény általában szükséges az ipari robotokhoz, de nem feltétlenül a szolgáltató vagy szórakoztató robotokhoz. A hétköznapi emberek könnyen összetévesztik a "valós idejű teljesítményt" a gyors feldolgozási vagy válaszsebességgel, de valójában a "valós idejű teljesítmény" időbeli determinizmust jelent. Például a megszakítási válasz vagy a folyamatváltás késleltetési idejének a valós idejű operációs rendszerben (RTOS) egy időtartományon belül kell lennie.
Az általunk általánosan használt operációs rendszerek (Windows, Linux) nem valós idejű operációs rendszerek, mivel átviteli sebességre készültek, és nem garantálják, hogy minden esemény egy bizonyos tartományon belül kerül feldolgozásra. Például a szabványos Ethernet átviteli sebessége sokkal gyorsabb, mint a valós idejű ipari Etherneté, de nem is valós idejű, mert az sem tudja garantálni, hogy adott időn belül megtörténik az adatátvitel.
Nem nehéz megérteni a valós időt, de a robot mely feladatainak kell valós időben futniuk? Hogyan határozható meg a program futásának időtartama a robot teljesítménykövetelményei szerint (1 ms vagy 10 ms)? A valós idő hardvertől vagy szoftvertől függ?
Hogyan válasszunk ki konkrét hardvert és szoftvert valós idejű adatok alapján (ARM vagy X86, Linux RTAI vagy VxWorks)? Az interneten hiányzik a mélyreható vita erről a szempontról, és a nagy robotgyártók nem hozzák nyilvánosságra teszt- és kísérleti eredményeiket. Úgy tűnik, ez a szempont elsősorban a tapasztalatokon és a próbálkozásokon múlik.
Itt csak néhány mutatót tudok közölni. Jelenleg az ipari robotkarok vezérlési ciklusa körülbelül 1 ms, és egy nagy teljesítményű szervohajtás pozícióhurkának vezérlési ciklusa elérheti a 125 [Math Processing Error] mu sμs-ot. A PLCopen meghatároz néhány szabványt a szervo- és mozgásvezérléshez, beleértve a programozási nyelvet, az alapvető mozgásvezérlő funkcióblokkokat, a bemeneti és kimeneti interfészek paramétereit stb. [Math Processing Error] ^{[3]}
[3] A konkrét megvalósítási kódrészleteket különböző gyártók biztosítják.
