TCC_DOC
45
1 ETEP - FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS UTILIZAÇÃO DE MODEL BASED DESIGN NA GERAÇÃO AUTOMÁTICA DE PROGRAMAS PARA PROJETO DE SISTEMAS DE CONTROLE COM CLP. Marcos Fernando Nantes Gonzaga Trabalho de Conclusão de Curso de Bacharelado em Engenharia Mecatrônica, orientado pelo Prof. Eng. M.Sc. Samuel J. da Silva ETEP Faculdades São José dos Campos 2015
-
Upload
marcos-gonzaga -
Category
Documents
-
view
114 -
download
0
Transcript of TCC_DOC
1
ETEP - FACULDADE DE TECNOLOGIA
DE SÃO JOSÉ DOS CAMPOS
UTILIZAÇÃO DE MODEL BASED DESIGN NA GERAÇÃO
AUTOMÁTICA DE PROGRAMAS PARA PROJETO DE SISTEMAS DE
CONTROLE COM CLP.
Marcos Fernando Nantes Gonzaga
Trabalho de Conclusão de Curso de Bacharelado em Engenharia Mecatrônica,
orientado pelo Prof. Eng. M.Sc. Samuel J. da Silva
ETEP Faculdades
São José dos Campos
2015
2
ETEP - FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS
CAMPOS
UTILIZAÇÃO DE MODEL BASED DESIGN NA GERAÇÃO
AUTOMÁTICA DE PROGRAMAS PARA PROJETO DE SISTEMAS DE
CONTROLE COM CLP.
_______________________________
Marcos Fernando Nantes Gonzaga
_______________________________
Prof. Eng. M.Sc. Samuel J. da Silva
Orientador Acadêmico
ETEP Faculdades
São José dos Campos
2015
3
AGRADECIMENTOS
Agradeço primeiramente a Deus e a minha mãe. Agradeço aos meus professores, pela
dedicação e compreensão, principalmente neste final de curso, em especial ao meu orientador:
Samuel Silva que me ajudou desde a definição do tema deste trabalho, que possibilitou aplicar
ferramentas de engenharia e conceitos aprendidos nestes cinco anos de graduação sem deixar
de aproveitar minhas experiências adquiridas anteriormente.
4
RESUMO
Quando se fala em automação, surgem algumas divergências de opiniões envolvendo
confiabilidade ligada ao hardware utilizado e limitações de software bem como a capacidade
de processamento. Desta forma surgem os que defendem o uso de hardware baseado em PC,
que possuem grande capacidade de processamento e devido a este fato, possuem um poderoso
software, normalmente, programado em linguagem gráfica de alto nível capaz de realizar
operações complexas através de uma interface gráfica amigável. Em contrapartida, existem os
que defendem a confiabilidade de uma plataforma estável e já consagrada em ambiente
industrial que é o Controlador Lógico Programável (CLP), mas que possui limitações de
processamento e armazenamento quando comparados aos recursos de um PC, tornando a
programação de sistemas complexos, uma tarefa extremamente difícil. Este trabalho descreve
detalhadamente uma metodologia capaz de aproximar estes dois mundos citados
anteriormente: utilizando-se de uma poderosa e amplamente conhecida ferramenta
computacional de engenharia, e graças a padronização internacional nas linguagens de
programação de CLP’s, é possível modelar um determinado sistema e obter automaticamente
a rotina de CLP correspondente ao modelo, pronto para uso e para ser embarcada em um
controlador. Os resultados obtidos demonstram que o método se torna mais interessante à
medida que a complexidade do sistema de controle aumenta, mas também foram encontradas
limitações e dificuldades inerentes à metodologia. Não existe uma fórmula ou regra para a
escolha de determinada metodologia para o desenvolvimento de um projeto, cada projeto
pode ter uma que apresente melhores resultados, ou a própria experiência da equipe pode
apresentar maior rendimento com determinado método, este trabalho apresenta mais uma
metodologia que pode ser utilizada, inclusive em conjunto com outras visando reduzir o
tempo e aumentar a robustez do processo de criação de software de controle.
Palavras Chave: Controlador Lógico Programável, Programmable Logical Controller, Model
Based Design, CLP, PLC, MBD, automação.
5
Sumário
AGRADECIMENTOS ................................................................................................... 3
RESUMO ........................................................................................................................ 4
Lista de Figuras ............................................................................................................... 7
Lista de Tabelas .............................................................................................................. 8
1 INTRODUÇÃO ....................................................................................................... 9
1.1 Objetivo .......................................................................................................... 10
1.2 Justificativa ..................................................................................................... 10
2 FUNDAMENTAÇÃO TEÓRICA ......................................................................... 11
2.1 MODEL BASED DESIGN ............................................................................ 11
2.1.1 Modelagem ................................................................................................ 12
2.1.2 Simulação .................................................................................................. 12
2.1.3 Ferramentas Computacionais ..................................................................... 13
2.2 CONTROLADOR LÓGICO PROGRAMÁVEL (CLP) ................................ 15
2.2.1 Linguagens de Programação ...................................................................... 16
2.2.2 IEC 61131-3 ............................................................................................... 19
2.2.3 Automação ( Breve histórico ) ................................................................... 19
2.3 COMPONENTES DA PROVA DE CONCEITO .......................................... 20
2.3.1 Motor de Corrente Contínua ...................................................................... 20
2.3.2 Controlador PID ......................................................................................... 22
3 METODOLOGIA .................................................................................................. 25
3.1 Modelagem do motor de corrente contínua .................................................... 27
3.1.1 Parte mecânica ........................................................................................... 28
3.1.2 Parte elétrica: ............................................................................................. 29
3.1.3 Modelo do motor de corrente contínua ...................................................... 30
3.2 Modelo completo do sistema a ser embarcado ............................................... 31
3.3 Rockwell RSLogix 5000 ................................................................................. 33
6
4 RESULTADOS ...................................................................................................... 36
5 CONCLUSÃO ....................................................................................................... 39
6 Referências: ............................................................................................................ 40
7 Anexos .................................................................................................................... 41
7.1 Anexo 1 – Arquivo de texto gerado pelo MatLab .......................................... 41
7.2 Anexo 2 – Texto após importação pelo RSLogix ........................................... 44
7
Lista de Figuras
Figura 1.1 - Automação baseada em PC ......................................................................... 9
Figura 2.1 - Ambiente Simulink ................................................................................... 14
Figura 2.2 - Diagrama Ladder ...................................................................................... 16
Figura 2.3 - Linguagem texto Estruturado .................................................................... 17
Figura 2.4 - Diagrame de blocos ................................................................................... 18
Figura 2.5 - Diagrama Grafcet ...................................................................................... 18
Figura 2.6 - Motor de Corrente Contínua ..................................................................... 20
Figura 2.7 - Controlador PID ........................................................................................ 22
Figura 2.8 - Método 1 Ziegler-Nichols ......................................................................... 23
Figura 2.9 - Obtenção do valor de período crítico ........................................................ 24
Figura 3.1 - Sequência Metodológica ........................................................................... 25
Figura 3.2 - Requisitos mínimos ................................................................................... 26
Figura 3.3 - Configuração utilizada .............................................................................. 26
Figura 3.4 - Diagrama Funcional Motor CC ................................................................ 27
Figura 3.5 - Modelo Motor CC - Componentes Mecânicas ......................................... 28
Figura 3.6 - Modelo Motor CC - Componentes Elétricas ............................................ 29
Figura 3.7 - Modelo Motor CC ..................................................................................... 30
Figura 3.8 - Modelo com controlador PID ................................................................... 31
Figura 3.9 - Modelo Completo ..................................................................................... 31
Figura 3.10 - Configurando a geração de programas.................................................... 32
Figura 3.11 - Importação do arquivo ............................................................................ 33
Figura 3.12 – Bloco criado com a importação do Arquivo .......................................... 34
Figura 3.13 - Tela do RSLogix 5000 ............................................................................ 35
Figura 4.1 – Resposta do sistema em malha aberta ...................................................... 36
Figura 4.2 – Resposta em malha fechada ..................................................................... 36
Figura 4.3 – Malha fechada ampliado .......................................................................... 36
8
Lista de Tabelas
Tabela 2.1 - Valores dos ganhos - método 1 ................................................................ 23
Tabela 2.2 - Valores dos ganhos - método 2 ................................................................ 24
Tabela 3.1 - Parâmetros do Motor ................................................................................ 27
Tabela 4.1 – Resultados do modelo embarcado ........................................................... 37
9
1 INTRODUÇÃO
Com a contínua e crescente evolução da informática, bem como a redução
significativa nos custos de componentes de hardware, em alguns setores da indústria,
surgiram frentes de automação baseadas em microcomputador pessoal (PC) que podem ser
industriais, ou em alguns casos onde o ambiente é menos agressivos, PC´s convencionais.
Quando comparada com a automação clássica baseada em controladores dedicados
(normalmente controladores lógicos programáveis – CLP´s), este tipo de automação apresenta
vantagens na integração com outros sistemas por estar sendo executado em um PC, em
sistema operacional padrão (Windows, por exemplo), este diferencial vem sendo superado
com a utilização de CLP´s conectados a supervisórios que são executados em PC´s. Mas a
principal vantagem talvez esteja na programação da lógica de controle, pois possui disponível
todo o vasto recurso de software para PC.
O gráfico a seguir, obtido através de uma pesquisa da revista Mecatrônica Atual, nos
dá uma ideia do cenário de aceitação desta tecnologia.
Figura 1.1 - Automação baseada em PC
Fonte: Adaptado de (Revista Mecatrônica Atual,2013)
Em contrapartida, existe também uma rejeição relativamente grande, alegando que um
sistema baseado em PC não possui a confiabilidade de um sistema de controle que utiliza
como hardware principal um controlador dedicado.
A decisão se torna ainda mais difícil quando o sistema a ser controlado é de alta
complexidade matemática, e precisa ser desenvolvido em curto espaço de tempo, estes dois
requisitos tendem a direcionar a decisão para uma plataforma de automação baseada em PC.
43%
27%
24% 6%
O que você acha de automação baseada em PC?
É uma tecnologia que euimplantaria
Não tenho conhecimentosuficiente para julgar
Implantaria empartes dosistema
Jamais confiaria em processosbaseadoem PC
10
1.1 Objetivo
A proposta deste trabalho é apresentar uma metodologia de desenvolvimento de
projetos de sistema de controle para aplicações complexas, baseado em controladores lógicos
programáveis que, utilizando-se de recursos computacionais existentes gera automaticamente
o software do CLP em linguagem de texto estruturado conforme norma IEC-61131-3.
Desta forma, torna-se possível reduzir o tempo total de desenvolvimento, já que o
ambiente integrado é capaz de simular o modelo durante a fase de desenvolvimento e testes
podem ser realizados antes mesmo de existir o sistema de controle ou o sistema a ser
controlado e ainda utilizar recurso computacional para facilitar a geração de código através de
programas de modelagem matemática.
1.2 Justificativa
A utilização desta metodologia tem como principais vantagens sobre as metodologias
convencionais de desenvolvimento de projetos: a redução do tempo de desenvolvimento;
redução do custo de desenvolvimento, uma vez que se reduz a fabricação de modelos físicos
(protótipos), aumento na confiabilidade do projeto, já que o sistema de controle pode ser
testado antes mesmo do CLP estar disponível.
À medida que a aplicação cresce em complexidade, proporcionalmente, esta
metodologia apresenta ganhos no tempo de elaboração do software de controle, já que a
programação convencional vai se tornando confusa e cada vez mais sujeita a erros.
11
2 FUNDAMENTAÇÃO TEÓRICA
Para facilitar a compreensão e contextualização, o trabalho proposto foi dividido em
três partes principais: Modelagem computacional; Controlador Lógico Programável; Modelo
para a prova de conceito.
A modelagem é o centro da metodologia apresentada, já que é uma metodologia
baseada em modelo (Model Based Design), o CLP é objeto principal pelo qual o trabalho foi
realizado e a prova de conceito foi a maneira escolhida de comprovar a eficácia do método.
2.1 MODEL BASED DESIGN
Para o desenvolvimento de um projeto, desde sua concepção, passando-se por etapas
fabricação de protótipos até o seu encerramento, todo o caminho percorrido na ordem em que
cada etapa é executada, é chamado de “Metodologia de Desenvolvimento de Projeto”,
algumas destas metodologias foram sofrendo padronizações e aperfeiçoamentos e ganharam
destaque no cenário atual por apresentarem características como:
• Redução no custo de desenvolvimento;
• Redução no tempo total de desenvolvimento;
• Diminuição na quantidade de iterações e retrabalhos, reduzindo custo e tempo;
• Robustez na metodologia, que traz como consequência, a padronização dos
resultados, mesmo quando desenvolvidos por equipes diferentes.
Algumas das etapas comuns em diversas metodologias podem ser realizadas de
maneiras diferentes, mas buscando-se os mesmos indicadores. Um exemplo deste fato é a fase
de testes do desenvolvimento, quando o projeto atinge certo grau de maturidade, passa por
vários testes a fim de se estabelecer parâmetros para confirmar conceitos adotados, ou
realimentar informações que ajudem a melhorar o desempenho do sistema.
Em metodologias convencionais, na etapa de testes é imprescindível que se tenha um
protótipo (muitas vezes chamado de modelo físico ou real) para ser ensaiado, porém algumas
metodologias fazem uso de modelos matemáticos e simulação computacional para estudar o
comportamento do sistema em desenvolvimento e suas reações diante das mais diversas
situações.
O protótipo possui um custo e prazo associado a sua fabricação, e um novo custo e
tempo de retrabalho, cada vez que se descobre algum problema nos ensaios. O modelo
12
matemático computacional requer apenas “ajustes” nas equações para que represente o novo
sistema corrigido, eliminando os custos de fabricação, matéria prima e montagem.
Para cada tipo de projeto e de acordo com o conjunto de requisitos deste projeto, pode
haver uma metodologia que seja mais adequada, não é simples definir qual é a melhor de
todas as metodologias de desenvolvimento.
Model Based Design é uma metodologia de desenvolvimento de projetos, baseada na
modelagem e simulação de um sistema a ser projetado. Nessa metodologia, o modelo do
sistema é o centro do processo de desenvolvimento, desde a geração dos requisitos até o
projeto, a implementação e os testes.
2.1.1 Modelagem
Modelagem matemática de um sistema físico é a representação deste sistema através
de equações matemáticas de tal forma que este modelo possa reagir a estímulos de maneira
idêntica ou muito próxima as reações do sistema real.
Uma das maneiras simples de se criar o modelo matemático de um sistema físico, é
utilizando-se condições de entrada que gerem respostas conhecidas na saída deste sistema,
quanto mais condições conhecidas forem usadas, maior será a chance de este modelo
representar o sistema para quaisquer outros conjuntos de condições. Para sistemas mais
complexos, existem metodologias próprias para a criação dos modelos.
A resposta do sistema modelado será tão próxima a resposta do sistema real, quanto
maior for a fidelidade e, consequente complexidade, do modelo matemático criado.
De acordo com Ogata (2009), existe um ponto ideal que relaciona a simplicidade do
modelo e a precisão dos resultados obtidos pela análise dos dados de resposta do sistema
modelado. Em alguns casos são, intencionalmente, desprezadas certas propriedades de
características não lineares, que causam diferenças desprezíveis entre os resultados da análise
computacional e os resultados experimentais do sistema físico.
2.1.2 Simulação
Simulação é o processo pelo qual o modelo é excitado e responde aos estímulos
aplicados.
13
2.1.3 Ferramentas Computacionais
Existem muitas ferramentas computacionais capazes de criar um modelo matemático e
executar sua simulação, algumas específicas para determinadas áreas do conhecimento, outras
mais genéricas capazes de criar modelos para diversas aplicações. Uma das ferramentas mais
poderosas e reconhecidas neste aspecto é o software denominado MatLab, criado pela
empresa The Mathworks Inc., EUA.
2.1.3.1 Matlab
Segundo Felício (2010), o MATLAB é um software de computador baseado em
matrizes para cálculos matemáticos e de engenharia, que reúne várias funcionalidades como
análise numérica, cálculo matricial, aquisição, processamento e análise de sinais, construção
de gráficos, algoritmos e modelagem e simulação em ambiente interativo, no qual o elemento
básico é uma matriz que não precisa ser dimensionada.
A operação do software é, de certa forma, intuitiva, sendo mais próxima da escrita
convencional matemática do que de uma linguagem de programação que possui regras de
sintaxe e acaba exigindo um tempo de aprendizado maior, como é o caso do tradicional
Fortran, por exemplo. No MATLAB, os comandos são digitados na linha de comando, ou
podem ser armazenados em arquivo de texto na forma de programa (script).
Assim como os demais softwares, o MATLAB possui algumas rotinas pré-definidas
(em outros softwares conhecidas como funções, sub-rotinas ou macros) que facilitam sua
programação. Outra forma de se obter programas pré-definidos para uso no MATLAB são as
toolboxes, que trazem funções adicionais sobre aplicações específicas.
2.1.3.2 Simulink
O Simulink, é um pacote de software para análise de sistemas dinâmicos que oferece
suporte em sistemas lineares e não lineares. Possui uma interface gráfica de usuário (GUI)
para a construção de modelos como diagramas de blocos, por exemplo. O Simulink possui
uma biblioteca de blocos prontos, mas permite personalizar modelos com a criação de blocos
específicos.
14
Para a simulação e visualização dos resultados, existem blocos para geração de
gráficos, que permitem o acompanhamento da resposta do sistema, inclusive alterando-se
parâmetros do modelo durante a simulação.
Com o Simulink, é possível criar uma máquina ou aparelho que não existe fisicamente
e observar seu funcionando antes que venham a existir.
Figura 2.1 - Ambiente Simulink
Fonte: Autor, 2015.
15
2.2 CONTROLADOR LÓGICO PROGRAMÁVEL (CLP)
Controlador Lógico Programável (CLP) ou em inglês PLC, para Rosário (2005), é um
dispositivo eletrônico que possui memória interna programável, e que é capaz de armazenar e
executar sequências de comandos lógicos binários, e outros.
Segundo a norma ABNT, o CLP é definido como um equipamento eletrônico-digital
compatível com aplicações industriais.
Em outras palavras, um CLP é um dispositivo que possui um microprocessador, para
uso industrial, possui entradas e saídas digitais e analógicas, possui capacidade de
armazenamento (para programas e dados) e é capaz de executar tomadas de decisão
(controlar) segundo condições pré-estabelecidas em sua programação. Além disso, este
equipamento, hoje, conta com canais de comunicação, que permite a troca de informações
com outros dispositivos.
Existem equipamentos com número fixo de entradas e saídas e existem equipamentos
chamados “modulares”, pois permitem a expansão do número de pontos, o fator limitante
neste caso é a capacidade do processador em gerenciar este número de entradas e saídas.
O funcionamento do CLP pode ser resumido em:
Leitura dos sinais de entrada;
Execução da lógica inserida para a obtenção dos valores de saída;
Atualização das saídas físicas;
Esta sequência de tarefas vem definida no chamado firmware do equipamento, é
executada ciclicamente enquanto o CLP estiver em operação. O tempo de execução deste
ciclo é conhecido como scan time, que pode ser traduzido como tempo de varredura, e está
associado a performance do CLP, quanto menor o valor, melhor o equipamento, pois será
capaz de responder adequadamente, a estímulos de menor período de duração, ou seja,
variações mais rápidas podem ser detectadas.
A linguagem mais utilizada na programação dos CLP´s é a linguagem LADDER,
também conhecida como diagrama de contatos. Esta linguagem teve grande aceitação devido
às semelhanças entre o programa gerado e os esquemas elétricos de máquinas antigas,
baseados em lógica de relé.
Os programas são implementados com o auxílio de um microcomputador com um
software de desenvolvimento, e cada fabricante possui seu próprio ambiente de programação
que pode verificar, compilar e enviar para a CPU do CLP.
16
O CLP vem sendo amplamente aplicado na indústria, nos mais diversos segmentos,
como solução na automação de máquinas ou de processos contínuos.
2.2.1 Linguagens de Programação
As linguagens de programação para CLP podem ser gráficas ou textuais. Após a
elaboração da norma IEC-61.131-3, houve a padronização, por parte dos fabricantes de
controladores em cinco linguagens:
2.2.1.1 LADDER (LD);
Ladder é uma linguagem gráfica que utiliza símbolos que faz com que os programas
desenvolvidos tenham certas semelhanças com diagramas elétricos de comando baseados em
lógica de relé, por este motivo a linguagem se tornou a mais popular no meio industrial, e é a
mais indicada para a maioria dos programas utilizados em máquinas sequenciais. O exemplo a
seguir foi extraído do software Click2Edit da WEG.
Figura 2.2 - Diagrama Ladder
Fonte: Autor, 2015.
O nome da linguagem (Ladder, escada em inglês) é uma referência a disposição dos
símbolos de contatos e bobinas, que lembra o formato de uma escada.
17
2.2.1.2 Texto Estruturado (ST);
Esta linguagem de texto é considerada como evolução da linguagem Pascal, sendo
portando de fácil utilização para programadores C, Pascal, Java, etc. É uma linguagem de alto
nível possui estruturas da linguagem como IF, THEN, ELSE, DO, bem como muitos outras. É
uma linguagem muito poderosa, porém mais familiar para um programador de computador,
do que para um técnico eletromecânico. Linguagens textuais são mais recomendadas para
aplicações complexas, e é exatamente a utilizada nesse estudo.
Figura 2.3 - Linguagem texto Estruturado
Fonte: Autor, 2015.
2.2.1.3 Lista de Instruções (IL);
Linguagem textual e segundo Lewis (1998) A linguagem Instruction List para CLP se
assemelha à linguagem assembly e é usada para fornecer a lógica de controle para o
dispositivo de acordo com as entradas de dados no tempo. Esta linguagem é classificada como
sendo de mais baixo nível, ou seja, está mais próxima do que o processador realmente
entende, sem grandes alterações durante a compilação. Seria mais indicada para sistemas que
exigem altíssimo processamento e resposta rápida, mas devido a evolução no hardware pode
não fazer tanta diferença hoje em dia.
18
2.2.1.4 Diagrama de blocos (FBD);
Linguagem gráfica que utiliza símbolos lógicos e blocos funcionais. Esta talvez seja a
linguagem de mais alto nível, isto é, talvez a mais fácil de se programar, inclusive para
pessoas sem experiência de programação, mas é limitada, quando o sistema se torna
complexo. Abaixo um exemplo extraído do software de programação LOGO! Soft Confort
utilizado para programar o CLP de pequeno porte da SIEMENS, chamado LOGO!
Figura 2.4 - Diagrame de blocos
Fonte: Autor, 2015.
2.2.1.5 Grafcet (SFC).
É uma linguagem gráfica sequencial, com transições e etapas bem definidas, apresenta
grande vantagem para processos sequenciais e cíclicos.
Figura 2.5 - Diagrama Grafcet
Fonte: Autor, 2015.
19
2.2.2 IEC 61131-3
Esta é a terceira parte de um total de oito, de uma norma internacional que
regulamenta hardware e software para controladores programáveis industriais. Esta norma
teve sua primeira edição em dezembro de 1993 e a revisão mais recente data de fevereiro de
2013.
Esta regulamentação abrange modelos de arquitetura, de software, de comunicação, e
de programação para este equipamento. Além disso, define tipos de dados e variáveis.
2.2.3 Automação ( Breve histórico )
Automatizar significa tornar automático, isto é, fazer com que um determinado
processo realize suas funções com o mínimo de intervenção, ou até mesmo sem qualquer
intervenção. Na indústria, podemos encontrar automação em diversos níveis, não só no
processo produtivo (fabricação), mas no transporte de materiais, ou ainda no fluxo de
informação.
A automação de máquinas, células de produção e processos contínuos, normalmente
utiliza o CLP como o principal equipamento de controle.
Conforme publicado na revista Mecatrônica Atual, 2013, a primeira aplicação
industrial de um CLP, surgiu da necessidade de uma das fábricas da General Motors, na
década de 1960, em atualizar uma das linha de produção e fazer esta atualização de forma
mais rápida, alterando-se apenas o software de controle, ou seja fazer com que a linha tivesse
alguma flexibilidade.
Ainda de acordo com a matéria, o primeiro CLP produzido em série, foi o modelo o84
da MODICON, criado por Dick Morley.
20
2.3 COMPONENTES DA PROVA DE CONCEITO
Com a finalidade de demonstrar a metodologia estudada foi criado um modelo
matemático representando um sistema composto por um motor de corrente contínua e um
controlador com opções de controle selecionáveis por entradas específicas.
2.3.1 Motor de Corrente Contínua
O Motor de Corrente Contínua é uma máquina elétrica rotativa capaz de converter
eletricidade (na forma de corrente contínua) em torque mecânico (na forma de potência de
eixo). Construtivamente possui uma armadura rotativa e um campo estacionário.
O campo pode ser obtido através de imãs permanentes, mas normalmente é
conseguido através de um conjunto de bobinas indutoras. A armadura, também recebe o nome
de induzido e constitui o rotor que recebe alimentação através do coletor, uma espécie de anel
segmentado, que alimenta os conjuntos de bobinas através de escovas.
Figura 2.6 - Motor de Corrente Contínua
Fonte: Adaptado de (KOSOW, 1982)
21
Segundo Kosow (1982), o torque (T) gerado pelo motor pode ser calculado pela
seguinte equação:
𝑇 = 𝐾∅. 𝑖 Equação 2.1
Onde, (K) é uma constante e depende do projeto construtivo do motor (número de
pólos, condutores, etc.), (∅) é o fluxo magnético por pólo, e (i) é a corrente de armadura. É
possível notar que o torque aumenta com o aumento da corrente e/ou do fluxo magnético, pois
a força magnética também aumenta.
Ainda segundo o mesmo autor, a força contra eletromotriz (EG) será dada por:
𝐸𝐺 = 𝐾. ∅. 𝑛. 𝑉 Equação 2.2
Onde, (n) é a velocidade expressa em [rpm] e K é uma constante que depende de
características construtivas do motor. Neste caso a tensão induzida (EG) aumenta com a
velocidade e com o aumento do fluxo magnético.
Analisando-se o circuito da armadura, pode-se deduzir que:
𝐸𝐺 = 𝑉𝐴 + 𝑅𝐴. 𝑖 Equação 2.3
Sendo (VA) a tensão aplicada na armadura, (RA) a resistência interna e (i) a corrente.
22
2.3.2 Controlador PID
De acordo com Ogata (2009) mais da metade dos controladores utilizados em
aplicações industriais são do tipo PID ou PID modificados, que em aplicações gerais podem
prover um controle satisfatório mesmo quando não se conhece o modelo matemático da planta
a ser controlada.
Para Dorf e Bishop (2001) a popularidade dos controladores PID se deve a robustez de
desempenho, a grande faixa de condições operacionais e simplicidade funcional.
O controle através deste dispositivo é obtido pela diferença entre o valor que se deseja
(ENTRADA) e o valor medido por uma realimentação do valor da saída, multiplicada pelos
ganhos proporcional (P), integral (I) e derivativo (D).
Figura 2.7 - Controlador PID
Fonte: Adaptado de (ASTRÖM E MURRAY, 2008).
A partir do diagrama funcional acima, é possível verificar que a saída do controlador
u(t) será calculada como:
𝑢(𝑡) = 𝐾𝑝. 𝑒(𝑡) + 𝐾𝑖. ∫ 𝑒(𝑡)𝑑𝑡 + 𝐾𝑑
𝑑𝑒(𝑡)
𝑑𝑡
Para que o controle seja efetivo e haja a estabilidade desejada com o tempo de resposta
esperado, é necessário sintonizar o controlador, ou seja, estabelecer os valores dos ganhos de
forma que haja um equilíbrio resultando na resposta pretendida.
𝐾𝑝
𝐾𝑖 ∫ 𝑒(𝑡)𝑑𝑡
𝐾𝑑𝑑𝑒(𝑡)/𝑑𝑡
23
Este processo de sintonia ou determinação dos valores dos ganhos pode ser realizado
de forma manual, mas alguns sistemas ou controladores possuem opções de sintonia
automática (self-tuning), onde o próprio sistema se parametriza.
Existem alguns métodos para o ajuste dos ganhos, segundo Ogata (2009), existem dois
métodos denominados Ziegler-Nichols.
O primeiro método determina os valores dos ganhos em função da resposta da planta
em função de um degrau na entrada:
Figura 2.8 - Método 1 Ziegler-Nichols
Fonte: OGATA (2009).
A partir dos valores de L e T do gráfico, determinam-se os ganhos pela tabela abaixo:
Tabela 2.1 - Valores dos ganhos - método 1
Fonte: OGATA (2009).
24
O segundo método baseia-se no período crítico e nos valores de ganhos críticos que
colocariam o sistema em oscilação permanente.
Figura 2.9 - Obtenção do valor de período crítico
Fonte: OGATA (2009).
E neste método calculam-se os valores pela tabela a seguir:
Tabela 2.2 - Valores dos ganhos - método 2
Fonte: OGATA (2009).
25
3 METODOLOGIA
Para comprovar o funcionamento do método de geração automática de programas
proposto, desenvolveu-se um modelo matemático no MATLAB / SIMULINK contendo um
motor de corrente contínua, um controlador PID operando em malha fechada, e lógica de
seleção. Este modelo completo representa todo o código a ser embarcado no CLP.
Figura 3.1 - Sequência Metodológica
Fonte: Autor, 2015.
DEFINIÇÕES
REQUISITOS
SISTEMAS A SEREM
MODELADOS
MODELAGEM
IDENTIFICAÇÃO
EQUAÇÕES
LEIS DA FÍSICA
VALIDAÇÃO
SIMULAÇÃO
GERAÇÃO DO CÓDIGO
EXPORTAÇÃO NO MATLAB
IMPORTAÇÃO NO
SOFTWARE DO PLC
UTILIZAÇÃO DA ROTINA
IMPORTADA
CONCLUSÃO
TESTES
ENTREGA
1 2 3 4
1.1 2.1 3.1 4.1
1.2 2.2 3.2 4.2
2.3 3.3
2.4
2.5
26
Em teoria, para se utilizar o método, principalmente nas etapas principais: “2-
Modelagem” e “3-Geração de código” da figura 3.1, precisa-se basicamente dos recursos
apresentados na figura 3.2, a seguir:
Figura 3.2 - Requisitos mínimos
Fonte: Autor, 2015.
Para a demonstração do funcionamento, verificou-se alguma incompatibilidade entre
os softwares utilizados, no que se refere aos respectivos sistemas operacionais, isto é, a versão
2011 do MatLab utilizada na etapa de modelagem, era para um sistema operacional de 64 bits,
enquanto o software de programação do PLC utilizado era uma versão para sistema
operacional de 32 bits. Para resolver esta questão, utilizou-se uma máquina virtual rodando
Windows XP, instalada em uma máquina real com Windows 7(64), onde foi instalado o
MatLab. Além desse problema, não foi possível utilizar um PLC real, desta forma utilizou-se
um emulador, chamado Emulate 5000 chS monitor executado no mesmo ambiente XP do
Logix. Utilizou-se, portanto, a configuração apresentada na figura 3.3:
Figura 3.3 - Configuração utilizada
Fonte: Autor, 2015.
Texto Estruturado
MATLAB
RSLogix 5000 PLC
Texto Estruturado
MATLAB
RSLogix 5000 RSEmulate 5000
27
3.1 Modelagem do motor de corrente contínua
Felício (2010), afirma que a elaboração do modelo de um sistema físico possui
fundamentalmente quatro partes: hipótese; aplicação de leis básicas do conhecimento
científico; relações entre as variáveis; validação do modelo. A partir desta definição, foi
possível iniciar a modelagem deste componente.
O motor de corrente contínua, possui características elétricas e mecânicas envolvidas
no processo de criação do modelo matemático, bem como parâmetros e variáveis específicos
para cada parte do modelo, conforme figura 3.4:
Figura 3.4 - Diagrama Funcional Motor CC
Fonte: (MESSNER E TILBURY, 2011)
Vamos assumir que a entrada do sistema, é a tensão (V) aplicada a armadura do motor,
enquanto que a saída é a velocidade de rotação d 𝜃 / dt. Os parâmetros físicos para o este
exemplo são apresentados na tabela 3.1.
Tabela 3.1 - Parâmetros do Motor
Parâmetro Valor Unidade
o momento de inércia do rotor J = 0,01 kg.m2;
constante de atrito viscoso do motor b = 0,1 Nms;
constante de força contra eletromotriz Ke = 0,01 V / rad / sec;
constante de torque do motor KT = 0,01 Nm / Amp;
resistência eléctrica R = 1 Ohm;
indutância eléctrica L = 0,5 H.
Fonte: Adaptado de (MESSNER E TILBURY, 2011)
28
3.1.1 Parte mecânica
O torque gerado por um motor de corrente contínua é proporcional à corrente do
induzido e a força do campo magnético. Neste exemplo, vamos supor que o campo magnético
é constante e, portanto, que o torque do motor é proporcional à corrente “i” do induzido
apenas por um fator constante Kt como mostrado na equação (1). Isto é conhecido como
motor controlado por armadura.
𝑇 = 𝐾𝑇. 𝑖 Equação 3.1
Observando-se a figura 3.1, pode-se verificar que as demais forças atuantes no motor
são o atrito que é proporcional a rotação, e a inércia gerada pela massa do rotor.
Desta forma, podemos escrever o torque em função das demais forças:
𝐾𝑇 . 𝑖 = 𝐽. �̈� + 𝑏. �̇�
𝐽. �̈� + 𝑏. �̇� = 𝐾𝑇 . 𝑖 Equação 3.2
Figura 3.5 - Modelo Motor CC - Componentes Mecânicas
Fonte: Autor, 2015.
29
3.1.2 Parte elétrica:
Observando-se a malha de tensão formada na figura 3.2 e sabendo-se que a força
contra eletromotriz é proporcional à velocidade angular vezes uma constante Ke, temos:
𝑒 = 𝐾𝑒 . �̇� Equação 3.3
𝑒 = 𝑉 − 𝑉𝑅 − 𝑉𝐿 ( 𝐾𝑖𝑟𝑐ℎ𝑜𝑓𝑓 )
e = V − R. i − Ldi
dt
𝐿𝑑𝑖
𝑑𝑡+ 𝑅. 𝑖 = 𝑉 − 𝐾𝑒 . �̇�
𝐿𝑑𝑖
𝑑𝑡= 𝑉 − 𝐾𝑒 . �̇� − 𝑅. 𝑖 Equação 3.4
Figura 3.6 - Modelo Motor CC - Componentes Elétricas
Fonte: Autor, 2015.
30
3.1.3 Modelo do motor de corrente contínua
Juntando-se as duas partes, obtem-se o modelo do motor, onde a entrada é um valor de
tensão e a saída o valor da rotação já em rpm, devido à conversão colocada através da
multiplicação de valor em radianos por segundo por uma constante com valor 60/(2. 𝜋).
Figura 3.7 - Modelo Motor CC
Fonte: Autor, 2015.
Como o modelo será utilizado para a geração de código em texto estruturado para ser
embarcado em um processador de um CLP, os integradores assim como o controlador PID
devem ser discretos, e precisam ser configurados com um determinado valor de taxa de
amostragem. O valor deste tempo de amostragem deve ser suficientemente pequeno para
manter a precisão do sistema, sem ser pequeno demais para comprometer o processamento e a
varredura do programa. Desta forma adotou-se e padronizou-se o valor de 10 ms para todo
tempo de amostragem solicitado pelo modelo.
31
3.2 Modelo completo do sistema a ser embarcado
Para facilitar a compreensão o conjunto que representa o motor de corrente contínua
pode ser definido como um subsistema. Para completar o modelo acrescentou-se um
controlador e uma lógica de seleção para malha aberta e malha fechada, conforme figura 3.8:
Figura 3.8 - Modelo com controlador PID
Fonte: Autor, 2015.
O conjunto contendo o subsistema do motor de corrente contínua, com o controlador e
a lógica de seleção de malha aberta/malha fechada, foi reduzido a um novo subsistema
chamado “Modelo”, que representa exatamente o código que será gerado para ser embarcado
no CLP. Os blocos que estão fora deste subsistema não serão compilados, representam apenas
funcionalidades para uso no MatLab/Simulink, permitindo que o modelo seja validado.
Figura 3.9 - Modelo Completo
Fonte: Autor, 2015.
32
Com o modelo pronto, ajustou-se os valores dos ganhos do controlador PID, com a
função <Tune> do bloco MatLab.
Com o modelo pronto e validado, no próprio simulink, deve-se clicar com o botão
direito do mouse no subsistema que se deseja exportar para o CLP, fazendo surgir um menu
suspenso com a opção “PLC code generation - > Enable treat as atomic unit” que abrirá a
seguinte janela, onde o check box “Treat as atomic unit” deve ser marcado.
Das próximas vezes que clicar sobre o subsistema com o botão direito do mouse, o
menu mostrará outras opções para a geração efetiva do código em um arquivo de texto que
deverá ser guardado para uso futuro.
Figura 3.10 - Configurando a geração de programas
Fonte: Autor, 2015.
Cada sinal de entrada ou saída representado no bloco “Modelo” será exportado para o
programa do CLP como um respectivo sinal de entrada ou saída e deverá ser associado a uma
variável, no caso do CLP Rockwell, estas variáveis recebem o nome de TAG´s, e podem estar
associadas a entradas e saídas físicas do CLP.
Desta forma teremos no bloco do programa do CLP as TAG´s dos seguintes tipos:
ref - deverá ser associada a uma TAG do tipo REAL;
In1 - deverá receber o sinal de uma TAG booleana;
rpm, posrad e corrente - enviarão seus valores para TAG´s REAIS;
33
3.3 Rockwell RSLogix 5000
Depois de o modelo ter sido gerado, validado e o arquivo com a programação em texto
estruturado estar salvo, é hora de importar este arquivo no software de programação do CLP
escolhido, no caso deste trabalho optou-se por utilizar o RSLogix 5000.
Na janela de projeto mostrada abaixo, deve-se clicar com o botão direito em “Add-On
Instructions” e em seguida “Import Add-On Instruction”, isso fará com que o Logix 5000
solicite a localização do arquivo gerado no MatLab.
Figura 3.11 - Importação do arquivo
Fonte: Autor, 2015.
Feito isso, será criado um bloco contendo o conjunto de instruções que representa o
modelo gerado no MatLab.
34
O bloco criado automaticamente pelo método descrito pode interagir com os demais
componentes ligados ao CLP, ou seja, algum sinal elétrico proveniente de algum sensor
ligado a uma entrada analógica pode fornecer o valor da referência, uma entrada digital pode
acionar a opção de malha aberta ou fechada, e os valores de corrente, velocidade e posição
podem ser visualizados em uma interface homem-máquina ou software supervisório,
armazenados como registros do processo, utilizados para gerar alarmes ou sinais de tensão ou
corrente analógica em saídas adequadas.
Figura 3.12 – Bloco criado com a importação do Arquivo
Fonte: Autor, 2015.
35
O código gerado, que aparece na figura 3.12 como um bloco de instrução primeira
linha do programa em LADDER, consiste de uma rotina de quase 100 linhas de programação
em texto estruturado, que pode ser verificada detalhadamente no anexo 7.2. Estas linhas
poderiam ser digitadas instrução a instrução, ou obtidas da forma que foi apresentada, através
da geração automática a partir do modelo matemático, figuras 3.7 a 3.9.
Figura 3.13 - Tela do RSLogix 5000
Fonte: Autor, 2015.
Para realizar algumas medições de valores no software embarcado, programou-se de
maneira convencional em LADDER, uma pequena lógica que verifica o instante em que o
degrau foi comandado, e determina o tempo de estabilização do sistema (settling time). Este
tempo foi considerado como sendo o intervalo entre o disparo do degrau e o tempo em que a
velocidade medida (saída), assume o valor de 95% do valor comandado (setpoint).
Comparou-se estes resultados obtidos de valores pontuais medidos na execução do programa
com valores de pontos correspondentes dos gráficos gerados pelo simulink.
36
4 RESULTADOS
No ambiente de desenvolvimento MatLab / Simulink, a resposta do sistema foi
apresentada conforme figuras abaixo, a figura 4.1 mostra a simulação em malha aberta, onde a
resposta foi mais lenta e apresentou um erro de estado estacionário em torno de 50 rpm.
A linha amarela representa a entrada e a lilás mostra a resposta.
Figura 4.1 – Resposta do sistema em malha aberta
Fonte: Autor, 2015.
Figura 4.2 – Resposta em malha fechada
Fonte: Autor, 2015
Figura 4.3 – Malha fechada ampliado
Fonte: Autor, 2015
37
A figura 4.2 mostra a resposta do sistema em malha fechada, onde é possível perceber
a melhora do sistema com a utilização do controlado PID e a informação de realimentação. A
figura 4.3 mostra em detalhe a região mais próxima do topo do degrau.
Comparou-se o resultado programado no simulink com o resultado obtido no CLP:
Tabela 4.1 – Resultados do modelo embarcado
Valor do degrau: 1000 rpm Simulink CLP
Mal
ha
Aber
ta Overshoot 0 rpm 0 rpm
Settling Time 3.5 s 5.7 s
Erro de estado estacionário 35 rpm 36 rpm
Mal
ha
Fec
had
a Overshoot 0 rpm 0 rpm
Settling Time 0.1 s 0.24 s
Erro de estado estacionário 0 rpm 0 rpm
Fonte: Autor, 2015
Apesar de existirem divergências entre os valores obtidos pelo simulink e os valores
do CLP, o resultado representa de maneira satisfatória o comportamento de um motor de
corrente contínua associado a um controlador tipo PID.
Comparar a metodologia apresentada com a forma tradicional de desenvolvimento de
software para sistema de controle e quantificar os resultados em termos de tempo gasto na
elaboração do software poderia apresentar muita imprecisão devido a fatores e variáveis
diversos como: a experiência da equipe de desenvolvimento nas duas metodologias; a
complexidade do sistema a ser controlado, pois como já foi mencionado, esta metodologia
apresenta ganhos superiores à medida que o sistema se torna mais complexo. O exemplo
escolhido para a comprovação da eficiência do método, no entanto, demonstrou claramente a
rapidez na elaboração do software, não apenas pela geração do código, o que já seria uma
superioridade significativa, uma vez que gerar manualmente o código proposto despenderia
muito mais tempo, mas pela robustez do processo, quando o código é gerado, o modelo já foi
validado, evitando eventuais retrabalhos, além disso os modelos podem compor uma
biblioteca, com aproveitamento total para futuras aplicações.
Ao contrário do que se esperava no início do desenvolvimento deste trabalho, o
método não é tão abrangente nem mesmo tão versátil no que se refere a gama de fabricantes e
modelos de CLP. Por exemplo, para o fabricante Rockwell, existe um formato de saída
específico de código gerado pelo MatLab, para uma plataforma conhecida como família de
38
controladores Logix5000 em que os testes foram realizados e apresentaram resultados
conforme esperado. Porém este formato não funciona para as demais linhas de controladores
da própria Rockwell, muito menos para linhas de outros fabricantes.
Existem alguns formatos específicos para os principais modelos dos principais
fabricantes, mas o método pode não funcionar perfeitamente para todos os modelos de CLP´s
disponíveis no mercado, ou para funcionar em alguns modelos pode precisar de alguma
intervenção manual para ajustar a sintaxe do código.
39
5 CONCLUSÃO
Os CLP´s disponíveis no mercado apresentam cada vez mais capacidade de
processamento e recursos avançados de programação, com isso surgem novas possibilidades
de aplicações, mas, para se utilizar totalmente os novos recursos disponíveis, e explorar todo o
hardware, o trabalho do programador se torna cada vez mais complexo, e surge a necessidade
de um método de desenvolvimento capaz de auxiliar a geração de software para aplicações
complexas. Existem ainda os sistemas que podemos classificar como sendo de complexidade
mediana, e nestes casos, no mínimo, a utilização do método reduz significativamente o tempo
de desenvolvimento.
A utilização de Model Based Design para a geração de software em sistemas de
controle com CLP comprovou ter suas vantagens, principalmente simplificando a
programação de rotinas complexas, e diminuindo o tempo total de desenvolvimento.
Por outro lado, a programação convencional tem seu espaço garantido, uma vez que
nem todo o processo precisa ou pode ser modelado, enfim, o método pode e deve ser utilizado
com outros métodos de desenvolvimento e ainda juntamente com a programação
convencional, cada projeto possui um certo nível de complexidade, e consequentemente, uma
melhor metodologia para ser executado.
40
6 Referências:
______. NBR 14724: informação e documentação: trabalhos acadêmicos:
apresentação. Rio de Janeiro, 2011. 6 p.
ASTRÖM, Karl Johan; MURRAY, Richard M. FeedBack Systems – An Introduction
for Scientists and Engineers. 1a. ed. New Jersey: Princeton University Press, 2008
DORF, Richard C.; BISHOP, Robert H. Modern Control Sistems. 11ª. ed. Rio de
Janeiro: LTC, 2001
DOWNEY, Allen B. Physical Modeling in MATLAB. 1ª. ed. Boston: Needham,
2007
FELÍCIO, Luiz Carlos. Modelagem da dinâmica de sistemas e estudo da resposta.
2ª. ed. São Carlos: RiMa, 2010.
KOSOW, Irving Lionel. Máquinas Elétricas e Transformadoras. 1ª. ed. Porto
Alegre: Globo, 1982.
LEWIS, Robert W. Programming Industrial Control System IEEE Control.
Hardcover, 1998.
LYSHEVSKI, Sergey E. Engineering and Scientific Computations Using
MATLAB. Rochester: Wiley, 2003.
Mecatrônica Atual. A hora e a vez do PC industrial. Disponível em
<http://www.mecatronicaatual.com.br/educacao/807-a-hora-e-a-vez-do-pc-industrial>.
Acesso em 18 de dezembro de 2014.
Mecatrônica Atual. História dos controladores lógicos programáveis. Disponível em
<http://www.mecatronicaatual.com.br/educacao/1404-um-pouco-de-histria-sobre-os-
controladores-lgico-programveis-e-a-automao-industrial>. Acesso em 05 de dezembro de
2014.
MESSNER, Bill; TILBURY, Dawn. Control Tutorials for Matlab & Simulink.
Disponível em <http://ctms.engin.umich.edu/CTMS/index.php?example=MotorSpeed&
section=SystemModeling>. Acesso em 20 de dezembro de 2014.
NISE, Normam S. Engenharia de Sistemas de Controle. Rio de Janeiro: LTC, 2002.
OGATA, Katsuhiko. Modern Control Engineering. Boston : Prentice Hall, 2009.
PALM III, William, J. A Concise Introduction to MATLAB. Rhode Island:
McGraw-Hill, 2008.
ROSÁRIO, João Maurício. Princípios de Mecatrônica. São Paulo : Prentice Hall,
2005.
41
7 Anexos
Os anexos a seguir representam o programa gerado pelo MatLab antes e depois da
importação pelo RSLogix 5000, demonstrado que existe um pós processamento executado
pela importação no software da Rockwell.
7.1 Anexo 1 – Arquivo de texto gerado pelo MatLab
O texto a seguir, gerado automaticamente pelo modelo, representa um formato
específico para a importação do software RSLogix 5000, ou seja, não é um programa em texto
estruturado para CLP em conformidade com a norma IEC-61131-3, mas um conjunto de
instruções para serem interpretadas pelo software da Rockwell.
<?xml version="1.0" encoding="utf-8"?> <RSLogix5000Content ContainsContext="true" SchemaRevision="1.0" TargetName="Modelo0" TargetType="AddOnInstructionDefinition"> <Controller Name="Modelo" Use="Context"> <AddOnInstructionDefinitions> <AddOnInstructionDefinition Name="Modelo0" Use="Target"> <Parameters> <Parameter DataType="SINT" Name="ssMethodType" Required="true" Usage="Input" Visible="true"/> <Parameter DataType="REAL" Name="ref" Required="true" Usage="Input" Visible="true"/> <Parameter DataType="REAL" Name="In1" Required="true" Usage="Input" Visible="true"/> <Parameter DataType="REAL" Name="rpm" Required="true" Usage="Output" Visible="true"/> <Parameter DataType="REAL" Name="posrad" Required="true" Usage="Output" Visible="true"/> <Parameter DataType="REAL" Name="corrente" Required="true" Usage="Output" Visible="true"/> <Parameter DataType="REAL" Name="DiscreteTimeIntegrator1_DSTATE" Usage="Local" Visible="true"/> <Parameter DataType="REAL" Name="DiscreteTimeIntegrator_DSTATE" Usage="Local" Visible="true"/> <Parameter DataType="REAL" Name="Filter_DSTATE" Usage="Local" Visible="true"/> <Parameter DataType="REAL" Name="Integrator_DSTATE" Usage="Local" Visible="true"/> <Parameter DataType="REAL" Name="DiscreteTimeIntegrator2_DSTATE" Usage="Local" Visible="true"/> <Parameter DataType="REAL" Name="rtb_Conv" Usage="Local" Visible="true"/> <Parameter DataType="REAL" Name="rtb_FilterCoefficient" Usage="Local" Visible="true"/> <Parameter DataType="REAL" Name="rtb_dtetadt" Usage="Local" Visible="true"/> <Parameter DataType="REAL" Name="VL" Usage="Local" Visible="true"/> <Parameter DataType="REAL" Name="rtb_d2tetadt2" Usage="Local" Visible="true"/> <Parameter DataType="REAL" Name="Switch" Usage="Local" Visible="true"/> <Parameter DataType="REAL" Name="b_Add" Usage="Local" Visible="true"/> </Parameters> <Routines> <Routine Name="Logic" Type="ST"> <STContent> <Line Number="1"><![CDATA[]]></Line> <Line Number="2"><![CDATA[CASE ssMethodType OF]]></Line> <Line Number="3"><![CDATA[ 2: ]]></Line> <Line Number="4"><![CDATA[ (* InitializeConditions for Atomic SubSystem: '<S1>/Motor cc' *)]]></Line> <Line Number="5"><![CDATA[ ]]></Line> <Line Number="6"><![CDATA[ (* InitializeConditions for DiscreteIntegrator: '<S3>/Discrete-Time Integrator1' *)]]></Line> <Line Number="7"><![CDATA[ DiscreteTimeIntegrator1_DSTATE := 0;]]></Line> <Line Number="8"><![CDATA[ ]]></Line> <Line Number="9"><![CDATA[ (* InitializeConditions for DiscreteIntegrator: '<S3>/Discrete-Time Integrator' *)]]></Line> <Line Number="10"><![CDATA[ DiscreteTimeIntegrator_DSTATE := 0;]]></Line> <Line Number="11"><![CDATA[ ]]></Line> <Line Number="12"><![CDATA[ (* InitializeConditions for DiscreteIntegrator: '<S3>/Discrete-Time Integrator2' *)]]></Line> <Line Number="13"><![CDATA[ DiscreteTimeIntegrator2_DSTATE := 0;]]></Line> <Line Number="14"><![CDATA[ (* End of InitializeConditions for SubSystem: '<S1>/Motor cc' *)]]></Line> <Line Number="15"><![CDATA[ ]]></Line>
42
<Line Number="16"><![CDATA[ (* InitializeConditions for DiscreteIntegrator: '<S2>/Filter' *)]]></Line> <Line Number="17"><![CDATA[ Filter_DSTATE := 0;]]></Line> <Line Number="18"><![CDATA[ ]]></Line> <Line Number="19"><![CDATA[ (* InitializeConditions for DiscreteIntegrator: '<S2>/Integrator' *)]]></Line> <Line Number="20"><![CDATA[ Integrator_DSTATE := 0;]]></Line> <Line Number="21"><![CDATA[ 3: ]]></Line> <Line Number="22"><![CDATA[ (* Outputs for Atomic SubSystem: '<S1>/Motor cc' *)]]></Line> <Line Number="23"><![CDATA[ ]]></Line> <Line Number="24"><![CDATA[ (* Outport: '<Root>/corrente' incorporates:]]></Line> <Line Number="25"><![CDATA[ * DiscreteIntegrator: '<S3>/Discrete-Time Integrator1' *)]]></Line> <Line Number="26"><![CDATA[ corrente := DiscreteTimeIntegrator1_DSTATE;]]></Line> <Line Number="27"><![CDATA[ ]]></Line> <Line Number="28"><![CDATA[ (* DiscreteIntegrator: '<S3>/Discrete-Time Integrator' *)]]></Line> <Line Number="29"><![CDATA[ rtb_dtetadt := DiscreteTimeIntegrator_DSTATE;]]></Line> <Line Number="30"><![CDATA[ ]]></Line> <Line Number="31"><![CDATA[ (* Gain: '<S3>/Const. F. Eletromotriz' *)]]></Line> <Line Number="32"><![CDATA[ VL := 4.4E-6 * rtb_dtetadt;]]></Line> <Line Number="33"><![CDATA[ ]]></Line> <Line Number="34"><![CDATA[ (* Gain: '<S3>/Conv' *)]]></Line> <Line Number="35"><![CDATA[ rtb_Conv := 9.5492965855137211 * rtb_dtetadt;]]></Line> <Line Number="36"><![CDATA[ ]]></Line> <Line Number="37"><![CDATA[ (* Gain: '<S3>/Inercia' incorporates:]]></Line> <Line Number="38"><![CDATA[ * Gain: '<S3>/Amortecimento']]></Line> <Line Number="39"><![CDATA[ * Gain: '<S3>/Constante de Torque']]></Line> <Line Number="40"><![CDATA[ * Sum: '<S3>/Add1' *)]]></Line> <Line Number="41"><![CDATA[ rtb_d2tetadt2 := ((0.0244 * corrente) - (0.000219 * rtb_dtetadt)) * 2.3980815347721823E+6;]]></Line> <Line Number="42"><![CDATA[ (* End of Outputs for SubSystem: '<S1>/Motor cc' *)]]></Line> <Line Number="43"><![CDATA[ ]]></Line> <Line Number="44"><![CDATA[ (* Outport: '<Root>/rpm' *)]]></Line> <Line Number="45"><![CDATA[ rpm := rtb_Conv;]]></Line> <Line Number="46"><![CDATA[ ]]></Line> <Line Number="47"><![CDATA[ (* Outputs for Atomic SubSystem: '<S1>/Motor cc' *)]]></Line> <Line Number="48"><![CDATA[ (* Outport: '<Root>/posrad' incorporates:]]></Line> <Line Number="49"><![CDATA[ * DiscreteIntegrator: '<S3>/Discrete-Time Integrator2' *)]]></Line> <Line Number="50"><![CDATA[ posrad := DiscreteTimeIntegrator2_DSTATE;]]></Line> <Line Number="51"><![CDATA[ (* End of Outputs for SubSystem: '<S1>/Motor cc' *)]]></Line> <Line Number="52"><![CDATA[ ]]></Line> <Line Number="53"><![CDATA[ (* Sum: '<S1>/Sum' incorporates:]]></Line> <Line Number="54"><![CDATA[ * Inport: '<Root>/ref' *)]]></Line> <Line Number="55"><![CDATA[ rtb_Conv := ref - rtb_Conv;]]></Line> <Line Number="56"><![CDATA[ ]]></Line> <Line Number="57"><![CDATA[ (* Gain: '<S2>/Filter Coefficient' incorporates:]]></Line> <Line Number="58"><![CDATA[ * DiscreteIntegrator: '<S2>/Filter']]></Line> <Line Number="59"><![CDATA[ * Gain: '<S2>/Derivative Gain']]></Line> <Line Number="60"><![CDATA[ * Sum: '<S2>/SumD' *)]]></Line> <Line Number="61"><![CDATA[ rtb_FilterCoefficient := ((0.8 * rtb_Conv) - Filter_DSTATE) * 50;]]></Line> <Line Number="62"><![CDATA[ ]]></Line> <Line Number="63"><![CDATA[ (* Switch: '<S1>/Switch' incorporates:]]></Line> <Line Number="64"><![CDATA[ * DiscreteIntegrator: '<S2>/Integrator']]></Line> <Line Number="65"><![CDATA[ * Gain: '<S2>/Proportional Gain']]></Line> <Line Number="66"><![CDATA[ * Inport: '<Root>/In1']]></Line> <Line Number="67"><![CDATA[ * Inport: '<Root>/ref']]></Line> <Line Number="68"><![CDATA[ * Sum: '<S2>/Sum' *)]]></Line> <Line Number="69"><![CDATA[ IF In1 > 0 THEN ]]></Line> <Line Number="70"><![CDATA[ ]]></Line> <Line Number="71"><![CDATA[ Switch := ((10 * rtb_Conv) + Integrator_DSTATE) + rtb_FilterCoefficient;]]></Line> <Line Number="72"><![CDATA[ ELSE ]]></Line> <Line Number="73"><![CDATA[ Switch := ref;]]></Line> <Line Number="74"><![CDATA[ END_IF;]]></Line> <Line Number="75"><![CDATA[ (* End of Switch: '<S1>/Switch' *)]]></Line> <Line Number="76"><![CDATA[ ]]></Line> <Line Number="77"><![CDATA[ (* Update for Atomic SubSystem: '<S1>/Motor cc' *)]]></Line> <Line Number="78"><![CDATA[ (* Sum: '<S3>/Add' *)]]></Line> <Line Number="79"><![CDATA[ b_Add := (Switch - corrente) - VL;]]></Line> <Line Number="80"><![CDATA[ ]]></Line> <Line Number="81"><![CDATA[ (* Update for DiscreteIntegrator: '<S3>/Discrete-Time Integrator1' incorporates:]]></Line> <Line Number="82"><![CDATA[ * Gain: '<S3>/Indutancia' *)]]></Line> <Line Number="83"><![CDATA[ DiscreteTimeIntegrator1_DSTATE := ((2463.0541871921182 * b_Add) * 0.01) + DiscreteTimeIntegrator1_DSTATE;]]></Line> <Line Number="84"><![CDATA[ ]]></Line> <Line Number="85"><![CDATA[ (* Update for DiscreteIntegrator: '<S3>/Discrete-Time Integrator' *)]]></Line>
43
<Line Number="86"><![CDATA[ DiscreteTimeIntegrator_DSTATE := (0.01 * rtb_d2tetadt2) + DiscreteTimeIntegrator_DSTATE;]]></Line> <Line Number="87"><![CDATA[ ]]></Line> <Line Number="88"><![CDATA[ (* Update for DiscreteIntegrator: '<S3>/Discrete-Time Integrator2' *)]]></Line> <Line Number="89"><![CDATA[ DiscreteTimeIntegrator2_DSTATE := (0.01 * rtb_dtetadt) + DiscreteTimeIntegrator2_DSTATE;]]></Line> <Line Number="90"><![CDATA[ (* End of Update for SubSystem: '<S1>/Motor cc' *)]]></Line> <Line Number="91"><![CDATA[ ]]></Line> <Line Number="92"><![CDATA[ (* Update for DiscreteIntegrator: '<S2>/Filter' *)]]></Line> <Line Number="93"><![CDATA[ Filter_DSTATE := (0.01 * rtb_FilterCoefficient) + Filter_DSTATE;]]></Line> <Line Number="94"><![CDATA[ ]]></Line> <Line Number="95"><![CDATA[ (* Update for DiscreteIntegrator: '<S2>/Integrator' incorporates:]]></Line> <Line Number="96"><![CDATA[ * Gain: '<S2>/Integral Gain' *)]]></Line> <Line Number="97"><![CDATA[ Integrator_DSTATE := ((15 * rtb_Conv) * 0.01) + Integrator_DSTATE;]]></Line> <Line Number="98"><![CDATA[END_CASE;]]></Line> </STContent> </Routine> </Routines> </AddOnInstructionDefinition> </AddOnInstructionDefinitions> </Controller> </RSLogix5000Content>
44
7.2 Anexo 2 – Texto após importação pelo RSLogix
Estas linhas a seguir, representam o programa em linguagem de texto estruturado para
CLP Rockwell compatível com família 5000, do modelo gerado em MatLab.
CASE ssMethodType OF 2: (* InitializeConditions for Atomic SubSystem: '<S1>/Motor cc' *) (* InitializeConditions for DiscreteIntegrator: '<S3>/Discrete-Time Integrator1' *) DiscreteTimeIntegrator1_DSTATE := 0; (* InitializeConditions for DiscreteIntegrator: '<S3>/Discrete-Time Integrator' *) DiscreteTimeIntegrator_DSTATE := 0; (* InitializeConditions for DiscreteIntegrator: '<S3>/Discrete-Time Integrator2' *) DiscreteTimeIntegrator2_DSTATE := 0; (* End of InitializeConditions for SubSystem: '<S1>/Motor cc' *) (* InitializeConditions for DiscreteIntegrator: '<S2>/Filter' *) Filter_DSTATE := 0; (* InitializeConditions for DiscreteIntegrator: '<S2>/Integrator' *) Integrator_DSTATE := 0; 3: (* Outputs for Atomic SubSystem: '<S1>/Motor cc' *) (* Outport: '<Root>/corrente' incorporates: * DiscreteIntegrator: '<S3>/Discrete-Time Integrator1' *) corrente := DiscreteTimeIntegrator1_DSTATE; (* DiscreteIntegrator: '<S3>/Discrete-Time Integrator' *) rtb_dtetadt := DiscreteTimeIntegrator_DSTATE; (* Gain: '<S3>/Const. F. Eletromotriz' *) VL := 4.4E-6 * rtb_dtetadt; (* Gain: '<S3>/Conv' *) rtb_Conv := 9.5492965855137211 * rtb_dtetadt; (* Gain: '<S3>/Inercia' incorporates: * Gain: '<S3>/Amortecimento' * Gain: '<S3>/Constante de Torque' * Sum: '<S3>/Add1' *) rtb_d2tetadt2 := ((0.0244 * corrente) - (0.000219 * rtb_dtetadt)) * 2.3980815347721823E+6; (* End of Outputs for SubSystem: '<S1>/Motor cc' *) (* Outport: '<Root>/rpm' *) rpm := rtb_Conv; (* Outputs for Atomic SubSystem: '<S1>/Motor cc' *) (* Outport: '<Root>/posrad' incorporates: * DiscreteIntegrator: '<S3>/Discrete-Time Integrator2' *) posrad := DiscreteTimeIntegrator2_DSTATE; (* End of Outputs for SubSystem: '<S1>/Motor cc' *) (* Sum: '<S1>/Sum' incorporates: * Inport: '<Root>/ref' *) rtb_Conv := ref - rtb_Conv; (* Gain: '<S2>/Filter Coefficient' incorporates: * DiscreteIntegrator: '<S2>/Filter' * Gain: '<S2>/Derivative Gain' * Sum: '<S2>/SumD' *) rtb_FilterCoefficient := ((0.8 * rtb_Conv) - Filter_DSTATE) * 50; (* Switch: '<S1>/Switch' incorporates: * DiscreteIntegrator: '<S2>/Integrator' * Gain: '<S2>/Proportional Gain' * Inport: '<Root>/In1'
45
* Inport: '<Root>/ref' * Sum: '<S2>/Sum' *) IF In1 > 0 THEN Switch := ((10 * rtb_Conv) + Integrator_DSTATE) + rtb_FilterCoefficient; ELSE Switch := ref; END_IF; (* End of Switch: '<S1>/Switch' *) (* Update for Atomic SubSystem: '<S1>/Motor cc' *) (* Sum: '<S3>/Add' *) b_Add := (Switch - corrente) - VL; (* Update for DiscreteIntegrator: '<S3>/Discrete-Time Integrator1' incorporates: * Gain: '<S3>/Indutancia' *) DiscreteTimeIntegrator1_DSTATE := ((2463.0541871921182 * b_Add) * 0.01) + DiscreteTimeIntegrator1_DSTATE; (* Update for DiscreteIntegrator: '<S3>/Discrete-Time Integrator' *) DiscreteTimeIntegrator_DSTATE := (0.01 * rtb_d2tetadt2) + DiscreteTimeIntegrator_DSTATE; (* Update for DiscreteIntegrator: '<S3>/Discrete-Time Integrator2' *) DiscreteTimeIntegrator2_DSTATE := (0.01 * rtb_dtetadt) + DiscreteTimeIntegrator2_DSTATE; (* End of Update for SubSystem: '<S1>/Motor cc' *) (* Update for DiscreteIntegrator: '<S2>/Filter' *) Filter_DSTATE := (0.01 * rtb_FilterCoefficient) + Filter_DSTATE; (* Update for DiscreteIntegrator: '<S2>/Integrator' incorporates: * Gain: '<S2>/Integral Gain' *) Integrator_DSTATE := ((15 * rtb_Conv) * 0.01) + Integrator_DSTATE; END_CASE;
