Quando umMáquina de teste Advantest V93000Se não for possível conectar-se à cabeça de teste ou se a conexão for perdida durante a operação, não presuma que a placa do instrumento tenha falhado. Registre o primeiro erro, verifique se o controlador permaneceu operacional e procure por alarmes anteriores de energia, refrigeração ou sistema.
Uma mensagem de comunicação identifica uma interação falha. Ela não identifica necessariamente o componente que a causou.
A primeira tarefa é distinguir uma falha de conexão na inicialização de uma conexão perdida após uma operação bem-sucedida.
Falha na inicialização ou desconexão durante a execução?
Essas duas situações fornecem evidências diferentes.
| Situação | O que estabelecer primeiro |
|---|---|
| O cabeçote de teste nunca fica disponível após a inicialização. | Verificar se o controlador, a prontidão da cabeça de teste e a sequência de inicialização foram concluídos conforme o esperado. |
| A conexão é interrompida após a inicialização bem-sucedida. | O que mudou ou causou alarme imediatamente antes da interrupção? |
| Um dos instrumentos falha na inicialização, embora a cabeça permaneça acessível. | Se o problema se limita a esse instrumento ou às suas dependências. |
| O teste do dispositivo é interrompido, mas a cabeça permanece conectada. | Independentemente de a interrupção pertencer ao programa, à interface ou ao fluxo de automação. |
| O próprio controlador trava ou reinicia. | Se a perda do host causou a aparente desconexão da cabeça de teste. |
Registre a etapa exata em que a operação é interrompida. "O testador está desconectado" é menos útil do que "o controlador permaneceu responsivo, mas a cabeça de teste ficou indisponível após um alarme de resfriamento".
Em um V93000testador de semicondutoresUma falha de conexão pode envolver o controlador, o caminho de comunicação ou a infraestrutura do cabeçote de teste. Identifique a conexão afetada antes de decidir qual componente requer investigação.
Confirme qual conexão falhou.
Antes de trocar os cabos ou encomendar uma placa de substituição, identifique os pontos de extremidade envolvidos no erro.
A relação relevante pode ser:
O controlador comunicando com a cabeça de teste.
O sistema inicializa um instrumento individual.
O testador troca sinais com um manipulador ou sonda de wafer.
Software que se comunica com um servidor de licenças.
Uma estação de trabalho remota que acessa o controlador de teste.
Um tempo limite do manipulador não comprova que a conexão entre o controlador e o servidor de teste falhou. Da mesma forma, a perda de acesso remoto ao controlador não prova que o caminho de comunicação interno do testador esteja com defeito.
Utilize a mensagem original e o status do sistema para identificar a relação afetada. Evite tratar todas as mensagens relacionadas à comunicação como se fossem a mesma falha.
Salve o primeiro erro antes de reiniciar.
Reiniciar o aparelho pode restaurar o funcionamento temporariamente, mas remove informações úteis da tela.
Se for seguro, conserve:
O primeiro erro completo e as mensagens subsequentes.
Registros relevantes do controlador e do testador.
O momento da interrupção.
Quais aplicativos e serviços permaneceram responsivos?
Estado do cabeçote de teste e da unidade de refrigeração.
Se todos os instrumentos ou apenas um recurso se tornou indisponível.
O programa e a fase operacional estavam ativos naquele momento.
Alterações recentes em software, hardware ou instalações.
Ao comparar registros de diferentes sistemas, mantenha os registros de data e hora alinhados. O relógio do controlador e o relógio de monitoramento da instalação podem não mostrar a mesma hora.
Não crie uma interpretação de código de erro com base em uma mensagem semelhante encontrada em outra geração do V93000. Mantenha a redação exata para consulta na documentação aplicável.
Se a cabeça de teste não se conectar na inicialização
Verificar prontidão do controlador
Verifique se o controlador concluiu a inicialização normal e se o ambiente de software necessário está disponível.
Se o controlador não inicializar, reiniciar repetidamente ou parar de responder, investigue essa condição antes de atribuir o problema à unidade de teste.
Após a substituição de um controlador ou a restauração de uma imagem do sistema, verifique o ambiente operacional compatível e a configuração restaurada. Um desktop funcional não comprova que o ambiente de teste foi restaurado corretamente.
Evite reinstalar o software ou alterar os arquivos de configuração antes de preservar o estado atual e os backups.
Verificar a prontidão da cabeça de teste e alarmes anteriores
Verifique as informações de status permitidas pelo procedimento operacional. Identifique se a inicialização está sendo impedida por uma condição de sistema não resolvida.
Problemas de energia, refrigeração ou outras condições de proteção podem interromper a prontidão e causar um erro de comunicação posterior. Investigue o primeiro evento relevante, em vez de apenas a mensagem final.
Não ignore um sistema de intertravamento nem suprima um alarme de proteção para forçar a inicialização.
Inspecione o caminho de comunicação externa documentado.
Identifique o caminho de comunicação correto para o controlador instalado e a configuração da unidade de teste. Os tipos de cabos, conectores e infraestrutura variam entre as instalações.
Com o sistema no estado de segurança prescrito, pessoal qualificado pode inspecionar as conexões acessíveis em busca de danos, tensão, fixação inadequada ou alterações feitas durante a manutenção recente.
Não assuma que um cabo de rede comum seja um substituto adequado. Não desconecte o sistema operacional experimentalmente nem perturbe os conectores ópticos sem seguir o procedimento de manuseio especificado.
A presença de uma indicação de ligação visível serve como evidência complementar, e não como prova, de que todas as comunicações necessárias estão funcionando.
Se a conexão cair durante a operação
Para interrupções em tempo de execução, a sequência de eventos é particularmente importante. Determine o que aconteceu antes da perda de comunicação.
| Padrão observado | Direção da investigação | O que isso não prova |
|---|---|---|
| Desconecte após um alarme de resfriamento ou de energia. | Analise o alarme inicial e a resposta de proteção. | Que o hardware de comunicação está com defeito. |
| O controlador trava ou reinicia ao mesmo tempo. | Analise as evidências do controlador e do sistema operacional. | Que o chefe de teste iniciou a interrupção |
| A falha ocorre após o movimento da cabeça de teste. | Inspecione o roteamento permitido dos cabos externos, a tensão e as conexões associadas. | Esse movimento identificou de forma conclusiva a parte que falhou. |
| A interrupção começa após uma alteração de software ou de configuração. | Compare com a configuração suportada documentada. | Que a alteração do software seja necessariamente a causa raiz. |
| Um instrumento reporta erros antes de uma perda de funcionamento mais ampla. | Analise o erro original do instrumento e as dependências compartilhadas. | O fato de o instrumento, por si só, ter causado o desligamento |
| As falhas ocorrem apenas durante um programa específico. | Comparar o uso de recursos e as condições de operação. | Que o programa está com defeito ou que o hardware está funcionando corretamente. |
Esses padrões orientam a investigação. Eles não substituem o diagnóstico ou a confirmação do reparo.
Registre as condições antes de uma interrupção relacionada à carga.
Se o testador permanecer conectado enquanto ocioso, mas se desconectar durante o teste do dispositivo, registre a configuração ativa e as condições de operação.
O comportamento da alimentação e do sistema de refrigeração, a atividade dos instrumentos, os eventos do controlador e a execução do programa podem ser relevantes. Um teste de conexão em modo ocioso não reproduz todas as condições presentes durante a produção.
Não execute repetidamente uma condição suspeita de ser prejudicial apenas para reproduzir a falha.
Trate os sintomas relacionados ao movimento como uma pista separada.
Caso ocorram interrupções após o acoplamento, desacoplamento ou reposicionamento, documente a relação sem mover repetidamente a cabeça para provocar falhas.
Uma tensão externa no cabo ou uma conexão afetada por movimento podem justificar uma investigação. A posição mecânica também pode coincidir com outra alteração, portanto, apenas o momento da verificação não constitui um diagnóstico.
Não substitua o PS1600 ou o AVI64 com base apenas em uma mensagem de desconexão.
Uma falha em um instrumento individual e a perda de comunicação com a cabeça de teste exigem evidências diferentes.
Se um instrumento reportar uma falha de diagnóstico enquanto a cabeça de teste permanecer acessível, investigue esse recurso utilizando o procedimento correspondente.
Se vários instrumentos pararem de funcionar simultaneamente, verifique a infraestrutura compartilhada antes de concluir que várias placas falharam ao mesmo tempo.
A substituição do instrumento deve ser considerada somente após a investigação identificar uma necessidade justificada de hardware. A substituição não controlada pode gerar problemas de compatibilidade, alterações de configuração e requisitos adicionais de calibração.
Quando a substituição for autorizada, utilize hardware compatível verificado e altere uma variável de cada vez. Registre as identidades do componente original e do componente de substituição, bem como os resultados da comparação.
O que deve ser verificado após a recuperação?
Uma reconexão bem-sucedida é um resultado inicial de recuperação. Não significa aceitação completa da produção.
Siga os procedimentos aplicáveis de inicialização e pós-serviço e, em seguida, verifique:
Reconhecimento de hardware esperado.
Conclusão dos diagnósticos necessários.
Resolução dos alarmes que os iniciaram.
Qualquer calibração exigida pela intervenção.
Funcionamento estável nas condições de aplicação relevantes.
Comunicação correta com o manipulador ou o responsável pela sondagem, quando aplicável.
Para um problema intermitente, defina um escopo de verificação significativo com base no momento em que a falha ocorreu. Um breve teste de inicialização é insuficiente para demonstrar a resolução de uma interrupção que ocorria anteriormente após um período prolongado de operação.
Se a conexão cair novamente, preserve as novas evidências e continue a investigação em vez de depender de reinicializações repetidas.
Informações necessárias para avaliação de reparo ou substituição
Antes de enviar um controlador, conjunto de interface ou instrumento, forneça:
| Informação | Propósito |
|---|---|
| Geração V93000 e identificação da cabeça de teste | Estabelece o contexto de hardware |
| Modelo do controlador e ambiente de software | Suporta revisão de configuração |
| Lançamento do SmartTest | Identifica o contexto do software instalado. |
| Erro inicial exato e registros completos. | Preserva a sequência de falhas original |
| Ocorrência de inicialização ou em tempo de execução | Separa a inicialização da operação intermitente. |
| Eventos de energia e refrigeração | Ajuda a identificar uma interrupção a montante. |
| Alterações recentes | Define comparações relevantes |
| Rótulos de componentes suspeitos | Suporta correspondência precisa de peças |
Remova as informações confidenciais do programa do dispositivo sempre que necessário, mantendo os detalhes de diagnóstico necessários para investigar a falha.
Para serviços no exterior, essas evidências ajudam a determinar se a próxima etapa deve ser uma verificação nas instalações locais, uma inspeção autorizada do sistema, uma avaliação do controlador ou o reparo de um componente específico. Também podem reduzir o risco de envio de um conjunto não relacionado.
Solicite uma avaliação de falhas de conexão V93000.
Envie o erro de conexão original, a identificação do sistema e um breve resumo dos eventos. Informe se a unidade de teste nunca se conectou, desconectou-se após a inicialização ou ficou indisponível após outro alarme.
Inclua as verificações já concluídas e quaisquer alterações de hardware ou software feitas desde a última operação bem-sucedida.
