Movimento descontrolado intermitente do carro é um evento de segurança de máquina

Um eixo que se move sem o comando esperado não é uma falha rotineira de comissionamento. É um evento de movimento descontrolado que pode danificar ferramentas, estruturas da máquina, peças, dispositivos de fixação e pessoas. O risco se torna mais difícil de gerenciar quando o carro se comporta normalmente por muitas horas antes de se mover repentinamente a uma velocidade ou em uma direção inesperada.

A máquina considerada neste caso usa uma Siemens SIMATIC S7-200 CPU 226, uma unidade SIMOVERT MASTERDRIVES para os eixos dos carros, um MICROMASTER 440 para o spindle e um painel de operação TP 170A. Os dados de comando e status trafegam por uma rede de comunicação serial USS.

O problema relatado ocorre em um ou em ambos os carros. Um incidente pode aparecer uma ou duas vezes durante um dia de trabalho, seguido por dois ou três dias de operação normal. As tentativas anteriores incluíram separar o VFD do spindle do painel de controle principal e melhorar o aterramento. Essas ações não eliminaram a falha.

Esse padrão frequentemente incentiva uma investigação baseada em especulação. Os engenheiros podem substituir um encoder, redirecionar um cabo, ajustar um parâmetro do acionamento ou adicionar outro condutor de aterramento. Uma alteração pode modificar temporariamente o sintoma, criando a impressão de que o problema foi resolvido. O evento então retorna porque o caminho real do comando nunca foi comprovado.

Uma investigação confiável deve identificar o primeiro ponto em que o comportamento esperado se torna anormal. A equipe precisa saber o que a IHM solicitou, o que o CLP aceitou, o que o CLP transmitiu, o que o acionamento recebeu, o que o acionamento ativou internamente e o que o motor realmente fez.

Comece confirmando todos os dispositivos instalados

Os sistemas Siemens legados frequentemente permanecem em operação muito tempo depois que a equipe de comissionamento original saiu. Os desenhos podem conter alterações manuscritas. Os backups de parâmetros podem estar incompletos. Módulos de reposição podem ter sido instalados sem que a documentação fosse atualizada. Portanto, a identificação do hardware deve vir antes da interpretação dos parâmetros.

Registre o número de pedido completo de cada plaqueta de identificação. Não dependa apenas de uma lista de equipamentos digitada. O número da CPU S7-200 informado contém caracteres que podem ter sido copiados incorretamente. O controlador real pode corresponder ao Siemens 6ES7216-2BD23-0XB0 SIMATIC S7-200 CPU 226, mas a fonte de alimentação e a variante de saída devem ser confirmadas diretamente na unidade instalada.

Um único caractere incorreto pode levar ao manual, diagrama de terminais ou peça de reposição errados. A letra O é frequentemente confundida com o zero. O número um pode ser confundido com a letra I. Um sufixo ausente também pode ocultar uma opção importante de hardware.

A mesma disciplina se aplica à unidade SIMOVERT MASTERDRIVES. MASTERDRIVES é uma família ampla, e não um único projeto fixo de acionamento. As placas de controle, versões de software, opções de encoder, placas de tecnologia e configurações de Vector Control ou Motion Control podem alterar os parâmetros disponíveis e o roteamento interno dos sinais.

O número de pedido do MICROMASTER 440 também deve ser verificado. Embora o MM440 controle o spindle, e não os carros deslizantes, ele compartilha o ambiente do gabinete e pode compartilhar o caminho de comunicação USS. Seus eventos de comutação, roteamento de cabos, configuração de endereço e temporização da comunicação podem influenciar o sistema como um todo.

Registre o modelo do TP 170A, a versão do projeto da IHM, as configurações de comunicação e os endereços do CLP conectado. O painel pode conter eventos de botões, funções de receita, valores de inicialização ou comportamentos de tags que não podem ser identificados apenas pelo programa do CLP.

Antes de alterar qualquer parâmetro, crie backups completos do programa do CLP, do projeto da IHM, do conjunto de parâmetros do MASTERDRIVES e do conjunto de parâmetros do MM440. Fotografe as blindagens dos cabos, as chaves das placas, as conexões dos terminais e os módulos opcionais. Essa linha de base permite comparar e reverter todas as modificações posteriores.

Defina o que os operadores querem dizer com “disparo”

A palavra “disparo” pode descrever vários eventos diferentes. Uma aceleração até a velocidade máxima é diferente de um jog curto não intencional. Um movimento durante a inicialização é diferente de um movimento durante uma sequência automática. O caminho de diagnóstico muda de acordo com o evento exato.

Entreviste todas as pessoas que testemunharam a falha. Peça observações, não conclusões. “O encoder falhou” é uma conclusão. “O carro deslizante se moveu rapidamente na direção positiva enquanto a IHM mostrava velocidade zero” é uma observação.

Registre o eixo envolvido, a direção, a velocidade estimada, a duração, a posição inicial, o modo da máquina, o estado do spindle, a etapa ativa do programa e o método que interrompeu o movimento. Determine se o movimento começou a partir do repouso ou se se desenvolveu durante um movimento já em andamento.

Se o carro deslizante acelerar até a velocidade máxima, investigue a polaridade do feedback, as fontes ativas de referência, a sequência de habilitação e a regulação do acionamento. Se ele se mover apenas uma curta distância, investigue os bits de jog, os acionamentos duplicados por flanco, os comandos obsoletos e as transições de estado da sequência.

