Hélder Manuel Silva Vilas Boas Desenvolvimento de um ...

Hélder Manuel Silva Vilas Boas

Desenvolvimento de um Sistema de Testee Monitorização para Sensores de Direção

Héld

er M

anue

l Silv

a Vi

las

Boas

dezembro de 2013UMin

ho |

201

3De

senv

olvi

men

to d

e um

Sis

tem

a de

Tes

te e

Mon

itori

zaçã

o pa

ra S

enso

res

de D

ireç

ão

Universidade do MinhoEscola de Engenharia

dezembro de 2013

Tese de MestradoCiclo de Estudos Integrados Conducentes ao Grau deMestre emEngenharia Eletrónica Industrial e Computadores

Trabalho efetuado sob a orientação doProfessor Doutor Sérgio LopesUniversidade do Minho

e co-orientação doEngenheiro António LopesBosch Car Multimedia

Hélder Manuel Silva Vilas Boas

Desenvolvimento de um Sistema de Testee Monitorização para Sensores de Direção

Universidade do MinhoEscola de Engenharia

Aos meus Pais,

“O que nos distingue são os nossos sonhos

e o que fazemos para que se realizem”

Joseph Epstein

Desenvolvimento de um Sistema de Teste e Monitorização para Sensores de Direção

Universidade do Minho – Hélder Vilas Boas – Bosch Car Multimedia xi

Agradecimentos

As primeiras palavras de agradecimento vão sem dúvida alguma para os meus pais,

Manuel Vilas Boas e La Salete Silva, por todo o apoio, esforço e suporte que sempre

me deram, especialmente no meu percurso académico e também para os meus irmãos

Isabel e Miguel, que tiveram e têm um papel importante na minha vida.

Ao meu orientador, Professor Doutor Sérgio Lopes, pela disponibilidade,

cooperação e por me ter proporcionado a participação neste estágio.

Quero agradecer à empresa Bosch Car Multimedia, nomeadamente à secção

QMM7, a oportunidade de estágio, em especial ao Engº. Alexandre Cardoso pela

confiança depositada desde o início. Ao meu orientador na empresa, Engº. António

Lopes, pela disponibilidade, incentivo e compreensão ao longo do estágio.

Aos restantes engenheiros e técnicos do Laboratório de Fiabilidade, especialmente

ao Engº. Victor Silva pelo apoio, disponibilidade, dedicação, conselhos e críticas dadas

ao longo do desenvolvimento da aplicação. Ao técnico Paulo Franco pelo incentivo,

apoio e sugestões. À drª. Anabela Coutinho e à drª. Rosalina Ferreira pelos concelhos

durante a revisão paciente da escrita desta dissertação. Sem deixar de referir todos os

outros colaboradores da secção QMM7 pela ajuda, compreensão e pelo fantástico

ambiente existente no departamento. A todos eles o meu muito obrigado!

Aos meus amigos e colegas de curso Fábio Cunha, Carlos Almeida, André Pereira,

Bohdan Arzhanov e João Brito que desde o início acompanharam o meu percurso

académico.

A todos os meus familiares, com especial agradecimento ao meu tio Engº. Carlos

Silva e à minha prima Ana Silva pelo apoio.

A todas as pessoas não mencionadas, que ajudaram direta ou indiretamente na

elaboração desta dissertação.


Universidade do Minho – Hélder Vilas Boas – Bosch Car Multimedia xiii

Resumo

Ao longo dos últimos anos têm sido desenvolvidos sistemas ativos de segurança

que contribuem significativamente para a redução do número de acidentes rodoviários.

Um destes sistemas é designado por Electronic Stability Program, que é constituído por

sensores de direção, sensores de velocidade e atuadores. Esta Dissertação de Mestrado

descreve o desenvolvimento, em ambiente de estágio na empresa Bosch Car

Multimedia, de uma aplicação de teste e monitorização de sensores de ângulo de

direção.

Nesta tese, apresentam-se os requisitos da aplicação para que esta suporte a

realização de todos os testes pretendidos, bem como, especificações para o interface

com o operador e modos de operação dos testes. Relativamente à monotorização ao

longo do teste, deve ser recolhida e analisada toda a informação necessária para a

determinação dos erros dos sensores. Neste documento apresentam-se, também, os

vários componentes necessárias para a implementação da aplicação, nomeadamente, o

suporte físico e o suporte lógico do controlador, bem como o motor e a placa de

aquisição de dados dos sensores. Segue-se uma breve descrição de alguns testes de

fiabilidade efetuados na secção de Gestão da Qualidade e Métodos da empresa.

A aplicação foi desenvolvida em LabVIEW. No Capítulo de desenvolvimento é

detalhada a estrutura da aplicação, os menus de definições, bem como os modos de

operação. Finalmente, são apresentados os resultados dos testes efetuados à aplicação.

No final deste documento são retiradas as conclusões do desenvolvimento deste

projeto, bem como apresentadas algumas sugestões de trabalho futuro.

Palavras Chave: Sensor de Ângulo de Direção, Testes de Fiabilidade, LabVIEW


Universidade do Minho – Hélder Vilas Boas – Bosch Car Multimedia xv

Abstract

These last years active security systems have been developed which significantly

contribute to decrease the number of car crashes. One of these systems is the ESP

(Electronic Stability Program). This system is consists of: a steering angle sensor, wheel

speed sensors and actuators. This master degree thesis describes the development, in a

training environment at the Bosch Car Multimedia Company, of a test and monitoring

application system for steering angle sensors.

Throughout this document the different technologic devices needed to the

implementation of this application, will be shown such as, the hardware and the

software of the controller, as well as, the acquisition devices for the sensors data.

Subsequently a brief description of a few reliability tests performed by the Quality

Management Methods section, will be introduced as well as the requirements allowing

to handle the intended tests, user interface specifications and test operating modes.

The application was developed in LabVIEW, that consists of a graphic

programmable language specialized in monitoring and data acquisition. The

Development chapter details the application’s structure, menus setup and also the test

operating modes. Finally some test results of the application will be shown.

In the end of this document there will be some conclusions about this project, as

well as some suggestions for future improvements.

Keywords: Steering Angle Sensor, Reliability Tests, LabVIEW


Universidade do Minho – Hélder Vilas Boas – Bosch Car Multimedia xvii

Índice de Conteúdos

Agradecimentos .................................................................................................... xi

Resumo ................................................................................................................ xiii

Abstract ................................................................................................................. xv

Índice de Conteúdos .......................................................................................... xvii

Glossário .............................................................................................................. xxi

Índice de Figuras .............................................................................................. xxiii

Índice de Tabelas ............................................................................................. xxvii

1. Introdução .................................................................................................... 1

1.1 Motivação ................................................................................................ 1

1.2 Enquadramento - ESP .............................................................................. 2

1.3 Objetivos .................................................................................................. 5

1.4 Estrutura da Dissertação .......................................................................... 6

2. Análise do Problema .................................................................................... 7

2.1 Sensor de Ângulo de Direção .................................................................. 7

2.2 Plataforma de Aquisição de Dados ........................................................ 10

2.3 Motor ...................................................................................................... 13

2.4 Controlador ............................................................................................ 14

2.4.1 Módulos de Controlo ...................................................................... 14

2.4.2 Hardware ........................................................................................ 16

2.4.3 Software .......................................................................................... 19

2.5 Câmara Climática ................................................................................... 20

2.6 Linguagens Utilizadas ............................................................................ 21



xviii Universidade do Minho – Hélder Vilas Boas – Bosch Car Multimedia

2.6.1 Introdução ao LabVIEW ................................................................ 21

2.6.2 Introdução ao SDL .......................................................................... 24

2.7 Conclusão ............................................................................................... 25

3. Requisitos da Aplicação ............................................................................. 27

3.1 Testes de Fiabilidade .............................................................................. 27

3.2 Interface com o Utilizador ..................................................................... 29

3.3 Modos de Operação ............................................................................... 30

3.4 Arquitetura do Sistema .......................................................................... 31

4. Desenvolvimento da Aplicação ................................................................. 33

4.1 Arquitetura da Aplicação ....................................................................... 33

4.2 Menu de Definições ............................................................................... 37

4.2.1 Definições de Comando .................................................................. 38

4.2.2 Definições de Aquisição ................................................................. 39

4.2.3 Definições do Controlador .............................................................. 40

4.3 Modos de Operação ............................................................................... 40

4.3.1 Modo de Comando ......................................................................... 40

4.3.2 Modo de Aquisição ......................................................................... 45

4.3.3 Modo de Comando e Aquisição ..................................................... 49

4.4 Conclusão ............................................................................................... 54

5. Resultados ................................................................................................... 55

5.1 Modo de Comando ................................................................................. 57

5.2 Modo de Aquisição ................................................................................ 58

5.3 Modo de Comando e Aquisição ............................................................. 60

6. Conclusão .................................................................................................... 65

6.1 Conclusões do Trabalho Desenvolvido ................................................. 65



Universidade do Minho – Hélder Vilas Boas – Bosch Car Multimedia xix

6.2 Sugestões de Trabalho Futuro ................................................................ 66

7. Apêndices .................................................................................................... 67

Referências ........................................................................................................... 77


Universidade do Minho – Hélder Vilas Boas – Bosch Car Multimedia xxi

Glossário

ABS Antilock Braking System

API Application Programming Interface

ASIC Application Specific Integrated Circuit

BASIC Beginner's All-purpose Symbolic Instruction Code

CPU Central Processing Unit

DAQ Data Acquisition

DMA Direct Memory Access

ECU Engine Control Unit

ESP Electronic Stability Program

FIFO First in First Out

ICM Immediate Command Mode

LabVIEW Laboratory Virtual Instrument Engineering Workbench

LWS LenkWinkelSensor (Alemão), Steering Angle Sensor

MML Mint Motion Library

NI National Instruments

PCI Peripheral Component Interconnect

PFI Programmable Function Input

PI Proporcional e Integrativo

PID Proporcional Integrativo e Derivativo

PWM Pulse Width Modulation

QMM Quality Management Methods

TCS Traction Control System


Universidade do Minho – Hélder Vilas Boas – Bosch Car Multimedia xxiii

Índice de Figuras

Figura 1.1 - Constituintes do ESP e a sua distribuição no veículo [1]. .......................... 3

Figura 1.2 - Implementação do ESP ao longo dos anos [1]. .......................................... 4

Figura 2.1 - Sensor LWS6: a) Constituintes do sensor; b) Aspeto final do sensor. ....... 8

Figura 2.2 - Conetor do sensor. ...................................................................................... 8

Figura 2.3 - Sinais fornecidos pelo sensor [Bosch]. ....................................................... 9

Figura 2.4 - Modo de descodificação X1. .................................................................... 10



Figura 2.7 - Placa de aquisição de dados DAQ PXI-6624 [7]. .................................... 11

Figura 2.8 - Servo Motor Síncrono [3]. ....................................................................... 13

Figura 2.9 - Princípio de funcionamento de um Resolver [3][3]. ................................ 14

Figura 2.10 - Interligação dos módulos de controlo. ................................................... 15

Figura 2.11 - Interface do hardware do controlador [5]. ............................................. 16

Figura 2.12 - Ligações necessárias para o correto funcionamento do controlador [5].18

Figura 2.13 - Arquitetura do Software Mint. ................................................................ 19

Figura 2.14 - Aspeto exterior da Câmara. .................................................................... 20

Figura 2.15 - Aspeto interior da Câmara. .................................................................... 20

Figura 2.16 - Perfil de temperatura criado pela Câmara Climática. ............................ 20

Figura 2.17 - Ambiente de programação do Front Panel do LabVIEW. ..................... 22

Figura 2.18 - Ambiente de programação do Block Diagram do LabVIEW. ............... 22

Figura 2.19 - Guia para a escolha da arquitetura de uma aplicação [8]. ...................... 23

Figura 2.20 - Arquitetura da linguagem SDL. ............................................................. 24

Índice de Figuras


xxiv Universidade do Minho – Hélder Vilas Boas – Bosch Car Multimedia

Figura 2.21 - Interligação dos vários componentes. .................................................... 25

Figura 3.1 - Especificação dos movimentos aplicados aos sensores: a) Sequência de um

ciclo; b) Duração esperada para um bloco. .......................................................... 28

Figura 3.2 - Interligação dos vários componentes. ...................................................... 31

Figura 4.1 - Diagrama com a interligação entre os blocos do sistema. ....................... 33

Figura 4.2 - Diagrama SDL do processo "Botão Stop". .............................................. 35

Figura 4.3 - Conteúdo do Cluster “Definições”. .......................................................... 36

Figura 4.4 - Conteúdo do Cluster “Estado do Teste”. ................................................. 36

Figura 4.5 - Ambiente gráfico da janela “ Definições”. .............................................. 37

Figura 4.6 - Ambiente gráfico da janela “ Definições de Comando”. ......................... 38

Figura 4.7 - Associação do conceito canal da plataforma de aquisição com os sensores.

.............................................................................................................................. 39

Figura 4.8 - Ambiente gráfico da janela “ Definições de Aquisição”. ........................ 39

Figura 4.9 - Ambiente gráfico da janela “ Definições do Controlador”. ..................... 40

