top of page
Search

PLC do Rascunho ao Software -12

Writer's picture: Paulo Ricardo Siqueira SoaresPaulo Ricardo Siqueira Soares

Updated: Dec 10, 2023

Dando continuidade ao nosso software, bom anteriormente criamos nossas primeiras estruturas de dados, que serão utilizadas para os nossos modos de operação, porém percebemos que os nomes dados as mesmas apesar de bem descritivos, ficara um pouco longos, então agora vamos melhorar elas um pouco, isso é algo que pode acontecer com um programador mais experiente ou um novato, então vamos lá.



Nossas estruturas originais, veja o exemplo da primeira UDT_ComandosMododeOperaçao, um nome grande, que inclusive dificulta um pouco a visualização na IDE, e como podemos reduzir esse nome? Vamos pegar a palavra comandos, uma forma universal de resumir essa palavra é pelo acrônimo "cmd", que também é usada na língua inglesa, então vamos ver como ficaria:


Ficou menor, mas levando em consideração que eu vou utilizar sempre "cmd", para comandos, já posso começar a pensar outra coisa, vou utilizar isso várias vezes então quando eu foi digitar "cmd", vai sempre aparecer uma série de UDTs, porque estou usando as ações ou descrições antes da entidade que eles pertencem, então não seria mais interessante ter as entidades no lugar das ações e descrições? Outra coisa seria que ModosDeOperacao, que também é bem longa, mas ModosOp? não seria intuitivo e fácil de ler? então vamos adotar modosOP, e vocês verão o porquê:




Agora bom o nome das UDTs, está fácil de entender e um pouco menores, o que ajuda na navegação do software.


Agora vamos ver as nossas rotinas, originalmente, elas estão com número sequenciais, porém vamos pensar um pouco e se eu quiser adicionar uma rotina a mais, vamos dizer que eu tenha que fazer a leitura de uma remota IO-Link, que precisa utilizar algum bloco de função para um mapeamento mais fácil, ou tenha algum equipamento que precisa de alguma configuração específica, ou que agora eu tenha um robô para alimentar (tá bom para um magazine de palete seria meio loucura), resumindo, digamos que eu precise de maior escalabilidade para adicionar rotinas, mantendo a organização e os critérios que adotamos para criar as rotinas, não temos como no momento, teríamos que ficar renomeando as rotinas a todo momento, mas uma coisa simples pode ajudar, que tal se ao invés de uma ordem de 1,2,3,4, adotarmos uma ordem em dezenas? como 10, 20, 30, 40, nesse caso vamos ter um "espaço" as rotinas permitindo que eu possa adicionar uma rotina 21, por exemplo, aí vamos ter a escalabilidade que nos faltava, e isso é uma boa prática para organizar seu software, escalabilidade, que anda de mãos dadas com a reutilização do software.



Pronto agora temos as nossas rotinas, e UDTs para os modos de operação, e agora vamos criar nossa primeira função.


Quando criamos nossas estruturas de dados, fomos orientados pelos nossos requisitos e eles que vão orientar a criação dessa função.


Vamos começar com os 2 primeiros requisitos:


Baseado nesses 2 requisitos já sabemos que temos 3 entradas na função que não estão previstas nas UDT, porém são entradas físicas que podem ser mapeadas diretamente no escopo de inputs (entradas), do bloco, e porquê? Porque, assim eu posso até mesmo criar uma lógica externa caso em algum equipamento futuro exista alguma combinação de chaves, etc., estou pensando em um bloco geral que pode ser utilizado no futuro em outros projetos.

Aí vamos relembrar novamente o escopo de variáveis, para o bloco de função temos entradas, saídas, local (interno), entradas e saídas, e utilizar o escopo correto é importante, então vamos lá, agora no começo da nossa função já temos algumas variáveis a serem declaradas: chaves seletoras, botões de automático e manual, como entradas, já a variável que vai ser do tipo UDT_ModosDeOp, vai ser de entradas e saídas, uma vez que temos dentro dela elementos que serão utilizados como entradas e outros como escrita.




Agora vamos para a lógica, baseada no requisito temos a habilitação do modo automático:


Caso a seletora esteja na posição manual OU não tenha pré-condições de partida, o modo de operação automático será desabilitado conforme








Percebam como a organização, utilizando estrutura de dados deixa o software mais fácil de ler e identificar.


modosOp.status.precondicoesDePartidaOK

modosOp.status.status.automatico


facilmente saber que estamos lidando com o status atual, e agora estamos somente internos dentro da função, e isso vai ficar ainda melhor quando for para o escopo global.


Mas ainda precisamos, falar das pré-condições de partida, que já estamos utilizando, porém, do que estamos falando? Seriam condições para que o equipamento possa funcionar de forma segura em automático, por exemplo emergência não acionada, falhas de sensores não ativas, nada mais são do que interlocks de segurança, e para identificar uma eventual parada por falta de condições é importante mostrar essas informações na interface homem máquina (IHM), por isso temos dentro da nossa estrutura de dados IHMLer, um array de interlocks.



Porém temos que avaliar as condições desse array para ter o status de pré-condições de partida Ok e também enviar para a IHM as informações.


Vale lembrar que a UDT_Interlocks tem a seguinte estrutura:







Então o interlock pode estar ativo ou não para ser avaliado, seu status (a condição está OK) a descrição que é uma string que vai para IHM informar a condição faltante.


Então qual é a premissa do interlock estar ok? Ele estar ativo e seus status ser verdadeiro, os interlocks que não estão ativos, são considerados verdadeiros por não estar em uso.


Interlocks serão utilizados em vários locais do software, como para liberar movimentos pneumáticos, etc., nesse caso faz sentido ter uma função para verificar as os interlocks ao invés de repetir a lógica a todo momento (reusabilidade), outra coisa, para facilitar a programação faz sentido também definir o tamanho dos arrays que serão utilizados para todos os interlocks no caso os modos de operação possuem 10 e vamos manter 10 para a função a ser criada.

Como vamos trabalhar com um array também é mais apropriado utilizar a linguagem de texto estruturado, e vamos ver como vai ser simples!



Veja como consigo verificar todos os meus interlocks em apenas 6 linhas!


Bom agora que eu tenho minha função de interlocks, finalmente posso verificar as minhas pré-condições de partida.


Pronto, agora eu tenho minhas pré-condições de partida verificadas, vou apenas copiar para a IHM.




O mesmo processo eu irei utilizar para criar todos os outros requisitos relacionados com a função modos de operação, como por exemplo, modo manual e dry-run.



A mesma lógica feita no Siemens e no Studio5000 da Rockwell








Até o próximo artigo,










331 views0 comments

Recent Posts

See All

Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating

Sobre Nos

SOCIALS 

Participe do nosso Grupo:

Telegram e  WhatsApp.
 

SUBSCRIBE 

PLC com Engenharia de Sofware nasceu de um grupo de WhatsApp, que teve suas origens em 2018 em outro grupo, e criado oficialmente em 2020. Depois de solicitação seus participantes e outras pessoas que gostam do trabalho, vem a criação desse Blog para trazer alguns artigos, apostilas e tamém sempre que possível notícias.

Se inscreva para receber notificações de novas postagens!

Obrigado por sua Inscrição

© 2035 by FEEDs & GRIDs. Powered and secured by Wix

bottom of page