Se o evento ocorrer apenas no modo automático, a lógica da sequência se torna mais significativa. Se também ocorrer no modo manual, concentre-se na arbitragem de comandos compartilhada pelos dois modos. Se o eixo se mover durante a energização, a transição da CPU, o reset do inversor ou a reconexão da IHM, a inicialização na partida merece atenção imediata.

O comportamento da parada fornece evidências valiosas. Se a remoção do sinal de habilitação do inversor pelo CLP parar o eixo, o estágio de potência ainda pode estar respondendo ao caminho de habilitação esperado. Se o movimento continuar até que a alimentação principal seja isolada, investigue o hardware do inversor, a fiação de habilitação externa, o comportamento dos contatores e as fontes de comando externas ao CLP.

Determine também se o inversor gerou um aviso ou uma falha. Um evento sem falha não prova que o inversor estava em boas condições, mas sugere que ele pode ter considerado válidos o comando e o feedback.

Trate a máquina como uma cadeia de comando completa

O comando de movimento pode começar no painel de operação TP 170A. Um botão, uma entrada numérica, uma receita, um evento de tela ou uma sequência automática define um valor na memória do CLP. O S7-200 valida essa solicitação e calcula uma velocidade ou referência de movimento. Em seguida, uma rotina de comunicação USS monta um telegrama contendo dados de controle e de processo.

A unidade MASTERDRIVES recebe o telegrama e encaminha a palavra de controle e a referência por sua estrutura interna de sinais. O comando ativo final também pode incluir velocidades fixas, entradas analógicas, comandos por terminais, referências adicionais, entradas de jog ou blocos de funções internos.

O caminho de retorno é igualmente importante. O motor ou a carga pode usar um encoder incremental, um resolver, um tacômetro ou outro dispositivo de feedback. O inversor interpreta esse sinal como velocidade ou posição. Alguns valores reais podem então ser transmitidos ao CLP.

Chaves fim de curso mecânicas, sensores de origem, chaves de sobrepercurso, contatores, freios e contatos de inversor pronto criam caminhos adicionais. Cada caminho pode afetar o início, a continuidade ou a parada do movimento.

Cada etapa deve ter um valor mensurável. No CLP, registre a solicitação bruta da IHM, o modo de operação selecionado, o estado da sequência, a referência final validada, a direção, o comando de habilitação e o resultado da comunicação. No inversor, observe a palavra de controle recebida, a referência recebida, a referência interna ativa, a velocidade real, o status do feedback, a corrente, os avisos e as falhas.

Um zero exibido na IHM não prova que o CLP transmitiu zero. Um zero em um registro do CLP não prova que outra fonte de comando estava inativa. Um telegrama USS correto não prova que o inversor foi configurado para usar esse telegrama como sua única fonte de referência.

A investigação deve identificar o primeiro ponto em que o valor esperado e o valor registrado divergem. Esse ponto divide o problema entre a lógica da IHM, a aplicação do CLP, a comunicação, a configuração do inversor, o feedback, o hardware de potência ou a mecânica.

A divisão diagnóstica mais importante

A primeira pergunta técnica é simples: o acionamento recebeu um comando legítimo para se mover?

Compare quatro valores durante o evento:

• O setpoint final de movimento do CLP.
• O setpoint recebido pelo acionamento.
• O setpoint interno ativo do acionamento.
• O movimento real medido do motor ou do carro.

Se o setpoint final do CLP se tornar diferente de zero e o acionamento o seguir, o acionamento pode estar operando corretamente. O movimento indesejado foi gerado a montante. Investigue eventos da IHM, lógica de sequência, valores retidos, transições de modo e múltiplas gravações no comando final.

Se o setpoint final de movimento do CLP permanecer em zero, mas o acionamento receber um valor diferente de zero, investigue a construção do telegrama, o mapeamento de memória, o escalonamento, o gerenciamento do buffer e a execução do bloco de comunicação. O valor inesperado exato pode identificar o mecanismo. Um valor fixo repetido geralmente indica dados retidos ou obsoletos. Um valor positivo ou negativo extremo pode indicar um problema de número com sinal ou de ordem dos bytes.

Se o acionamento receber zero, mas seu setpoint interno ativo se tornar diferente de zero, examine a configuração do acionamento. Uma velocidade fixa, uma referência analógica, uma função de jog, uma entrada de terminal, um setpoint suplementar, um potenciômetro motorizado ou uma opção tecnológica pode estar ativa.

Se o setpoint do CLP, o setpoint recebido e o setpoint interno permanecerem todos em zero enquanto o motor acelera, o evento é mais grave. Investigue o comportamento da realimentação, a regulação do acionamento, a alimentação da placa de controle, o hardware do acionamento, o comportamento do estágio de saída e o acoplamento mecânico.

Este método de quatro sinais evita a substituição descontrolada de peças. Ele também cria uma conclusão técnica defensável. A falha é atribuída com base nas evidências registradas, e não em suposições.

A realimentação é uma suspeita prioritária, mas não uma conclusão automática

Uma falha intermitente no encoder ou no tacômetro é plausível, especialmente quando o evento muda com a vibração, a temperatura, o movimento do cabo ou a posição do carro. No entanto, a suposição de que qualquer perda de realimentação causa automaticamente velocidade máxima é ampla demais.

Um acionamento configurado corretamente normalmente deve detectar uma realimentação ausente ou implausível e responder de acordo com suas configurações de monitoramento e falha. A resposta exata depende da versão do controle, da opção de realimentação, da configuração e da aplicação.