Figura 4.10 - Diagrama temporal da sequência de instruções para o comando do motor.

.............................................................................................................................. 41

Figura 4.11 – Componentes envolvidos no Modo de Comando. ................................. 41

Figura 4.12 - Diagrama temporal ilustrativo da sequência de instruções para a execução

de três movimentos. ............................................................................................. 42

Figura 4.13 - Comandos em LabVIEW para a execução de um movimento. ............. 43

Figura 4.14 - Implementação em LabVIEW da configuração do temporizador de

movimentos. ......................................................................................................... 44

Figura 4.15 - Implementação em LabVIEW da verificação do temporizador de

movimentos. ......................................................................................................... 45

Figura 4.16 – Componentes envolvidos no Modo de Aquisição. ................................ 45

Figura 4.17 - Diagrama de blocos do hardware utilizado no Modo de Aquisição. ..... 46

Figura 4.18 - Interligação do DAQ PXI-6624 com o módulo SCB-100 [7]. ............... 47

Índice de Figuras


Universidade do Minho – Hélder Vilas Boas – Bosch Car Multimedia xxv

Figura 4.19 - Implementação em LabVIEW da configuração do gerador de pulsos. .. 48

Figura 4.20 - Sequência de estados no processo de aquisição de dados dos sensores. 49

Figura 4.21 – Componentes envolvidos no Modo de Comando e Aquisição. ............. 49

Figura 4.22 - Sequência de estados do modo de comando e aquisição. ...................... 50

Figura 4.23 - Sinal digital do controlador e os respetivos pulsos de um LWS. ........... 52

Figura 4.24 - Sinais adquiridos por um osciloscópio no modo de comando e aquisição.

.............................................................................................................................. 53

Figura 4.25 - Bancada de desenvolvimento do projeto. ............................................... 54

Figura 5.1 - Interação do equipamento no laboratório. ................................................ 55

Figura 5.2 - Organização do quadro elétrico que alimenta o motor. ........................... 56

Figura 5.3 - Aspeto gráfico da aplicação no Modo de Comando. ............................... 57

Figura 5.4 - Aspeto gráfico da aplicação no Modo de Aquisição ................................ 58

Figura 5.5 - Aspeto dos gráficos da aplicação no Modo de Aquisição. ....................... 59

Figura 5.6 - Aspeto dos gráficos da aplicação no Modo Comando e Aquisição. ........ 60

Figura 5.7 - Aspeto das tabelas de resultados da aplicação no Modo Comando e

Aquisição. ............................................................................................................ 61

Figura 5.8 - Organização do ficheiro de registo dos dados. ......................................... 62

Figura 5.9 - Organização do ficheiro de registo de erros. ............................................ 62

Figura 5.10 - Representação gráfica de algumas amostras do ficheiro de registo de erros.

.............................................................................................................................. 63

Figura 7.1 - Pinout NI PXI – 6624. ............................................................................ 71

Figura 7.2 - Distribuição dos terminais na Placa SCB – 100. ...................................... 72

Figura 7.3 - Front Panel da função responsável por determinar o próximo ângulo. ... 73

Figura 7.4 - Block Diagram da função responsável por determinar o próximo ângulo.

.............................................................................................................................. 74

Figura 7.5 - Front Panel do bloco "Registo de Dados". .............................................. 75

Índice de Figuras


xxvi Universidade do Minho – Hélder Vilas Boas – Bosch Car Multimedia

Figura 7.6 - Block Diagram do processo "Log" do bloco “Registo de Dados”. .......... 76


Universidade do Minho – Hélder Vilas Boas – Bosch Car Multimedia xxvii

Índice de Tabelas

Tabela 2.1 - Dados Técnicos do Sensor LWS 6. ........................................................... 8

Tabela 2.2 - Pinout do Conetor do Sensor. .................................................................... 8

Tabela 2.3 - Características da placa PXI - 6624. ........................................................ 11

Tabela 2.4 - Interface do hardware do controlador. .................................................... 16

Tabela 2.5 - Exemplos de estados do display 7-segmentos ......................................... 17

Tabela 2.6 - Pinout do Conetor X3 do Controlador. .................................................... 18

Tabela 3.1 - Requisitos do Operational Endurance Teste. .......................................... 28

Tabela 7.1 - Dados técnicos do motor. ........................................................................ 69

Tabela 7.2 - Dados técnicos do controlador. ................................................................ 69

Tabela 7.3 - Requisitos da fonte de alimentação externa. ............................................ 70

Tabela 7.4 - Parâmetros por defeito da comunicação RS232. ..................................... 70


Universidade do Minho – Hélder Vilas Boas – Bosch Car Multimedia 1

1. Introdução

Este Projeto de Dissertação surge no âmbito de um estágio na empresa Bosch Car

Multimedia Portugal S.A. localizada em Braga. O projeto tem como objetivo o

desenvolvimento de um sistema de teste e monitorização para sensores de direção

utilizados na indústria automóvel para a implementação do Electronic Stability

Program (ESP).

1.1 Motivação

Atualmente no setor industrial existe uma grande concorrência e competitividade

entre as empresas. Aspetos como o custo de produção e a qualidade dos produtos são

cruciais para o sucesso destas empresas. A empresa Bosch Car Multimedia encontra-se

ligada ao setor da indústria automóvel, no qual são exigidas características relacionadas

com a durabilidade, qualidade e fiabilidade dos equipamentos.

Neste sentido existe uma secção responsável pela Gestão da Qualidade e Métodos

(QMM – Quality Management Methods) na empresa. Das várias competências desta

secção destaca-se o teste da qualidade e fiabilidade dos produtos provenientes das linhas

de produção.

Sendo esta Dissertação realizada num ambiente industrial possibilitará uma

primeira abordagem ao mercado de trabalho, onde são exigidas maiores

responsabilidades e uma maior disciplina. Este estágio permitirá também aplicar muitos

dos conceitos adquiridos ao longo do curso, bem como aprofundar e aprender sobre

novas temáticas.

1. Introdução


2 Universidade do Minho – Hélder Vilas Boas – Bosch Car Multimedia

1.2 Enquadramento - ESP

Ao longo dos últimos anos têm sido desenvolvidos sistemas ativos de segurança

que contribuem significativamente para a redução do número de acidentes, apesar do

aumento da densidade de tráfego. Dos vários sistemas ativos de segurança destacam-

se: o Sistema de Travagem Anti Bloqueio, também designado por ABS; o Sistema de

Controlo de Tração (TCS) e o Programa Eletrónico de Estabilidade (ESP).

O ABS previne o bloqueio das rodas durante a travagem, e por sua vez, o TCS evita

que as rodas percam tração nas acelerações. Enquanto estes sistemas intervêm na

dinâmica longitudinal do veículo, o ESP melhora a dinâmica lateral, garantindo, assim,

uma condução estável em todas as direções.

Em vários estudos internacionais assumidos pelos principais fabricantes de

automóveis e autoridades de segurança, concluiu-se que pelo menos 40% de todos os

acidentes com feridos mortais são causados por derrapagens. Estes estudos também

demonstraram que o ESP pode reduzir até 80% o número de mortes e feridos em

acidentes rodoviários, bem como, contribuir de forma importante na segurança

rodoviária. Uma análise macroeconómica efetuada em 2007 pela Universidade da

Colômbia demonstra que só na Europa poderiam ser salvas 4 mil vidas e 100 mil feridos

se todos os veículos estivessem equipados com o sistema ESP.

Na Europa 80% das marcas utilizam o acrónimo ESP, contudo este sistema também

pode ser designado por DSC (Dynamic Stability Control), VSA (Vehicle Stability

Assist) ou VSC (Vehicle Stability Control). As funcionalidades e o modo de operação,

bem como os benefícios adquiridos são os mesmos.

O principal objetivo do ESP consiste em corrigir situações de subviragem, (situação

em que o veículo numa curva tende a sair de frente), sobreviragem (situação em que o

veículo numa curva tende a sair de traseira) e problemas de falta de tração em

acelerações ou reduções bruscas [1]. Este programa é constituído por cinco elementos,

identificados na Figura 1.1.

1. Introdução



Figura 1.1 - Constituintes do ESP e a sua distribuição no veículo [1].

Legenda:

1. Unidade Hidráulica Integrada com a Unidade de Controlo;

2. Sensores de Velocidade das rodas;

3. Sensor de Ângulo de Direção (LWS);

4. Giroscópio e Acelerómetro;

5. Comunicação com a Unidade de Controlo do Motor (ECU).

A Unidade Hidráulica corresponde a um dos atuadores do ESP e é responsável por

regular a pressão nos travões das rodas, através de válvulas solenoides. A unidade de

controlo é responsável por processar toda a informação dos sensores e transmitir

comandos aos atuadores.

A unidade de controlo utiliza os sinais provenientes dos sensores de velocidade das

rodas para calcular a velocidade das mesmas. Para esta finalidade podem ser usados

dois tipos de sensores distintos: sensores passivos e sensores ativos. Ambos medem a

velocidade das rodas, sem contacto com as mesmas, através de campos magnéticos.

Atualmente os sensores ativos são os mais utilizados para este objetivo.

O Sensor de Ângulo de Direção é colocado na coluna de direção do veículo e

permite medir a posição do volante através do ângulo. Com base no ângulo do volante,

1. Introdução



na velocidade do veículo e na pressão de ambos os pedais (travão e acelerador) é

possível calcular a intenção de condução do condutor.

O giroscópio regista todos os movimentos do veículo em torno do seu eixo vertical.

A informação deste sensor e a sua conjugação com os sinais do acelerómetro lateral

permitem determinar a orientação do veículo e as forças a que o mesmo está sujeito.

O ESP comunica com o ECU através do barramento de dados, permitindo que o

torque do motor possa ser reduzido, tanto no caso em que condutor pretenda acelerações

bruscas, como no caso de deslizamento das rodas, sendo estas provocadas por excesso

de torque aplicado às rodas motrizes.

Resumidamente, o ESP verifica 25 vezes a cada segundo se a direção pretendida

pelo condutor corresponde à direção do veículo. Caso se verifique uma diferença nessas

direções (situação esta, vulgarmente conhecida como derrapagem) o ESP intervém

independentemente das ações do condutor, aplicando diferentes forças de travagem às

rodas e, caso seja necessário, reduz a potência do motor no sentido de estabilizar o

veículo [2].

O número de veículos equipados com o ESP tem aumentado constantemente e

estima-se que venha a aumentar ainda mais nos próximos anos. A Figura 1.2 evidencia

a implementação do ESP em veículos de passageiros e comerciais.

Figura 1.2 - Implementação do ESP ao longo dos anos [1].

1. Introdução



Em Março de 2009 o Parlamento Europeu concordou em tornar obrigatória a

implementação do ESP em todos os novos veículos. De acordo com a legislação, a

partir de Novembro de 2011 todos os novos veículos de passageiros e comerciais

registados na União Europeia estão equipados com o sistema ativo de segurança ESP.

A partir de Novembro de 2014 esta legislação será aplicada a todos os novos veículos.

Os acidentes rodoviários são responsáveis por retirarem a vida a quase 1.3 milhões

de pessoas e ainda por ferirem um número superior todos os anos. A meta da década de

ação para a segurança rodoviária é reduzir e estabilizar o número de perdas humanas

em 2020, garantindo que a visão de um mundo em que a mobilidade é segura se torne

uma realidade.

1.3 Objetivos

O intuito deste projeto consiste em analisar o comportamento de sensores de ângulo

de direção ao longo de vários ciclos de utilização sob diferentes ambientes climáticos.

Assim, pretende-se comandar e monitorar uma sequência de testes efetuados a um

conjunto de 6 sensores aplicados a um sistema de teste de vida acelerado, composto por

um veio motorizado integrado numa câmara climática. Esta monitorização incide na

amostragem no valor do erro do sensor.

De forma a tornar o interface com o sistema mais amigável e intuitivo para o

utilizador pretende-se desenvolver uma aplicação que cumpra, não só, os requisitos dos

testes de fiabilidade, como também, os requisitos funcionais. Entende-se por requisitos

funcionais todos os aspetos que atribuem à aplicação uma maior flexibilidade e

funcionalidade. De forma a criar um sistema que suporte diferentes modos de operação,

nomeadamente, o comando do motor que permitirá acionar os sensores, a aquisição dos

dados disponibilizados pelos mesmos e a combinação dos dois modos anteriores.

A implementação destes modos é de extrema importância, uma vez que permite a

utilização da aplicação para realização de diferentes testes, bem como, o teste de

diferentes sensores.

1. Introdução



1.4 Estrutura da Dissertação

Esta Dissertação encontra-se organizada em seis capítulos distintos, descritos e

enumerados de seguida.

No Capítulo 1, designado por “Introdução”, é descrito o enquadramento do trabalho

e são apresentadas as motivações, os objetivos e a organização da dissertação.

No Capítulo 2 são apresentados os componentes utilizados neste projeto de

desenvolvimento de um sistema de teste e monitorização para sensores de direção,

nomeadamente, o hardware e software do controlador, o motor e a placa de aquisição

de dados.

No Capítulo 3 são descritos os requisitos da aplicação, nomeadamente, as

