Hur löser man Fanuc-robotlarmet SRVO-408?
För er som arbetar med Fanuc-robotar: När ni stöter på denna SRVO-408-larmkod är många människors första reaktion: »Utmärkt – servomotorn gör igen ett utbrott?« Eftersom koden börjar med SRVO är det ju svårt att inte tänka på servosystemet. Men låt mig kyla ner er lite: Detta larm har faktiskt mycket lite att göra med servomotorn eller servoförstärkaren – det är i själva verket ett larm som uppstår i Fanucs DCS-säkerhetssystem.
Av de SRVO-408-fall vi hanterat på verkstaden visar nio och en halv av tio slutligen att problemet ligger i säkerhetsstreckan eller DCS-konfigurationen – inte alls i en motorfel. Idag kommer jag därför att gå igenom detta steg för steg och förklara för er alla vad som egentligen gömmer sig bakom SRVO-408, samt var ni bör börja söka när ni stöter på det – så att ni inte slösar bort tid på att slita isär servosystemet utan anledning och därmed försinker produktionen onödigt. 
Vad betyder raden på skärmen, "SRVO-408 DCS SSO Ext Emergency Stop"?
Kom ihåg först denna mening: SRVO-408 = DCS SSO External Emergency Stop = säkerhetsutgången SSO[3] har satts i OFF-läget. Det finns två termer här som du måste förstå först: DCS och SSO.
DCS, förkortning för Dual Check Safety, är en uppsättning säkerhetsfunktioner inom Fanuc-robotstyrsystemet. Genom redundanta signaler, säkerhetsövervakning och säkerhets-I/O övervakar det robotens rörelse och säkerhetsstatus för att förhindra att roboten går ur kontroll och skadar någon eller kolliderar med utrustning. När det gäller SSO kan du tänka på det som en typ av säkerhetsutgångssignal inom DCS-systemet – i princip ett "säkerhetsflagga" som DCS skickar ut.
I SRVO-408-larmet avser Fanuc specifikt säkerhetsutgången med nummer SSO[3]. När DCS:s säkerhetslogik avgör att den yttre nödstoppets associerade SSO[3]-utgång har stängts av går roboten in i ett nödstoppläge och skärmen lyser upp med SRVO-408.
Så som du kan se informerar dig detta larm i princip om följande: DCS:s säkerhetslogik anser att det finns ett fel på säkerhetsutgången som är kopplad till det yttre nödstoppet, och den har redan stängt av den. Detta är en helt annan fråga än exempelvis "servomotor överström", "enkoderfel" eller "förstärkare bränd ut". I det förflutna, när du fick ett servolarm, kunde du gå och kontrollera motorn, enkodern, förstärkaren eller kablarna. Men när du får SRVO-408 är en mer tillförlitlig metod att spåra DCS:s säkerhetssignalkedja. Enkelt uttryckt: SRVO-408 → SSO[3] AVSTÄNGD → kontrollera Safe I/O Connect → ta reda på vad som styr SSO[3] → kontrollera motsvarande säkerhedskrets.
Varför blir denna larmfunktion alltid förvirrad med saker som nödstoppknappar och säkerhetsgrindar?
På många automatiserade produktionslinjer arbetar Fanuc-roboten inte ensam i isolering. Den omges ofta av säkerhetsgrindar, säkerhetsljusförhänge, nödstoppknappar, säkerhetsreläer, säkerhets-PLC:er och ibland andra robotar, maskinverktyg eller transportband i närheten. Dessa enheter är anslutna till robotens styrsystem via säkerhetskretsar. En typisk säkerhetskedja ser ut så här: nödstoppknapp aktiverad → tillståndet för säkerhetsreläet eller säkerhets-PLC:n ändras → säkerhetssignalen kopplas bort → DCS:s säkerhetslogik upptäcker ett fel → SSO[3] ställs på OFF → felkoden SRVO-408 visas.
Så när du ser SRVO-408 är det sant att du bör kontrollera nödstoppet och säkerhetsutrustningen. Men det finns en sak som är särskilt viktig: du får inte bara anta att »säkerhetsdörren är öppen, så det måste vara SRVO-408«. Fanucs DCS har en hel rad olika säkerhetsfunktioner, och det finns också en rad liknande larmkoder – till exempel sådana som gäller »stängsel öppet« eller »servo frånkopplad«. När du faktiskt felsöker bör du inte bara gå i cirklar på nivån »något är fel med robotens säkerhetsfunktion« – fortsätt att gräva djupare: vilken specifik säkerhetssignal ändrades exakt? Och vilken SSO styr den signalen? När du har identifierat detta på den nivån kan du lokalisera problemet exakt.
De vanligaste utlösningarna som du kommer att se på plats, pekade ut en i taget
1. SSO[3] har faktiskt dragits till OFF
Detta är den mest direkta orsaken, och det är det första du behöver bekräfta vid felsökning av SRVO-408. Fanucs kärnutlösande villkor för SRVO-408 är: SSO[3] är i OFF-läget. Med andra ord, när du ser detta larm bör du inte genast misstänka servoförstärkaren – gå istället och kolla DCS-statusen för att se om SSO[3] verkligen är OFF. Om det verkligen är OFF är nästa steg att ta reda på vilken säkerhetslogik som styr den utgången. I vissa system kan SSO[3] vara kopplad till en specifik säkerhetsingång, SPI, eller den kan styras via logiska relationer inom Safe I/O Connect. Exakt hur den är konfigurerad beror på hur den aktuella robotens säkerhetsdesign ursprungligen var inställd. Anta därför inte att du kan använda samma fasta I/O-nummer på alla maskiner.
2. Den säkerhetsingång som är kopplad till SSO[3] har gått till OFF
När du har hittat SSO[3] är nästa steg att ta reda på vad som styr den. Detta steg är särskilt kritiskt vid felsökning. Till exempel kan en viss Fanuc-robot ha SSO[3] kopplad till en säkerhetsingång, SPI. Om den SPI:n går OFF på grund av att någon extern säkerhetsförutsättning inte är uppfylld, kommer DCS-logiken naturligtvis också att ställa in SSO[3] på OFF, vilket till slut utlöser SRVO-408.
I detta fall kan den faktiska felkällan överhuvudtaget inte ligga i Fanuc-styrskåpet. Det kan istället vara så att den externa nödstoppkretsen inte har återställts, säkerhetsreläet inte har dragit in igen, säkerhets-PLC:n inte har genererat det korrekta säkerhetssignalet, en ledning till säkerhetsingången har gått sönder, en säkerhetsswitch hålls fortfarande nere och har inte släppts, eller en kontakt har en dålig anslutning. Vid felsökning är det därför bäst att gå igenom signalvägen avsnitt för avsnitt i stället för att direkt byta ut hårdvara.
3. Det finns ett fel i den externa nödstoppkretsen själv
Nödstopp-systemet inom robotcellen är ett område som kräver särskild uppmärksamhet för SRVO-408. När en operatör trycker på nödstoppknappen öppnas säkerhetsreläet, robotstyrningen tar emot motsvarande säkerhetsstatus och DCS utför ett säkerhetsstopp – det vill säga säkerhetsfunktionen fungerar normalt, inget fel där. Problemet uppstår när nödstoppknappen redan har släppts, men säkerhetskedjan inte fullständigt återställts. Till exempel kan nödstoppknappen ha återställts mekaniskt, men säkerhetsreläet har inte återställts; eller säkerhets-PLC:n tror fortfarande att någon säkerhetsförutsättning inte är uppfylld. I detta fall rör sig roboten fortfarande inte och fortsätter att generera säkerhetslarm.
Under felsökning ska du alltså inte bara titta på om nödstoppknappen har återställts — du måste bekräfta att hela säkerhetskedjan har återställts. Du kan kontrollera saker i denna ordning: nödstoppknapp → säkerhetsrelä → säkerhets-PLC → säkerhetsingång → DCS Safe I/O Connect → SSO[3]. Om någon länk längs vägen inte har återställts kan roboten inte återgå till ett normalt säkerhetstillfälle.
4. Konfigurationen av DCS Safe I/O Connect har ändrats
Om roboten har fungerat korrekt hela tiden och plötsligt börjat ge SRVO-408-fel ofta, och någon har ändrat i kontrollerns konfiguration, bör DCS-konfigurationen undersökas noggrant. Till exempel: DCS:s säkerhets-I/O har ändrats, kontrollern har bytts ut, en robot-säkerhetskopia har återställts, säkerhets-PLC-programmet har ändrats, robotarbetsplatsen har omkonfigurerats, en extern säkerhetsenhet har ersatts eller robotsystemet har tagits i drift igen. Detta gäller särskilt begagnade Fanuc-kontroller som tidigare monterats på ett annat robotsystem och senare tagits bort och installerats på ny utrustning – du måste verifiera om den ursprungliga DCS-säkerhetskonfigurationen verkligen motsvarar säkerhetsdesignen för den aktuella maskinen.
Tidpunkten då alarmet visas är i sig en viktig ledtråd. Om maskinen inte haft detta problem på åratal och SRVO-408 dyker upp precis när en styrenhet byts ut, bör du först kontrollera styrenhetens DCS-konfiguration och säkerhets-I/O-status istället för att misstänka robotens servomotor.
5. Säkerhets-PLC:n eller någon annan extern säkerhetsenhet ger inte korrekt status
Idag använder många robotarbetsstationer en säkerhets-PLC. Om Fanucs DCS är ansluten till ett externt säkerhetssystem via signaler påverkar säkerhets-PLC:s status också robotens slutliga säkerhetsstatus. Till exempel: säkerhets-PLC:n upptäcker att något säkerhetskrav inte är uppfyllt → säkerhetsutgången återställs inte → Fanucs säkerhetsingång förblir AVSLAGEN → DCS-logiken håller SSO[3] AVSLAGEN → SRVO-408. I detta fall är det i princip slöseri med tid att undersöka Fanucs servosystem.
Om det finns en säkerhets-PLC på plats är det en bra idé att samtidigt kontrollera PLC:s diagnostikinformation för att bekräfta om säkerhetsinmatningarna, utmatningarna och den relaterade säkerhetslogiken alla befinner sig i det förväntade tillståndet.
6. Logiken för Safe I/O Connect stämmer inte överens med maskinens faktiska design
Det finns en annan situation som lätt kan missas: DCS:s säkerhets-I/O-konfiguration stämmer inte överens med maskinens nuvarande säkerhetsdesign. Till exempel kan roboten ha konfigurerats om och de externa säkerhetsutrustningarna har ändrats, men DCS:s säkerhets-I/O-konfiguration har inte uppdaterats för att matcha detta; eller så har styrenheten återställts från en gammal säkerhetskopia, vilket orsakar en missmatch mellan den nuvarande utrustningen och den ursprungliga säkerhetslogiken. I detta fall kan roboten själv inte ha något mekaniskt eller servohårdvarufel alls, men DCS tror helt enkelt att säkerhetsvillkoret inte är uppfyllt.
Om du redan har bekräftat att alla externa säkerhetsenheter fungerar normalt, men SSO[3] inte återkommer, måste du noggrant jämföra den aktuella DCS Safe I/O Connect-konfigurationen med maskinens ursprungliga elektriska ritningar, igångkörningsdokument och säkerhetsdesign.
Hur jag vanligtvis spårar detta steg för steg vid felsökning
Det största tabun när man hanterar denna typ av larm är att "byta ut en komponent så fort man ser ett larm." Larmet SRVO-408 anger redan tydligt: SSO[3] OFF. Vid faktisk felsökning spårar du därför signalen baklänges.
Först skriver du ner den fullständiga larmloggningen från handledningspanelen. Förutom SRVO-408 kontrollerar du också om larmhistoriken innehåller andra larm relaterade till DCS, säkerhets-I/O eller nödstopp. Ibland är SRVO-408 bara slutresultatet, och den verkliga orsaken kan ha dykt upp tidigare.
Nästa steg är att kontrollera den relevanta DCS-statusen för att bekräfta om SSO[3] verkligen är AV. Om SSO[3] är AV går du vidare och granskar Safe I/O Connect-konfigurationen för att hitta den inmatning eller logikrelation som styr SSO[3]. Oavsett vad du gör ska du inte gissa eller lita på tidigare erfarenheter i detta steg – DCS-konfigurationen kan variera kraftigt beroende på robotmodell, styrenhet och arbetsstation. Även om två maskiner båda är Fanuc kan deras SPI-, SSO- och säkerhets-I/O-tilldelningar vara helt olika.
När du har hittat motsvarande säkerhetsinmatning kontrollerar du om den för närvarande är PÅ eller AV. Om även denna säkerhetsinmatning är AV fortsätter du att spåra utåt. Till exempel: SPI AV → kontrollera säkerhets-PLC:n → kontrollera säkerhetsreläet → kontrollera nödstoppet → kontrollera enheter som säkerhetsdörren och ljusgardinen.
Om alla externa säkerhetsenheter fungerar normalt men SPI fortfarande inte återställs, måste du gå vidare och kontrollera säkerhetskablarna, anslutningarna och DCS-konfigurationen. Om det externa säkerhetssystemet har återställts fullständigt men DCS-statusen fortfarande är av, fokusera på om konfigurationen av "Safe I/O Connect" är korrekt.
Denna felsökningsmetod kan verka långsammare än att bara byta ut servoförstärkaren, men i praktiken är den oftast snabbare. Det beror på att du lokaliserar felet genom att följa alarmets logik istället för att förlita dig på trial-and-error-byten av komponenter.
Kan du bara trycka på återställning och tvinga igenom?
När en operatör utlöser en robotlarm är den första reaktionen att trycka på RESET. Du kan försöka återställa SRVO-408 också, men att bara trycka på reset löser i princip inte problemet. Anledningen är enkel: om DCS fortfarande upptäcker att SSO[3] är AV, har säkerhetsvillkoret inte återställts, och larmet kommer att utlösas igen omedelbart efter återställning. Rätt tillvägagångssätt är: återställ först säkerhetsvillkoret → bekräfta att SSO[3] återgått till normalt tillfälle → återställ sedan larmet → och verifiera slutligen robotens driftstatus.
Att upprepade gånger trycka på RESET eller till och med kontinuerligt starta om styrenheten utan att lösa den underliggande orsaken till att SSO[3] är AV är rent och skärt slöseri med arbetsinsats. Ännu allvarligare är att aldrig – bara för att spara tid – använda en tvångsövergång (force-jumper) på säkerhetsingången eller godtyckligt ändra säkerhetslogiken för att få roboten att röra sig.
Kan servomotorn faktiskt vara trasig?
I allmänhet inte. Även om larmnamnet börjar med SRVO är kärndefinitionen av SRVO-408 "DCS SSO Ext Emergency Stop", vilket motsvarar tillståndet SSO[3] OFF inom DCS:s säkerhetsfunktion. Om roboten därför endast genererar larmet SRVO-408, utan något annat larm som tydligt pekar på servosystemet, är det inte lämpligt att omedelbart byta ut servomotorn, servoförstärkaren, enkodern eller reduktorn. Dessa komponenter kan vara primära misstänkta vid andra Fanuc-larm, men för SRVO-408 är de inte det första man ska undersöka.
Detta är också anledningen till att man ofta ser fall på plats där "servoförstärkaren byttes ut men larmet kvarstår" – eftersom problemet aldrig fanns i förstärkaren från början, och det spelar ingen roll hur många man byter ut.
Vad du än gör – ta inte genvägen att kortsluta säkerhetssignalen
SRVO-408 är en larmrelaterad säkerhetsfunktion för roboten och bör inte hanteras som ett vanligt produktionslarm. Vissa personer på plats kanske tänker: "Varför inte kortsluta denna säkerhetssignal för tillfället och få igång roboten?" Detta tillvägagångssätt är extremt farligt.
Försök aldrig att tvinga roboten tillbaka i drift med metoder som dessa: kortsluta säkerhetsingången, tvinga säkerhetsutgången till PÅ, inaktivera DCS godtyckligt, kringgå säkerhets-PLC:n, ta bort säkerhetsdörrarnas interlock eller kringgå nödstoppkretsen. Dessa åtgärder kan direkt förstöra robotens avsedda säkerhetsfunktion. DCS finns särskilt för att minska risken för att roboten rör sig oväntat och orsakar skada. Om DCS utlöser ett larm är den korrekta åtgärden att ta reda på varför säkerhetsvillkoret inte uppfylls, inte att hitta ett sätt för systemet att "ignorera" detta villkor.
Om det verkligen blir nödvändigt att ändra DCS-konfigurationen måste detta också följa utrustningens ursprungliga säkerhetsdesign, riskbedömning och motsvarande säkerhetsstartprocess – det får inte göras på ett godtyckligt sätt.
Hur man undviker att det stör dig så ofta i daglig användning
SRVO-408 är inte något som du kan förhindra helt genom att byta ut en viss komponent. Det är kopplat till tillståndet hos hela robotsäkerhetssystemet, så regelbunden underhållsinspektion måste även omfatta säkerhetskretsen.
Till exempel bör nödstoppknapparna, säkerhetsdörrarna, säkerhetsreläerna, säkerhets-PLC:erna och den relaterade säkerhetsverkningen regelbundet inspekteras. Anslutningarna och säkerhets-I/O-verkningen inuti robotens kontrollskåp måste också förbli säkra, så att långvarig vibration inte orsakar dålig kontakt och intermittenta säkerhetsfel.
Om du har gjort ändringar i DCS-konfigurationen på en Fanuc-styrning är det bäst att hålla reda på ändringarna och ha en giltig säkerhetskopiering av styrningen. I synnerhet efter utbyte av styrningar, återställning av en säkerhetskopia eller omkonfigurering av robotarbetsplatsen måste du bekräfta att DCS-säkerhetskonfigurationen matchar den aktuella maskinen.
För robotar som varit i drift under en längre tid måste du också vara uppmärksam på åldrande säkerhetskablar. Långvarig vibration, fram- och tillbakarörelse inuti kabellådor, oljeföroreningar och frekvent böjning kan alla orsaka problem med kablar eller kontakter. Dessa problem utlöser inte omedelbart någon larm, men de kommer till slut att visa sig som instabila säkerhetsinmatningsstater och ibland ge DCS-larm som SRVO-408.
När ska du kalla in en specialist?
Om du redan har bekräftat att externa enheter, till exempel nödstoppknappen, säkerhetsdörrar och säkerhetsreläer, alla fungerar normalt, men SSO[3] fortfarande är AV, måste du granska DCS-konfigurationen och säkerhetssignalerna mer ingående.
I synnerhet om du stöter på någon av följande situationer är det lämpligt att involvera en ingenjör med erfarenhet av Fanuc DCS: robotstyrningen har precis bytts ut; en DCS- eller systembackup har precis återställts; säkerhets-PLC-programmet har nyligen ändrats; robotarbetsplatsen har precis omdesignats; konfigurationen av DCS Safe I/O Connect är oklar för dig; du vet inte vilken säkerhetsingång som styr SSO[3]; alla externa säkerhetsenheter fungerar normalt men SRVO-408 fortsätter att dyka upp trots detta; eller roboten har genererat en rad DCS-relaterade larm.
För säkerhetsfunktioner är det viktigaste inte "att få roboten igång igen så snabbt som möjligt" – utan att bekräfta att säkerhetssystemet verkligen har återgått till rätt tillstånd.
