Når enAdvantest testmaskine V93000ikke kan oprette forbindelse til testhovedet eller mister forbindelsen under drift, må man ikke antage, at et instrumentkort er defekt. Bevar den første fejl, fastslå, om controlleren forblev funktionsdygtig, og kontroller for tidligere strøm-, køle- eller systemalarmer.
En kommunikationsbesked identificerer en mislykket interaktion. Den identificerer ikke nødvendigvis den komponent, der forårsagede den.
Den første opgave er at skelne mellem en opstartsforbindelsesfejl og en forbindelse, der mistes efter en vellykket operation.
Opstartsfejl eller afbrydelse ved kørsel?
Disse to situationer giver forskellige beviser.
| Situation | Hvad skal man etablere først |
|---|---|
| Testhovedet bliver aldrig tilgængeligt efter opstart | Om styreenheden, testhovedets parathed og initialiseringssekvensen er fuldført som krævet |
| Forbindelsen afbrydes efter vellykket initialisering | Hvad ændrede sig eller alarmerede umiddelbart før afbrydelsen |
| Et instrument mislykkes initialisering, mens hovedet forbliver tilgængeligt | Om problemet er begrænset til det pågældende instrument eller dets afhængigheder |
| Enhedstesten stopper, men hovedet forbliver tilsluttet | Om afbrydelsen tilhører programmet, grænsefladen eller automatiseringsflowet |
| Selve controlleren fryser eller genstarter | Om tab af værten forårsagede den tilsyneladende afbrydelse af testhovedet |
Registrer det præcise stadie, hvor driften stopper. "Testeren er afbrudt" er mindre nyttigt end "controlleren forblev responsiv, men testhovedet blev utilgængeligt efter en afkølingsalarm".
I en V93000halvledertester, en forbindelsesfejl kan involvere controlleren, kommunikationsstien eller testhovedinfrastrukturen. Identificer den berørte forbindelse, før du beslutter, hvilken komponent der skal undersøges.
Bekræft hvilken forbindelse der er mislykkedes
Før du skifter kabler eller bestiller et nyt printkort, skal du identificere de endepunkter, der er involveret i fejlen.
Det relevante forhold kan være:
Styringen kommunikerer med testhovedet.
Systemet initialiserer et individuelt instrument.
Testeren udveksler signaler med en handler eller waferprober.
Software kontakter en licensserver.
En fjernarbejdsstation, der tilgår testercontrolleren.
En timeout for en handler bekræfter ikke, at forbindelsen mellem controller og testhoved er mislykket. Tilsvarende beviser tab af fjernadgang til controlleren ikke, at testerens interne kommunikationssti er defekt.
Brug den oprindelige besked og systemstatus til at identificere den berørte relation. Undgå at behandle alle kommunikationsrelaterede beskeder som den samme fejl.
Gem den første fejl før genstart
En genstart kan muligvis midlertidigt gendanne driften, mens nyttig kontekst fjernes fra skærmen.
Hvis det er sikkert, behold:
Den komplette første fejl og efterfølgende meddelelser.
Relevante controller- og testlogfiler.
Tidspunktet for afbrydelsen.
Hvilke applikationer og tjenester forblev responsive.
Status for testhoved og køleenhed.
Om alle instrumenter eller kun én ressource blev utilgængelig.
Det program og den driftsfase, der er aktiv på det tidspunkt.
Nylige ændringer i software, hardware eller faciliteter.
Sørg for, at tidsstemplerne er justeret, når du sammenligner logfiler fra forskellige systemer. Et controllerur og et anlægsovervågningsur viser muligvis ikke det samme klokkeslæt.
Opfind ikke en fortolkning af fejlkoden ud fra en lignende meddelelse, der findes for en anden V93000-generation. Gem den nøjagtige ordlyd til gennemgang i forhold til den relevante dokumentation.
Hvis testhovedet ikke opretter forbindelse ved opstart
Kontroller controllerens klarhed
Fastslå, om controlleren har gennemført sin normale opstart, og om det nødvendige softwaremiljø er tilgængeligt.
Hvis controlleren ikke starter, genstarter gentagne gange eller ikke reagerer, skal du undersøge problemet, før du tilskriver problemet til testhovedet.
Efter udskiftning af controlleren eller gendannelse af systembilledet skal du gennemgå det understøttede operativsystemmiljø og den gendannede konfiguration. Et fungerende skrivebord beviser ikke, at testmiljøet er blevet gendannet korrekt.
Undgå at geninstallere software eller ændre konfigurationsfiler, før du bevarer den eksisterende tilstand og sikkerhedskopier.
Gennemgå testhovedets klarhed og tidligere alarmer
Kontroller statusoplysningerne, som er tilladt i henhold til driftsproceduren. Identificer, om initialisering forhindres af en uløst systemtilstand.
Strøm, køling eller andre beskyttelsesforhold kan afbryde beredskabet og forårsage en senere kommunikationsfejl. Undersøg den tidligst relevante hændelse i stedet for kun den endelige meddelelse.
Omgå ikke en interlock eller undertryk en beskyttelsesalarm for at fremtvinge initialisering.
Undersøg den dokumenterede eksterne kommunikationssti
Identificér den korrekte kommunikationssti for den installerede controller og testhovedkonfigurationen. Kabeltyper, stik og infrastruktur varierer på tværs af installationer.
Når systemet er i den foreskrevne sikre tilstand, kan kvalificeret personale inspicere tilgængelige forbindelser for skader, belastning, usikker fastholdelse eller ændringer foretaget under nylig service.
Gå ikke ud fra, at et almindeligt netværkskabel er en passende erstatning. Frakobl ikke et operativsystem eksperimentelt, og forstyr ikke optiske stik uden den angivne håndteringsprocedure.
En synlig linkindikation, hvor den er til stede, er understøttende bevis snarere end bevis for, at al nødvendig kommunikation fungerer.
Hvis forbindelsen afbrydes under drift
Ved afbrydelser under kørsel er hændelsessekvensen særlig vigtig. Bestem, hvad der skete, før kommunikationen blev afbrudt.
| Observeret mønster | Efterforskningsretning | Hvad det ikke beviser |
|---|---|---|
| Afbrydelse følger en køle- eller strømalarm | Gennemgå den udløsende alarm og beskyttelsesresponsen | At kommunikationshardwaren er defekt |
| Controlleren fryser eller genstarter samtidig | Gennemgå controller- og operativsystembeviser | At testlederen initierede afbrydelsen |
| Fejl følger testhovedets bevægelse | Inspicer tilladt ekstern kabelføring, belastning og tilhørende forbindelser | Den bevægelse har endegyldigt identificeret den fejlslagne del |
| Afbrydelsen begynder efter en software- eller konfigurationsændring | Sammenlign med den dokumenterede understøttede konfiguration | At softwareændringen nødvendigvis er den grundlæggende årsag |
| Et instrument rapporterer fejl før større driftstab | Gennemgå den oprindelige instrumentfejl og delte afhængigheder | At instrumentet alene forårsagede nedlukningen |
| Fejl opstår kun under et bestemt program | Sammenlign ressourceforbrug og driftsforhold | At programmet er defekt, eller at hardwaren er i orden |
Disse mønstre vejleder undersøgelsen. De erstatter ikke diagnostik eller et bekræftet reparationsfund.
Optag betingelser før en belastningsrelateret afbrydelse
Hvis testeren forbliver tilsluttet i inaktiv tilstand, men afbryder forbindelsen under enhedstest, skal du registrere den aktive konfiguration og driftsforholdene.
Strøm- og køleadfærd, instrumentaktivitet, controllerhændelser og programudførelse kan alle være relevante. En test af inaktiv forbindelse reproducerer ikke alle tilstande, der er til stede under produktionen.
Kør ikke en mistænkt skadelig tilstand gentagne gange blot for at reproducere fejlen.
Behandl bevægelsesrelaterede symptomer som en separat ledetråd
Hvis der opstår afbrydelser efter docking, fradocking eller repositionering, skal forholdet dokumenteres uden at bevæge hovedet gentagne gange for at fremkalde fejl.
Ekstern kabelbelastning eller en forbindelse påvirket af bevægelse kan berettige undersøgelse. Den mekaniske position kan også falde sammen med en anden ændring, så timing alene er ikke en diagnose.
Udskift ikke PS1600 eller AVI64 udelukkende baseret på en afbrydelsesmeddelelse
En individuel instrumentfejl og tab af kommunikation mellem testhoved og testhoved kræver forskellig dokumentation.
Hvis et instrument rapporterer en diagnostisk fejl, mens testhovedet stadig er tilgængeligt, skal ressourcen undersøges ved hjælp af den tilsvarende procedure.
Hvis flere instrumenter forsvinder samtidig, skal den delte infrastruktur gennemgås, før man konkluderer, at flere kort har fejlet samtidigt.
Et erstatningsinstrument bør kun overvejes, når undersøgelsen har identificeret et berettiget hardwarekrav. Ukontrolleret udskiftning kan medføre kompatibilitetsspørgsmål, konfigurationsændringer og yderligere kalibreringskrav.
Hvor substitution er tilladt, skal verificeret kompatibel hardware anvendes, og én variabel skal ændres ad gangen. Registrer den oprindelige og erstatningsidentiteten samt resultaterne af sammenligningen.
Hvad skal verificeres efter gendannelse?
En vellykket genoprettelse er et indledende resultat af genoprettelsen. Det er ikke en fuldstændig produktionsaccept.
Følg de gældende opstarts- og efterserviceprocedurer, og verificer derefter:
Forventet hardwaregenkendelse.
Færdiggørelse af nødvendig diagnostik.
Løsning af de udløste alarmer.
Enhver kalibrering, der kræves af interventionen.
Stabil drift under de relevante anvendelsesforhold.
Korrekt kommunikation med behandleren eller undersøgeren, hvor det er relevant.
For et periodisk problem skal du definere et meningsfuldt verifikationsomfang baseret på, hvornår fejlen opstod. En kort opstartstest er ikke tilstrækkelig til at demonstrere løsning af en afbrydelse, der tidligere har været opstået efter længerevarende drift.
Hvis forbindelsen afbrydes igen, skal du gemme de nye beviser og fortsætte efterforskningen i stedet for at stole på gentagne nulstillinger.
Oplysninger nødvendige til vurdering af reparation eller udskiftning
Før du sender en controller, interfaceenhed eller instrument, skal du sørge for:
| Information | Formål |
|---|---|
| V93000-generering og identifikation af testhoved | Etablerer hardwarekonteksten |
| Controllermodel og softwaremiljø | Understøtter konfigurationsgennemgang |
| SmarTest-udgivelse | Identificerer den installerede softwarekontekst |
| Præcis første fejl og fulde logfiler | Bevarer den oprindelige fejlsekvens |
| Opstarts- eller kørselsforekomst | Adskiller initialisering fra intermitterende drift |
| Strøm- og kølehændelser | Hjælper med at identificere en opstrøms afbrydelse |
| Seneste ændringer | Definerer relevante sammenligninger |
| Mærkater for mistænkte komponenter | Understøtter præcis delmatchning |
Fjern fortrolige oplysninger om enhedsprogrammer, hvor det er nødvendigt, samtidig med at du bevarer de diagnostiske detaljer, der er nødvendige for at undersøge fejlen.
For service i udlandet hjælper denne dokumentation med at afgøre, om det næste skridt skal være et lokalt anlægstjek, en autoriseret systeminspektion, en vurdering af styreenheden eller en specifik komponentreparation. Det kan også reducere risikoen for at sende en uafhængig samling.
Anmod om en V93000-forbindelsesfejlvurdering
Send den oprindelige forbindelsesfejl, systemidentifikation og en kort tidslinje for hændelsen. Angiv, om testhovedet aldrig blev forbundet, afbrudt efter initialisering eller blev utilgængeligt efter en anden alarm.
Inkluder de kontroller, der allerede er udført, og eventuelle hardware- eller softwareændringer, der er foretaget siden den sidste vellykkede operation.