especificações do interface com o operador e os modos de operação da aplicação de

teste. Além disso, também se efetua uma breve abordagem aos testes de fiabilidade.

O Capítulo 4 descreve as etapas de desenvolvimento da aplicação de teste, desde

os menus de definições aos modos de operação, bem como a estrutura da aplicação.

O Capítulo 5 é dedicado à avaliação do desempenho da aplicação, onde se apresenta

o resultado de alguns testes, permitindo retirar conclusões sobre a fiabilidade e

estabilidade da aplicação desenvolvida.

Finalmente, o Capítulo 6 encontra-se reservado para as conclusões obtidas após a

realização do trabalho e que permitiram a elaboração desta dissertação. Além disso, são

apresentadas sugestões de trabalhos futuros de forma a melhorar os resultados obtidos.



2. Análise do Problema

Neste capítulo pretende-se abordar todas as características físicas e lógicas dos

vários componentes necessários para a concretização do projeto. No final, e em jeito de

conclusão, mostra-se uma figura onde se conjugam as possíveis interligações entre os

vários equipamentos de forma a satisfazer os objetivos do projeto.

2.1 Sensor de Ângulo de Direção

Atualmente são produzidos na empresa dois tipos de sensores de ângulo de direção

(LWS - LenkWinkelSensor), distribuídos em duas classes. Na classe I encontram-se

agrupados os sensores com encoders incrementais, que apenas medem ângulos

relativos, no entanto, não possuem Interface CAN. Este tipo de sensores é designado

por LWS6, apresentado na Figura 2.1. Na classe II são agrupados os sensores com

encoders absolutos e com Interface CAN. Neste documento só serão abordados aspetos

relacionados com os sensores pertencentes à classe I, uma vez que para este projeto

apenas se pretende efetuar a aquisição de dados com este tipo de sensores.

Um encoder é um dispositivo eletromecânico que fornece na sua saída sinais

elétricos no formato de pulsos que podem, por sua vez, ser traduzidos em movimento,

direção e posição. O princípio de funcionamento do sensor LWS6 baseia-se no efeito

de Hall. Este fenómeno relaciona o surgimento de uma diferença de potencial num

condutor elétrico, transversal ao fluxo de corrente e um campo magnético perpendicular

à corrente.

2.Análise do Problema



a) b)

Figura 2.1 - Sensor LWS6: a) Constituintes do sensor; b) Aspeto final do sensor.

O hub é o elemento do sensor sujeito a movimento rotativo porque faz contacto

físico com a coluna de direção do veículo, e está dividido em 60 polos Norte e 60 polos

Sul. O campo magnético criado pelos ímanes permanentes do Hub origina uma

comutação no sinal de saída do sensor de efeito de Hall a cada transição do polo. Na

Tabela 2.1 encontram-se apresentados os dados técnicos deste sensor e na Tabela 2.2 a

correspondência dos pinos do conetor apresentado na Figura 2.2.

Tabela 2.1 - Dados Técnicos do Sensor LWS 6.

Dados Técnicos LWS6

Tipo de sensor Incremental

Princípio e Funcionamento efeito de Hall

Tensão de Alimentação 7V …16V DC

Interface Coletor Aberto

Corrente ≤ 25 mA

Velocidade Máxima < 2500º/s

Resolução ≤ 1,5º

Tabela 2.2 - Pinout do Conetor do Sensor.

Pinout do Conetor do Sensor

1 Sinal SASA - Fio Azul

2 Sinal SASB - Fio Amarelo

3 GND - Fio Preto

4 Alimentação - Fio Vermelho

5 Sinal S1 - Fio Verde

6 Sinal S2 - Fio Castanho

Figura 2.2 - Conetor do sensor.




O sensor LWS6 apresenta duas versões em que a diferença consiste no número de

encoders implementados. Numa versão apenas está disponível um encoder que

disponibiliza na saída dois sinais designados por S1 e S2. Na outra versão além deste

enconder é implementado um outro também com dois sinais cujos nomes são SASA

(Signal Steering Angle Sensor A) e SASB (Signal Steering Angle Sensor B). Ambas as

versões deste sensor utilizam encoders em quadratura, isto é, são compostos por dois

canais onde os pulsos se encontram desfasados 90 graus. Este desfasamento é

determinante na identificação da direção em que o sensor se movimenta. Por exemplo,

se o sinal do canal A do sensor estiver adiantando do sinal do canal B o sensor roda no

sentido direto (ponteiros do relógio), caso seja o canal B que esteja adiantado, o sensor

roda no sentido inverso. Na Figura 2.3 encontram-se apresentados os sinais de saída do

sensor. É importante referir que os sensores baseiam-se na montagem em coletor aberto,

sendo por isso necessária a utilização de resistências externas de pull-up para que os

sinais disponibilizados possuam a amplitude pretendida.

Figura 2.3 - Sinais fornecidos pelo sensor [Bosch].

Na Figura 2.3 os indicadores: 𝑇𝑥, 𝛼x e 𝛽𝑥 correspondem a valores expressos em graus,

sendo que:

𝑇𝑥- É o valor em graus correspondente ao período do sinal, aproximadamente 6°;

𝛼x- Corresponde ao valor em graus entre transições de nível, aproximadamente 3°;

𝛽𝑥- Corresponde ao valor em graus entre o início de estado e o ponto mediano

desse estado, determina o atraso entre os dois sinais, aproximadamente 1,5°.




2.2 Plataforma de Aquisição de Dados

A plataforma de aquisição de dados a ser implementada no projeto deverá suportar

a leitura dos sensores de ângulo de direção descritos anteriormente. Uma vez que estes

sensores incorporam encoders em quadratura segue-se uma breve explicação dos

modos de descodificação destes encoders.

Os encoders em quadratura suportam diferentes modos de descodificação,

denominados por: X1, X2 e X4. No modo X1, como se ilustra na Figura 2.4, quando o

sinal A se encontra adiantado em relação ao B o registo de contagem é incrementado

nas transições ascendentes do sinal A. Por sua vez, quando o sinal B se encontra

adiantado o registo de contagem é decrementado nas transições descendentes do sinal

A.

Figura 2.4 - Modo de descodificação X1.

No modo X2, como se evidencia na Figura 2.5, o registo de contagem é

incrementado e decrementado sempre que há uma transição do sinal A.


De uma forma similar o registo de contagem do modo X4 é

incrementado/decrementado nas transições de ambos os sinais. Este é o modo de

descodificação que permite uma melhor resolução, contudo, também é mais suscetível




a falhas, caso existam vibrações no encoder. Na Figura 2.6 encontra-se demonstrado

um exemplo deste modo de descodificação.


O registo de contagem referido na Figura 2.6 tem por base o funcionamento de um

contador que consiste num dispositivo que regista o número de transições de nível. Um

contador pode suportar além de funcionalidades de medição/contagem de pulsos, as

funcionalidades de gerador de pulsos. A National Instruments (NI) disponibiliza

dispositivos dedicados para a aquisição de dados (DAQ - Data Acquisition),

nomeadamente adequados para a contagem de pulsos. Um deles é o dispositivo PXI-

6624, que se encontra apresentado na Figura 2.7.

Tabela 2.3 - Características da placa PXI - 6624.

Figura 2.7 - Placa de aquisição de dados DAQ PXI-6624 [7].

Este tipo de placas são ideais para aplicações que exigem um elevado grau de

fiabilidade, desempenho e facilidade de integração com outros sistemas. Estas

características são requisitos para sistemas de monitorização industriais e aplicações de

Características da placa PXI-6624

Contadores/Temporizadores 8

Resolução 32 bits

Canais de Entrada 26 isolados

Canais de Saída 8 isolados

Tensão Máxima nos Canais 48V DC

Corrente Máxima de Entrada 10 mA

Clock 100kHz e 20MHz

Interface com barramentos PCI e PXI




teste de fabrico, como por exemplo, para a indústria automóvel, sistemas embebidos de

controlo e também para sistemas de verificação de linhas de produção.

Este equipamento é concebido para efetuar aquisição de dados com recurso a

temporizadores, contadores e buffers. Permite efetuar aquisição da posição através de

encoders em quadratura, contagem de pulsos, medição do período, medição da largura

de pulso e medição de frequência.

Como referido anteriormente, o dispositivo PXI-6624 permite um interface isolado

com os barramentos PCI ou PXI para a transferência dos dados. Existem 4 mecanismos

de transferência de dados através do barramento PCI: Direct Memory Access (DMA),

interrupções, entradas e saídas programadas e USB Bulk. Contudo, estes dois últimos

mecanismos não se encontram disponíveis neste dispositivo.

O DMA é um mecanismo que permite transferências de dados entre os vários

periféricos do sistema sem a utilização do CPU, fazendo uso de hardware dedicado para

este processo. Desta forma é possível atingir taxas de transferência altas e libertar o

processamento do CPU. Contudo, existe um número limitado de canais, que para o PXI

6624 é de três. No mecanismo por interrupções o dispositivo notifica o CPU que se

encontra disponível para efetuar a transferência e só depois de o CPU o permitir é

iniciada a transferência. A limitação deste mecanismo encontra-se na velocidade de

transferência dos dados, que no máximo pode ser igual ao clock do CPU.




2.3 Motor

O motor da câmara de teste é um Servo Motor Síncrono. Este tipo de motores é

também muitas vezes designado por AC Servo Motor sem escovas. Os Servo Motores

Síncronos têm um rotor com ímanes permanentes e um estator com alimentação

trifásica. O motor utilizado é também composto por um Resolver, como se pode

observar na Figura 2.8. Relativamente ao rotor, este apresenta pouca inércia e pode

alcançar um desempenho dinâmico rápido. O fluxo magnético produzido pelos ímanes

permanentes do rotor e o fluxo magnético produzido pelas correntes do estator

produzem as forças que geram binário e forçam a rotação do veio. No capítulo 7

Apêndices encontra-se apresentada a Tabela 7.1 referente aos aspetos técnicos do

motor.

Figura 2.8 - Servo Motor Síncrono [3].

Resolver

O modo de funcionamento de um Resolver tem por base o princípio do transformador

e possui um arranjo de três enrolamentos. O sinal de referência é ligado ao rotor através

de um transformador, permitindo que o enrolamento de referência rode à velocidade do

veio. Os outros dois enrolamentos encontram-se desfasados 90 graus mecânicos entre

eles, como se pode verificar na Figura 2.9. Ao rodar o enrolamento de referência é

induzida tensão nos outros dois enrolamentos e os sinais de saída destes são

posteriormente ligados a um amplificador, obtendo-se, desta forma, a posição e

velocidade do motor [3].




Figura 2.9 - Princípio de funcionamento de um Resolver [3][3].

Para calcular o ângulo (Ɵ) utiliza-se a função inversa da tangente do quociente entre

o valor 𝑉𝑐 e o valor 𝑉𝑠 ,como se pode verificar na expressão (1)

Ɵ = arctan ( 𝑉𝑐

𝑉𝑠) (1)

2.4 Controlador

Neste capítulo são abordados aspetos relacionados com o hardware, software, bem

como os módulos de controlo disponíveis no controlador do motor.

2.4.1 Módulos de Controlo

O controlador pode ser configurado para três modos distintos de operação: controlo

da corrente, controlo da velocidade e controlo da posição.

O controlo da posição é processado no controlador da posição e tem como entradas

dois sinais, um que corresponde ao valor de referência da posição, o outro corresponde

ao valor de referência da velocidade. Com base nestes sinais é gerado um novo sinal

correspondente à posição pedida e, por sua vez, este sinal é comparado com o valor

atual da posição do motor. O resultado desta comparação (erro) gera o sinal de

referência para o controlador da velocidade.

O controlo de velocidade é processado no controlador da velocidade e tem como

entradas dois sinais, um sinal que corresponde ao valor de referência da velocidade e o

outro corresponde aos tempos de aceleração e desaceleração. Com base nestes sinais é




gerado um novo sinal correspondente à velocidade pedida, que é comparado com o

valor atual da velocidade do motor. O resultado desta comparação gera o sinal de

referência para o controlador de torque. De forma a facilitar a perceção encontra-se

evidenciado o controlador da velocidade na Figura 2.10.

O controlo de corrente é processado no controlador do torque e tem como entrada

um sinal que corresponde ao valor de referência do torque. Com base neste sinal é

gerado um novo sinal que traduzirá a referência do torque num valor de referência para

a corrente. De seguida, este sinal de corrente é comparado com o atual valor de corrente

que atravessa os enrolamentos do motor. O resultado desta comparação gera um sinal

adequado de PWM (Pulse Width Modulation) para o circuito de potência do controlador

como se verifica na Figura 2.10.

Figura 2.10 - Interligação dos módulos de controlo.




2.4.2 Hardware

O hardware do controlador disponibiliza os conetores de entrada e saída apresentados na

Figura 2.11. A correspondência dos conetores está apresentada na Tabela 2.4.

Tabela 2.4 - Interface do hardware do controlador.

Figura 2.11 - Interface do hardware do controlador [5].

O conetor X1 permite a alimentação de todo o controlador, tanto para o circuito de