Comportamentos perigosos ainda podem ocorrer quando o sinal de realimentação está presente, mas incorreto. Polaridade invertida, sequência de fases incorreta, amplitude instável do sinal, canais danificados, tipo de encoder incorreto, escalonamento inadequado, acoplamentos frouxos ou uma configuração inadequada do regulador podem fazer o acionamento reagir na direção errada.

Um cabo intermitente raramente falha como um circuito perfeitamente aberto. Um condutor pode se separar somente quando o cabo se dobra. Um pino do conector pode perder contato apenas durante vibração intensa. A alimentação do encoder pode cair quando um contator opera. A corrente da blindagem pode distorcer um canal diferencial sem remover completamente o sinal.

Compare a velocidade real informada pelo acionamento com uma medição independente. Um tacômetro portátil, um sensor temporário verificado ou uma medição adequada com osciloscópio pode determinar se o valor real interno corresponde ao movimento físico.

Se o acionamento informar velocidade zero enquanto o eixo gira, o caminho de realimentação é suspeito. Se o acionamento informar a velocidade correta enquanto o comando se tornar incorreto, a realimentação pode estar funcionando normalmente.

Nunca realize um teste de realimentação expondo pessoas a um carro em movimento. Use barreiras, velocidade reduzida, condições de teste controladas e um método independente de parada.

Inspecione todo o circuito de realimentação

Um sistema de realimentação inclui mais do que o encoder. O sensor, o acoplamento mecânico, o cabo, o conector, a alimentação, a blindagem, o sistema de aterramento, a placa de entrada e a configuração do acionamento contribuem para o valor medido.

Comece pela conexão mecânica. Confirme que o eixo do encoder, a correia, a engrenagem ou o acoplamento flexível não podem escorregar. Inspecione os cubos do acoplamento, as chavetas, os parafusos de fixação, rachaduras, contaminação e desalinhamento. Um encoder mecanicamente desconectado pode continuar produzindo um sinal que já não representa o movimento real da carga.

Inspecione todos os conectores sob boa iluminação e com ampliação. Procure contatos recuados, crimpagens fracas, pinos tortos, corrosão, contaminação por óleo, alívio de tensão quebrado e tensão no cabo. Confirme se os conectores de reposição usam o tipo correto de contato.

Teste a continuidade com a máquina isolada, mas não dependa apenas de um teste de resistência estática. Um condutor fraturado pode conduzir quando está reto e abrir quando é flexionado. Em um teste aprovado e de baixo risco, monitore o sinal de realimentação enquanto o porta-cabos percorre seu curso normal.

Meça a alimentação do encoder no próprio encoder sob carga de operação. Uma tensão estável dentro do gabinete não comprova que ela permanece estável no sensor. Registre o valor mínimo durante a aceleração do spindle, a reversão do eixo, a frenagem e a operação do contator.

Para um encoder incremental, verifique a amplitude dos canais, a simetria entre os canais, a relação de fase e o pulso de índice, se utilizado. Os pares diferenciais devem permanecer balanceados. Rajadas de ruído, pulsos ausentes ou amplitude em queda podem indicar problemas no cabo, na blindagem, na alimentação ou no sensor.

Verifique o tipo de encoder, a contagem de pulsos, a polaridade, o escalonamento e a fonte de realimentação no conjunto de parâmetros instalado no acionamento. Não presuma que um número de parâmetro de outro manual do MASTERDRIVES se aplica a esta placa de controle.

Erros do USS não devem ser reduzidos a mudanças aleatórias de bits

A comunicação USS opera por meio de um telegrama estruturado. O protocolo inclui verificação de erros, portanto um telegrama danificado normalmente deve ser rejeitado, em vez de ser aceito como um setpoint de velocidade válido não relacionado.

Isso não significa que o USS possa ser ignorado. Problemas de comunicação ainda podem contribuir para um movimento descontrolado devido ao comportamento da aplicação. O CLP pode formar a palavra errada de dados de processo. Um valor com sinal pode ser interpretado incorretamente. Os bytes alto e baixo podem ser trocados. Dados antigos podem permanecer em um buffer de transmissão. Uma resposta ausente pode deixar o setpoint anterior ativo.

Endereços de escravo duplicados também podem causar um comportamento confuso. Cada inversor na rede deve usar um endereço exclusivo. A sequência de consulta do CLP deve associar cada resposta ao escravo correto e à área de memória correta.

A palavra de controle merece a mesma atenção que o setpoint de velocidade. Um inversor pode permanecer habilitado enquanto o programa do CLP presume que ele foi parado. O reconhecimento de falhas, os comandos LIGA/DESLIGA, os bits de direção e a lógica de reinicialização podem ser processados incorretamente durante a recuperação da comunicação.

Conte as transações bem-sucedidas, os tempos limite, os quadros rejeitados, as falhas consecutivas e os eventos de recuperação. Um único bit de “falha de comunicação” fornece informações insuficientes. Os dados de diagnóstico devem identificar qual escravo estava sendo consultado e qual transação falhou.

No MICROMASTER 440, P2010 está relacionado à configuração da taxa de transmissão USS. Ele não deve ser tratado como um ajuste geral do tempo limite do telegrama. P2011 é comumente associado ao endereço USS. Ainda assim, todos os significados dos parâmetros devem ser verificados no manual correto do MM440 e na configuração da interface.

Um tempo limite maior não é automaticamente mais seguro. Se o inversor continuar usando um setpoint diferente de zero anterior enquanto aguarda o tempo limite, aumentar esse atraso pode prolongar um movimento indesejado. Primeiro defina a resposta necessária à perda de comunicação.

A camada física da RS-485 ainda é importante

