Motion Control Function Blocks for IEC61131-3

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO Motion Control Function Blocks for IEC61131-3 André José Domingues Serra Mestrado Integrado em Engenharia Eletrotécnica e de Computadores Orientador: Mário Jorge Rodrigues de Sousa (Prof. Dr.) 31 de Julho de 2014 c André José Domingues Serra, 2014 ii Resumo A automação industrial é nos dias de hoje uma área em forte crescimento e com uma importância fulcral nas diversas unidades industriais espalhadas pelos diferentes sectores económicos. Tendo em conta a importância dos autómatos usados no ambiente industrial e o facto das linguagens de programação de PLC’s definidas na norma IEC 61131-3 não estarem adaptadas para o controlo das máquinas CNC, fez com que o grupo PLCOpen definisse um conjunto de diversos Function Blocks que podem ser utilizados na interligação dos PLC’s com as máquinas CNC. Nesta dissertação, são desenvolvidos alguns dos Function Blocks criados pela PLCOpen, de forma a serem testados no motor disponível pela Faculdade de Engenharia da Universidade de Porto provando que os FB desenvolvidos pela organização estão aptos a serem utilizados como interligação entre os PLC’s e as máquinas CNC. Para o desenvolvimento deste projeto foram usadas ferramentas como a linguagem C de forma a ser produzido um protocolo série que permitisse a comunicação entre o ambiente de desenvolvimento e o motor. Para o desenvolvimento do código presente no interior dos Function Blocks foi usado o XML,eXtensible Markup Language. O desenvolvimento do projeto foi baseado na norma IEC 61131, nomeadamente na sua terceira parte, esta norma define características mecânicas e lógicas que devem ser seguidas pelos Autómatos Programáveis. No desenvolvimento do projeto, no âmbito da automação industrial, existem inúmeros ambientes de desenvolvimento lançados pelas diversas marcas de fabricantes de autómatos. Porém estes têm algumas desvantagens, como o facto de serem pagos e de possuírem diversas restrições a nível da plataforma de uso e de compatibilidade. Devido a estes fatores, foi usado o Beremiz, um software criado pela Lolitech. Este ambiente é open-source, grátis, multiplataforma e segue as restrições impostas pela norma IEC 61131-3. De modo a validar e avaliar os Function Blocks criados, foram realizados inúmeros testes que verificaram se estes comunicavam corretamente com o motor incentivando a sua movimentação. iii iv Abstract Industrial automation is nowadays an area of strong growth and a central importance in various industrial units spread across different economic sectors. Given the importance of the automatons used in an industrial environment and the fact that the programming languages fo PLC’s defined in IEC 61131-3 are not suited for the control of CNC machines, has made the PLCOpen group define a number of Function Blocks that can be used in the interconnection of PLCs with CNC machines. In this dissertation, are developed some of the Function Blocks created by PLCopen in order to test the engine available from the Faculty of Engineering, University of Porto proving that FB developed by the organization are able to be used as interconnection between the PLC’s and CNC machines. For the development of this project tools such as the C language were used in order to be producing a serial protocol allowing communication between the development environment and the engine. For the development of the code within the Function Blocks was used XML, eXtensible Markup Language. The development of the project was based on the IEC 61131 standard, notably in its third part, this standard defines mechanical characteristics and logic that must be followed by Programmable Logic Controllers. In the development of the project, within the industrial automation, there are numerous development environments launched by various brands of PLCs. But they have some disadvantages such as the fact that they are paid and they have various restrictions on the level of use platform and compatibility. Due to these factors, we used the Beremiz, software created by Lolitech. This environment is open-source, free, multiplatform and follows the restrictions imposed by IEC 61131-3. In order to validate and evaluate the Function Blocks created, numerous tests that verified if they communicate properly with the engine encouraging their movement were performed. v vi Agradecimentos Em primeiro lugar gostaria de agradecer ao Professor Mário Sousa pela disponibilidade e confiança demonstradas, pelo acompanhamento do trabalho e ajuda na resolução de problemas. O meu sincero agradecimento por tudo. A todos os meus amigos que me acompanharam neste percurso difícil ao longo destes 5 anos, sem vocês não teria chegado onde estou. Gostaria de agradecer à minha família, aos meus pais por me terem apoiado e proporcionado a oportunidade de frequentar este Mestrado e por toda a educação que me deram ao longo destes 22 anos, ao Bruno, meu irmão mais novo, por ser o meu melhor amigo. A todos vós, o meu mais sincero obrigado. André José Domingues Serra vii xiv LISTA DE FIGURAS 3.32 MC_Reset FB [5].................................. 55 3.33 MC_DigitalCamSwitch FB [5]........................... 56 4.1 Movement Tab do NanoPro [1]........................... 60 4.2 FicheiroXML.................................... 65 4.3 Exemplo do tipo de dados AXIS_REF . . . . . . . . . . . . . . . . . . . . . . . 66 4.4 EstruturaAXIS_REF................................ 66 4.5 Declaração das entradas dos FB . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.6 Associação das entradas do MC_MoveRelative . . . . . . . . . . . . . . . . . . 67 4.7 Abertura do canal de comunicação . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.8 Funções usadas no MC_MoveRelative para comando do motor . . . . . . . . . . 68 4.9 Extension.py .................................... 69 4.10 MC_MoveRelative no Beremiz . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.11 MC_MoveAbsolute no Beremiz . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.12 Interligação do FB MC_MoveAbsolute com o FB MC_MoveRelative . . . . . . 72 A.1 Ligação DTE-DCE [6] ............................... 75 A.2 Ligação DTE-DTE [6] ............................... 76 A.3 Conetor de um dispositivo DTE . . . . . . . . . . . . . . . . . . . . . . . . . . 76 A.4 Conetor de um dispositivo DCE . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Lista de Tabelas 2.1 Possíveis estados das saídas [1]........................... 9 2.2 Actualização do firmware [1]............................ 10 3.1 Tipos de dados segundo a norma IEC 61131-3 [7]................. 16 3.2 Tipos de variáveis segundo a norma IEC 61131-3 [7] ............... 17 3.3 Atributos (qualificadores) das variáveis [7]..................... 18 3.4 Prefixos para a localização e tamanho das directly represented variables [7] . . . 18 4.1 Uso do software NanoPro [1]............................ 60 xv xvi LISTA DE TABELAS Abreviaturas e Símbolos FB Function Blocks PLC Programmable Logic Controller POU Program Organization Unit PROG Program FB Function Block FUN Function ST Structured Text IL Instructuin List LD Ladder Diagram FBD Function Block Diagram SFC Sequential Function Chart EIA Electronic Industries Association DTE Data Terminal Equipment DCE Data Circuit-terminating Equipment xvii Capítulo 1 Introdução O trabalho desenvolvido nesta Dissertação tem como objetivo a construção de um conjunto de Function Blocks de modo a que seja possível controlar um motor da forma pretendida. 1.1 Automação Industrial O termo automação pode ser definido como um processo onde são realizadas diversas operações industriais com o auxilio de diversos dispositivos eletrónicos e/ou mecânicos que controlam os seus processos. Com o decorrer dos anos, os sistemas de automação foram evoluindo, deixando de ser sistemas de controlo automático e passando a ser sistemas baseados nas atuais tecnologias [8]. Todas estas mudanças advêm da necessidade de aumentar a produtividade, bem como garantir a melhor relação custo/benefício. A automação surge como a aplicação de uma variedade de técnicas que juntamente com vários softwares e equipamentos específicos de uma determinada máquina executam o processo industrial. São sistemas automatizados que possuem elevados níveis de precisão e sincronismo [9]. Com o grande crescimento da automação industrial, a sua importância tem vindo a aumentar, com a sua introdução em todos os sectores esta fez com que os responsáveis por estes sistemas se deparem com inúmeros desafios, tais como, segurança, confiança nos sistemas, comunicações seguras e a identificação de erros [8]. 1.2 Objetivos e Interesse da Dissertação Este tema está inserido no contexto do uso das várias linguagens da norma IEC 61131-3 para a programação de PLC’s (autómatos) em ambientes industriais. A norma IEC 61131-3, é a norma standard para o mundo industrial, nomeadamente com o referido anteriormente no campo dos autómatos programáveis. No entanto, este software não está adaptado para o controlo de máquinas CNC. Basicamente, as máquinas CNC são equipamentos que usam um controlador numérico que permite o controlo 1 2Introdução das mesmas e é utilizado principalmente em tornos, fresas e robots. O CNC permite o controlo simultâneo de vários eixos, através de um conjunto de instruções escritas num código específico, comandam o movimento do eixo. Para isso, o grupo PLCOpen definiu os Function Blocks for Motion Control, que poderão ser utilizados na interligação de PLC’s com as máquinas CNC, isto é, para que estas possam ser programadas usando as linguagens de programação normalizadas. Numa altura em que os fabricantes de autómatos tentam o melhor possível seguir a norma, este projeto não vai ser exceção. Assim, o estudo da norma IEC 61131, mais em particular a sua terceira parte (IEC 61131-3), que nos descreve as várias linguagens de programação que podem ser usadas bem como conceitos abrangentes e guidelines para o desenvolvimento de projetos para PLC, é um fator importante para o desenvolvimento desta dissertação. Isto é interessante devido ao facto da uniformização e normalização da forma de programar os PLC’s com as máquinas CNC usando as linguagens normalizadas pelo IEC 61131-3, para que qualquer pessoa que entenda as linguagens de programação de PLC’s os consiga programar para que estes façam a sua função e o código produzido possa ser reutilizado por uma máquina do mesmo tipo mas de outro fabricante, ou seja, haver portabilidade dos programas desenvolvidos. Para tal, nesta dissertação vão ser implementados alguns dos Function Blocks definidos pela PLCOpen, que estão disponíveis no seu website para download (http://www.plcopen.org/ pages/tc2_motion_control/downloads/). Quanto ao ambiente de desenvolvimento, existem no mercado inúmeras escolhas mas todas elas proprietárias e com custo elevado. Neste projeto foi imposto o uso do ambiente Beremiz para o desenvolvimento do projeto. A validação dos Function Blocks desenvolvidos será feita com recurso ao eixo/motor localizado no laboratório I105 e representado na figura 1.1. Figura 1.1: Eixo a ser usado para a validação dos Function Blocks De seguida apresenta-se os objetivos na forma de uma lista para que haja uma melhor perceção dos mesmos: 1.3 Estrutura da Dissertação 3 •Desenvolvimento de alguns Function Blocks da PLCOpen; •Desenvolvimento da aplicação de acordo com a norma no Beremiz; •Teste e validação da aplicação desenvolvida. 1.3 Estrutura da Dissertação A Dissertação está dividida em cinco capítulos, constituindo o Capítulo 1, uma contextualização ao tema base do projeto, cuja descrição pormenorizada é apresentada nos capítulos seguintes. No Capítulo 2é descrito de forma detalhada o motor Nanotec PD4-N que serviu de validação do trabalho realizado, falando um pouco das suas ligações, Inputs eOutputs e a sobre a sua configuração e modos de operação. No Capítulo 3, denominado "Tecnologias Presentes", são descritas todas as tecnologias que foram utilizadas na conceção e desenvolvimento do trabalho. Este inicia-se com uma apresentação da norma IEC 61131, de seguida é apresentado o Beremiz, bem como as suas características e razão para a sua escolha. É apresentado o protocolo de comunicação entre o motor e o ambiente de desenvolvimento, protocolo RS232 e por último são apresentados os Motion Control Function Blocks, mostrando quais os FB selecionados e a sua constituição. No Capítulo 4, é descrito o desenvolvimento do projeto desde o seu inicio até à ultima fase de testes e validação. O Capítulo 5encerra a Dissertação apresentando as principais conclusões do trabalho desenvolvido. Mais, são propostos possíveis progressos e trabalhos futuros em consequência do trabalho desenvolvido. 4Introdução Capítulo 2 Motor Nanotec PD4-N Neste capítulo vai ser apresentado o motor presente no eixo que foi usado para o teste dos Function Blocks e do protocolo desenvolvido, falando-se um pouco do mesmo, das suas características e de como são enviados os comandos para o seu controlo. 2.1 Visão Geral O motor Nanotec PD4-N é um motor Plug & Drive que incluí, para além de uma fase terminal de potência, possuí também uma completa rede capaz de controlar a velocidade e posição num closed loop, isto é, controlar a velocidade e a posição numa rede em malha fechada [1]. O PD4-N não reduz apenas as despesas de desenvolvimento e de instalação, mas também as necessidades relativas ao espaço e componentes. Este tipo de motor também aumenta a flexibilidade, as propriedades do sistema e a eficácia de uma estação de acionamento. Devido à compatibilidade elétrica e mecânica deste tipo de motores, as atuais soluções podem facilmente ser substituídas por eles [1]. Quanto a como estes motores podem ser operados temos duas hipóteses de firmware viáveis: •RS485 firmware •CANopen firmware Em relação às funções e características disponibilizadas pelo motor Plug & Drive PD4-N estas estão mencionadas na lista seguinte: •Microstep 1/1 – 1/64 estado final do output (0.014ode resolução do step); •Controlo de corrente em malha fechada, através da comutação de uma onda sinusoidal que provém do encoder; •Poderoso microprocessador DSP para I/O flexíveis; 5 12 Motor Nanotec PD4-N Capítulo 3 Tecnologias Presentes Neste capitulo serão apresentadas as tecnologias incorporadas no projeto. Por um lado a norma IEC 61131, enquanto modelo usado na programação da aplicação de controlo, como também o Beremiz que foi usado como ambiente de desenvolvimento. Por outro lado, protocolo de comunicação RS232 responsável pela comunicação entre a aplicação de controlo e o motor também será alvo de estudo. 3.1 Norma IEC 61131-3 3.1.1 Visão Geral Desde da criação dos PLC’s, muitas das linguagens de programação têm sido utilizadas para escrever programas para máquinas e processos. Antes da criação da norma, como não havia uma forma "universal"de se programar nos PLC’s dos vários fabricantes e devido ao constante crescimento da complexidade dos sistemas, houve um grande aumento nos custos e na perda de tempo, pois era necessário o treino de programadores para as aplicações, para a criação de programas maiores e a implementação de cada vez mais sistemas de programação complexos. Para atenuar esses problemas, a norma IEC 61131 foi criada em 1982 pela mão de um grupo dentro da IEC (International Electrotecnical Commission) tendo como objetivo criar uma interface comum ao uso dos autómatos programáveis. Ela está dividida em 8 partes, mas no âmbito desta dissertação, a que tem mais interesse é a terceira parte, pois é esta que aborda o aspeto da programação de controladores industriais e define o modelo de programação e não só. O IEC 61131-3 oferece também conceitos abrangentes e guidelines para o desenvolvimento de projetos para PLC [2]. Os principais conceitos e características apresentadas pelo IEC 61131-3 [2] são: •Declaração de variáveis e alocação estática; •Tipos de dados; •Estruturação, modularização, reutilização e portabilidade de software; 13 14 Tecnologias Presentes •Orientação a objetos; •Processamento multitarefa; •Cinco linguagens de programação (2 textuais e 3 gráficas). A norma é considerada como uma guideline para a maioria dos fabricantes de PLC’s e define vários aspetos para os PLC’s, tais como, características do hardware, instalação, testes, comunicação e programação, ficando assim estes pontos standardizados para os vários fabricantes e utilizadores desta tecnologia. Com a norma, tanto os fabricantes como os utilizadores ganham benefícios, como por exemplo, para o caso dos fabricantes esta diminui o risco de estes desenvolverem um sistema que não satisfaça os requisitos do mercado. Embora a norma defina um conjunto de regras às quais os fabricantes deveriam aderir, tal não acontece de uma forma rígida tendo os fabricantes bastante liberdade em implementar os componentes que pretendem, mesmo quando estes não seguem a norma. Quanto aos utilizadores, em vez de terem diferentes cursos de programação em PLC’s, estes com o IEC 61131-3 apenas precisam de aprender os pontos mais delicados do uso de sistemas de programação individuais e as características especiais dos PLC’s que forem adicionadas. Isto "corta"a necessidade do uso de especialistas do sistema e de treino de pessoal e assim os programadores dos PLC’s tornam-se mais flexíveis. Em suma, nos últimos anos e com a crescente necessidade de uniformizar o mercado dos PLC, a aceitação da norma tem aumentado, trazendo várias vantagens aos fabricantes e principalmente ao consumidor final, vantagens estas já referidas anteriormente. Assim, é possível normalizar a estrutura funcional dos equipamentos, criar um ambiente de desenvolvimento independente do equipamento ou do fabricante, que vai por sua vez, simplificar o fabrico de equipamentos e reduzir os custos associados. 3.1.2 Program Organization Units A norma apresentada anteriormente, traz a vantagem de conseguirmos realizar uma programação estruturada em elementos funcionais designados de POU’s (Program Organization Units) e poder escolher a linguagem em que irá ser programada parte do projeto. Os Program Organization Units (POU), são unidades básicas de uma aplicação de controlo. Estes estão divididos em três tipos diferentes [2]: •Function (FUN); •Function Block (FB); •Program (PROG). Segundo a norma, o POU é constituído por um cabeçalho e corpo estando as variáveis presentes no cabeçalho e as instruções para a execução no corpo, tal como está ilustrado na figura 3.1. 3.1 Norma IEC 61131-3 15 Figura 3.1: Estrutura comum dos 3 tipos de POU [2] Os três diferentes tipos de POU referidos anteriormente, possuem uma hierarquia entre si. Os Program estão no topo da cadeia podendo incluir nas suas instruções Function Blocks eFunctions, no entanto são os únicos que não podem incluir no seu corpo uma instância de outro PROG. No nível seguinte da hierarquia vêm os Function Blocks, estes podem incluir no seu corpo FUN e outros FB ao contrário dos PROG que não permitem instâncias do mesmo tipo de POU. Os Function Blocks são os Building Blocks principais na estruturação de programas para os PLC’s. Estes podem ser instanciados como variáveis, isto é, podemos ter variáveis em que o seu tipo é um FB. Depois de instanciado um Function Block pode ser usado como uma instância e chamado dentro do POU em que é declarado. No último lugar da cadeia temos as Function, estas só podem chamar outras FUN, além disso as FUN diferem dos restantes tipos porque não possuem memória, isto é, o estado passado não é tido em conta na presente execução do programa. Para além dos três tipo de POU já apresentados, a norma define alguns modelos de FUN e FB, os Basic Building Blocks. Estes são POU pré-definidos capazes de realizar funções de conversão, numéricas, entre outros. 3.1.3 Tipos de dados e Variáveis 3.1.3.1 Tipos de dados O IEC 61131-3 também especifica vários tipos de dados, como por exemplo, o Bool,Float, Byte,Integer, entre outros que podem ser usados nos vários programas e blocos que são feitos. Estas diferem, por exemplo, no número de bits ou no uso de sinais. A tabela 3.1 mostra os vários tipos de dados definidos pela norma: 16 Tecnologias Presentes Tabela 3.1: Tipos de dados segundo a norma IEC 61131-3 [7] Data Type Size (bits) Default Number BOOL 1 False BYTE 8 0 WORD 16 0 DWORD 32 0 LWORD 64 0 SINT/UINT 8 0 INT/UINT 16 0 DINT/UDINT 32 0 LINT/ULINT 64 0 REAL 32 0 LREAL 64 0 STRING 8(por caracter) string vazia WSTRING 16(por caracter) string vazia TIME Implementação Dependente T#0S TIME_OF_DAY Implementação Dependente TOD#00:00:00 DATE Implementação Dependente D # 0001-01-01 DATE_AND_TIME Implementação Dependente DT # 0001-01-01-00:00:00 É também possível que o utilizador defina novos tipos de dados derivados dos tipos apresentados anteriormente. A criação de novos tipos de dados pode acontecer de diferentes formas: •Direta - Cria um tipo de dados elementar com um particular valor inicial; •Com intervalo - Cria um tipo de dados com um determinado limite. Por defeito, assume o valor mais baixo do intervalo; •Enumeração - O tipo de dados pode assumir um valor de uma determinada lista; •Array . Vários elementos do mesmo tipo de dados combinam e formam array; •Estrutura - Vários elementos combinam e formam um tipo de dados. Desta forma o utilizador pode definir qualquer tipo de dados que desejar. Os tipos de dados são fundamentais, visto que estão ligados a todas as variáveis do projeto. Isto é, todas as variáveis usadas num projeto estão definidas com um tipo de dados, esta característica oferece ao programa robustez, evitando assim a realização de operações inválidas como dividir um inteiro por uma string. 3.1 Norma IEC 61131-3 17 3.1.3.2 Variáveis A norma também especifica os tipos de variáveis que podem ser internas, de entrada, saída ou entrada/saída. As variáveis internas são usadas num POU mas o seu valor é irrelevante para o restante programa. As de entrada são alimentadas externamente por outras variáveis presentes noutro POU, acontecendo o contrário com as variáveis de saída, isto é, estas alimentam outras variáveis de outros POU. A declaração da variável é efetuada tendo em conta os seguintes atributos [2]: •Tipo de variável; •Nome; •Tipo de dados; •Valor Inicial; •Atributos. Na tabela 3.2, mostra mais alguns tipos de variáveis, para além dos já mencionados anteriormente: Tabela 3.2: Tipos de variáveis segundo a norma IEC 61131-3 [7] Keyword Description VAR Internal to POU variables VAR_INPUT Externally supplied, not modifiable within POU VAR_OUTPUT Supplied by POU to external entities VAR_IN_OUT Supplied by external entities, can be modified within POU VAR_EXTERNAL Supplied by configuration via VAR_GLOBAL, can be modified within POU VAR_GLOBAL Global variable declaration VAR_ACCESS Access path declaration Quando são usadas variáveis remotas, como por exemplo, entradas e saídas de um PLC a sua definição é realizada recorrendo à expressão AT e concatenando os seguintes parâmetros: "% + Localização + tamanho + um ou mais inteiros separados por ’.’ " Existem ainda outros atributos para as variáveis, para além do AT, que estão apresentados na tabela 3.3: 18 Tecnologias Presentes Tabela 3.3: Atributos (qualificadores) das variáveis [7] Attribute Meaning AT Location Assignment RETAIN Constant variable (cannot be modified) R_EDGE Rising edge F_EDGE Falling Edge READ_ONLY Write-protected READ_WRITE Can be read and written to A norma ainda refere que quando a representação inclui os inteiros separados por pontos finais, estes devem ser interpretados como um endereçamento numa lógica hierárquica, com o inteiro mais à esquerda a representar o nível mais alto e decrescendo da esquerda para a direita. Na tabela 3.4, pode ser verificado quais os prefixos para a localização e tamanho das directly represented variables: Tabela 3.4: Prefixos para a localização e tamanho das directly represented variables [7] No Prefix Meaning 1 I Input Location 2 Q Output Location 3 M Memory location 4 X Single bit size 5 none Single bit size 6 B Byte (8 bits) size 7 W Word (16 bits) size 8 D Double word (32 bits) size 9 L Long word (64 bits) size 3.1.4 Linguagens de Programação Uma das principais vantagens da adoção do IEC 61131-3 é a uniformização/normalização das linguagens de programação para os PLC’s. A norma possui cinco linguagens: •Structured Text (ST); •Instruction List (IL); 3.1 Norma IEC 61131-3 19 •Ladder Diagram (LD); •Function Block Diagram (FBD); •Sequential Function Chart (SFC). Destas cinco linguagens, duas delas são textuais, nomeadamente o ST (Structured Text e o IL (Instruction List) e as restantes gráficas, que são o Ladder (LD), Sequencial Function Chart (SFC) e o Function Block Diagram (FBD). Estas linguagens não possuem nenhuma restrição quanto ao uso de variáveis ou tipos de dados, além disso as linguagens conseguem interagir entre si sem haver qualquer problema. O ST é uma linguagem de alto nível orientada a máquinas, semelhante ao Pascal e que consiste numa lista de procedimentos. Cada procedimento é processado determinando os valores que controlam o fluxo do programa. É uma linguagem que apresenta uma vasta gama de procedimentos abstratos e com grande complexidade. Tem como vantagens, a possibilidade de uma forma de programação compacta, tendo as suas instruções claras e em blocos, e uma potente construção do fluxo do programa, permitindo a construção de estruturas complexas, como por exemplo, ciclos While,For, bem como a construção de expressões complexas, como operações matemáticas, processamento de dados, entre outras [2]. Além disto, apresenta algumas desvantagens como a sua tradução para código máquina não ser direta pois este é processado por um compilador. A figura 3.2 mostra um excerto de código escrito em ST: Figura 3.2: Excerto de código ST [3] O IL é uma linguagem textual que ao contrário do ST é uma linguagem de baixo nível, semelhante à lista de instruções do Assembly usado na programação de microcontroladores. É muitas vezes usada na programação de sistemas de controlo de processos simples pois possui uma execução muito eficiente, isto é, devido à sua rapidez e baixo consumo de memória. Mas para além disto, esta tem algumas desvantagens, como a construção de estruturas e dificuldade em construir ciclos/sequências complexas, como o ciclo For. Se o programa for extenso, este também é difícil de ler e interpretar [2]. 20 Tecnologias Presentes Figura 3.3: Excerto de código IL [3] O LD é uma linguagem gráfica de baixo nível, análoga á construção de um circuito elétrico com relés. Esta representa o fluxo de energia da esquerda para a direita de um POU. É uma linguagem que era usada nos primeiros PLC equipados principalmente com relés, razão pela qual os seus símbolos são idênticos a circuitos elétricos. Estes têm a vantagem de possuir uma execução muito eficiente, em termos de rapidez e baixo consumo de memória, mas tal como o IL, é difícil construir estruturas complexas, bem como sequencias/ciclos complexos e se o programa for extenso existe dificuldade na sua análise [2]. Na figura 3.4 temos um excerto de código em LD: Figura 3.4: Excerto de código LD [3] O FBD surgiu da área de processamento de sinal e descreve as interações entre os sinais de entrada e os sinais de saída que são processados através dos diferentes blocos. É uma linguagem gráfica de alto nível baseada no conceito de fluxo de sinal, incorporando uma programação orientada a objetos, e cada bloco implementa uma determinada ação de processamento, como pode ser visto na figura 3.5. A sua utilização permite que seja uma linguagem modular. Basicamente, o FBD é composto pela interligação de vários Function Blocks,Function Blocks estes que podem ser chamados por programas e por outros Function Blocks (instâncias). As saídas de um bloco só podem ser conectadas às entradas de outro [2]. Além disso, não é possível conectar variáveis com diferentes tipos de dados. É uma linguagem poderosa e versátil que tem vindo a chamar a atenção do mundo da automação industrial. 3.1 Norma IEC 61131-3 21 Figura 3.5: Excerto de código FBD [3] O SFC é uma linguagem gráfica de alto nível, que descreve sequências de operações e interações entre processos paralelos, sequenciais e concorrentes. Esta fornece os meios para a estruturação do programa num conjunto de etapas separadas por transições, etapas estas que têm que ser programadas numa das outras linguagens disponíveis. Cada transição está associada a uma expressão que tem que ser satisfeita para que o programa continue com o seu fluxo. É uma linguagem com uma execução menos eficiente, pois é mais lenta e usa mais memória, mas como já foi dito, permite-nos uma boa organização do programa [2]. Figura 3.6: Excerto de código SFC [3] Em conclusão, a norma IEC 61131-3, mostra uma nova forma de programar PLC’s, onde entre várias vantagens, como a portabilidade do código para diferentes máquinas de diferentes fabrican- 28 Tecnologias Presentes 3.4.1 Visão Geral O mercado de controlo de movimento (Motion Control) disponibiliza uma grande variedade de sistemas e soluções incompatíveis. Em empresas onde sistemas diferentes são usados, esta incompatibilidade induz custos elevados para o utilizador final, a aprendizagem é difícil, a engenharia torna-se difícil e o crescimento do mercado abranda. A normalização certamente faria com que esses fatores negativos diminuíssem. A normalização mencionada não significa apenas as linguagens de programação apresentadas na norma IEC 61131-3, mas também a normalização da interface para as diferentes soluções de controlo de movimento. Desta forma, a programação dessas soluções para o controlo de movimento serão menos dependentes do hardware. A reutilização da aplicação de software é aumentada e os custos envolvidos no treino e suporte serão reduzidos. Para a resolução deste problema a PLCOpen criou a Motion Control Task Force, que definiu a interface normalizando assim os Function Blocks for Motion [5]. Estes Function Blocks são aplicáveis nas linguagens do IEC 61131-3 considerando os seguintes fatores [5]: •Simplicidade - facilidade de utilização, para o programador da aplicação e para a instalação e manutenção; •Eficiência - no número de Function Blocks, direcionada para a eficiência no Design e entendimento; •Consistência - conformidade com a norma IEC 61131-3; •Universalidade - independente do hardware; •Flexibilidade - para extensões futuras ou aumento da amplitude da aplicação; •Plenitude - não é obrigatória mas é suficiente. A definição deste conjunto de FB preocupa-se com a granularidade e modularidade dos Function Blocks standardizados. Os extremos são um FB por eixo em relação a uma funcionalidade a nível de comando. Os objetivos acima mencionados podem ser conseguidos facilmente através de um design modular dos FB, pois a modularidade cria um nível elevado de escalabilidade, flexibilidade e reconfiguração. Na figura 3.9, são apresentados os vários Function Blocks definidos e divididos em administrativos e de movimento, isto é, FB que não acionam movimento e os que o induzem: 3.4 Function Blocks for Motion Control 29 Figura 3.9: Lista dos vários Function Blocks disponíveis [5] 3.4.2 Modelo Os Function Blocks que foram desenvolvidos pela PLCOpen têm o objetivo de controlar eixos via as linguagens de programação que estão definidas na norma IEC 61131-3. Foi decidido pela Motion Control Task Force que não seria prático que todos os aspetos de um eixo fossem encapsulados em apenas um Function Block. A solução escolhida foi disponibilizar um conjunto de Function Blocks comandados e que possuem uma referência para o eixo, por exemplo o tipo de dados "Axis", que oferece flexibilidade, facilidade de utilização e reutilização. As implementações baseadas na norma IEC 61131-3, por exemplo através de Function Blocks e SFC, serão focadas para a interface (look-and-feel/ proxy) dos FB. De seguida será apresentado o diagrama de estados que define o comportamento do eixo quando múltiplos Motion Control Function Blocks estão "simultaneamente"ativos. 3.4.2.1 Diagrama de Estados Como mencionado anteriormente, este diagrama de estados representa o comportamento do eixo quando temos múltiplos MC_FB em funcionamento. Esta combinação de perfis de movimento são úteis para a construção de um perfil mais complicado e na forma como lidar as exceções que podem aparecer dentro de um programa. Basicamente, o que a regra impõe é que os comandos que geram o movimento sejam realizados sequencialmente, mesmo que o PLC tenha a capacidade de processamento paralelo. O eixo está sempre num dos estados definidos, qualquer comando que induza movimento e que cause uma transição irá fazer com que haja uma mudança no estado do eixo. A mudança de estado é refletida "imediatamente"quando o comando de movimento é realizado. 30 Tecnologias Presentes O Diagrama de Estados é considerado como uma camada de abstração do estado onde está na realidade o eixo, é comparável com a imagem dos I/O num ciclo de um programa de um PLC. De seguida na figura 3.10 é apresentado o Diagrama de Estados usado pelos Motion Control Function Blocks [5]. Figura 3.10: Diagrama de Estados dos Motion Control Function Blocks [5] O diagrama apresentado está focado em apenas um eixo. Para FB de múltiplos eixos, estes podem ser observados de um ponto de vista do diagrama, como múltiplos "eixos únicos"todos em estados específicos. Por exemplo, o CAM-Master pode estar no estado "ContinuousMotion"e o escravo correspondente no estado "SynchronizedMotion". Explicando melhor o diagrama, as setas a cheio representam as possíveis transições de estado devido a um comando, enquanto que as setas a tracejado são usadas para representar transições de estado que ocorrerem quando um comando terminou ou algo de errado aconteceu. Os comandos de movimento que fazem com que o eixo troque de estado estão mencionados em cima do estado correspondente. Falando agora dos principais estados do diagrama: •Disable - descreve o estado inicial do eixo. Neste estado o movimento do eixo não é influenciado pelo FB’s. Para sair deste estado o FB MC_Power tem de ser chamado com o Enable = TRUE, o estado passa do Disable para o estado StandStill; •ErrorStop - é um estado com uma prioridade elevada e aplicável quando ocorre um erro, podendo a transição para este estado ser feita de qualquer um dos outros estados. A intenção deste estado é que o eixo pare, se possível. Para sair deste estado é necessário que seja feito um reset, pois enquanto este não for feito nenhum dos outros comandos será aceite. A 3.4 Function Blocks for Motion Control 31 transição para ErrorStop apenas se refere a erros no eixo ou no controlo do eixo não de erros nas instâncias dos Function Blocks; •StandStill - é o estado em que o eixo está operacional para o movimento e se encontra parado à espera que seja acionado um comando para que o eixo se movimente. 3.4.2.2 Tratamento de erros Todo o acesso para o controlo de movimento é feito através dos Function Blocks, internamente estes fornecem uma verificação básica de erros na entrada. Por exemplo, se o MaxVelocity possuir o valor 6000, e a entrada Velocity do Function Block está a 10000, só existem duas soluções ou o sistema abranda ou este vai gerar um erro [5]. Para o tratamento dos erros, tanto o método centralizado ou o descentralizado podem ser usados, pois ambos são possíveis quando os Motion Control Function Blocks são usados. Quanto ao método centralizado este é usado para simplificar a programação do Function Block. A reação ao erro é independente da instância na qual o erro ocorreu [5]. Figura 3.11: Exemplo de FB com o tratamento de erros centralizado [5] Quanto ao tratamento de erros descentralizado, é um pouco diferente, este dá a possibilidade de ter diferentes reações ao erro ocorrido, dependendo do Function Block onde o erro ocorreu. A figura 3.12, mostra um exemplo de FB onde é o usado o tratamento descentralizado: 32 Tecnologias Presentes Figura 3.12: Exemplo de FB com o tratamento de erros descentralizado [5] 3.4.2.3 Buffered Modes Alguns destes Function Blocks possuem uma entrada chamada "BufferMode. Esta entrada permite que os FB trabalhem ou num "Non-buffered mode", que é o comportamento por defeito, ou num "Buffered mode". A diferença entre estes dois modos verifica-se quando o FB deve iniciar a sua ação, isto é, quando um comando está no modo "non-buffered"este é realizado imediatamente, mesmo que este interrompa outro movimento, após isto o buffer é limpo. Se um comando está no modo "Buffered", este espera até que o FB que está ativo naquele momento coloque a sua saída a um. Neste último modo, temos várias opções que são as seguintes [5]: •Aborting - Modo que está escolhido por defeito, consiste em que FB seguinte aborte qualquer movimento que está a ser executado e o comando afeta o eixo/motor imediatamente e limpa o buffer; •Buffered - Consiste em que o FB seguinte afete o eixo assim que o anterior coloque a um a sua saída Done; •BlendingLow - O FB seguinte controla o eixo depois do anterior ter terminado, mas o eixo não parará entre os movimentos. A velocidade com que este rodará será a menor entre os dois comandos. •BlendingPrevious - Funciona como o anterior, só que a velocidade escolhida será a velocidade do FB anterior e não a do FB que vai realizar o comando. 3.4 Function Blocks for Motion Control 33 •BlendingNext - Ao contrário do anterior este faz com que a velocidade do eixo seja a velocidade do FB que vai realizar o comando; •BlendingHigh - Consiste em realizar o comando proposto à maior velocidade entre a do FB que acabou de realizar um comando e a do FB que vai realizar o comando seguinte. 3.4.2.4 Apresentação dos Function Blocks escolhidos Como já foi mencionado, foram escolhidos alguns dos Motion Control Function Blocks definidos pela PLCOpen para serem desenvolvidos e interligados de forma a atingir o objetivo proposto. De seguida são apresentados os FB escolhidos [5]: •MC_Power - Este FB tem como função controlar se o dispositivo está ON/OFF, isto é, se está ligado e desligado. Na figura 3.13 vê-se a constituição do FB. Figura 3.13: MC_Power FB [5] Especificando as entradas do FB: –AXIS_REF - esta entrada/saída dá a referência para o eixo, isto é, indica qual o eixo a ser controlado; –Enable - se estiver a TRUE, o sistema está ligado; –EnablePositive - Entrada opcional em que se o Enable for TRUE permite o movimento na direção positiva; –EnableNegative - Entrada opcional em que se o Enable for TRUE permite o movimento na direção negativa; Em relação às saídas: –AXIS_REF - esta entrada/saída dá a referência para o eixo, isto é, indica qual o eixo a ser controlado; –Status - Como o nome indica, esta saída dá o estado efetivo do sistema; –Valid - Se for TRUE, podemos ter conjuntos de saídas disponíveis para o FB; 34 Tecnologias Presentes –Error - Vai a 1, se algum erro acontecer no Function Block; –ErrorID - Saída opcional, identificação do erro. •MC_Home - Este FB comanda o eixo a "procurar uma casa", isto é, o eixo vai para uma espécie de posição de referência. A figura 3.14, mostra quais as entradas e saídas deste Function Block. Figura 3.14: MC_Home FB [5] Entradas do FB: –AXIS_REF - esta entrada/saída dá a referência para o eixo, isto é, indica qual o eixo a ser controlado; –Execute - Quando houver um rising edge inicia o movimento; –Position - É a posição quando o sinal de referência é detetado; –BufferMode - Esta é uma entrada opcional que define a sequência cronológica do FB de acordo com os modos disponíveis, ver subcapítulo 3.4.2.3. Saídas do FB: –AXIS_REF - esta entrada/saída dá a referência para o eixo, isto é, indica qual o eixo a ser controlado; –Done - Como o nome indica, esta saída diz-nos que o FB concluiu a sua função; –Busy - Saída opcional que, enquanto for TRUE, indica que o FB ainda não terminou a sua tarefa; –Active - Saída opcional, que indica que o FB tem controlo sobre o eixo; –CommandAborted - Saída opcional, que diz que o comando que estava a ser executado foi abortado por outro; –Error - Vai a 1, se algum erro acontecer no Function Block; –ErrorID - Saída opcional, identificação do erro. 3.4 Function Blocks for Motion Control 35 •MC_Stop - Este Function Block tem como função parar qualquer ação de movimento que esteja a ocorrer e transferir o eixo para o estado "Stopping" do diagrama de estados, ver subcapítulo 3.4.2.1. Este FB é mais usado para paragens de emergência ou situações especiais. Enquanto a estrada Execute se mantiver a TRUE ou se o motor ainda não tiver atingido a velocidade zero, este mantém-se no estado "Stopping" e só transita quando a entrada Execute for False e a saída Done for TRUE, transitando assim para o estado "StandStill". A figura 3.15, mostra quais as entradas e saídas do FB. Figura 3.15: MC_Stop FB [5] Entradas do FB: –AXIS_REF - esta entrada/saída dá a referência para o eixo, isto é, indica qual o eixo a ser controlado; –Execute - Quando houver um rising edge inicia o movimento; –Deceleration - Entrada opcional, que indica o valor da desaceleração; –Jerk - Esta é uma entrada opcional que diz qual o valor pretendido para o Jerk que é a variação de aceleração em função do tempo. Saídas do FB: –AXIS_REF - esta entrada/saída dá a referência para o eixo, isto é, indica qual o eixo a ser controlado; –Done - Como o nome indica, esta saída diz-nos que o FB concluiu a sua função; –Busy - Saída opcional que, enquanto for TRUE, indica que o FB ainda não terminou a sua tarefa; –CommandAborted - Saída opcional, que diz que o comando que estava a ser executado foi abortado por outro; –Error - Vai a 1, se algum erro acontecer no Function Block; –ErrorID - Saída opcional, identificação do erro. 36 Tecnologias Presentes •MC_Halt - Este Function Block é usado para comandar uma paragem de movimento controlada, ou seja, é usado para parar o eixo em condições normais de funcionamento. Em termos do diagrama de estados, o MC_Halt faz com que o eixo se mude para o estado "DiscreteMotion", até que a velocidade seja zero. Quando a saída Done for a TRUE, o eixo passa para o estado "StandStill". A figura 3.16 mostra a constituição do MC_Halt. Figura 3.16: MC_Halt FB [5] Entradas do FB: –AXIS_REF - esta entrada/saída dá a referência para o eixo, isto é, indica qual o eixo a ser controlado; –Execute - Quando houver um rising edge inicia o movimento; –Deceleration - Entrada opcional, que indica o valor da desaceleração; –Jerk - Esta é uma entrada opcional que diz qual o valor pretendido para o Jerk que é a variação de aceleração em função do tempo. –BufferMode - Esta é uma entrada opcional que define a sequência cronológica do FB de acordo com os modos disponíveis, ver subcapítulo 3.4.2.3. Saídas do FB: –AXIS_REF - esta entrada/saída dá a referência para o eixo, isto é, indica qual o eixo a ser controlado; –Done - Como o nome indica, esta saída diz-nos que o FB concluiu a sua função; –Busy - Saída opcional que, enquanto for TRUE, indica que o FB ainda não terminou a sua tarefa; –Active - Saída opcional, que indica que o FB tem controlo sobre o eixo; –CommandAborted - Saída opcional, que diz que o comando que estava a ser executado foi abortado por outro; –Error - Vai a 1, se algum erro acontecer no Function Block; 3.4 Function Blocks for Motion Control 37 –ErrorID - Saída opcional, identificação do erro. •MC_MoveAbsolute - Este FB comanda o eixo a realizar um movimento para uma posição especificada. A figura 3.17, mostra quais as suas entradas e saídas. Figura 3.17: MC_MoveAbsolute FB [5] Entradas do FB: –AXIS_REF –Execute - Quando houver um rising edge inicia o movimento; –ContinuousUpdate - Entrada opcional, que quando o FB for acionado, e se esta estiver aTRUE, vai fazer com que o FB use os valores atuais das variáveis de entrada e aplicálos ao movimento em curso; –Position - Posição para onde o FB vai; –Velocity - Valor máximo que a velocidade pode atingir; –Acceleration - Entrada opcional, indica o valor da aceleração, é sempre positivo; –Deceleration - Entrada opcional, que indica o valor da desaceleração; –Jerk - Esta é uma entrada opcional que diz qual o valor pretendido para o Jerk que é a variação de aceleração em função do tempo. –Direction - Pode ter 1 de 4 valores: mcPositiveDirection, mcShortestWay, mcNegativeDirection, mcCurrentDirection; –BufferMode - Esta é uma entrada opcional que define a sequência cronológica do FB de acordo com os modos disponíveis, ver subcapítulo 3.4.2.3. Saídas do FB: –AXIS_REF 44 Tecnologias Presentes –Direction - Pode ter 1 de 4 valores: mcPositiveDirection, mcShortestWay, mcNegativeDirection, mcCurrentDirection; –BufferMode - Esta é uma entrada opcional que define a sequência cronológica do FB de acordo com os modos disponíveis, ver subcapítulo 3.4.2.3. Saídas do FB: –AXIS_REF –InEndVelocity - Vai a TRUE, quando atinge a posição desejada e está a movimentar-se com a EndVelocity; –Busy - Saída opcional que, enquanto for TRUE, indica que o FB ainda não terminou a sua tarefa; –Active - Saída opcional, que indica que o FB tem controlo sobre o eixo; –CommandAborted - Saída opcional, que diz que o comando que estava a ser executado foi abortado por outro; –Error - Vai a 1, se algum erro acontecer no Function Block; –ErrorID - Saída opcional, identificação do erro. •MC_MoveContinuousRelative - Este FB comanda um movimento relativo a uma distância especificada, acabando o movimento com a velocidade escolhida. Basicamente funciona como o FB anterior, só que em vez de termos uma posição absoluta temos uma distância que este vai ter que percorrer a uma velocidade constante. Na figura 3.23 podemos ver as entradas e saídas constituintes deste FB. Figura 3.23: MC_MoveContinuousRelative FB [5] Entradas do FB: –AXIS_REF 3.4 Function Blocks for Motion Control 45 –Execute - Quando houver um rising edge inicia o movimento; –ContinuousUpdate - Entrada opcional, que quando o FB for acionado, e se esta estiver aTRUE, vai fazer com que o FB use os valores atuais das variáveis de entrada e aplicálos ao movimento em curso; –Distance - Distância que se quer percorrer; –EndVelocity - Valor da velocidade final, tomando como exemplo a velocidade de corte; –Velocity - Valor máximo que a velocidade pode atingir; –Acceleration - Entrada opcional, indica o valor da aceleração, é sempre positivo; –Deceleration - Entrada opcional, que indica o valor da desaceleração; –Jerk - Esta é uma entrada opcional que diz qual o valor pretendido para o Jerk que é a variação de aceleração em função do tempo. –BufferMode - Esta é uma entrada opcional que define a sequência cronológica do FB de acordo com os modos disponíveis, ver subcapítulo 3.4.2.3. Saídas do FB: –AXIS_REF –InEndVelocity - Vai a TRUE, quando atinge a posição desejada e está a movimentar-se com a EndVelocity; –Busy - Saída opcional que, enquanto for TRUE, indica que o FB ainda não terminou a sua tarefa; –Active - Saída opcional, que indica que o FB tem controlo sobre o eixo; –CommandAborted - Saída opcional, que diz que o comando que estava a ser executado foi abortado por outro; –Error - Vai a 1, se algum erro acontecer no Function Block; –ErrorID - Saída opcional, identificação do erro. •MC_TorqueControl - Este FB exerce continuamente um binário ou a força da magnitude especificada. Esta magnitude é aproximada através de uma rampa definida (“TorqueRamp”), e o Function Block coloca a TRUE a saída “InTorque” se o binário especificado é atingido. Este Function Block é aplicável para a força e para o binário. Quando não existe uma carga externa, a força é aplicável. O binário é positivo na direção positiva da velocidade. Na figura 3.24 podemos ver como está constituído o FB. 46 Tecnologias Presentes Figura 3.24: MC_TorqueControl FB [5] Entradas do FB: –AXIS_REF –Execute - Quando houver um rising edge inicia o movimento; –ContinuousUpdate - Entrada opcional, que quando o FB for acionado, e se esta estiver aTRUE, vai fazer com que o FB use os valores atuais das variáveis de entrada e aplicálos ao movimento em curso; –Torque - Valor do binário; –TorqueRamp - Máxima derivada em ordem ao tempo do valor do binário ou da força; –Velocity - Valor máximo que a velocidade pode atingir; –Acceleration - Entrada opcional, indica o valor da aceleração, é sempre positivo; –Deceleration - Entrada opcional, que indica o valor da desaceleração; –Jerk - Esta é uma entrada opcional que diz qual o valor pretendido para o Jerk que é a variação de aceleração em função do tempo. –Direction - Pode ter 1 de 2 valores: mcPositiveDirection, mcNegativeDirection; –BufferMode - Esta é uma entrada opcional que define a sequência cronológica do FB de acordo com os modos disponíveis, ver subcapítulo 3.4.2.3. Saídas do FB: –AXIS_REF –InTorque - Vai a TRUE, quando é atingido o binário/força especificados; 3.4 Function Blocks for Motion Control 47 –Busy - Saída opcional que, enquanto for TRUE, indica que o FB ainda não terminou a sua tarefa; –Active - Saída opcional, que indica que o FB tem controlo sobre o eixo; –CommandAborted - Saída opcional, que diz que o comando que estava a ser executado foi abortado por outro; –Error - Vai a 1, se algum erro acontecer no Function Block; –ErrorID - Saída opcional, identificação do erro. •MC_PositionProfile - Este é um Function Block que comanda um perfil de movimento da posição em função do tempo. Na figura 3.25, mostra quais as entradas e saídas do FB. Figura 3.25: MC_PositionProfile FB [5] Entradas do FB: –AXIS_REF –TimePosition - Referência para o Tempo/Posição. Este par pode também ser expresso como Deltatempo/Posição, onde Delta é a diferença entre dois pontos consecutivos; –Execute - Quando houver um rising edge inicia o movimento; –ContinuousUpdate - Entrada opcional, que quando o FB for acionado, e se esta estiver aTRUE, vai fazer com que o FB use os valores atuais das variáveis de entrada e aplicálos ao movimento em curso; –TimeScale - Entrada opcional, que representa o fator de escala do tempo do perfil; –PositionScale - Entrada opcional, que representa o fator de escala da posição; –Offset - Entrada opcional, indica qual o offset do perfil; –BufferMode - Esta é uma entrada opcional que define a sequência cronológica do FB de acordo com os modos disponíveis, ver subcapítulo 3.4.2.3. Saídas do FB: 48 Tecnologias Presentes –AXIS_REF –Time_Position –Done - Fica a TRUE, quando o perfil está completo; –Busy - Saída opcional que, enquanto for TRUE, indica que o FB ainda não terminou a sua tarefa; –Active - Saída opcional, que indica que o FB tem controlo sobre o eixo; –CommandAborted - Saída opcional, que diz que o comando que estava a ser executado foi abortado por outro; –Error - Vai a 1, se algum erro acontecer no Function Block; –ErrorID - Saída opcional, identificação do erro. •MC_VelocityProfile - Este FB comanda um perfil de movimento da velocidade em função do tempo. A velocidade do elemento final presente no perfil é mantida. A constituição do FB está presente na figura 3.26. Figura 3.26: MC_VelocityProfile FB [5] Entradas do FB: –AXIS_REF –TimeVelocity - Referência para o Tempo/Velocidade. Este par pode também ser expresso como Deltatempo/Velocidade, onde Delta é a diferença entre dois pontos consecutivos; –Execute - Quando houver um rising edge inicia o movimento; –ContinuousUpdate - Entrada opcional, que quando o FB for acionado, e se esta estiver aTRUE, vai fazer com que o FB use os valores atuais das variáveis de entrada e aplicálos ao movimento em curso; –TimeScale - Entrada opcional, que representa o fator de escala do tempo do perfil; –VelocityScale - Entrada opcional, que representa o fator de escala da velocidade; 3.4 Function Blocks for Motion Control 49 –Offset - Entrada opcional, indica qual o offset do perfil; –BufferMode - Esta é uma entrada opcional que define a sequência cronológica do FB de acordo com os modos disponíveis, ver subcapítulo 3.4.2.3. Saídas do FB: –AXIS_REF –Time_Velocity –ProfileCompleted - Fica a TRUE, quando o perfil está completo; –Busy - Saída opcional que, enquanto for TRUE, indica que o FB ainda não terminou a sua tarefa; –Active - Saída opcional, que indica que o FB tem controlo sobre o eixo; –CommandAborted - Saída opcional, que diz que o comando que estava a ser executado foi abortado por outro; –Error - Vai a 1, se algum erro acontecer no Function Block; –ErrorID - Saída opcional, identificação do erro. •MC_AccelerationProfile - Tal como os FB anteriores, este comanda um perfil de movimento sendo que neste caso se trata de um perfil de aceleração. Este Function Block quando finaliza o perfil mantém a velocidade final e a aceleração vai para zero. A constituição do FB pode ser vista na figura 3.27. Figura 3.27: MC_AccelerationProfile FB [5] Entradas do FB: –AXIS_REF –TimeAcceleration - Referencia para o Tempo/Aceleração. Também pode ser expresso por Deltatempo/Aceleração, onde o Delta é a diferença entre dois pontos consecutivos; –Execute - Quando houver um rising edge inicia o movimento; 50 Tecnologias Presentes –ContinuousUpdate - Entrada opcional, que quando o FB for acionado, e se esta estiver aTRUE, vai fazer com que o FB use os valores atuais das variáveis de entrada e aplicálos ao movimento em curso; –TimeScale - Entrada opcional, que representa o fator de escala do tempo do perfil; –AccelerationScale - Entrada opcional, que representa o fator de escala para a amplitude da aceleração; –Offset - Entrada opcional, indica qual o offset do perfil; –BufferMode - Esta é uma entrada opcional que define a sequência cronológica do FB de acordo com os modos disponíveis, ver subcapítulo 3.4.2.3. Saídas do FB: –AXIS_REF –Time_Acceleration –ProfileCompleted - Fica a TRUE, quando o perfil está completo; –Busy - Saída opcional que, enquanto for TRUE, indica que o FB ainda não terminou a sua tarefa; –Active - Saída opcional, que indica que o FB tem controlo sobre o eixo; –CommandAborted - Saída opcional, que diz que o comando que estava a ser executado foi abortado por outro; –Error - Vai a 1, se algum erro acontecer no Function Block; –ErrorID - Saída opcional, identificação do erro. •MC_SetPosition - Este Function Block muda o sistema de coordenadas de um eixo, manipulando tanto a posição do ponto de ajuste, bem como a posição real de um eixo com o mesmo valor, sem causar qualquer movimento (Re-calibração com mesmo erro). Isto pode ser utilizado, por exemplo, para uma situação de referência. Este bloco de função também pode ser usado durante o movimento, sem alterar a posição comandada, que agora está posicionada no sistema de coordenadas deslocado. Na figura 3.28, apresenta as entradas e saídas do FB. 3.4 Function Blocks for Motion Control 51 Figura 3.28: MC_SetPosition FB [5] Entradas do FB: –AXIS_REF –Execute - Quando for TRUE, começa a ajustar a posição; –Position -Unidade de posição, significa "Distance if Relative = TRUE"; –Relative - Entrada opcional, indica a distância relativa e significa "if TRUE, ’Absolute’ position, if False = Default"; –ExecutionMode - Esta é uma entrada opcional e define a sequência do FB: mcImmediately, em que a funcionalidade é validada imediatamente podendo influenciar o movimento que está a ocorrer, o outro modo é o mcQueued - mesma funcionalidade que o buffer mode Buffered. Saídas do FB: –AXIS_REF –Done - Fica a TRUE, quando a entrada "Position"tem um novo valor; –Busy - Saída opcional que, enquanto for TRUE, indica que o FB ainda não terminou a sua tarefa; –Error - Vai a 1, se algum erro acontecer no Function Block; –ErrorID - Saída opcional, identificação do erro. •MC_ReadActualPosition - Este FB retorna a posição atual do eixo A sua constituição pode ser vista na figura 3.29. 52 Tecnologias Presentes Figura 3.29: MC_ReadActualPosition FB [5] Entradas do FB: –AXIS_REF –Enable - Enquanto estiver ativo, o FB está continuamente a obter o valor da posição. Saídas do FB: –AXIS_REF –Valid - Fica a TRUE, quando uma saída válida está disponível no FB; –Busy - Saída opcional que, enquanto for TRUE, indica que o FB ainda não terminou a sua tarefa; –Error - Vai a 1, se algum erro acontecer no Function Block; –ErrorID - Saída opcional, identificação do erro. –Position - Valor atual da Posição. •MC_ReadActualVelocity - Este Function Block retorna o valor da velocidade atual enquanto o Enable estiver ativo. A saída Valid éTRUE quando a saída Velocity é válida. Se for feito um reset ao Enable, os dados perdem a sua validade. O reset é feito a todas as saídas mesmo que haja novos dados disponíveis. Na figura 3.30 podemos ver a entradas e saídas constituintes do FB. 3.4 Function Blocks for Motion Control 53 Figura 3.30: MC_ReadActualVelocity FB [5] Entradas do FB: –AXIS_REF –Enable - Enquanto estiver ativo, o FB está continuamente a obter o valor da velocidade. Saídas do FB: –AXIS_REF –Valid - Fica a TRUE, quando uma saída válida está disponível no FB; –Busy - Saída opcional que, enquanto for TRUE, indica que o FB ainda não terminou a sua tarefa; –Error - Vai a 1, se algum erro acontecer no Function Block; –ErrorID - Saída opcional, identificação do erro. –Velocity - Valor atual da Velocidade. •MC_ReadActualTorque - É um FB que retorna o valor do binário atual enquanto o Enable estiver ativo. A saída Valid éTRUE quando a saída Torque é válida. Se for feito um reset ao Enable os dados perdem a sua validade. O reset é feito a todas as saídas mesmo que haja novos dados disponíveis. A constituição do FB está presente na figura 3.31. 60 Desenvolvimento Tabela 4.1: Uso do software NanoPro [1] Step Action 1 Install the NanoPro control software on your PC. See the NanoPro separate manual. 2 Connect the PC to the RS485 interface of the Plug & Drive motor according to the connection diagram. 3 Switch on the operating voltage (12-48 V DC). If operating voltage > 50 V, the output stage is destroyed. 4 If necessary, install the driver for the converter cable ZK-RS485-USB. 5 Connect the Plug & Drive motor to the PC. 6 Start NanoPro software. 7 Select the Communication tab 8 In the "Port"field select the COM port to which the PD4-N is connected 9 Select the "115200 bps"entry in the "Baudrate"selection field 10 Check the current setting using the motor data sheet on the "Motor Settings"tab. Presettings: Phase Current equal to 50%(current level) and Phase current during idle equal to 25%. 11 Select the "Movement Mode"tab 12 Click on the "Test Record"button to carry out the pre-set travel profile. 13 Now we can enter the required settings or create a new travel profile. Para uma melhor visualização do ambiente do programa, tomemos atenção à figura 4.1: Figura 4.1: Movement Tab do NanoPro [1] 4.1 Protocolo de Comunicação 61 Depois de se verificar que o motor comunicava e funcionava corretamente, deu-se inicio ao desenvolvimento do protocolo RS232. Para conseguirmos fazer com que o motor se movimente é necessário enviar para este o comando desejado, recorrendo-se ao Programming Manual fornecido pela Nanotec. Um comando inicia-se com o caracter # e termina com o carriage return ’\r’. O caracter inicial é seguido por um endereço do motor representado como um número decimal em ASCII. O valor desse número pode estar desde 1 até 254, se ’*’ é enviado em vez de um número, todos os drivers conectados ao barramento são endereçados [11]. O endereço do motor é seguido pelo comando em si, que geralmente consiste num caracter em ASCII ou um número ASCII opcional. É necessário ter em atenção que alguns comandos consistem em vários caracteres enquanto que outros não requerem um número, mas sim letras, como um parâmetro. No parágrafo anterior falamos da estrutura do comando enviado, agora vamos falar da resposta que confirma a receção do comando. Após o envio de um comando, se o controlador o reconhecer, este confirma a sua receção retornando o comando como um echo, mas sem o caracter inicial #. No caso de o controlador receber um comando que não conheça, este responde enviando o comando seguido de um ponto de interrogação ’?’. A resposta do controlador tal como o comando que é enviado terminam com o carriage return ’\r’. No caso de serem enviados valores inválidos ao controlador, estes são ignorados mas enviados na mesma como um echo [11]. De seguida são apresentados alguns exemplos do envio do comando e da sua receção. •Valor transmitido ao controlador: ’#1u1000\r’ •Resposta do firmware: ’1u1000\r’ •Especificar a distancia ao controlador 1: ’#1s1000\r’ -> ’1s1000\r’ •Iniciar o motor: ’#1A\r’ -> ’1A\r’ •Comando inválido: ’#1o\r’ -> ’1o?\r’ Agora vai ser apresentado o protocolo desenvolvido falando um pouco do objetivo de cada função. Antes de mais, é necessário mencionar o uso da biblioteca "serial_util"que possui as funções necessárias para a realização da comunicação série entre o computador e o motor. As funções presentes são as seguintes: •serial_open - função que abre o canal de comunicação série; •serial_close - fecha o canal de comunicação; •serial_config - realiza a configuração do canal de comunicação; •serial_read - permite ler o que está presente no canal de comunicação, neste caso ler a resposta do controlador; 62 Desenvolvimento •serial_write - função que permite escrever no canal de comunicação, no presente caso o envio de comandos para o motor. Agora vão ser apresentadas as funções desenvolvidas, sendo dada uma breve explicação da sua utilidade, bem como o seu cabeçalho e o comando enviado. •serial_device - esta função realiza a abertura do canal de comunicação. Cabeçalho - int serial_device(char *serport) A variável serport corresponde à porta série que vai ser usada, visto que apenas é usado um motor, a porta ttyS0 foi a única escolhida. •currentPos - tem como objetivo indicar qual a posição em que está o motor. Cabeçalho - void currentPos(int serfd) A variável serfd corresponde ao file descriptor da ligação série. Esta variável é necessária em todas as funções, exceto na serial_device pois é aí que este é criado. Comando enviado - ’#1C\r’. •step - permite especificar o tipo de step pretendido. O valor escolhido é o equivalente ao número de microsteps por full step, com exceção do valor 254 que seleciona o feed rate mode e do valor 255 que escolhe o adaptive step mode. Os valores permitidos são: 1, 2, 4, 5, 8, 10, 16, 32, 64, 254 e 255. Cabeçalho - void step(int serfd, int stepvalue) Como o nome indica a variável stepvalue armazena o valor desejado para o step. Comando enviado - ’#1gxxxx\r’, onde xxxx é o valor proveniente da variável sentstep. •MotorStart - função que inicia o motor com os parâmetros escolhidos. Cabeçalho - void MotorStart(int serfd) Comando enviado - ’#1A\r’. •rampType - seleciona o tipo de rampa para todos os modos, este pode ter 1 de 3 valores possíveis: –0 - Rampa Trapezoidal; –1 - Rampa Sinusoidal; –2 - Rampa jerk-free Cabeçalho - void rampType(int serfd, int ramp) A variável ramp guarda o valor escolhido pelo utilizador para a seleção da rampa, valor este que pode ter um dos três valores indicados anteriormente. Comando enviado - ’#1:ramp_mode=n\r’, n corresponde ao número guardado na variável ramp. •MotorStop - esta função para o movimento que está a ser executado. Cabeçalho - void MotorStop(int serfd) Comando enviado - ’#1S\r’. 4.1 Protocolo de Comunicação 63 •PositioningMode - esta função tem como objetivo escolher que modo desejamos para o deslocamento do motor. Os modos disponíveis são os seguintes: –1 - Relative Positioning –2 - Absolute Positioning Cabeçalho - void PositioningMode(int serfd, int mode) A variável mode pode ter 1 de 2 valores, se possuir o valor 1 o motor deslocar-se-á no modo relativo caso possua o valor 2 este usará o modo de deslocamento absoluto. Comando enviado - ’#1px\r’, onde x corresponde ao número escolhido pelo utilizador de acordo com o tipo de deslocamento que deseja usar. •TravelDistance - como o nome indica esta função serve para especificar a distancia/posição que queremos que seja percorrida, isto é, no caso de ser escolhido o deslocamento relativo este comando especifica a distância a ser percorrida, neste caso apenas valores positivos são permitidos e a direção do movimento tem que ser escolhida via um comando presente na função rotationDirection que irá ser apresentado brevemente. No caso de ser escolhido o movimento absoluto este comando especifica a posição para onde se quer ir, relativamente à direção do movimento já não é necessária a função rotationDirection, pois neste modo valores negativos já são aceites, ou seja, se o valor for positivo este movimenta-se para a direita, se for negativo movimenta-se para a esquerda. Cabeçalho - void TravelDistance(int serfd, int distance) Na variável distance é onde está guardado o valor escolhido. Comando enviado - ’#1sxxxx\r’, onde xxxx corresponde ao valor presente na variável distance. •MinimumFreq - esta função especifica a velocidade mínima, em Hertz, a que o motor pode andar. Aceita valores desde 1 até 160000. Cabeçalho - void MinimumFreq(int serfd, int initfreq) A variável initfreq armazena o valor escolhido para a velocidade. Comando enviado - ’#1uxxxx\r’, onde xxxx corresponde ao valor guardado em initfreq. •MaximumFreq - esta função especifica a velocidade máxima, em Hertz, a que o motor pode andar. A velocidade máxima é atingida depois de passar pela rampa de aceleração. Cabeçalho - void MaximumFreq(int serfd, int maxifreq) A variável maxifreq armazena o valor escolhido para a velocidade. Comando enviado - ’#1oxxxx\r’, onde xxxx corresponde ao valor guardado em maxifreq. •AccelRamp - especifica qual o valor para a rampa de aceleração. Cabeçalho - void AccelRamp(int serfd, int num) Comando enviado - ’#1bxxxx\r’, onde xxxx corresponde ao valor guardado na variável num. 64 Desenvolvimento •BrakeRamp - especifica qual o valor para a rampa de aceleração. Se o valor especificado for 0 significa que o valor usado na rampa de aceleração é usado também na rampa de travagem. Cabeçalho - void BrakeRamp(int serfd, int value) Comando enviado - ’#1Bxxxx\r’, onde xxxx corresponde ao valor guardado na variável value. •rotationDirection - Tal como o nome indica esta função tem como objetivo definir o sentido da rotação. Não esquecer que esta função apenas funciona se o modo de deslocamento for o modo relativo. Para escolher a direção no comando a enviar, tem que ir um dos seguintes valores: –0 - Esquerda; –1 - Direita; Cabeçalho - void rotationDirection(int serfd, int direction) Na variável direction é onde vai o valor que especifica qual a direção a tomar. Comando enviado - ’#1dx\r’, onde x corresponde ao valor proveniente da variável distance. •NumberRepetitions - esta função consiste em definir um número de repetições para o movimento que está a ser definido. Cabeçalho - void NumberRepetitions(int serfd, int number) A variável number armazena o número de repetições escolhido. Comando enviado - ’#1Wxxx\r’, onde xxx corresponde ao número de repetições armazenado na variável number. •repetitionDirection - esta função define se deve ser alterada a direção da rotação após cada repetição, esta função apenas aceita dois valores: –0 - Não haver mudança de direção; –1 - Para existir mudança de direção Cabeçalho - void repetitionsDirection(int serfd, int change) Comando enviado - ’#1tx\r’, onde x corresponde a um dos números mencionados em cima e que estão guardados na variável change. •AccelJerk - Especifica o jerk máximo para a aceleração. Cabeçalho - void AccelJerk(int serfd, int acc) Comando enviado - ’#1:bx\r’, onde x corresponde ao valor do jerk escolhido e guardado na variável acc. •BrakeJerk - Indica qual o máximo jerk para a rampa de travagem. Se o valor escolhido for 0, o valor usado para a travagem será o mesmo que é usado para a aceleração. 4.2 Biblioteca MCFunctionBlocks 65 Cabeçalho - void BrakeJerk(int serfd, int brk) Comando enviado - ’#1:Bx\r’, onde x corresponde ao valor do jerk escolhido para a rampa de travagem. Depois de desenvolvido, foram realizados testes ao protocolo de forma a se verificar se cada função realizava o seu objetivo. Verificou-se que a cada envio de um comando o controlador respondia da maneira esperada, maneira esta que é um echo do comando enviado tal como foi mencionado anteriormente. Também foi verificado se este realizava o movimento pretendido, isto é, foi colocado um valor para a distância no caso de um movimento relativo e um para a posição no caso de um movimento absoluto. Após o deslocamento foi realizada uma medição verificandose se o motor tinha andado a distância pretendida e no outro modo se este tinha se deslocado para a posição desejada. Este teste foi realizado para diferentes valores de distância e posição concluindo-se que o protocolo desenvolvido funcionava corretamente. 4.2 Biblioteca MCFunctionBlocks Após a conclusão do protocolo era necessário desenvolver no Beremiz os Function Blocks pretendidos. Para isso foi sugerido pelo orientador realizar o seu desenvolvimento através de um ficheiro XML, criando uma biblioteca no ambiente de desenvolvimento com os Motion Control Functions Blocks que aparece na janela Library do Beremiz. Na figura 4.2, mostra a aparência do ficheiro bem como o seu cabeçalho inicial: Figura 4.2: Ficheiro XML 66 Desenvolvimento Antes de iniciar a construção dos FB, foi necessário criar um tipo de dados especial o AXIS_REF que é uma estrutura que contém informação sobre o eixo em funcionamento. Como já foi dito anteriormente este é usado como uma VAR_IN_OUT em todos os Motion Control Function Blocks. Quanto conteúdo desta estrutura, este é dependente da implementação desenvolvida e em última instância pode estar vazia. Na figura 4.3 mostra um exemplo de como pode estar definido este tipo de dados. Figura 4.3: Exemplo do tipo de dados AXIS_REF No caso desta dissertação, esta estrutura contém apenas a referência para o motor em uso, tal pode ser verificado na figura 4.4. Figura 4.4: Estrutura AXIS_REF Após a definição deste tipo de dados, prosseguiu-se para o desenvolvimento do POU, neste caso os Function Blocks. Primeiramente é necessário indicar quais as entradas e saídas presentes no FB, na figura 4.5 pode-se ver como são declaradas as entradas do FB. 4.2 Biblioteca MCFunctionBlocks 67 É de notar que as variáveis que são do tipo BOOL estão com o tipo INT, isto porque na linguagem C o tipo BOOL não pode ser usado, pelo que é usado o tipo INT para representar este tipo quando necessário. Figura 4.5: Declaração das entradas dos FB No caso das saídas e das variáveis entrada/saída no local onde aparece inputVars, coloca-se outputVars eInOutVars, respetivamente. Após a definição de todas as variáveis, passa-se para o desenvolvimento do corpo do FB. Este foi feito usando a linguagem C, isto é possível devido ao compilador Matiec, pois o que este faz é converter a linguagem em que está escrito o projeto IEC 61131-3 para linguagem C, pelo que é permitido a escrita em C. Falando mais propriamente do conteúdo do corpo dos FB, o código no interior FB consiste na chamada das funções criadas no protocolo criado e apresentado no subcapítulo anterior. De seguida, será apresentado o conteúdo do FB MC_MoveRelative de forma a se perceber como foi efetuado o desenvolvimento do código do FB. Para se conseguir aceder às entradas do FB, é necessário usar a função __GET_VAR(data__- >nomeVariável, na imagem 4.6 podemos ver como foi feita essa associação. Figura 4.6: Associação das entradas do MC_MoveRelative Após esta associação, os valores colocados nas entradas do FB são colocados nas variáveis criadas no corpo do FB. 68 Desenvolvimento De seguida, é necessário abrir o canal de comunicação, para evitar a constante abertura do canal foi criada uma variável auxiliar AxisState que passa a 1 quando o canal é aberto o que pode ser visto na figura 4.7. Quando o canal é fechado esta passa a 0. Figura 4.7: Abertura do canal de comunicação Após este passo é necessário indicar quais as funções presentes no corpo do FB, isto é, colocar as funções que permitam que o FB comande o motor a realizar o movimento, tal pode ser observado na figura 4.8. Figura 4.8: Funções usadas no MC_MoveRelative para comando do motor O comando __SER_VAR(data__->,nomeVariável,__type_LITERAL) permite colocar a 1 ou a 0 as saídas do Function Block. Quanto aos restantes FB, todos eles seguem estes passos, tendo apenas como diferenças as funções necessárias para o FB em questão. 4.2 Biblioteca MCFunctionBlocks 69 Depois de desenvolvido o ficheiro XML que contém a biblioteca dos MC_Function Blocks é necessário colocá-la no Beremiz. Isto é feito através do ficheiro em python, chamado extension.py que realiza a criação da biblioteca no Beremiz, bem como a ligação da biblioteca com o protocolo desenvolvido de forma a que seja possível a comunicação entre o motor e o Beremiz. Na figura 4.9 pode-se ver como é a constituição do código. Figura 4.9: Extension.py As partes do código em que se define a biblioteca e quais os recursos que esta necessita, ou seja, para que o Beremiz saiba a localização da biblioteca e saber de onde vêm as funções usadas nos FB são: •def GetLibraryPath(self) - que pode ser visto na linha 10 e que retorna o local onde se localiza o ficheiro XML onde estão desenvolvidos os Function Blocks, ou seja, a biblioteca criada; •def Generate_C(self, buildpath, varlist, IECCFLAGS) - é o local onde se indica, se necessário, a localização de outras bibliotecas usadas no XML, neste caso o protocolo desenvolvido e a biblioteca serial_util. Por fim, para que a biblioteca aparecesse no ambiente de desenvolvimento o Beremiz deveria ser iniciado pela linha de comandos da seguinte maneira: "./Beremiz.py -e extension.py/MCFunctionBlocks" Depois de concluída esta parte, passou-se para a construção de aplicações com os FB desenvolvidos e ao seu teste, isto vai ser apresentado com mais detalhe no subcapítulo seguinte. 76 Ligações RS232 Figura A.2: Ligação DTE-DTE [6] A.2 Sinais para os dispositivos DTE e DCE A definição dos sinais para um dispositivo DTE é representada na figura A.3. A negrito estão apresentados os sinais mais comuns. Figura A.3: Conetor de um dispositivo DTE A.2 Sinais para os dispositivos DTE e DCE 77 Na figura A.4, está representado os sinais disponíveis para um dispositivo DCE: Figura A.4: Conetor de um dispositivo DCE Quando o dispositivo DCE é um modem, para realizar a comunicação muitos sinais são necessários para as conexões. No caso em que o dispositivo DCE não é um modem, ou quando dois dispositivos DTE são ligados diretamente poucos sinais são necessários. É de se notar, que nas figuras apresentadas existe um segundo canal que inclui um conjunto de sinais de controlo duplicados. Este canal fornece sinais de gestão do modem remoto, fazendo com que seja possível a mudança da taxa de transmissão durante a comunicação, efetuando um pedido de retransmissão se erros forem detetados. De seguida será apresentado a função dos pinos mais usados na comunicação série: •Pino 1 - GND (Protetive Ground) - Sinal de terra de proteção; •Pino 7 - SG (Signal Ground) - Sinal terra usado como referência para outros sinais; •Pino 2 - TD (Transmitted Data) - Este sinal está ativo quando são enviados dados do DTE para o DCE; •Pino 3 - RD (Received Data) - Está ativo quando o DTE recebe dados do modem ou DCE; •Pino 4 - RTS (Request to Send) - Este sinal é um pedido para enviar dados a partir de um DTE.O dispositivo espera até que o CTS fique ativo; •Pino 5 - CTS (Clear to Send) - O CTS é a resposta do DCE que informa o DTE que este pode transmitir dados; 78 Ligações RS232 •Pino 6 - DSR (Data Set Ready) - É um sinal do DCE que indica que o dispositivo está ligado e pronto a receber dados; •Pino 20 - DTR (Data Terminal Ready) - Funciona da mesma maneira que o DSR mas este sinal vem do DTE; •Pino 8 - DCD (Data Carrier Detect) - Sinal de saída de um DCE que indica que existe um carrier entre os DCE e indica também que a conexão está pronta para a comunicação; •Pino 24 - EC (External Clock) - É um sinal usado na transmissão síncrona quando é necessário clock data. Este sinal é uma entrada no DCE; •Pino 15 - TC (Transmit Clock) - Transmite o clock do DCE em sistemas síncronos; •Pino 17 - RC (Receive Clock) - Sinal que indica o clock recebido no DTE para a descodificação dos dados; •Pino 22 - RI (Ring Indicator) - Sinal de saída de um modem que indica que foi recebido um sinal de toque. Referências [1] Nanotec Electronic. Pd4-n technical manual v1.5, Junho 2013. [2] K.H. John e M. Tiegelkamp. IEC 61131-3: Programming Industrial Automation Systems: Concepts and Programming Languages, Requirements for Programming Systems, Aids to Decision-making Tools. Springer, 2010. [3] Flavio Bonfatti, Paola Daniela Monari, e Umberto Sampieri. IEC 61131-3 programming methodology: software engineering nethods for industrial automated systems. ICS Triplex ISaGRAF, 2003. [4] Lolitech. Beremiz user manual, 2008. URL: http://www.beremiz.org. [5] PLCOpen Technical Committee 2 Task Force. Function blocks for motion control version 2.0, March 2011. [6] Slides da unidade curricular arquitecturas de comunicação industrial, 2013. [7] Jerzy Kasprzyk. Lecture: Iec 61131-3: Programming languages, Maio 2001. [8] C. Neves e L.Duarte e N. Viana e V. Ferreira. Os dez maiores desafios da automação industrial: as perspectivas para o futuro. II Congresso de Pesquisa e Inovação da Rede Norte Nordeste de Educação Tecnológica João Pessoa, 2007. [9] A.A.B. Buccioli e E.R. Zorzal e C. Kirner. Usando a realidade virtual e aumentada na visualização da simulação de sistemas de automação industrial. SVR2006-VIII Symposium on Virtual Reality, 2006. [10] Edmur Canzian. Comunicação série. URL: http://www.professores.aedb.br/ arlei/AEDB/Arquivos/rs232.pdf. [11] Nanotec Electronic. Programming manual v2.7, June 2013. 79