potência como para o circuito de controlo. No capítulo 7. Apêndices encontram-se

apresentadas as seguintes tabelas: Tabela 7.2, referente aos dados técnicos do

controlador e Tabela 7.3, referente aos requisitos da fonte de alimentação externa. Por

fim, o conetor X1, disponibiliza terminais para colocar uma resistência de regeneração

adicional para a travagem dinâmica. A resistência de regeneração permite dissipar

potência do barramento de tensão DC durante as desacelerações do motor. Quando

ocorre uma sobretensão no barramento de tensão DC a resistência é automaticamente

ligada bem como o Led “DB on”. O controlador utilizado já tem uma resistência interna

de 90 Ω e 400W [5].

No conector X3 encontram-se as entradas e saídas tanto analógicas como digitais

do controlador. Este conetor também disponibiliza os terminais para ligar os sinais de

controlo que permitem habilitar por hardware o controlador.

Interface do Hardware

X1 Alimentação

X3 Entrada e Saída de sinais

X6 RS232 / RS485

X7 Saída do Encoder

X8 Interface do Resolver do Motor

X9 Master Encoder

SW Switches

DB on Led Dinamic Break

Display Display de 7 segmentos




O terminal X6 é um conetor de 9 pinos do tipo D que permite ligar um porto de

comunicação RS232 ou RS485. As configurações por defeito da comunicação RS232

encontram-se apresentadas na Tabela 7.4.

O conetor X8 é um terminal de 9 pinos do tipo D e é o interface com o Resolver

interno do motor, cujos terminais são os da Figura 2.9. O conetor X7 é um terminal

auxiliar de saída do Encoder/Resolver interno do motor e pode ser utilizado para dar

feedback a outro controlador, utilizando o conetor X9 que é um terminal auxiliar de

entrada do Encoder/Resolver interno de um motor.

O terminal SW, ao lado do display de 7 segmentos, é composto por dez switches

on/off, que permitem algumas configurações por hardware. Neste salienta-se o switch

8 que corresponde ao Enable do Controlador e deve estar sempre na posição on.

Por último, o display de 7 segmentos permite fornecer informação sobre o estado

do controlador, bem como alertar para situações de erro. Na Tabela 2.5 encontram-se

apresentados alguns exemplos. Por sua vez, no manual de instalação do controlador

encontra-se a listagem dos possíveis estados do display [5].

Tabela 2.5 - Exemplos de estados do display 7-segmentos

Exemplos de estados do display

Controlador habilitado

Movimento posicional

Erro Geral

Erro: Barramento DC

em subtensão




Na Figura 2.12 estão apresentadas as ligações necessárias para o correcto

funcionamento do controlador.

Figura 2.12 - Ligações necessárias para o correto funcionamento do controlador [5].

A função dos pinos do conetor X3 encontra-se apresentada na Tabela 2.6.

Tabela 2.6 - Pinout do Conetor X3 do Controlador.

Pinout do Conector X3 do Controlador

P.7 Massa 0V

P.9 Enable 24V

P.10 Sinal de Emergência

P.11 Sinal da Câmara Climática

P.18 Sinal Relé - Luz Verde

P.19 Sinal Relé - Luz Branca

P.20 Sinal de Fim do Movimento




2.4.3 Software

O controlador é programado utilizando a plataforma MintMT (Motion INTeligence

Multi-Tasking) é uma linguagem estruturada de BASIC, projetada e otimizada como

principal propósito de tornar mais simples a programação de aplicações de controlo de

movimentos. Das várias funcionalidades do MintMT destacam-se o controlo da posição,

velocidade, torque e sincronização de múltiplos eixos.

O ambiente MintMT é composto por dois componentes principais: o WorkBench,

que é executado no computador anfitrião, e o firmware, que é executado no controlador.

O primeiro consiste num ambiente integrado de desenvolvimento, usado para

configurar, programar o controlador e comandar o motor. O firmware é baseado numa

Biblioteca de Movimentos (Mint Motion Library - MML).

A comunicação entre aplicações e o controlador é efetuada através de controlos

Mint ActiveX, que são instalados no PC juntamente com a instalação do WorkBench.

Estes controlos possibilitam a comunicação com a camada de Interface Immediate

Command Mode (ICM) através de tramas de dados. Assim, a camada ICM estabelece

o interface entre os controlos ActiveX e a MML [4] [5]. Na Figura 2.13 encontra-se

apresentada a arquitetura do software do controlador e a sua interligação com uma

aplicação no computador.

Figura 2.13 - Arquitetura do Software Mint.




2.5 Câmara Climática

Uma câmara climática permite criar diferentes ambientes climáticos através da

variação das condições de temperatura e humidade. Neste projeto em particular, a

câmara climática permitirá simular os diversos ambientes aos quais um sensor pode

estar sujeito durante o seu período de utilização num veículo. Na Figura 2.14 e na Figura

2.15 é possível ver o aspeto exterior e interior, respetivamente, da câmara climática

utilizada.

Figura 2.15 - Aspeto interior da Câmara.

A conjugação do desgaste provocado pelo motor com as condições climáticas

criadas pela câmara permitem simular aproximadamente 15 anos de utilização do

sensor, em apenas alguns dias. Na Figura 2.16 encontra-se apresentado um perfil de

temperatura aplicado num dos testes de fiabilidade. No gráfico verifica-se que a

temperatura varia entre -40°C e 85°C ao longo de aproximadamente 960 horas. O tempo

total encontra-se dividido em 26 blocos, cada um com condições específicas. O perfil é

criado e editado através de uma aplicação e de seguida é enviado para a câmara. Durante

a execução do teste a câmara devolve feedback da temperatura e da humidade à mesma

aplicação.

Figura 2.14 - Aspeto exterior da Câmara.

Figura 2.16 - Perfil de temperatura criado pela Câmara Climática.




2.6 Linguagens Utilizadas

A linguagem utilizada no desenvolvimento da aplicação foi o LabVIEW, uma vez

que é a linguagem utilizada na secção para o desenvolvimento de aplicações de teste e

monitorização. Neste subcapítulo também será introduzida a linguagem que permite

traduzir a sequência lógica do código desenvolvido de forma mais clara.

2.6.1 Introdução ao LabVIEW

O LabVIEW - Laboratory Virtual Instruments Engineering Workbench é uma

linguagem de programação gráfica que utiliza ícones em vez de linhas de texto para

criar aplicações. Em contraste com a programação baseada em texto, cujas instruções

determinam a execução do programa, o LabVIEW utiliza o fluxo de dados para

determinar a execução. Esta linguagem, também designada por linguagem G permite o

desenvolvimento de aplicações com interface com o utilizador recorrendo a um

conjunto de ferramentas e objetos. O interface com o utilizador é designado por Front

Panel cujos objetos são controlados por representações gráficas (código) que se

assemelham a um fluxograma, acedidas através do Block Diagram.

O LabVIEW fornece/suporta comunicação com hardware utilizando variadíssimos

protocolos, como por exemplo: GPIB, VXI, PXI, RS-232 e dispositivos DAQ plug-in.

Esta linguagem também disponibiliza bibliotecas, como por exemplo, o ActiveX e o

TCP/IP para conectar as aplicações à Web.

Como referido anteriormente, a programação nesta linguagem é efetuada

recorrendo a dois ambientes gráficos, designados por: Front Panel e Block Diagram.

No primeiro ambiente são definidas as variáveis de entrada e saída das Virtual

Instruments (VI’s), isto é, das funções, como se pode verificar na Figura 2.17. Além

disso, neste ambiente também são facultadas funcionalidades que possibilitam a

manipulação da apresentação dos dados para as VI’s.

Por outro lado, o segundo ambiente possibilita o desenvolvimento das VI’s, como

se apresenta na Figura 2.18. Neste ambiente são facultadas funções elementares de

programação em LAbVIEW.




Analisando com mais detalhe a Figura 2.17, destaca-se: a área “Controlos e

Indicadores”, onde são apresentados os controlos/indicadores de entrada/saída

utilizados nesta VI; a área de funcionalidades que disponibiliza todo o tipo de

controlos/indicadores; e, por último, destaca-se a área “Padrão de ligações e ícone da

VI”. O padrão de ligações define tanto o local como o tipo de variáveis de entrada/saída

da VI. Esta funcionalidade é indispensável para seguir as boas práticas de programação

em LabVIEW, bem como a identificação da VI através de um ícone.

Figura 2.18 - Ambiente de programação do Block Diagram do LabVIEW.

Figura 2.17 - Ambiente de programação do Front Panel do LabVIEW.




Esta linguagem permite o desenvolvimento de aplicações de registo e aquisição de

dados, controlo de instrumentação, análise de medições e apresentação de resultados.

Além disso permite criar executáveis stand-alone e bibliotecas partilhadas, tais como

DLL’s. Assim, em função do propósito da aplicação deve ser escolhida a arquitetura,

mais adequada, de forma a atingir melhores resultados. Na Figura 2.19 encontra-se

esquematizado um fluxograma guia para a escolha da arquitetura.

Figura 2.19 - Guia para a escolha da arquitetura de uma aplicação [8].

A escolha da arquitetura é de extrema importância, por isso, e de forma a efetuar

uma escolha prudente é necessário ter em atenção os requisitos da aplicação.




2.6.2 Introdução ao SDL

O Specification & Description Language (SDL) é uma linguagem com o propósito

de ser inequívoca na especificação, descrição da estrutura e comportamento, bem como,

nos dados de um sistema. O termo especificação na ótica desta linguagem traduz-se na

descrição dos requisitos comportamentais do sistema em questão. Por outro lado, o

termo descrição traduz-se na real descrição do comportamento do sistema após a sua

implementação. A estrutura da linguagem SDL é constituída essencialmente por três

tipos de elementos, designados por: sistema, bloco e processo, como se pode ver na

Figura 2.20. A comunicação entre os elementos é efetuada através de sinais. O sistema

representa o mais alto nível de abstração e é composto por um ou mais blocos. Os blocos

podem ser compostos por vários processos, bem como por outros blocos. Os processos

são essencialmente compostos por máquinas de estado, mas também podem ser

compostos por outros processos. É nos processos que se encontra definido a

comportamento dinâmico do sistema.

Figura 2.20 - Arquitetura da linguagem SDL.




2.7 Conclusão

Na Figura 2.21 encontra-se apresentado um esquemático que demostra uma visão

geral do problema. O controlador será responsável por aplicar a tensão adequada nos

terminais do motor, de forma a atuar os sensores em teste. Os sensores são alimentados

por uma fonte externa. Por fim, a aplicação de configuração permitirá programar os

ciclos de temperatura e humidade da câmara e efetuar a monitorização destes

parâmetros.

Figura 2.21 - Interligação dos vários componentes.



3. Requisitos da Aplicação

Este capítulo tem como principal intuito detalhar os requisitos da aplicação, para

isso, e de forma a realizar uma análise mais pormenorizada, são inicialmente abordados

os testes de fiabilidade que se pretendem efetuar a partir da mesma. Posteriormente

apresentam-se aspetos relacionados com o user interface, e por fim, abordam-se

diferentes comportamentos/modos de operação que a aplicação deverá suportar em

função do tipo de teste requerido.

3.1 Testes de Fiabilidade

Os testes de fiabilidade efetuados aos sensores de ângulo de direção são divididos

em dois grupos: Testes Climáticos e Testes Mecânico-Dinâmicos. Os testes do primeiro

grupo são essencialmente testes que permitem monitorar os sinais fornecidos pelos

sensores quando sujeitos a alterações climáticas. Os Testes Mecânico-Dinâmicos

permitem testar o comportamento dos sensores quando os mesmos são sujeitos a

movimentos, vibrações e desgaste das partes móveis dos sensores.

Um dos testes que a aplicação deverá permitir efetuar é um Teste Climático

designado por Temperature Cycling. Neste teste o hub dos sensores é fixado à sua

própria estrutura e estes são submetidos a variações climáticas, em simultâneo

monitoriza-se os sinais disponibilizados pelos sensores através da aplicação. Um outro

tipo de teste é o Teste Mecânico-Dinâmico de desgaste, designado por Operational

Endurance Test, que consiste em aplicar movimento ao hub do sensor de forma a

provocar um desgaste. Neste teste, também, são alteradas as condições climáticas

através da câmara climática e, por fim, é efetuada a monitorização através da aplicação.

O principal objetivo deste teste é simular o período operacional do sensor em apenas

alguns dias. Na Tabela 3.1 são apresentados alguns requisitos deste tipo de teste.

3.Requisitos da Aplicação



Tabela 3.1 - Requisitos do Operational Endurance Teste.

Operational Endurance Test

Temperaturas 23ºC / -40º C / 85ºC

Humidade 95% / 85%

Número de Blocos 26

Número de Ciclos 1000

Ângulo Máximo 720º

Velocidade 60 rpm / 80 rpm

Tempo de Aceleração 200ms

Tempo de Desaceleração 200ms

Tensão de Alimentação 13,5V

Os movimentos aplicados aos sensores encontram-se apresentados na Figura 3.1

onde se verifica a sequência dos ângulos bem como o número de repetições que são