Mesmo quando os quadros corrompidos são rejeitados, uma rede RS-485 instável pode causar novas tentativas repetidas, dados desatualizados, atualizações de status perdidas e temporização irregular da aplicação. Portanto, a rede física exige uma auditoria completa.

Documente o barramento da porta de comunicação do S7-200 até cada inversor. Confirme se a fiação usa uma topologia de linha adequada. Derivações longas em estrela podem criar reflexões e devem ser evitadas, a menos que a documentação da interface instalada permita explicitamente seu uso.

Verifique se todos os dispositivos usam configurações de comunicação compatíveis. Elas incluem taxa de transmissão, paridade, estrutura do telegrama, comprimento dos dados de processo e endereço do escravo. Registre as configurações em vez de alterá-las de memória.

A terminação deve seguir os requisitos das interfaces e dos conectores Siemens reais. Um resistor genérico de 120 ohms não deve ser adicionado automaticamente. A terminação ou polarização incorreta pode piorar o sinal.

Inspecione o tipo de cabo de comunicação, a continuidade da blindagem, a ligação dos conectores e o roteamento. O cabo RS-485 não deve percorrer longas distâncias ao lado de cabos de saída de motores, condutores de resistores de frenagem, cabos de contatores ou outros circuitos de potência de alta frequência.

Quando a separação for limitada, cruze os cabos de potência e de sinal aproximadamente em ângulos retos. Mantenha uma ligação equipotencial planejada entre os painéis e as seções da máquina. Evite longas derivações de blindagem, que reduzem a eficácia em alta frequência.

Quando necessário, use uma ponta de prova diferencial adequada de osciloscópio para inspecionar a forma de onda. Procure reflexões, tensão de modo comum excessiva, oscilações, bordas lentas, rajadas de ruído e alterações de amplitude durante a aceleração do fuso ou a frenagem do eixo.

Um notebook conectado ou um conversor USB pode alterar o aterramento e a carga do barramento. Registre se a falha muda quando o equipamento de diagnóstico é conectado.

Os componentes usados em comunicação e redes industriais devem ser avaliados juntamente com a topologia, a blindagem, a terminação, o endereçamento e o tratamento de transações do CLP. Substituir um conector não corrigirá uma máquina de estados de comunicação instável.

Revise o programa do S7-200 como uma máquina de estados

Falhas intermitentes de comissionamento costumam aparecer durante transições, e não durante a operação estável. A máquina pode funcionar corretamente enquanto opera continuamente, mas falhar ao alternar entre o modo manual e automático, concluir o homing, se recuperar de um alarme, mudar uma receita ou restaurar a comunicação.

Pesquise na referência cruzada do programa todas as instruções que gravam nas variáveis finais de velocidade, direção e habilitação. Programas antigos costumam gravar na mesma palavra de memória V em várias redes. A última gravação executada controla o resultado, o que pode produzir um comportamento que parece aleatório.

Crie um único estágio claro de arbitragem de comandos. Jog manual, movimento automático, homing, funções de configuração e comandos de manutenção devem entrar nesse estágio como solicitações separadas. O setpoint final só deve ser gerado após a validação do modo, dos limites, do feedback, da comunicação e das permissivas de segurança.

Revise a lógica de pulso único e de detecção de borda. Um comando destinado a durar apenas um ciclo de varredura pode permanecer ativo porque sua memória de borda foi reutilizada, retida ou sobrescrita. Um comando também pode ser disparado novamente quando um bit de modo muda.

Examine cada trava. Identifique a condição que a ativa e todas as condições que a redefinem. Uma trava de movimento que depende apenas de uma etapa posterior da sequência pode permanecer ativa quando a sequência é interrompida por uma falha.

Verifique o tratamento de dados com sinal. Um inteiro negativo interpretado como uma palavra sem sinal pode se tornar um valor positivo grande. A multiplicação pode causar overflow. Uma palavra copiada na ordem de bytes incorreta pode criar um setpoint extremo.

Verifique a conversão das unidades de engenharia para o valor de processo USS. Aplique os limites positivo e negativo após o cálculo final, não apenas na entrada da IHM.

Os sistemas de controle Siemens SIMATIC S7 legados podem operar de forma confiável por décadas, mas suas aplicações frequentemente contêm modificações de várias etapas de comissionamento. Uma revisão estruturada de referências cruzadas é mais valiosa do que presumir que o hardware da CPU ficou instável.

Os Estados de Inicialização e Recuperação Precisam de Testes Separados

Dados não inicializados ou retentivos podem criar movimentos raros após interrupções de energia, downloads de software, transições da CPU de STOP para RUN, resets do inversor ou reconexões da IHM.

Identifique todas as áreas de memória retentiva usadas pelo programa de movimento. Determine o valor inicial do comando de velocidade, da direção, da habilitação, do modo, da etapa da sequência, dos bits de avanço e do status da comunicação após cada tipo de reinicialização.

A rotina de inicialização deve forçar todas as solicitações de movimento para zero. Ela deve limpar comandos pendentes de avanço e automáticos, validar o feedback, confirmar o estado dos limites, estabelecer a comunicação e exigir uma nova sequência deliberada de habilitação.

Um setpoint não nulo retentivo nunca deve se tornar efetivo simplesmente porque o inversor fica pronto antes de o CLP concluir a inicialização.

Teste a partida a frio, a reinicialização a quente, a transição da CPU de STOP para RUN, o reset do inversor, a reconexão da IHM e a restauração de um escravo USS que tenha falhado. Realize esses testes com a máquina sob controle mecânico e com a velocidade disponível reduzida.

