Semana passada substituimos 4 arquiteturas Simatic S5 por hardware VIPA Speed7, System 300V e System 100V. Dentre as intervenções, 2 foram numa enchedora Krones que era controlada por dois CLPs independentes (Simatic S5 945 na enchedora, Simatic S5 095U na enxaguadora). Tal arquitetura original justifica-se pelo fato de que as máquinas (enchedora e enxaguadora) foram adquiridas individualmente e depois integradas.

O escopo do trabalho incluiu então a integração da Enchedora e da Enxaguadora em uma única CPU. Ou seja, o rack de 115U onde estava instalada a 945 foi eliminado, uma CPU Speed7 313C-2DP passou a controlar a máquina e convertemos o rack de 095 da enxaguadora numa remota do System 300V da VIPA.

Ocorre que concluída toda a instalação elétrica, quando partimos para testar a máquina, verificamos que havia uma falha. Através de funções de diagnóstico, verificamos que o problema estava justamente na nova remota.

Para nossa surpresa, haviamos deixado o cabo conversor 232/DP no escritório, de outra forma, seria fácil verificar se o problema estava na infra-estrutura de rede ou na remota. Mas, como a máquina precisava rodar, partimos para o diagnóstico de outra maneira.

Isolando o problema

Infra-estrutura de rede ou módulo de comunicação?

  1. Carregamos no Speed7 313-2DP um aplicativo sem a nova remota e fechamos o resistor de terminação de barramento na última remota da configuração original. Ou seja, desligamos a nova remota lógica e fisicamente. Então a falha saiu como já era de se esperar.
  2. Substituimos o módulo de comunicação da última remota(imediatamente anterior à nova) pelo módulo da nova. Ao partirmos novamente o Speed7, verificamos que a rede continuava estável. Então concluímos que o módulo de comunicação estava em perfeito estado de funcionamento.
  3. Instalamos o Speed7 313-2DP no rack onde estava a nova remota e utilizamos seu ponto de conexão para interligá-lo à rede. Resultado: a máquina funcionou.

Conclusão: a infra-estrutura de rede estava íntegra, assim como o módulo de comunicação.

Módulos de i/o ou conectores de barramento?

Ora, se a rede estava íntegra e os módulos de comunicação também, o problema só podia estar no rack dos componentes da nova remota. Então adotamos a velha técnica de configuração módulo-a-módulo.

  1. Conectamos à CPU Speed7 um único módulo de i/o através do bus traseiro. Resultado: OK.
  2. Prosseguimos conectando os demais módulos, um a um, e testando o rack.
  3. Quando conectamos o último módulo, verificamos que ele não estava sendo lido pela CPU. Precisavamos então saber se o problema estava no módulo, ou no barramento.
  4. Trocamos o módulo de posição e verificamos que ele estava em perfeito funcionamento, mas o outro instalado em sua posição original não mais estava sendo lido.

Resolução e considerações.

Substituimos o barramento e colocamos a máquina em marcha.

A técnica que utilizamos é muito usada para diagnóstico de falhas de hardware. É simples e eficaz. Basta ir criando projetos novos, sem programa, configurando apenas o hardware. Através de funções de monitoramento e force, deve-se tentar ler e/ou escrever em cada módulo para verificar se estão se comunicando com a CPU.

Em outros momentos, chegamos a conclusões como:

  • O barramento da cpu estava com defeito.
  • Um módulo de i/o só funcionava na última posição do rack. Qualquer módulo colocado depois dele não era lido.
  • Um conector de barramento tinha um defeito tal, que só permitia o tráfego dos dados dos módulos de i/o digital, a partir daquele ponto, nenhum módulo analógico era lido
  • Um rack de expansão estava com defeito

Realço o fato que esses problemas aconteceram com arquiteturas de diversos fabricantes diferentes, mas a forma de diagnosticar foi a mesma. Detalhe: o trabalho de diagnóstico exige calma e tranquilidade. Aprendi com meu amigo Alberto Lopes, engenheiro de manutenção, a parar pra tomar um café, ou uma água, quando estou no “pico” da pressão. E isso faz toda a diferença.

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.

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.

© 2010 Dênis Leite Suffusion WordPress theme by Sayontan Sinha