Como otimizar o tempo de varredura e corrigir falhas de Watchdog Exceeded no IC695CPU310

Entendendo a causa raiz da falha de tempo excedido do watchdog do RX3i

Uma falha de "Watchdog Timer Exceeded" no PACSystems RX3i IC695CPU310 da GE Fanuc não significa automaticamente que sua CPU não tem capacidade de processamento. Você nunca deve tratar esse erro simplesmente aumentando a configuração do temporizador de watchdog do software. A principal causa é um pico inesperado no tempo de execução de uma única varredura do programa do CLP. Condições anormais de loop, chamadas recursivas excessivas ou operações intensivas de memória geralmente provocam esses atrasos de execução.

De acordo com as diretrizes de referência das CPUs GE Fanuc, o watchdog do software detecta atrasos anormais na conclusão da varredura. A faixa configurável do watchdog do software vai de 10 ms a 2550 ms, ajustável em incrementos de 10 ms. Os engenheiros de campo devem sempre localizar o gargalo do programa que aumenta o tempo máximo de varredura, em vez de mascarar falhas lógicas subjacentes com tempos limite estendidos.

Diferenciando falhas do watchdog de software e de hardware

Os engenheiros devem identificar o mecanismo exato, de hardware ou software, por trás da falha antes de alterar qualquer código.

• Falhas do watchdog de software: ocorrem quando uma única varredura de execução excede o limite programado do watchdog. Os gatilhos típicos incluem loops FOR ou WHILE enormes, blocos de função recursivos, operações de arrays sem limitação, processamento intenso de strings, comunicações Ethernet concentradas ou gravações diretas na memória não volátil.
• Falhas do watchdog de hardware: representam o acionamento de um mecanismo interno de segurança da CPU. Diferentemente dos erros de software, as falhas do watchdog de hardware geralmente exigem um ciclo completo de desligamento e religamento físico para serem eliminadas em plataformas de CPU mais antigas, como o IC695CPU310.

Quando ocorre um desligamento inesperado, acesse a Tabela de Falhas do PAC Machine Edition (PME). Examine a Descrição da Falha, o Código da Falha, o Registro de Data e Hora e a Contagem de Ocorrências. Prossiga com a otimização da lógica somente se o registro de diagnóstico indicar explicitamente uma expiração do watchdog de software.

Analisando a dinâmica da varredura: varredura média versus varredura máxima no pior caso

Muitos engenheiros de automação se concentram exclusivamente no tempo médio de varredura do programa, o que cria um ponto cego perigoso. Um sistema operando com um tempo médio de varredura de 18 ms pode facilmente atingir 240 ms durante determinados acionamentos condicionais. Se o limite do watchdog estiver definido em 200 ms, o CLP entrará imediatamente em uma falha de parada.

Uma lógica condicional pesada geralmente causa esses desligamentos aleatórios. Operações como cálculos diários de lotes de relatórios, arquivamento de dados históricos ou cópias em massa de memória executadas durante um único ciclo de varredura aumentam o tempo máximo de execução.

Métodos práticos para reduzir o tempo de varredura no controlador IC695CPU310

Otimizar os ciclos de varredura mantém os loops de controle responsivos em instalações de embalagem de alta velocidade, tratamento de água e fabricação contínua. Aplique estas técnicas de engenharia para reduzir o tempo máximo de varredura:

• ⚙️ Implemente divisão de tempo para loops grandes: nunca execute loops FOR ou WHILE enormes em um único ciclo de varredura. Divida o processamento de arrays em blocos menores ao longo de várias varreduras consecutivas usando índices de máquina de estados.
• ⚙️ Audite chamadas recursivas e blocos de função: verifique a árvore de chamadas de blocos do PAC Machine Edition. Elimine chamadas recursivas indiretas nas quais a Função A aciona a Função B, que acidentalmente chama a Função A novamente sob determinadas ramificações lógicas.
• ⚙️ Passe do tratamento contínuo para o tratamento orientado a eventos: evite copiar ou dimensionar milhares de registros analógicos em cada varredura. Execute fórmulas matemáticas complexas e a classificação de arrays somente quando sinalizadores de alteração de dados forem acionados.
• ⚙️ Distribua as tarefas de comunicação Ethernet e serial: distribua comunicações ativas, como Modbus, SRTP ou EGD, ao longo de vários ciclos usando uma estratégia de consulta round-robin, em vez de consultar todos os nós externos de uma só vez.
• ⚙️ Limite as gravações na memória flash não volátil: chamadas lógicas diretas que gravam dados operacionais na memória não volátil consomem um tempo significativo da CPU. Acione as gravações na flash periodicamente ou após a conclusão de um lote, em vez de realizá-las em cada varredura lógica.

Fluxo de trabalho passo a passo para solução de problemas em campo

Siga esta sequência metódica de engenharia para eliminar picos no tempo de varredura com segurança:

1. Identifique a origem da falha: verifique a Tabela de Falhas do PME para confirmar o acionamento do watchdog de software.
2. Registre as métricas de referência: registre a varredura média da CPU, a varredura máxima no pior caso e a configuração atual do tempo limite do watchdog.
3. Rastreie os gargalos do código: procure loops sem limitação, transferências contínuas de arrays, comunicações concentradas e gravações na memória flash.
4. Reestruture a lógica: aplique máquinas de estados, algoritmos de divisão de tempo e blocos lógicos orientados a eventos para distribuir a carga de processamento.
5. Reavalie o desempenho: monitore os tempos máximos de varredura durante vários turnos operacionais sob carga máxima de produção.
6. Ajuste a margem do watchdog: defina o limite final do watchdog de software ligeiramente acima do novo tempo máximo de varredura estabelecido, mantendo uma margem de segurança confiável.

Cenário de aplicação: otimização do sistema de transportadores de uma linha de engarrafamento

Em uma instalação de engarrafamento de bebidas de alta velocidade controlada por um IC695CPU310, a linha de produção apresentava falhas intermitentes de parada do CLP a cada poucos dias durante as trocas de turno.

A causa raiz: durante as transições de turno, uma sub-rotina ativa de lógica ladder executava um loop sem limitação que classificava, atualizava e copiava 4.000 registros de rastreamento de produtos para um array de arquivamento em uma única varredura. Isso elevava o tempo máximo de varredura de 22 ms, em condições normais, para 265 ms, excedendo o limite de 200 ms do watchdog de software.

A solução: nossa equipe de engenharia reestruturou o algoritmo de classificação em uma máquina de estados com divisão de tempo, que processava 200 registros por ciclo de varredura ao longo de 20 varreduras consecutivas. Essa alteração reduziu o tempo máximo de varredura de 265 ms para 38 ms, eliminando completamente o problema de acionamento do watchdog sem alterar os componentes de hardware.

Perguntas frequentes (FAQs)

P1: Nossa CPU310 aciona regularmente falhas de Watchdog Timer Exceeded. Isso significa que a velocidade do processador da CPU é muito baixa e que ela precisa ser substituída?
Resposta: não necessariamente. A substituição da CPU deve ser sua última opção. A maioria dos erros de watchdog resulta de uma lógica de programa mal estruturada, operações de loop sem limitação ou picos repentinos de comunicação. Você pode eliminar os picos de varredura reestruturando cálculos pesados em máquinas de estados com divisão de tempo ao longo de vários ciclos lógicos. Considere uma atualização de hardware somente se o tempo médio de varredura de referência continuar próximo da capacidade da CPU após a reestruturação do código.

P2: Podemos definir com segurança o temporizador de watchdog do software no valor máximo de 2550 ms para evitar acionamentos?
Resposta: embora o menu de configuração da CPU permita fisicamente até 2550 ms, isso é uma prática de engenharia inadequada. Estender o limite até esse ponto mascara erros lógicos críticos, como loops infinitos ou chamadas recursivas travadas. Em automação de processos críticos, uma CPU travada que permanece em execução por 2,5 segundos antes de entrar em falha pode causar graves riscos operacionais e de segurança. Mantenha o limite do watchdog ligeiramente acima do seu tempo máximo de varredura real, com uma margem de segurança razoável.

P3: Com base na experiência em campo, qual é a melhor maneira de rastrear qual bloco específico causa um pico no tempo de varredura?
Resposta: use as ferramentas de diagnóstico do PAC Machine Edition junto com temporizadores de execução personalizados. Insira leituras de registro de data e hora do sistema antes e depois dos blocos de função suspeitos para registrar as durações máximas de execução em registros de acompanhamento. Compare essas leituras com os registros de estado da máquina para descobrir quais eventos de produção — como trocas de lote, geração de relatórios ou consultas da IHM — acionam o pico de carga de varredura.

Perspectivas do autor e opinião especializada

"Ao longo dos anos prestando suporte a equipamentos de automação industrial na Ubest Automation Limited, frequentemente vemos equipes de campo tentando resolver falhas de watchdog do CLP aumentando arbitrariamente as configurações do temporizador ou comprando hardware novo. Em plataformas como o PACSystems RX3i, os picos no tempo de varredura quase sempre estão relacionados ao gerenciamento ineficiente de dados ou a comunicações sem limitação. Adotar uma abordagem disciplinada que prioriza o software economiza um tempo de inatividade significativo e prolonga a vida útil do hardware de controle existente."
— Equipe de Engenharia da Ubest Automation Limited

Procurando hardware GE Fanuc confiável e suporte especializado?

Seja para solucionar problemas em sistemas legados ou obter peças de reposição para automação industrial, a Ubest Automation Limited fornece componentes originais de CLP testados, módulos DCS e soluções de controle industrial.

Encontre componentes originais GE Fanuc e PACSystems na Ubest Automation Limited.