Monitore a alimentação de controle de 24 V durante eventos de energização. O CLP, o encoder, a IHM, a interface de comunicação, os contatores e os circuitos eletrônicos de controle do inversor podem reiniciar em diferentes limiares de tensão. Uma breve queda de tensão pode deixar um dispositivo funcionando enquanto outro reinicia.

Registre a sequência de alimentação de controle, CLP em RUN, comunicação saudável, inversor pronto, liberação do freio e habilitação do movimento. Essa ordem deve ser explícita e repetível.

A IHM Pode Produzir Comandos Que Já Não Estão Visíveis

O projeto do TP 170A deve ser revisado junto com o programa do CLP. Um comando da IHM pode ser escrito durante o pressionamento do botão, ao soltar o botão, na abertura ou no fechamento da tela, no download de uma receita, na atualização de uma tag ou na recuperação da comunicação.

Um botão de avanço momentâneo pode criar uma condição perigosa quando a ação de pressionar define um bit e a ação de soltar o limpa. Se a comunicação falhar enquanto o botão estiver pressionado, o comando de limpeza pode nunca chegar ao CLP.

Mais tarde, o operador vê um botão não pressionado, mas o bit do CLP permanece ativo. Outra transição de modo ou condição permissiva pode então permitir que a solicitação de jog obsoleta chegue ao comando final de movimento.

Uma função de jog robusta não deve depender apenas de um par de pressionar e soltar. O CLP deve exigir a atualização contínua do comando, aplicar um curto tempo de expiração, validar o modo de operação e remover o comando quando a comunicação se tornar inválida.

Verifique todos os eventos da IHM associados a jog, entrada de velocidade, direção, reset, seleção de modo, referenciamento e controle de ciclo automático. Procure tags duplicadas apontando para o mesmo endereço do CLP.

As entradas numéricas exigem verificação de faixa tanto no painel quanto no CLP. O CLP deve rejeitar valores fora da faixa de engenharia permitida, mesmo quando o campo da IHM parece estar configurado corretamente.

Os sistemas Siemens SIMATIC HMI legados podem conter comportamentos no nível da tela que não são visíveis na lógica do CLP. Registrar a tag bruta da IHM separadamente do comando validado pelo CLP ajuda a identificar a verdadeira origem do comando.

O MM440 pode influenciar o evento sem controlar o carro

O MICROMASTER 440 controla o fuso, mas ainda pode influenciar o ambiente de controle do carro. Seu retificador de entrada, elo CC, saída do motor, circuito de frenagem e frequência de comutação podem criar interferência conduzida ou irradiada.

A perturbação mais forte pode ocorrer durante a aceleração, desaceleração, picos de corrente ou frenagem do fuso, e não durante a operação estável. Compare os registros de data e hora dos movimentos descontrolados com o estado do fuso.

Registre a partida e a parada do fuso, a alteração de velocidade, a corrente, a condição do barramento CC, o histórico de falhas e a atividade de frenagem. Determine se cada evento ocorre durante uma transição semelhante do fuso.

Se as unidades MM440 e MASTERDRIVES compartilharem o barramento USS, o fuso também afetará o tempo da comunicação. O CLP deve consultar cada escravo de forma previsível e processar cada resposta na estrutura de memória correta.

Verifique se as áreas de dados USS do fuso e do carro não se sobrepõem. Aplicações compactas com S7-200 às vezes reutilizam a memória V sem uma separação clara. Um bloco escrito para o fuso pode sobrescrever parte do comando do carro.

Mover o MM440 para fora do gabinete não elimina completamente sua influência. Os cabos do motor, os caminhos de aterramento, o roteamento da comunicação e as fontes de alimentação compartilhadas podem continuar conectados.

Use medições em vez de realocações repetidas. Examine a separação dos cabos, a conexão das blindagens, os reatores de linha ou filtros especificados para o inversor, a equipotencialização do gabinete, a terminação do cabo do motor e a relação temporal entre os eventos de comutação e os erros de comunicação.

Auditar o MASTERDRIVES por função do sinal

Uma auditoria dos parâmetros do MASTERDRIVES deve seguir todo o caminho do sinal. Não comece com uma lista de números de parâmetros copiada de outra instalação.

Primeiro, verifique a versão do controle instalado, a versão do software, a placa de controle e a opção de feedback. Em seguida, revise o modo de controle, os dados do motor, o tipo de feedback, a escala do feedback e a fonte do feedback.

Identifique todas as fontes que podem controlar os comandos LIGA/DESLIGA do inversor. Elas podem incluir palavras de controle USS, entradas de terminal, comandos fixos, conexões internas de binector ou funções tecnológicas.

Identifique todas as fontes que podem contribuir para o valor de referência final de velocidade ou posição. Verifique o valor de referência principal, os valores de referência suplementares, as velocidades fixas, as funções de jog, as entradas analógicas, as funções de potenciômetro motorizado e os blocos de função internos.

Revise os limites de velocidade positiva e negativa, as rampas de aceleração, as rampas de desaceleração, os limites de corrente, os limites de torque e as restrições de direção. Configurações temporárias conservadoras podem reduzir o risco do diagnóstico, mas não constituem uma proteção de segurança independente.

Examine o monitoramento do feedback e a resposta a falhas. Determine o que o inversor está configurado para fazer quando o feedback ficar ausente, instável, invertido ou implausível.

Leia o histórico de avisos e falhas do inversor antes de limpá-lo. Um aviso que pareça não relacionado pode registrar o momento em que a condição de controle mudou.

