Cando unMáquina de proba Advantest V93000non se pode conectar ao seu cabezal de proba ou perde a conexión durante o funcionamento, non dea por sentado que fallou unha tarxeta do instrumento. Preserve o primeiro erro, determine se o controlador permaneceu operativo e comprobe as alarmas anteriores de alimentación, refrixeración ou sistema.
Unha mensaxe de comunicación identifica unha interacción fallida. Non identifica necesariamente o compoñente que a causou.
A primeira tarefa é distinguir un fallo de conexión de inicio dunha conexión perdida despois dunha operación exitosa.
Fallo de inicio ou desconexión en tempo de execución?
Estas dúas situacións proporcionan probas diferentes.
| Situación | Que establecer primeiro |
|---|---|
| O cabezal de proba nunca está dispoñible despois do inicio | Se o controlador, a dispoñibilidade do cabezal de proba e a secuencia de inicialización se completaron segundo o requirido |
| A conexión córtase despois dunha inicialización correcta | Que cambiou ou xerou a alarma inmediatamente antes da interrupción |
| Un instrumento falla na inicialización mentres a cabeza permanece accesible | Se o problema se limita a ese instrumento ou ás súas dependencias |
| A proba do dispositivo detense pero o cabezal permanece conectado | Se a interrupción pertence ao programa, á interface ou ao fluxo de automatización |
| O propio controlador conxélase ou reinicia | Se a perda do servidor causou a aparente desconexión do cabezal de proba |
Rexistra a fase precisa na que se detén o funcionamento. «O comprobador está desconectado» é menos útil que «o controlador seguiu respondendo, pero o cabezal de proba deixou de estar dispoñible despois dunha alarma de arrefriamento».
Nun V93000probador de semicondutores, un fallo de conexión pode afectar o controlador, a ruta de comunicación ou a infraestrutura do cabezal de proba. Identifique a conexión afectada antes de decidir que compoñente require investigación.
Confirmar cal das conexións fallou
Antes de cambiar os cables ou solicitar unha placa de substitución, identifique os puntos finais implicados no erro.
A relación relevante pode ser:
O controlador comunicándose co cabezal de proba.
O sistema inicializando un instrumento individual.
O probador intercambia sinais cun manipulador ou unha sonda de obleas.
Software contactando cun servidor de licenzas.
Unha estación de traballo remota que accede ao controlador do probador.
Un tempo de espera do controlador non establece que a conexión entre o controlador e o cabezal de proba fallou. Do mesmo xeito, a perda do acceso remoto ao controlador non demostra que a ruta de comunicación interna do testador sexa defectuosa.
Emprega a mensaxe orixinal e o estado do sistema para identificar a relación afectada. Evita tratar todas as mensaxes relacionadas coa comunicación como o mesmo fallo.
Garda o primeiro erro antes de reiniciar
Un reinicio pode restaurar o funcionamento temporalmente á vez que elimina contexto útil da pantalla.
Se é seguro, conserve:
O primeiro erro completo e as mensaxes posteriores.
Rexistros relevantes do controlador e do probador.
O momento da interrupción.
Que aplicacións e servizos seguiron respondendo.
Estado do cabezal de proba e da unidade de refrixeración.
Se todos os instrumentos ou só un recurso quedaron indispoñibles.
O programa e a fase operativa activa nese momento.
Cambios recentes no software, hardware ou instalacións.
Manteña as marcas de tempo aliñadas ao comparar rexistros de diferentes sistemas. É posible que un reloxo de controlador e un reloxo de monitorización de instalacións non mostren a mesma hora.
Non inventes unha interpretación de código de erro a partir dunha mensaxe similar atopada para outra xeración de V93000. Conserva a redacción exacta para revisala na documentación aplicable.
Se o cabezal de proba non se conecta ao iniciar
Comprobar a dispoñibilidade do controlador
Comprobe se o controlador completou o seu arranque normal e se o entorno de software requirido está dispoñible.
Se o controlador non arranca, reiníciase repetidamente ou deixa de responder, investigue esa condición antes de atribuír o problema ao cabezal de proba.
Despois de substituír un controlador ou restaurar a imaxe do sistema, revise o entorno operativo compatible e a configuración restaurada. Un escritorio que funcione non demostra que o entorno de probas se restaurase correctamente.
Evite reinstalar software ou modificar os ficheiros de configuración antes de conservar o estado e as copias de seguridade existentes.
Revisar a dispoñibilidade do cabezal de proba e as alarmas anteriores
Comprobe a información de estado permitida polo procedemento operativo. Identifique se a inicialización está a ser impedida por unha condición do sistema non resolta.
A alimentación, a refrixeración ou outras condicións de protección poden interromper a dispoñibilidade e producir un erro de comunicación posterior. Investigue o evento relevante máis temperán en lugar de só a mensaxe final.
Non omita un bloqueo nin suprima unha alarma de protección para forzar a inicialización.
Inspeccionar a ruta de comunicación externa documentada
Identifica a ruta de comunicación correcta para o controlador instalado e a configuración do cabezal de proba. Os tipos de cable, os conectores e a infraestrutura varían segundo as instalacións.
Co sistema no estado seguro prescrito, o persoal cualificado pode inspeccionar as conexións accesibles para detectar danos, tensións, retención insegura ou cambios realizados durante o mantemento recente.
Non deas por feito que un cable de rede ordinario é un substituto axeitado. Non desconecte un sistema operativo experimentalmente nin manipule os conectores ópticos sen o procedemento de manipulación especificado.
Unha indicación de ligazón visible, se a houbese, constitúe unha evidencia que respalda o funcionamento en lugar dunha proba de que toda a comunicación requirida está a funcionar.
Se a conexión se cae durante o funcionamento
Para as interrupcións en tempo de execución, a secuencia de eventos é particularmente importante. Determine que aconteceu antes de que se perdese a comunicación.
| Patrón observado | Dirección da investigación | O que non demostra |
|---|---|---|
| A desconexión segue a unha alarma de refrixeración ou de enerxía | Revisar a alarma inicial e a resposta de protección | Que o hardware de comunicación está defectuoso |
| O controlador conxélase ou reiníciase ao mesmo tempo | Revisar a evidencia do controlador e do sistema operativo | Que o xefe de probas iniciou a interrupción |
| Fallo despois do movemento do cabezal de proba | Inspeccionar o trazado de cables externos permitidos, a tensión e as conexións asociadas | Ese movemento identificou de forma concluínte a parte fallida |
| A interrupción comeza despois dun cambio de software ou de configuración | Comparar coa configuración compatible documentada | Que o cambio de software é necesariamente a causa raíz |
| Un instrumento informa de erros antes dunha perda de funcionamento máis ampla | Revisar o erro orixinal do instrumento e as dependencias compartidas | Que o instrumento por si só causou o apagado |
| Os fallos só ocorren durante un programa en particular | Comparar o uso dos recursos e as condicións operativas | Que o programa estea defectuoso ou que o hardware estea en bo estado |
Estes patróns guían a investigación. Non substitúen o diagnóstico nin un achado de reparación confirmado.
Rexistro das condicións antes dunha interrupción relacionada coa carga
Se o comprobador permanece conectado mentres está inactivo pero se desconecta durante as probas do dispositivo, rexistre a configuración activa e as condicións de funcionamento.
O comportamento da alimentación e da refrixeración, a actividade do instrumento, os eventos do controlador e a execución do programa poden ser relevantes. Unha proba de conexión inactiva non reproduce todas as condicións presentes durante a produción.
Non execute repetidamente unha condición sospeitosa de ser daniña simplemente para reproducir o fallo.
Trata os síntomas relacionados co movemento como unha pista separada
Se aparecen interrupcións despois do acoplamento, desacoplamento ou reposicionamento, documente a relación sen mover a cabeza repetidamente para provocar un fallo.
Unha tensión externa no cable ou unha conexión afectada polo movemento poden xustificar unha investigación. A posición mecánica tamén pode coincidir con outro cambio, polo que o tempo por si só non é un diagnóstico.
Non substituír PS1600 ou AVI64 baseándose unicamente nunha mensaxe de desconexión
Un fallo individual do instrumento e a perda de comunicación co cabezal de proba requiren probas diferentes.
Se un instrumento informa dun fallo de diagnóstico mentres o cabezal de proba permanece accesible, investigue ese recurso usando o procedemento correspondente.
Se varios instrumentos desaparecen xuntos, revise a infraestrutura compartida antes de chegar á conclusión de que fallaron varias tarxetas simultaneamente.
Só se debe considerar a substitución dun instrumento despois de que a investigación identifique un requisito de hardware xustificado. A substitución incontrolada pode introducir dúbidas de compatibilidade, cambios de configuración e requisitos de calibración adicionais.
Onde se autorice a substitución, use hardware compatible verificado e cambie unha variable á vez. Rexistre as identidades orixinal e de substitución e os resultados da comparación.
Que se debe verificar despois da recuperación?
Unha reconexión exitosa é un resultado inicial da recuperación. Non é unha aceptación completa da produción.
Siga os procedementos de posta en marcha e posvenda aplicables e, a seguir, verifique:
Recoñecemento de hardware esperado.
Completamento dos diagnósticos requiridos.
Resolución das alarmas iniciadoras.
Calquera calibración requirida pola intervención.
Funcionamento estable nas condicións de aplicación relevantes.
Comunicación correcta co manipulador ou co detector, se é o caso.
Para un problema intermitente, defina un alcance de verificación significativo baseado en cando se produciu o fallo. Unha proba de inicio curta non é suficiente para demostrar a resolución dunha interrupción que se producía previamente despois dun funcionamento prolongado.
Se a conexión volve caer, conserva as novas probas e continúa a investigación en lugar de depender de reinicios repetidos.
Información necesaria para a avaliación de reparación ou substitución
Antes de enviar un controlador, un conxunto de interface ou un instrumento, proporcione:
| Información | Propósito |
|---|---|
| Xeración de V93000 e identificación do cabezal de proba | Establece o contexto do hardware |
| Modelo de controlador e entorno de software | Admite a revisión da configuración |
| Lanzamento de SmarTest | Identifica o contexto do software instalado |
| Primeiro erro exacto e rexistros completos | Conserva a secuencia de fallos orixinal |
| Ocorrencia de inicio ou de execución | Separa a inicialización do funcionamento intermitente |
| Eventos de enerxía e refrixeración | Axuda a identificar unha interrupción augas arriba |
| Cambios recentes | Define comparacións relevantes |
| Etiquetas de compoñentes sospeitosos | Admite a correspondencia precisa de pezas |
Eliminar a información confidencial do programa do dispositivo onde sexa necesario, conservando os detalles de diagnóstico necesarios para investigar o fallo.
Para o servizo no estranxeiro, esta evidencia axuda a determinar se o seguinte paso debe ser unha comprobación nunha instalación local, unha inspección autorizada do sistema, unha avaliación do controlador ou a reparación dun compoñente específico. Tamén pode reducir o risco de enviar un conxunto non relacionado.
Solicitar unha avaliación de fallos de conexión V93000
Enviar o erro de conexión orixinal, a identificación do sistema e unha breve cronoloxía do evento. Indicar se o cabezal de proba nunca se conectou, se se desconectou despois da inicialización ou se deixou de estar dispoñible despois doutra alarma.
Inclúa as comprobacións xa completadas e calquera cambio de hardware ou software realizado desde a última operación correcta.
