Erro 0020 da armadilha de estouro do SLC 500: corrigindo o latch S:5/0

O erro grave 0020H do SLC 500 é comumente descrito como uma falha de estouro, mas o código é mais abrangente do que uma única instrução ADD com problema. A Rockwell o define como uma condição de erro menor que permaneceu ativa quando o processador chegou a END, TND ou REF e, por isso, foi promovida a um erro grave. O diagnóstico consiste em identificar qual bit de status causou a promoção, determinar qual operação o ativou e decidir se a recuperação controlada é segura.

O erro 0020H deve levar a uma investigação do arquivo de status, não à conclusão automática de que o hardware do processador falhou.

Leia o arquivo de status antes de limpar qualquer coisa

Registre o código de falha, o número de catálogo do processador, o modo de operação, o horário, o estado da produção e os valores de S:5 e S:6 antes de reinicializar o controlador. S:5/0 é a armadilha de estouro matemático. S:5/2 indica um erro de registro de controle causado por instruções como FIFO, deslocamento de bits ou operações de sequenciador. Outros bits de S:5 também podem ser promovidos ao final da varredura. Limpar o processador antes de capturar esses valores destrói evidências e favorece o retorno da mesma falha.

O Manual de Referência do Conjunto de Instruções do SLC 500 da Rockwell afirma que S:5/0 é ativado quando ocorre um estouro matemático e que um erro grave 0020H é declarado se o bit ainda estiver ativo quando END, TND ou REF for executado. O manual recomenda examinar o bit após a instrução relevante, tomar as medidas apropriadas e somente então limpar S:5/0 com um OTU ou limpar a palavra de status aplicável.

Entenda o resultado matemático e a armadilha

Para ADD, SUB, MUL, DIV ou NEG, um resultado que não pode ser representado no destino ativa o bit de estouro aritmético S:0/1 e a armadilha S:5/0. Com o estado padrão de S:2/14, um resultado positivo é limitado a 32767 e um resultado negativo a -32768. Quando S:2/14 está ativo, os 16 bits menos significativos podem ser colocados no destino. Essa configuração altera o comportamento do destino; ela não comprova que o resultado da aplicação é válido.

DDV e algumas instruções de conversão ou escalonamento têm regras adicionais, portanto a investigação deve seguir a referência exata da instrução. Divisão por zero, um comprimento de controle inválido ou um endereço indireto fora do intervalo permitido podem produzir um caminho de status diferente. Não agrupe todo evento 0020H em “estouro de inteiro” sem verificar S:5 e a instrução executada imediatamente antes de o bit ser ativado.

Encontre a primeira operação causadora

Revise as alterações recentes e faça uma referência cruzada de todas as instruções capazes de ativar o bit de status observado. Para estouro matemático, inspecione cálculos de escalonamento, totais de produção, conversões de unidades, valores acumulados de tempo de operação, limites com sinal e destinos intermediários. Um cálculo pode ser matematicamente válido em unidades de engenharia, mas inseguro quando uma etapa intermediária é armazenada em um inteiro de 16 bits.

Registre tendências ou capture os operandos de origem, os valores de destino, S:0/1 e S:5/0 ao redor das instruções suspeitas. Em um sistema de teste off-line, reproduza casos-limite logo abaixo, exatamente no limite e acima do intervalo permitido. Se várias instruções puderem ativar a armadilha durante uma varredura, adicione travas de diagnóstico temporárias que identifiquem o primeiro local. Esses bits de diagnóstico devem ser revisados, nomeados e removidos ou mantidos formalmente depois que a causa raiz for conhecida.

Use a lógica de recuperação somente com uma política explícita

Um OTU S:5/0 incondicional no último degrau pode impedir a promoção ao final da varredura, mas também suprime o desligamento independentemente do cálculo que sofreu o estouro. Isso pode ser aceitável para um contador não crítico cujo valor seja limitado e gere um alarme. Não é aceitável quando o resultado influencia movimento, pressão, temperatura, dosagem, proteção do equipamento ou uma decisão relacionada à segurança.

Uma lógica robusta verifica o resultado da instrução no local em que ele ocorre. Valide os operandos antes da execução, escolha um destino com faixa adequada, limite o valor somente quando o significado do processo permitir, ative um alarme de diagnóstico, substitua o valor por um valor seguro documentado e só então limpe a armadilha. Se a resposta correta for interromper a sequência, preserve a falha em vez de forçar o processador a continuar.

Uma rotina de falha do usuário pode dar suporte à recuperação controlada de eventos selecionados, e o manual da Rockwell inclui um exemplo que contabiliza ocorrências repetidas de 0020H e, por fim, permite o desligamento. Esse padrão é mais informativo do que uma limpeza incondicional, pois diferencia um evento isolado e tratado de um defeito recorrente. A própria rotina de falha deve ser testada cuidadosamente; um segundo erro dentro dela pode sobrescrever informações de diagnóstico ou impedir a recuperação.

Separe falhas de software de preocupações com o hardware

Uma armadilha de estouro geralmente aponta para dados do programa e comportamento das instruções, não para uma falha do chassi. Ainda assim, alimentação instável, problemas de memória ou alterações não intencionais no programa podem modificar os dados e merecem investigação quando houver evidências. Verifique a bateria e o histórico de alimentação do controlador, compare o programa em execução com o arquivo aprovado e confira se uma IHM, mensagem ou sistema externo grava nos operandos envolvidos.

Não substitua um processador SLC como primeira resposta a um limite matemático repetível. Uma CPU substituta executando o mesmo programa com os mesmos dados reproduzirá a falha. Se a plataforma estiver obsoleta, gerencie peças sobressalentes e a migração de acordo com o plano de ciclo de vida de sistemas PLC e PAC da unidade, mas mantenha essa decisão separada da análise imediata da causa raiz.

Comprove a correção

Teste a lógica corrigida com valores normais, nos dois limites da faixa, com entradas inválidas, perda de comunicação, primeira varredura e qualquer condição de reinicialização. Confirme que os alarmes identificam o cálculo afetado, que o valor substituído é seguro e que os eventos repetidos são contabilizados. Observe S:5/0 e S:0/1 durante um ciclo de produção representativo e verifique se o processador não está simplesmente ocultando um estouro recorrente.

Arquive os arquivos RSS anteriores e posteriores, as evidências da falha, os resultados dos testes e a justificativa de qualquer lógica de recuperação. Associe esse registro à orientação de migração de escalonamento do SLC da unidade ao modernizar a aplicação. O erro 0020H torna-se administrável quando a equipe o trata como um problema preciso de status e qualidade dos dados, em vez de um bit a ser desativado imediatamente.