Use o método de engenharia instalado, como o DriveMonitor, a PMU, o OP1S ou outra interface aprovada, para observar os conectores internos e os valores reais. Selecione os valores de acordo com a versão específica do controle.

Essa abordagem funcional se aplica a sistemas legados e atuais de acionamento e controle de movimento da Siemens. O software de controle, as opções de feedback e o roteamento interno podem variar mesmo quando dois inversores parecem fisicamente semelhantes.

Crie um gravador de eventos disparado

Um evento que ocorre uma vez por dia não pode ser solucionado observando a IHM continuamente. O sistema precisa de um gravador de diagnóstico que capture o período antes e depois do movimento anormal.

Crie um buffer circular no CLP contendo o comando bruto da IHM, o comando validado, o valor de referência final de velocidade, a direção, a habilitação, o modo, o estado da sequência, as entradas de limite, o status de inversor pronto, o resultado da transação USS e um contador de amostras.

No inversor, capture a palavra de controle recebida, o valor de referência recebido, o valor de referência interno ativo, a velocidade real, o status do feedback, a corrente de saída, a corrente que produz torque, quando disponível, os avisos e as falhas.

O disparo pode se basear em uma velocidade real acima de um pequeno limite enquanto o comando final do CLP é zero. Outro disparo pode detectar movimento fora de um estado de sequência aprovado. Uma divergência entre a direção comandada e a medida também pode disparar o registro.

Preserve os dados anteriores ao disparo. Se o registro começar somente depois que a corrediça tiver se movido, a condição que iniciou o evento pode já ter desaparecido.

O diagnóstico de comunicação deve distinguir transações bem-sucedidas, respostas não recebidas, mensagens rejeitadas, falhas consecutivas e eventos de recuperação. Registre qual escravo estava ativo durante o erro.

Mantenha a lógica de diagnóstico compacta. O S7-200 tem memória e capacidade de varredura limitadas. Confirme que o registro não interfere no tempo das rotinas USS existentes.

Exporte os dados após cada evento. Armazene-os com a data, o estado da máquina, o relatório da testemunha e quaisquer observações físicas. Uma sequência de vários eventos pode revelar um padrão que um único evento não revelaria.

Use contadores de diagnóstico que respondam a perguntas específicas

Os contadores só são úteis quando seu significado é claro. Um contador geral de comandos e um contador geral de realimentação podem divergir por vários motivos normais.

Conte cada solicitação de movimento aceita pela IHM. Conte cada comando de movimento aceito pela arbitragem final do CLP. Conte cada transmissão USS concluída com sucesso. Conte cada resposta válida recebida do acionamento do eixo.

Conte também os tempos limite de comunicação, os eventos de acionamento não pronto, as ativações de limite, as mudanças de modo e as expirações de comandos.

Armazene o último valor de velocidade transmitido e a palavra de controle. Armazene o último valor real válido recebido e a palavra de status. Adicione um número de sequência à estrutura de comandos quando for viável.

Quando ocorre um evento, os contadores podem responder a várias perguntas:

• A IHM gerou uma solicitação?
• O CLP aprovou essa solicitação?
• O CLP transmitiu um novo telegrama?
• O acionamento retornou uma resposta válida?
• O movimento real começou sem um novo comando aprovado?

Um contador não deve ser redefinido automaticamente a cada inicialização, a menos que seu valor histórico seja desnecessário. Considere salvar um contador de eventos em memória retentiva e, ao mesmo tempo, forçar todos os comandos de movimento a um valor seguro de inicialização.

A proteção independente contra sobrecurso não pode depender da lógica normal

Os limites de posição do software são valiosos, mas não podem ser a única defesa contra uma falha que pode ter origem no programa do CLP, no caminho de comunicação ou no controlador normal do acionamento.

Cada eixo deve ter uma proteção de fim de curso projetada adequadamente. Dependendo da avaliação de risco da máquina, isso pode incluir chaves de limite cabeadas, sensores de posição com classificação de segurança, relés de segurança, circuitos de inibição do acionamento, contatores, freios ou outra arquitetura validada.

Uma entrada padrão do CLP que escreve um comando de velocidade zero não é automaticamente uma função de segurança. A mesma falha lógica que criou o movimento pode impedir que esse comando de parada seja processado.

Remover a referência de velocidade também não garante a remoção do torque. O acionamento pode permanecer habilitado, uma referência secundária pode continuar ativa ou a energia mecânica armazenada pode continuar movimentando a carga.

Teste separadamente a parada de emergência, os intertravamentos das proteções, os interruptores de sobrecurso, os contatos de falha do acionamento, os freios e os contatores. Confirme que a reinicialização exige uma ação deliberada após a atuação da proteção.

Durante a execução de diagnósticos, reduza a velocidade máxima, a aceleração, o torque e o curso disponível sempre que for tecnicamente possível. Batentes mecânicos temporários só devem ser usados quando forem projetados para a possível energia de impacto.

Nenhum objetivo de diagnóstico justifica expor uma pessoa a um eixo que já demonstrou movimento descontrolado.

Exemplo de caso: um cabo que falha somente durante a reversão

Considere um carro que se comporta normalmente durante testes estáticos lentos, mas se move violentamente durante uma reversão rápida de direção. O registro do CLP mostra um comando estável. O traço do acionamento mostra uma perturbação repentina na velocidade medida, seguida de uma grande saída de correção.