exigidas de forma a alcançar o tempo estipulado (90s ou 120s dependendo da

velocidade). A toda a sequência definida na Figura 3.1a) é atribuído o termo: ciclo.

Sendo que o teste é composto por 26 blocos e que cada bloco terá no máximo 1000

ciclos. Na Figura 3.1 b) encontra-se apresentado o tempo esperado para um bloco de

1000 ciclos.

Figura 3.1 - Especificação dos movimentos aplicados aos sensores:

a) Sequência de um ciclo; b) Duração esperada para um bloco.




3.2 Interface com o Utilizador

A Aplicação deverá ter um interface amigável e intuitivo para o operador, e

possibilitar funcionalidades para a configuração e edição dos programas, bem como, a

paragem do teste sempre que necessário. Toda a informação importante sobre o teste

em execução deve ser apresentada de forma clara e em tempo real.

Relativamente ao menu de edição, o operador deve ter a possibilidade de abrir

ficheiros de programas já guardados, e conseguir edita-los de forma a satisfazer os

requisitos do teste. Na eventualidade de não ser possível abrir um ficheiro todos os

campos devem ser preenchidos com dados por defeito, de forma a evitar situações que

comprometam o bom funcionamento de todo o hardware envolvido, assim como o bom

funcionamento da aplicação. Concluída a fase de edição o operador deve ter a

possibilidade de guardar o novo programa.

A arquitetura da aplicação deve prever três modos de operação: o comando do

motor, a aquisição de dados e o comando do motor conjugado com a aquisição de dados.

Durante a execução de um teste o operador deve ter acesso à informação sobre o

estado atual deste, nomeadamente, tempo decorrido, modo de operação e indicadores

caso ocorram erros no sistema, entre outros. Nos modos de operação de “aquisição” e

“comando e aquisição” a aplicação deve facultar informação gráfica relativa aos erros

dos sensores em teste, além disso, deve disponibilizar funcionalidades para uma análise

mais detalhada sobre a informação apresentada, nomeadamente ajustes nas escalas dos

eixos.

Também durante a execução do teste e em simultâneo com o user Interface a

aplicação deve registar em ficheiros todos os dados obtidos, de modo a que no final do

teste seja possível analisar qualquer período.

3.Requisitos da Aplicação



3.3 Modos de Operação

Em função do tipo de teste a efetuar aos sensores a aplicação deverá ter

comportamentos diferentes. De forma a abranger todos os testes são necessários três

modos: “Comando”, “Aquisição” e a combinação dos dois anteriores, isto é, “Comando

e Aquisição”. Assim, a aplicação deverá possibilitar um campo para escolher o modo

de operação do teste.

O modo de Comando é o mais simples e apenas se pretende que a aplicação

possibilite o comando do motor. Por outro lado, no modo de aquisição, a aplicação

deverá possibilitar a aquisição dos dados dos sensores, a monitorização e o registo em

ficheiros de todos os dados adquiridos. Por último no modo de aquisição e comando

pretende-se que a aplicação permita efetuar ambos os modos anteriores em simultâneo.




3.4 Arquitetura do Sistema

Na Figura 3.2 encontra-se apresentado um esquemático que demostra a interligação

entre os vários componentes a serem utilizadas no projeto. Como se evidencia na figura,

a aplicação partilhará informação com o controlador do motor, através de uma

comunicação série, e com a plataforma de aquisição de dados através de um barramento

PCI Express. A câmara climática disponibiliza um sinal digital que será interpretado

pelo controlador. Este sinal permitirá sincronizar os movimentos do controlador com

os perfis de temperatura e humidade da câmara. Os sensores são alimentados por uma

fonte externa e os seus sinais serão adquiridos pela plataforma de aquisição e reportados

à aplicação.

Figura 3.2 - Interligação dos vários componentes.



4. Desenvolvimento da Aplicação

Neste capítulo é efetuada uma apresentação, com algum detalhe e de forma sucinta,

do desenvolvimento da aplicação. Este capítulo encontra-se subdividido em:

Arquitetura da Aplicação, Menu de Definições e Modos de Operação.

4.1 Arquitetura da Aplicação

Em função dos requisitos apresentados verifica-se que a aplicação não possui uma

sequência fixa de teste, sendo que, necessita responder a ações desencadeadas pelo

utilizador e terá bastante processamento de dados. Analisando a Figura 2.19 conclui-se

assim, que a melhor arquitetura para esta aplicação será Produtor/Consumidor com

eventos.

A aplicação desenvolvida é constituída por cinco blocos, representados no

diagrama de blocos SDL da Figura 4.1. O processamento dos blocos é efetuado em

paralelo e a comunicação entre os blocos é estabelecida através de canais de

comunicação, designados por Queues. Cada canal tem um bloco de destino associado e

a gestão destes canais é baseada no modelo FIFO (First in First Out).

Figura 4.1 - Diagrama com a interligação entre os blocos do sistema.

4.Desenvolvimento da Aplicação



O “Bloco-Produtor” é responsável por interpretar os eventos, criados por ações do

utilizador, e proceder à criação de comandos que por sua vez serão transmitidos ao

“Bloco-Consumidor”, através do canal de comunicação. Por exemplo, caso o botão

“Settings” do menu de Interface com o utilizador seja pressionado, será gerado um

evento que é interpretado pelo “Bloco-Produtor”, que por sua vez, produzirá um

comando correspondente para o “Bloco-Consumidor”, que processará posteriormente

esse comando.

Devido ao contexto do problema, foi necessário criar duas flags: “Emergência” e

“Erro no Controlador”. A flag “Emergência” é ativada sempre que a botoneira de

emergência é pressionada. Esta ação gera uma interrupção no controlador com base

numa transição de estado da sua entrada digital associada à botoneira de emergência

(Figura 2.12 – Pino 10). Aquando desta situação a aplicação interromperá o normal

procedimento do teste e reportará esse estado ao operador. A nível elétrico, a botoneira

encontra-se ligada a um contactor que quando ativa abrirá os contactos que alimentam

o motor, desta forma é assegurado que o motor irá parar o movimento de qualquer das

formas. De forma análoga implementou-se a flag “Erro no Controlador”, cuja finalidade

consiste em reportar à aplicação qualquer tipo de erro que possa surgir no controlador

do motor, que colocará em causa o procedimento de teste. Existe uma lista de possíveis

erros fornecida pelo fabricante, a título de exemplo, podem surgir erros relacionados

com: o excesso de temperatura no motor, corrente consumida acima do estipulado ou

desconexão de uma das ligações do controlador. Quando uma destas situações, ou uma

análoga, surgir é gerada uma interrupção no controlador que reportará à aplicação o

respetivo erro no controlador. Da mesma forma, o procedimento de teste será

interrompido e o operador será notificado da situação. A função de monitorização

destas flags é atribuída ao “Bloco-Produtor”.

O “Bloco-Produtor” é composto por 7 processos. Por exemplo, na Figura 4.2

encontra-se ilustrado o processo “Botão Stop” inserido no “Bloco-Produtor”. Quando

o utilizador pressiona o botão “Stop” surge uma mensagem no ecrã questionando o

utilizador se realmente pretende parar o teste. Caso o utilizador confirme a paragem é

processada a instrução para limpar o buffer do canal e é produzido um comando “Stop”

para o “Bloco-Consumidor”.




Figura 4.2 - Diagrama SDL do processo "Botão Stop".

O “Bloco-Consumidor” é o bloco mais complexo do sistema, uma vez que é

responsável por processar os comandos do “Bloco-Produtor”, bem como é responsável

pelo processo que permite a introdução das definições do teste e por todos os processos

que permitem a gestão da sequência de teste e ainda por criar comandos para os

restantes blocos. Este bloco encontra-se dividido num total de quinze processos onde

todos partilham dois Clusters de dados. Um Cluster relativo às definições do teste e

outro Cluster relativo ao estado do teste em si. Entende-se por Cluster um conjunto de

variáveis de qualquer tipo de dados. Na Figura 4.3 é possível visualizar o conteúdo do

Cluster “Definições”. Este Cluster encontra-se subdividido em quatro Clusters e em

mais dois campos:

Cluster ”Definições de Registo” - contém o nome, diretoria, caminho e

referência para os ficheiros de registo;

Cluster ”Definições de Comando” - contém a sequência de ângulos e

blocos, bem como o Bloco e o Ciclo iniciais do teste;

Cluster “Definições do Controlador” - contém um Cluster com os

parâmetros da porta série, bem como um campo relativo aos pulsos por

volta do veio acoplado ao motor, que movimenta os sensores;

Cluster ”Definições de Aquisição” - contém uma tabela com informação

relativa aos contadores usados, um campo para o número máximo de

elementos apresentados nos gráficos, um Cluster agrupando o tempo total

de teste e a frequência de aquisição para os testes onde apenas se efetua

aquisição;

Campo ” Caminho do Ficheiro de Configurações” - guarda o caminho para

o ficheiro onde é guardado todo o Cluster ” Definições”;

Campo “Modo de Operação do Teste” - guarda o modo de operação do

teste: pode ter três modos: “Comando”, “Comando e Aquisição” ou

“Aquisição”.




Figura 4.3 - Conteúdo do Cluster “Definições”.

Na Figura 4.4 é possível visualizar o conteúdo do Cluster “Estado do Teste”. Este

Cluster é composto por:

Tabela de Ângulos - contém a sequência de ângulos;

Tabela de Blocos - contém a sequência de blocos;

Tabela de Resultados - contém os últimos dados obtidos no teste;

Tabela de Contadores - contém a sequência dos contadores selecionados

indiretamente pelo operador, quando este escolhe os canais a usar;

Tabela de Dados dos Encoders - contém os últimos dados adquiridos;

Cluster “Último Ângulo” - contém toda a informação relativa ao último ângulo,

nomeadamente, ângulo pretendido, velocidade, tempo de aceleração e

desaceleração, números do Bloco, Ciclo e Subciclo, em que o ângulo se

encontra inserido;

Cluster “Próximo Ângulo” - contém informação relativa ao próximo ângulo;

Dados dos Gráficos - contém a informação que é apresentada nos gráficos da

aplicação;

Tempo Decorrido do Teste - contém o tempo decorrido ao longo do teste;

Tempo Decorrido do Bloco - contém o tempo decorrido ao longo do bloco atual.

Figura 4.4 - Conteúdo do Cluster “Estado do Teste”.




O “Bloco-Display” (Figura 4.1) é responsável por atualizar toda a informação

disponível no menu principal da aplicação e encontra-se dividido em dezasseis

processos. Por sua vez, o “Bloco-Registo de Dados” é responsável por produzir e gerir

os ficheiros que contêm toda a informação gerada ao longo do teste. Por último, o

“Bloco-Registo de Erros” é responsável por produzir e gerir os ficheiros que contêm

apenas a informação relativa aos erros nas medições dos sensores sujeitos ao teste.

4.2 Menu de Definições

Sempre que o “Bloco-Consumidor” é iniciado pela primeira vez ou o utilizador

pressione o botão “Settings”, surge uma nova janela na aplicação que permite editar as

definições do teste. Na Figura 4.5 pode observar-se o ambiente gráfico dessa janela. A

janela “ Definições” é dotada das seguintes funcionalidades: Abrir Ficheiro, Guardar

Ficheiro e Editar Caminho do Ficheiro de Registo. Alem disso, faculta ao operador

acesso aos menus: “Command Settings”, “Aquisition Settings” e “Controller Settings”

bem como, permite escolher o modo de operação do teste.

Figura 4.5 - Ambiente gráfico da janela “ Definições”.




4.2.1 Definições de Comando

Quando é pressionado o botão “Command Settings” surge a janela apresentada na

Figura 4.6. Esta janela é composta pelos seguintes elementos: “Tabela de Ângulos”,

“Tabela de Blocos”, Cluster “Início do Teste” e os controlos de edição para ambas as

tabelas.

A “Tabela de Ângulos” é constituída por três colunas, a primeira indica o número

de Subciclos, isto é, o número de vezes consecutivas que o motor se movimentará para

o ângulo A e de seguida para o ângulo B. A segunda coluna indica o valor do ângulo A

e a terceira indica o valor do ângulo B. Cada linha desta tabela é designada por “Set” e

tem um número único associado que determina a ordem de execução desse “Set”.

A “Tabela de Blocos” é composta por quatro colunas, sendo a primeira referente

ao número de ciclos, isto é, o número de vezes consecutivas que a tabela de ângulos

será executada. A segunda coluna corresponde à velocidade expressa em rotações por

minuto (rpm). A terceira corresponde ao tempo de aceleração expresso em

milisegundos (ms) e a quarta, e última, coluna corresponde ao tempo de desaceleração

também expresso em milisegundos. Cada linha desta tabela é designada por “Bloco”.

As funcionalidades disponibilizadas pelos controlos das tabelas são: adicionar

linha, remover linha, limpar tabela, substituir linha, copiar linhas selecionadas e colar

as respetivas linhas.

Figura 4.6 - Ambiente gráfico da janela “ Definições de Comando”.




4.2.2 Definições de Aquisição

Quando na janela “Definições” é pressionado o botão “Acquisition Settings” surge

a janela apresentada na Figura 4.8. Esta é composta pelos seguintes elementos: “Tabela

