A cada poucos dias, o SLC entra em falha. Erro grave 0020. Os operadores dão de ombros, a manutenção limpa a falha e a produção é retomada — até que o mesmo erro matemático ocorra novamente no turno da noite. Esse padrão é o bit de armadilha de overflow S:5/0 fazendo exatamente o que a Rockwell projetou para fazer: permanecer travado para que você não possa fingir que a aritmética incorreta nunca aconteceu.

Em um 5/04, como o 1747-L524, 0020 significa que uma instrução produziu um resultado fora da faixa válida de inteiros. Os cálculos com inteiros assinados de 16 bits ficam entre −32768 e +32767. Ultrapasse esse limite com ADD ou MUL, divida por zero, percorra uma FIFO/LIFO além do seu buffer ou execute NEG sobre −32768, e o processador definirá S:5/0 e permanecerá em falha até que algo destrave esse bit. Os manuais da família das publicações 1747-UM011 / 1747-UM001 descrevem a armadilha; no chão de fábrica, o que se vê é uma CPU parada.

Os processadores SLC legados ainda controlam muitas máquinas discretas. As armadilhas de overflow quase sempre são causadas pela matemática da aplicação — não por um backplane que está morrendo.

O OTU que interrompe o problema

A maioria das recuperações rápidas coloca um OTU em S:5/0 para que a varredura possa continuar após a armadilha. A posição é o ponto crucial. Coloque-o como o último rung da LAD 2 — o arquivo que contém suas chamadas JSR — para que todas as sub-rotinas já tenham terminado antes de você limpar o latch. Assim, o overflow é detectado durante a varredura e depois limpo uma única vez, antes do tempo ocioso.

LAD 2 — último rung
  S:5/0
----] [----(OTU)----

Coloque o mesmo OTU dentro da sub-rotina que apresenta o overflow e você criará um novo modo de falha: limpar cedo demais, ocorrer outro overflow mais tarde na mesma varredura e haver uma nova falha imediata. Ou o OTU será executado em um caminho que não encontra a matemática incorreta naquela varredura, fazendo você pensar que “corrigiu” o problema enquanto o rung real continua causando a falha duas vezes por semana.

Faça o download, coloque a CPU em RUN e observe S:5/0 permanecer limpo durante alguns turnos. Se continuar silencioso, você ganhou tempo — não encerrou a causa raiz.

Encontre a matemática que realmente causou o overflow

Trate o OTU como um cinto de segurança. Depois, investigue:

• Qualquer alteração recente que envolva inteiros — contagens de bateladas, sinais analógicos escalonados inseridos em arquivos N, “temporários” MUL para conversão de unidades
• ADD / SUB / MUL / DIV / DDV sem limites de faixa
• Locais que deveriam usar LADD / LMUL (32 bits) depois que os valores saíram da faixa confortável de 16 bits
• NEG em um valor que pode chegar a −32768
• Comprimento da FIFO/LIFO em relação ao buffer que você realmente reservou

Bits de status relacionados que vale a pena conhecer durante a depuração: S:5/1 habilitação da armadilha de overflow, S:1/0 primeira varredura, S:2/0 falha do processador. Não limpe armadilhas às cegas em edições online sem saber qual rung está causando o problema.

Verificação da realidade do hardware

As CPUs 5/04 da classe 1747-L524 estão profundamente obsoletas. Se o chassi permanecer, mantenha um 5/04 sobressalente em boas condições na prateleira — as fábricas que ainda compram dessa família frequentemente acabam recorrendo a módulos como o 1747-L542. Máquinas menores às vezes migram lateralmente para um 5/03, como o 1747-L532, mas isso é uma decisão de projeto, não uma correção para overflow. No longo prazo, a maioria das instalações migra o processo para CompactLogix ou ControlLogix e elimina as armadilhas da matemática de 16 bits com a plataforma. A estratégia de peças sobressalentes para frotas Logix mistas ainda deve considerar como você mantém em estoque sistemas PLC e PAC.

Até que essa migração seja concluída, a disciplina é simples: OTU por último na LAD 2 e, depois, comprove qual ADD/MUL está mentindo sobre sua faixa.