Um teste de continuidade no cabo do encoder é aprovado enquanto a máquina está parada. O cabo, porém, passa por uma esteira móvel. Um condutor está rompido próximo ao raio mínimo de curvatura e abre somente quando a esteira chega a uma determinada posição.

Uma medição com osciloscópio na entrada do acionamento mostra um canal do encoder colapsando durante a reversão. O comando permanece correto, e nenhuma falha USS é registrada.

O cabo é substituído pelo tipo correto para flexão contínua. O alívio de tensão e a terminação da blindagem são restaurados. A alimentação do encoder e a qualidade da forma de onda são testadas durante todo o percurso do carro.

A verificação final inclui reversões repetidas em velocidade reduzida, seguidas de operação controlada na velocidade normal de produção. Uma nova forma de onda íntegra é armazenada como referência.

Este caso mostra por que uma falha de realimentação deve ser comprovada dinamicamente. Um teste estático de resistência pode ser aprovado mesmo quando o cabo falha durante o serviço.

Exemplo de caso: um comando de avanço persiste após a perda de comunicação com a IHM

Em outra máquina, pressionar um botão de avanço define um bit do CLP. Soltar o botão o limpa. A IHM perde a comunicação enquanto o botão permanece pressionado, portanto o comando de liberação nunca chega ao CLP.

Naquele momento, outro intertravamento impede o movimento. O bit de avanço obsoleto permanece oculto. Mais tarde, o operador muda o modo da máquina. A lógica final do CLP agora aceita a solicitação de avanço antiga, e o carro se move inesperadamente.

O acionamento segue um setpoint legítimo do CLP. A comunicação USS está íntegra quando o movimento começa. Substituir o encoder ou adicionar outra conexão de blindagem não corrigirá o problema.

A lógica revisada do CLP exige uma solicitação de avanço contínuo e atualizada. O comando expira após um curto intervalo. Ele só é aceito no modo correto, com comunicação válida e a condição de habilitação necessária.

A lógica de inicialização limpa todas as solicitações de movimento. A ação de liberação da IHM permanece, mas já não é o único mecanismo que remove o comando.

O registrador de eventos confirma que o bit bruto da IHM permaneceu ativo após a falha de comunicação anterior. A causa raiz não foi corrupção da comunicação. Foi o tratamento inseguro de um comando válido, porém obsoleto.

Exemplo de caso: o ruído expõe um tratamento frágil do buffer USS

Uma terceira máquina apresenta tempos limite do USS quando o fuso acelera. Telegramas danificados são rejeitados, portanto a rede não converte diretamente um comando de velocidade em outro.

No entanto, a aplicação do CLP não invalida o comando anterior do eixo após uma transação não recebida. A rotina USS também é executada condicionalmente, criando intervalos irregulares de consulta.

Durante uma transição de sequência, o novo comando zero é gravado em um local da memória enquanto o buffer de transmissão ainda contém um valor não zero mais antigo. O próximo telegrama bem-sucedido envia dados válidos, porém obsoletos.

O inversor recebe um comando estruturado corretamente e responde normalmente. A perturbação na camada física revelou uma fragilidade do software, em vez de gerar diretamente o valor de referência.

A ação corretiva melhora o roteamento dos cabos e a conexão da blindagem. Em seguida, a rotina de comunicação do CLP é reprojetada para que cada inversor use uma memória dedicada. O valor de referência final validado é copiado para o buffer de transmissão imediatamente antes da transação.

Uma resposta não recebida marca os dados como inválidos. A resposta programada à perda de comunicação é verificada por meio de testes controlados.

Este caso demonstra por que a solução de problemas de comunicação deve abranger tanto a forma de onda elétrica quanto o ciclo de vida dos dados da aplicação.

Uma sequência prática de investigação no local

Etapa 1: Proteja a máquina. Estabeleça proteção independente contra sobrecurso, reduza a energia de teste e restrinja o acesso de pessoas.

Etapa 2: Confirme o hardware. Registre os números de pedido completos, as versões de software, as placas opcionais, os dispositivos de feedback e os módulos de interface.

Etapa 3: Crie backups. Salve o programa do S7-200, o projeto do TP 170A, o conjunto de parâmetros do MASTERDRIVES e os parâmetros do MM440.

Etapa 4: Defina o evento. Registre a direção, a velocidade, a duração, o modo de operação, a posição, o estado do fuso e o comportamento de parada.

Etapa 5: Mapeie a cadeia de comandos. Identifique cada fonte de referência de ajuste, habilitação, direção, velocidade fixa, jog e referência suplementar.

Etapa 6: Adicione registros sincronizados. Capture comandos do CLP, dados USS, valores internos do inversor, feedback, corrente, limites, avisos e falhas.

Etapa 7: Teste os estados de inicialização. Examine a inicialização a frio, a reinicialização a quente, as transições de EXECUÇÃO da CPU, a reconexão da IHM e a recuperação da comunicação.

Etapa 8: Inspecione o feedback dinamicamente. Teste a tensão de alimentação, a qualidade da forma de onda, o acoplamento, os conectores, a blindagem e a flexão dos cabos.

Etapa 9: Audite o USS e o RS-485. Verifique o endereçamento, a topologia, a terminação, as áreas de dados, o temporizamento e o tratamento de erros.

Etapa 10: Revise as referências cruzadas do CLP. Encontre cada elemento que grava no setpoint final, na direção e na habilitação do inversor.

Etapa 11: Audite o roteamento dos sinais do inversor. Verifique cada fonte de comando e cada elemento que contribui para o setpoint ativo.

Etapa 12: Altere um item por vez. Registre o estado anterior, o novo estado, o motivo, o resultado do teste e o método de reversão.

