Rastreando um defeito intermitente. Método e relato de caso. | Dênis Leite

automação para competitividade

Rastreando um defeito intermitente. Método e relato de caso.

Certa vez fomos solicitados a prestar assistência técnica numa máquina que apresentava um defeito intermitente. De uma ora para a outra, a máquina parava, e perdia-se considerável quantidade de matéria-prima na nova partida.

Ao chegar à fábrica, fui comunicado que outro profissional já havia tentato resolver o problema. Ele havia passado um dia inteiro monitorando o programa mas como a falha não aconteceu, não conseguiu diagnosticar a origem do defeito.

Como o problema precisava ser resolvido, nós precisavamos “dar nossos pulos”, e aí vai passo-a-passo o método que utilizamos naquele dia.

1. Descontaminação da mente.

Após a conversa preliminar sobre o problema, às vezes somos tentados a seguir uma linha de raciocínio baseada em experiências passadas que nem sempre conduz à resolução do problema. Mas aprendemos com o tempo que a melhor coisa para resolver “uma bronca” é entrar com a mente descontaminada.

Nessa hora, esquecemos que tinhamos notebooks, terminais de programação, manuais etc. O foco era o operador. Não buscamos entender todo o processo, mas sim tudo o que o operador fazia para operar a máquina, cada botão, cada parâmetro na ihm.

2. Reconhecimento da máquina e do problema.

Com a mente descontaminada, deve-se então procurar entender duas coisas: o que está acontecendo, e o que deveria estar acontecendo. Em outras palavras, como está funcionando e como deveria estar.

Essa etapa não nos ajudou muito. Em síntese, era pra funcionar, e de uma ora pra outra, parava.

3. Reconhecimento de quando começou o problema.

Muitas vezes o problema surge após uma intervenção na máquina(reforma, troca de componente etc), uma troca de turno, uma queda de energia etc. Qualquer informação que marque a fronteira entre o funcionada, e o não funciona mais, é muito importante.

Não havia marco do início do problema. Começou de repente.

4. Reconhecimento do que também ocorre quando o problema ocorre.

Se a máqunia para quando o problema ocorre, fica ainda mais difícil rastreá-lo. A pergunta, nesse caso, o que acontece primeiro? Onde começa o problema?

Aqui encontramos o que procurávamos. Descobrimos que todas as vezes que o problema ocorria, a IHM exibia uma determinada tela.

5. Isolamento das possíveis causas.

Nesse ponto, são vários caminhos a serem traçados. No nosso caso, utilizamos a estratégia de “atacar pelos dois lados” ou seja, verificar o que está acontecendo, e o que pode estar fazendo isso acontecer.

Nessa aplicação específica foi relativamente fácil resolver depois que descobrimos o detalhe da IHM. Somente duas condições levavam a aplicação àquela tela: um comando de navegação da própria IHM e uma entrada digital. Ora, se o operador não estava comandando manualmente, só podia ser o teclado da IHM com defeito ou a entrada digital.

Como não havia outra IHM para testarmos, programamos para que na borda de subida do comando da IHM ou da entrada digital, fossem setados flags que nos permitissem verificar depois do “pulso”, quem teria sido o “culpado”.

Para nossa felicidade, era a entrada digital que causava a parada e a IHM estava intácta. Paralelamente, haviamos verificado um detalhe que só confirmava nossa teoria: a entrada digital bloqueava o motor principal da máquina.

6. Isolamento da causa e resolução do problema.

Pronto. Isolada a causa, vem a ação.

A bendita entrada digital não estava documentada. Seguimos o fio e não conseguimos encontrar “a outra ponta” que estava após um leito que ligava a máquina a um CCM. Verificamos “o que poderia ser” mas não identificamos nada. A entrada digital ficava normalmente em ZERO e parava o motor quando ficava em 1 (um). Verificamos que não era o sinal do relé térmico, não tinha relação com a emergência, não era retroaviso de nada, pois todos esses elementos de segurança e intertravamento estavam devidamente documentados.

Moral da história: isolamos o cabo e o problema foi sanado.

Cliente satisfeito, máquina em marcha, fábrica produzindo. Melhor impossível.

A propósito, o CLP era um Piccolo da Altus, acho que um PL104. A IHM era um Foton 10, cuja navegação é toda controlada pelo CLP. Nessas horas ajuda muito conhecer coisas antigas!

Acho que esse é um caso que merecia ser comentado para ilustrar o método que pode ajudar a resolver outros problemas semelhantes.

Gostou do conteúdo? Assine nossa newsletter!

Como sabemos que ninguem tem tempo a perder, condensamos o material e enviamos os headlines uma ou duas vezes ao mês.


4 Comments

  • Muito bom post cara. Parabéns, mas acho que faltou um comentário.. Esses tipos de problemas ocorrem por erros de projeto.. Se essa entrada gerasse alguma falha na IHM daria muito menos dor de cabeça

  • Rogério,
    obrigado pela contribuição!
    Nesse caso específico, não ficou claro se o problema se tratava de uma falha no as-built, ou uma alteração não-documentada. Só uma coisa é certa, o sinal não servia para nada senão para gerar problemas, porque até hoje a máquina está totalmente funcional sem ele.
    Saudações,
    Dênis

Post a Comment

Your email address will not be published. Required fields are marked *

Spam Protection by WP-SpamFree

  • Categorias