Hogyan oldjuk meg a Fanuc SRVO-408 robotriasztás problémáját?
Azoknak, akik Fanuc robotokkal dolgoznak: amikor ezt az SRVO-408 riasztást kapják, sokan első reakcióként így szólnak: „Nagyszerű, megint hisztizik a szervomotor?” Végül is az SRVO kód kezdődik, így nehéz nem a szervorendszerre gondolni. De hadd zárjam le ezt a lehetőséget: ez a riasztás valójában alig kapcsolódik a szervomotorhoz vagy a szervoerősítőhöz – hanem a Fanuc DCS biztonsági rendszeréből származik.
A műhelyben kezelt SRVO-408 esetek közül tízből kilenc és fél végül a biztonsági áramkör vagy a DCS konfiguráció problémáját mutatja – egyáltalán nem motorhiba. Ezért ma részletesen elemezem ezt a riasztást, és elmondom mindenkinek, mi rejlik valójában az SRVO-408 mögött, valamint hol érdemes elkezdeni a hibaelhárítást, hogy ne pazaroljátok hiába az időt a szervo szétbontásával, és ne késleltessétek feleslegesen a gyártást. 
Mit jelent a képernyőn látható „SRVO-408 DCS SSO Ext Emergency Stop” felirat valójában?
Először is jegyezze meg ezt a mondatot: SRVO-408 = DCS SSO külső vészhelyzeti leállítás = a biztonsági kimenet SSO[3] kikapcsolt állapotba került. Itt két fogalommal kell először megismerkednie: DCS és SSO.
A DCS (Dual Check Safety) a Fanuc robotvezérlőrendszeren belüli biztonsági funkciók egy csoportja. A redundáns jelek, a biztonsági figyelés és a biztonsági bemenet/kimenet segítségével ellenőrzi a robot mozgását és biztonsági állapotát, hogy megakadályozza a robot irányíthatatlanná válását, valamint az emberek megsérülését vagy a berendezések sérülését. Az SSO-t úgy tekintheti, mint egy biztonsági kimeneti jel típusát a DCS rendszeren belül – lényegében egy „biztonsági zászlót”, amelyet a DCS küld ki.
Az SRVO-408 riasztásnál a Fanuc kifejezetten az SSO[3] számú biztonsági kimenetre utal. Amikor a DCS biztonsági logika úgy dönt, hogy az külső vészleállítással kapcsolatos SSO[3] kimenet KI lett kapcsolva, a robot vészleállítási állapotba kerül, és a képernyőn megjelenik az SRVO-408 riasztás.
Ahogy látható, ez a riasztás tulajdonképpen azt jelzi: a DCS biztonsági logika szerint hiba van azon biztonsági kimeneten, amely a külső vészleállításhoz kapcsolódik, és már le is kapcsolta azt. Ez teljesen más jellegű probléma, mint például a „szervomotor túláram”, az „enkóder-hiba” vagy az „erősítő meghibásodása”. Korábban, ha szervóriasztást kapott, esetleg a motort, az enkóder-t, az erősítőt vagy a kábeleket ellenőrizte. Az SRVO-408 riasztás esetén azonban megbízhatóbb megközelítés a DCS biztonsági jelkör követése. Egyszerűen fogalmazva: SRVO-408 → SSO[3] KI → biztonságos I/O-kapcsolat ellenőrzése → meghatározni, mi vezérli az SSO[3]-at → a megfelelő biztonsági áramkör ellenőrzése.
Miért gabalyodik be ez a riasztó mindig olyan elemekkel, mint a vészkikapcsoló gombok és a biztonsági kapuk?
Sok automatizált gyártósoron a Fanuc robot nem izoláltan, egyedül működik. Gyakran körülveszik biztonsági kapuk, biztonsági fényfüggönyök, vészkikapcsoló gombok, biztonsági relék, biztonsági PLC-k, sőt néha más robotok, gépek vagy szállítószalagok is. Ezeket az eszközöket biztonsági áramkörökön keresztül kötik össze a robot vezérlőrendszerével. Egy tipikus biztonsági lánc így néz ki: vészkikapcsoló gomb megnyomása → biztonsági relé vagy biztonsági PLC állapotváltozása → biztonsági jel megszűnik → DCS biztonsági logika hibát észlel → SSO[3] kikapcsolásra kerül → SRVO-408 hibaüzenet jelenik meg.
Tehát amikor látja az SRVO-408 kódot, valóban ellenőriznie kell a vészleállítást és a biztonsági eszközöket. De van egy dolog, amely különösen fontos: nem feltétlenül következik abból, hogy „a biztonsági kapu nyitva van”, hogy ez az SRVO-408 kód. A Fanuc DCS rendszerében számos különböző biztonsági funkció van, és ehhez hasonló riasztási kódok is léteznek – például olyanok, amelyek a „kerítés nyitva” vagy a „szervó lecsatlakozott” állapotra utalnak. Amikor valójában hibaelhárítást végez, ne maradjon meg a „valami baj van a robot biztonsági funkciójával” szintjén – folyamatosan mélyüljön: pontosan melyik konkrét biztonsági jel változott meg? És melyik SSO vezérli ezt a jelet? Ha elérte ezt a részletességi szintet, akkor pontosan meghatározhatja a problémát.
A leggyakoribb, helyszínen előforduló okok egyesével felsorolva
1. Az SSO[3] ténylegesen ki lett kapcsolva
Ez a legközvetlenebb ok, és ez az első dolog, amit ellenőrizni kell a SRVO-408 hibaüzenet hibaelhárítása során. A Fanuc SRVO-408 hibaüzenetének alapvető kiváltó feltétele: az SSO[3] kimenet KI állásban van. Más szavakkal: ha ezt a riasztást látja, ne siessen megvádolni a szervohajtót – először nézze meg a DCS állapotát, hogy az SSO[3] tényleg KI állásban van-e. Ha valóban KI állásban van, akkor a következő lépés annak megállapítása, melyik biztonsági logika vezérli ezt a kimenetet. Egyes rendszerekben az SSO[3] egy adott biztonsági bemenethez (SPI) kapcsolódhat, vagy a Safe I/O Connect belső logikai kapcsolatain keresztül vezérelhető. Pontosan hogyan van konfigurálva, az attól függ, hogyan lett eredetileg beállítva az adott robot biztonsági terve. Ne feltételezze tehát, hogy ugyanazt az I/O-számot minden gépen alkalmazhatja.
2. Az SSO[3]-hoz kapcsolódó biztonsági bemenet KI állásba került
Miután megtalálta az SSO[3]-at, a következő lépés annak megállapítása, hogy mi szabályozza. Ez a lépés különösen fontos a hibaelhárítás során. Például tegyük fel, hogy egy adott Fanuc robotnál az SSO[3] egy biztonsági bemenetre, az SPI-re van kötve. Ha ez az SPI kikapcsol, mert valamilyen külső biztonsági feltétel nem teljesül, akkor a DCS logika természetes módon szintén kikapcsolja az SSO[3]-at, ami végül az SRVO-408 hibát váltja ki.
Ebben az esetben a tényleges hibapont egyáltalán nem feltétlenül található a Fanuc vezérlőszekrényen belül. Lehet, hogy a külső vészleállító áramkört nem állították vissza, a biztonsági relé nem kapcsolt be újra, a biztonsági PLC nem adta ki a megfelelő biztonsági jelet, egy vezeték megszakadt a biztonsági bemeneten, egy biztonsági kapcsoló továbbra is lenyomva van és nem lett elengedve, vagy egy csatlakozó rossz kontaktust mutat. Ezért a hibaelhárítás során a legjobb eljárás a jelút szakaszonkénti átvizsgálása, ahelyett, hogy azonnal hardvercserére térnénk.
3. A külső vészleállító áramkörben hiba van
A robotcellán belüli vészkikapcsoló rendszer az SRVO-408 esetében egy olyan terület, amely különös figyelmet igényel. Amikor egy műszaki szakember megnyomja a vészkikapcsoló gombot, a biztonsági relé kinyílik, a robotvezérlő érzékeli a megfelelő biztonsági állapotot, és a DCS biztonsági leállítást hajt végre – ez a biztonsági funkció normális működése, itt nincs probléma. A probléma akkor merül fel, amikor a vészkikapcsoló gombot már felengedték, de a biztonsági lánc még nem állt helyre teljesen. Például a vészkikapcsoló gomb mechanikusan újraállítható, de a biztonsági relé még nem állítódott vissza; vagy a biztonsági PLC továbbra is úgy érzi, hogy egy biztonsági feltétel nem teljesült. Ebben az esetben a robot továbbra sem indul el, és folyamatosan biztonsági riasztásokat generál.
Tehát a hibaelhárítás során ne csak azon gondolkodjunk, hogy a vészleállító gomb kilökött-e – meg kell győződnünk arról, hogy az egész biztonsági áramkör helyreállt. Az ellenőrzést ebben a sorrendben végezhetjük el: vészleállító gomb → biztonsági relé → biztonsági PLC → biztonsági bemenet → DCS Safe I/O Connect → SSO[3]. Ha bármelyik láncszem nem állt helyre, a robot nem tud visszatérni a normál biztonsági állapotba.
4. A DCS Safe I/O Connect konfigurációját módosították
Ha a robot eddig hibátlanul működött, és csak mostanában kezdte gyakran kiváltani az SRVO-408 hibakódot, valamint valaki módosította a vezérlő konfigurációját, akkor a DCS biztonsági konfigurációnak különös figyelmet kell szentelni. Például: módosították a DCS biztonsági bemenet/kimenet (I/O) beállításait, cserélték a vezérlőt, visszaállítottak egy robotbiztonsági mentést, megváltoztatták a biztonsági PLC programját, újrakonfigurálták a robotmunkaállomást, kicseréltek egy külső biztonsági eszközt, vagy újra üzembe helyezték a robotszisztémát. Ez különösen érvényes a másodkezi Fanuc vezérlőkre, amelyeket korábban egy másik robotszisztémán használtak, majd eltávolítottak és új berendezésre szereltek fel – ellenőrizni kell, hogy az eredeti DCS biztonsági konfiguráció ténylegesen illeszkedik-e az aktuális gép biztonsági tervezéséhez.
Az riasztás megjelenésének időpontja maga is fontos jelzés. Ha a gép évek óta nem mutatott ilyen problémát, és az SRVO-408 hibaüzenet azonnal megjelenik egy vezérlő csere után, akkor először a vezérlő DCS-konfigurációját és biztonsági bemeneti/kimeneti állapotát kell ellenőrizni, ne pedig a robot szervomotorját gyanúsítani.
5. A biztonsági PLC vagy egy másik külső biztonsági eszköz nem adja meg a megfelelő állapotot
Manapság sok robotmunkaállomás biztonsági PLC-t használ. Ha a Fanuc DCS-je jelek útján csatlakozik egy külső biztonsági rendszerhez, akkor a biztonsági PLC állapota is befolyásolja a robot végleges biztonsági állapotát. Például: a biztonsági PLC észleli, hogy egy biztonsági feltétel nem teljesül → a biztonsági kimenet nem áll helyre → a Fanuc biztonsági bemenete OFF marad → a DCS-logika SSO[3]-at OFF állapotban tartja → SRVO-408. Ebben az esetben a Fanuc szervorendszerének vizsgálata teljesen felesleges munka.
Ha a helyszínen van biztonsági PLC, érdemes egyidejűleg ellenőrizni a PLC diagnosztikai információit is annak megerősítésére, hogy a biztonsági bemenetek, kimenetek és a kapcsolódó biztonsági logika mind az elvárt állapotban vannak-e.
6. A Safe I/O Connect logika nem felel meg a gép tényleges tervezésének
Van egy másik, könnyen figyelmen kívül hagyható helyzet: a DCS biztonsági I/O-konfiguráció maga nem felel meg a gép jelenlegi biztonsági tervezésének. Például a robot újrakonfigurálásra kerülhetett, és a külső biztonsági eszközök megváltoztak, de a DCS biztonsági I/O-konfigurációt nem frissítették ennek megfelelően; vagy a vezérlőt egy régi biztonsági mentésből állították vissza, ami ellentmondást eredményezett a jelenlegi felszerelés és az eredeti biztonsági logika között. Ebben az esetben a robot maga egyáltalán nem mutathat mechanikai vagy szervohardver-hibát, de a DCS egyszerűen úgy véli, hogy a biztonsági feltétel nem teljesül.
Tehát ha már megerősítették, hogy minden külső biztonsági eszköz működik normálisan, de az SSO[3] egyszerűen nem tér vissza, akkor gondosan össze kell hasonlítani a jelenlegi DCS Safe I/O Connect konfigurációt a gép eredeti villamosrajzaival, üzembe helyezési dokumentumával és biztonsági tervezésével.
Hogyan követem át általában lépésről lépésre ezt a folyamatot hibaelhárítás közben
A legnagyobb tabu ilyen típusú riasztás kezelésekor az, hogy „azonnal cseréljen ki egy alkatrészt, amint megjelenik a riasztás.” Az SRVO-408 riasztás már világosan jelzi: SSO[3] KI. Ezért a gyakorlati hibaelhárítás során ezen jel visszafelé történő nyomon követésére van szükség.
Először írja le teljes egészében a riasztási naplót a tanítókonzolról. Az SRVO-408 mellett ellenőrizze, hogy a riasztási előzményekben szerepelnek-e más DCS-, biztonsági I/O- vagy vészleállítással kapcsolatos riasztások is. Néha az SRVO-408 csupán a végső eredmény, és a valódi ok korábban már felbukkant.
Ezután ellenőrizze a megfelelő DCS állapotot annak megerősítésére, hogy az SSO[3] ténylegesen KI van-e kapcsolva. Ha az SSO[3] ki van kapcsolva, folytassa a Safe I/O Connect konfiguráció átnézésével, hogy megtalálja a bemenetet vagy logikai kapcsolatot, amely az SSO[3]-t vezérli. Bármit is tesz, ne találgasson és ne támaszkodjon a korábbi tapasztalatra ezen a lépésen — a DCS konfiguráció rendkívül eltérő lehet a robotmodelltől, vezérlőtől és munkaállomástól függően. Még akkor is, ha két gép is Fanuc, az SPI-, az SSO- és a biztonsági I/O-hozzárendelések teljesen eltérőek lehetnek.
Miután megtalálta a megfelelő biztonsági bemenetet, ellenőrizze, hogy jelenleg BE vagy KI van-e kapcsolva. Ha ez a biztonsági bemenet is KI van kapcsolva, folytassa a nyomozást kifelé. Például: SPI KI → ellenőrizze a biztonsági PLC-t → ellenőrizze a biztonsági relét → ellenőrizze a vészleállítást → ellenőrizze az eszközöket, például a biztonsági ajtót és a fényfüggönyt.
Ha minden külső biztonsági eszköz működik rendesen, de az SPI továbbra sem tér vissza, akkor tovább kell lépnie, és ellenőriznie kell a biztonsági vezetékeket, a csatlakozókat és a DCS-konfigurációt. Ha a külső biztonsági rendszer teljesen helyreállt, de a DCS állapota továbbra is kikapcsolt, akkor a figyelmét a „Safe I/O Connect” konfiguráció helyességére kell irányítania.
Ez a hibaelhárítási módszer lassabbnak tűnhet, mint a „csak cserélje ki a szervohajtót”, de gyakorlatban általában gyorsabb. Ennek az az oka, hogy az riasztás logikáját követve azonosítja a problémát, nem pedig próbálgatással és hibás alkatrész-cserével.
Csak megnyomhatja a reset gombot, és kényszerítheti a folyamatot?
Amikor egy műszaki személyzet tagja riasztást kap egy robotnál, az első reakció általában a RESET gomb megnyomása. Megpróbálhatja a SRVO-408 riasztás törlését is, de a RESET gomb egyszerű megnyomása alapvetően nem oldja meg a problémát. Az ok egyszerű: ha a DCS továbbra is azt érzékeli, hogy az SSO[3] kikapcsolt állapotban van, akkor a biztonsági feltétel nem állt helyre, és a riasztás azonnal újra aktiválódik a törlés után. A helyes eljárás a következő: először helyre kell állítani a biztonsági feltételt → majd ellenőrizni kell, hogy az SSO[3] visszatért-e normál működési állapotba → ezután törölni kell a riasztást → végül ellenőrizni kell a robot működési állapotát.
Az ismételt RESET gomb megnyomása vagy akár a vezérlő folyamatos újraindítása anélkül, hogy megoldanánk az SSO[3] kikapcsolt állapotának gyökér okát, teljesen felesleges erőfeszítés. Sőt, különösen fontos, hogy soha ne próbálja meg – még időt takarítva meg – a biztonsági bemenetet kényszerített jumperrel rövidre zárni vagy tetszőlegesen módosítani a biztonsági logikát, hogy a robot működni kezdjen.
Tényleg meghibásodott a szervomotor?
Általában nem. Még ha a riasztás neve is SRVO-vel kezdődik, az SRVO-408 alapvető meghatározása „DCS SSO Ext Emergency Stop”, ami a DCS biztonsági funkcióban szereplő SSO[3] OFF állapotnak felel meg. Tehát ha a robot csak az SRVO-408 riasztást adja ki, és nincs más, egyértelműen a szervorendszerre utaló riasztás, akkor nem javasolt azonnal a szervomotor, a szervoerősítő, az enkóder vagy a hajtómű cseréjébe kezdeni. Ezek a komponensek más Fanuc-riasztások esetén valóban elsődleges gyanúsítottak lehetnek, de az SRVO-408 esetében nem az első ellenőrizendő elemek.
Ez az oka annak is, hogy gyakran előfordulnak olyan helyszíni esetek, amikor „a szervoerősítőt lecserélték, mégis továbbra is riaszt”, mert a probléma soha nem az erősítőben volt, és teljesen mindegy, hány darabot cserélnek fel.
Bármit is tesz, ne kerülje meg a biztonsági jel jumperelésével
Az SRVO-408 egy riasztás, amely a robot biztonsági funkciójához kapcsolódik, és nem kezelhető úgy, mint egy átlagos gyártási riasztás. Néhány helyszíni személy talán így gondolkodik: „Miért ne kötnénk most ideiglenesen át ezt a biztonsági jelet, és indítanánk el újra a robotot?” Ez a megközelítés rendkívül veszélyes.
Soha ne kényszerítsük vissza a robotot a működésbe ilyen módszerekkel: a biztonsági bemenet átkötése, a biztonsági kimenet kényszerített bekapcsolása, a DCS tetszőleges kikapcsolása, a biztonsági PLC megkerülése, a biztonsági ajtókapcsoló eltávolítása vagy a vészleállítási áramkör megkerülése. Ezek a lépések közvetlenül megszüntethetik a robot tervezett biztonsági funkcióját. A DCS különösen azért létezik, hogy csökkentse a robot váratlan mozgásának és ebből eredő sérülés okozásának kockázatát. Ha a DCS riasztást generál, a helyes eljárás annak megállapítása, miért nem teljesül a biztonsági feltétel, nem pedig olyan megoldás keresése, amellyel a rendszer „figyelmen kívül hagyja” ezt a feltételt.
Ha valóban szükségessé válik a DCS-konfiguráció módosítása, akkor ezt is az eszköz eredeti biztonsági tervezése, kockázatértékelése és a megfelelő biztonsági üzembe helyezési folyamat szerint kell elvégezni – nem végezhető el önkényesen.
Hogyan lehet elkerülni, hogy naponta annyiszor zavarjon
Az SRVO-408 hibát nem lehet teljesen megelőzni egyetlen alkatrész cseréjével. A hiba a teljes robotbiztonsági rendszer állapotához kapcsolódik, ezért a rendszeres karbantartásnak a biztonsági áramkört is fel kell foglalnia.
Például rendszeresen ellenőrizni kell a vészhelyzeti leállítógombokat, a biztonsági kapukat, a biztonsági reléket, a biztonsági PLC-ket és a kapcsolódó biztonsági vezetékeket. A robotvezérlőszekrény belsejében lévő csatlakozók és a biztonsági I/O-vezetékek is stabilan rögzítve maradnak, hogy a hosszú távú rezgés ne okozzon rossz érintkezést és időszakos biztonsági hibákat.
Ha módosításokat hajtott végre a DCS-konfiguráción egy Fanuc vezérlőn, érdemes feljegyezni a változtatásokat, és érvényes vezérlőbiztonsági másolatot készíteni. Különösen akkor szükséges újraellenőrizni, hogy a DCS biztonsági konfiguráció egyezik-e az aktuális géppel, ha vezérlőt cseréltek, biztonsági másolatot állítottak vissza, vagy újra konfigurálták a robotmunkaállomást.
Azoknál a robotoknál, amelyek hosszú ideje üzemelnek, figyelni kell a biztonsági vezetékek öregedésére is. A hosszú távú rezgés, a kábelvezetékekben zajló előre-hátra mozgás, az olajszennyeződés és a gyakori hajlítás mindegyike problémákat okozhat a kábelekben vagy csatlakozókban. Ezek a hibák nem okoznak azonnal riasztást, de idővel instabil biztonsági bemeneti állapotként jelentkeznek, és néha DCS-riasztásokat – például az SRVO-408-at – eredményeznek.
Mikor érdemes szakembert hívni?
Ha már megerősítette, hogy a külső eszközök – például a vészleállítás, a biztonsági kapuk és a biztonsági relék – mind normálisak, de az SSO[3] továbbra is KI van kapcsolva, akkor mélyebbre kell nyúlnia a DCS-konfigurációban és a biztonsági jelekben.
Különösen akkor érdemes szakmérnököt bevonni, aki jártas a Fanuc DCS rendszerben, ha bármelyik alábbi helyzet áll fenn: éppen cserélték a robotvezérlőt; éppen visszaállították a DCS- vagy rendszerbiztonsági mentést; nemrég módosították a biztonsági PLC-programot; éppen újra konfigurálták a robotmunkaállomást; a DCS Safe I/O Connect konfigurációja számára nem egyértelmű; nem tudja, melyik biztonsági bemenet vezérli az SSO[3]-at; minden külső biztonsági eszköz normális, de az SRVO-408 hibakód makacsul továbbra is megjelenik; vagy a robot egész sor DCS-kapcsolódó riasztást adott ki.
A biztonsági funkciók esetében a legfontosabb nem az, hogy „minél gyorsabban újra elindítsuk a robotot”, hanem hogy megbizonyosodjunk: a biztonsági rendszer valóban visszatért a megfelelő állapotba.