de Canais”, controlos de edição para a tabela e campo “Elementos do Gráfico”. Cada

linha desta tabela é designada por “Canal” e no total existem 6 canais disponíveis, este

número de canais é um requisito do sistema. Assim, cada canal, do sistema

implementado, suporta a leitura de um sensor composto por no máximo dois encoders.

Sendo que cada encoder é composto por dois canais, como se apresenta na Figura 4.7.

A “Tabela de Canais” é composta por quatro colunas: indicação se o respetivo canal

será ou não usado; nome do dispositivo sujeito ao teste (DUT-Device under Test), que

é introduzido pelo operador e é único; tipo de sensor, existindo as possibilidades “S1/2”

e SASA/B”; por fim, a margem de tolerância para cada DUT.

1 Sensor 1 Canal

Encoder 1

Encoders 2

Canal B2

Canal A2

Canal B1

Canal A1

Figura 4.7 - Associação do conceito canal da plataforma de aquisição com os sensores.

O campo “ Elementos do Gráfico” representa o número máximo de elementos que

terão os gráficos, apresentados ao longo do teste.

Figura 4.8 - Ambiente gráfico da janela “ Definições de Aquisição”.




4.2.3 Definições do Controlador

Quando na janela “Definições” é pressionado o botão “Controller Settings” surge

a janela apresentada na Figura 4.9. Esta é composta pelos seguintes elementos: Cluster

“Porta Série” e campo “Pulsos por Volta”. Nesta janela encontram-se também

implementadas funcionalidades que permitem efetuar um teste à comunicação entre a

aplicação e o Controlador, bem como, um teste aos indicadores luminosos do sistema.

Relativamente ao teste à comunicação, é enviada a instrução para habilitar o controlador

e verifica-se se a instrução foi executada com sucesso.

Figura 4.9 - Ambiente gráfico da janela “ Definições do Controlador”.

4.3 Modos de Operação

Neste subcapítulo é descrita a forma de implementação dos três modos de operação:

Modo de Comando, Modo de Aquisição e Modo de Comando e Aquisição.

4.3.1 Modo de Comando

Inicialmente o comando do motor foi efetuado segundo o modelo ilustrado na

Figura 4.10. Na linha temporal superior são apresentadas as comunicações entre o PC

e o controlador, na linha inferior pretende-se ilustrar o tempo de execução dos

movimentos no veio do motor. Cada instrução enviada pela porta série demora em




média cerca de 15ms. Como se verifica na Figura 4.10, inicialmente é enviado para o

buffer de movimentos do controlador o primeiro ângulo, através da instrução “Load

Angle A” e de seguida é enviada a instrução que dá inicio ao movimento através do

comando Go. O motor inicia o movimento e quando este é concluído, é despoletada

uma interrupção na aplicação através do comando “Idle”, enviado pelo controlador. No

momento posterior efetua-se a leitura do Resolver do motor, de forma a garantir que o

ângulo requerido foi o ângulo executado pelo motor. A instrução seguinte corresponde

ao envio do próximo ângulo para o buffer. E de seguida é enviada a ordem para o início

desse movimento.

O modelo apresentado é bastante simples de implementar, contudo existe um tempo

de espera significativo durante o qual o motor se encontra parado entre movimentos.

De forma a contornar esta situação, acionou-se uma saída digital do controlador para

reportar à aplicação quando um movimento é concluído. Este sinal é recebido pela placa

de aquisição de dados e depois enviado para a aplicação. Esta alteração requer uma

alteração no processo de comando, dada a necessidade de monitorização deste sinal.

Assim é possível manipular o movimento do motor de forma mais eficiente. Na Figura

4.11. encontram-se apresentadas a interligações entre os diferentes componentes

envolvidos.

Figura 4.11 – Componentes envolvidos no Modo de Comando.

Figura 4.10 - Diagrama temporal da sequência de instruções para o comando do motor.




Na Figura 4.12 encontra-se apresentado um diagrama temporal que demostra a

solução implementada. A figura tem uma terceira linha onde são apresentados os pulsos

enviados pelo controlador no fim de cada movimento através da saída digital.

Inicialmente é enviado para o buffer de movimentos do controlador o ângulo para

o primeiro movimento, e de seguida é enviada a instrução que dá inicio ao arranque do

motor através do comando “Go”. O motor inicia o movimento e é determinado o

próximo ângulo através da função “Get Next Angle”. No capítulo 7. Apêndices

encontram-se apresentadas as seguintes figuras, relativas a essa função: Figura 7.3,

relativa ao Front Panel e a Figura 7.4, relativa ao Block Diagram. Após ser determinado

o próximo ângulo procede-se ao envio via porta série desse ângulo para o buffer.

Quando o ângulo é alcançado o controlador coloca uma das suas saídas no nível lógico

1. Este pulso é interpretado pela aplicação, e de imediato é efeituada a leitura da posição

do resolver seguindo-se o envio do comando para iniciar o próximo movimento. O

processo repete-se até se executar o último ângulo.

Na Figura 4.13 estão apresentados unicamente os comandos em LabVIEW para a

execução de apenas um movimento. O fluxo de execução é processado da esquerda para

a direita. No lado esquerdo os quatro indicadores representam as variáveis de entrada,

sendo: “MintController” a referência para o controlador, “error in” o Cluster de erros,

Cluster “Angle” o ângulo pretendido, acedido pelo elemento “Requested Angle” e, por

fim, o Cluster “Drive Settings” que no elemento “Pulses/rev” contêm os pulsos por

volta, fornecidos pelo Resolver do motor, adequados para a configuração de redutoras

e correias acopladas ao veio do motor.

Figura 4.12 - Diagrama temporal ilustrativo da sequência de instruções para a execução de três

movimentos.




O comando “MoveA” coloca no buffer de movimentos um movimento de posição

absoluta, e tem como entradas o movimento absoluto pretendido e o respetivo eixo,

nesta aplicação apenas foi utilizado um e este está definido como sendo o eixo zero. De

seguida é processado o comando “MoveOutX”. Este comando permite definir a

alteração de uma saída digital nos momentos imediatamente seguintes à conclusão de

um movimento. Este comando também fica acumulado no buffer de movimentos e têm

como entradas a correspondente saída que se pretende configurar e o respetivo estado

que se pretende definir nessa saída após a conclusão do movimento. Estes dois

comandos, “MoveOutX”.e “MoveA”, correspondem à instrução “Load Angle A”

apresentada na Figura 4.12. Por fim é processada a ordem de execução do movimento

que se encontra no buffer e inicia-se o movimento do motor. Os dois indicadores do

lado direito correspondem às variáveis de saída. A velocidade, o tempo de aceleração e

desaceleração para os movimentos é sempre definido no início de cada bloco e os

respetivos comando em LabVIEW para definir estes parâmetros são semelhantes aos

apresentados na Figura 4.13.

Os comandos apesentados na Figura 4.13, como referido anteriormente, apenas

traduzem as instruções para a execução de um movimento. De modo que quando são

executados sucessivos movimentos existe a execução de comandos intercalados entre

estes. Um dos comandos é o “Read Angle”, e este é processado entre o comando

“MoveOutX” e o “DoGo”.

Por motivos de segurança foi implementado na aplicação um temporizador de

movimentos, vulgarmente este tipo de temporizadores é designado por Watchdog

Timer. Este temporizador é iniciado aquando da instrução de início de movimento, e

caso o tempo decorrido seja superior ao tempo máximo de execução desse movimento,

o processo é interrompido. O tempo máximo de execução de um movimento é

determinado pela expressão (2):

Figura 4.13 - Comandos em LabVIEW para a execução de um movimento.




𝑇𝑚𝑎𝑥 = [(𝐴𝑎 + 𝐴𝑠

𝑉) × 1000 + 𝑇𝑎𝑐𝑒𝑙 + 𝑇𝑑𝑒𝑠] × (1 + 𝑀𝑠𝑒𝑔) (2)

Cujas variáveis têm o seguinte significado:

𝑇𝑚𝑎𝑥 − Tempo máximo em 𝑚𝑠;

𝐴𝑎 − Ângulo atual em pulsos por volta.( 𝑝𝑝𝑣);

𝐴𝑠 − Ângulo seguinte em 𝑝𝑝𝑣;

𝑉 − Velocidade em pulso por volta por segundo (𝑝𝑝𝑣/𝑠);

𝑇𝑎𝑐𝑒𝑙 − Tempo de aceleração em 𝑚𝑠;

𝑇𝑑𝑒𝑠 − Tempo de desaceleração em 𝑚𝑠;

𝑀𝑠𝑒𝑔 − Margem de segurança expressa sob a forma de percentagem.

A implementação em LabVIEW deste temporizador encontra-se dividida em duas

etapas: a primeira corresponde à configuração (Figura 4.14) e a segunda corresponde à

verificação do tempo decorrido (Figura 4.15). A etapa a processar é definida pelo

comando “Timing_Motion” sendo os seus valores “Start” e “Check Time”

respetivamente.

Figura 4.14 - Implementação em LabVIEW da configuração do temporizador de movimentos.

Na etapa de configuração acede-se aos parâmetros necessários para se efetuar o

cálculo do tempo esperado para o movimento e depois de determinado inicia-se o




temporizador. Na etapa de verificação a função retorna verdadeiro ou falso caso o

temporizador tenha atingido ou não, respetivamente, o tempo definido na etapa anterior.

Figura 4.15 - Implementação em LabVIEW da verificação do temporizador de movimentos.

4.3.2 Modo de Aquisição

Na Figura 4.16 apresenta-se de forma simplista a interligação entre os componentes

envolvidos no modo de aquisição.

Figura 4.16 – Componentes envolvidos no Modo de Aquisição.

Na Figura 4.17 são ilustrados com mais detalhe os módulos de hardware da

plataforma de aquisição. Os terminais dos sensores LWS encontram-se conectados aos

terminais disponibilizados pelos módulos Shielded Desktop Connector Block (SCB)

onde se efetua o acondicionamento do sinal, permitindo que o dispositivo de aquisição

possa receber os sinais de forma adequada. Uma vez que, os sensores não possuem




resistências de pull-up, estas foram colocadas neste módulo, SCB, entre os terminais

dos sensores e as entradas dos contadores. O valor destas resistências foi determinado

tendo em atenção o valor máximo da corrente de entrada nos terminais dos contadores

(10mA) e a tensão de alimentação dos sensores (13,5V DC). Assim, foram utilizadas

resistências com o valor de 1.8kΩ, colocadas entre cada canal dos encoders e a tensão

de alimentação dos sensores.

Figura 4.17 - Diagrama de blocos do hardware utilizado no Modo de Aquisição.

A placa PXI–6624 apresentada no capítulo 2.2 Plataforma de Aquisição de Dados

foi utilizada devido às suas caracetísticas e foi colocada num slot’s do Chassi NI PXI

1033. A placa PXI-6624 está equipada com a tecnologia dedicada que integra

contadores com funcionalidades que permitem entradas e saídas digitais de dados (TIO

ASIC – Timer/Counter Input/Ouput Application Specific Integrated Circuits). Como se

encontra descrito na Tabela 2.3, a placa é composta por 8 Contadores/Temporizadores

organizada por Programmable Function Inpus (PFI), com 26 canais de entrada

isolados, 2 canais por cada contador mais 2 canais extra, e por 8 canais de saída isolados.

Uma vez que se pretende um sistema para testar no máximo 6 sensores, cada um

podendo ter 2 encoders, são necessários 12 contadores. Assim, são necessárias duas

placas PXI-6624. O Pinout da placa encontra-se apresentado na Figura 7.1 do Capítulo

Apêndices.

Os módulos SCB encontram-se conectados as placas PXI-6624 através de um cabo

SH100-100. A ligação entre o Chassi e o computador é estabelecida através de uma

placa NI PCI Express Host Card ligada diretamente ao barramento PCI Express do

computador. O interface com a placa PXI-6624 é disponiblizado por um conetor com




100 terminais (SCB-100). Na Figura 7.2 do Capítulo Apêndices encontra-se

apresentada a distribuição dos terminais na placa do módulo SCB-100.

Este módulo é bastante versátil, uma vez que a sua utilização pode ser para a

aquisição de dados de várias grandezas. Assim, é previamente necessário definir a

posição adequada de cada um dos Switches para a finalidade pretendida. Na Figura 4.18

encontram-se apresentadas as corretas posições dos Switches, para a interligação com

as placas PXI-6624.

Atendendo à Figura 7.1 do Capítulo Apêndices, segue-se uma pequena explicação

da finalidade de cada terminal do Counter0. Ao Source (terminal 1), deve ser ligado o

sinal a medir, ou o sinal que define a frequência de clock do Counter. Em aplicações de

leitura de enconders em quadratura, o sinal do canal A deve ser ligado a este terminal.

Por sua vez, a Gate, (terminal 3) pode ser configurada para diferentes tarefas,

nomeadamente: início, pausa ou paragem da contagem, configuração da frequência de

amostragem ou simplesmente para a aceder ao sinal que se pretende ler. Ao Aux

(terminal 5) deve ser ligado o sinal do canal B quando se pretende a leitura da posição

