Wenn einAdvantest Prüfmaschine V93000Kann keine Verbindung zum Testkopf hergestellt werden oder verliert dieser während des Betriebs die Verbindung, gehen Sie nicht automatisch von einem Defekt der Instrumentenkarte aus. Speichern Sie den ersten Fehler, prüfen Sie, ob die Steuerung weiterhin betriebsbereit war, und suchen Sie nach vorangegangenen Strom-, Kühlungs- oder Systemalarmen.
Eine Kommunikationsmeldung kennzeichnet eine fehlgeschlagene Interaktion. Sie benennt jedoch nicht zwangsläufig die Komponente, die den Fehler verursacht hat.
Die erste Aufgabe besteht darin, einen Verbindungsfehler beim Start von einem Verbindungsverlust nach erfolgreichem Betrieb zu unterscheiden.
Startfehler oder Verbindungsabbruch während des Betriebs?
Diese beiden Situationen liefern unterschiedliche Beweise.
| Situation | Was sollte man zuerst festlegen? |
|---|---|
| Der Testkopf ist nach dem Start nie verfügbar. | Ob die Controller-, Testkopf-Bereitschafts- und Initialisierungssequenz wie erforderlich abgeschlossen wurde |
| Die Verbindung bricht nach erfolgreicher Initialisierung ab. | Was hat sich unmittelbar vor der Unterbrechung verändert oder Anlass zur Sorge gegeben? |
| Ein Instrument schlägt bei der Initialisierung fehl, während der Messkopf weiterhin zugänglich ist. | Ob das Problem auf dieses Instrument oder seine Abhängigkeiten beschränkt ist |
| Die Geräteprüfung wird beendet, aber der Kopf bleibt verbunden. | Ob die Unterbrechung zum Programm, zur Schnittstelle oder zum Automatisierungsablauf gehört |
| Der Controller selbst friert ein oder startet neu. | Ob der Verlust des Hosts die offensichtliche Trennung des Testkopfes verursacht hat, ist unklar. |
Dokumentieren Sie den genauen Zeitpunkt, an dem der Betrieb abbricht. „Das Testgerät ist getrennt“ ist weniger hilfreich als „Die Steuerung reagierte weiterhin, aber der Testkopf war nach einem Kühlungsalarm nicht mehr verfügbar“.
In einem V93000HalbleitertesterEin Verbindungsfehler kann die Steuerung, den Kommunikationspfad oder die Testkopf-Infrastruktur betreffen. Identifizieren Sie die betroffene Verbindung, bevor Sie entscheiden, welche Komponente untersucht werden muss.
Bitte bestätigen Sie, welche Verbindung fehlgeschlagen ist.
Bevor Sie Kabel austauschen oder eine Ersatzplatine bestellen, identifizieren Sie die Endpunkte, die an dem Fehler beteiligt sind.
Die relevante Beziehung könnte folgende sein:
Die Steuereinheit kommuniziert mit dem Testkopf.
Das System initialisiert ein einzelnes Instrument.
Der Tester tauscht Signale mit einem Handler oder Wafer Prober aus.
Software, die einen Lizenzserver kontaktiert.
Eine entfernte Workstation, die auf den Tester-Controller zugreift.
Ein Handler-Timeout beweist nicht, dass die Verbindung zwischen Controller und Testkopf unterbrochen wurde. Ebenso wenig beweist der Verlust des Fernzugriffs auf den Controller, dass der interne Kommunikationspfad des Testers defekt ist.
Nutzen Sie die Originalnachricht und den Systemstatus, um die betroffene Beziehung zu identifizieren. Vermeiden Sie es, jede kommunikationsbezogene Nachricht als denselben Fehler zu behandeln.
Speichern Sie den ersten Fehler vor dem Neustart.
Ein Neustart kann den Betrieb vorübergehend wiederherstellen, entfernt dabei aber nützliche Informationen vom Bildschirm.
Falls sicher, aufbewahren:
Die vollständige erste Fehlermeldung und alle nachfolgenden Meldungen.
Relevante Controller- und Testerprotokolle.
Der Zeitpunkt der Unterbrechung.
Welche Anwendungen und Dienste weiterhin reagierten.
Status des Prüfkopfes und der Kühleinheit.
Ob alle Instrumente oder nur eine Ressource nicht mehr verfügbar waren.
Das Programm und die Betriebsphase waren zu diesem Zeitpunkt aktiv.
Kürzlich vorgenommene Änderungen an Software, Hardware oder Anlagen.
Achten Sie beim Vergleich von Protokollen verschiedener Systeme auf die Übereinstimmung der Zeitstempel. Die Uhr einer Steuerung und die Uhr eines Anlagenüberwachungssystems zeigen möglicherweise nicht dieselbe Zeit an.
Erfinden Sie keine eigene Fehlercode-Interpretation anhand einer ähnlichen Meldung einer anderen V93000-Generation. Behalten Sie den genauen Wortlaut bei, um ihn mit der entsprechenden Dokumentation abzugleichen.
Wenn der Testkopf beim Start keine Verbindung herstellt
Controller-Bereitschaft prüfen
Prüfen Sie, ob der Controller seinen normalen Startvorgang abgeschlossen hat und ob die erforderliche Softwareumgebung verfügbar ist.
Wenn der Controller nicht hochfährt, wiederholt neu startet oder nicht mehr reagiert, untersuchen Sie diesen Zustand, bevor Sie das Problem dem Testkopf zuschreiben.
Nach dem Austausch eines Controllers oder der Wiederherstellung eines Systemabbilds sollten Sie die unterstützte Betriebsumgebung und die wiederhergestellte Konfiguration überprüfen. Ein funktionierender Desktop beweist nicht, dass die Testumgebung korrekt wiederhergestellt wurde.
Vermeiden Sie die Neuinstallation von Software oder die Änderung von Konfigurationsdateien, bevor Sie den bestehenden Zustand und die Backups gesichert haben.
Überprüfung der Testkopfbereitschaft und früherer Alarme
Prüfen Sie die gemäß Betriebsablauf zulässigen Statusinformationen. Stellen Sie fest, ob die Initialisierung durch einen ungelösten Systemzustand verhindert wird.
Stromausfall, Kühlung oder andere Schutzmaßnahmen können die Einsatzbereitschaft beeinträchtigen und zu einem späteren Kommunikationsfehler führen. Untersuchen Sie das früheste relevante Ereignis und nicht nur die endgültige Nachricht.
Umgehen Sie keine Verriegelung und unterdrücken Sie keinen Schutzalarm, um die Initialisierung zu erzwingen.
Prüfen Sie den dokumentierten externen Kommunikationsweg
Ermitteln Sie den korrekten Kommunikationspfad für die installierte Steuerung und Testkopfkonfiguration. Kabeltypen, Steckverbinder und Infrastruktur variieren je nach Installation.
Befindet sich das System im vorgeschriebenen sicheren Zustand, können qualifizierte Fachkräfte die zugänglichen Anschlüsse auf Beschädigungen, Belastungen, unsichere Befestigung oder Veränderungen, die während der letzten Wartung vorgenommen wurden, überprüfen.
Gehen Sie nicht davon aus, dass ein gewöhnliches Netzwerkkabel ein geeigneter Ersatz ist. Trennen Sie ein Betriebssystem nicht testweise vom Stromnetz und berühren Sie optische Anschlüsse nicht ohne die vorgeschriebene Vorgehensweise.
Ein sichtbarer Verbindungsindikator ist, sofern vorhanden, eher ein unterstützender Hinweis als ein Beweis dafür, dass die gesamte erforderliche Kommunikation funktioniert.
Wenn die Verbindung während des Betriebs abbricht
Bei Laufzeitunterbrechungen ist die Ereignisabfolge besonders wichtig. Ermitteln Sie, was geschah, bevor die Kommunikation abbrach.
| Beobachtetes Muster | Ermittlungsrichtung | Was es nicht beweist |
|---|---|---|
| Die Trennung erfolgt nach einem Kühlungs- oder Stromalarm. | Überprüfen Sie die auslösende Alarm- und Schutzreaktion. | Dass die Kommunikationshardware defekt ist |
| Der Controller friert ein oder startet gleichzeitig neu. | Überprüfung der Controller- und Betriebssystemnachweise | Dass der Testkopf die Unterbrechung ausgelöst hat. |
| Fehler tritt nach Bewegung des Testkopfes auf | Prüfen Sie die zulässige externe Kabelführung, die Zugfestigkeit und die zugehörigen Anschlüsse. | Diese Bewegung hat den gescheiterten Teil eindeutig identifiziert. |
| Die Unterbrechung beginnt nach einer Software- oder Konfigurationsänderung | Vergleichen Sie mit der dokumentierten unterstützten Konfiguration. | Dass die Softwareänderung zwangsläufig die Ursache ist |
| Ein Gerät meldet Fehler, bevor es zu einem größeren Funktionsausfall kommt. | Überprüfen Sie den ursprünglichen Instrumentenfehler und die gemeinsamen Abhängigkeiten. | Dass das Instrument allein die Abschaltung verursacht hat |
| Fehler treten nur während eines bestimmten Programms auf. | Vergleich der Ressourcennutzung und der Betriebsbedingungen | Dass das Programm fehlerhaft ist oder die Hardware in Ordnung ist |
Diese Muster dienen als Grundlage für die Untersuchung. Sie ersetzen jedoch weder die Diagnose noch einen bestätigten Reparaturbefund.
Bedingungen vor einer lastbedingten Unterbrechung aufzeichnen
Wenn das Testgerät im Leerlauf verbunden bleibt, sich aber während der Geräteprüfung trennt, notieren Sie die aktive Konfiguration und die Betriebsbedingungen.
Stromversorgungs- und Kühlverhalten, Instrumentenaktivität, Controller-Ereignisse und Programmausführung können allesamt relevant sein. Ein Leerlauf-Verbindungstest bildet nicht alle im Produktionsbetrieb auftretenden Bedingungen ab.
Führen Sie einen mutmaßlich schädlichen Zustand nicht wiederholt aus, nur um den Fehler zu reproduzieren.
Behandeln Sie bewegungsbezogene Symptome als separaten Hinweis.
Wenn nach dem Andocken, Abdocken oder Umpositionieren Unterbrechungen auftreten, dokumentieren Sie die Beziehung, ohne den Kopf wiederholt zu bewegen, um einen Fehler zu provozieren.
Äußere Kabelbelastung oder eine durch Bewegung beeinträchtigte Verbindung können eine Untersuchung erforderlich machen. Die mechanische Position kann auch mit einer anderen Veränderung zusammenfallen, daher ist der Zeitpunkt allein keine Diagnosemöglichkeit.
Tauschen Sie PS1600 oder AVI64 nicht allein aufgrund einer Verbindungsabbruchmeldung aus.
Ein einzelner Gerätefehler und der Verlust der Testkopf-Kommunikation erfordern unterschiedliche Nachweise.
Wenn ein Messgerät einen Diagnosefehler meldet, während der Testkopf noch zugänglich ist, untersuchen Sie diese Ressource mithilfe des entsprechenden Verfahrens.
Wenn mehrere Geräte gleichzeitig ausfallen, überprüfen Sie die gemeinsam genutzte Infrastruktur, bevor Sie schlussfolgern, dass mehrere Karten gleichzeitig versagt haben.
Ein Austausch des Instruments sollte erst dann in Betracht gezogen werden, wenn die Untersuchung einen begründeten Hardwarebedarf festgestellt hat. Ein unkontrollierter Austausch kann Kompatibilitätsprobleme, Konfigurationsänderungen und zusätzlichen Kalibrierungsaufwand nach sich ziehen.
Sofern ein Austausch zulässig ist, verwenden Sie geprüfte, kompatible Hardware und ändern Sie jeweils nur eine Variable. Dokumentieren Sie die Identität des Original- und des Ersatzteils sowie die Ergebnisse des Vergleichs.
Was muss nach der Wiederherstellung überprüft werden?
Eine erfolgreiche Wiederverbindung ist ein erster Wiederherstellungserfolg. Sie bedeutet noch keine vollständige Produktionsaufnahme.
Befolgen Sie die entsprechenden Inbetriebnahme- und Nachwartungsverfahren und überprüfen Sie anschließend Folgendes:
Erwartete Hardwareerkennung.
Abschluss der erforderlichen Diagnostik.
Behebung der auslösenden Alarme.
Jegliche Kalibrierung, die aufgrund des Eingriffs erforderlich ist.
Stabiler Betrieb unter den entsprechenden Anwendungsbedingungen.
Korrekte Kommunikation mit dem Handler oder dem Prüfer, sofern zutreffend.
Bei einem intermittierenden Problem sollte der sinnvolle Prüfumfang anhand des Zeitpunkts des Fehlers definiert werden. Ein kurzer Starttest reicht nicht aus, um die Behebung einer Unterbrechung nachzuweisen, die zuvor nach längerem Betrieb aufgetreten war.
Sollte die Verbindung erneut abbrechen, sichern Sie die neuen Beweise und setzen Sie die Ermittlungen fort, anstatt sich auf wiederholte Neustarts zu verlassen.
Informationen, die für die Beurteilung einer Reparatur oder eines Austauschs benötigt werden
Vor dem Versand eines Controllers, einer Schnittstellenbaugruppe oder eines Instruments ist Folgendes bereitzustellen:
| Information | Zweck |
|---|---|
| V93000-Generation und Testkopfidentifizierung | Stellt den Hardwarekontext her |
| Controller-Modell und Softwareumgebung | Unterstützt die Konfigurationsprüfung |
| SmarTest-Veröffentlichung | Identifiziert den Kontext der installierten Software |
| Genaue erste Fehlermeldung und vollständige Protokolle | Behält die ursprüngliche Fehlersequenz bei. |
| Start- oder Laufzeitereignis | Trennt die Initialisierung vom intermittierenden Betrieb |
| Strom- und Kühlungsereignisse | Hilft dabei, eine vorgelagerte Unterbrechung zu identifizieren |
| Jüngste Änderungen | Definiert relevante Vergleiche |
| Verdächtige Komponentenetiketten | Unterstützt die präzise Teilezuordnung |
Entfernen Sie gegebenenfalls vertrauliche Geräte- und Programminformationen, während Sie die zur Untersuchung des Fehlers erforderlichen Diagnosedetails beibehalten.
Bei Auslandseinsätzen helfen diese Nachweise dabei, zu entscheiden, ob als nächster Schritt eine Überprüfung der lokalen Einrichtung, eine autorisierte Systeminspektion, eine Controller-Bewertung oder die Reparatur einer bestimmten Komponente erforderlich ist. Sie können auch das Risiko verringern, eine nicht zugehörige Baugruppe zu versenden.
Fordern Sie eine V93000-Verbindungsfehleranalyse an
Senden Sie die ursprüngliche Verbindungsfehlermeldung, die Systemkennung und eine kurze Zeitleiste des Ereignisses. Geben Sie an, ob der Testkopf nie eine Verbindung hergestellt hat, die Verbindung nach der Initialisierung getrennt wurde oder nach einem anderen Alarm nicht mehr verfügbar war.
Führen Sie die bereits durchgeführten Prüfungen sowie alle seit dem letzten erfolgreichen Betrieb vorgenommenen Hardware- oder Softwareänderungen auf.
