“Sem comunicação” não é um diagnóstico
Na manutenção industrial, frases como “o inversor não comunica”, “o CLP perdeu o drive” ou “a IHM não enxerga o acionamento” parecem descrever o mesmo problema.
Nem sempre descrevem.
Um drive pode estar sem link físico. Pode ter link, mas estar com endereço ou identidade incompatível com o projeto. Pode aparecer na rede, mas não estabelecer a conexão cíclica de I/O. Pode trocar dados e ainda assim interpretar palavras diferentes das esperadas pelo controlador. Pode até transmitir status normalmente e, mesmo assim, não aceitar partida ou referência porque a arquitetura não concedeu ao barramento a autoridade de controle.
Por isso, a pergunta mais útil não é:
“Qual equipamento está com defeito?”
A pergunta inicial é:
“Em qual camada da comunicação a cadeia deixou de funcionar?”
Essa mudança de raciocínio reduz tentativas aleatórias de reset, troca de hardware e alteração de parâmetros antes que o problema esteja localizado.
Nota institucional: a Adler do Brasil atua como empresa independente e multimarcas. A menção a fabricantes, protocolos e marcas possui finalidade exclusivamente técnica e descritiva, não implicando representação, autorização ou vínculo oficial.
Comece pelo mapa da arquitetura, não pelo parâmetro
Antes de investigar uma configuração específica, é importante entender quem deveria conversar com quem.
Uma arquitetura simples pode seguir a lógica:
CLP → drive
Mas outras instalações incluem:
IHM → CLP → drive
ou:
IHM → drive
Também podem existir switches industriais, gateways, redes separadas, remotas de I/O, SCADA e outros intermediários.
Essa diferença muda completamente o diagnóstico.
Se o CLP recebe dados válidos e atualizados do drive, mas a IHM exibe valores congelados, o problema pode estar no caminho entre IHM e CLP. Um valor ainda visível na memória ou na tela não comprova uma leitura recente. A arquitetura e os diagnósticos disponíveis precisam permitir distinguir dado atual de último valor retido.
O primeiro passo conceitual, portanto, é identificar:
- quais equipamentos participam da comunicação;
- qual protocolo deveria existir em cada trecho;
- quem é controller/client e quem é device/server/adaptador naquela arquitetura;
- quais dados deveriam circular;
- por qual caminho comandos e status deveriam passar.
Sem esse mapa, um sintoma na tela pode levar a uma intervenção no equipamento errado.
As camadas abaixo organizam o raciocínio; não são um procedimento de alteração da rede nem uma sequência rígida que substitui os diagnósticos da aplicação.
Camada 1: existe link de rede de verdade?
A primeira separação é entre ausência de link e falha de comunicação de aplicação.
Documentação de fabricantes mostra que interfaces industriais normalmente oferecem diagnósticos próprios para distinguir estados físicos e lógicos. No PowerFlex 525, por exemplo, a Rockwell Automation diferencia informações de link da condição de comunicação EtherNet/IP do adaptador.
Isso revela um princípio importante:
LED de link aceso não significa que o CLP esteja trocando I/O corretamente com o drive.
O link indica uma conexão no trecho observado. Não comprova a integridade de todo o caminho até o controlador nem que a aplicação esteja trocando dados válidos. O significado dos LEDs deve ser consultado no manual da interface específica.
A conexão de aplicação depende de outros elementos: identificação, protocolo, configuração do projeto, controller, estruturas de I/O e estado do equipamento.
Da mesma forma, ausência de link não deve ser confundida com erro de telegrama ou de programação do CLP. São níveis diferentes do problema.
A inspeção física de cabos, conectores, alimentação de interfaces e equipamentos de rede deve respeitar os procedimentos de segurança aplicáveis. Este artigo não orienta intervenção em circuitos ou painéis energizados.
Camada 2: o controller está procurando o dispositivo certo?
Quando o meio físico parece disponível, a próxima pergunta é sobre identidade e endereçamento.
Em redes EtherNet/IP, documentação da Rockwell registra situações como endereço IP duplicado e configuração de rede inválida. Já em PROFINET existe outro elemento fundamental: o device name.
No comissionamento PROFINET descrito pela PROFIBUS & PROFINET International, o nome de dispositivo permite ao controller identificar o device esperado pelo projeto e estabelecer a comunicação configurada. Isso não significa que um equipamento sem nome seja invisível a toda ferramenta de descoberta. A Siemens apresenta esse papel da identidade na integração S7/SINAMICS G120; atribuição inicial ou automática depende dos recursos e da topologia suportados.
Isso evita uma simplificação comum:
“Se está na mesma rede IP, deveria funcionar.”
Não necessariamente.
A identidade esperada pelo projeto pode envolver IP, nome de estação, mecanismos de atribuição e parâmetros próprios do protocolo e do equipamento.
Por isso, alterar IP, máscara, gateway ou device name sem conhecer a topologia pode transformar uma falha localizada em um problema maior — inclusive criando colisões ou fazendo o projeto procurar um dispositivo que deixou de ter a identidade esperada.
Camada 3: Ethernet não é um protocolo único
Outra fonte frequente de confusão é tratar a porta física como se ela definisse a comunicação.
PROFINET, EtherNet/IP e Modbus TCP podem compartilhar Ethernet como infraestrutura, mas não são protocolos intercambiáveis.
A documentação dos próprios fabricantes deixa isso claro.
A WEG, por exemplo, possui módulos e configurações específicos para EtherNet/IP, Modbus TCP e PROFINET IO em determinadas famílias. A Yaskawa oferece opções distintas de comunicação para protocolos diferentes. Na linha ACS880, a ABB também utiliza adaptadores específicos para diferentes fieldbuses industriais.
Portanto:
“Tem RJ45” ou “tem Ethernet” não significa “fala o protocolo que meu CLP espera”.
Além do protocolo, ainda podem importar:
- módulo ou adaptador instalado;
- família e versão do equipamento;
- firmware suportado;
- arquivo de descrição/configuração utilizado no projeto;
- recursos disponíveis naquela combinação específica.
Essa é uma das razões pelas quais trocar um drive por outro fisicamente semelhante nem sempre restaura a comunicação automaticamente.
Camada 4: o CLP encontrou o drive ou estabeleceu a troca de I/O?
Depois que o equipamento aparece na rede, ainda existe outra distinção importante.
Ser visível na rede não é o mesmo que estar integrado ao processo de controle.
No EtherNet/IP, a ODVA diferencia mensagens explícitas e conexões implícitas utilizadas para I/O. A documentação do PowerFlex 525 também mostra situações em que a interface está conectada à rede, mas o drive não está efetivamente sendo controlado por Ethernet porque a configuração ou o estado do controller não estabeleceu a troca esperada.
Uma consulta explícita bem-sucedida não comprova que a conexão de I/O usada pelo projeto esteja ativa. Já em Modbus TCP, o raciocínio é de requisições e respostas de aplicação, como leitura de registradores; não se deve transportar para ele, como regra universal, o modelo de assemblies ou telegramas de outros protocolos. O diagnóstico deve identificar qual troca o projeto realmente espera.
Em PROFINET, o dispositivo também precisa estar corretamente integrado ao projeto, com configuração coerente para que os dados cíclicos sejam trocados como previsto.
Na prática, vale separar quatro estados:
- o dispositivo não aparece na rede;
- aparece, mas a conexão de I/O não estabelece;
- a conexão estabelece, mas os dados não correspondem ao esperado;
- os dados chegam, mas o drive não executa o comando.
Chamar todos esses cenários de “falha de comunicação” esconde justamente a informação que mais ajuda no diagnóstico.
Camada 5: os dois lados concordam sobre o significado dos dados?
Mesmo com a conexão ativa, controlador e drive precisam concordar sobre quais dados estão sendo trocados e o que cada posição significa.
Dependendo do fabricante e do protocolo, isso pode envolver:
- telegramas;
- assemblies;
- palavras de comando e status;
- perfis de acionamento;
- mapeamento de entradas e saídas cíclicas;
- quantidade e ordem de bytes ou palavras;
- parâmetros selecionados para troca de dados.
A Schneider Electric documenta, por exemplo, perfis, telegramas e mapeamento cíclico em suas interfaces PROFINET. Em EtherNet/IP, assemblies definem estruturas usadas nas conexões de I/O. A WEG também documenta dados cíclicos, parâmetros de rede e fontes de comando conforme família e protocolo.
Uma consequência prática é importante:
a conexão pode estar online e, ainda assim, o significado dos dados estar errado.
Um valor inesperado na IHM, uma palavra de status incompatível ou um comando sem efeito não provam, isoladamente, defeito eletrônico no drive.
Podem indicar uma diferença entre o projeto do controlador e a estrutura realmente configurada no acionamento.
Em Modbus, o mapa que relaciona os dados do protocolo à aplicação do equipamento é específico do dispositivo. Um endereço de registrador válido não garante que ele represente a variável, a unidade ou a escala esperada pelo projeto. Conferir o significado da informação é diferente de apenas constatar que houve resposta.
Por segurança e compatibilidade, este artigo não publica control words, telegramas ou assemblies como receita universal. Essas estruturas precisam ser verificadas na documentação da combinação real de drive, interface, controlador e aplicação.
Camada 6: comunicar não significa ter autoridade para comandar
Existe um cenário particularmente enganoso:
o CLP lê o drive, os dados parecem coerentes, mas o motor não parte ou a referência não é aceita.
Isso pode não ser uma falha de comunicação.
Acionamentos possuem estados operacionais, fontes de comando e fontes de referência que dependem da parametrização e da arquitetura da máquina. A documentação da Rockwell mostra situações em que a rede está conectada sem que o drive esteja controlado via Ethernet. A WEG também documenta, em sua colocação em operação de redes, a definição de fontes de comando conforme a aplicação.
Portanto, três ideias precisam permanecer separadas:
- conectividade: existe caminho de rede;
- troca de dados: controller e drive conseguem enviar/receber informação coerente;
- autoridade de controle: o equipamento está configurado e em estado válido para aceitar daquele canal os comandos esperados.
Misturar essas três coisas leva facilmente a diagnósticos errados.
Alterar fonte de comando, referência, interlocks ou estados de safety apenas “para testar” não é uma prática segura nem universal. Qualquer intervenção precisa respeitar o projeto, a análise de risco e a documentação aplicável.
E quando é a IHM que “não enxerga” o drive?
A IHM merece uma pergunta própria:
ela fala diretamente com o drive?
Em muitas arquiteturas, a IHM não lê o acionamento de forma direta. Ela exibe tags mantidas pelo CLP, que por sua vez se comunica com o drive.
Em outras, pode existir comunicação direta ou um gateway intermediário.
Isso muda completamente o ponto de investigação.
Se o CLP recebe velocidade, status e outras variáveis válidas e atualizadas do drive, mas a tela não atualiza, esse trecho de leitura drive–CLP pode estar íntegro. A falha pode envolver tags da IHM, comunicação IHM–CLP, SCADA, gateway ou configuração de visualização. A leitura correta de status também não demonstra, sozinha, que o caminho de escrita de comandos esteja funcionando.
Por outro lado, se o CLP também perdeu o dispositivo, a IHM pode estar apenas mostrando a consequência de uma falha que surgiu antes.
A tela é o lugar onde o sintoma aparece. Não necessariamente é onde a falha começou.
Antes de resetar, preservar evidências costuma ser mais valioso
Quando a produção está parada, existe uma tentação compreensível de começar alterando parâmetros: resetar comunicação, trocar IP, restaurar padrão de fábrica, atualizar firmware ou substituir o drive.
O problema é que essas ações também podem apagar pistas.
Antes de mudanças, quando tecnicamente possível, vale preservar informações como:
- fabricante, modelo e código completo dos equipamentos envolvidos;
- protocolo e módulo/interface utilizados;
- estado dos LEDs e diagnósticos antes da intervenção;
- mensagens exibidas pelo CLP, IHM ou software de engenharia;
- momento em que a falha surgiu;
- se houve troca de equipamento, manutenção, atualização ou alteração de projeto pouco antes do sintoma;
- cópia do projeto e backups existentes;
- endereçamento e identidade documentados;
- quais dados ainda são lidos e quais deixaram de responder.
Esse princípio conversa diretamente com a preservação de configuração antes de substituir um acionamento: uma tentativa de correção não deve destruir o contexto necessário para entender a falha.
Quando começa a fazer sentido suspeitar do hardware?
Diagnosticar por camadas não significa assumir que hardware nunca falha.
Interfaces de comunicação, módulos opcionais, fontes internas, conectores e circuitos eletrônicos podem apresentar defeitos.
A diferença está na ordem do raciocínio.
A suspeita de hardware ganha força quando a infraestrutura, identidade, protocolo, configuração do controller e estrutura de dados foram confrontados com a documentação aplicável e o comportamento continua incompatível — especialmente quando existem diagnósticos do próprio equipamento apontando falha da interface.
Um diagnóstico direto de falha eletrônica pode antecipar essa investigação. O modelo por camadas ajuda a organizar hipóteses, mas não exige esgotar tentativas de configuração antes de reconhecer uma evidência concreta de defeito.
Isso evita substituir um drive saudável para descobrir depois que o problema estava no projeto do CLP, em um endereço duplicado ou em uma interface incompatível.
O inverso também é válido: insistir indefinidamente em configuração quando a interface possui uma falha eletrônica comprovada também aumenta o tempo de parada.
O objetivo é reduzir incerteza de forma progressiva.
Segurança e cybersecurity também fazem parte do diagnóstico
Redes industriais fazem parte do funcionamento da máquina e, em muitos casos, da arquitetura OT da planta.
Por isso, alterações em endereçamento, switches, VLANs, firewalls, firmware, watchdogs, ações de perda de comunicação e fontes de comando não devem ser tratadas como tentativas neutras.
Uma mudança pode afetar outros equipamentos, criar conflito de identidade ou alterar a resposta da máquina diante de uma perda de rede.
Este artigo é conceitual. Não orienta reset de fábrica, forcing de comandos, bypass de interlocks ou safety, atualização de firmware como tentativa genérica nem alteração de rede de produção sem validação da arquitetura e dos procedimentos aplicáveis.
Observações e intervenções devem respeitar a autorização de acesso, a coordenação da equipe responsável pela rede OT e a habilitação exigida para a atividade. Preservar evidências não significa executar varreduras, alterar diagnósticos ou testar comandos em produção sem esses controles.
O que levar para uma avaliação técnica
Um contexto documentado ajuda a equipe a separar hipóteses de rede, configuração, integração e hardware.
Informações úteis incluem:
- modelo completo do drive;
- modelo do CLP e da IHM, quando envolvidos;
- protocolo utilizado;
- módulo ou adaptador de comunicação;
- descrição objetiva do sintoma;
- diagnóstico/LEDs exibidos;
- quais dados ainda funcionam;
- se o drive aparece no software ou projeto do controlador;
- evento que antecedeu a falha;
- versão de firmware conhecida;
- backup e projeto original disponíveis.
Se o sintoma vier acompanhado de alarmes do acionamento, também vale separar a comunicação do restante do sistema. A matéria Servo drive em alarme: quando a falha está no drive e quando está fora dele? mostra por que um fault pode ter origem fora do módulo eletrônico principal.
A pergunta final é simples: onde a cadeia parou?
Quando um drive não comunica com o CLP ou a IHM, existem várias possibilidades antes da conclusão “o drive queimou”.
A falha pode estar no link, na identidade, no protocolo, na compatibilidade da interface, no projeto do controller, no mapa de dados, na autoridade de comando ou em outro trecho da arquitetura.
Por isso, um diagnóstico consistente segue uma lógica:
primeiro localize a camada da falha; depois decida o que precisa ser alterado ou reparado.
Essa ordem preserva evidências, reduz mudanças desnecessárias e aumenta a chance de corrigir a causa — não apenas o sintoma.