de encoders em quadratura. No Output (terminal 9), o Counter disponibiliza o seu sinal

de saída, geralmente é utilizado para gerar pulsos ou uma sequência de pulsos.

Apesar das vantagens do mecanismo de transferência de dados DMA, referidas no

capítulo 2.2, foi implementado o mecanismo que recorre de interrupções do CPU para

transferir os dados adquiridos pelos contadores. Dado que, no pior cenário é necessário

adquirir leituras de 12 contadores, e através do mecanismo DMA apenas é permitido a

leitura de 3 contadores. De forma a evitar interrupções desnecessárias do CPU e tornar

Figura 4.18 - Interligação do DAQ PXI-6624 com o módulo SCB-100 [7].




mais eficiente este mecanismo de transferência configurou-se um dos contadores a

funcionar como gerador de pulsos, a fim de definir a frequência de amostragem (sample

clock), com que o CPU é interrompido, de modo a gerir os dados que são recebidos

através do barramento e disponibilizados num buffer. Neste modo de operação (Modo

de Aquisição) a frequência de análise dos dados, provenientes dos sensores, é definida

pelo operador. De forma a assegurar que são analisados os dados com essa frequência

definiu-se uma frequência superior para a leitura dos sinais. Assim, no momento da

análise dos dados é apenas considerada a informação, no buffer, relativa à última leitura,

sendo a restante desprezada.

A Figura 4.19 apresenta a implementação em LabVIEW do gerador de pulsos. O

sinal definido tem uma frequência de 100Hz com um Duty-Cycle de 50%. Por sua vez

este sinal será disponibilizado na PFI8 do Slot3.

Figura 4.19 - Implementação em LabVIEW da configuração do gerador de pulsos.

A Figura 4.20 ilustra a sequência de procedimentos necessários para a aquisição

dos dados. Para cada canal definido pelo operador é necessário criar uma tarefa e nela

são definidas as configurações do canal, bem como, as configurações do encoder a ler.

Relativamente às configurações do canal, é necessário definir: o dispositivo que

desempenhará as funções de contador, a frequência de amostragem, o respetivo

terminal onde é aplicado o sinal com a frequência, o modo de transferência dos dados

e o modo de leitura do buffer de dados. Relativamente às configurações do encoder, é

necessário definir o valor de pulsos por volta, o ângulo inicial, e o modo de

descodificação.




No procedimento seguinte é enviada a ordem para que a contagem inicie. Uma vez

concluído esse procedimento é possível ler o registo do contador. Caso não seja

necessário efetuar uma nova leitura é dada a ordem de paragem da contagem. Por

último, a tarefa é eliminada para que possam ser criadas novas tarefas sem restrições de

memória nos próximos testes.

Figura 4.20 - Sequência de estados no processo de aquisição de dados dos sensores.

4.3.3 Modo de Comando e Aquisição

Este modo combina os dois modos anteriores, e as interligações entre os

componentes encontram-se apresentadas na Figura 4.21.

Figura 4.21 – Componentes envolvidos no Modo de Comando e Aquisição.

A sequência de estados deste modo encontra-se apresentada na Figura 4.22. No

estado “Iniciar Processo” procede-se à configuração de todos os parâmetros do

controlador, bem como do dispositivo de aquisição de sinais. De seguida verifica-se se

ambos os dispositivos devolveram um feedback positivo após a configuração, caso um

deles devolva um erro o processo transita para o estado “Parar Processo”, que será

descrito posteriormente. Se a inicialização for bem sucedida, verifica-se o sinal digital

fornecido pela câmara climática. Esta verificação é necessária, pois permite a

sincronização do sistema com a respetiva câmara. Caso a câmara não se encontre com

o perfil de temperatura e humidade adequado ao bloco em execução o sinal digital




mantem-se no nível lógico 0, e o processo mantem-se nesta verificação, segundo o

modelo de polling, até o sinal passar para o nível lógico 1. Uma vez estabelecida a

sincronização entre os equipamentos procede-se ao início do bloco.

Figura 4.22 - Sequência de estados do modo de comando e aquisição.

No estado “Iniciar Bloco” é enviado para o controlador: a velocidade; o tempo de

aceleração e o tempo de desaceleração, bem como, o primeiro ângulo do bloco em

questão. O valor destas variáveis é necessárias para o correto funcionamento do

controlador da posição apresentado na Figura 2.10. De seguida é enviada para o

controlador a instrução para iniciar o movimento, inicia-se o temporizador, e é

calculado o tempo máximo de execução deste movimento.

No procedimento “Determinar Próximo Ângulo” e como o nome indica, é

determinado o próximo ângulo, sendo este apenas enviado para o controlador (só será

iniciado após a ordem de início, conforme explicado na secção 4.3.1 na Figura 4.12).

Depois, verifica-se se o motor já alcançou o ângulo do movimento previamente

iniciado. Se o resultado da verificação “Ângulo Alcançado?” for negativo procede-se à

verificação do temporizador.




No procedimento “ Parar Processo”, o normal fluxo do processo é interrompido e

envia-se para o controlador a instrução que permite a paragem do motor. Sendo também

enviada uma instrução para parar a leitura dos sensores, e por fim, é enviada para o

interface com o utilizador uma notificação do sucedido. Por outro lado, caso o tempo

decorrido seja inferior ao tempo máximo é verificado de novo se o ângulo do motor foi

alcançado. Caso o controlador devolva um sinal a indicar que o ângulo foi alcançado o

processo executa o procedimento ”Leitura dos Encoders”.

No procedimento “Leitura dos Encoders”, o motor encontra-se parado. De forma a

tornar o teste/aquisição mais eficiente, o tempo em que o motor se encontra parado deve

ser o mínimo possível. Para isso, procede-se à leitura de todos os contadores, bem como,

do resolver do motor, inicia-se logo o novo movimento, e só depois se faz a análise dos

dados recolhidos. No fim de cada movimento verifica-se se o ângulo testado

corresponde ao último do bloco. Caso se verifique essa situação o processo avança para

a fase “Analisar Dados”, se não é executada a ação “Iniciar Novo Ângulo”.

Na ação “Iniciar Novo Ângulo” é transmitida para o controlador a instrução que

procede ao arranque do motor para o ângulo previamente carregado no vetor de

movimentos. Além disso, procede ao cálculo do novo tempo máximo para a

concretização desse movimento e é reinicializado o temporizador do movimento,

referido no final da secção 4.3.1.

No final do último movimento do bloco ou após o início de um novo movimento é

executada a ação “Analisar Dados”. Nesta ação é calculado o ângulo alcançado pelo

motor (com base nos valores dos encoders/resolver) e comparado com o ângulo

requerido. Caso exista uma diferença nestes ângulos superior a 1 grau é incrementado

o contador “System Fails”, e é reportada essa informação para o ficheiro de registo do

teste. No capítulo 7 Apêndices encontram-se apresentadas as seguintes figuras: Figura

7.5, relativa ao Front Panel da função responsável pela gestão das operações de escrita

no ficheiro de registo do teste e a Figura 7.6, relativa ao Block Diagram da mesma

função. É também nesta ação, “Analisar Dados”, comparado o ângulo alcançado pelo

motor com o ângulo de cada um dos sensores de forma a determinar os respetivos

valores de erro. Por fim, classificam-se os valores de erro em “Passou” ou “Falhou”,

em função da margem de tolerância estipulada para cada sensor.




Uma vez concluído o estado “Analisar dados” é verificado de novo se o movimento

executado corresponde ao último do bloco. Caso se verifique essa situação o processo

transita para o procedimento ”Fim do Bloco”, se não é executado o procedimento

“Determinar Próximo Ângulo” e inicia um novo ciclo.de movimento.

No estado ”Fim do Bloco”, gera-se um ficheiro TDMS (Technical Data

Management System) que regista o número de falhas por sensor durante a execução

deste bloco, o tempo decorrido, o número acumulado de erros por sensor e o tempo

decorrido ao longo do teste. O ficheiro tem o nome “ReportFailsBlockX”, onde X

representa o número do bloco. De seguida verifica-se se existe outro bloco a executar,

caso exista é efetuada a verificação do sinal digital da câmara climática e o processo

inicia um novo bloco. Caso o teste tenha terminado o processo transita para a etapa

“Fim do Processo”. Nesta etapa procede-se à paragem da aquisição de dados dos

encoders dos sensores LWS, tal como está apresentado na Figura 4.20, e o processo

termina.

Na Figura 4.23 pode-se observar as leituras obtidas através de um osciloscópio

digital. A linha a azul-escuro corresponde à saída digital do controlador. Uma transição

ascendente deste sinal é interpretada pela aplicação como a conclusão de um

movimento por parte do motor. O sinal é colocado, posteriormente, no nível lógico zero

quando se inicia o próximo movimento. A linha azul claro e a linha castanha

correspondem aos sinais do canal A e canal B, respetivamente, de um encoder em

quadratura de um sensor de direção.

Figura 4.23 - Sinal digital do controlador e os respetivos pulsos de um LWS.




Na Figura 4.24 encontram-se apresentados com mais detalhe os sinais referidos

anteriormente. Estes sinais foram obtidos durante movimentos com uma reduzida

amplitude angular, cerca de 36º. Na mesma figura vê-se o desfasamento entre o sinal

do canal A e o sinal do canal B de 90º. Além disso também se conseguem identificar os

períodos de aceleração e desaceleração sofridos pelos sensores, períodos estes, visíveis

atendendo à variação da frequência dos sinais do canal A e B. Ainda sobre a Figura

4.24, destaca-se o período em que o motor se encontra parado, inferior a 50 𝑚𝑠, visível

através da saída digital do controlador.

Figura 4.24 - Sinais adquiridos por um osciloscópio no modo de comando e aquisição.




4.4 Conclusão

Na Figura 4.25 encontra-se ilustrada a bancada de desenvolvimento do projeto.

Figura 4.25 - Bancada de desenvolvimento do projeto.

Legenda:

1. Interface com o Operador;

2. Computador;

3. NI PXI 1033 Chassis;

4. Módulo SCB- 100;

5. Terminais para a ligação dos sensores;

6. Fonte de Alimentação DC dos sensores;

7. Sensores LWS e Suporte;

8. Motor;

9. Controlador do Motor e a Fonte de Alimentação DC;

10. Botoneira de Emergência;

11. Disjuntor e Seccionador;

12. Contactor para alimentação do motor;

13. Osciloscópio.



5. Resultados

Neste capítulo pretende-se apresentar o aspeto final da aplicação, a interligação dos

vários componentes utilizados e os resultados de alguns testes efetuados à aplicação.

A Figura 5.1 mostra o protótipo final e a interligação dos equipamentos envolvidos

no projeto.

Figura 5.1 - Interação do equipamento no laboratório.

Legenda:

1. Interface com o Operador;

5. Resultados



2. Computador;

3. NI PXI 1033 Chassis;

4. Módulo SCB- 100 e terminais para ligação dos sensores;

5. Fonte de Alimentação DC dos sensores;

6. Sensores LWS e Suporte

7. Motor

8. Localização do Quadro Elétrico com o Controlador do Motor (ao fundo);

9. Botoneira de Emergência;

10. Veio;

11. Sistema mecânico de correias;

12. Câmara Climática;

13. Indicadores luminosos do estado do teste.

Na Figura 5.2 encontra-se ilustrado a organização do quadro elétrico que alimenta

o motor.

Figura 5.2 - Organização do quadro elétrico que alimenta o motor.

Legenda:

1. Controlador do Motor;

2. Resistência de regeneração de 56Ω;

3. Fonte de Alimentação DC;

4. Seccionadores;

5. Resultados



5. Contactor para alimentação do motor;

6. Relés que alimentam os indicadores luminosos do estado de teste.

5.1 Modo de Comando

A Figura 5.3 apresenta o aspeto gráfico da aplicação desenvolvida “LWS

Endurance Test System” no modo de comando. O teste consiste em dois blocos cada

um com mil ciclos cuja sequência de comando é a definida na Figura 3.1.

Os indicadores: Block, Cycle, e Sub-Cycle informam sobre o movimento atual do

teste. A informação desse movimento é colocada na última linha da Test Table. O

indicador “System Fails” é incrementado sempre que um movimento do motor não

corresponda ao movimento requerido nas definições de comando. A barra de estado

que se encontra na parte inferior reporta ao operador o estado atual do teste, podendo

adquirir três cores: verde (a decorrer), vermelho (processo parou/ emergência), laranja

(processo concluído).

Figura 5.3 - Aspeto gráfico da aplicação no Modo de Comando.

5. Resultados



5.2 Modo de Aquisição

A Figura 5.4 apresenta o aspeto gráfico da aplicação a operar no modo de aquisição.

Na aba “ Table” são apresentadas duas tabelas, uma referente às falhas de cada encoder

(tabela da esquerda) e outra referente aos resultados dos últimos movimentos do teste

(tabela da direita). Com base nesta última tabela é escrito o ficheiro de registo de dados

que se apresenta na Figura 5.8

Como se verifica na tabela à esquerda, o teste foi efetuado a dois sensores sendo

analisados os dados fornecidos pelos seus dois encoders. A frequência de aquisição

neste modo é configurada pelo utilizador, sendo este valor apresentado no indicador

