KiedyMaszyna testowa Advantest V93000Jeśli nie można połączyć się z głowicą testową lub połączenie zostaje utracone podczas pracy, nie należy zakładać awarii karty urządzenia. Zachowaj pierwszy błąd, sprawdź, czy kontroler nadal działał i sprawdź, czy nie wystąpiły wcześniejsze alarmy zasilania, chłodzenia lub systemu.
Komunikat komunikacyjny identyfikuje nieudaną interakcję. Niekoniecznie identyfikuje komponent, który ją spowodował.
Pierwszym zadaniem jest odróżnienie niepowodzenia połączenia początkowego od połączenia utraconego po pomyślnym zakończeniu operacji.
Błąd uruchamiania czy rozłączenie w czasie wykonywania?
Te dwie sytuacje dostarczają różnych dowodów.
| Sytuacja | Co ustalić w pierwszej kolejności |
|---|---|
| Głowica testowa nigdy nie staje się dostępna po uruchomieniu | Czy kontroler, gotowość głowicy testowej i sekwencja inicjalizacji zostały ukończone zgodnie z wymaganiami |
| Połączenie zostaje zerwane po pomyślnej inicjalizacji | Co uległo zmianie lub wywołało alarm bezpośrednio przed przerwaniem |
| Jeden z instrumentów nie został zainicjowany, podczas gdy głowica pozostaje dostępna | Czy problem ogranicza się do danego instrumentu czy jego zależności |
| Testowanie urządzenia zostaje zatrzymane, ale głowica pozostaje podłączona | Czy przerwanie dotyczy programu, interfejsu czy przepływu automatyzacji |
| Sam kontroler zawiesza się lub uruchamia ponownie | Czy utrata hosta spowodowała widoczne odłączenie głowicy testowej |
Zanotuj dokładny etap, na którym operacja się zatrzymuje. „Tester jest odłączony” jest mniej użyteczne niż „kontroler nadal reagował, ale głowica testowa stała się niedostępna po alarmie chłodzenia”.
W V93000tester półprzewodnikówAwaria połączenia może dotyczyć kontrolera, ścieżki komunikacyjnej lub infrastruktury testowej. Zidentyfikuj problematyczne połączenie przed podjęciem decyzji, który komponent wymaga zbadania.
Potwierdź, które połączenie się nie powiodło
Przed wymianą kabli lub zamówieniem nowej płytki należy zidentyfikować punkty końcowe, których dotyczy błąd.
Odpowiedni związek może być następujący:
Kontroler komunikujący się z głowicą testową.
System inicjujący pojedynczy instrument.
Tester wymienia sygnały z urządzeniem obsługującym lub próbnikiem płytek.
Oprogramowanie nawiązujące kontakt z serwerem licencji.
Zdalna stacja robocza uzyskująca dostęp do kontrolera testera.
Przekroczenie limitu czasu obsługi nie oznacza, że połączenie między kontrolerem a głowicą testową zostało zerwane. Podobnie, utrata zdalnego dostępu do kontrolera nie dowodzi, że wewnętrzna ścieżka komunikacyjna testera jest uszkodzona.
Użyj oryginalnej wiadomości i statusu systemu, aby zidentyfikować problematyczną relację. Unikaj traktowania każdej wiadomości związanej z komunikacją jako tego samego błędu.
Zapisz pierwszy błąd przed ponownym uruchomieniem
Ponowne uruchomienie może tymczasowo przywrócić działanie urządzenia, usuwając jednocześnie przydatny kontekst z ekranu.
Jeśli to bezpieczne, zachowaj:
Pełny pierwszy błąd i kolejne komunikaty.
Odpowiednie dzienniki kontrolerów i testerów.
Czas przerwania.
Które aplikacje i usługi pozostały responsywne.
Stan głowicy testowej i układu chłodzącego.
Czy niedostępne stały się wszystkie instrumenty czy tylko jeden zasób.
Program i etap operacyjny aktywny w tym czasie.
Ostatnie zmiany oprogramowania, sprzętu lub obiektów.
Porównując dzienniki z różnych systemów, należy zachować spójność znaczników czasu. Zegar kontrolera i zegar monitorujący obiekt mogą nie pokazywać tego samego czasu.
Nie należy tworzyć interpretacji kodu błędu na podstawie podobnego komunikatu znalezionego dla innej generacji V93000. Należy zachować dokładne brzmienie do wglądu w odpowiedniej dokumentacji.
Jeśli głowica testowa nie łączy się podczas uruchamiania
Sprawdź gotowość kontrolera
Sprawdź, czy kontroler zakończył normalny rozruch i czy wymagane środowisko programowe jest dostępne.
Jeśli kontroler nie uruchamia się, wielokrotnie restartuje się lub przestaje reagować, należy zbadać przyczynę, zanim przypisze się problem do głowicy testowej.
Po wymianie kontrolera lub przywróceniu obrazu systemu należy sprawdzić obsługiwane środowisko operacyjne i przywróconą konfigurację. Działający pulpit nie jest dowodem na to, że środowisko testowe zostało poprawnie przywrócone.
Unikaj ponownej instalacji oprogramowania lub zmiany plików konfiguracyjnych przed zachowaniem obecnego stanu i kopii zapasowych.
Przejrzyj gotowość głowicy testowej i wcześniejsze alarmy
Sprawdź informacje o stanie dozwolone przez procedurę operacyjną. Sprawdź, czy inicjalizacja jest blokowana przez nierozwiązany problem systemowy.
Zasilanie, chłodzenie lub inne czynniki bezpieczeństwa mogą przerwać gotowość i spowodować późniejszy błąd komunikacji. Zbadaj najwcześniejsze istotne zdarzenie, a nie tylko ostatnią wiadomość.
Nie należy omijać blokady ani wyłączać alarmu ochronnego w celu wymuszenia inicjalizacji.
Sprawdź udokumentowaną ścieżkę komunikacji zewnętrznej
Określ prawidłową ścieżkę komunikacji dla zainstalowanego kontrolera i konfiguracji głowicy testowej. Typy kabli, złącza i infrastruktura różnią się w zależności od instalacji.
Gdy system znajduje się w odpowiednim, bezpiecznym stanie, wykwalifikowany personel może dokonać kontroli dostępnych połączeń pod kątem uszkodzeń, naprężeń, niepewnego zamocowania lub zmian wprowadzonych podczas ostatniego serwisu.
Nie zakładaj, że zwykły kabel sieciowy jest odpowiednim zamiennikiem. Nie odłączaj systemu operacyjnego eksperymentalnie ani nie naruszaj złączy optycznych bez zachowania zalecanej procedury.
Widoczne wskazanie połączenia, o ile występuje, stanowi raczej dowód niż potwierdzenie, że cała wymagana komunikacja funkcjonuje prawidłowo.
Jeżeli połączenie zostanie zerwane podczas pracy
W przypadku przerw w działaniu sekwencja zdarzeń jest szczególnie ważna. Określ, co wydarzyło się przed utratą komunikacji.
| Zaobserwowany wzór | Kierunek śledztwa | Czego to nie dowodzi |
|---|---|---|
| Odłączenie następuje po alarmie chłodzenia lub zasilania | Przejrzyj inicjujący alarm i reakcję ochronną | Że sprzęt komunikacyjny jest uszkodzony |
| Kontroler zawiesza się lub uruchamia ponownie w tym samym czasie | Przejrzyj dowody kontrolera i systemu operacyjnego | Że głowica testowa zainicjowała przerwanie |
| Błąd następuje po ruchu głowicy testowej | Sprawdź dozwolone zewnętrzne prowadzenie kabli, naprężenia i powiązane połączenia | Ten ruch ostatecznie zidentyfikował wadliwą część |
| Przerwanie rozpoczyna się po zmianie oprogramowania lub konfiguracji | Porównaj z udokumentowaną obsługiwaną konfiguracją | Że zmiana oprogramowania jest koniecznie przyczyną główną |
| Jeden z przyrządów zgłasza błędy przed dalszą utratą działania | Przejrzyj oryginalny błąd instrumentu i współdzielone zależności | Że przyczyną wyłączenia był wyłącznie sam instrument |
| Awarie zdarzają się tylko podczas trwania konkretnego programu | Porównanie wykorzystania zasobów i warunków operacyjnych | Że program jest wadliwy lub sprzęt jest sprawny |
Te wzorce kierują dochodzeniem. Nie zastępują one diagnostyki ani potwierdzonego wyniku naprawy.
Rejestruj warunki przed przerwą związaną z obciążeniem
Jeśli tester pozostaje podłączony, gdy nie jest używany, ale rozłącza się w trakcie testowania urządzenia, zapisz aktywną konfigurację i warunki pracy.
Zachowanie zasilania i chłodzenia, aktywność urządzeń, zdarzenia kontrolera i wykonywanie programu – wszystkie te czynniki mogą mieć znaczenie. Test połączenia bezczynnościowego nie odtwarza wszystkich warunków występujących podczas produkcji.
Nie uruchamiaj wielokrotnie podejrzewanego uszkodzenia w celu odtworzenia błędu.
Traktuj objawy związane z ruchem jako odrębną wskazówkę
Jeżeli po dokowaniu, oddokowaniu lub zmianie położenia pojawią się przerwy, należy udokumentować zależność, unikając wielokrotnego poruszania głowicą w celu spowodowania awarii.
Zewnętrzne naprężenie kabla lub uszkodzenie połączenia spowodowane ruchem mogą wymagać zbadania. Pozycja mechaniczna może również zbiegać się z inną zmianą, więc sam czas nie stanowi diagnozy.
Nie zastępuj PS1600 lub AVI64 wyłącznie na podstawie komunikatu o rozłączeniu
W przypadku awarii pojedynczego urządzenia oraz utraty komunikacji z głowicą testową wymagane są różne dowody.
Jeżeli przyrząd zgłosi błąd diagnostyczny, a głowica testowa pozostaje dostępna, należy zbadać to źródło, stosując odpowiednią procedurę.
Jeśli kilka urządzeń zniknie jednocześnie, należy dokonać przeglądu współdzielonej infrastruktury przed stwierdzeniem, że kilka kart uległo awarii jednocześnie.
Wymiana urządzenia powinna być rozważona dopiero po ustaleniu uzasadnionych wymagań sprzętowych. Niekontrolowana wymiana może powodować wątpliwości co do kompatybilności, zmiany konfiguracji i dodatkowe wymagania kalibracyjne.
W przypadku, gdy zastąpienie jest dozwolone, należy używać sprawdzonego, kompatybilnego sprzętu i zmieniać jedną zmienną na raz. Należy zapisać tożsamość oryginalną i zastępczą oraz wyniki porównania.
Co należy zweryfikować po odzyskaniu?
Pomyślne ponowne połączenie jest wstępnym rezultatem odzyskiwania. Nie oznacza to całkowitej akceptacji produkcji.
Postępuj zgodnie z odpowiednimi procedurami uruchamiania i obsługi poserwisowej, a następnie sprawdź:
Oczekiwane rozpoznanie sprzętu.
Zakończenie wymaganej diagnostyki.
Rozwiązanie alarmów inicjujących.
Wszelkie kalibracje wymagane przez interwencję.
Stabilna praca w odpowiednich warunkach zastosowania.
Prawidłowa komunikacja z osobą obsługującą lub badającą, jeśli ma to zastosowanie.
W przypadku problemu sporadycznego należy zdefiniować zakres weryfikacji oparty na czasie wystąpienia awarii. Krótki test rozruchowy nie jest wystarczający, aby wykazać rozwiązanie problemu przerwania, które wystąpiło wcześniej po dłuższym okresie eksploatacji.
Jeśli połączenie zostanie ponownie zerwane, zachowaj nowe dowody i kontynuuj śledztwo, zamiast polegać na kolejnych resetach.
Informacje potrzebne do oceny naprawy lub wymiany
Przed wysyłką sterownika, zespołu interfejsu lub instrumentu należy zapewnić:
| Informacja | Zamiar |
|---|---|
| Generacja V93000 i identyfikacja głowicy testowej | Ustala kontekst sprzętowy |
| Model kontrolera i środowisko programowe | Obsługuje przegląd konfiguracji |
| Wydanie SmartTest | Identyfikuje kontekst zainstalowanego oprogramowania |
| Dokładny pierwszy błąd i pełne logi | Zachowuje oryginalną sekwencję awarii |
| Wystąpienie podczas uruchamiania lub wykonywania | Oddziela inicjalizację od operacji przerywanych |
| Wydarzenia związane z zasilaniem i chłodzeniem | Pomaga zidentyfikować przerwę w transmisji w górę rzeki |
| Ostatnie zmiany | Definiuje trafne porównania |
| Etykiety podejrzanych komponentów | Obsługuje dokładne dopasowanie części |
W razie potrzeby usuń poufne informacje o programie urządzenia, zachowując jednocześnie szczegóły diagnostyczne niezbędne do zbadania usterki.
W przypadku usług za granicą, dowód ten pomaga ustalić, czy kolejnym krokiem powinna być kontrola w lokalnym zakładzie, autoryzowana inspekcja systemu, ocena sterownika, czy naprawa konkretnego podzespołu. Może to również zmniejszyć ryzyko wysyłki niepowiązanego zespołu.
Poproś o ocenę błędów połączenia V93000
Prześlij oryginalny błąd połączenia, identyfikator systemu i krótką chronologię zdarzenia. Określ, czy głowica testowa nigdy się nie połączyła, rozłączyła się po inicjalizacji lub stała się niedostępna po kolejnym alarmie.
Należy uwzględnić kontrole, które zostały już wykonane, a także wszelkie zmiany sprzętu i oprogramowania wprowadzone od ostatniej pomyślnej operacji.
