Írta: Sós András
2019. február 6. 16:09:51 CET
Évtizedek óta várunk arra, hogy egy nyelv megtanulásával az összes PLC-t tudjuk programozni. Bár a létra programozás ezt ígérte, a gyártók implementációja különbözik egymástól annyira, hogy legyenek omronosok, siemensesek, AB-sek, akik nem vállalják más gyártók PLC-jének a programozását.
Ezt a helyzetet próbálta meg orvosolni 15 éve az IEC 61131-3 szabvány, amely egy egységes programozási nyelv. Ehhez már csak annyi kellett, hogy szülessen egy fejlesztői környezet is, amely támogatja ezt a nyelvet is, és amelyhez a gyártók is elkészítik a drivereiket. A legígéretesebb jelölt a német 3S-Smart cég CodeSys nevű programja volt, míg csak nem…
Forrás: https://www.codesys.com/news-events/press-releases/article/codesys-softplc-for-open-linux-device-platforms.html
Technológiai cégeknél bevett szokás, hogy a kutatás fejlesztési eredményeket idejekorán levédik, majd ha még nem látják hasznát, jegelik. Később, amikor valaki sikerre viszi a fejlesztést, akkor szabadalom megsértése miatt perelnek. Minél inkább sikerre vitték a fejlesztést, annál nagyobb összegre lehet perelni, ezért szokták megvárni, amíg tényleg sikeres lesz, nem azonnal csapnak le. Olyannyira bevett szokás ez, hogy mára nevet is kapott: szabadalmi trollkodás (az angol patent trollból ered), amivel persze el is ítéli az ilyen viselkedést, pedig biztos akadnak "erkölcsös" szabadalmi trollok is.
A CodeSys-t is beperelték. Nem tisztünk megítélni, hogy valóban történt-e szabadalomsértés, az viszont biztos, hogy a 2016-os per jócskán lelassította az egységesítést.
Az Opto22 egy amerikai tulajdonú cég, és egyedülálló módon a gyártást is Amerikában tartották, nem vitték ki Kínába. Eleinte szilárdtest reléket (SSR), később ipari vezérlő rendszereket kezdtek gyártani, a G1, G4, majd a SNAP-PAC rendszert, illetve a legújabb groov EPIC-et. Erősségük mindig is a megbízhatóság volt. SSR-jeikre és moduljaikra élettartam garanciát vállalnak. Vezérlőik programozása folyamatábrával történt, ami sokkal könnyebben tanulható, mint a létra. Jellemzően fél nap oktatás után a partnereink neki szoktak tudni látni a projektnek. Az EPIC az első vezérlőjük, amelyet már nem csak folyamatábrával, hanem létrával is programozható.
Az Amerikában megbízhatósága miatt népszerű, hazánkban egyelőre kevésbé ismert Opto22 már napokra volt a bejelentéstől, hogy az eszközeik támogatni fogják az IEC 61131-3 szabványt a CodeSys rendszerén belül, amikor megjelent a per híre. Azóta kellett várnunk a nagy bejelentésre, de íme, megjött. Az IoT controller kategóriában igen erős groov EPIC legújabb firmware-e már támogatja az IEC 61131-3 szabványt, melynek köszönhetően egy fontos szereplővel bővül a már így is széles, több mint 400 eszközt számláló közösség.
A groov EPIC egy edge device, amely egyszerre egy programozható vezérlő (értsd: PLC), HMI valamint adatfeldolgozó és -továbbító eszköz. Ebből is ered a rövidítés: Edge Programmable Industrial Controller.
Edge device-nak nevezzük az olyan eszközöket, amellyel az Edge Computing megvalósítható.
Edge Computingnak pedig nevezzük azt az elvet, hogy az adatokat a keletkezésük helyén dolgozzuk fel ahelyett, hogy felküldenénk egy központi feldolgozó egységbe, pl egy szerverre vagy a felhőbe. Ipari folyamatoknál sokkal több adat keletkezik, mint amennyit értelme van továbbítani. Egy PLC néhány tized másodpercenként frissíti a regisztereit. Miért kéne mindig minden értéket továbbküldeni? Miért nem csak azt küldjük, aminek az adott pillanatban értelme van? Míg hagyományosan a PLC-t “polloztuk”, azaz folyamatosan kérdezgettük, és egy-rendszerint Windows PC-n értékeltük ki az adatokat, addig ma már rendelkezésre áll a számítási kapacitás egyes PLC-kben, és léteznek robosztus protokollok is, hogy ők maguk döntsék el, hogy milyen üzemállapotban melyik adatot érdemes felküldeni a szervereknek, és azt saját maguk kezdeményezésére fel is tudják küldeni, tehát nem kell pl másodpercenként kérdezgetni őket, hogy “mi a regiszter tartalma? Mi a regiszter tartalma? Mi a regiszter tartalma? Mi a regiszter tartalma?” Csak azért, hogy megtudjuk, történt-e változás. Ezzel töredékére tudjuk csökkenteni a szükséges sávszélességet, és egyszerűsíteni tudjuk a magasabb szintű adatfeldolgozást.
Bár sokszor a Felhő (cloud computing) és a fog computing alternatívájaként szokták felsorolni, valójában ezeknek a megvalósíthatóságát segíti, mivel nincs többé szükség dedikált adatfeldolgozó PC-re (SCADA-ra), amely továbbítja az adatot a magasabb szintű szoftvereknek a felhőbe, vagy a fog-ba, hanem ezt a feladatot átveszi maga az edge device.
Megírjuk a vezérlő programot bármely általunk preferált nyelven: létra (LD), funkcióblokk diagram (FBD), strukturált szöveg (ST), szekvenciális funkció diagram (SFC) vagy az Opto22 eredeti nyelvén, a folyamatábrákkal.
Összekattintgatjuk hozzá a kezelő felületeket, a HMI-t.
Elkészítjük hozzá az adatfeldolgozást egy olyan módszerrel, amelyik sokkal alkalmasabb a PLC programozási nyelveknél. A legegyszerűbb a beépített Node Red használata, amellyel kattintgatással, programozási ismeretek nélkül is össze tudjuk állítani az üzleti logikát.
Majd felküldjük az adatokat az adatgyűjtő rendszerekbe tárolásra, vagy a magasabb szintű irányító rendszerekbe, MES-be, ERP-be, esetleg adatelemzésre.
Erre össze is állítottunk házon belül egy kis OEE demo alkalmazást, amelynek bemutatására a következő cikkemben vállalkozom.
Amennyiben szeretnél többet megtudni a fenti technológiákról vagy eszközökről, lépj tovább a groov EPIC oldalára, vagy keress minket bátran elérhetőségeink bármelyikén!
Várjuk hozzászólásaidat, tapasztalataidat, véleményedet!
Megjegyzés:
A cikk eredetileg 2019. február 6-án jelent meg, melyet azóta frissítettünk, hogy aktuális legyen.
