software de control, d’adquisició de dades i de...
TRANSCRIPT
Software de control, d’adquisició de dades i de visualització gràfica per la Monitorització dels Esforços
al Caminar.
TITULACIÓ: Enginyeria en Automàtica i Electrònica Industrial
Autor: Albert Pérez Llorens
Director: Nicolau Cañellas Alberich
Data: Abril 2008
2
3
Índex
1 Objectius Del Projecte
1.1 Introducció 6
1.2 Antecedents 7
2 Especificacions del Projecte
2.1 Esquema General del Sistema 8
2.2 Estudis Biomecànics 10
2.3 Cèl·lules de càrrega i Cinta Dinamomètrica 13
2.4 Amplificadors d’ Instrumentació 15
2.5 Targeta d’ Adquisició 16
2.6 Programa Adquisició de Dades 17
2.7 Programa Control Motor
18
3 Disseny Programa Adquisició (Estàtica)
3.1 Disseny de la Interfície Gràfica 19
3.2 Disseny del Control del Sistema Operatiu 21
3.3 Disseny del Bucle de Temporització 24
3.4 Disseny Utilització de la Targeta 27
3.5 Disseny dels Fitxers de Sortida 32
3.6 Disseny del Filtre 34
3.7 Disseny del Codi representació gràfica 35
3.8 Disseny de l’aplicació
36
4 Disseny Programa MEC (Dinàmica)
4.1 Disseny de la Interfície Gràfica 41
4.2 Disseny del codi de Comunicació 43
4.3 Disseny del Codi inici adquisició i sincronització 50
4.4 Disseny de l’aplicació
52
4
5 Hardware
5.1 PCB Amplificadors
56
6 Avaluació
6.1 Temporització 59
6.2 Avaluació al centre en estàtic 65
6.2.1 Avaluació programa 65
6.2.2 Proves realitzades 69
6.3 Avaluació al centre en dinàmic 72
6.3.1 Avaluació programa 72
6.3.2 Proves realitzades 78
7 Conclusions
7.1 Programa Estàtica 79
7.2 Programa Dinàmica 80
8 Referències 81
9 Apèndix
9.1 Cèlul·les de càrrega 83
9.2 Amplificadors d’ Instrumentació 83
9.3 Targeta d’Adquisició 84
9.4 Programa Adquisició de Dades 90
9.5 Control Motor 91
5
1 Objectius Del Projecte
1.1 Introducció
El present projecte té com a objectiu la posta en marxa d’un software d’adquisició i representació de dades en l’entorn del sistema operatiu Microsoft Windows. El programa s’instal·larà a un centre podològic i ha de permetre treure una valoració dels esforços que realitza un pacient al caminar.
El sistema consta d’una cinta dinamomètrica on un pacient hi caminarà. Unes cèl·lules de càrrega (situades als corrons que fan girar la cinta) que ens permetran mesurar les forces aplicades al caminar (que són proporcionals al pes i donen informació de les possibles alteracions de la marxa). Les cèl·lules donaran un potencial segons la força exercida. Al ser aquest un potencial petit el farem passar per uns amplificadors. El valor dels amplificadors el llegirem amb una tarja d’adquisicó (PCL 818) que està conectada al PC. El nostre programa haurà de ser capaç de capturar aquestes dades, tractar-les i representar-les gràficament, tenint molta cura de fer l'adquisició de forma correcta sense veure'ns afectats per les característiques multitasca de Windows. Al voler fer adquisicions d’entre 1 ms i 10 ms, necessitarem crear-nos un retard per cumplir els períodes d’adquisició, degut a que la resolució mínima del timer del windows és superior a la desitjada (55 ms pel windows 98 i 10 ms pel windows Xp).
En el projecte, es realitzaran dos programes diferenciats segons es faci l'adquisició amb la cinta parada o amb aquesta en moviment, encara que tindran les mateixes bases a l’hora d’adquirir i representar.
En el primer programa, el que es pretèn és l’adquisició amb la cinta parada (caminant per damunt la cinta sense que aquesta és mogui).
Per altra banda, es farà un segon programa que ens permetrà fer l’adquisició del pacient corrent. Per tant, aquest programa ens haurà de permetre poder donar diferents velocitats i temps al variador del motor, per tal de poder realitzar estudis dels pacients corrent o caminant. Per realitzar aquesta part tenim un variador de freqüència amb un PLC que es comunicarà amb el port sèrie de l’ordinador amb el connector per RS-232. Per tant nosaltres enviarem les ordres al PLC i aquest, al variador.
Finalment, es vol aconseguir representar, des dels programes creats, les gràfiques corresponents a les adquisicons realitzades.
6
1.2 Antecedents
El projecte està destinat al Centre Podològic de Tarragona, on es realitza una part important d’investigació i desenvolupament de projectes de manera particular i sense ajut econòmic exterior. El centre compta amb una plataforma dinamomètrica amb vuit cèl·lules de càrrega que permeten capturar una sèrie de forces exercides sobre aquesta en caminar-hi per damunt. També compta amb una cinta que es fa girar amb l’ajut d’un motor, de tal manera que sembla una cinta de córrer d’un gimnàs. Aquestes cèl·lules estan estratègicament situades de manera que permeten capturar les forces verticals, anteroposteriors i mediolaterals de la marxa humana. En la següent imatge és pot observar la cinta amb l’esquema de la connexió de les cèl·lules de càrrega situades als corrons (és l’ampliació que hi ha feta de color vermell), on una mesura la força vertical, una altre la lateral, i la tercera, mesura l’anteroposterior.
Fig 1.1 Cèl·lules de carrega
El sistema es va intentar posar en funcionament en un projecte anterior sense aconseguir l’objecitu.
Els senyals de sortida de les cèl·lules s'acondiciona amb vuit amplificadors d’instrumentació. Aquests amplificadors ens permeten obtenir una tensió de sortida de 0 a 10 V, permeten l’ajustament de l’offset i del guany per a cada amplificador independentment. Per a més informació a l’apartat 2.4 del projecte es fa una descripció general dels amplificadors d’instrumentació utilitzats. Per alimentar els amplificadors s’utilitza una font d’alimentació regulada de ± 12 V, ajustable i amb ‘tracking’ que ens permet ajustar el valor de sortida amb gran precisió. Les sortides dels amplificadors es connecten a una targeta multi funció PCL 818L d’ “Advantech Industrial Automation”, que ens permetrà l'adquisició.
Tot aquest material ha estat adquirit pel Centre Podològic. Per tant, en el present projecte s’intentarà posar en marxa tot el sistema i proporcionar un software adient per al control, l’adquisició i visualització de les dades; aquesta integració ja s'havia intentat sense èxit en un projecte anterior.
7
2 Especificacions Del Projecte
En aquest apartat es pretén donar un coneixement general de l’estudi que es realitza en el caminar d’una persona per tal de poder entendre les dades que es veuran en el projecte. També s’explicaran els diferents components que intervenen en el projecte per veure quina és la funció que realitzen. La informació més tècnica de cada punt es troba en l’apartat 9.
2.1 Esquema General del Sistema
En aquest apartat veurem la conexió entre els elements del sistema així com l’adaptació dels senyals.
Per un costat, tenim el motor connectat a un variador de freqüència que em permetrà cambiar la velocitat. El programa no controla directament el variador de freqüència, sinó que nosaltres enviem les ordres a un PLC per mitjà de comunicació sèrie RS232. El sistema ja estava muntat d’aquesta manera i no és objectiu d’aquest projecte eliminar el PLC. Tenim informació de les ordres a enviar (accelerar, desaccelerar, engegar, parar...) al PLC perquè aquest per mitjà del variador controli el motor. En la figura 2.1 es pot observar la comunicació entre el motor i el PC per mitjà del PLC i el variador de freqüència.
Per altra banda, tinc les cèl·lules de càrrega que són els punts vermells (les 4 cèl·lules que mesuraran les forces verticals) que s’observen en la figura d’aquesta pàgina. Com s’indica en l’esquema, el seu rang de valors va des de 0 fins a 36 mV. Degut a què els valors són petits per llegir-los amb la tarja d’adquisició, passem els senyals dels sensors per uns amplificadors, que, al tenir un guany de 278, adapten la senyal de 0-36mV a 0-10V. Per tant, com les cèl·lules de carga són d’un màxim de 500 Kg, quan posem 500Kg damunt la cinta a la sortida tindré 10V. La senyal de 0-10V és llegida per la tarja d’adquisició que està connectada al PC. Per mitjà del programa és pasaran les senyals a Kg i s’en farà la representació gràfica.
Fig 2.1 Sistema General
8
Cinta amb el motor
En la figura 2.2 podem observar la cinta amb el motor.
Fig 2.2 Cinta i motor
Amplificadors
En la primera imatge s’observa el panell frontal que ens permet ajustar l’ofsset de cada canal. També podem observar l’interruptor per engegar el sistema. En la segona imatge observem la font que ens proporciona 12V i els dos amplificadors, cadascun de 4 canals.
Fig 2.3 Caixa amplificadors
Conexions al PC
En la imatge s’observa la connexió amb la targeta i la del port sèrie.
Fig 2.4 Connexions
9
2.2 Estudis Biomecànics
La biomecànica és l’estudi del cos humà com un sistema sota dos conjunts de lleis: les lleis de la mecànica Newtoniana i les lleis biològiques.
Per al present projecte ens interessa l’estudi que la biomecànica realitzarà sobre la cinemàtica i la cinètica del cos humà amb diferents patrons de comportament o activitats del cos humà sota tot tipus de situacions imaginables. Aquesta part s’anomena estudi de la marxa humana, i serà el tema del nostre projecte.
La marxa humana consisteix en un procés de locomoció on el cos humà es mou cap endavant amb el cap en alt i suportant el seu pes sobre les cames alternativament.
El fet de repetir dues vegades una passa s’anomena cicle de marxa o gambada. El principi del cicle es pren des del moment en què un dels peus pren contacte amb el sòl a través del taló i s’acaba quan torna a produir-se un nou contacte amb el mateix peu. Aquest cicle serà el patró a seguir alhora de representar les dades i tenir un control del que s’ha adquirit amb la targeta i la cinta dinamomètrica.
Cada passa es pot separar en dos fases distingibles : fase de recolzament, on un dels peus està en contacte amb la plataforma, i la fase d’oscil·lació, on l’altre està enlairat de la plataforma. El cicle de la marxa humana es representa en tant per cent. En una passa d’un peu tindrem que la fase de recolzament dura un 60% del cicle i la fase d’oscil·lació un 40%, havent-hi un 10% on es produeix una fase de recolzament bípeda i els dos peus prenen contacte amb la plataforma alhora. La figura 2.5 mostra un esquema del cicle de marxa i les seves fases per cada peu.
Fig 2.5 Gràfic del cicle de la marxa humana.
10
El nombre de passes donades en un interval de temps, en unitats de passes/s, s’anomena cadència, a on la cadència serà igual a:
Cadència (passes/s) = 2 / duració cicle.
o
Cadència (passes/min) = 120 / duració cicle.
A partir de la cadència, i juntament amb la longitud de la gambada (distància que es fa al fer una passa), podem extreure l’equació de la velocitat obtenint:
Velocitat (m/s) = longitud gambada (m/passos) x cadència (passos/s).
Les forces exercides pel pacient sobre la plataforma seran dependents del pes i moviment executat. Per tal de mesurar i analitzar aquestes forces s’utilitzen les plataformes dinamomètriques. Així, el podòleg serà capaç de valorar els resultats de la marxa humana, tècniques esportives o l’equilibri postural. D’aquestes forces se n’extreuen unes gràfiques característiques o patró. En la pàgina següent s’en mostren les gràfiques. D’aquí podrem veure si el que estem adquirint té algun sentit o no, i si pot ser utilitzat com a element d’estudi en un futur.
Fig. 2.6 Gràfiques per les forces de reacció obtingudes en la marxa humana.
11
La gràfica A de la figura 2.6 mostra la forma típica de les forces verticals. Aquesta forma es caracteritza per tenir una semblança a la lletra M, i serà el nostre patró de comparació a l’hora de definir si les dades adquirides són correctes o no. Una altra referència important que podem tenir per saber si la gràfica és correcta, és el fet que el pic màxim de la forma de la M és d’aproximadament 1,2 vegades el pes. Pel que fa al temps, sabem que el temps de realitzar una passa caminant normal (és a dir, sense córrer) és aproximadament 800 ms. La B serà la representació de les forces mediolaterals. I la C les forces anteroposteriors. Les tres gràfiques juntes formen un sistema tridimensional, on les forces mediolaterals representen l’eix X, les anteroposteriors l’eix Y i les verticals l’eix Z.
El que es pretén és disposar d'un sistema que permeti mesurar i representar aquestes corbes per a poder-ho utilitzar com a eina de diagnòstic. Tindrem les cèl·lules de càrrega que ens subministren una tensió positiva a la sortida en resposta a una compressió exercida, tindrem un variador que ens permetrà controlar el motor, els amplificadors per tal d’elevar les senyals dels sensors i una tarja d’adquisició que realitzarà la lectura d’aquests.
12
2.3 Cèl·lules de càrrega i Cinta Dinamomètrica
Les cèl·lules de càrrega són una forma típica de transductor que utilitza galgues extensiomètriques i serveixen per mesurar pes i forces. Les cèl·lules proporcionen una tensió positiva a la sortida en resposta a una compressió exercida sobre l’element on estan aplicades.
Les galgues extensiomètriques es munten sobre l’element mecànic sensible, cablejats en forma de pont de Wheatstone, ja que aquesta configuració, proporciona més sensibilitat en la tensió de sortida i permet una millor compensació de la temperatura fins a fer-la pràcticament nul·la. La mesura es realitza per deflexió, és a dir, la diferència de tensió existent a la sortida del sensor, per aquesta raó s’utilitzen els amplificadors d’instrumentació per condicionar el senyal de sortida proporcionat pel pont.
Fig. 2.7 Forma de pont de Wheatstone
En el nostre cas tenim vuit cèl·lules de càrrega instal·lades als dos eixos que fan girar la cinta. Cada cèl·lula mesura un tipus de força exercida sobre ella. Quatre ens mesuraran les forces verticals exercides (cèl·lules 5,6,7 i 8 de la figura 2.8) pel pacient en qüestió, com que són les que rebran un impacte més fort i, per tant, hauran de mesurar valors més elevats, tenen la capacitat de mesurar fins a 500 quilograms de pes.
Dues més mesuraran les forces anteroposteriors exercides pel pacient en qüestió. En aquest cas els valors a mesurar no són tan elevats i tenen una capacitat de mesura de fins a 200 quilograms de pes(1 i 2 de la figura 2.8). Les cèlul·les 1 i 2 mesuren les forces anteroposteriors de la marxa humana, de forma que la cèl·lula 2 mesura la força de frenat en produir-se el contacte del peu amb el terra, i la 1 mesurarà la força de propulsió en retirar el peu de la plataforma.
Les dues últimes mesuren les forces mediolaterals, igual que les anteriors no mesuraran valors elevats i ,per tant, tenen una capacitat de mesura de fins a 200 quilograms de pes. Les cèl·lules numero 3 i 4 de la figura 2.8 són les que mesuren les forces mediolaterals de la marxa humana. Ara bé, aquestes cèl·lules treballen d’una forma més complexa que les anteriors, ja que, depenent amb quin peu estiguem treballant mesurarem la component medial o la lateral. Si treballem amb el peu dret la cèl·lula 4 estarà mesurant la component medial,la 3 la component lateral; de forma inversa, si treballem amb el peu esquerre, la cèl·lula 4 mesurarà la component lateral i la 3 la component medial.
13
La figura següent ens mostra la distribució de les 8 cèl·lules de càrrega sobre la plataforma de la cinta.
Fig. 2.8 Distribució de les 8 cèl·lules de càrrega
La cinta dinamomètrica subministrada per dur a terme el projecte consisteix en una plataforma on hi ha instal·lades les vuit cèl·lules de càrrega que ens ajudaran a mesurar les forces exercides pel pacient en caminar sobre la cinta i un convertidor que ens permetrà controlar la durada de les adquisicions i velocitats de la cinta. El convertidor de freqüència utilitzat per al control del motor és un SYSDRIVE 3G3MV-A4015 de l’empresa OMRON. La figura 2.9 mostra l’aparença d’una cinta dinamomètrica.
Fig. 2.9 Cinta dinamomètrica
14
2.4 Amplificadors d’ Instrumentació
Els amplificadors d’instrumentació són un tipus de circuits basats en amplificadors operacionals treballant en zona lineal amb baixa tensió d’offset. Té, com a característiques principals, una entrada diferencial amb una impedància d’entrada elevada i una impedància de sortida molt baixa. La sortida està referenciada a massa, un factor de rebuig CMRR elevat, de l’ordre dels 100 dB, i un “slew-rate” elevat.
Els amplificadors d’instrumentació s’utilitzen per amplificar amb precisió senyals de molt baix nivell en mode diferencial que provenen de transductors, com són les galgues extensiomètriques en pont de Wheatstone que s’apliquen a les cèl·lules de càrrega utilitzades. Això permet ser aplicat en un gran ventall d’aplicacions, en el nostre cas, per a l’adquisició de dades.
En el projecte actual tenim disposem de vuit amplificadors d’instrumentació, un per a cada cèl·lula de càrrega de la plataforma. El propòsit d’aquests és condicionar el senyal molt baix aportat per les cèl·lules, d’uns 36 mV a fons d’escala, a una tensió apropiada per a ser adquirida amb la targeta d’adquisició per obtenir una tensió d’entre 0 i 10 V a fons d’escala.
Fig 2.10 Amplificadors
En la imatge anterior podem veure la PCB que conté 4 amplificadors.
15
2.5 Targeta d’ Adquisició
Per tal de convertir les tensions obtingudes dels amplificadors operacionals a un format de dades adequat, utilitzem una targeta d’adquisició multifunció que conté un convertidor d’analògic a digital, que ens permet obtenir la tensió analògica en format binari, perquè pugui ser tractat posteriorment amb l’ordinador.
La targeta utilitzada és el model PCL 818L, que és una targeta d’adquisició de dades i control multifunció amb inserció al bus ISA per a IBM PC/XT/AT o compatibles, de la casa Advantech Industrial Automation. Podem veure la targeta comentada en la figura 2.11.
Fig 2.11 Tarja d’adquisició
El sistema de hardware extern es composa de vuit senyals analògics procedents de les cèl·lules de càrrega. Per tant, com es pot veure en les especificacions, tenim suficients canals per connectar els vuit senyals simples subministrats pels amplificadors d’instrumentació. Utilitzarem els vuit primers per facilitar les connexions dels senyals i facilitar la lectura per software de les conversions. Com que els senyals estaran compresos entre un rang de 0 a 10V necessitarem configurar la targeta perquè permeti un rang d’entrada de ±10V. Les diferents configuracions es realitzen a traves d’uns jumpers connectats a la targeta. El programa realitzat farà adquisicions amb una velocitat de mostreig de 100 a 1000 Hz, de manera que amb aquesta targeta ja en tenim suficient ja que permet una velocitat màxima de mostreig de fins a 40 kHz.
16
2.6 Programa Adquisició de Dades
Un dels punts importants del projecte és dissenyar un programa que ens permeti fer una adquisició d’un senyal analògic exterior i convertir-lo en dades binàries mitjançant un convertidor analògic digital integrat en una targeta d’adquisició i representar el senyal adquirit en una gràfica. La targeta estarà connectada al bus ISA, per tal de poder tractar les dades amb l’ordinador i obtenir uns resultats gràfics que puguin ser estudiats per un podòleg especialitzat.
En el present projecte es vol treballar amb el sistema operatiu Windows XP. Interessa treballar amb el windows XP degut a que si es treballa amb un Windows 98 hi han problemes amb els dispositius USB (al podòleg li interessa poder treure les dades del ordinador amb USB). Per tant, anem a veure unes idees del principal funcionament d’aquest.
El Window XP es un sistema operatiu gràfic multiprogramació i multitasca de 32-bits. Aquest utilitza un entorn anomenat GUI (Grafic User Interface o Interfície Gràfica d’Usuari) que permet una millor utilització de la pantalla i aporta una interacció amb l’usuari més agradable que no pas el sistema operatiu MS-DOS. Cada programa que s’està executant ocuparà una finestra, normalment una àrea rectangular de la pantalla, que contindrà una capçalera, on posarem el nom del programa, i un menú del sistema, que ens permet restaurar, maximitzar, minimitzar i tancar la finestra o programa. Tindrem una interfície amb l’usuari mitjançant controls com botons, finestres d’edició de text, menús, ... que permetran a l’usuari comunicar-se amb els programes mitjançant l’utilització del teclat i el ratolí.
Windows també suporta la multitasca. És a dir, permet que diversos programes es mostrin i s’executin al mateix temps. Aquesta propietat serà molt útil per realitzar el projecte ja que necessitem fer l’adquisició de dades i el control del motor de forma que treballin alhora.
El Windows ens permet dir-li al nostre programa que treballi amb més o menys prioritat, de manera que li podrem donar la màxima o mínima prioritat depenent del que volguem fer en aquell moment.
Una altra avantatge és l’execució multifilar (o multi-threaded applications) que ens permet dividir el nostre programa en fils d’execució perquè treballin concurrentment. Aquests fils d’execució solen realitzar tasques que no interactuen amb l’usuari, permeten així desfer-se del programa,o fil, principal d’algunes tasques i d’encarregar-se només de la interacció amb l’usuari. Els fils d’execució comparteixen la memòria de programa, així com les variables estàtiques globals amb el programa principal. Però cada fil té les seves variables locals, el seu propi “stack” de memòria i un estat de processador que serà guardat i recuperat mentre es fa l’elecció del fil a executar.
Al voler fer adquisicions d’entre 1 ms i 10 ms, necessiterem crear-nos un retard per cumplir els períodes d’adquisició, degut a què la resolució mínima del windows és superior a la desitjada (55 ms pel windows 98 i 10 ms pel windows Xp).
17
2.7 Programa Control Motor
El convertidor de freqüència utilitzat per al control del motor és un SYSDRIVE 3G3MV-A4015 de l’empresa OMRON. Suporta comunicacions RS-422 i RS-485 d’acord amb el protocol de comunicacions MODBUS, que facilita la construcció de xarxes utilitzant un PLC SYSMAC d’ OMRON.
Com ja s’ha comentat, nosaltres enviarem ordres al PLC i serà aquest el que controlarà al variador. Les ordres bàsiques a enviar són: unsigned char Msgn151[11] = 0x01,0x10,0x01,0x97,0x00,0x01,0x02,0x00,0x04,0xBF,0xA0; //Comunicacio Time-Over unsigned char Msgn154[11] = 0x01,0x10,0x01,0x9A,0x00,0x01,0x02,0x00,0x02,0x3E,0xBF; //Seleccio Velocitat comunicacions unsigned char Msgn155[11] = 0x01,0x10,0x01,0x9B,0x00,0x01,0x02,0x00,0x02,0x3F,0x6E; //Seleccio paritat unsigned char Msgn019[11] = 0x01,0x10,0x01,0x13,0x00,0x01,0x02,0x00,0x00,0x00,0x00; //Temps Acceleracio 1 unsigned char Msgn020[11] = 0x01,0x10,0x01,0x14,0x00,0x01,0x02,0x00,0x00,0x00,0x00; //Temps Deceleracio 1 unsigned char MsgRUN[11] = 0x01,0x10,0x00,0x01,0x00,0x01,0x02,0x00,0x01,0x66,0x41; //Engegar Motor unsigned char MsgSTOP[11] = 0x01,0x10,0x00,0x01,0x00,0x01,0x02,0x00,0x00,0xA7,0x81; //Parar Motor unsigned char MsgFREQ[11] = 0x01,0x10,0x00,0x02,0x00,0x01,0x02,0x00,0xC8,0xA6,0x24; //Actualitzar Freqüència
La comunicació sempre l’inicia el mestre (ordinador). Envia unes dades (missatge de comandes) a un esclau amb una seqüència predeterminada. Un cop rebut, l’esclau el descodifica, el processa i retorna un missatge de resposta al mestre.
Un aspecte important per realitzar les comunicacions és respectar una sèrie d’intervals de temps establerts pel fabricant.
Els missatges de comunicació estan compostos totalment per dades hexadecimals. Cada missatge o resposta es divideix en blocs de 8 bits o d’un byte. Per tant, les dades s’hauran de seleccionar en blocs de 8 bits per comunicacions.
Fig 2.12 Motor
18
3 Disseny Programa Adquisició (Estàtica) El propòsit del programa d’adquisició de dades és la de poder avaluar els esforços amb la cinta parada i la de capturar de les dades en format digital provinents de l’exterior i, el seu posterior tractament i visualització gràfica en l’entorn de Windows. Per fer l’adquisició necessitem tenir un control absolut sobre la targeta ja que es pretén realitzar una adquisició de “n” canals cada període de temps finit. Un altre aspecte important, és dur a terme la realització d’una temporització per al període de mostreig que volem utilitzar. Al voler fer adquisicions de entre 1 ms i 10 ms, necessiterem crear-nos un retard per cumplir els períodes d’adquisició, degut a què el timer del Windows no ens serveix. Primerament, es fa el disseny de la interfície gràfica que utilitzarem per comunicar el programa amb l’usuari. Aquesta interfície serà la utilitzada cada cop que obrim el programa i tindrà el mínim de variables possibles per simplificar al màxim la interfície i no haver de ser un expert en temes de conversió o de tractament de senyal.
3.1 Disseny de la Interfície Gràfica
Aquest programa es va realitzar a petició del centre pogològic, per tal de poder fer adquisicions amb la cinta parada. A més a més, va voler incorporar al programa la distribució dels sensors de la cinta per tal de veure exactament la seva posició i com anaven canviant de valor segons a on es col·locava un pes en un lloc determinat de la cinta. Un altre detall que va demanar és el de poder veure el pes de la persona que estigui damunt la cinta. En la següent figura podem observar la interfície gràfica dissenyada.
Fig 3.1 Interfície Gràfica
19
En la figura anterior podem observar dos parts diferenciades separades per la línia horitzontal. En la part inferior esquerre tindríem la cinta amb els sensors situats en la seva posició corresponent i al centre de la mateixa de color groc tindríem el pes. En aquesta part de programa també es permet canviar el període de mostreig i els rangs dels canals.
En la part superior del programa tindríem tot el que seria adquisició, tractament i visualització de les dades. El primer punt podem visualitzar el nom del dispositiu connectat (tarja d’adquisició). El segon punt, seria el de l’adquisició, on ens demanarà el nom del fitxer on guardarem les dades, la freqüència de mostreig i el temps durant el que es vol mostrejar. Llavors es calculen les constants de temps per trobar el valor de la variable de retard i, es comença a fer l’adquisició.
Un cop tenim les dades adquirides passaríem al tercer punt corresponent al tractament de les dades adquirides. En clicar aquest botó s’obre la següent interfície.
Fig 3.2 Diàleg Estadística (filtre passa baixos)
Permet realitzar un filtrat passa baixos de les dades (realitza una mitjà del número de mostres que li diem), si fos necessari, i passar-les a kg. Per passar-les a kg multiplicarem les dades per un escalar que ens fa la conversió de la tensió en kg. Aquest escalar tindrà un valor de 50 per a les cèl·lules de 500 kg i de 20 per a les de 200 kg. El diàleg està format per un control d’edició, que permet escollir l’ample del filtre. Si l’ample té un valor d’1, serà el mínim valor possible, les dades només es passaran a kg i, no s’aplicarà cap filtratge. Dos botons ràpids que permeten cridar un diàleg per obrir fitxers i obrir el fitxer font del qual es vol fer el filtratge i el fitxer destí on es guardaran les noves dades. Com a últim pas tenim el botó “gràfica” que ens permet fer la representació de les dades adquirides.
20
3.2 Disseny del Control del Sistema Operatiu
El principal problema que tenim és que en l’entorn del sistema operatiu Windows no és possible obtenir el control absolut de l’ordinador, a diferència del sistema operatiu MS-DOS, degut a què permet una simultaneïtat de programes treballant alhora i, per tant, necessita tenir un control dels programes que estan treballant per poder fer una planificació de les execucions i que no es produeixin colls d’ampolla o, que el sistema operatiu es quedi col·lapsat. Llavors tenim un problema greu, degut a què l’adquisició ha de mantenir una temporització constant i no es pot perdre cap dada, sinó podríem estar observant dades no reals.
Una de les propietats del Windows és treballar en multiprogramació, és a dir, executant múltiples programes alhora. Cada programa té el seu espai de memòria que serà executat com un thread. Aquests programes poden estar dividits en múltiples tasques independents, això s’anomena multithreaded-applications. Aquesta propietat ens permet que un programa es divideixi en diverses tasques, de manera que aquestes tasques estan destinades a esperar respostes d’elements hardware lents i no interferir en l’execució del programa principal. Per fer això, cada thread té el seu espai de memòria, amb els seus registre de CPU i el seu propi “stack”. Un programa tindrà com a mínim un thread que estarà executant codi de l’espai de memòria de procés. Per tots els threads creats la CPU els assigna temps d’execució, de manera que sembla que tots els threads s’executin de forma concurrent en una planificació del tipus round-robin (es van executant els threads de forma equitativa i en un ordre racional).
Un diagrama simple seria tenir un fil principal, o programa, i subdividir-lo en diferents fils que realitzen tasques lentes que han d’esperar resposta d’un element lent.
Fig 3.3 Diagrama multithread. Fig 3.4 Diagrama programa principal threads.
Programa Principal
Thread 1 Thread 2 Thread N.
21
El Windows ens permet donar al nostre fil un ordre de prioritat sobre la resta de programes o fils. Aquests ordres ens permetran dir-li al nostre fil que s’executi de forma més prioritària o menys prioritària segons la feina que hagi de dur a terme. En aquest cas necessitarem que el thread s’executi amb la màxima prioritat (per asegurar-nos d’adquirir correctament), de forma que obtingui el màxim control del sistema i la mínima intervenció del Windows, si pot ser una intervenció nul·la, millor.
Cada thread que s’executa té una prioritat que va des de 0 (mínima prioritat) fins a 31 (màxima prioritat ). Quan el sistema decideix quin fil és el següent a efectuar-se, comença per els de més prioritat donant-li la màxima temporització, de manera que no s’executarà un d’ordre menys prioritat fins que el més prioritari s’hagi acabat o no en quedi cap de màxima prioritat, en el cas que hi hagués més d’un. En aquest cas estarem ocupant la CPU per complet i ens trobarem en una situació anomenada starvation, o passar gana.
El Windows permet sis ordres de prioritat per a les aplicacions, temps-real, alta, per sobre del normal, normal, per sota del normal i baixa. La prioritat baixa es la més baixa de totes i només s’utilitza per tasques que s’executen quan el sistema, o més ben dit la CPU, no esta fent res. La normal és la més comuna i la que utilitza el 99 % de les aplicacions. La que ens interessa és la prioritat de temps real, aquesta ens permet un control absolut de manera que el sistema sembla que s’hagi penjat. Aquesta prioritat s’utilitza per execucions que necessiten una latència curta del hardware o per realitzar tasques curtes reals que no poden ser interrompudes. Els threads també permeten un ordre de prioritat, de manera que el Windows permet set ordres de prioritat per als threads, molt baixa, baixa, per sota del normal, normal, per sobre del normal, alta i de temps crític. Aquestes prioritats són relatives a la prioritat del programa, de tal manera que un thread amb prioritat normal en un programa amb prioritat normal tindràn un nivell 8 de prioritat.
La classe de prioritat per a un programa és un concepte abstracte creat per Microsoft per tal d’aïllar-te dels treballs interns del controlador de tasques, no té un altre propòsit. La prioritat important és la que rep el thread en qüestió, de forma que si un fil d’execució té la màxima prioritat, aquest no serà posat a cua, sinó que rebrà el control de la CPU immediatament.
Per assignar la classe de prioritat del programa utilitzarem la funció SetPriorityClass ( ) amb la declaració següent:
BOOL SetPriorityClass( HANDLE hProcess, DWORD fdwPriority );
Els valors de la variable fdwPriority són:
REALTIME_PRIORITY_CLASS. HIGH_PRIORITY_CLASS. AVOBE_NORMAL_PRIORITY_CLASS. NORMAL_PRIORITY_CLASS. BELOW_NORMAL_PRIORITY_CLASS. IDLE_PRIORITY_CLASS.
22
Per crear el thread primer creem un objecte de la classe TThread de la següent forma:
class ThreadConversio : public TThread private: protected: void __fastcall Execute(); public: __fastcall ThreadConversio(bool CreateSuspended); ;
La inicialització de la prioritat es farà en la funció constructora, de manera que crearem el thread en suspensió, li assignarem la prioritat i l’activarem.
__fastcall ThreadConversio::ThreadConversio(bool CreateSuspended) : TThread(CreateSuspended) Priority = tpTimeCritical; //Activem la màxima prioritat per al thred. Resume( ); //Activem el thread
Els valors per la variable Priority són:
tpTimeCritical; //prioritat màxima tpHighest; tpHigher; tpNormal; tpLower; tpLowest; tpIdle;
El codi del thread anirà junt amb la funció Execute( ).
void __fastcall ThreadConversio::Execute( ) while(!Terminated) //---- Col·loca el codi del thread aqui ---- . . .
23
3.3 Disseny del Bucle de Temporització
La següent característica a complir seria la temporització. El Windows utilitza el rellotge del sistema integrat en el hardware del PC i en la ROM BIOS. Aquest rellotge genera una interrupció cada 55 ms aproximadament, o 18 tics per segon. El Windows utilitza els tics generats per aquest rellotge per crear diversos timers, com per exemple el rellotge mostrat a l’escriptori, o un rellotge per al propi programa. Per tant, no serà el mateix programa el que rebi el senyal del tic, sinó que serà prèviament processat pel sistema operatiu. Els timers generats pel Windows són uns comptadors descendents, de tal manera que quan s’acaba el comptatge s’envia un missatge WM_TIMER a la cua de missatges de l’aplicació i es torna a carregar el comptador amb el valor original. Aquest comptador és un sencer sense signe, de manera que permet fer interrupcions, en teoria, des d’1 ms fins a 4 294 967 295 ms. El Windows 98 té una resolució de 55 ms. En canvi, el Windows NT, té una resolució de 10ms aproximadament, ja que incorpora un rellotge intern més potent que no pas el hardware més antic. Degut a aquests paràmetres no podem realitzar timers amb valors de temps inferiors als 10 ms o inferiors als 55 ms. En el sistema operatiu MS-DOS se’ns permet utilitzar, i s’ha d’utilitzar si vols fer una temporització, la interrupció directament, de manera que podem canviar el seu valor i permetre interrupcions en períodes de temps més curts, de l’ordre de µs. En el Windows aquesta propietat no és aplicable, ja que els tics generats per aquest rellotge són manegats per el sistema operatiu, i això ens limita a que hi ha altres aplicacions que segurament estan utilitzant timers, i la modificació d’aquest valor podria afectar a les aplicacions.
El problema està en què volem realitzar mostrejos a una freqüència de 100Hz fins 1000Hz. Això representa que volem adquirir dades cada 10 ms fins a 1ms com a màxim. Per al cas de 100Hz podríem arribar a utilitzar el timer del sistema operatiu si treballem amb Windows NT, 2000 o XP, i un “hardware” relativament nou, que si que permeten aquesta temporització. El problema està en què volem un rang més ampli que aquest sistema no ens el proporciona. Un altre problema relacionat amb aquests timers de sistema es que envien un missatge a la cua de missatges de l’aplicació relativa, de manera que si el programa esta ocupat no rebrà a temps el senyal de WM_TIMER i ens crea una indeterminació de temps que no interessa, a més es produirien pèrdues en l’adquisició. Per tant, la idea queda descartada.
Per solucionar-ho farem una temporització realitzant un bucle de retard. Això consisteix en realitzar un bucle de repetició. Aquest bucle executarà unes instruccions de duració coneguda i es repetirà “n” vegades depenent de la temporització necessitada. El número de repeticions vindrà determinat per la duració temporal de les instruccions executades. En Windows sorgeix el problema de la indeterminació temporal a l’hora d’executar instruccions, ja que aquest realitzarà tasques més importants en determinats moments. Si l’execució dels threads a màxima prioritat ens permeten aconseguir un control pràcticament absolut del sistema podrem realitzar el rellotge d’aquesta forma.
24
Un altre problema serà mesurar el temps que triguen a efectuar-se les operacions dins el bucle de retard. Per fer aquesta mesura realitzarem un bucle que executi moltes vegades les instruccions, llegint el valor del rellotge a l’inici i al final de l’execució, de manera que es pugui veure quina duració té la instrucció. Necessitem executar moltes vegades el bucle per poder apreciar un canvi en el tic del rellotge. Per exemple, si l’execució de les instruccions és 1 µs no podem executar-la un cop i veure un canvi en el rellotge, ja que aquest només s’actualitza cada 55 ms. Per tant, hauríem d’executar el bucle un mínim de 55 000 vegades per veure el mínim canvi en el rellotge.
Volem una freqüència màxima de mostreig d’1kHz. Llavors seria interessant fer un bucle de retard amb un error vàlid per la nostra aplicació, és a dir, executar el mínim d’instruccions per obtenir un valor d’execució del bucle de l’ordre de µs o ns. Això ens permetrà una execució del bucle de retard més elevada i cometre així un error de temps més petit. Per què ? Degut a que la instrucció no s’executarà sempre durant el mateix temps, com més cops l’executem, menys error cometrem, ja que hi haurà un valor de repetició més elevat.
Primer de tot, farem el càlcul o la mesura del temps que durarà l’execució de la instrucció en qüestió. Realitzarem l’execució d’un bucle for( ; ; ) per a tal efecte. A més a més, abans i després del bucle mirarem el valor del rellotge del sistema utilitzant les rutines de les biblioteques de C. El codi representatiu serà:
Inici = clock( ); for( ; i<n_vegades; i++ ) Executar_instrucció; Fi = clock ( );
Un cop realitzat això obtindrem el valor del temps mesurat fent el següent càlcul:
Temps_execució = ( fi – inici ) / ( n_vegades * tikcs_segon );
Aquesta equació ens donarà el temps que triga la instrucció en efectuar-se en funció dels paràmetres del rellotge llegits, el nombre de vegades que s’ha executat la instrucció i el nombre de vegades per segon que es produeix una actualització del valor del rellotge del sistema (ticks_segon).
25
S’ha de recordar que interessa que el valor n_vegades sigui elevat per obtenir una mesura òptima i fiable. Llavors, si volem saber quin retard volem aplicar al nostre bucle farem:
Retard = temps_període / temps_execució;
On el temps de període serà el període de mostreig que es vol i, temps d’execució, el temps d’execució de la instrucció mesurat anteriorment. Aquesta equació estaria incompleta ja que necessitarem restar-li al temps de període el temps que tarda en efectuar-se l’adquisició dels vuit canals alhora. Com que son períodes de temps relativament petits ens veurem afectats pel temps que triga en efectuar-se l’adquisició dels vuit canals i per tant necessitarem aplicar aquest retard en algun lloc. Per calcular el temps que triga l’adquisició fem servir el mateix mètode que abans. Es a dir, executar n vegades l’adquisició amb un bucle i mesurarem el temps amb el rellotge del sistema. El codi seria el següent:
Inici = clock( ); for( ; i<n_vegades; i++ ) Executar_adqusició; Fi = clock ( );
El valor del temps es calcularà amb l’equació:
Temps_adquisició = ( fi – inici ) / ( n_vegades * tikcs_segon );
I llavors el càlcul del retard es farà amb la modificació de l’expressió anterior per calcular el retard, quedant la següent equació:
Retard = ( temps_periode – temps_adquisicio ) / temps_execucio ;
Suposarem que el temps d’adquisició és menor que el temps de període. En cas contrari no podríem fer una adquisició a aquesta velocitat ja que no estaria permès per la targeta. Per tant, s’hauran de tractar els límits per no cometre errors.
26
3.4 Disseny Utilització de la Targeta
La targeta d’adquisició permet fer una programació a nivell de registres, o bé proporciona unes biblioteques dinàmiques per poder utilitzar-la. En aquest cas, es faran servir les biblioteques o arxius .dll. Advantech proporciona un arxiu anomenat ADSAPI32.DLL, que té utilitat amb totes les targetes d’aquesta marca. El fet d’utilitzar les dll amplien les característiques de les aplicacions, ja que no ens hem de preocupar tant del funcionament del hardware i et pots concentrar més en generar una interfície més còmode per realitzar operacions amb la targeta. Aporten un major aprofitament de la memòria. Aquestes es carreguen a memòria del procés dinàmicament. D’aquesta manera l’aplicació determina en temps d’execució quines funcions utilitza i llavors carrega les funcions per executar-les. Com que es troben paginades a memòria RAM una vegada, aquesta permet ser compartida per altres aplicacions alhora. Per al programa utilitzarem l’API proporcionada per Advantech. Aquesta API conté totes les funcions que estan a l’arxiu ADSAPI32.DLL.
Per poder utilitzar l’API corresponent necessitem carregar primer l’arxiu .lib al nostre projecte per així tenir les declaracions de les funcions. Aquest arxiu pot estar adjunt amb la dll o bé es pot generar mitjançant la comanda del dos següent:
IMPLIB [options] libname[.lib] dllname[.dll]
Permet passar la dll a una biblioteca d’importació .lib., on libname serà l’arxiu lib destí i dllname serà l’arxiu dll font.
A més a més, de les funcions proporcionades per utilitzar la targeta també hi ha una sèrie d’estructures que ens serviran per passar els paràmetres a les funcions. El sistema de drivers ens permet comunicar-nos amb la targeta utilitzant les següents API:
Funcions de dispositiu: ens permet obrir, tancar el dispositiu, adquirir les seves característiques o el nombre de dispositius connectats al PC.
Entrada analògica: funcions per activar i llegir les dades adquirides amb el convertidor
analògic digital.
Sortida analògica: funcions per controlar el convertidor D/A.
E/S digitals: funcions per al control de les entrades i sortides digitals.
27
Nosaltres ens fixarem en les funcions de dispositiu i les d’entrada analògica. Les funcions són:
Funcions de dispositiu:
DRV_DeviceGetNumOfList(NumOfDevices); Obté el nombre de dispositius instal·lats.
DRV_DeviceGetList(DeviceList, MaxEntries, OutEntries); Obté una llista dels dispositius instal·lats.
DRV_DeviceGetFeatures(DriverHandle, lpDEvFeatures); Obté les característiques d’una targeta i les guarda en un buffer.
DRV_DeviceOpen(DeviceNum, DriverHandle); Obté els parametres de funcionament del dispositiu des del registre o el fitxer de configuració, i assigna memòria per un ràpid accés.
DRV_DeviceClose(DriverHandle); Allibera la memòria assignada en la funció d’obrir el dispositiu.
Entrada analògica:
DRV_AIConfig(DriverHandle, lpAIConfig); Configura el guany per al canal especificat.
DRV_AIVoltageIn(DriverHandle, lpAIVoltageIn); Obté el valor de la conversió en volts per a un únic canal.
DRV_MAIConfig(DriverHandle, lpMAIConfig);
Configura el guany per diversos canals.
DRV_MAIVoltageIn(DriverHandle, lpMAIVoltageIn); Obté el valor de la conversió en volts de múltiples canals.
28
Per programar i utilitzar la targeta seguim el següent diagrama de flux:
Programar i Utilitzar la Targeta
Fig 3.5 Diagrama de flux programació i utilització de la targeta.
En el primer bloc realitzarem la comprovació de que existeix alguna targeta connectada a l’ordinador. Això ho farem amb la funció del driver DRV_DeviceGetNumOfList( ). Aquesta funció se li passa per referència un sencer curt que contindrà el nombre de dispositius connectats. Un cop sabem que hi ha dispositius instal·lats obtenim una llista dels diferents dispositius amb la funció DRV_DeviceGetList( ). A aquesta funció se li passa per referència l’estructura DEVLIST que contindrà el número de dispositiu, el nom del dispositiu i si té dispositius esclau connectats. El codi quedaria:
DEVLIST DevceList[NumDispositiusAcceptats]; . . . if ( (DRV_DeviceGetNumOfList( NumDevices ))==SUCCES) if(NumDevices != 0) DRV_GetDevList(&DeviceList[0], NumDevices, &OutEntries); . . .
Inici
AlgunaTargeta Instal·lada?
Obtenir Característiques
No
Si
Realitzar Adquisició
Sortir
Configurar Targeta
29
Ara ja tenim el número de dispositius connectats i el nom de cada dispositiu. Al següent bloc adquirirem les característiques de la targeta que volem utilitzar, en cas que n’hi hagués més d’una. Pel que fa al nostre projecte només n’utilitzarem una. Per obtenir les característiques utilitzem la funció DRV_DeviceGetFeatures(DriverHandle, lpDevFetures). Haurem d’inicialitzar una estructura de tipus DEVFEATURES. Aquesta estructura contindrà un identificador de targeta, el màxim nombre de canals d’entrada analògics, el màxim nombre de canals de sortida analògica, entrades i sortides digitals ... A nosaltres ens interessa un paràmetre anomenat usNumGain que indica el nombre de guanys que es poden programar, i una estructura, GAINLIST, que conté el codi del guany i el nom. És a dir, si tenim dos guanys, ±5V i ±10 V, usNumGain valdrà 2 i l’estructura GAINLIST proporciona el codi del guany per poder fer la configuració posterior. El nom, simplement, és una cadena de caràcters acabada amb el caràcter nul, que ens permet mostrar-la per pantalla amb un control ComboBox, per exemple. Abans de poder utilitzar aquesta funció s’ha d’obrir el dispositiu per tal d’assignar la memòria.
DEVFEATURES lpDevFeatures; . . . if((DRV_DeviceOpen(&DriverHandle))==SUCCES) if((DRV_DeviceGetFeatures( DriverHandle, lpDevFeatures))
==SUCCESS) Mostrar_valors_de_guany( ); . . .
El següent pas és configurar la targeta perquè treballi com ens interessa. La tensió rebuda dels amplificadors serà com a màxim de 10 V, per tant, s’haurà de configurar la targeta perquè treballi entre ±10V. Aquesta configuració aporta un guany unitari, de manera que el nostre senyal no es veu afectat pel guany. També necessitem configurar els vuit canals com a entrades simples, això es realitza per hardware amb els jumpers de la targeta. L’API proporcionada per Advantech compta amb una funció que permet realitzar la programació dels guanys per als vuit canals alhora. Aquesta funció realitza una escriptura a la memòria SRAM integrada en la targeta que serveix per mantenir els valors de configuració de guany per a cada canal. Per tant, cada cop que vulguem fer una adquisició de nou es convenient fer la configuració ja que quan apaguem l’ordinador s’esborrarà el contingut de la memòria.
30
Utilitzarem l’estructura PT_MAICONFIG, que conté el número de canals, el canal inicial i un punter a taula amb els valors del guany, per passar-li els valors a la funció.
PT_MAICONFIG lpMAIConfig; . . . lpMAIConfig.NumChan = 8; lpMAIConfig.StartChan = 0; lpMAIConfig.GainArray = (USHORT far)&GainCode[ 0 ]; if((DRV_MAIConfig( DriverHandle, (LPT_MAICONFIG)&lpMAIConfig ) )!= SUCCESS) Error ( ); . . .
Per últim, es farà l’adquisició. Per fer l’adquisició utilitzarem el diagrama de flux d’adquisició. Primer de tot s’hauria d’haver fet el càlcul de les constants de temps i del valor de la variable retard. Ens interessa adquirir els vuit canals alhora. Evidentment no es pot perquè només hi ha un convertidor. El driver proporciona una funció, de la mateixa manera que l’anterior, que ens permet fer l’adquisició de vuit canals alhora i retorna el valor en volts. Per aquesta funció utilitzarem l’estructura PT_MAIVoltageIn, que contindrà el número de canals a convertir, el canal inicial, un punter a taula de sencers amb el codi de guany, el mode de dispar, en el nostre cas per software, i un punter a una taula de reals per als valors adquirits i convertits.
PT_MAIVoltageIn lpMAIVolatgeIn; . . . lpMAIVoltageIn.NumChan = 8; lpMAIVoltageIn.StartChan = 0; lpMAIVoltageIn.GainArray = (USHORT far)&CodiGuany[ 0 ]; lpMAIVoltageIn.TrigMode = 0; //Dispar per software. lpMAIVoltageIn.VoltageArray = (float far)&Voltate[ 0 ]; if((DRV_MAIVoltageIn( DriverHandle, (LPT_MAIVoltageIn) &lpMAIVoltageIn)!=SUCCESS) Error( ); . . .
31
3.5 Disseny dels Fitxers de Sortida
Les dades adquirides s’aniran guardant en un fitxer amb el nom introduït per l’usuari. A aquest fitxer li assignarem l’extensió .adq (exemple: Pacient x.adq). Representa una adquisició feta. Cada cop que es realitza el bloc d’adquisició, immediatament després es realitza l’actualització del fitxer, introduint una línia amb els valors obtinguts dels vuit canals convertits i escalats a un valor de tensió. El format del fitxer consisteix en una primera línia on s’escriu el temps de mostreig que tindrà el format següent:
Només s’introdueixen els valors de les adquisicions. Aquests valors són reals, per tant, estaran separats per punt decimal. A continuació d’aquest afegirem dues xifres significatives, de manera que ja en tenim suficient per la precisió que aporta el convertidor.
3.45 2.01 1.25 2.12 1.78 1.67 0.98 0.67
. . .
Totes les separacions estan fetes per tabuladors, i els finals de línia per retorn de carro. De manera que es pot accedir al fitxer senzillament sense trencar-se el cap en com estan organitzades les dades. Si volguéssim protegir les dades hauríem de complicar-ho més, o en tot cas arribar a xifrar les dades. Però en aquest cas no es necessari.
Per obrir, tancar, llegir i escriure els fitxers utilitzaré les rutines de les biblioteques de C per aquest propòsit. Primer de tot, i ja que el Windows ens ho permet, obrirem un diàleg, on l’usuari introduirà el nom del fitxer. Aquest es guardarà en una carpeta creada pel programa al directori principal del disc dur, i tindrà el nom d’‘EstudisMEC’. El diàleg és el típic diàleg de Windows per obrir, guardar fitxers i que et permet l’exploració de les carpetes per poder guardar o obrir el fitxer on vulguis. Aquest diàleg et retorna el nom del fitxer introduït. Un cop tenim el nom el separem per parts i obtenim només el nom sense extensió. La funció fnsplit( ) permet realitzar aquesta operació fàcilment.
char szFileName[n]; . . . if(DialegCrear->Execute( )) // executem el diàleg i si s’ha
introduït un nom i s’ha pres la tecla Acceptar. Fnsplit( DialegCrear->FileName, 0,0,szFileName,0); //obtenim el nom
sol sense extensió . . .
A continuació li afegim l’extensió que nosaltres vulguem. La funció strcat( ) ens permet concatenar frases.
. . .
32
Strcat(szFileName,”.adq”); //li apliquem l’extensió. . . .
El diàleg es el típic de Windows:
Fig 3.6 Diàleg per crear el fitxer a on es guardaran les dades.
Per últim obrim el fitxer, hi escrivim i el tanquem. Per fer això utilitzem les rutines de C com fopen( ), li associa un stream al fitxer obert i retorna un punter al fitxer per identificar el stream posteriorment. fprintf( ), que escriu al fitxer amb format especificat. fclose( ), tanca el fitxer obert i allibera l’stream netejant tots els buffers associats a aquest.
FILE *fp; //creem una variable punter a fitxer. . . . fp = fopen(szFileName, “w”); //Obrim el fitxer per escriure. . . . fprintf(fp, “%.2f\t”, Voltatge[ i ]); //escrivim al fitxer . . . fclose(fp); //tanquem el fitxer
El diàleg estadística generarà un altre tipus de fitxer amb format. Aquests fitxers posseiran l’extensió .est. Rebran l’extensió alhora d’obrir el fitxer quan utilitzem el diàleg per al fitxer de sortida. Posseirà l’estructura següent. En aquest cas hi haurà 9 columnes. Una per als valors temporals en ms, i les altres vuit corresponents als vuit canals filtrats i convertits
Capçalera
Directori creat pel
programa
Acceptació de
l’execució
Nom del fitxer
Extensió pròpia
33
a kg. La primera línia serà text que indica a que corresponent cada columna. Les dades estaran separades per tabuladors.
temps canal1 canal2 canal3 canal4 canal5 canal6 canal7 canal8
. . .
I seguit dels valor convertits.
. . .
1 3.25 2.34 1.54 2.45 1.29 0.98 0.67 1.08 1.02
. . .
3.6 Disseny del Filtre
El filtre aplicat és un tipus de filtre passa baixos. Consisteix en què si tenim un vector de “n” valors recalculem un nou vector fent la mitja del número de mostres indicat per l’usuari.
V[ v0, v1,v2, . . .vn ];
Podem filtrar el senyal, o suavitzar-lo, realitzant la suma de “m” termes i dividint-los per “m”. Tot això per a cada valor del vector. És a dir, aplicar la mitja de “m” termes per a cada terme del vector. El nou vector seria:
Vnou [ 0~V , 1
~V , 2~V ,. . ., iV~ ];
A on iV~ és la mitja de “m” termes.
34
3.7 Disseny del Codi representació gràfica Per tal de poder visualitzar les dades adquirides utilitzarem la llibreria engine de Matlab (libeng.lib), que ens permetrà representar les gràfiques des de Borland amb el Matlab. El principal avantatge que tenim utilitzant aquest sistema és que sense necessitat d’haver d’obrir el matlab podem beneficiar-nos de les seves representacions gràfiques. Aquesta eina serà de gran utilitat pel podòleg degut a què pot fer augments en zones del gràfic, pot imprimir les gràfiques, les pot guardar i totes les avantatges que et proporciona el Matlab. El principal inconvenient de representar en Matlab és que si tenim molts punts processa més lentament. El codi de programa per a realitzar la representació gràfica seria: char comando[120]; //vector on carregaré l’instrucció a executar pel Matlab int i; Engine *ep; OpenDialog->Execute(); //obro el dialeg de fitxer per seleccionar el fitxer a dibuixar llegir(OpenDialog->FileName.c_str()); //llegeixo les dades del fitxer, guardo els temps i les forces en vectors //Start the MATLAB engine if (!(ep = engOpen(NULL))) // error si no es pot obrir Matlab MessageBox ((HWND)NULL, (LPSTR)"Can't start MATLAB engine", (LPSTR) "Engwindemo.c", MB_OK); exit(-1); sprintf(comando,"hold on;"); //carrego instrucció a executar engEvalString(ep,comando); //executo instrucció. engEvalString(ep, "title('Esforços al caminar');"); //executo instrucció. engEvalString(ep, "xlabel('Temps (ms)');"); //executo instrucció. engEvalString(ep, "ylabel('Forces verticals (Kg)');"); //executo instrucció. //Plot the result for(i=1;i<Nmostres;i++) sprintf(comando,"plot([%.2f,%.2f],[%.2f,%.2f]);",Temps[i-1],Temps[i],Fverticals[i-1],Fverticals[i]); engEvalString(ep,comando); // Drawing the line OpenDialog->FileName=""; //deixo en blanc el nom per defecte del fitxer
35
3.8 Disseny de l’aplicació
En aquest apartat es presenten els diagrames de flux creats per seguir una estructura a l’hora de realitzar el programa. A l’iniciar la nostra aplicació ens trobarem al programa o menú principal. Els programes de Windows treballen amb events, en el nostre cas l’event es produirà quan l’usuari premi un botó. Cada programa té el seu bucle de missatges, on cada missatge enviat al nostre programa correspondrà a un event, ja pot ser havent clicat un botó o escrit alguna cosa en un control d’edició.
Programa Principal
Fig 3.7 Diagrama Flux Programa Principal
Un cop rebem un missatge tractem aquest. Cada event rebut al nostre programa es podrà tractar per què aquest realitzi les operacions necessàries. Els principals missatges que podem rebre al nostre programa seran els relacionats amb els botons, els controls d’edició i els ítems del menú principal. En la figura 3.8 veiem els possibles events que explicarem als següents apartats d’aquest tema.
Tractament de Missatges
Fig 3.8 Diagrama de Tractament de Missatges
Inici
Adquisició? Parar? Fitxers Est? Gràfica?
Adquirir Dades Parar Adquisició Obrir Diàleg Obrir Diàleg
Si Si Si Si
Inici
Mostra valors
Hi ha Missatges?
Tractar Missatge
No
Si
36
Un dels missatges més important a tractar és el d’adquisició. Un cop rebut aquest el programa demanarà les dades necessàries i començarà el procés d’adquisició de les dades. Obrirà un thread que s’executarà en paral·lel amb el programa i amb màxima prioritat.
Primer de tot obrirem un fitxer on es guardaran les dades que s’han obtingut de l’adquisició. Aquest fitxer tindrà l’extensió *.adq, referent a l’adquisició. Les dades s’escriuran en format real al fitxer.
Un cop obert calcularem les constants de temps per tal d’executar el retard correctament. El càlcul de la constant de temps estarà relacionat amb l’adquisició i una funció que realitzarà en el bucle de retard (el retard depèn bàsicament de NumChans, SampleRate).
Finalment, quan ja tenim un lloc on guardar les dades i les constants de temps calculades activem el thread d’adquisició.
Adquisició
Fig 3.9 Diagrama pel Missatge Adquisició
Inici
Obrir Fitxer
Fitxer Creat?
Calcular Cnst. Temps
No
Si
Constants Correctes?
Thread Adquirir
No
Si
Programa Principal
37
El diagrama a seguir pel Thread adquirir consisteix en realitzar una adquisició dels 8 canals a convertir i seguidament realitzar el bucle de retard, per així fer una adquisició a cada període de temps estimat.
Thread Adquirir
Fig 3.10 Diagrama pel Thread Adquirir
El següent diagrama representa el diàleg que s’obre quan rebem el missatge “estadística”. L’aspecte d’aquest menú ja s’ha vist en la figura 3.2 i ens servirà per passar les dades a Kg i aplicar un filtre si és desitja.
Diàleg Estadística
Fig 3.11 Diagrama Diàleg Estadística
El tractament dels missatges serà igual que en el programa principal però en aquest cas pels controls del diàleg.
Inici
Adquirir 8 Canals
Adquisició Acabada?
Bucle de Retard
No
SiFi
Inici
Bucle de Missatges
Hi ha Missatges?
Tractar Missatge
No
Si
38
Tractament Missatges Diàleg Estadistica
Fig 3.12 Diagrama Tractament Dades Diàleg
La part de convertir dades es pot dividir per formar un diagrama de flux. Primer es farà la lectura del fitxer d’entrada introduït *.adq, seguidament filtrarem les dades segons el valor introduït a número de mostres i per últim es crearà el fitxer amb les dades convertides.
Convertir Dades
Fig 3.13 Diagrama per Convertir Dades
Inici
Llegir Fitxer *.adq
Fitxer Llegit?
Filtrar Dades
No
Si
Dades Filtrades?
Generar Fitxer de Sortida *.est
No
Si
Diàleg
Inici
Realitzar Estadística? Sortir? . . .?
Convertir Dades Sortir del Diàleg Obrir Fitxer
Si Si Si
39
El diagrama de flux pel que fa a la representació gràfica de les dades adquirides serà:
Diàleg Gràfica
Fig 3.14 Diagrama Diàleg gràfica
Diagrama de flux si executem el botó de representar la gràfica.
Missatge Gràfica
Fig 3.15 Diagrama dibuixar dades
Inici
Llegir Fitxer *.EST
Fitxer Llegit?
Representar Dades
No
Si
Diàleg
Inici
Bucle de Missatges
Hi ha Missatges?
Tractar Missatge G.
No
Si
40
4 Disseny Programa MEC (Dinàmica)
Aquest és el programa que servirà per veure els esforços d’una persona al caminar i al córrer. Per a realitzar aquest programa agafarem parts del programa fet en l’anterior projecte, com el tema de la comunicació amb el variador. Tot el tema del retard, la representació gràfica i els threads en aquest tema no s’explica degut a que és el mateix que l’utilitzat en el programa en estàtica.
4.1 Disseny de la Interfície Gràfica
En la següent imatge es pot observar la interfície gràfica pel programa MEC (Monitorització Esforços al Caminar). A la part superior esquerra tenim els botons de connectar i desconnectar-nos amb el PLC. Tenim un altre punt al menú superior que es diu protocol que ens servirà per a dir les característiques (velocitat màxima, temps d’acceleració, temps de desacceleració, duració...) de l’adquisició. L’evolució de la velocitat del motor en el temps s’observa en la pantalla negra de la imatge. Un cop connectats amb el variador i tenint el protocol creat passaríem a la tercera fase corresponent a la part superior dreta de la imatge on tindríem els botons “Start” i “Stop” per iniciar i parar el sistema. També en el menú superior tindríem l’estadística que ens servirà per a fer un filtratge de les dades i passar-les a Kg. Per últim, tenim el botó de representar gràfiques que com el seu nom indica ens representarà el fitxer d’adquisició que li diguem.
Fig 4.1 Interfície Gràfica
41
Per l’opció de crear protocol s’obre el següent submenú:
Fig 4.2 Diàleg crear protocol
On tenim les opcions de crear un protocol nou, obrir-ne un d’existent, esborrar les caselles o sortir d’aquest submenú i tornar al principal.
Per l’estadística s’obre el següent submenú:
Fig 4.3 Diàleg estadística
On ens permet seleccionar els fitxers d’entrada i sortida així com el valor del filtre.
42
4.2 Disseny del codi de Comunicació
El primer pas és realitzar una connexió amb el port sèrie. El Windows proporciona una API que conté funcions per utilitzar el port sèrie. Les funcions d’aquesta API seran les utilitzades per dur a terme les funcions de connexió, escriptura i lectura del port sèrie.
Primer obrirem el port necessari per realitzar les comunicacions. Per a fer això s’utilitza la funció CreateFile ( ). Aquesta ens permet obtenir un manegador als streams necessaris oberts per escriure i llegir el port. Per obrir un port sèrie s’utilitza la configuració dels paràmetres següents:
HANDLE CreateFile( LPCTSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile ); On lpFileName és el nom del port (exemple: COM1), dwDesiredAcces determina el tipus d’accés lectura/escriptura, dwCreationDisposition l’acció a prendre quan un fitxer existeix i quan no existeix (exemple: OPEN_EXISTING, crea un fitxer, i si no existeix retorna un error) i dwFlagsandAttributes que permet definir els flags i els atributs. Les variables no descrites es poden considerar amb valor zero o nul, ja que no es solen utilitzar per comunicacions.
Per a realitzar la comunicació s’ha fet una funció externa que permet obrir un manegador. Aquesta funció retorna el valor del manegador obert en funció del port escollit. El port es pot escollir mitjançant l’ítem de configuració del menú del programa, aquest ens permet escollir entre el port COM1 i el port COM2.
Existeixen dues estructures que són importants per a dur a terme les comunicacions correctament. Una és l’anomenada DCB (Device-Control Block). En aquesta estructura s’inicialitzen els valors de la velocitat de comunicació, la paritat utilitzada, el nombre de bits, el nombre de bits de stop i més com el control del flux.... que no s’utilitzaran, i es deixaran els valors per defecte. La mala inicialització d’aquesta estructura provoca la majoria d’errors en les comunicacions. Una altra estructura és COMTIMEOUTS. Aquesta representa els temps de time-out per realitzar les operacions de lectura i escriptura. Això afecta de la següent forma, si una operació s’agafa més temps que el especificat a l’estructura, l’operació acaba satisfactòriament i no retorna cap error. L’única manea de detectar l’error és mirant el número de bytes llegits o escrits segons l’operació. Si no existissin els valors dels time-out possiblement ens podríem quedar en un bucle infinit on esperaríem que l’operació finalitzés.
En la funció també s’hi configura l’estructura DCB, que és una estructura que ens permet determinar quin tipus de comunicació volem. En aquesta, modificarem els valors per al baud rate, la paritat, el número de bits i els bits de stop. I els valors dels time out, o temps finals.
43
Aquests temps permeten que el programa no es quedi penjat si es produeix un problema de connexió quan realitzem una escriptura a una lectura del port. Això és degut a que si es produeix un problema de connexió i realitzem una lectura del buffer el programa estarà infinitament esperant la resposta de la lectura, per evitar-ho s’utilitzen els time outs. La funció té la següent declaració:
extern HANDLE ObrirPortSerie(char *szPort,COMMTIMEOUTS *timeOutVell1);
Un cop obert el port podem escriure i llegir d’aquest. Per escriure al port sèrie utilitzarem la funció WriteFile ( ). Aquesta permet escriure o enviar un missatge pel port sèrie obert anteriorment. La definició de la funció és:
BOOL WriteFile( HANDLE hFile, LPCVOID lpBuffer, DWORD nNumberOfBytesToWrite, LPDWORD lpNumberOfBytesWritten, LPOVERLAPPED lpOverlapped );
On hFile serà el valor del manegador del port obert, lpBuffer el missatge a enviar, nNumberOfBytesToWrite el longitud del missatge en bytes, lpNumberOfBytesWritten el nombre de bytes escrits, lpOverlapped punter a l’estructura OVERLAPPED.
S’ha creat una funció externa per a tal propòsit. Per a l’escriptura necessitarem el manegador del port, el missatge a escriure i la longitud d’aquest. Aquests seran els paràmetres principals que se’ls passarà a la funció. El valor de retorn en aquest cas és un bolea que determinarà si s’ha executat l’escriptura correctament.
extern bool EscriurePort(HANDLE Com,char *Missatge, DWORD Tamany); Per llegir el port s’utilitzarà la funció anomenada ReadFile ( ), que permet llegir el buffer del port sèrie amb les dades rebudes. La utilització d’aquestes està representada al capítol següent. La declaració de la funció és:
BOOL ReadFile( HANDLE hFile, LPVOID lpBuffer, DWORD nNumberOfBytesToRead, LPDWORD lpNumberOfBytesRead, LPOVERLAPPED lpOverlapped ); On hFile és el manegador creat anteriorment, lpBuffer el buffer on s’emmagatzema el missatge rebut, nNumberOfBytesToRead, el Tamany del buffer on emmagatzema les dades, lpNumberofBytesRead el nombre de bytes llegits i lpOverlapped el punter a l’estructura OVERLAPPED.
44
En aquest cas la lectura de les dades es farà a través d’un thread que s’executarà en paral·lel amb el programa. El fil de lectura s’estarà executant fins que no es desconnecti del port i s’activarà quan ens connectem al port.
Per saber quan es rep un missatge utilitzarem la funció SetCommMask( ). Aquesta funció col·loca una màscara de les banderes que volem que ens avisin quan succeeix alguna cosa en el port. Nosaltres activarem la màscara EV_RXCHAR, que indica quan ha arribat un caràcter al buffer de la USART. Com que el thread s’estarà executant permanentment mentre s’estigui connectat al port necessitarem saber quan arriba aquest caràcter. Llavors utilitzarem la funció WaitComEvent( ) que respon segons la màscara introduïda anteriorment. A aquest se li passa una variable per referència de manera que retornarà el valor de l’event produït.
Per tancar el port s’ha creat la funció externa TancarPort( ), que retorna el manegador i tanca el port deixant-lo lliure per què pugui ser utilitzat per una altra aplicació.
extern bool TancaPort(HANDLE hCom, COMMTIMEOUTS *timeoutVell1);
Ara ja es poden escriure missatges i llegir des del port. Els missatges a enviar i rebre tenen el format especificat. Hi ha tres missatges importants. Un, el missatge de posada en marxa. Aquest missatge es definirà com una variable global del programa i tindrà els valors carregats a l’hora de crear la variable. Serà el següent:
char MsgRUN[11]=0x01,0x10,0x00,0x01,0x00,0x01,0x02,0x00,0x01,0x66,0x41;
Si existeix un missatge per arrancar el motor necessitem un per parar-lo, per tant, el següent missatge es el missatge de stop. Aquest permetrà parar el motor quan nosaltres vulguem amb l’ajut del botó parar.
char MsgSTOP[11]=0x01,0x10,0x00,0x01,0x00,0x01,0x02,0x00,0x00,
0xA7,0x81;
El pròxim és el missatge per variar la freqüència del convertidor. L’usuari podrà modificar la freqüència mitjançant el control d’edició corresponent. Un cop introduït el valor quest s’haurà de tractar, ja que s’haurà d’enviar un valor en hexadecimal que entengui el convertidor.
Per fer això es crea una funció que calcula el valor en hexadecimal del valor introduït per l’usuari. A la funció li passem el valor de la freqüència i el missatge on anirà el nou valor.
extern bool TransformarFreqHex(int Freq, char *Msg);
45
Un cop calculat el valor de la freqüència en hexadecimal i carregat al missatge, fem el càlcul del CRC. S’ha implementat una funció externa que realitza aquest càlcul. Per calcular el CRC d’un missatge es fa servir l’algoritme següent:
function crc(bit array bitString[1...len], int polinomi) ShiftRegister := initial_value; for i from 1 to len if LSB of ShiftRegister xor bitString[i] = 1 ShidtRegister := (ShiftRegister >> 1) xor polinomi; else ShiftRegister := ShiftRegister >> 1; return ShiftRegister;
On bitString serà el missatge d’on calcularem el crc, ShiftRegister serà el crc i polinomi el polinomi divisor per calcular el crc. El valor inicial pel ShitRegister serà de 0xFFFF, ja que és el valor que determina el fabricant a utilitzar. El valor del polinomi és 0xA001. La funció externa té la següent declaració:
extern bool Calcular_CRC(char *Msg,int size);
Un cop tenim els missatges creats els carreguem en una estructura dissenyada per enviar més d’un missatge alhora. Aquesta estructura està formada per un array d’strings, a on guardarem els missatges que seran enviats.
typedef struct CuaMissatges char M[8][40]; USHORT NumMsgs; USHORT ContMsg; USHORT size[8]; bool Acabat; CuaMsg_str; On M serà un array de 8 strings de 40 bytes cadascun. S’escull aquest valor perquè el missatge màxim ocuparà 40 bytes. NumMsgs, seran els missatges carregats a l’estructura. ContMsg, comptarà els missatges enviats de l’estructura. Size és la longitud en bytes de cada missatge carregat a M. I Acabat, indicarà quan s’ha acabat d’enviar tots els missatges.
El propòsit de l’estructura és enviar més d’un missatge sense obstaculitzar el programa deixant-lo penjat esperant a que enviï un missatge per poder enviar el següent. També es
46
vol establir el compliment de la temporització especificada pel fabricant. Per exemple volem enviar 3 missatges, llavors carreguem els tres missatges a l’estructura creada per tal propòsit. Un cop carregat enviem el primer missatge. Abans de començar la transmissió s’ha de posar a zero el comptador de missatges i a fals la variable Acabat. Quan el convertidor respon, es llegeix la resposta amb el thread i s’activa un timer del sistema perquè realitzi la transmissió del següent missatge 100 ms després d’haver rebut el primer. Quan s’envia el missatge s’actualitzen les variables corresponents de l’estructura per portar el control del missatge que s’ha enviat i el que s’enviarà seguidament. Un cop rebuda la resposta del segon tornem a esperar 100 ms i enviem el tercer missatge carregat a l’estructura. En aquest cas com que es l’últim missatge llavors actualitzarem la variable de l’estructura Acabat per dir que no necessitem enviar més missatges. A més, cada cop que s’envia un missatge s’activa un timer perquè produeixi interrupcions cada segon. Aquest farà la funció de control de comunicació, de forma que si enviem un missatge i al cap d’un segon no s’ha rebut cap resposta, llavors s’ha produït un error en la transmissió.
Per carregar l’estructura es crea la funció que realitza aquesta operació. El propòsit és controlar que es carreguin més de 8 missatges i facilitar la càrrega evitant una repetició redundant de codi.
extern bool CarregarEstructura(char *Msg, int size, CuaMsg_str *Cua);
Com totes les funcions anteriors aquesta retornarà un bolea per determinar si s’ha executat la càrrega correctament. A més, li passem el missatge, la longitud del missatge i un punter a la nostra estructura.
Un cop tenim el sistema de comunicació passem a realitzar la programació del control del programa. S’han creat tres timers del sistema per portar el control.
El primer timer es l’encarregat de controlar els missatges de resposta del convertidor. Aquest s’activarà cada 100 ms. El funcionament consisteix en activar el timer cada cop que llegim un missatge amb el thread, que estarà contínuament comprovant si s’ha rebut algun missatge, i un cop passats els 100 ms tractem el missatge rebut i enviem el següent missatge si n’hi ha. Els missatges estaran carregats a l’estructura CuaMissatges creada per tal propòsit.
El procediment és el següent:
El programa envia un missatge al convertidor, llavors, al cap d’un temps, aquest ens respon, la resposta serà llegida pel thread que s’executarà contínuament, i un cop llegit s’activarà el timer perquè s’executi als 100 ms. Al cap del temps sol·licitat, s’executarà el processat del missatge. Primer mirem si aquest és erroni i quin error s’ha comès. Llavors, mirem si la resposta és deguda què estàvem llegint la freqüència de sortida del variador si no és així passem a enviar el següent missatge, que estaran carregats a l’estructura. Si no hi ha missatges no s’enviarà res.
El següent timer és el timer Error, que ens permet controlar si no s’ha rebut cap resposta del convertidor després d’enviar un missatge. Cada cop que s’envia un missatge activem aquest
47
i al cap d’un segon s’executarà el codi introduït. Si teníem missatges pendents els neteja i atura la transmissió.
El tercer timer és el de lectura de la freqüència del convertidor. Aquest s’està executant cada 500 ms. S’activa quan arranquem el cicle del motor. Per tant, cada 500 ms llegim la freqüència i actualitzem la gràfica de la pantalla. El codi del timer només realitza l’enviament del missatge de lectura de la freqüència i el timer resposta processa el missatge rebut pel convertidor. Com s’ha dit abans el timer resposta comprova si s’està realitzant la lectura de la freqüència per mitjà d’una variable boleana.
Per últim, tenim el timer duració que és l’encarregat de controlar el temps de duració del cicle. Aquest s’executa cada segon, llavors va incrementant dues variables, un pels segons i l’altre pels minuts. Mitjançant la variable duració carregada pel protocol sabrem quan de temps s’haurà d’estar executant el cicle. Els valors calculats es mostraran pel control situat a la finestra del programa.
Un cop arrancat el cicle s’anirà dibuixant el procés per pantalla. El dibuix s’anirà refrescant cada cop que es fa la lectura de la freqüència.
Per a fer el dibuix s’han utilitzat les funcions de la classe canvas del borland, que permet dibuixar línies, corbes, circumferències i més. Llavors tenim una zona de la finestra dedicada al dibuix. Aquesta zona tindrà un mida en píxels que utilitzarem per referènciar-nos sobre la pantalla. Com tota gràfica d’una funció consta de dos eixos cartesians, l’eix X, que representarà el temps; i l’eix Y, que representarà el valor de la freqüència de sortida del variador. L’eix X es divideix en 44 porcions de forma que el màxim nombre de punts a visualitzar a la pantalla seran 44. D’aquesta forma es creen dues variables, una que guardarà les freqüències llegides i l’altra que guardarà els punts calculats amb les freqüències llegides.
El càlcul dels punts a dibuixar es fa creant dues variables més, una representarà l’increment de l’eix x, que serà prèviament calculat segons la mida de la zona de dibuix; i l’altre l’increment de l’eix y, aquest serà prèviament calculat en funció de la freqüència màxima. Llavors els punts seran calculats de la forma següent:
PA[DivisioX].x = Xo + DivisioX*IncrementX; PA[DivisioX].y = Yo - Freq[DivisioX]*IncrementY;
On Xo i Yo són l’origen dels eixos. Divisio X és la posició X actual, com a màxima prendrà el valor 44, i Increment X i Increment Y explicats abans. Freq[DivixioX] serà la freqüència llegida en aquest moment.
Per donar la sensació de moviment s’utilitza la variable Divisio X com a referència. De forma que quan DivisioX arriba al valor 44, movem tots els valors dels punts un lloc enrere de l’array de punts i calculem l’últim punt en funció de la freqüència actual llegida, i es fa un refresc del dibuix actualitzant la gràfica.
48
Per altra banda, tenim la creació dels protocols. Aquests vindran determinats per una sèrie de paràmetres que son interessants de controlar. Tenim la velocitat, el temps d’acceleració, el temps de desacceleració i la duració del cicle. Cada protocol tindrà un nom que s’haurà introduït anteriorment.
Per poder crear els protocols s’ha dissenyat un diàleg que s’obrirà quan pitgem l’ítem del menú del programa crea protocol. El diàleg conté un control edit per a cada variable citada anteriorment. A més, conté 4 botons, un és el botó crea protocol, que ens serveix per guardar les dades introduïdes, les quals es guardaran en un arxiu amb extensió *.ptl. L’arxiu prendrà el nom del protocol. Obre protocol permet obrir un protocol creat anteriorment per tal de modificar les seves variables i crear un de nou a partir d’aquest. Neteja esborra els controls edit deixant-los en blanc i sortir tancar el diàleg.
Un cop creats els protocols podem obrir-los amb el programa per mitjà de l’ítem obre protocol del menú principal. Aquest carregarà les dades que es mostraran per pantalla i actualitzarà els valors del variador i de variables internes del programa per al control del cicle.
49
4.3 Disseny del Codi inici adquisició i sincronització
Per tal de sincronitzar l’adquisició i el control del motor s’afegeix un timer que controla el temps del cicle. Aquest timer es posarà en marxa quan iniciem el cicle i portarà el control dels temps en que s’ha d’activar la conversió i parar el motor.
El funcionament és el següent: un cop obert el programa ens connectarem amb el port i carregarem el protocol. Després premerem el botó start. En aquest instant s’activa el timer i es posa en marxa el motor. Al cap d’un temps, calculat anteriorment, es posarà en marxa l’adquisició durant x segons. Un cop acabada l’adquisició passaran uns segons abans no es pari la cinta. El temps estarà controlat pel timer que incrementarà una variable cada segon.
Un cop acabat el cicle el timer es pararà i no es tornarà a engegar fins al següent cicle. El codi és el següent:
void __fastcall TMainForm::TimerDuracioTimer(TObject *Sender) Seg++; EditTemps->Clear(); sprintf(gszBuf," %02d:%02d",Min,Seg); EditTemps->SetTextBuf(gszBuf); if(Seg+(Min*60) == TAdq+TempsAcc) TimerResposta->Enabled = false; TimerError->Enabled = false; TimerDuracio->Enabled = false; TimerFreq->Enabled = false; FiLlegir = true; FiAdq = false; ThreadConversio = new TConversio(true); if(Seg == 60) Seg = 0; Min++; EditTemps->Clear(); sprintf(gszBuf," %02d:%02d",Min,Seg); EditTemps->SetTextBuf(gszBuf); if((Seg+(Min*60)) == TempsAcc) EditTemps->Color = clWhite; EditTemps->Font->Color = clBlack; if((Seg+(Min*60)) == (Duracio-TempsDes)) BtnStop->Click(); if(((Seg+(Min*60)) == Duracio)&&(FreqReal == 0))
50
TimerDuracio->Enabled = false; EditTemps->Clear(); EditTemps->Color = clWhite; sprintf(gszBuf," %02d:%02d",Min,Seg); EditTemps->SetTextBuf(gszBuf);
Les variables estrella són: Seg i Min, que controlen els segons i el minuts transcorreguts des que s’ha iniciat el cicle. Seg s’incrementarà cada cop que s’executa el codi del timer. Llavors, en funció del valor d’aquest, s’incrementarà el valor de Min.
També tenim la variable Duració, aquesta conté el valor de la duració màxima del cicle, de manera que quan el valor dels segons més el dels minuts és igual al valor de la duració es pararà el motor i s’acabarà el cicle de prova.
Per al control de l’adquisició es crea la variable Tadq. Conté el moment en el qual s’ha de començar l’adquisició. El càlcul d’aquest valor es fa en el moment d’obrir el protocol, de forma que
TAdq = (Duracio*60) / 3; En el moment en què el temps del cicle és igual al moment de l’adquisició es fan diverses coses. Primer, s’aturen els timers del sistema utilitzats, encara que quan estem adquirint aquest, no funcionen, ja que el control està agafat pel thread d’adquisició i el programa principal no funciona, per dir-ho d’una manera. Després es para el thread de lectura del port sèrie fent la variable FiLlegir igual a cert. Per últim, activem el thread per a l’adquisició, i el codi és el següent:
//Para els timers TimerResposta->Enabled = false; TimerError->Enabled = false; TimerDuracio->Enabled = false; TimerFreq->Enabled = false; //Atura el thread de lectura FiLlegir = true; //Activa el thread d’adquisició FiAdq = false; ThreadConversio = new TConversio(true);
51
4.4 Disseny de l’aplicació
Els següents diagrames de flux són els utilitzats per realitzar el programa per al control de la plataforma. Igual que en el programa d’adquisició, el programa principal funcionarà amb missatges i events. Per tant, el programa principal només controlarà el bucle de missatges. Per a la comunicació s’ha utilitzat el protocol especificat en el manual del convertidor per enviar i rebre missatges. En la figura 9.13 es pot veure com funciona l’aspecte de les temporitzacions. L’últim diagrama fa referència al tractament dels errors. Quan es tracten els errors es realitza el reenviament del missatge n vegades abans d’aturar la comunicació.
Windows treballa amb events. És a dir, cada cop que es produeix algun event, Windows realitza una tasca relacionada amb aquest. Els events estaran directament relacionats amb els programes emergents en aquell moment, de forma que, quan succeeixi alguna cosa Windows enviarà un missatge al programa que ha de tractar aquest event. Llavors necessitem en el programa un tros de codi que estigui mirant contínuament si el Windows ens envia algun missatge per tractar-ho.
Programa Principal
Fig 4.4 Diagrama del Programa Principal
Un cop Windows envia un missatge corresponen al nostre programa, aquest s’haurà de processar per executar alguna tasca. En el programa per al control de la plataforma tenim 5 events clau a tractar.
Inici
Bucle de Missatges
Hi ha Missatges?
Tractar Missatge
No
Si
52
Tractament del Missatge
Fig 4.5 Diagrama del Tractament del Missatge Rebut
Connectar farà la connexió amb el port, COM 1 o COM 2. Desconnectar alliberarà el port i netejarà els buffers. Arranca, enviarà el missatge al convertidor perquè aquest comenci a funcionar. Para, enviarà el missatge corresponent al convertidor perquè pari. I gràfica, enviarà un missatge per a que és puguin representar les dades capturades.
El següent diagrama de flux representa el bucle de comunicació que s’executarà cada cop que enviem un missatge. Es seguirà el format representat a la figura 9.13. Per tant, tindrem dos rellotges que ens permetran realitzar els temps d’espera abans de rebre i enviar un missatge. Aquest bucle només s’executarà si primerament ens hem connectat al port sèrie.
Inici
Connectar? Desconnectar? Arranca? Para?
Obrir Port Sèrie Tancar Port Sèrie Arranca el Motor Para el Motor
Si Si Si Si
Gràfica?
Representa Gràfica
Si
53
Comunicació
Fig 4.6 Diagrama de Comunicació
Inici
Enviar Missatge
Esperar Temps 1
Fi ?
Mirar Missatge Rebut
Missatge Correcte?
Esperar Temps 2
Fi
Més Missatges a Enviar?
Enviar Missatge Següent
Si
No
Si
Si
Si
No
No
NoFi
Tractar Error
54
El següent i últim diagrama fa referència al tractament dels missatges erronis. En aquest cas, s’enviarà el missatge n cops i si no és correcte abans de finalitzar els n enviaments llavors comuniquem a l’usuari l’error de comunicació i la tanquem.
Tractament Missatge Erroni
Fig 4.7 Diagrama Tractament de Missatge Erroni
Inici
Reenviar MissatgeMissatge Enviat n
cops?
Error de Comunicació
No
Si
55
5 Hardware
En aquest tema veurem el hardware que s’ha fet, així com el seu ajust en el laboratori.
5.1 PCB Amplificadors
Com ja s’ha comentat, el sistema té dues plaques PCB en les quals hi han 4 amplificadors. En realitzar alguna petita prova, ràpidament s’observa que la placa corresponent als sensors de components anteroposterios i mediolaterals no funcionava correctament. El que s’ha fet aprofitant el fotolit existent, és crear una nova placa i ajustar-la al laboratori per poder-la reemplaçar i reparant l’actual tenir-ne una de recanvi.
Anem a veure una mica el procés que s’ha realitzat. El primer pas ha estat obtenir el suport PCB i soldar els components a la placa.
Fig 5.1 Amplificadors en suport PCB
Un cop tenim la placa amb tots els components soldats, procediment a l’ajust en el laboratori. El primer que s’ha fet és obtenir una alimentació de +12V i -12V amb la que s’alimentaran els amplificadors.
Fig 5.2 Alimentació 12V
56
Un cop tenim l’alimentació per la nostra placa procedim a ajustar els guanys dels amplificadors per a tenir 10 volts a la sortida quan a l’entrada tinguem el valor màxim dels sensors, que són 36mV. Per últim, s’ha d’ajustar l’offset per tal de tenir el 0. Anem a veure els càlculs teòrics per tenir una orientació de valors, així com l’esquema per ajustar l’offset.
Fig 5.3 Amplificador d’instrumentació
El valor de la tensió de sortida és:
Rg serà el potenciòmetre amb el qual ajustarem el guany, el seu valor teòric per tal que amb una entrada de 36mV tinguem 10V a la sortida és:
Guany = 10V/ 36mV = 277,78
1+2R1/Rg= Guany => Rg = 2R1/ Guany-1= 722,6 Ω
Ara ens quedaria per veure com ajustar l’offset. Per ajustar l’offset el que s’ha fet és posar entre els pins 1 i 8 de l’amplificador operacional un potenciòmetre de 20 kΩ, amb el cursor connectat a l’alimentació positiva de l’amplificador.
Fig 5.4 Esquema per ajustar l’offset
57
En les imatges següents es pot observar l’aplicació a les entrades de 36mV per tal de poder ajustar el guany i el valor de offset inicial negatiu que s’haurà d’ajustar a 0 amb els potenciòmetres.
Fig 5.5 Ajusts amplificadors
S’ha comprovat que el valor teòric del potenciòmetre per tenir el guany desitjat i el real, són molt similars. El valor teòric del potenciòmetre per tenir un guany de 278 és de 722,6 Ω i el real és d’uns 730 Ω. Un cop realitzats els passos indicats ja tenim la placa apunt per substituir.
Fig 5.6 Amplificadors calibrats
58
6 Avaluació
Aquest capítol farà referència a les proves realitzades per comprovar el correcte funcionament del projecte. Hi ha dos parts diferenciades: avaluació del programa d’adquisició estàtica i avaluació del programa dinàmica.
6.1 Temporitzacions
El que s’ha fet és comprovar que els temps d’adquisició fossin els desitjats i per tant poder assegurar que funciona correctament.
El bucle de retard està format per una sentència for( ; ; ) de la forma següent:
for(;i<retard;i++) executar codi;
Primer de tot tenim una variable anomenada retard que serà de tipus sencer, i representa les vegades que s’executa el bucle per poder realitzar la temporització. Aquesta variable es calcula a partir del període de mostreig, el temps que tarda el driver en realitzar la conversió de n canals i el temps que tarda en efectuar-se el codi intern del bucle de retard. Obtenim una expressió matemàtica .
En el meu cas, el codi a executar dins del bucle és l’expressió matemàtica:
log(25);
Ara ens interessa saber quin és el temps aproximat que tarda el nostre PC en executar un cop l’expressió matemàtica per poder calcular la nostra variable retard.
Per fer això, executem la instrucció un nombre de vegades, i, mitjançant el rellotge del sistema del PC, obtenim el temps que tarda en efectuar-se n vegades la nostra expressió. Un cop tenim aquest temps, el dividim pel nombre de vegades que s’ha executat l’expressió. Per tant, tindrem un tros de codi que consistirà en un bucle de repetició en el qual executarem n vegades l’expressió matemàtica log( 25 ).
for(;i<n;i++) log(25);
El que volem és que el nostre bucle de retard pugui realitzar temporitzacions menors de 1ms ja que mostrejarem el senyal a una freqüència de 1000 Hz i necessitarem fer la
59
conversió dels 8 canals cada 1ms. Per aquesta raó també executem una expressió que el PC executi en un temps relativament curt.
//Calculem el temps d'execució de log(25) ini = clock(); for(i=0; i<1000000;i++) log(25); fi=clock(); const_retard = (float)(fi-ini)/(CLK_TCK*1000000.0);
Després d’unes quantes proves el valor òptim adoptat ha estat d’executar el bucle 1 000 000 de vegades, ja que l’operació tarda ns en efectuar-se. El valor obtingut després de realitzar les proves és que l’expressió log(25) tarda 270 ns en efectuar-se. Això ens permet realitzar més cops el bucle de retard i no cometre un error molt gran. El que passa, principalment, és que si executem el bucle poques vegades obtenim un valor de temps d’execució major i que no s’ajusta al valor d’execució de les instruccions real. Llavors, a l’hora de calcular el valor del retard, aquest ens implicarà que el retard sigui més petit i el bucle s’executarà poques vegades, cometen un error major.
En el cas del valor de Conversió_n_Canals fem el mateix procediment. En Aquest cas com que la conversió d’un sol canal té una duració aproximada d’uns 26 us el bucle per calcular el temps no fa falta que sigui tan llarg, realitzem la conversió dels 8 canals 10 000 cops.
//Calculem el temps de conversió de n canals //Configurem el guany dels 8 canals de la targeta lp_MAIConfig.NumChan = NumChans; lp_MAIConfig.StartChan = StartChan; lp_MAIConfig.GainArray = (USHORT *)GainArray; if((ErrCde = DRV_MAIConfig(*DriverHandle,(LPT_MAIConfig)&lp_MAIConfig))!=SUCCESS) DRV_GetErrorMessage(ErrCde,szErrCde); MessageBox(NULL,szErrCde, "Missatge del Driver",MB_OK|MB_ICONEXCLAMATION); //Efectuem la conversion 1000 vegades lp_MAIVoltageIn.NumChan = NumChans; lp_MAIVoltageIn.StartChan = StartChan; lp_MAIVoltageIn.GainArray = (USHORT *)GainArray; lp_MAIVoltageIn.TrigMode = 0; lp_MAIVoltageIn.VoltageArray = (float *)VoltageArray; ini=clock(); for(j=0;j<1000;j++) if((ErrCde =
60
DRV_MAIVoltageIn(*DriverHandle,(LPT_MAIVoltageIn)&lp_MAIVoltageIn))!=SUCCESS) DRV_GetErrorMessage(ErrCde,szErrCde); MessageBox(NULL,szErrCde, "Missatge del Driver", MB_OK|MB_ICONEXCLAMATION); for(k=0;k<NumChans;k++) fprintf(OutFile, "%.2f\t",(float)VoltageArray[k]); cont++; fprintf(OutFile, "\n"); fi=clock(); const_conv = (float)(fi-ini)/(CLK_TCK*10000.0);
Per últim, el valor del període de mostreig be determinat per l’usuari i serà la inversa de la freqüència introduïda per aquest.
const_temps = (float)1.0/SampleRate;
Les gràfiques següents mostren els valors obtinguts després d’executar diverses vegades els bucles anteriors. S’han agafat 100 mostres per a cada temporització. La primera gràfica mostra els valors obtinguts d’executar 100 vegades el bucle per calcular el valor del log(25). La segona mostra els temps que tarda en efectuar-se l’adquisició de 8 canals. La prova consisteix en executar 100 vegades el càlcul de les dues temporitzacions seguides.
Fig 6.1Gràfica de temps d’execució del log(25).
61
Fig 6.2 Gràfica del temps d’execució de la conversió de 8 canals.
Es pot veure en les gràfiques que l’execució de les instruccions no és fixa i varia segons determini l’ocupació del sistema. Però comparant les dues gràfiques s’observa com les irregularitats d’un coincideixen amb les irregularitats de l’altre. És a dir, quan l’execució del log(25) tarda més temps en efectuar-se llavors la conversió tarda el mínim de temps en efectuar-se. I a la inversa, quan la conversió tarda el màxim, el càlcul del logaritme tarda el mínim. Per tant, podem dir que estan compensats i no afectaran d’una forma significativa a la temporització.
Ara, fem el càlcul de la variable retard per tal de poder executar l’adquisició cada període de temps determinat.
//Calculem el valor del retard if(const_conv > const_temps) MessageBox(NULL,"Impossible Realitzar la Conversió.\ \nIncompatibilitat Temporal.", "Error", MB_OK|MB_ICONEXCLAMATION); return false; else retard = (((float)(const_temps-const_conv)/(float)const_retard)+0.5); if(retard < 0) retard = 0xFFFFFFFF-(ULONG)retard; else retard = (ULONG)retard;
Un cop creat el bucle de retard executem el programa d’adquisició i fem una conversió d’x segons. Amb l’ajuda del rellotge del sistema, mirem el rellotge abans de fer l’adquisició i després de fer-la i calculem el temps, fent la resta del valor final menys el valor inicial i dividint aquesta per la freqüència del rellotge, en segons. Inici = clock(); while(!acaba)
62
//Funció del driver per converitr els 8 canals alhora if((glErrCde = DRV_MAIVoltageIn(DriverHandle,(LPT_MAIVoltageIn)&lpMAIVoltageIn))!=SUCCESS) DRV_GetErrorMessage(glErrCde,gszErrCde); Application->MessageBox(gszErrCde, "Missatge del Driver", MB_OK|MB_ICONEXCLAMATION); for(k=0;k<usNumChans;k++) //Escrivim els valors en un fitxer fprintf(fp, "%.2f\t",(float)fVoltatge[k]); mostres++; fprintf(fp, "\n"); if(mostres == glNumMostres*CANALS) //Si la conversion s’ha acabat Final = clock(); acaba = true; else for(i=0;i<glRetard;i++) //Realitzem el retard log(25); Si activem la conversió i activem el cronòmetre alhora es pot veure com el temps i la conversió duren aproximadament els segons introduïts per l’usuari. La taula següent mostra uns quants valors provats.
Valor Predeterminat
(segons)
Valor del Cronòmetre (segons) Mitja
5 4.965 4.979 4.893 4.913 4.977 4.934 4.904 4.983 4.912 4.932 4.93
20 19.43 19.30 19.57 19.24 1943 19.50 19.37 19.30 19.43 19.43 19.4
40 39.31 38.81 39.01 39.42 38.88 39.15 39.42 39.16 38.75 38.88 39.2
60 58.93 58.73 58.33 58.53 59.14 58.93 58.13 59.14 59.13 58.73 58.83
80 78.52 78.05 78.25 78.98 80.40 80.65 78.88 80.80 80.32 80.70 79.55
100 101.0 100.3 100.9 100.9 101.3 100.9 101.3 101.1 101.1 101.0 100.9
120 121.7 121.4 120.8 121.0 121.1 121.1 120.9 121.3 121.0 121.2 121.1
Fig 6.3 Duració de la conversió.
Els valors de la taula corresponen a la realització de 10 conversions a diferents valors de temps i el càlcul de la mitjana d’aquests valors. Podem dir que hi ha una desviació, arrodonint, de ±1segon del FE, on el fons d’escala serien els segons que volem que duri l’adquisició. Per tant, podem donar per bons els resultats, ja que no influeix gaire en
63
l’adquisició, i es compleixen els temps força correctament. Com que en principi farem adquisicions durant llargs períodes de temps, 2 minuts o més, encara es pot afirmar que cometem menys error, ja que la variació de ±1 segon enfront de 120 segons és una relació petita, i només varia en un ±0.83 % de totes les dades adquirides.
64
6.2 Avaluació al centre en estàtic
En el primer apartat d’aquest tema es comprovarà que el programa tingui el comportament desitjat i que tots els botons i edits que conté funcionin tal i com desitgem. En la segona part mostrarem les proves realitzades per tal de poder verificar el correcte funcionament del programa.
6.2.1 Avaluació programa
El primer pas a fer és obrir el programa. Un cop obert, observem els valors dels sensors en la cinta i el pes al centre de la mateixa. Observem com a la part on hi ha el nom del dispositiu la detecta correctament (PCL 818). El botó d’adquisició està apunt per a ser clicat, mentre que el de Fi adquisició el tenim deshabilitat i el edit Ok està en vermell perquè no estem adquirint.
Fig 6.4 Menú principal
Si cliquem a inici adquisició s’obre el següent menú.
Fig 6.5 Menú introducció freqüència
65
En el qual hem d’introduir el valor de la freqüència de mostreig. Si no introduïm un valor dins del rang permès, el programa ens ho indicarà amb un missatge d’error.
Fig 6.6 Error introduir dades
Si el valor introduït està comprès entre 100 i 1000 el programa et dirà amb el període de mostreig que adquirirà i et demanarà amb el temps que vols adquirir.
Fig 6.7 Informació període de mostreig
Fig 6.8 Introduir temps a adquirir
Si tot ha estat correcte el programa t’informa de les mostres que realitzaràs.
Fig 6.9 Infromació número mostres
66
Per últim, si totes les dades són correctes el programa et demana un nom de fitxer per guardar l’adquisició a un directori que crea automàticament que es diu “Estudis MEC”.
Fig 6.10 Introduir nom fitxer
Un cop acceptat el fitxer, el programa comença a adquirir i els botons d’adquisició inverteixen l’habilitació tal i com es veu en la imatge següent. El botó ok es posa verd indicant que està adquirint.
Fig 6.11 Estat inici adquisició
Un cop acaba l’adquisició els botons tornen al seu estat inicial
Fig 6.12 Estat fi adquisició
67
El següent pas a realitzar és el de l’estadística, que ens passarà l’adquisició realitzada a Kg. En clicar el botó Fitxers s’obre un menú on posarem el nom del fitxer a tractar i el nom que volem que tingui el nou fitxer passat a Kg.
Fig 6.13 Obre diàleg estadística
Per representar l’adquisició realitzada clicariem al botó gràfica i ens obrirà el següent menú:
Fig 6.14 Botó representar gràfiques
68
Clicant al botó anterior amb l’icona de Matlab ens demanarà el nom del fitxer a representar i ens ho dibuixarà en una finestra de Matlab sense arribar a obrir-lo.
Fig 6.15 Representació feta
6.2.2 Proves realitzades
Un cop fetes les proves a casa a partir d’una demo i comprovar que l’adquisició i generació de dades és correcta, passem a realitzar proves al centre podològic. Un cop al lloc de treball es fan les connexions pertinents. Primer connectem el cable que anirà connectat als amplificadors, i un connector DB-37, que anirà connectat a la targeta d’adquisició. Engeguem l’ordinador i activem els amplificadors d’instrumentació. En aquest moment ja estem preparats per fer les proves.
69
La primera prova a realitzar és la més simple. El que farem és adquirir el pes d’una persona. El qui realitzarà les proves, inicialment estarà fora de la cinta i entrarà en ella quedant-se parat sense caminar. El resultat d’aquesta prova és el següent:
Fig 6.16 Representació pes
Podem observar que el pacient entra a la cinta al cap de 1,5s, el fet de situar-se en la cinta ens provoca un transitori i al cap de 3,5 segons entrem en estat estacionari on observem el pes del pacient que és de 80 Kg.
La segona prova realitzada correspon a realitzar una passa sobre la plataforma. Com ja sabem la forma que ha de tenir aquesta gràfica és la de una M.
Fig 6.17 Representació 1 pas
70
En la imatge anterior es poden diferenciar clarament el moment d’impacte del taló que ens provoca el pic de 115 Kg. La segona fase és el moment en què recolzem tot el peu. Per últim hi ha el moment de propulsió. Altres dades que ens ha valorat el Dr. Jose és que el temps d’una passa és de uns 800ms i que el pic és de 1,2 vegades el pes. Si mirem la gràfica es compleixen perfectament les bases teòriques.
Per últim, el que es farà és realitzar dues passes seguides, o el que és el mateix, un cicle complert.
Fig 6.18 Representació 2 passes
Observem en la gràfica la primera passa al cap d’1,5s, però en el moment de propulsió del peu dret coincideix amb el moment d’impacte del peu esquerre i per això tenim el pic indicat amb un cercle vermell. Després del pic es pot veure el moment en què només recolzem el peu esquerre i finalment la propulsió d’aquest.
71
6.3 Avaluació al centre en dinàmic
En el primer apartat d’aquest tema es comprovarà que el programa tingui el comportament desitjat i que tots els botons i edits que conté funcionin tal com desitgem. En la segona part mostrarem part de les proves realitzades per tal de poder verificar el correcte funcionament del programa.
6.3.1 Avaluació programa
El primer pas és obrir el programa. Un cop obert ens apareix la interfície d’aquest. Ens connectem amb el convertidor pitjant el botó Connectar que apareix a la pantalla. Llavors s’activa una finestra de missatge avisant que es configurarà el convertidor. Com es pot veure, la connexió funciona correctament, per tant, ja tenim un pas provat i funcionant correctament.
Fig 6.19 Configurant convertidor
Un dels possibles errors que es poden produir és que l’ordinador no tingui port sèrie i, per tant, no puguem realitzar una connexió.A més, també es pot donar el cas que el port al que ens volem connectar, ja estigui ocupat per una altra aplicació. En aquests casos el programa avisarà l’usuari que no existeix cap port o que aquest està sent utilitzat per alguna altra aplicació.
72
Fig 6.20 Error de Port inexistent.
Un altre dels errors possibles és que no tinguem el convertidor connectat amb l’ordinador o que el cable de connexió estigui defectuós. Llavors, en el moment d’enviar qualsevol missatge, al cap d’un segon, ens apareixerà un missatge d’error indicant-nos que el missatge no s’ha pogut enviar.
Fig 6.21 Error a l’hora d’enviar les dades.
Un cop connectats passem a la creació dels protocols per després carregar-los al programa. Per crear els protocols s’ha afegit un diàleg que s’obre quan pitgem l’ítem del menú principal Crea Protocol. Aquest diàleg presenta una sèrie de controls edit que ens permeten modificar les variables per crear el protocol. Aquestes dades es guardaran en uns arxius amb l’extensió *.ptl i tindran el nom introduït al control Nom Protocol. Per tant, pitgem l’ítem i s’obre, el diàleg. Llavors omplim totes les variables amb els valors que ens interessin i pitgem el boto Crea Protocol.
Fig 6.22 Menú crear protocol
73
Es pot veure com totes les dades tenen un valor. Un cop creat apareix un missatge confirmant que s’ha creat el protocol correctament. En el cas que cometem una errada el programa ens avisarà amb un missatge. Per exemple, si introduïm una dada incorrecta el programa ens avisa que la dada introduïda es incorrecta i quins són els valors en els quals es troba. En la següent figura es pot veure com es provoca un error degut a que no s’ha introduït cap valor per la velocitat.
Fig 6.23 Error en la creació del protocol.
Un cop creat el protocol tornem al programa principal i l’obrim. Per obrir-lo anem al menú principal protocol i en pitgem l’ítem obre protocol. Llavors ens apareix un diàleg de Windows per obrir fitxers i obrim el protocol creat amb el nom PacientX. Un cop obert es configurarà el convertidor amb les dades introduïdes i es mostraran les dades per pantalla.
Fig 6.24 Obrim el protocol.
74
Es pot veure com apareixen les dades en el grup amb els paràmetres carregats anteriorment quan s’ha creat el protocol. La velocitat serà de 80Hz, amb un temps d’acceleració de 10 segons i un temps de desacceleració de 10 segons. A més el cicle a velocitat màxima durarà 1 minut. Mostrejarem les dades a 100 Hz. Ara ja tenim els paràmetres del protocol carregats i s’ha habilitat el botó start de color verd. Comencem el cicle pitjant el botó. Primerament ens demanarà el nom del fitxer al guardar l’adquisició i després es posarà en marxa el motor accelerant lentament durant 10 segons fins assolir la velocitat màxima.
Fig 6.25 Arranquem el cicle.
Es pot veure a la figura com la velocitat va accelerant lentament. A la part esquerra es veu un rellotge en vermell. Sempre que el motor està accelerant o frenant apareixerà el rellotge en vermell. A la figura següent es veu com assoleix la velocitat màxima i es manté.
Fig 6.26 Velocitat màxima.
75
Un cop passats x segons es posarà en marxa l’adquisició automàticament obtenint les dades proporcionades per les cèl·lules de càrrega. Després de l’adquisició el motor continuarà funcionant fins assolir el temps de duració especificat en el protocol. Llavors el motor es pararà fins assolir la velocitat de 0.
Fig 6.27 Desacceleració fins a la velocitat 0.
Un cop acabat el cicle filtrem les dades fent el procés d’estadística. Per filtrar les dades podem obrir un diàleg amb l’ítem del menú, estadística. S’obre el diàleg i apareix una finestra amb controls edit i una sèrie de botons. Podem modificar l’ample del filtre i obrir els fitxers necessaris dels quals tractarem les dades.
Fig 6.28 Filtratge de les dades.
76
Un cop s’han obtingut les dades de la plataforma i s’ha aplicat el filtre per suavitzar el soroll, podem veure el resultat clicant el botó de gràfica que ens representarà el fitxer que li diem.
Fig 6.29 Botó representar gràfiques
Representació:
Fig 6.30 Dades adquirides i filtrades.
77
6.3.2 Proves realitzades
Les proves d’aquest apartat s’han realitzat amb la següent configuració.
Fig 6.31 Paràmetres protocol
El resultat de l’adquisició del Dr. Jose corrent és el que ens mostra en la figura 6.32, on és poden veure clarament els cicles del corre.
Fig 6.32 Representació al correr.
78
7 Conclusions En aquest capítol es treuran les conclusions dels dos programes implementats per separat. Es valoraran els resultats finals obtinguts i les possibles observacions que es podran realitzar amb els programes.
7.1 Programa Estàtica
Pel què fa al programa d’adquisició estàtica a donat uns resultats molt bons. Aquest programa ens ha servit per observar el pic que tenim en el moment que coincideixen els dos peus recolzats al caminar, detall que si es mira en el dinàmic no podríem observar.
Un altre punt molt important és la visualització dels sensors en la posició que ocupen en la cinta, degut a què ens ha permès veure que els sensors mediolaterals (que no s’utilitzen en aquest projecte) tenien un problema mecànic. A més aquesta zona de programa ens permet veure només iniciar en el mateix que els sensors estiguin ajustats.
Un dels problemes és que les instruccions mai tarden el mateix temps en efectuar-se i, per tant, hi haurà un error que sempre estarà present en el bucle de retard. Es veurà reflectit en la temporització de l’aplicació. S’han realitzat proves de diferents temporitzacions amb un cronòmetre i per la nostra aplicació l’error que es comet és petit (ordre inferior a segon). Podem dir que la temporització és bona.
En les gràfiques realitzades s’ha pogut observar com el resultat obtingut era l’esperat teòricament, donant pics de 1,2 vegades el pes de la persona i obtenint un representació gràfica en forma de M.
La conclusió final del programa és que s’obtenen resultats molt bons complint les especificacions temporals necessàries i obtenint unes gràfiques de les dades adquirides òptimes per a un estudi. El Dr. Jose el podòleg del centre ja ha utilitzat el programa amb un pacient esportista podent-ne treure valoracions.
79
7.2 Programa Dinàmica
En el programa d’adquisició dinàmica els resultats obtinguts també han estat satisfactoris. Aquest programa ens permet veure els cicles en la carrera d’un esportista a diferents velocitats i temps.
La part del control del motor (duració, acceleració, desacceleració, velocitat) funciona correctament i el motor es comporta tal i com defineix l’usuari en el protocol. El problema el tenim amb la cinta que frega amb la base de fusta i es frena una mica. El Dr. Jose volia espera a la finalització d’aquest projecte per moure la cinta de lloc i solucionar aquest petit problema.
Un altre punt important és que amb l’adquisició en marxa, pel moviment de la mateixa cinta, es pot pensar que introduirem molt de soroll. Per tal de poder valorar realment la importància d’aquest soroll introduït es van fer proves amb la cinta funcionant sense ningú al damunt i amb el Dr. Jose es va veure que realment era un error assumible.
Els gràfics finals obtinguts ens serveixen per observar els cicles en la carrera d’un esportista. Com ja s’ha comentat si la marxa no és corrent i la fem caminant es sobreposen la passa dreta amb l’esquerre en el moment de propulsió d’una i ‘ impacte de l’altra. Aquest punt s’hauria de tractar per mitjà del programa si és volgués visualitzar les passes completament per separat.
La conclusió final del programa és que s’obtenen resultats bons complint les especificacions temporals necessàries i obtenint unes gràfiques de les dades adquirides òptimes per a un estudi. El Dr. Jose, el podòleg del centre ja ha utilitzat el programa amb un pacient esportista podent-ne treure valoracions.
80
8 Referencies
Bibliografia
[1] Francisco Charte Programación con C++ Builder 5. Anaya Multimedia cop.2000 [2] Jeffrey Richter, Programming Applications for Microsoft Windows. 4a Edició Microsoft Press. 1999. [3] Charles Petzol, Programming Windows. 5a Edició Miscrosoft Press. 2002. [4] Kent Reisdroph & Ken Henderson, Teach Yourself Borland C++ in 14 days. Borland Press. [5] Johnson M. Haunt, Windows System Programming. 3a Edició Addison Wesley Professional. 2004. [6] Mario Giannini, Jim Keogh, Windows Programming. Programer’s Notebook. Prentice Hall. [7] Jim Beveridge, Robert Wiener, Multithreading Applications in Win32. Addison Wesley Developers
Press. 1997. [8] Thuan Q. Pham & Pankaj K. Garg, Multithreaded Applications in Windows NT. Prentice Hall.1996.
Pàgines Web
[9] http://www.wikipedia.com [10] http://www.mathworks.com [11] http://www.nastfulgore.sapces.live.com /blog/ [12] http://www.borland.com/es/. [13] http://www.advantech.com/ .
Programari
- Borland C++ Builder 5.0:
Programa utilitzat per a realitzar l’escriptura, compilació, linkatge i creació de l’executable del codi de les aplicacions creades. Aquest proporciona una interfície gràfica utilitzant classes predefinides per als diferents objectes típics de Windows anomenades VCL (Visual Component Library). Permet la creació de GUI, bases de dades i desenvolupaments web utilitzant C, C++.
- Microsoft Word XP:
Processador de text utilitzat per realitzar la redacció de tota la documentació referent al projecte. És el processador de text més estès i utilitzat, i el departament proporciona les plantilles necessàries per a realitzar la redacció i documentació necessària per presentar el projecte.
81
- Matlab 7.0:
S’ha utilitzat per visualitzar les dades obtingudes amb el programa d’adquisició de dades.
- Adobe Acrobat Profesional 7.0:
Programa per convertir l’arxiu .doc creat amb Microsoft Windows a arxiu .pdf. Aquest tipus d’arxiu guarda les fonts, les imatges i les presentacions dels documents creats. És un tipus d’arxiu àmpliament estès i que permet que qualsevol persona pugui veure el seu contingut amb facilitat.
82
9 Apèndix En aquest apartat s’inclou la part d’informació més específica dels components del sistema.
9.1 Cèlul·les de càrrega
En aquesta taula tenim les característiques de les cèl·lules de càrrega emprades pel nostre sistema d’adquisició.
Fig 9.1 Característiques cèl·lules de càrrega
9.2 Amplificadors d’ Instrumentació
En la taula següent es mostren les característiques principals dels amplificadors d’instrumentació proporcionats:
83
Fig 9.2 Taula de característiques dels amplificadors d’instrumentació.
De la taula podem veure que els amplificadors compleixen les condicions ideals dels amplificadors d’instrumentació força correctament. Les impedàncies d’entrada són elevades de forma que podem connectar un senyal baix sense veure’ns afectats per efectes de càrrega i mesurar d’aquesta forma una tensió real. Té un factor de rebuig del mode comú proper als 100 dB, exactament de uns 87 dB, que permetran eliminar el soroll paràsit degut als acoblaments en mode comú d’una connexió en mode diferencial. L’ample de banda podria ser un factor altament restrictiu però en aquest cas com que mostregem a una freqüència de mostreig de 1000 Hz, és a dir, que la màxima freqüència del senyal d’entrada serà de 500 Hz, un ample de banda de 2 kHz el qual no ens afecta en absolut.
9.3 Targeta d’Adquisició
Les seves principals característiques són:
- 16 entrades analògiques simples o 8 entrades analògiques diferencials seleccionables per jumper.
- Un convertidor A/D de 12-bits amb una velocitat de mostreig de fins a 40 kHz, transferència per DMA i guany independent per a cada canal.
- Valors de guany programables per software.
- Selecció del rang d’entrada analògica per software ( Bipolar ). Dos rangs a través del jumper JP7.
±10, ±5, ±2.5, ±1.25 o ±5, ±2.5, ±1.25, ±0.625
- 16 entrades digitals i 16 sortides digitals, TTL/DTL compatibles.
- Un convertidor digital a analògic de 12 bits.
- Opcions variables de dispar de la conversió: per software, per programació de la velocitat o per polsos externs.
84
En aquest cas ens interessa la part relacionada amb el convertidor analògic a digital. Les especificacions de la targeta per aquest són:
- Canals: 16 simples o 8 diferencials, seleccionables per interruptor.
- Resolució: 12 bits.
- Rang d’entrada (bipolar, Vdc): ±10, ±5, ±2.5, ±1.25
±5, ±2.5, ±1.25, ±0.625
- Sobrevoltatge: ±30V màxim.
- Tipus de convertidor: per aproximacions successives.
- Velocitat de conversió: 40 kHz màxim.
- Precisió: (±0.01 % de lectura) ±1 bit.
- Linealitat: ±1 bit.
- Format del dispar: per software, programable o per polsos exteriors.
- Transferència de dades: per programa, interrupció o DMA.
Abans de connectar la targeta a l’ordinador necessitem configurar els jumpers perquè aquesta treballi de la forma que ens interessa. La següent figura mostra la disposició dels diferents jumpers per tal de posicionar-nos damunt la targeta. Aquests jumpers es configuraran abans de connectar la targeta a l’slot d’expansió del bus ISA de la placa base.
Fig 9.3 Distribució dels jumpers i interruptors a la placa base de la targeta.
85
El switch SW1 ens permet determinar quina serà l’adreça base que utilitzarà la targeta per a les entrades i sortides del PC. Aquesta targeta necessita 16 posicions de memòria consecutives, per tant, a més de l’adreça base se li han de sumar 16 posicions més a aquesta. Saber això ens es útil per a saber si estem trepitjant llocs de memòria que utilitza un altre dispositiu. Ens permet configurar l’adreça base des de 000H fins a l’adreça 3F0H. En el nostre cas s’ha deixat l’adreça per defecte que ve configurada de fàbrica. És l’adreça 300H, amb la comprovació que no estava utilitzada per cap altre dispositiu hardware del PC. La configuració del switch es mostra a la figura 9.4.
Figura 9.4. Configuració per defecte dels interruptors dip de la placa base.
La figura 9.5 mostra una configuració típica de l’ocupació de les adreces de memòria en un PC. Aquestes adreces seran les que l’ordinador assigna als perifèrics. Nosaltres podrem utilitzar les direccions on posa Reserved. Aquestes direccions es deixen lliures expressament per els dispositius connectats als slots d’extensió de la placa base. En la figura es veu com la direcció assignada a la placa per defecte no està utilitzada per cap component perifèric. Per tant, es podrà utilitzar sense cap problema.
Figura 9.5. Ocupació típica de les adreces d’un PC.
86
El jumper JP6 ens permet configurar els canals com a entrades simples o diferencials. Per al projecte necessitem que els canals siguin d’entrada simple. Perquè les entrades de la targeta treballin en mode simple necessitem col·locar el jumper en la posició que indica la figura 9.6 de l’esquerra. Per a una configuració diferencial dels canals d’entrada haurem de col·locar el jumper en la posició que indica la figura 9.6 de la dreta.
Fig 9.6 Configuracions simple i diferencial
El jumper JP7 selecciona el rang de tensió d’ entrada del convertidor A/D. Si posiciones el JP7 a ±5 V, com mostra la figura 9.7 de la dreta, la màxima entrada que podrà suportar serà ±5 V màxim i els rangs programables són ±5, ±2.5, ±1.25, ±0.625. Si posicionem el JP7 a ±10 V, com mostra la figura 9.7 de l’esquerra, la màxima entrada permesa serà de ±10 V i els rangs programables són ±10, ±5, ±2.5, ±1.25.
Fig 9.7 Conexió a 5 i 10 V
La figura 9.8 següent mostra l’assignació de pins del connector:
Fig 9.8 Connector DB-37.
87
Per fer una connexió més senzilla i seguir un ordre entre els canals connectats utilitzarem els vuit primers canals de la targeta d’adquisició. Per fer això haurem de fer les connexions dels senyals dels amplificadors cap a la targeta mitjançant un connector DB-37 mascle. Connectarem el canal 0 amb el pin 1 del DB-37, el canal 1 amb el pin 2 i així fins al canal 7 en el pin 8. La connexió de massa es farà en els pins 9 o 10. Per tal de realitzar la connexió entre la targeta i la caixa dels amplificadors necessitem fer un cable que ens permeti arribar d’un lloc a un altre. El terminal de la caixa d’amplificadors es del tipus DB-9, per tant s’haurà de fer la conversió, quedant les connexions dels terminals de la següent manera:
Fig 9.9 Cable de conexions
Una bona connexió ens permetrà rebre i enviar senyals amb precisió. Els senyals provinents dels amplificadors són de tipus simple. Aquest sistema utilitza només un cable per a cada canal a connectar, i la referència de tots estarà connectada a la massa de la targeta. Una connexió estàndard seria del tipus:
Fig. 9.10 Conexió d’un canal en mode simple
88
Per tal d’entendre les connexions internes de la targeta i la relació entre els diferents components d’aquesta, la figura següent mostra el diagrama de blocs dels diferents elements de què està composta.
Fig. 9.11 Diagrama de blocs de la tarja
La zona encerclada mostra els principals components utilitzats per a realitzar una conversió d’analògic a digital. Com es pot veure, començant per la dreta, tenim les entrades analògiques que van directament a un multiplexor. Aquest multiplexor serà l’encarregat d’enviar cada canal al convertidor A/D. Seguidament, tenim l’amplificador de guany variable que juntament amb el multiplexor, permet realitzar mostrejos de múltiples canals a velocitats altes i amb independència de guany. Per la nostra aplicació ens anirà be poder canviar ràpidament de canal ja que necessitarem mostrejar els vuit canals de cop cada període de temps, a una freqüència de 100 a 1000 Hz. El fet del guany no ens afecta ja que tots els canals tindran el mateix guany.
Seguidament, tenim el convertidor que realitzarà la conversió del canal en aquell moment seleccionat en el multiplexor. D’aquí passarà les dades a un buffer intern compost per una memòria de tipus FIFO, des de on llegirem les dades mostrejades.
89
Per poder fer programes per a utilitzar la targeta, Advantech proporciona un rang ampli de drivers DLL. D’altra banda, també permet una programació a nivell de registres, explicats en el manual, però, com volem treballar en entorn Windows ens anirà millor utilitzar les llibreries dinàmiques proporcionades amb la targeta. Aquestes llibreries ens permeten treballar amb compiladors com el Visual C o el Borland C++ Builder. Per poder-les utilitzar s’haurà d’afegir el fitxer . lib que contindrà les funcions que es poden fer servir per portar a terme les diferents opcions que permet la targeta. Al capítol de disseny s’explica de forma més extensa aquest tema.
9.4 Programa Adquisició de Dades
Windows treballa amb un concepte anomenat ‘dynamic linking’ (connexió dinàmica) que treballa en ‘run-time’ (temps d’execució). Consisteix en uns arxius d’extensió .dll o, a vegades .exe, que contenen funcions útils per tal que el programador utilitzi els recursos del sistema operatiu per comunicar-se amb el hardware de l’ordinador. S’utilitzen, majoritàriament, per implementar les interfícies amb l’usuari i mostrar text i gràfics per la pantalla. El Windows parteix de tres biblioteques dinàmiques principals, que són:
- Kernel32.dll : gestiona els recursos de manegament de memòria, fitxers d’ E/S i control de tasques.
- User32.dll : referent a la interfície amb l’usuari ( teclat i ratolí ) i la implementació de la lògica de control de les finestres.
- Gdi32.dll : és el dispositiu d’interfícies gràfiques que permet als programes mostrar text i gràfics per la pantalla.
Les funcions que contenen aquestes biblioteques es criden igual que les funcions de C. Un aspecte important és que el codi de les funcions no s’afegeix a l’hora del linkatge, sinó que estan localitzades fora del programa, concretament en els arxius .dll o .exe. El programa de linkatge juntament amb les biblioteques d’importació crearà unes taules per a l’ executable que tindran informació sobre les biblioteques dinàmiques i les funcions utilitzades que resoldran les crides a les funcions de Windows.
Així, els programes executables .exe, tindran referències a les funcions i les biblioteques dinàmiques que utilitzarà i no el codi de les funcions.
De tot això podem dir que el programa d’adquisició necessitarà incloure les biblioteques dinàmiques citades anteriorment, ja que les necessitarem per poder fer la interfície amb l’usuari mitjançant finestres. També ens faran servei per tractar les dades provinents del teclat i el ratolí, com la gestió de memòria i l’escriptura i lectura de fitxers. El tema de l’execució multifilar ens serà útil ja que volem fer una adquisició de dades a velocitats importants i necessitarem el control absolut del sistema de manera que el Windows
90
intervingui el mínim possible. Això ho podrem fer donant-li el fil d’execució en qüestió la màxima prioritat d’execució.
9.5 Control Motor
Les dades del missatge consten d’una direcció d’esclau, codi de funció, dades de comunicació i bloc de comprovació d’error, figura 9.12.
Fig. 9.12 Format de comunicacions.
Els missatges de comunicació estan compostos totalment per dades hexadecimals. Cada missatge o resposta es divideix en blocs de 8 bits o un1 byte. Per tant, les dades s’hauran de seleccionar en blocs de 8 bits per comunicacions. Aquests missatges es divideixen en quatre àrees:
- Direcció de l’esclau: el mestre es pot comunicar amb els esclaus utilitzant aquesta direcció. Cada esclau tindrà una direcció única. El rang de direccions va des de 00 a 32 (00H a 20H), si s’emet un missatge a la direcció 00 el missatge es difondrà per a tots els esclaus.
- Codi de funció: és una comanda que conte instruccions de procés del convertidor. N’hi ha tres disponibles. La instrucció 03H, permet la lectura de dades del convertidor. La instrucció 08H que realitza la comprovació del bucle de comunicacions. I la instrucció 10H, que permet realitzar l’escriptura de dades al convertidor.
- Dades de comunicació: indicaran les direccions dels registres a llegir o a escriure, i les dades a escriure en els registres.
- Comprovació d’error: el codi de comprovació utilitzat es la resta de les dades és del tipus CRC-16. Utilitza 2 bytes per al codi.
Un aspecte important per realitzar les comunicacions és respectar una sèrie d’intervals de temps establerts pel fabricant.
Un cop el convertidor rep un missatge del mestre, llavors aquest espera un temps de 24 bits més un interval de temps determinat en el registre n156. Llavors, un cop transcorregut aquest temps, el convertidor retornarà una resposta al mestre. El valor de n156 s’utilitzarà per sincronitzar les comunicacions. La direcció d’aquest es 019C Hex i un rang entre 10 i 65 ms. La unitat de selecció es 1 ms, i, per defecte té un valor de 10 ms.
Un cop rebut el missatge de l’esclau per part del mestre, aquest s’haurà d’esperar un temps de 24 bits més un mínim de 10 ms per poder enviar el següent missatge. La figura següent representa els intervals de temps explicats.
91
Fig. 9.13 Esquema temporal de comunicacions
La següent explicació determina com realitzar els missatges i quina resposta es retorna. Cada missatge o resposta es divideix en blocs de 8 bits, per tant, les dades s’han de seleccionar en blocs de 8 bits per les comunicacions.
Per la lectura de dades, com estat de les E/S de control, monitorització de variables o valor de paràmetres seleccionats, es genera un tipus de missatge. La longitud màxima de les dades a llegir és de 16 canals ( 16 registre de 32 bytes ) per missatge. El tipus de missatge a enviar o com a resposta són els següents:
El missatge a enviar esta compost per 8 bytes a on se li passa la direcció de l’esclau, el codi de funció ( 03H de lectura ), els registre a llegir i el codi de comprovació d’error calculat prèviament.
Fig. 9.14 Missatge de lectura
Podem tenir dos tipus de respostes: la normal, que conté la direcció de l’esclau, el codi de funció, el número de dades llegit i les dades llegides; o la resposta d’error, on es rep, a més dels corresponents bytes identificatius, l’error produït. El codi de funció rebut en cas d’error és 83H, ja que si es produeix un error es posa a 1 el MSB del byte.
Fig. 9.15 Resposta normal de lectura
92
Fig. 9.16 Resposta error de lectura
L’escriptura de dades és molt semblant a la lectura. Com abans s’ha de generar un missatge específic i només es podran escriure 16 canals (16 registres). Els tipus de missatge a enviar com a resposta són els següents:
Està compost per 8 bytes on se li passa la direcció de l’esclau, el codi de funció (10H d’escriptura), els registre a escriure, les dades per a cada registre i el codi de comprovació d’error calculat prèviament.
Fig. 9.17 Missatge d’escriptura
Podem tenir dos tipus de respostes: la normal, que conté la direcció de l’esclau, el codi de funció i el numero de registres escrit, o la resposta d’error, on es rep, a més dels corresponents bytes identificatius, l’error produït. El codi de funció rebut en cas d’error és 90H, ja que si es produeix un error es posa a 1 el MSB del byte.
Fig. 9.18 Resposta normal escriptura
93
Fig. 9.19 Resposta error escriptura
Per últim, hi ha un tipus de funció que ens permet realitzar la comprovació de l’estat de les comunicacions. El missatge del mestre serà retornat per l’esclau com a resposta. Aquests missatges no seran tractats pel variador. El tipus de missatge a enviar o com a resposta són els següents:
Està compost per la direcció de l’esclau, el codi de funció, quatre bytes de dades aleatòries i el codi de comprovació:
Fig. 9.20 Misatge test comunicació
Podem tenir dos tipus de respostes: la normal, que conté la direcció de l’esclau, el codi de funció i les dades escrites; o la resposta d’error, on es rep, a més dels corresponents bytes identificatius, l’error produït. El codi de funció rebut en cas d’error es 88H, ja que si es produeix un error es posa a 1 el MSB del byte.
Fig. 9.21 Resposta normal test comunicació
94
Fig. 9.22 Resposta error test comunicació
A continuació es descriuen els registres utilitzats en comunicació per establir alguns paràmetres del convertidor. Aquests registres només s’utilitzen per comunicacions.
Fig. 9.23 Funcions entrada sortida
Els dos registres utilitzats són el 0001H (comanda RUN), que permet donar l’ordre de posar en marxa o aturar el convertidor. I el registre 0002H que permet determinar la freqüència de referència. La següent taula mostra els bits corresponent al registre de comanda RUN.
Fig. 9.24 Bits registre 001 H
95
Els següents registres són els anomenats de monitorització. Aquests permeten llegir l’estat del convertidor quan aquest està en marxa. Ens permet mirar si el convertidor està en marxa o parat, quina freqüència de referència té i quina freqüència de sortida té en aquest moment, etc.
Fig. 9.25 Registre de monitorització