Há algum tempo atrás, passei por um problema interessante com um processo controlado por um SLC500.
Os controladores da Rockwell têm o mau hábito de parar a execução do programa e entrar em estado de falha no caso de um overflow matemático, sabendo disso, quem programa Rockwell já conhece as alternativas, ou você protege todos os seus cálculos, verificando se seus divisores são maiores que zero nas divisões, se as somas não excederão a capacidade dos acumuladores etc. Ou, enganando a CPU com um unlatch para o overflow trap (OTU S:5/0) na última linha do programa principal (o Ladder 2), como na imagem abaixo (clique para ver no tamanho original).
isso faz com que o flag de overflow caia no final de cada ciclo de scan, como o controlador verifica os flags que podem o enviar para o estado de falha depois de executar a última linha, o método funciona sempre, ou quase, como foi no meu caso.
O incrível é que os piores problemas na Automação Industrial ocorrem de madrugada, coisas catastróficas acontecem sempre quando estamos dormindo. Numa dessas madrugadas, um SLC500 entra em falha devido à um math overflow, o instrumentista que estava no turno fez um download do backup daquele controlador e o processo voltou a funcionar. Fui ver o que provocou isso e, para ajudar, o SLC tem uma palavra de status que indica a linha onde ocorreu a útima falha, só que... o math overflow sempre acontece na última linha do ladder 2, legal né? Então vamos procurar a maldita instrução que estava provocando o overflow manualmente. Foi aí que tive a surpresa, no final do programa principal, bem na última linha, o OTU S:5/0 estava lá!
Como é que a CPU entrou em falha então?! Estaria a CPU possuída por algum espírito malígno? Fiquei preocupado. Mais cedo ou mais tarde a CPU paranormal poderia parar o processo novamente, e não era um processo qualquer, ele abastece seis linhas de produção, as mais críticas da fábrica! FODEU!
Comecei a procurar possíveis divisões por zero, e a proteger todas elas.
No mesmo dia a CPU entra em falha novamente, aproximadamente seis horas depois. Eu já havia verificado todas as divisões do programa. Comecei a checar as adições, até que achei isso (clique para aumentar):
Uma adição normal, né? Quase, ela está dentro de um ladder configurado como STI. Beleza, um ladder que é executado periodicamente, em intervalos de tempo definidos na palavra de status S:30 (o valor definido nessa palavra, multiplicado por 10 é o setpoint de intervalo do STI em milissegundos).
Essa adição estava dentro de um bloco STI porque se trata de um acumulador de volume que recebe pulsos de um flow-meter, que neste caso só conseguia enviar pulsos de 100ms, para que estes pulsos não fossem perdidos pelo scan do PLC, foi configurado um STI que acumula os pulsos e é executado a cada 50ms.
Agora vem o segredo, eu descobri isso depois da terceira parada no tal processo, depois de solucionar fiz diversos testes em bancada e consegui comprovar a causa.
O STI roda em intervalos de tempo fixos. No caso do meu ladder 70, a cada 50ms, independente do que a CPU estiver fazendo. Pois bem, existe uma probabilidade de esse intervalo coincidir com a execução da última linha do programa principal. O scan executa todo o programa principal, inclusive as subrotinas, antes da última linha ele faz o unlatch no overflow trap, aí toca o despertador do STI, dentro desse STI acontece um overflow, o scan termina e a CPU verifica que houve um overflow. FAULT! Sem dó, aliás, controladores não têm dó de ninguém, nem gerentes de planta.
Vale dizer que essa informação não está em nenhuma literatura da Rockwell, nem é dita em nenhum treinamento oficial.
Como resolver isso então, Batman?
Se você quiser continuar enganando sua CPU, inclua além do OTU S:5/0 do ladder 2, um OTU S:5/0 no final do ladder STI (foi o que eu fiz).
Senão você pode verificar todos os seus cálculos.
Simples, não? Nem tanto quando a fábrica pode parar a qualquer momento... :)
E mais uma vez ficou provado que paranormalidades "non ecxistem", como diria o padre Kevedo.
