PLC do Rascunho ao Software - 10
- Paulo Ricardo Siqueira Soares
- Nov 6, 2023
- 5 min read
Updated: Nov 6, 2023
Estrutura do Software
Bom agora que já temos nossos requisitos levantados e refinados a um ponto que podemos utilizá-los, chegou a hora pensar na nossa estrutura do software, para isso vamos primeiramente dar uma olhada no layout geral, fornecido pelos engenheiros mecânicos para mostrar onde estará nosso magazine de paletes, conforme a ilustração abaixo:
O esboço já veio com as nomenclaturas dos sistemas de transporte e estação da linha, que está inserida na Área 1 do cliente. As divisões conforme, área, estação, etc. podem ser dadas pela ISA88 - Parte 1, porém isso vai ser assunto para um artigo a parte, no momento para nós o importante é entender como está inserido o magazine de paletes e o importante já temos o seu nome.
Bom partindo disso a primeira coisa que vou fazer é organizar as minhas rotinas, e depois entender quais são as funções que tenho que criar e minhas estruturas de dados.
Começando pelas minhas rotinas, para definir as minhas rotinas a primeira coisa é saber que elas estarão dentro da minha estação, a qual terá o programa principal que chamará as rotinas, e para isso uma coisa importante é relembrar o ciclo de funcionamento do CLP, no qual o scan ocorre de cima para baixo, onde são lidas as entradas, processada a lógica linha a linha e depois atualizada as saídas, então as minhas rotinas devem estar priorizadas levando em conta o scan.
Ahh vejam que estou falando sempre da forma genérica, não com nomes específicos do Codesys (que está no nosso requisito) ou qualquer outra IDE de programação, isso é para mostrar que todo esse passo conceitual é aplicável em qualquer plataforma e vou provar isso mais para frente.
O magazine de paletes é uma máquina bem simples, que nem mesmo possui uma aplicação de segurança dentro, então serão utilizadas poucas rotinas.
Obedecendo o scan do CLP, eu tenho em primeiro lugar o mapeamento das entradas, quando não é possível fazer diretamente no hardware é feito em uma rotina separada para uma melhor organização, mesmo que eu consiga fazer o mapeamento todo no hardware o seguro morreu de velho e eu já deixo uma rotina separada para eventuais mudanças no escopo e requisitos, a minha segunda rotina será a de Sistema onde eu irei gerenciar desde meus modos de operação ao diagnóstico do meu hardware, eu poderia fazer uma rotina separada para diagnóstico, mas nesse caso o equipamento é tão pequeno que não compensa, um equipamento maior iria possuir uma quantidade maior de lógica de diagnóstico para fins de organização que inclui navegação e facilidade para debug e monitoramento, é interessante uma rotina de diagnóstico em separado.
Uma vez que eu vou ter interação entre o magazine e a linha de paletes, em especial com o transportador "Entrada-TR01", uma rotina para tratar essa informação se faz necessária, uma vez que as informações podem ser tratadas em um só lugar, novamente em uma máquina maior pode-se optar por mais rotinas, essa é a minha terceira rotina chamada de Intertravamentos Externos.
Podemos perceber que além do scan do CLP a ordem das rotinas está também seguindo uma priorização, entradas, sistema, intertravamentos, perceba que sem isso nem adianta querer pensar em uma sequência de funcionamento e essa é a nossa próxima rotina sequência, que nada mais do que a sequência de funcionamento em automático.
Uma vez que eu tenho uma sequência de funcionamento chega o momento de enviar os comandos para os atuadores e motores, comandos esses que foram enviados pela sequência de funcionamento em automático, bom então a minha próxima sequência será, atuadores, uma vez que a posição dos atuadores que serão avaliadas pela função que será chamada dentro da rotina será usada como intertravamento para os motores, então eu coloquei como prioridade eles.
Meu próximo passo será avaliar as falhas uma vez que os comandos e a verificação de status, etc. já foram enviados, assim é a vez da rotina de falhas, seguidas da rotina com as minhas lógicas de sinalização, de envio de informações para a IHM - Interface Homem Máquina e finalmente por último, mas não menos importante meu mapeamento de entradas e saídas.
Bem já temos nossa estrutura básica das rotinas do software, agora podemos começar a pensar nas funções que iremos precisar, então vamos pensar um pouco, a função deve executar tarefas repetitivas, servindo como código reutilizável, além de encapsular a lógica que é comum em vários momentos, você ganha tempo, quando utiliza uma função, além de um código muito mais fácil de ler, então já podemos pensar em algumas situações que podem ser interessantes, primeiro por exemplo uma função que vai gerenciar os modos de operação, uma vez que essa gestão também vai lidar com comandos vindos de uma IHM e enviar status para a IHM, isso permite, uma lógica que eu posso reutilizar no futuro, mas que vai ser estática nesse projeto, ou seja, utilizada uma vez e não sofrerá mudanças, encapsular essa lógica vai tornar o software mais legível e vou poder ter minha primeira função para uma futura biblioteca.
Dispositivos em geral, é sempre interessante ter uma função para gerenciar dispositivos, como atuadores, motores, inversores, servos, leitores de código de barras, etc., pois ou serão reutilizados várias vezes ou irá tornar o software mais legível e você vai poder reutilizar a lógica em futuros projetos
Para esse primeiro momento então eu já posso listar 3 funções e onde elas serão chamadas:
Chamei minhas funções de:
Modos de Operação
Válvulas
Partida Direta
Com certeza durante o desenvolvimento vamos descobrir mais funções que podemos criar, mas para esse momento essas 3 já são o começo para começarmos o nosso software, nada nos impede de criar mais, desde que existam critérios para isso.
Com as minhas funções e minhas rotinas estruturadas o próximo passo vai ser criar as estruturas de dados básicas para o nosso software, com tudo isso é hora de começar pôr a mão na massa e programar.
Então vamos lá, as estruturas de dados consistem em organizar os dados de forma refletir algumas abstrações, se você quiser saber mais sobre elas, tem esse artigo aqui (https://www.plcengsoft.com/post/estrutura-de-dados-com-plc), lê lá e depois volta se não sabe do que estou falando.
Logo de cara já posso pensar em algumas bem fáceis de identificar:
Modos de Operação
Atuador
Motor
Essas estruturas estão intimamente ligadas as nossas funções, porém podemos ter outras para auxiliar no desenvolvimento, como uma estrutura de dados para contagem da produção, outra para ajudar no controle da sequência de automático, uma outra de falhas e uma outra de status dos intertravamentos externos.
Estrutura de Dados Modos de Operação
Quando eu fui desenvolver a minha estrutura de dados de modo de operação baseado nos meus requisitos que os descrevem, eu percebi, que seria mais inteligente ao invés de ter uma estrutura grande com várias variáveis, subdividir a mesma em estruturas mais organizadas, como para a IHM, status e comandos, e também como existe uma pré-condição para iniciar o modo manual decidi criar a estrutura interlocks, que não só vai facilitar eu programar meus interlocks como também vai trazer visibilidade para a IHM uma vez que vou enviar para ela o status e a descrição dos mesmos.
O mesmo conceito eu irei seguir para as demais estruturas de dados as quais vou separar as informações relacionadas a IHM, comandos e status.
Não vou colocar todos os diagramas aqui pois o artigo já está longo, mas percebam que nossa documentação agora está ficando bem completa.
No próximo artigo, vamos começar a programar vou mostrar as estruturas de dados, estrutura de rotinas já no CLP, fazendo um paralelo entre 3 IDEs, para vocês perceberem que os conceitos são aplicáveis independente da IDE.
Até o próximo artigo,
Bibliografia:
ISA88 Parte 1
Construção de algoritmos – Jander Moreira – Universidade Federal de São Carlos – UFScar
Komentáře