När enAdvantest testmaskin V93000inte kan ansluta till testhuvudet eller förlorar anslutningen under drift, anta inte att ett instrumentkort har gått sönder. Spara det första felet, fastställ om styrenheten förblev funktionsduglig och kontrollera föregående ström-, kyl- eller systemlarm.
Ett kommunikationsmeddelande identifierar en misslyckad interaktion. Det identifierar inte nödvändigtvis den komponent som orsakade den.
Den första uppgiften är att skilja mellan ett anslutningsfel vid start och en anslutning som förlorats efter en lyckad operation.
Startfel eller frånkoppling vid körning?
Dessa två situationer ger olika bevis.
| Situation | Vad man ska etablera först |
|---|---|
| Testhuvudet blir aldrig tillgängligt efter uppstart | Huruvida styrenheten, testhuvudets beredskap och initialiseringssekvensen slutfördes enligt kraven |
| Anslutningen bryts efter lyckad initialisering | Vad som förändrades eller orsakade oron omedelbart före avbrottet |
| Ett instrument misslyckas med initialiseringen medan huvudet fortfarande är tillgängligt | Om problemet är begränsat till det instrumentet eller dess beroenden |
| Enhetstestningen avbryts men huvudet förblir anslutet | Om avbrottet tillhör programmet, gränssnittet eller automatiseringsflödet |
| Själva kontrollenheten fryser eller startar om | Huruvida förlusten av värden orsakade den uppenbara frånkopplingen av testhuvudet |
Registrera det exakta skedet då driften avbryts. ”Provaret är frånkopplat” är mindre användbart än ”styrenheten fortsatte att svara, men testhuvudet blev otillgängligt efter ett kylningslarm”.
I en V93000halvledartestare, ett anslutningsfel kan involvera styrenheten, kommunikationsvägen eller testhuvudets infrastruktur. Identifiera den berörda anslutningen innan du bestämmer vilken komponent som behöver undersökas.
Bekräfta vilken anslutning som har misslyckats
Innan du byter kablar eller beställer ett ersättningskort, identifiera de slutpunkter som är involverade i felet.
Det relevanta förhållandet kan vara:
Styrenheten kommunicerar med testhuvudet.
Systemet initierar ett enskilt instrument.
Testaren utbyter signaler med en hanterare eller waferprober.
Programvara kontaktar en licensserver.
En fjärrarbetsstation som har åtkomst till testarens styrenhet.
En timeout för hanteraren bekräftar inte att anslutningen mellan styrenheten och testenheten har misslyckats. På samma sätt bevisar inte förlust av fjärråtkomst till styrenheten att testarens interna kommunikationsväg är defekt.
Använd det ursprungliga meddelandet och systemstatusen för att identifiera den berörda relationen. Undvik att behandla alla kommunikationsrelaterade meddelanden som samma fel.
Spara det första felet innan omstart
En omstart kan återställa driften tillfälligt samtidigt som användbar kontext tas bort från skärmen.
Om det är säkert, bevara:
Det fullständiga första felet och efterföljande meddelanden.
Relevanta loggar för kontrollanter och testare.
Tidpunkten för avbrottet.
Vilka applikationer och tjänster förblev responsiva.
Testhuvud och kylenhets status.
Om alla instrument eller bara en resurs blev otillgänglig.
Det program och den operativa fasen som var aktiv för tillfället.
Nyligen genomförda ändringar i programvara, hårdvara eller anläggning.
Håll tidsstämplarna i linje när du jämför loggar från olika system. En styrenhetsklocka och en anläggningsövervakningsklocka kanske inte visar samma tid.
Hitta inte på en felkodstolkning utifrån ett liknande meddelande som hittats för en annan V93000-generation. Spara den exakta formuleringen för granskning mot tillämplig dokumentation.
Om testhuvudet inte ansluts vid uppstart
Kontrollera att styrenheten är redo
Fastställ om styrenheten har slutfört sin normala start och om den nödvändiga programvarumiljön är tillgänglig.
Om styrenheten inte startar, startar om upprepade gånger eller slutar svara, undersök det tillståndet innan du tillskriver problemet till testhuvudet.
Efter ett byte av styrenhet eller återställning av systemavbildningen, granska den operativa miljön som stöds och den återställda konfigurationen. Ett fungerande skrivbord bevisar inte att testmiljön har återställts korrekt.
Undvik att installera om programvara eller ändra konfigurationsfiler innan du bevarar befintligt tillstånd och säkerhetskopior.
Granska testhuvudets beredskap och tidigare larm
Kontrollera statusinformationen som tillåts enligt driftsproceduren. Identifiera om initialiseringen förhindras av ett olöst systemproblem.
Strömförsörjning, kylning eller andra skyddsförhållanden kan avbryta beredskapen och orsaka ett senare kommunikationsfel. Undersök den tidigaste relevanta händelsen snarare än bara det slutliga meddelandet.
Kringgå inte en förregling eller undertryck ett skyddslarm för att tvinga fram initialisering.
Kontrollera den dokumenterade externa kommunikationsvägen
Identifiera rätt kommunikationsväg för den installerade styrenheten och testhuvudkonfigurationen. Kabeltyper, kontakter och infrastruktur skiljer sig åt mellan installationer.
När systemet är i föreskrivet säkert tillstånd kan kvalificerad personal inspektera tillgängliga anslutningar för skador, spänningar, osäker fastsättning eller ändringar som gjorts under den senaste servicen.
Anta inte att en vanlig nätverkskabel är en lämplig ersättning. Koppla inte ur ett operativsystem experimentellt och rör inte vid optiska kontakter utan att följa anvisningarna.
En synlig länkindikation, där sådan finns, är ett stödjande bevis snarare än ett bevis på att all nödvändig kommunikation fungerar.
Om anslutningen bryts under drift
Vid avbrott under körning är händelsesekvensen särskilt viktig. Bestäm vad som hände innan kommunikationen bröts.
| Observerat mönster | Utredningens riktning | Vad det inte bevisar |
|---|---|---|
| Frånkoppling efter ett kylnings- eller strömlarm | Granska det utlösande larmet och skyddsåtgärden | Att kommunikationshårdvaran är defekt |
| Styrenheten fryser eller startar om samtidigt | Granska bevis för styrenheter och operativsystem | Att testledaren initierade avbrottet |
| Fel följer testhuvudets rörelse | Kontrollera tillåten extern kabeldragning, belastning och tillhörande anslutningar | Den rörelsen har slutgiltigt identifierat den misslyckade delen |
| Avbrottet börjar efter en program- eller konfigurationsändring | Jämför med den dokumenterade konfigurationen som stöds | Att programvaruförändringen nödvändigtvis är grundorsaken |
| Ett instrument rapporterar fel innan större funktionsbortfall | Granska det ursprungliga instrumentfelet och delade beroenden | Att instrumentet ensamt orsakade avstängningen |
| Fel uppstår endast under ett visst program | Jämför resursanvändning och driftsförhållanden | Att programmet är felaktigt eller att hårdvaran är felfri |
Dessa mönster vägleder undersökningen. De ersätter inte diagnostik eller ett bekräftat reparationsfynd.
Registrera villkor före ett lastrelaterat avbrott
Om testaren förblir ansluten i viloläge men kopplas bort under enhetstestning, registrera den aktiva konfigurationen och driftsförhållandena.
Ström- och kylfunktion, instrumentaktivitet, styrenhetshändelser och programkörning kan alla vara relevanta. Ett test av vilolägesanslutning reproducerar inte alla tillstånd som finns under produktionen.
Kör inte ett misstänkt fel upprepade gånger bara för att reproducera felet.
Behandla rörelserelaterade symtom som en separat ledtråd
Om avbrott uppstår efter dockning, lossning eller ompositionering, dokumentera förhållandet utan att upprepade gånger röra huvudet för att framkalla fel.
Extern kabelspänning eller en förbindelse som påverkas av rörelse kan motivera undersökning. Det mekaniska läget kan också sammanfalla med en annan förändring, så enbart tidpunkten är inte en diagnos.
Ersätt inte PS1600 eller AVI64 enbart baserat på ett frånkopplingsmeddelande
Ett enskilt instrumentfel och kommunikationsförlust mellan testhuvudet kräver olika bevis.
Om ett instrument rapporterar ett diagnostiskt fel medan testhuvudet fortfarande är tillgängligt, undersök resursen med hjälp av motsvarande procedur.
Om flera instrument försvinner samtidigt, granska den delade infrastrukturen innan du drar slutsatsen att flera kort har slutat fungera samtidigt.
Ett ersättningsinstrument bör endast övervägas efter att undersökningen identifierat ett motiverat hårdvarukrav. Okontrollerad utbyte kan medföra kompatibilitetsfrågor, konfigurationsändringar och ytterligare kalibreringskrav.
Där substitution är tillåten, använd verifierad kompatibel hårdvara och ändra en variabel i taget. Registrera original- och ersättningsidentiteterna samt resultaten av jämförelsen.
Vad måste verifieras efter återställning?
En lyckad återanslutning är ett initialt återställningsresultat. Det är inte ett fullständigt produktionsgodkännande.
Följ gällande start- och efterserviceprocedurer och verifiera sedan:
Förväntad hårdvaruigenkänning.
Slutförande av nödvändig diagnostik.
Lösning av de utlösande larmen.
Eventuell kalibrering som krävs av interventionen.
Stabil drift under relevanta tillämpningsförhållanden.
Korrekt kommunikation med hanteraren eller utredaren, där så är tillämpligt.
För ett intermittent problem, definiera ett meningsfullt verifieringsomfång baserat på när felet inträffade. Ett kort starttest är otillräckligt för att visa lösningen på ett avbrott som tidigare inträffat efter längre tids drift.
Om anslutningen bryts igen, bevara de nya bevisen och fortsätt utredningen istället för att förlita sig på upprepade återställningar.
Information som behövs för bedömning av reparation eller utbyte
Innan du skickar en styrenhet, gränssnittsenhet eller instrument, tillhandahåll:
| Information | Ändamål |
|---|---|
| V93000-generering och identifiering av testhuvud | Etablerar hårdvarukontexten |
| Styrenhetsmodell och programvarumiljö | Stöder konfigurationsgranskning |
| SmarTest-version | Identifierar den installerade programvarukontexten |
| Exakt första fel och fullständiga loggar | Bevarar den ursprungliga felsekvensen |
| Start- eller körningsförekomst | Separerar initialisering från intermittent drift |
| Kraft- och kylningshändelser | Hjälper till att identifiera ett avbrott uppströms |
| Senaste ändringarna | Definierar relevanta jämförelser |
| Etiketter för misstänkta komponenter | Stöder noggrann delmatchning |
Ta bort konfidentiell information om enhetsprogram vid behov, samtidigt som du behåller de diagnostiska detaljer som behövs för att undersöka felet.
För utlandstjänster hjälper dessa bevis till att avgöra om nästa steg ska vara en lokal anläggningskontroll, en auktoriserad systeminspektion, en kontrollbedömning eller en specifik komponentreparation. Det kan också minska risken för att skicka en orelaterad montering.
Begär en V93000-anslutningsfelsbedömning
Skicka det ursprungliga anslutningsfelet, systemidentifiering och en kort tidslinje för händelsen. Ange om testhuvudet aldrig anslöts, kopplades bort efter initialisering eller blev otillgängligt efter ett annat larm.
Inkludera de kontroller som redan har utförts och eventuella hårdvaru- eller mjukvaruändringar som gjorts sedan den senaste lyckade operationen.
