Când unMașină de testare Advantest V93000Dacă controlerul nu se poate conecta la capul său de testare sau pierde conexiunea în timpul funcționării, nu presupuneți că o placă de instrument s-a defectat. Păstrați prima eroare, stabiliți dacă controlerul a rămas operațional și verificați dacă există alarme anterioare de alimentare, răcire sau sistem.
Un mesaj de comunicare identifică o interacțiune eșuată. Nu identifică neapărat componenta care a cauzat-o.
Prima sarcină este de a distinge o eroare de conexiune la pornire de o conexiune pierdută după o operațiune reușită.
Eroare la pornire sau deconectare la runtime?
Aceste două situații oferă dovezi diferite.
| Situaţie | Ce să stabilim mai întâi |
|---|---|
| Capul de testare nu devine niciodată disponibil după pornire | Dacă controlerul, pregătirea capului de testare și secvența de inițializare au fost finalizate conform cerințelor |
| Conexiunea se întrerupe după o inițializare reușită | Ce s-a schimbat sau a cauzat alarma imediat înainte de întrerupere |
| Un instrument eșuează la inițializare în timp ce capul rămâne accesibil | Dacă problema este limitată la acel instrument sau la dependențele sale |
| Testarea dispozitivului se oprește, dar capul rămâne conectat | Dacă întreruperea aparține programului, interfeței sau fluxului de automatizare |
| Controlerul în sine se blochează sau repornește | Dacă pierderea gazdei a cauzat aparenta deconectare a capului de testare |
Înregistrați etapa precisă în care funcționarea se oprește. „Testerul este deconectat” este mai puțin util decât „controlerul a rămas receptiv, dar capul de testare a devenit indisponibil după o alarmă de răcire”.
Într-un V93000tester de semiconductori, o eroare de conexiune poate implica controlerul, calea de comunicație sau infrastructura capului de testare. Identificați conexiunea afectată înainte de a decide ce componentă necesită investigare.
Confirmați care conexiune a eșuat
Înainte de a schimba cablurile sau de a comanda o placă de schimb, identificați punctele finale implicate în eroare.
Relația relevantă poate fi:
Controlerul comunică cu capul de testare.
Sistemul inițializează un instrument individual.
Testerul schimbă semnale cu un handler sau un sonder de plachete.
Software-ul contactează un server de licențe.
O stație de lucru la distanță care accesează controlerul testerului.
O expirare a handlerului nu stabilește că conexiunea dintre controler și capul de testare a eșuat. În mod similar, pierderea accesului de la distanță la controler nu dovedește că este defectă calea de comunicare internă a testerului.
Folosește mesajul original și starea sistemului pentru a identifica relația afectată. Evită să tratezi fiecare mesaj legat de comunicare ca fiind aceeași eroare.
Salvați prima eroare înainte de a reporni
O repornire poate restabili temporar funcționarea, eliminând în același timp contextul util de pe ecran.
Dacă este sigur, păstrați:
Prima eroare completă și mesajele ulterioare.
Jurnale relevante ale controlerului și testerului.
Momentul întreruperii.
Ce aplicații și servicii au rămas receptive.
Starea capului de testare și a unității de răcire.
Dacă toate instrumentele sau doar o resursă au devenit indisponibile.
Programul și etapa de operare active la momentul respectiv.
Modificări recente ale software-ului, hardware-ului sau instalațiilor.
Păstrați marcajele temporale aliniate atunci când comparați jurnalele din sisteme diferite. Este posibil ca un ceas al controlerului și un ceas de monitorizare a instalației să nu afișeze aceeași oră.
Nu inventați o interpretare a codului de eroare dintr-un mesaj similar găsit pentru o altă generație V93000. Păstrați formularea exactă pentru a o verifica în documentația aplicabilă.
Dacă capul de testare nu se conectează la pornire
Verificați disponibilitatea controlerului
Stabiliți dacă controlerul a finalizat pornirea normală și dacă este disponibil mediul software necesar.
Dacă controlerul nu pornește, repornește în mod repetat sau nu răspunde, investigați această situație înainte de a atribui problema capului de testare.
După înlocuirea unui controler sau restaurarea imaginii de sistem, verificați mediul de operare acceptat și configurația restaurată. Un desktop funcțional nu dovedește că mediul de testare a fost restaurat corect.
Evitați reinstalarea software-ului sau modificarea fișierelor de configurare înainte de a păstra starea existentă și copiile de rezervă.
Verificarea disponibilității capului de testare și a alarmelor anterioare
Verificați informațiile de stare permise de procedura de operare. Identificați dacă inițializarea este împiedicată de o condiție de sistem nerezolvată.
Condițiile de alimentare, răcire sau alte condiții de protecție pot întrerupe disponibilitatea și pot produce o eroare de comunicare ulterioară. Investigați cel mai timpuriu eveniment relevant, nu doar mesajul final.
Nu ocoliți o interblocare și nu suprimați o alarmă de protecție pentru a forța inițializarea.
Inspectați calea de comunicare externă documentată
Identificați calea de comunicare corectă pentru configurația controlerului instalat și a capului de testare. Tipurile de cabluri, conectorii și infrastructura diferă în funcție de instalație.
Cu sistemul în starea de siguranță prescrisă, personalul calificat poate inspecta conexiunile accesibile pentru a depista eventuale deteriorări, tensionări, fixări nesigure sau modificări efectuate în timpul service-ului recent.
Nu presupuneți că un cablu de rețea obișnuit este un înlocuitor potrivit. Nu deconectați experimental un sistem de operare și nu deranjați conectorii optici fără procedura de manipulare specificată.
O indicație vizibilă a legăturii, acolo unde este prezentă, reprezintă o dovadă justificativă, mai degrabă decât o dovadă că toate comunicările necesare funcționează.
Dacă conexiunea se întrerupe în timpul funcționării
Pentru întreruperile în timpul execuției, secvența evenimentelor este deosebit de importantă. Determinați ce s-a întâmplat înainte de pierderea comunicării.
| Model observat | Direcția investigației | Ceea ce nu dovedește |
|---|---|---|
| Deconectarea urmează unei alarme de răcire sau de alimentare | Revizuirea alarmei de declanșare și a răspunsului de protecție | Că hardware-ul de comunicații este defect |
| Controlerul se blochează sau repornește în același timp | Revizuirea dovezilor controlerului și sistemului de operare | Că întreruperea a fost inițiată de către responsabilul de testare |
| Eșecul urmează mișcării capului de testare | Verificați traseul extern permis al cablurilor, tensiunea și conexiunile asociate | Această mișcare a identificat în mod concludent partea eșuată |
| Întreruperea începe după o modificare de software sau de configurație | Comparați cu configurația acceptată documentată | Că schimbarea software-ului este în mod necesar cauza principală |
| Un instrument raportează erori înainte de o pierdere mai mare de funcționare | Revizuirea erorii instrumentului original și a dependențelor partajate | Că instrumentul singur a cauzat oprirea |
| Eșecurile apar doar în timpul unui anumit program | Comparați utilizarea resurselor și condițiile de operare | Că programul este defect sau că hardware-ul este funcțional |
Aceste modele ghidează investigația. Nu înlocuiesc diagnosticarea sau confirmarea unei constatări de reparare.
Înregistrarea condițiilor înainte de o întrerupere legată de sarcină
Dacă testerul rămâne conectat în timp ce este inactiv, dar se deconectează în timpul testării dispozitivului, înregistrați configurația activă și condițiile de funcționare.
Comportamentul la alimentare și răcire, activitatea instrumentului, evenimentele controlerului și execuția programului pot fi toate relevante. Un test de conexiune în inactivitate nu reproduce fiecare condiție prezentă în timpul producției.
Nu rulați în mod repetat o condiție suspectată de deteriorare doar pentru a reproduce defectul.
Tratați simptomele legate de mișcare ca pe un indiciu separat
Dacă apar întreruperi după andocare, dezandocare sau repoziționare, documentați relația fără a mișca în mod repetat capul pentru a provoca o defecțiune.
Tensiunea externă a cablului sau o conexiune afectată de mișcare pot necesita investigații. Poziția mecanică poate coincide și cu o altă modificare, așadar sincronizarea în sine nu constituie un diagnostic.
Nu înlocuiți PS1600 sau AVI64 doar pe baza unui mesaj de deconectare
O defecțiune individuală a instrumentului și pierderea comunicării cu capul de testare necesită dovezi diferite.
Dacă un instrument raportează o eroare de diagnosticare în timp ce capul de testare rămâne accesibil, investigați acea resursă utilizând procedura corespunzătoare.
Dacă mai multe instrumente dispar împreună, verificați infrastructura comună înainte de a concluziona că mai multe carduri au defectat simultan.
O înlocuire a instrumentului ar trebui luată în considerare numai după ce investigația identifică o cerință hardware justificată. Înlocuirea necontrolată poate introduce întrebări de compatibilitate, modificări de configurație și cerințe suplimentare de calibrare.
Acolo unde este autorizată substituirea, utilizați hardware compatibil verificat și schimbați câte o variabilă pe rând. Înregistrați identitatea originală și cea de înlocuire, precum și rezultatele comparației.
Ce trebuie verificat după recuperare?
O reconectare reușită este un rezultat inițial al recuperării. Nu este o acceptare completă a producției.
Urmați procedurile aplicabile de pornire și post-service, apoi verificați:
Recunoaștere hardware așteptată.
Finalizarea diagnosticelor necesare.
Rezolvarea alarmelor declanșatoare.
Orice calibrare necesară pentru intervenție.
Funcționare stabilă în condițiile de aplicație relevante.
Comunicare corectă cu manipulantul sau cu persoana care efectuează proba, acolo unde este cazul.
Pentru o problemă intermitentă, definiți un domeniu de verificare semnificativ, bazat pe momentul în care a apărut defecțiunea. Un test de pornire scurt este insuficient pentru a demonstra rezolvarea unei întreruperi care a apărut anterior după o funcționare prelungită.
Dacă conexiunea se întrerupe din nou, păstrați noile dovezi și continuați investigația, în loc să vă bazați pe resetări repetate.
Informații necesare pentru evaluarea reparației sau înlocuirii
Înainte de a expedia un controler, un ansamblu de interfață sau un instrument, furnizați:
| Informaţii | Scop |
|---|---|
| Generarea V93000 și identificarea capului de testare | Stabilește contextul hardware |
| Modelul controlerului și mediul software | Suportă revizuirea configurației |
| Lansarea SmarTest | Identifică contextul software-ului instalat |
| Prima eroare exactă și jurnale complete | Păstrează secvența originală de defecțiuni |
| Apariție la pornire sau la execuție | Separă inițializarea de funcționarea intermitentă |
| Evenimente de alimentare și răcire | Ajută la identificarea unei întreruperi în amonte |
| Modificări recente | Definește comparațiile relevante |
| Etichete ale componentelor suspecte | Suportă potrivirea precisă a pieselor |
Eliminați informațiile confidențiale despre programul dispozitivului, acolo unde este necesar, păstrând în același timp detaliile de diagnosticare necesare pentru investigarea defecțiunii.
Pentru service-ul în străinătate, aceste dovezi ajută la determinarea dacă următorul pas ar trebui să fie o verificare la un centru local, o inspecție autorizată a sistemului, o evaluare a controlerului sau repararea unei componente specifice. De asemenea, poate reduce riscul de a expedia un ansamblu fără legătură.
Solicitați o evaluare a erorilor de conexiune V93000
Trimiteți eroarea de conectare inițială, identificarea sistemului și o scurtă cronologie a evenimentului. Indicați dacă capul de testare nu s-a conectat niciodată, s-a deconectat după inițializare sau a devenit indisponibil în urma unei alte alarme.
Includeți verificările deja efectuate și orice modificări hardware sau software efectuate de la ultima operațiune reușită.