O reforço de longo prazo deve abordar a arquitetura

Depois de encontrar a causa imediata, pergunte por que uma única falha poderia produzir um movimento capaz de causar danos. Um único tempo limite de comunicação, rompimento de cabo ou erro da IHM não deve ignorar todas as camadas de proteção.

Separe a geração do comando, a validação do comando, o transporte da comunicação, o controle do inversor e a proteção de segurança. Cada camada deve ter uma responsabilidade definida.

O CLP deve gerar um comando limitado e validado quanto ao estado. A rotina de comunicação deve transmitir dados atuais, com validade e atualização claramente definidas. O inversor deve aplicar os limites operacionais configurados e o monitoramento da realimentação. Funções de segurança independentes devem controlar o movimento perigoso.

Considere se a arquitetura S7-200 e USS continua tendo suporte. A migração para uma plataforma mais nova de CLP e inversor pode melhorar os diagnósticos, a marcação de tempo, a disponibilidade de componentes, a visibilidade da rede e o gerenciamento de backups.

Uma rede mais nova não torna automaticamente uma máquina segura. O PROFINET, por si só, não corrige uma arbitragem fraca de comandos, uma lógica de inicialização inadequada ou uma proteção insuficiente contra sobrecurso.

A modernização deve incluir a IHM, os desenhos, o controle de versões do software, a arquitetura de segurança, a estratégia de peças sobressalentes e o treinamento da equipe. Substituir apenas o CLP pode transferir o problema para outra plataforma.

Para aplicações de posicionamento exigentes, avalie se o perfil de movimento deve ser executado dentro de um inversor dedicado ou controlador de movimento, em vez de usar comandos seriais de velocidade repetidos. A decisão correta depende da precisão de posicionamento, sincronização, tempo de ciclo, arquitetura de realimentação e risco da máquina.

A verificação é mais do que esperar que a falha retorne

Sete dias sem incidentes são um sinal positivo, mas não provam que a causa raiz foi eliminada. A verificação deve reproduzir deliberadamente as condições que anteriormente aumentaram o risco.

Execute ciclos repetidos de curso completo em velocidade controlada. Inclua reversões rápidas, aceleração do fuso, frenagem do fuso, condições de gabinete aquecido, carga normal máxima e movimento da esteira porta-cabos.

Repita os testes de inicialização e recuperação. Faça ciclos na alimentação de controle de acordo com um procedimento aprovado. Teste a transição de STOP para RUN da CPU, a redefinição do inversor, a reconexão da IHM, a perda de um escravo USS e a restauração da comunicação.

Verifique a resposta à falha de realimentação usando um método de teste aprovado. Não desconecte um encoder de produção enquanto houver pessoas expostas ao movimento.

Teste cada limite de hardware, limite de software, entrada de falha do inversor, parada de emergência, freio e dispositivo independente de sobrecurso. Confirme a resposta de parada exigida e o comportamento na reinicialização.

Compare o comando final do PLC, o comando recebido pelo inversor, o setpoint interno ativo e o movimento real durante todos os testes.

Defina os critérios de aceitação antes dos testes. Os critérios adequados podem incluir:

• Nenhum movimento não intencional durante qualquer condição de inicialização ou recuperação.
• Nenhuma falha de comunicação USS sem tratamento.
• Nenhum comando de movimento retido após a perda de comunicação com a IHM.
• Alimentação e forma de onda da realimentação estáveis durante todo o curso.
• Operação correta de cada dispositivo independente de sobrecurso.
• Concordância registrada entre o comando, o setpoint recebido, o setpoint ativo e o movimento real.

Mantenha o registrador de eventos durante a fase inicial de operação da produção. Uma ação corretiva bem-sucedida deve eliminar tanto o sintoma físico quanto o padrão de diagnóstico anormal que o causou.

A causa raiz aparecerá onde os sinais divergirem pela primeira vez

A aceleração descontrolada intermitente do carro em um sistema Siemens S7-200 e MASTERDRIVES não deve ser atribuída a “ruído”, ao “encoder” ou ao “USS” sem evidências.

O método decisivo é correlacionar o comando final do PLC, o comando recebido pelo inversor, o setpoint interno ativo e a resposta mecânica real.

Se o comando do PLC se tornar incorreto, investigue a IHM e a lógica da aplicação. Se o valor transmitido ou recebido se tornar incorreto, investigue o tratamento da memória, o escalonamento, a construção do telegrama e a rede RS-485.

Se o inversor ativar uma fonte de comando que o PLC não pretendia usar, audite a configuração interna do inversor. Se todos os comandos permanecerem seguros enquanto o motor acelera, investigue a realimentação, a alimentação da placa de controle, o hardware do inversor e a mecânica.

As falhas de realimentação continuam sendo plausíveis, mas devem ser testadas como circuitos completos. Os problemas de USS continuam sendo plausíveis, mas dados válidos obsoletos e uma lógica de recuperação fraca costumam ser mais prováveis do que um telegrama danificado aleatoriamente se tornar um comando válido de velocidade máxima.

A máquina só deve retornar à operação normal depois que a proteção independente estiver efetiva, o mecanismo iniciador estiver respaldado por evidências registradas e os testes controlados tiverem verificado tanto a ação corretiva quanto a resposta a falhas futuras.

Essa abordagem disciplinada exige mais preparação do que a substituição especulativa de componentes. Ela também produz um resultado mais valioso: uma máquina cujo trajeto de movimento é compreendido, registrado, documentado e protegido contra a próxima falha isolada.