Hoe om die Fanuc-robotalarm SRVO-408 op te los?
Vir die mense wat aan Fanuc-robots werk: wanneer jy hierdie SRVO-408-alarm teëkom, is baie mense se eerste reaksie: „Grootliks, die servo-motor maak weer ’n toneelstuk?“ Die kode begin immers met SRVO, dus is dit moeilik om nie aan die servo te dink nie. Maar laat my jou ’n bietjie afkoel: hierdie alarm het werklik min of geen verband met die servo-motor of die servo-versterker nie — dit is eintlik ’n alarm wat uit Fanuc se DCS-veiligheidstelsel verskyn.
Van die SRVO-408-gevalle wat ons op die werf hanteer het, bly dit in nege en ’n half uit tien gevalle uiteindelik by probleme met die veiligheidskring of die DCS-konfigurasie — glad nie ’n motordefek nie. Vandaag gaan ek dit dus stuk vir stuk ontbind en met almal bespreek wat werklik agter SRVO-408 skuil, en waar om te begin as jy dit teëkom, sodat jy nie jou tyd vermors deur blindelings die servo uitmekaar te trek nie en produksie onnodig vertrag. 
Wat beteken die lyn op die skerm, "SRVO-408 DCS SSO Ext Emergency Stop," werklik?
Eerstens, onthou hierdie een sin: SRVO-408 = DCS SSO External Emergency Stop = die veiligheidsuitset SSO[3] is na die AF-toestand getrek. Daar is twee terme hier wat jy eers moet verstaan: DCS en SSO.
DCS, wat staan vir Dual Check Safety, is 'n stel veiligheidsfunksies binne die Fanuc-robotbeheerstelsel. Deur middel van redundante seine, veiligheidsmonitering en veiligheid I/O, hou dit toe op die robot se beweging en veiligheidstoestand om te voorkom dat die robot buite beheer raak en iemand beseer of teen toerusting bots. Wat SSO betref, kan jy dit beskou as 'n tipe veiligheidsuitsetsein binne die DCS-stelsel — in wese 'n "veiligheidsvlag" wat DCS uitstuur.
In die SRVO-408-alarm verwys Fanuc spesifiek na die veiligheidsuitset wat genommer is as SSO[3]. Wanneer die DCS-veiligheidslogika bepaal dat die SSO[3]-uitset wat met die eksterne noodstop verbind is, AF gaan het, gaan die robot in ’n noodstop-toestand oor en lig die skerm op met SRVO-408.
Soos u kan sien, vertel hierdie alarm u dus basies: die DCS-veiligheidslogika glo dat daar iets verkeerd is met die veiligheidsuitset wat aan die eksterne noodstop gekoppel is, en dit het reeds afgeskakel. Dit is ’n heeltemal ander saak as dinge soos „servomotor oorstroom“, „enkoder-fout“ of „versterker verbrand“. In die verlede, wanneer u ’n servosalarm gehad het, sou u dalk die motor, die enkoder, die versterker of die kabels gaan toets. Maar wanneer u SRVO-408 kry, is ’n meer betroubare benadering om langs die DCS-veiligheidssignaalreeks te volg. Eenvoudig gestel: SRVO-408 → SSO[3] AF → toets Veilige I/O-konneksie → bepaal wat SSO[3] beheer → toets die ooreenstemmende veiligheidskring.
Hoekom raak hierdie alarm altyd verstrengel met dinge soos noodgeval-stopknoppies en veiligheidshekke?
Op baie outomatiese vervaardigingslyne werk die Fanuc-robot nie alleen in isolasie nie. Dit word dikwels omring deur veiligheidshekke, veiligheidsliggordyne, noodgeval-stopknoppies, veiligheidsrelais, veiligheids-PLC's en soms ander robots, masjienwerktuie of transportbandlyne in die nabyheid. Hierdie toestelle is aan die robotbeheerstelsel gekoppel deur veiligheidskringe. 'n Tipiese veiligheidsketting lyk soos volg: noodgeval-stopknoppie ingedruk → toestand van veiligheidsrelais of veiligheids-PLC verander → veiligheidsein afgesny → DCS-veiligheidslogika bespeur iets verkeerd → SSO[3] gesit na AF → SRVO-408 verskyn.
Dus wanneer jy SRVO-408 sien, is dit waar dat jy die noodstop- en veiligheidstoestelle moet gaan toets. Maar daar is een ding wat veral belangrik is: jy mag nie net aanneem dat „die veiligheidshek is oop, dus moet dit SRVO-408 wees“ nie. Fanuc se DCS het ’n hele reeks verskillende veiligheidsfunksies, en daar is ook ’n ry soortgelyke alarmkodes — byvoorbeeld dié wat met „heining oop“ of „servo ontkoppel“ verband hou. Wanneer jy werklik foute vind, moet jy nie net rondom die vlak van „iets is verkeerd met die robot se veiligheidsfunksie“ beweeg nie — gaan dieper in: watter spesifieke veiligheidsein het presies verander? En watter SSO beheer daardie sein? Sodra jy hierdie vlak vaslê, kan jy die probleem akkuraat identifiseer.
Die mees algemene ontlokkinge wat jy op die werf sal sien, een vir een aangedui
1. SSO[3] is werklik na AF gestel
Dit is die mees direkte oorsaak, en dit is die eerste ding wat jy moet bevestig wanneer jy SRVO-408 fouteer. Fanuc se kern aktiveringsvoorwaarde vir SRVO-408 is: SSO[3] is in die AF-toestand. Met ander woorde, wanneer jy hierdie alarm sien, moenie gou begin vermoed dat die servo-versterker foutief is nie — gaan eers kyk na die DCS-status om te bepaal of SSO[3] werklik AF is. As dit werklik AF is, is die volgende stap om uit te vind watter veiligheidslogika daardie uitset beheer. In sommige stelsels kan SSO[3] aan ’n spesifieke veiligheidsinvoer, SPI, gekoppel wees, of dit kan deur logiese verwantskappe binne Safe I/O Connect beheer word. Presies hoe dit gekonfigureer is, hang af van hoe daardie spesifieke robot se veiligheidsontwerp oorspronklik ingestel is. Moenie dus aanneem dat jy een vasgeleë I/O-nommer op elke masjien kan toepas nie.
2. Die veiligheidsinvoer wat aan SSO[3] gekoppel is, het na AF geval
Sodra as jy SSO[3] gevind het, is die volgende stap om te bepaal wat dit beheer. Hierdie stap is veral krities tydens probleemoplossing. Byvoorbeeld, stel dat ’n spesifieke Fanuc-robot SSO[3] aan ’n veiligheidstoegang, SPI, gekoppel het. As daardie SPI AF gaan omdat ’n eksterne veiligheidsvoorwaarde nie bevredig word nie, sal die DCS-logika natuurlik ook SSO[3] na AF stel, wat uiteindelik SRVO-408 aktiveer.
In hierdie geval kan die werklike foutepunt glad nie binne die Fanuc-beheerkabinet wees nie. Dit kan wees dat die eksterne noodstopstelsel nie herstel is nie, die veiligheidsrelais nie weer ingetrek het nie, die veiligheids-PLC nie die regte veiligheidseinale uitstuur nie, ’n draad op die veiligheidstoegang gebreek het nie, ’n veiligheidsskakelaar steeds ingedruk gehou word en nie vrygelaat is nie, of ’n verbinding ’n swak kontak het nie. Tydens probleemoplossing is dit dus die beste om deur die seinpad afdeling vir afdeling te werk, eerder as om dadelik hardeware te vervang.
3. Daar is ’n fout in die eksterne noodstopstelsel self
Die nooodstopstelsel binne die robotsel is ’n area wat spesiale aandag vir SRVO-408 vereis. Wanneer ’n bediener die nooodstopknoppie druk, maak die veiligheidsrelais oop, ontvang die robotbeheerder die ooreenstemmende veiligheidstatus, en voer die DCS ’n veiligheidstop uit — dit is die veiligheidsfunksie wat normaal werk; daar is geen probleem nie. Die probleem ontstaan wanneer die nooodstopknoppie reeds vrygestel is, maar die veiligheidsketting nog nie volledig herstel het nie. Byvoorbeeld, die nooodstopknoppie kan meganies herstel wees, maar die veiligheidsrelais het nie herstel nie; of die veiligheids-PLC glo steeds dat ’n sekere veiligheidsvoorwaarde nie bevredig is nie. In hierdie geval sal die robot steeds nie beweeg nie en sal dit voortgaan om veiligheidalarme te genereer.
Tydens probleemoplossing moet jy nie net kyk of die noodstop-knoppie teruggepop het nie — jy moet bevestig dat die hele veiligheidskringloop herstel is. Jy kan dit in hierdie volgorde kontroleer: noodstop-knoppie → veiligheidsrelais → veiligheids-PLC → veiligheidstoestel → DCS Safe I/O Connect → SSO[3]. As enige skakel op die pad nie herstel is nie, kan die robot nie na ’n normale veiligheidstoestand terugkeer nie.
4. Die DCS Safe I/O Connect-konfigurasie is gewysig
As die robot wat die hele tyd goed gefunksioneer het, onlangs begin is om gereeld SRVO-408-foute te genereer, en iemand die beheerderkonfigurasie aangeraak het, dan verdien die DCS-konfigurasie nou spesiale aandag. Byvoorbeeld: die DCS-veiligheids-I/O is gewysig, die beheerder is vervang, ’n robotrugsteun is herstel, die veiligheids-PLC-program is verander, die robotwerksentrum is herkonfigureer, ’n eksterne veiligheidstoestel is vervang, of die robotsisteem is weer in werking gestel. Dit geld veral vir tweedehandse Fanuc-beheerders wat voorheen op ’n ander robotsisteem gemonteer was en later verwyder en op nuwe toerusting geïnstalleer is — jy moet verifieer of die oorspronklike DCS-veiligheidskonfigurasie werklik ooreenstem met die veiligheidsontwerp van die huidige masjien.
Die tydstip waarop die alarm verskyn, is self 'n belangrike aanwysing. As die masjien nie hierdie probleem in jare ondervind het nie, en SRVO-408 verskyn die oomblik wat 'n beheerder vervang word, moet jy eers die beheerder se DCS-konfigurasie en veiligheid I/O-status nakies, eerder as om die robot se servo-motor te vermoed.
5. Die veiligheids-PLC of 'n ander eksterne veiligheidstoestel gee nie die korrekte status nie
Tans gebruik baie robot-werkstasies 'n veiligheids-PLC. As Fanuc se DCS via seine met 'n eksterne veiligheidstelsel verbind is, sal die veiligheids-PLC se status ook die robot se finale veiligheidstoestand beïnvloed. Byvoorbeeld: die veiligheids-PLC bespeur dat 'n sekere veiligheidsvereiste nie bevredig word nie → die veiligheidsuitvoer herstel nie → Fanuc se veiligheidsinvoer bly AF → die DCS-logika hou SSO[3] AF → SRVO-408. In hierdie geval is dit basies tydverspilling om al jou pogings te spandeer om Fanuc se servo-stelsel te toets.
Indien daar ’n veiligheids-PLC op die terrein is, is dit ’n goeie idee om terselfdertyd die PLC se diagnostiese inligting te kontroleer om te bevestig of die veiligheidsingange, -uitgange en verwante veiligheidslogika almal in die verwagte toestand is.
6. Die Veilige I/O-konneksielogika stem nie ooreen met die masjien se werklike ontwerp nie
Daar is ’n ander situasie wat maklik oor die hoof gesien word: die DCS-veiligheids-I/O-konfigurasie self stem nie ooreen met die masjien se huidige veiligheidsontwerp nie. Byvoorbeeld, die robot mag herkonfigureer geword het en die eksterne veiligheidstoestelle verander, maar die DCS-veiligheids-I/O-konfigurasie is nie opgedateer om daarmee ooreen te stem nie; of die beheerder is van ’n ou rugsteunherstel, wat ’n mislukking tussen die huidige toerusting en die oorspronklike veiligheidslogika veroorsaak. In hierdie geval mag die robot self glad nie ’n meganiese of servo-hardewarefout hê nie, maar die DCS glo bloot dat die veiligheidstoestand nie bevredig word nie.
Dus as jy reeds bevestig het dat al die eksterne veiligheidstoestelle normaal is, maar SSO[3] net nie terugkom nie, moet jy die huidige DCS Safe I/O Connect-konfigurasie noukeurig vergelyk met die masjien se oorspronklike elektriese trekkings, inwerkingstellingrekords en veiligheidsontwerp.
Hoe ek gewoonlik hierdie stap vir stap tydens probleemopsporing volg
Die grootste taboe by die hantering van hierdie tipe alarm is om 'n onderdeel te vervang sodra jy 'n alarm sien. Die SRVO-408-alarm het dit reeds duidelik vir jou gespel: SSO[3] AF. So tydens werklike probleemopsporing volg jy hierdie sein agteruit.
Eerstens, skryf die volledige alarmlog vanaf die lesbedieningspaneel neer. Behalwe vir SRVO-408, kyk ook of die alarmgeskiedenis enige ander DCS-, veiligheid I/O- of noodstopverwante alarums bevat. Soms is SRVO-408 net die finale gevolg, en die werklike oorsaak mag reeds vroeër verskyn het.
Volg dan die relevante DCS-status om te bevestig of SSO[3] werklik AF is. As SSO[3] AF is, gaan voort om deur die Safe I/O Connect-konfigurasie te kyk om die inset- of logika-verwantskap wat SSO[3] beheer, te vind. Wat ook al gebeur, raai nie of vertrou nie op vorige ervaring by hierdie stap nie — die DCS-konfigurasie kan baie verskil volgens die robotmodel, beheerder en werksstasie. Selfs as twee masjiene albei Fanuc is, kan hul SPI-, SSO- en veiligheid-I/O-toekennings heeltemal verskil.
Sodra jy die ooreenstemmende veiligheid-inset gevind het, kontroleer of dit tans AAN of AF is. As daardie veiligheid-inset ook AF is, gaan voort met die buitewaartse sporing. Byvoorbeeld: SPI AF → kontroleer die veiligheid-PLC → kontroleer die veiligheid-relais → kontroleer die noodstop → kontroleer toestelle soos die veiligheidshekkie en liggordyn.
As al die eksterne veiligheidstoestelle normaal is, maar die SPI steeds nie terugkom nie, moet jy verder gaan en die veiligheidbedrading, die konnektore en die DCS-konfigurasie nakien. As die eksterne veiligheidstelsel volkome herstel is, maar die DCS-status steeds af is, moet jy jou aandag rig op of die "Safe I/O Connect"-konfigurasie korrek is.
Hierdie probleemoplossingsmetode mag stadiger lyk as om net die servo-versterker te vervang, maar in praktyk is dit gewoonlik vinniger. Dit is omdat jy die probleem identifiseer deur die alarm se logika te volg, eerder as om op 'n proef-en-fout-basis onderdele te vervang.
Kan jy net die herstelknoppie druk en dit dwing om deur te gaan?
Wanneer ’n bediener ’n robotalarm aktiveer, is die eerste reaksie om op RESET te druk. Jy kan ook probeer om SRVO-408 te herstel, maar net om op reset te druk sal basies nie die probleem oplos nie. Die rede is eenvoudig: as die DCS steeds bespeur dat SSO[3] AF is, het die veiligheidsvoorwaarde nie herstel nie, en dit sal net weer onmiddellik alarm nadat jy dit herstel het. Die korrekte benadering is: herstel eers die veiligheidsvoorwaarde → bevestig dat SSO[3] na ’n normale toestand teruggekeer het → herstel dan die alarm → en verifieer laastens die robot se bedryfsstatus.
Om herhaaldelik op RESET te druk, of selfs die beheerder voortdurend te herbegin sonder om die onderliggende oorsaak van SSO[3] wat AF is, op te los, is bloot ’n verspilling van pogings. Nog kritieser: moenie — net om tyd te bespaar — die veiligheidsinvoer dwing-omskakel of die veiligheidslogika arbitrêr verander om die robot aan die beweeg te kry nie.
Kan die servo-motor werklik gebreek wees?
Algemeen nie. Selfs al begin die alarmnaam met SRVO, is die kerndefinisie van SRVO-408 "DCS SSO Ext Emergency Stop", wat ooreenstem met die SSO[3] AF-toestand binne die DCS-veiligheidsfunksie. As die robot dus slegs SRVO-408 aangegee het, sonder enige ander alarm wat duidelik na die servo-stelsel wys, is dit nie raadsaam om regstreeks die servomotor, servoversterker, enkoder of verminderder te vervang nie. Hierdie komponente mag wel die primêre verdagtes wees vir ander Fanuc-alarme, maar vir SRVO-408 is hulle nie die eerste dinge om te toets nie.
Dit is ook hoekom jy dikwels op die werf gevalle sien waar "die servoversterker vervang is en dit steeds alarm" — want die probleem was van die begin af nie in die versterker nie, en dit maak nie saak hoeveel jy daarvan vervang nie.
Wat jy ook al doen, neem nie die kortpad van die veiligheidseinale deur kortsluiting nie
SRVO-408 is ’n alarm wat verband hou met die robot se veiligheidsfunksie, en dit moet nie soos ’n gewone produksiealarm behandel word nie. Sommige mense ter plaatse dink dalk: "Hoekom nie net nou hierdie veiligheidsein aansluit nie en die robot aan die werk kry nie?" Hierdie benadering is baie gevaarlik.
Moenie die robot onder geen omstandighede weer in werking stel deur metodes soos hierdie nie: aansluiting van die veiligheidinvoer, dwing van die veiligheidsuitvoer na AAN, arbitrêre afskakeling van DCS, omseil van die veiligheids-PLC, verwydering van die veiligheidsdeur-onderskakelaar of omseil van die noodstopstelsel. Hierdie optredes kan die robot se bedoelde veiligheidsfunksie direk vernietig. DCS bestaan veral om die risiko van onverwagte beweging van die robot en gevolglike besering te verminder. Indien DCS ’n alarm aktiveer, is die korrekte benadering om uit te vind hoekom die veiligheidsvoorwaarde nie bevredig word nie, nie om ’n manier te vind om die stelsel te laat „ignoreer“ daardie voorwaarde nie.
Indien dit werklik nodig word om die DCS-konfigurasie te wysig, moet dit ook volg die toerusting se oorspronklike veiligheidsontwerp, risiko-evaluasie en die ooreenstemmende veiligheid-inbedryfstellingproses — dit kan nie op ‘n whimsiese manier gedoen word nie.
Hoe om dit te keer dat dit jou so dikwels in daaglikse gebruik pla
SRVO-408 is nie iets wat jy volkome kan voorkom deur bloot ‘n spesifieke onderdeel te vervang nie. Dit is verbind aan die toestand van die hele robot-veiligheidstelsel, dus moet rutynonderhoud ook die veiligheidskring insluit.
Byvoorbeeld, ondersoek gereeld die noodstopknoppies, veiligheidshekke, veiligheidsrelais, veiligheids-PLC’s en die verwante veiligheidswiring. Die konnektore en veiligheid-I/O-wiring binne-in die robotbeheerkabinet moet ook stewig bly, sodat langtermynvibrasie nie swak kontak veroorsaak en onderbrekende veiligheidsfoute produseer nie.
As jy veranderinge aan die DCS-konfigurasie op ’n Fanuc-beheerder aangebring het, is dit die beste om ’n rekord van die veranderinge te bêre en ’n geldige beheerder-terugsetbeskerming te handhaaf. Veral na die verruiling van beheerders, die herstel van ’n terugsetbeskerming of die herkonfigurasie van die robotwerksentrum moet jy weer bevestig dat die DCS-veiligheidskonfigurasie ooreenstem met die huidige masjien.
Vir robots wat reeds baie lank in diens is, moet jy ook oppas vir verouderde veiligheidsbedrading. Langtermyn-vibrasie, heen-en-weer-beweging binne kabelspore, oliebesmetting en gereelde buiging kan almal probleme met kabele of verbindingsstukke veroorsaak. Hierdie probleme sal nie dadelik ’n alarm aktiveer nie, maar sal uiteindelik as onstabiele veiligheidsinvoertoestande verskyn, wat soms DCS-alarme soos SRVO-408 veroorsaak.
Wanneer moet jy ’n spesialis inskakel?
As jy reeds bevestig het dat eksterne toestelle soos die noodstop, veiligheidsdeure en veiligheidrelais almal normaal is, maar SSO[3] steeds AF is, dan moet jy verder kyk na die DCS-konfigurasie en veiligheidseine.
In besonder, as jy enige van die volgende situasies teëkom, is dit 'n goeie idee om 'n ingenieur in te roep wat vertroud is met Fanuc DCS: die robotbeheerder is net vervang; 'n DCS- of stelselrugsteun is net herstel; die veiligheid-PLC-program is onlangs gewysig; die robotwerksentrum is net herkonfigureer; die DCS Safe I/O Connect-konfigurasie is vir jou onduidelik; jy weet nie watter veiligheidstoestel SSO[3] beheer nie; alle eksterne veiligheidstoestelle is normaal maar SRVO-408 verskyn hardnekkig; of die robot het 'n hele reeks DCS-verwante alarms uitgewys.
Vir veiligheidsfunksies is die belangrikste ding nie "om die robot weer so gou moontlik aan die beweeg te kry" nie — dit is om te bevestig dat die veiligheidstelsel werklik na die korrekte toestand teruggekeer het.