“Sample rate (Hz):”.

Figura 5.4 - Aspeto gráfico da aplicação no Modo de Aquisição

5. Resultados



De forma a facilitar a análise dos dados recolhidos ao longo do teste foi

desenvolvida a estrutura gráfica apresentada na Figura 5.5. A aba selecionada é

referente ao canal 6 que, neste exemplo em particular, está associado ao sensor “A02”.

O gráfico à esquerda é referente ao valor de erro dos sinais S1/2, deste sensor (sinais

estes mencionados na secção 2.1). Por sua vez, o gráfico à direita é referente ao valor

de erro dos sinais SASA/B do mesmo sensor. As linhas a vermelho representam as

margens de tolerância superiores e inferiores, enquanto a linha verde representa o erro

do sensor. O eixo vertical é expresso em graus, por sua vez, o eixo horizontal expressa

o tempo no formato HH:MM – DD/MM/AAA. Com base nos dados apresentados nos

gráficos é escrito o ficheiro de erros apresentado na Figura 5.9.

Figura 5.5 - Aspeto dos gráficos da aplicação no Modo de Aquisição.

5. Resultados



5.3 Modo de Comando e Aquisição

A Figura 5.6 apresenta o interface desenvolvido para o modo de operação

“Comando e Aquisição”. Para esta situação foi, inicialmente, configurado o

Operational Endurance Test com a sequência de comandos apresentada na Figura 3.1.

No menu “Definições de Aquisição” definiu-se a aquisição de dados de 6 sensores,

todos do tipo SASA/B (dois encoders por sensor) e com uma tolerância de ± 3º.

Destaca-se o facto da imagem apresentada ser adquirida 290 horas, aproximadamente,

depois do início do teste como se verifica no indicador “Elapsed Test Time”.

Figura 5.6 - Aspeto dos gráficos da aplicação no Modo Comando e Aquisição.

5. Resultados



A janela Windows Task Manager da Figura 5.7 mostra a taxa de ocupação do CPU

e a memória RAM utilizada pelo sistema no momento em que o teste concretizava,

aproximadamente, 290 horas. A aplicação foi testada num PC com o sistema operativo

XP e a memória RAM utilizada antes da execução era na ordem dos 800 MB. Veja-se

que no instante em que é executado um ângulo de reduzida amplitude (36º),

consequentemente existe menos tempo para o processamento da informação, o que se

traduz numa maior taxa de utilização do CPU.

Figura 5.7 - Aspeto das tabelas de resultados da aplicação no Modo Comando e Aquisição.

Na Figura 5.8 apresenta-se a organização do ficheiro de registo de dados. Este

ficheiro tem o nome: RPR2013.NNN, onde o NNN representa o número do processo

associado aos sensores submetidos a teste. Todos os ficheiros de registo de dados

encontram-se limitados a 100 mil linhas, para não ocupar demasiada memória RAM,

dado que o ficheiro é aberto no início e apenas fechado quando é atingido o limite

definido. Esta abordagem oferece uma maior velocidade no processo de escrita, e

melhora a eficiência de todo o processo.

5. Resultados



Como se pode ver este ficheiro é composto por 12 colunas e cada linha deste

ficheiro corresponde a uma leitura de um encoder.

O ficheiro de registo de erros, apresentado na Figura 5.9, só contém os erros obtidos

de cada sensor e apenas foi criado para facilitar a análise dos dados. Este tipo de

ficheiros tem o nome: DataGraphsBlockX, sendo X o número do bloco correspondente

à aquisição dos dados. Encontra-se organizado em 13 colunas, em que a primeira

corresponde ao tempo, e as outras correspondem ao erro dos encoders dos sensores.

Figura 5.9 - Organização do ficheiro de registo de erros.

Figura 5.8 - Organização do ficheiro de registo dos dados.

5. Resultados



A vantagem deste ficheiro em relação ao ficheiro de dados consiste na facilidade

de representação gráfica dos dados recolhidos. Na Figura 5.10 apresenta-se um gráfico

correspondente a algumas amostras do ficheiro apresentado na Figura 5.9. O eixo

horizontal corresponde à data de aquisição dos dados, enquanto que o eixo vertical

corresponde ao erro do sensor expresso em graus. No gráfico encontram-se

apresentadas cinco séries legendadas na área superior esquerda do gráfico. Como se

visualiza, no gráfico, o valor do erro da maioria das amostras vária entre [-1,5;1.5], com

exceção da amostra referente ao sensor A03 do tipo S1/S2. Os valores de erro obtidos

dos outros sensores são justificados pelo princípio de funcionamento deste tipo de

sensores, cuja resolução é de 1,5°. O resultado obtido do sensor A03 deve-se à perda

de pulsos do respetivo encoder entre as 16h:05 e as 16h09, possivelmente causados pela

conjugação do desgaste mecânico com as condições climáticas a que o sensor foi

sujeito, provando uma sucessão de valores de erro. Assim, este teste permitiu, não só,

comprovar o bom funcionamento da aplicação, como também, detetar uma falha num

dos sensores.

Figura 5.10 - Representação gráfica de algumas amostras do ficheiro de registo de erros.



6. Conclusão

Neste último capítulo apresenta-se um resumo do trabalho desenvolvido e as

conclusões sobre o mesmo. Finalmente, são enumeradas algumas sugestões para

trabalho futuro.

6.1 Conclusões do Trabalho Desenvolvido

O objetivo deste trabalho era desenvolver um sistema de monitorização e teste de

sensores de direção LWS, com base numa câmara climática e um motor já existente na

empresa. Sendo a câmara climática controlada por uma rede Ethernet, o problema

consistia basicamente em comandar o motor e ler os sensores através de uma aplicação

baseada em PC.

Para ler os sinais de até 6 sensores com 2 encoders cada um, optou-se pela

utilização de uma placa de aquisição de dados da NI e a consequente escolha do

LabVIEW como ferramenta de desenvolvimento do software. A solução desenvolvida

incluiu a interligação dos vários componentes de hardware do sistema. Para além dos

sensores foi também ligado à placa de aquisição de dados o sinal digital proveniente do

controlador do motor. Para sinalizar que as condições climáticas pretendidas se

verificam dentro da câmara, foi estabelecida uma ligação de sincronização entre a

câmara climática e o controlador do motor.

A aplicação de monitorização e teste desenvolvida permite a criação, carregamento

e edição de programas de teste a partir de ficheiros, a configuração dos sensores a testar

e de parâmetros dinâmicos dos movimentos do teste, e as possibilidades de iniciar,

suspender e parar um teste. Durante a realização de um teste, são apresentados em

tempo-real todos os dados relevantes da monitorização e controlo e são gravados para

ficheiro.

O principal desafio no desenvolvimento da aplicação foi conseguir cumprir os

tempos requeridos para os movimentos e gerir a informação adquirida dos sensores.

6. Conclusão



De acordo com os objetivos estipulados aquando do início do trabalho, pretendia-

se uma aplicação bastante versátil de modo a suportar diferentes tipos de testes de

fiabilidade e a possibilidade de integração com outros equipamentos, permitindo assim,

o teste de diferentes tipos de sensores produzidos na empresa. Deste modo, é possível

afirmar que os objetivos foram cumpridos.

Analisando com mais detalhe alguns aspetos, conclui-se também que a escolha do

LabVIEW como linguagem de programação foi uma boa opção, dado que se revelou

ser uma linguagem bastante orientada para aplicações de monitorização. Por último,

nos testes finais à aplicação, verificou-se que a quantidade de dados recolhidos e

armazenados em memória era excessiva.

6.2 Sugestões de Trabalho Futuro

Como trabalho futuro, e de forma a reduzir o espaço ocupado em memória pelos

dados recolhidos ao longo dos testes, sugere-se a implementação de um campo nas

configurações e no processo de aquisição, de forma a possibilitar a definição de uma

frequência de aquisição menor, no modo comando e aquisição. Bem como, a

possibilidade de monitorização e registo dos dados apenas em situações de erro dos

sensores ou então em todas as situações (com e sem erro).

Com o intuito de tornar o sistema mais funcional, sugere-se também a

implementação de um mecanismo mais eficiente na seleção de canais a quando da

configuração do teste, de forma a permitir a utilização de um maior número de

contadores, das placas da NI, conseguindo-se dessa forma efetuar o mesmo teste a um

maior número de sensores.



7. Apêndices

7. Apêndices



Tabela 7.1 - Dados técnicos do motor.

Motor - BSM 80B - 150AA

Torque Nominal 1,63 Nm

Corrente Nominal 3,78 ARMS

Corrente Máxima 11 ARMS

Tensão no Barramento DC 300 V

Velocidade Máxima 7000 rpm

Velocidade Nominal 6000 rpm

Número de Polos 4

Massa 4,1 Kg

Tabela 7.2 - Dados técnicos do controlador.

Controlador - FPH2A05TB-RN23

Tensão Nominal de Entrada 230V AC

Tensão Mínima 220V

Tensão Máxima 250V

Corrente Nominal de Entrada 5ARMS

Corrente Máxima de Saída 12ARMS

Potência Máxima de Saída 2,7kVA

Tensão Nominal no Barramento 320V DC

Tensão Mínima 306V DC

Tensão Máxima 350V DC

Eficiência >95%

Frequência de Saída 0-500Hz

Frequência de Nominal de Comutação 8kHz

7. Apêndices



Tabela 7.3 - Requisitos da fonte de alimentação externa.

Requisitos da Fonte de Alimentação Externa

Tensão Nominal de Entrada 24V DC

Tensão Mínima 20,4V

Tensão Máxima 28,8V

Ripple Máximo ±10%

Corrente Máxima de Saída 4A

Corrente Nominal de Saída 1,75A

Tabela 7.4 - Parâmetros por defeito da comunicação RS232.

Parâmetros da Comunicação RS232

BaudRate 57600 bps

Start bit 1 bit

bits de dados 8 bits

Stop bit 1 bit

Paridade Não

7. Apêndices



Figura 7.1 - Pinout NI PXI – 6624.

7. Apêndices



Figura 7.2 - Distribuição dos terminais na Placa SCB – 100.

7. Apêndices



Figura 7.3 - Front Panel da função responsável por determinar o próximo ângulo.

7. Apêndices



Figura 7.4 - Block Diagram da função responsável por determinar o próximo ângulo.

7. Apêndices



Figura 7.5 - Front Panel do bloco "Registo de Dados".

7. Apêndices



Figura 7.6 - Block Diagram do processo "Log" do bloco “Registo de Dados”.



Referências

[1] “ESP” Disponível online no dia 21 de Outubro de 2013, em <http://www.car-

engineer.com/esp-electronic-stability-program/>;

[2] “How ESP Work” Disponível online no dia 21 de Outubro de 2013, em

<http://www.bosch-

automotivetechnology.com/en/de/specials/specials_for_more_driving_safety/bosc

h_esp_3/esp__facts_4/esp_technik_2/esp_questions_and_answers_16.html>;“Ho

w a Brushless Motor Operates” Disponível online no dia 21 de Outubro de 2013,

em <http://www.motioncontrolonline.org/files/public/BrushlessOperation.pdf>;

[3] “Guide to motion control drives” Disponível online no dia 21 de Outubro de 2013,

em<http://www.motioncontrolonline.org/files/public/ABB-Guide-to-Motion-

Control-Drives.pdf>, (64 páginas);

[4] “Mint ActiveX help” Disponível online no dia 21 de Outubro de 2013, em

<http://www.baldor.com/support/Literature/Load.ashx/BR1202-B?LitNumber=BR1202-

B>;

[5] “Controlador Baldor - FPH2A05TB-RN23” Disponível online no dia 21 de

Outubro de 2013, em

<http://www.baldor.com/support/Literature/Load.ashx/MN1902?ManNumber=M

N1902>, (164 páginas);

[6] “SCB-100” Disponível online no dia 21 de Outubro de 2013, em

http://www.ni.com/pdf/manuals/371224b.pdf>;

[7] “NI PXI-6624” Disponível online no dia 21 de Outubro de 2013, em

<http://sine.ni.com/nips/cds/print/p/lang/pt/nid/14530>;

[8] “Design Pattern” Disponível online no dia 21 de Outubro de 2013, em

<http://forums.ni.com/attachments/ni/170/284351/1/LabVIEW>, (452 páginas).

http://www.car-engineer.com/esp-electronic-stability-program/

http://www.car-engineer.com/esp-electronic-stability-program/

http://www.bosch-automotivetechnology.com/en/de/specials/specials_for_more_driving_safety/bosch_esp_3/esp__facts_4/esp_technik_2/esp_questions_and_answers_16.html



http://www.motioncontrolonline.org/files/public/ABB-Guide-to-Motion-Control-Drives.pdf

http://www.motioncontrolonline.org/files/public/ABB-Guide-to-Motion-Control-Drives.pdf

http://www.ni.com/pdf/manuals/371224b.pdf

http://sine.ni.com/nips/cds/print/p/lang/pt/nid/14530

Hélder Manuel Silva Vilas Boas Desenvolvimento de um ...

Documents

Transcript of Hélder Manuel Silva Vilas Boas Desenvolvimento de um ...