A metodologia para implementação da TCS modular local em CLP, organiza o programa do CLP em sub-rotinas as quais são chamadas por uma rotina principal. Esta estruturação é possível ser implementada nos CLP existentes no mercado e levar a um programa estruturado e organizado, facilitando sua interpretação e manutenção. Além disso, permite-se que uma mesma sub-rotina possa ser chamada mais de uma vez ao longo da rotina principal, o que pode levar a reaproveitamento de código e à diminuição do programa.
Com o intuito de organizar o programa e facilitar seu entendimento, devem ser criadas dez sub-rotinas e a ordem de chamada dessas sub-rotinas é fundamental para o correto funcionamento programa. Assim, pode-se expandir o fluxograma apresentado na Figura 5.10 para o fluxograma apresentado na Figura 5.12, onde são incorporadas as sub-rotinas de leitura e escrita do CLP, inicialização dos estados dos autômatos e tratamento do problema da escolha, como será detalhado seguir em nove passos.
Note que na Figura 5.10, a sub-rotina nomeada de “Resgata os eventos gerados pela planta” é chamada mais de uma vez ao longo do ciclo de varredura.
Figura 5.12 – Fluxograma da rotina principal completo
O primeiro passo consiste em setar as memórias que representam os estados iniciais dos supervisores e dos subsistemas que compõem o sistema produto, já os demais estados devem ser resetados. Esse procedimento deve ser realizado apenas uma única vez, no primeiro ciclo de varredura do CLP.
O segundo passo consiste em realizar a leitura das entradas do CLP e identificar quais eventos foram gerados pela planta, de acordo com a identificação de alterações nos sinais de entrada do CLP correspondente aos eventos não controláveis. A Figura 5.13 apresenta, no seu lado direito, um exemplo de rotina que pode ser usada para identificar a geração dos eventos B e D, para o autômato apresentado no lado esquerdo da mesma figura. Nesta rotina, a cada mudança do sinal de entrada I0.0, de zero para um é identificado que o evento B foi gerado pela memória B0.1. Da mesma forma, o evento D, representado pela memória D0.1, é gerado toda vez que se tem uma alteração no valor da entrada I0.1, de zero para um.
Figura 5.13 – Identificação da transição na entrada e geração de evento
O terceiro passo é promover as transições de estados para todo o sistema produto com todos os eventos não controláveis que acabaram de ser identificados. Para isso são implementadas apenas as transições pertencentes ao sistema produto que envolve eventos não controláveis, lembrando que a cada transição realizada com um determinado evento a informação que o evento estava ativo é apagada a fim de evitar o efeito avalanche. A Figura 5.14 mostra o código do CLP que promove a transição de estados para o autômato apresentado na Figura 5.13.
Figura 5.14 – Transição com eventos não controláveis no sistema produto
No quarto passo, todos os supervisores implementados também devem realizar as transições de estados com os eventos não controláveis. A estrutura do código do CLP a ser implementado nos supervisores é a mesma estrutura usada no sistema produto que foi apresentado na Figura 5.14. Da mesma forma, apenas as transições dos supervisores que envolvam os eventos não controláveis devem ser implementadas nesse momento. A Figura 5.15 apresenta no lado esquerdo o autômato de um supervisor e no lado direto o programa do CLP que promove a transição de estados para os eventos não controláveis existentes.
Figura 5.15 – Transição com eventos não controláveis nos supervisores
Como a informação que o evento ativo foi apagado durante a atualização do sistema produto, antes de se atualizar cada supervisor deve-se resgatar a informação de quais eventos não controláveis foram gerados pela planta. Para isso, cada evento não controlável utiliza duas memórias, uma memória é usada para armazenar quais eventos foram gerados pela planta e a outra é usada para promover a transição de estados e será apagada em seguida.
A Figura 5.16 apresenta um exemplo de código de CLP para atualizar quais eventos não controláveis foram gerados. Para o evento B são usadas as memórias B0.1 e B0.2 onde na memória B0.1 é armazenada a informação que o evento B foi gerado, como ilustrado a Figura 5.13, e a memória B0.2 é utilizada para promover a transição do estado, como foi apresentado na Figura 5.14 e Figura 5.15.
Figura 5.16 – Resgata os eventos gerados pela planta
Desta forma se dá prioridade para o tratamento de eventos não controláveis, mantendo o estado do sistema produto e os estados dos supervisores em sincronia com o estado da planta física, evitando-se o efeito avalanche.
O quinto passo não se difere em nada do que foi proposto por Queiroz e Cury (2002), onde, a partir do estado atual dos supervisores verificam-se quais eventos estão desabilitados
pelo conjunto de supervisores. A Figura 5.17 apresenta no lado direito, um exemplo de código de CLP que promove as desabilitações dos eventos controláveis para o supervisor ilustrado no lado esquerdo da mesma. Note que as memórias d_A0.0 e d_C0.0 apresentam a informação acerca da desabilitação ou não dos eventos controláveis A e C.
Figura 5.17 – Desabilitações dos eventos controláveis
O sexto passo leva em consideração os estados em que se encontra cada um dos supervisores, e a lista de eventos controláveis não desabilitados em cada um desses estados. Assim, se algum dos supervisores apresentar o problema da escolha, esta deve ser realizada aleatoriamente. A estrutura do código a ser implementado depende de cada caso, conforme apresentado anteriormente na seção 5.1.3. Por outro lado se nenhum supervisor apresentar o problema da escolha o sexto passo não será implementado.
Já o sétimo passo corresponde à geração dos eventos controláveis que não foram desabilitados anteriormente e são possíveis de ocorrer na planta. Esta geração de eventos é feita no nível do sistema produto e é seguida da atualização de estados do sistema produto devido a estes eventos. Assim, nesse passo devem ser implementadas todas as transições que envolvem os eventos controláveis presentes no sistema produto que não foram implementadas no segundo passo, completando assim a implementação do sistema produto no CLP.
Na Figura 5.18 apresenta-se um exemplo de programa de CLP para a atualização do sistema produto referente ao autômato mostrado ao lado esquerdo da mesma. Quando a planta
G1 estiver no estado 0 e o evento A não estiver desabilitado (com a memória d_A0.0 não
energizada) o sistema promove a transição para o estado 1, apaga a informação que a planta estava no estado 0 e gerando o evento A, setando a memória A0.1.
Figura 5.18 – Geração dos eventos controláveis
No oitavo passo é realizada a atualização dos estados dos supervisores com os eventos controláveis que foram gerados no passo anterior, ou seja, são implementadas todas as transições dos supervisores que apresentam eventos controláveis que não foram implementas no terceiro passo, completando assim a implementação dos supervisores no CLP. Na Figura 5.19 apresenta-se o código do CLP que promove as transições dos estados para o supervisor apresentado ao lado esquerdo da mesma. Note que estando no estado 0 o supervisor deve transitar para o estado 1, com a geração do evento controlável A, realizada anteriormente no sistema produto, conforme foi apresentado na Figura 5.18.
Figura 5.19 – Transição dos supervisores com eventos controláveis
Assim, a partir dos dois últimos passos, antes mesmo da atuação física nas saídas do CLP decorrentes dos eventos controláveis gerados, o sistema produto e os supervisores estarão antecipando o estado da planta física. Note também, que teoricamente existe a possibilidade de existir o problema do efeito avalanche para eventos controláveis. Porém não foi estabelecido nenhum procedimento para tratar esse tipo de problema nos dois últimos passos. Uma vez que, os autores entendem que, em uma aplicação prática, esse problema não
irá se apresentar. De qualquer forma, acaso exista um exemplo prático que velha a apresentar esse tipo de problema, poderia ser utilizada a mesma abordagem que foi apresentada para evitar esse problema no tratamento dos eventos não controláveis.
No nono e ultimo passo, são transmitidos para a planta física os eventos controláveis que foram gerados anteriormente, ou seja, os eventos mapeados promovem acionamentos das saídas do CLP, gerando os eventos na planta física e dá-se início a um novo ciclo de varredura. Na Figura 5.20 apresenta-se o código do CLP que atualiza as saídas Q0.0 e Q0.1, a partir dos eventos gerados no sistema produto, representado pelo autômato ao lado esquerdo da mesma. Veja que quando o evento é transformado em comando para a saída, a informação que o evento estava ativo é apagada. Note também que é necessário estabelecer uma condição para que o sinal de saída seja resetado.
No exemplo em questão a geração dos eventos não controláveis que está fazendo esse papel, porém poderia ser qualquer outro evento até mesmo ser apenas um pulso onde a largura deste seria dada por um temporizador. Em fim, o importante é que o reset dos sinais de saídas deve ser realizado antes da geração dos eventos controláveis, para que não haja a possibilidade de uma condição de reset desabilitar um evento antes de este evento ser transmitido a planta física.
Figura 5.20 – Transição dos supervisores com eventos controláveis
5.2 ESTUDO DE CASO
Com o objetivo de ilustrar a metodologia de implementação proposta nesse trabalho, a seguir será apresentada a solução completa de um problema de controle supervisório, mostrando desde o modelamento da planta e das especificações, a síntese dos supervisores, até a obtenção do código ladder referente à lógica de controle que deve ser implementada no CLP a fim de garantir o correto funcionamento do sistema.