Cuando unMáquina de pruebas Advantest V93000Si no puede conectarse a su cabezal de prueba o pierde la conexión durante el funcionamiento, no dé por sentado que la tarjeta del instrumento ha fallado. Conserve el registro del primer error, determine si el controlador siguió funcionando y compruebe si hubo alarmas previas de alimentación, refrigeración o del sistema.
Un mensaje de comunicación identifica una interacción fallida. No necesariamente identifica el componente que la causó.
La primera tarea consiste en distinguir entre un fallo de conexión al iniciar la conexión y una conexión perdida después de una operación exitosa.
¿Fallo al iniciar o desconexión durante la ejecución?
Estas dos situaciones proporcionan evidencias diferentes.
| Situación | ¿Qué establecer primero? |
|---|---|
| El cabezal de prueba nunca está disponible después del arranque. | Si el controlador, la preparación del cabezal de prueba y la secuencia de inicialización se completaron según lo requerido |
| La conexión se interrumpe tras una inicialización exitosa. | ¿Qué cambió o qué causó alarma inmediatamente antes de la interrupción? |
| Un instrumento falla durante la inicialización mientras el cabezal permanece accesible. | Si el problema se limita a ese instrumento o a sus dependencias |
| Las pruebas del dispositivo se detienen, pero el cabezal permanece conectado. | Ya sea que la interrupción pertenezca al programa, a la interfaz o al flujo de automatización. |
| El controlador se congela o se reinicia. | Si la pérdida del host causó la aparente desconexión del cabezal de prueba |
Registre la etapa precisa en la que se detiene el funcionamiento. Decir "El comprobador está desconectado" es menos útil que decir "El controlador siguió respondiendo, pero el cabezal de prueba dejó de estar disponible tras una alarma de refrigeración".
En un V93000probador de semiconductoresUn fallo de conexión puede afectar al controlador, a la ruta de comunicación o a la infraestructura del cabezal de prueba. Identifique la conexión afectada antes de decidir qué componente requiere investigación.
Confirme qué conexión ha fallado.
Antes de cambiar los cables o pedir una placa de repuesto, identifique los puntos finales involucrados en el error.
La relación pertinente puede ser:
El controlador se comunica con el cabezal de prueba.
El sistema inicializa un instrumento individual.
El técnico intercambia señales con un operario o un analizador de obleas.
Software que se conecta a un servidor de licencias.
Una estación de trabajo remota que accede al controlador del probador.
Un tiempo de espera agotado en el controlador no indica que la conexión entre el controlador y el cabezal de prueba haya fallado. Del mismo modo, perder el acceso remoto al controlador no demuestra que la ruta de comunicación interna del probador sea defectuosa.
Utilice el mensaje original y el estado del sistema para identificar la relación afectada. Evite tratar todos los mensajes relacionados con la comunicación como si se tratara del mismo fallo.
Guarda el primer error antes de reiniciar.
Un reinicio puede restablecer el funcionamiento temporalmente, aunque elimine el contenido útil de la pantalla.
Si es seguro, conservar:
El primer error completo y los mensajes subsiguientes.
Registros relevantes del controlador y del probador.
El momento de la interrupción.
¿Qué aplicaciones y servicios siguieron funcionando?
Estado del cabezal de prueba y de la unidad de refrigeración.
Ya sea que todos los instrumentos o solo un recurso dejaran de estar disponibles.
El programa y la fase operativa que estaban activos en ese momento.
Cambios recientes en software, hardware o instalaciones.
Al comparar registros de diferentes sistemas, asegúrese de que las marcas de tiempo coincidan. Es posible que el reloj del controlador y el reloj de monitoreo de las instalaciones no muestren la misma hora.
No invente una interpretación del código de error a partir de un mensaje similar encontrado en otra generación del V93000. Conserve la redacción exacta para revisarla con la documentación correspondiente.
Si el cabezal de prueba no se conecta al iniciar
Comprobar la disponibilidad del controlador
Compruebe si el controlador ha completado su arranque normal y si el entorno de software necesario está disponible.
Si el controlador no arranca, se reinicia repetidamente o deja de responder, investigue esa situación antes de atribuir el problema al cabezal de prueba.
Tras sustituir un controlador o restaurar la imagen del sistema, revise el entorno operativo compatible y la configuración restaurada. Que el escritorio funcione correctamente no garantiza que el entorno de prueba se haya restaurado correctamente.
Evite reinstalar el software o modificar los archivos de configuración antes de conservar el estado actual y las copias de seguridad.
Revise la preparación del cabezal de prueba y las alarmas anticipadas.
Verifique la información de estado permitida por el procedimiento operativo. Identifique si la inicialización se ve impedida por una condición del sistema no resuelta.
El suministro eléctrico, la refrigeración u otras condiciones de protección pueden interrumpir la disponibilidad y provocar un error de comunicación posterior. Investigue el primer evento relevante, en lugar de centrarse únicamente en el mensaje final.
No anule un sistema de enclavamiento ni suprima una alarma de protección para forzar la inicialización.
Inspeccione la ruta de comunicación externa documentada.
Identifique la ruta de comunicación correcta para la configuración del controlador y el cabezal de prueba instalados. Los tipos de cables, conectores e infraestructura varían según la instalación.
Una vez que el sistema se encuentra en el estado de seguridad prescrito, el personal cualificado puede inspeccionar las conexiones accesibles para detectar daños, tensiones, sujeción deficiente o cambios realizados durante el mantenimiento reciente.
No asuma que un cable de red común es un reemplazo adecuado. No desconecte un sistema operativo de forma experimental ni manipule los conectores ópticos sin seguir el procedimiento de manipulación especificado.
La presencia de un indicador de enlace visible, cuando está presente, constituye una evidencia complementaria, pero no una prueba concluyente, de que todas las comunicaciones necesarias funcionan correctamente.
Si la conexión se interrumpe durante el funcionamiento.
En caso de interrupciones durante la ejecución, la secuencia de eventos es particularmente importante. Determine qué sucedió antes de que se perdiera la comunicación.
| Patrón observado | Dirección de la investigación | Lo que no demuestra |
|---|---|---|
| La desconexión se produce tras una alarma de refrigeración o de alimentación. | Revise la alarma inicial y la respuesta de protección. | Que el hardware de comunicación está defectuoso |
| El controlador se congela o se reinicia al mismo tiempo. | Revisar la evidencia del controlador y del sistema operativo | Que el cabezal de prueba inició la interrupción |
| El fallo se produce tras el movimiento del cabezal de prueba. | Inspeccione el trazado de cables externos permitido, la tensión y las conexiones asociadas. | Ese movimiento ha identificado de manera concluyente la parte fallida. |
| La interrupción comienza después de un cambio de software o de configuración. | Comparar con la configuración compatible documentada | Que el cambio de software sea necesariamente la causa raíz |
| Un instrumento informa de errores antes de que se produzca una pérdida de funcionamiento generalizada. | Revise el error del instrumento original y las dependencias compartidas. | Que el instrumento por sí solo provocó la parada |
| Los fallos ocurren solo durante un programa en particular. | Comparar el uso de recursos y las condiciones de funcionamiento | Que el programa sea defectuoso o que el hardware esté en buen estado. |
Estos patrones sirven de guía para la investigación. No sustituyen el diagnóstico ni la confirmación de la reparación.
Condiciones de registro antes de una interrupción relacionada con la carga
Si el comprobador permanece conectado mientras está inactivo, pero se desconecta durante la prueba del dispositivo, registre la configuración activa y las condiciones de funcionamiento.
El comportamiento de la alimentación y la refrigeración, la actividad de los instrumentos, los eventos del controlador y la ejecución del programa pueden ser factores relevantes. Una prueba de conexión en reposo no reproduce todas las condiciones presentes durante la producción.
No reproduzca repetidamente una condición que se sospecha que es dañina simplemente para reproducir la falla.
Tratar los síntomas relacionados con el movimiento como una pista aparte.
Si se producen interrupciones después del acoplamiento, desacoplamiento o reposicionamiento, documente la relación sin mover repetidamente el cabezal para evitar fallos.
Una tensión externa en el cable o una conexión afectada por el movimiento podrían requerir una investigación. La posición mecánica también podría coincidir con otro cambio, por lo que la sincronización por sí sola no constituye un diagnóstico.
No reemplace el PS1600 o el AVI64 basándose únicamente en un mensaje de desconexión.
Un fallo en un instrumento individual y la pérdida de comunicación con el cabezal de prueba requieren evidencias diferentes.
Si un instrumento informa de un fallo de diagnóstico mientras el cabezal de prueba permanece accesible, investigue ese recurso utilizando el procedimiento correspondiente.
Si varios instrumentos desaparecen al mismo tiempo, revise la infraestructura compartida antes de concluir que varias tarjetas fallaron simultáneamente.
Solo se debe considerar la sustitución del instrumento una vez que la investigación haya identificado una necesidad justificada de hardware. Una sustitución no controlada puede generar problemas de compatibilidad, cambios de configuración y requisitos de calibración adicionales.
Cuando se autorice la sustitución, utilice hardware compatible verificado y cambie una variable a la vez. Registre las identidades del componente original y del de reemplazo, así como los resultados de la comparación.
¿Qué debe verificarse después de la recuperación?
Una reconexión exitosa es un resultado inicial de recuperación. No implica la aceptación total de la producción.
Siga los procedimientos de puesta en marcha y post-servicio aplicables y, a continuación, verifique:
Reconocimiento de hardware esperado.
Realización de las pruebas diagnósticas requeridas.
Resolución de las alarmas iniciales.
Cualquier calibración requerida por la intervención.
Funcionamiento estable en las condiciones de aplicación pertinentes.
Comunicación correcta con el operador o la persona que realiza la prueba, según corresponda.
Para un problema intermitente, defina un alcance de verificación adecuado en función del momento en que se produjo el fallo. Una breve prueba de arranque no es suficiente para demostrar la resolución de una interrupción que se produjo tras un funcionamiento prolongado.
Si la conexión se interrumpe de nuevo, guarde las nuevas pruebas y continúe la investigación en lugar de depender de reinicios repetidos.
Información necesaria para la evaluación de reparación o reemplazo
Antes de enviar un controlador, un conjunto de interfaz o un instrumento, proporcione lo siguiente:
| Información | Objetivo |
|---|---|
| Generación del V93000 e identificación del cabezal de prueba | Establece el contexto del hardware |
| Modelo de controlador y entorno de software | Admite la revisión de la configuración |
| Versión de SmartTest | Identifica el contexto del software instalado |
| Primer error exacto y registros completos | Conserva la secuencia de fallos original. |
| Ocurrencia durante el inicio o la ejecución | Separa la inicialización del funcionamiento intermitente. |
| Eventos de energía y refrigeración | Ayuda a identificar una interrupción en la fase inicial del proceso. |
| Cambios recientes | Define las comparaciones relevantes. |
| Etiquetas de componentes sospechosos | Permite una correspondencia precisa de las piezas. |
Elimine la información confidencial del programa del dispositivo cuando sea necesario, conservando los detalles de diagnóstico necesarios para investigar la falla.
Para el servicio en el extranjero, esta evidencia ayuda a determinar si el siguiente paso debe ser una verificación de las instalaciones locales, una inspección autorizada del sistema, una evaluación del controlador o la reparación de un componente específico. También puede reducir el riesgo de enviar un conjunto no relacionado.
Solicite una evaluación de fallas de conexión V93000
Envíe el error de conexión original, la identificación del sistema y una breve cronología del evento. Indique si el cabezal de prueba nunca se conectó, se desconectó después de la inicialización o dejó de estar disponible tras otra alarma.
Incluya las comprobaciones ya realizadas y cualquier cambio de hardware o software realizado desde la última operación exitosa.
