Equipo Desarrollo - LBE

Depto. Física - FCEN - UBAAño 2012

Análisis y adaptación del software SensorDAQ

Laboratorio de Mecánica (I)

FECHA: 22/04/2012

R.J Padulo<padulo@df.uba.ar>

Desarrollo software para laboratorios de enseñanza Depto. Física

1

Índice general

Índice general i

1. Análisis del código fuente proporcionado por Vernier 4

1.1. Programación orientada a eventos . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2. Paradigma de orientación a objetos . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3. Implementación de la adquisición . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4. Gra�cado de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2. Análisis de factibilidad 12

2.1. Optimizando la frecuencia de adquisición . . . . . . . . . . . . . . . . . . . . . . 13

2.2. Análisis del timeout en la adquisición digital . . . . . . . . . . . . . . . . . . . . 14

3. Modi�cación del código 16

3.1. Descripción cualitativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.1. Tiempos de adquisición y timeout digital . . . . . . . . . . . . . . . . . . 16

3.1.2. Formato del trazo de grá�cos . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.3. Agregado de la función FFT . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.4. Correcciones del código . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2. Modi�caciones por nivel de anidamiento . . . . . . . . . . . . . . . . . . . . . . 17

3.2.1. Nivel 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.2. Nivel 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.3. Nivel 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.4. Nivel 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.5. Nivel 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

i

ÍNDICE GENERAL 1

3.2.6. Nivel 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.7. Nivel 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.8. Nivel 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.9. Nivel 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.10. Nivel 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3. Conclusiones y prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Bibliografía 23

Introducción

Motivados por el reemplazo de la placa de adquisición ISA MPLITM;1;[1] por los nuevosmódulos USB SensorDAQTM;[2] se plantea la necesidad de contar con un repositorio de softwareque permita adquirir con los diversos sensores disponibles en el laboratorio (principalmente sen-sor de fuerza, distancia y barreras infrarrojas).

El nuevo hardware cuenta con variados ejemplos de código fuente programados en Lab-viewTM;2;[3] para la adquisición, gra�cado y guardado de datos, siendo el programa principal elSensorDAQ. Sin embargo este software que ya es ampliamente utilizado en otros laboratorios(por ejemplo Laboratorio de Ondas, Laboratorios Avanzados y Laboratorio de Electromag-netismo) no cuenta con la posibilidad de adquisición del sensor de movimiento. Esto se debe aque la interface maneja por separado los canales analógicos (CH1, CH2, CH3 del panel frontaly AI0,AI1 de la bornera del panel posterior) y por otro los digitales (canal DIG, panel posterior).

El software citado solo implementa los canales analógicos y esta implementación, como seexplicará mas adelante, no es escalable fácilmente a los canales digitales (una versión ampliadade este software, y de carácter comercial, proporcionada por Vernier cubre estas necesidades: elLoggerProTM). De esta forma queda marcada la principal di�cultad a cubrir: la simultaneidadde medición del sensor de distancia[4] digital junto a sensores análogicos (ambos usados porejemplo en la medición de la constante k de un resorte, que utiliza el sensor de distancia y defuerza[5]). Si bien este problema fue resuelto satisfactoriamente con un desarrollo de hardwarese plantea asimismo la presente solución por software, mas económica, escalable y �exible antenuevos requerimientos.

A partir del análisis de las prácticas realizadas en el laboratorio y el nuevo hardware exis-tente se plantearon por parte de los docentes las necesidades básicas a cubrir. Se hizo especialénfasis en la continuidad de las funciones anteriormente existentes (Principalmente propor-cionadas por el software MPLITMy Precision TimerTM; para facilitar la transición y reemplazode las herramientas anteriores por las actuales.

1MPLI, SensorDAQ, PrecisionTimer y LoggerPro son productos registrados por Vernier Software & Tech-

nology.2Labview es una marca registrada de National Instruments

2

ÍNDICE GENERAL 3

A continuación se sintetizan los requerimientos planteados, detallándose los mínimos (min)y los opcionales (opc).

(min) Medición simultánea de sensor de distancia y sensores analógicos con una frecuenciade 20Hz o superior

(opc) Posibilidad de cambio del tipo de trazo del grá�co (en la versión original sólo estadisponible el trazo continuo)

(opc) Corrección de la función pre-trigger

(opc) Agregado de la función FFT

(opc) Traducción al español

Como referencia se observa el criterio utilizado por el MPLI, que utiliza como frecuenciamáxima de muestreo (condición ideal a alcanzar) para el sensor de posición un valor de 60Hz(este valor no se debe a una limitación de hardware o implementación sino a la distancia máx-ima que es posible medir en dicha frecuencia, ya que el método de medición es por retardo dela re�exión del frente de ondas de ultrasonido).

Debido a que el software SensorDAQ proporcionado con la placa de adquisición (tantoen versión compilada como código fuente) ya implementa muchas de las funciones de análisisde grá�cos presentes en el MPLI, y el uso del mismo ya se ha extendido en otros laboratorios,resulta natural plantear extensiones y mejoras en base a este mismo programa. A continuaciónse efectúa un análisis del mismo, recorriendo desde los aspectos generales a los particulares paraluego efectuar las modi�caciones necesarias que también se describen en este documento.

Capítulo 1

Análisis del código fuente proporcionadopor Vernier

A continuación se describirá el funcionamiento general del programa. Dado que se ex-plican todos los conceptos básicos de Labview necesarios para comprender el funcionamientodel código fuente no es necesario tener conocimiento de dicho lenguaje. También se orientael análisis a una interpretación del código dentro del paradigma de programación orientada aobjetos[6]. Asimismo se citan las nomenclaturas en idioma inglés para facilitar la interpretacióndel código original comentado en dicho idioma.

Debido a la extensa complejidad, anidamiento y dependencia de funciones que tiene elprograma no se explican al detalle las funciones de bajo nivel porque escapa del objetivo del pre-sente informe y oscurece la visibilidad[7] del código y la comprensión de su funcionamiento. Elanálisis exhaustivo de las mismas se efectuó y se comentó en el mismo código fuente, citándoselos motivos de cada modi�cación. Dichos comentarios son fácilmente visibles en el programapor estar en español, en contraposición al resto de los mismos que se encuentran en inglés. Enel penúltimo capítulo se listan todos los archivos modi�cados, describiéndose brevemente sufunción y la modi�cación realizada.

1.1. Programación orientada a eventos

En su estructura general el programa esta orientado a eventos y se centra en Gener-ar/Resolver los mismos, por esta razón se dice que el programa es del tipo Producer/Consumer(Events). Esto es, se maneja por un conjunto (cluster) �nito de posibles eventos creados poragentes generadores de eventos (Producer agents) y una cola en la cual se enrutan las ac-ciones asociadas a dichos eventos y que luego son procesadas por los agentes que los resuelven(Consumer agents). En el caso particular de este programa se crea un evento a partir de la

4

CAPÍTULO 1. ANÁLISIS DEL CÓDIGO FUENTE PROPORCIONADO POR VERNIER 5

interacción del usuario con los periféricos de entrada (mouse y teclado principalmente), dichoevento genera una serie de acciones que luego son procesadas y ejecutadas.

La implementación se realiza de la siguiente forma: existen dos bucles1 principales que seejecutan en �paralelo�2. En el primer bucle se procesan eventos generados por el usuario comoser click izquierdo del mouse en un botón especí�co. Este evento dispara una estructura basa-da en eventos3 que encamina hacia la cola de eventos a resolver (Queue) la acción requeridacon sus correspondientes datos de con�guración asociados. Esta acción a realizar se especi�camediante el uso de un dato del tipo enumerativo4. Posteriormente una estructura basada encasos5 procesa esta tarea ejecutando el código fuente contenido en dicho caso.

Es importante mencionar que los bucles en Labview permiten el uso de registros de de-splazamiento (Shift Registers), que permiten guardar datos y transferirlos desde un paso de laejecución del bucle al siguiente. En el bucle que gestiona eventos existen 4 variables de estetipo: �Collect button pressed� (tipo booleana, guarda el estado del botón �Collect�, presionadoo no), �Dont allow button code� (booleana, sirve como �ag para evitar que se presionen botonesde análisis del panel frontal cuando se están adquiriendo datos o realizando otras tareas incom-patibles con el análisis de datos), �ctrl ref for analog graph� (de tipo control de referencia, sirvepara almacenar una referencia a los grá�cos mostrados en pantalla) y �Mouse Move Act Curs�(de tipo entero, utilizado para el caso en el cual se selecciona una ventana dentro del grá�co dedatos, almacena la posición de la primer esquina de dicha ventana). En el caso del bucle quegestiona los casos o acciones a realizar el único registro de desplazamiento es el de la variable�Error�.

Para clari�car ponemos un ejemplo. El usuario hace click izquierdo en el botón Collect, sedispara el evento �Collect: Mouse Down� de la estructura basada en eventos, la misma agregaa la cola de eventos la tarea �RT Collect� junto a los datos de con�guración de la adquisición(cantidad de canales, tiempo de adquisición, frecuencia, adquisición de datos en tiempo real ono, etc). Posteriormente la estructura basada en casos procesa esta tarea ejecutando el códigofuente correspondiente.

A continuación se listan las acciones contempladas en el segundo bucle principal. Sedescriben aquellas acciones mas relevantes, es necesario notar que no todas las acciones están

1En Labview: click derecho en el código fuente, Programming ! Structures ! While Loop2Labview permite programar grá�camente bucles en paralelo aunque los mismos son ejecutados en un proce-

sador secuencial convencional compatible con el standard PC.3En Labview: click derecho en el código fuente, Programming ! Structures ! Event Structure. Ejemplo

de eventos: Click del mouse sobre el botón �Collect� equivale a �COLLECT�: Mouse Down, variable

numérica i cambia de valor es representado por �i�: Value Change.4Tipo de dato que puede tomar un número �nito de estados, cada estado tiene un nombre y tiene asociado

un entero que lo representa.5En Labview: click derecho en el código fuente, Programming ! Structures ! Case Structure.

CAPÍTULO 1. ANÁLISIS DEL CÓDIGO FUENTE PROPORCIONADO POR VERNIER 6

implementadas en los eventos que veremos mas adelante.

�Default�, default Se de�ne por completitud del programa pero este caso nunca esimplementado ni esta previsto que se ejecute en el funcionamiento normal del programa.

�Idle� Posición por defecto a la espera de una acción por parte del usuario. Se lee elvalor del primer canal analógico activado y se muestra dicho valor por pantalla (Esquinasuperior izquierda del grá�co).

�Initialize� Inicializa la comunicación con el modulo de adquisición SensorDAQ.

�No Connection� Veri�ca si el modulo de adquisición SensorDAQ esta conectado a laPC. En caso a�rmativo encamina en cola la acción �Iniatilize�. En este paso, y dentrode una de las funciones llamadas, se muestra un cartel de advertencia si el modulo noesta conectado a la PC. Si uno con�rma que desea continuar se repite recurrentemente elintento de veri�car el modulo conectado, en caso de cancelarse se detiene el programa.

�Reset Controls�: Mouse Down Restablece los botones a su valor por defecto, en falso(no presionados)

�Get Collection Parameters� Se ejecuta el menú de selección de canales y su respectivacalibración.

�Sensor Data From File� Deshabilita el botón �Collect� en caso que no haya ningúncanal de adquisición activado

�Change Sensor Units� Recon�gura los canales activos y grá�cos mostrados en funciónde la con�guración cargada manualmente por el usuario o la autodetección de sensores.

�Zero� Abre una ventana en la cual el usuario puede establecer el valor cero del canalseleccionado.

�RT Collect� Recolección de datos en tiempo real (para FADQ < 200Hz)

�NRT Collect� Recolección de datos en un único paquete (para FADQ > 200Hz)

�Stop Collect� Detiene la recolección de datos

�Store Latest Run� Guarda en memoria los datos de la ultima adquisición

�Clear Latest Run� Borra de memoria los datos de la ultima adquisición

�Clear All Data� Borra de memoria todos las adquisiciones

�Curve Fit� Función para ajuste de curva

�Linear Fit� Función de ajuste lineal

�Integral� Función integral

CAPÍTULO 1. ANÁLISIS DEL CÓDIGO FUENTE PROPORCIONADO POR VERNIER 7

�Examine� Muestra los datos del punto seleccionado con el cursor

�Statistics� Estadísticas sobre los datos seleccionados

�Export Data as Text� Guarda los datos en un archivo de texto

�About� Muestra un cartel con información sobre el programa

�Exit� Salir del programa

A continuación se listan los eventos contemplados en el primer bucle principal, con lanumeración utilizada en el mismo. Se añade una breve reseña de la acción que desencadenacada evento. Los eventos que encaminan en cola una acción homónima no son descriptos.

0) �COLLECT�: Mouse Down Se inicia la recolección de datos en tiempo real (acción�RT Collect�) en caso que la frecuencia de adquisición sea menor a 200Hz o la recolecciónde datos múltiples (acción �NRT Collect�) en caso de mayor frecuencia de muestreo.También se analiza la posibilidad de que el usuario este efectuando un análisis de datos,ante lo cual no comienza la adquisición hasta que el análisis se detenga, para asegurarsede no perder datos relevantes por un error del usuario.

1) �STOP�: Value Change Establece en Falso la variable booleana �Collect buttonpressed� (la misma esta almacenada en un registro de desplazamiento del bucle) y comoconsecuencia se detiene el proceso de adquisición de datos.

2) �Data Collection setup�,�COLLECT�,�Curve Fit�,�Linear Fit�,�Examine�,�Statistics�,�STOP�,�zoom�,�integral�:Mouse Enter Cambiar el color del botón que se encuentra bajo el cursor.

3) �Data Collection Setup�,�COLLECT�,�Curve Fit�,�Linear Fit�,�Examine�,�Statistics�,�STOP�,�zoom�,�integral�:Mouse Leave Restablece el color del botón que el cursor acaba de abandonar.

4) �Data Collection Setup�: Mouse Down Se encamina en cola la acción �Get Col-lection Parameters�

5) �Linear Fit�: Value Change

6) �Curve Fit�: Value Change

7) �Examine�: Value Change

8) �Statistics�: Value Change

9) �zoom�: Value Change

10) �integral�: Value Change

11) Menu Selection (user) Gestiona las opciones que el usuario selecciono desde elmenú del programa y encamina la acción correspondiente

CAPÍTULO 1. ANÁLISIS DEL CÓDIGO FUENTE PROPORCIONADO POR VERNIER 8

12)<event source>, <event source>, <event source>, <event source>, <eventsource>: Mouse Down Gestiona la posición de los clicks del mouse cuando se estánseleccionando datos sobre un grá�co

13) <event source>: Mouse Move Gestiona el movimiento del mouse sobre un grá�copara el modo de selección de datos

14) �Channel 1 Graph�, �Channel 2 Graph�, �Channel 3 Graph�, �A0 Graph�,�A1 Graph�: Mouse Up Idem al anterior

15) Panel close? Consulta si esta seguro si desea salir del programa

16) <User Event Cluster>: User Event Actualiza los datos en los grá�cos correspon-dientes

17) �Channel 1 Graph�, �Channel 2 Graph�, �Channel 3 Graph�, �A0 Graph�,�Channel 1 Chart�, �Channel 2 Chart�, �Channel 3 Chart�, �A0 Chart�, �A1Chart�, �A1 Graph�: Key Down; Mouse Down Si el usuario cambia manualmentela escala del grá�co, lo actualiza.

1.2. Paradigma de orientación a objetos

Debido a que el programa maneja una gran cantidad de datos de entrada y salida se im-plementa el encapsulamiento de los datos, creándose clases e instancias (objetos) pertenecientesa dichas clases. Cada clase tiene métodos asociados con los cuales modi�ca los atributos de lasinstancias de la clase. Para clari�car con un ejemplo concreto se tiene por ejemplo la clase�Grá�co� a la cual pertenecen las 5 instancias (grá�cos) correspondientes a los Canales 1,2,3y a las entradas Analógicas A0 y A1. Esta clase tiene una serie de métodos que permiten porejemplo escalar los grá�cos, cambiar su color, hacerlos visibles o no, etc.

En la implementación en particular que se estudia se utiliza el tipo de dato cluster, estetipo de dato permite encaminar en una única línea de datos (cableados de Labview) un númeroarbitrario de variables de diferentes tipos de datos, las mismas son leídas o escritas invocandoel nombre de la variable correspondiente6. Estas estructuras de datos son almacenadas en losregistros de desplazamiento de los bucles �While� antes mencionados. Cada arreglo de variableso cluster es modi�cado por un conjunto de funciones (métodos) implementados en forma decasos dentro de un VI.

A continuación se listan los clusters utilizados junto al nombre del grupo funcional (VI)asociado, se listan asimismo la cantidad de funciones (casos) de cada VI:

6En Labview: Functions! Programming Cluster, Class & Variant! funciones Unbundle by Name y Bundle

By Name

CAPÍTULO 1. ANÁLISIS DEL CÓDIGO FUENTE PROPORCIONADO POR VERNIER 9

User Event Cluster, de�nido por el VI �User and Dynamic Event�, utilizado por losVIs: �Initialize�, �SDAQ Collect�, �Curve Fit�, �Linear Fit�, �Integral�, �Examine� y �Stats�a través de la función �Get Event�. Se utiliza principalmente para registrar en que grá�coel usuario esta seleccionando datos y el rango seleccionado (para su posterior análisis)

Chart/Graph Cluster, modi�cado por el VI �Graph Chart Propty Module�, que im-plementa 33 métodos para darle formato a los grá�cos

Graph Refs Cluster, utilizado por los VIs: �Curve Fit�, �Linear Fit�, �Integral�, �Ex-amine� y �Stats� para procesar los datos seleccionados por el usuario sobre el gra�co yefectuar el análisis correspondiente

Los clusters �Error� y �Queue� no son analizados ya que son inherentes a Labview, soloresta explicitar que para gestionar Error se utilizan las funciones �Simple Error Handler� y�Clear Error�; para gestionar Queue se utilizan las funciones �Obtain Queue�, �Enqueue Ele-ment�, �Dequeue Element� y �Flush Queue�7.

Existen otros clusters muy importantes gestionados por el programa y que no están pre-sentes en el código principal, sino en una de las funciones anidadas en el mismo (función�SDAQ_Module2�, dentro de �SDAQ_Module�, dentro del código principal). Se trata de losclusters �Setup Parameters� y �DAQmx Task Cluster�. Los mismos son almacenados en registrosde desplazamientos dentro de un bucle �While� y almacenan la información y con�guración de laadquisición. Sobre este punto volveremos mas adelante cuando se describan las modi�cacionesrealizadas.

1.3. Implementación de la adquisición

Como se menciono anteriormente la adquisición se realiza en un función doblemente anida-da dentro del código fuente. La misma se realiza de dos formas diferentes, la primera denomi-nada �RT Collect� recolecciona datos en tiempo real (para frecuencias menores a 200Hz) y lasegunda �NRT Collect� que realiza una petición de múltiples datos y los recopila al �nalizar lamedición (utilizada para frecuencias superiores a 200Hz). La función �RT Collect� implementados variantes: �Averaging� que recopila varios puntos y los promedia para retornar solo uno conmenor ruido y la �NoAveraging� que simplemente adquiere un valor.

Existen diferencias marcadas entre la adquisición de canales analógicos y digitales. Enel primer caso se con�gura el tiempo de adquisición mediante la función �Start� que envía alhardware la principal con�guración: el tiempo entre mediciones y el modo de disparo. Cuando elmismo es de disparo externo y sincrónico, la misma se realiza a intervalos regulares, comenzando

7Todas estas funciones son descriptas en la documentación �Help� de Labview.

CAPÍTULO 1. ANÁLISIS DEL CÓDIGO FUENTE PROPORCIONADO POR VERNIER10

cuando se detecta un �anco ascendente o descendente (según la con�guración establecida) enel canal correspondiente. También puede lograrse una medición asincrónica, donde cada datose adquiere cuando se detecta el mencionado �anco.

En el modo mas simple y de uso extendido se con�gura en modo sincrónico y de comienzoestablecido por el usuario (al hacer click en �Collect� desde el panel frontal del programa). Eneste caso a intervalos regulares el hardware adquiere una medición analógica, efectúa la conver-sión y almacena el dato en un bu�er. El programa es responsable de requerir el dato a intervalosregulares, mostrarlo en pantalla y en caso de ser requerido guardar dichos datos. La ventaja deeste modo de operación es que si se con�gura un bu�er extenso los tiempos del programa noson críticos, si se produce una demora de procesamiento (por ejemplo por sobrecarga del proce-sador) el mismo puede pedir reiterados datos y actualizar rápidamente el gra�co, visualmenteesto se ve incosistente ya que varios datos son mostrados rápidamente, pero dado que cadamedición se toma con el clock interno de hardware esto asegura que cada dato fue adquirido enun tiempo correcto y no se producen deformaciones de la onda por asincronismo de la medición.

En cambio la adquisición digital se produce in situ. Es decir es el software el principalresponsable de generar los retardos entre cada medición, la cual se realiza emitiendo un pul-so de ultrasonido y aguardando su eco. Esto no es efectuado automáticamente y a intervalosregulares por el hardware sino que el software pide cada medición y debe esperar su resultado,no pudiéndose generar perdidas de procesamiento o comunicación de datos por parte de laPC. Este es el principal factor limitante a la momento de implementar frecuencias de medicióncercanas al valor óptimo esperado de 60Hz.

Existe además del bu�er de hardware, un bu�er de software que permite ir almacenandoen memoria diferentes adquisiciones, las cuales son mostradas simultáneamente en cada gra�co.Posteriormente las mismas pueden ser almacenadas en un archivo para su análisis.

Habiendo analizado extensamente el código se cuentan con las herramientas para pros-eguir en el análisis de la factibilidad de implementación de las modi�caciones requeridas. Espreciso notar que la gestión de detección de sensores (realizada por la función �Create SensorList�) esta protegida con contraseña por lo que su código fuente no es accesible. Esto di�culto elanálisis y fueron necesarias varias pruebas para inferir el modo de operación de dicha función.Esto se realizo estudiando el espacio de entrada y salida de la función.

1.4. Gra�cado de datos

Es importante notar que para cada canal existen dos tipos de grá�cos, los estáticos (imple-mentados con �Graphs�) y los dinámicos (implementados con �Charts�). Durante la adquisición

CAPÍTULO 1. ANÁLISIS DEL CÓDIGO FUENTE PROPORCIONADO POR VERNIER11

dinámica en tiempo real se actualizan de los grá�cos dinámicos en cada iteración de la adquisi-ción. Al �nalizar la misma estos datos son volcados a los grá�cos estáticos y almacenados enel canal de datos correspondiente. En caso que se desee guardar la adquisición en memoria losmismos serán mostrados tanto en los grá�cos dinámicos como estáticos, y la nueva adquisiciónse hará con un color de trazo nuevo para diferenciarla de la anterior. Todos los datos visualiza-dos y adquiridos en diferentes corridas pueden ser almacenados en un único archivo ejecutandola opción correspondiente en el menú.

Capítulo 2

Análisis de factibilidad

Para evaluar la factibilidad de la implementación de una adquisición simultanea del sen-sor Motion Detector junto a canales analógicos se planteo la necesidad de estudiar la formade trabajo del hardware SensorDAQ. La frecuencia de adquisición del mismo no es un factorlimitante pero si podrían serlo la escalabilidad del programa y sobre todo la posibilidad degestionar con una alta velocidad las peticiones de dos tareas completamente diferentes: una demedición de tiempos de retardo digital y otra de conversión analógica digital de un canal deentrada. La existencia de un software comercial (LoggerPro) de la �rma que permitiera realizaresta adquisición simultanea no deja duda de que el hardware lo permite, lo que no estaba com-pletamente determinado es si con el repositorio de funciones proporcionados por la misma �rmaesto era posible. Claramente podría existir la posibilidad de que al ser un producto closed sourceno se proporcionaran todas las funciones que permitieran explotar al máximo el hardware.

En primer lugar se efectuaron pruebas básicas de medición simultanea, el primer prob-lema evidente fue que con la función �SensorDAQ_Setup�1 proporcionada no estaba previstala adquisición simultanea y una con�guración de detección del Motion Detector interfería conla medición en canales analógicos. Adquirir una medición con el Motion Detector, recon�gu-rar y adquirir luego una medición analógica no fue una opción viable por la escasa frecuen-cia lograda (10 a 20Hz). Un posterior análisis del código �SensorDAQ_Setup� y extensivaspruebas determinaron la con�guración óptima requerida: un inicio de todas las funciones delSensorDAQ (implementado con la función �Start�) junto a la modi�cación manual del cluster�Setup Parameters�, especí�camente en la variable enumerativa �Con�g. DIG Ch.�!�Con�gDIG Channel(OFF)�, establecido su valor en �Motion detector�2. Estas primeras pruebas per-mitieron recolectar simultáneamente tanto digital como analógicamente a una frecuencia de30Hz, superior a los requerimientos. Se observo que para mayores frecuencias existía un excesoen el tiempo dedicado a cada medición, por ejemplo si se establecían 10 segundos de medición

1nSensorDAQnSensorDAQ Driver VisnSensorDAQ_Setup.vi2Pueden explorarse todas las opciones disponibles en el archivo �nSensorDAQnSensorDAQ Driver

VisnSensorDAQ_Start.vi�

12

CAPÍTULO 2. ANÁLISIS DE FACTIBILIDAD 13

se completaba la misma en 15seg. lo cual indicaba claramente un problema de excesivo tiem-po de cada medición individual. Sin embargo, buscando cumplir o superar las especi�cacionesdel hardware anterior (MPLI) se continuo el análisis para lograr una frecuencia mínima de 60Hz.

2.1. Optimizando la frecuencia de adquisición

Dado que en las pruebas preliminares se obtuvo un valor cercano a los requerimientos perosin el su�ciente margen de seguridad, y considerando que el nuevo hardware debe cumplir comomínimo las especi�caciones del antiguo se continuaron las mediciones y pruebas para mejorarla frecuencia de adquisición.

En primer lugar se observo detenidamente como es el proceso de retardo entre cada medi-ción, analizando los ejemplos de adquisición con el Motion_Detector3 y adquisición de un canalanalógico4 se observo una diferencia fundamental: el canal analógico administra por hardwareel retardo entre cada medición, este valor se con�gura antes de comenzar la adquisición yel software pide posteriormente de a un solo dato por vez, asegurándose de pedirlo antes deque el mismo este disponible (asignándose un tiempo limite timeout) para la comunicación deeste dato); mientras que para el canal digital se administra por software el tiempo entre cadaadquisición, dándose un timeout de 1=Freq para la adquisición del dato (en caso de que ladistancia sea mayor al rango para esa frecuencia la función devuelve un valor nulo). También seobservo una anomalía en el comportamiento de la función de adquisición digital en lo relativoal timeout, lo cual sera analizado en la próxima sección.

Con lo observado se plantearon 3 tiempos que deben ser en suma, menores al periodo dela adquisición:

1) Tiempo de ejecución de código (por ejemplo gra�cado del punto adquirido en pantalla,movimiento del mouse, etc)

2) Tiempo de adquisición del canal analógico

3) Tiempo de adquisición del canal digital

Lo que se pretende por supuesto para maximizar el rango del Motion Detector (maxi-mizando el tiempo citado en el ultimo punto). Analizaremos el caso limite de una frecuencia de60Hz para la cual se cuenta con 16,6ms para cada medición.

3nSensorDAQnEXAMPLESnDIG ChannelnDIGEx09_MotionDetector.vi4nSensorDAQnEXAMPLESnAnalog ChannelsnAnalogInEx01_Ch1.vi

CAPÍTULO 2. ANÁLISIS DE FACTIBILIDAD 14

Para el primer item se realizo una corrida de 10.000 ciclos del bucle de programa sinadquirir ningún dato y simulando un valor �jo de entrada de 5V en el canal 1, para evaluarsolamente el tiempo que demora el programa en actualizar los grá�cos y variables de entorno.El tiempo total fue de 8,5seg. por lo que el tiempo de cada ciclo resulta menor a 1ms.

Para el segundo punto se analizo la con�guración de inicialización de la placa, encontrán-dose que para el modo no promediado el reloj se establece con una frecuencia igual a la pedidapor el usuario (FADQ) mientras que en el modo promediado se establece una frecuencia de5000Hz y la cantidad de puntos promediados por medición resulta 5000/FADQ. Es decir en esteultimo el tiempo de adquisición por medición es de 0,2ms. Hay que resaltar que el programapide una muestra luego de que la misma haya sido medida y que el tiempo de adquisición delcanal analógico por lo tanto es despreciable pues mientras se realizan otras tareas en el progra-ma el SensorDAQ adquiere el dato y lo deja disponible en el bu�er, el proceso de petición deldato por parte del programa y su transmisión por parte del SensorDAQ es mucho menor a 0,2ms.

Finalmente se adopta un valor conservador de 1ms para la ejecución del ciclo de programay adquisición del canal analógico, obteniendose 13,6ms para la medición de distancia. Por lotanto se establece como timeout para la adquisición del canal digital un valor de 1=FADQ�3ms.

Luego de este punto se plantea la elección de adquisición en modo �Averaging� o �NoAver-aging�. Dado que algunas pruebas preliminares mostraban algunas fallas en el modo promediadocuando se utilizaba el Motion Detector, se modi�co la frecuencia original, estableciéndose la mis-ma en 1000Hz y resultando la cantidad de muestras promediadas en cada medición 1000=FADQ.

2.2. Análisis del timeout en la adquisición digital

Debido a que se observo un comportamiento anómalo de la función de adquisición detiempo de retardo digital, (utilizado para medir el tiempo de retorno del �anco de ultrasonido)la misma se estudió con mayor detalle. Partiendo del ejemplo de adquisición del Motion Detec-tor se estableció una cantidad de muestras �jas en 300, se anuló el retardo entre mediciones (deforma que en cuanto �nalice una medición de distancia comienza inmediatamente la siguiente)y se agregó la posibilidad de un timeout a elección. Dado que el timeout se establece como1=FADQS, lo razonable seria que si se mide a 60Hz (timeout para cada medición de 16,6msaprox) y si se mide siempre una distancia excesiva para cada invocación de la función deberíatranscurrir un tiempo de 16,6ms y �nalizar con un error por timeout, por lo que la adquisiciónen total durará 16,6ms*300 = 5seg. Se observó que esto no era así, sino que el tiempo transcur-rido fue muy superior a 5seg.

Para cuanti�car esta discrepancia se realizaron pruebas de medición de 300 muestras con

CAPÍTULO 2. ANÁLISIS DE FACTIBILIDAD 15

TMOUT (ms) TESPERADO(seg) TTOT (seg) TMOUTcalculado (ms)9 2,7 4,42 14,73ms10 3 4,71 15,7ms11 3,3 4,98 16,6ms12 3,6 4,42 18,06ms

Figura 2.1: Estimación del timeout real en el caso de una distancia excesiva. Se adquirieron 300en todos los casos. Existe una discrepancia entre el timeout asignado y el tiempo de �nalizaciónde la función.

diferentes timeouts, midiéndose el tiempo total de medición y calculándose un timeout equiv-alente a dicho tiempo (TTOT=NMUESTRAS). Los resultados se observan en la Figura 2.2. Comose puede apreciar cuando el Motion Detector no recibe un retorno de �anco en menor tiempoque el timeout el tiempo que tarda la función en �nalizar es alrededor de un 63% mayor a suvalor normal. Esto supone una gran di�cultad ya que es posible que el usuario este utilizandoel Motion Detector incorrectamente y mida simultáneamente un canal analógico. Esta excesivademora de retorno de la función hace que se produzca una falta de sincronismo de la medicióndel canal analógico ya que cuando la función del canal digital se resuelve ha pasado el tiempoen el cual hay que solicitar la medición analógica, y como el programa asume que ese tiempoes regular se corre el riesgo de obtener datos correctos pero asincrónicos. La solución a esteproblema se discutirá en el próximo capitulo.

Finalizada la caracterización de los tiempos de adquisición digital y analógica, y con-siderando que es posible alcanzar los requerimientos mínimos se procede a la implementaciónde las modi�caciones necesarias y su posterior optimización para elevar el standard y presta-ciones del software.

Capítulo 3

Modi�cación del código

3.1. Descripción cualitativa

Luego de efectuar un análisis del código fuente desde los niveles mas generales a los par-ticulares, y habiendo realizado pruebas extensivas sobre los tiempos de adquisición contamoscon las herramientas e información necesaria para implementar las modi�caciones requeridas.La �losofía de trabajo fue expandir y utilizar todos los canales de datos disponibles en el pro-grama, aprovechando las funciones existentes que los gestionan. Esto nos brinda numerosasventajas, deja un código visible y que no se aparta de la codi�cación original, con el objetivo deque ulteriores modi�caciones mantengan este standard y una vez comprendido el código fuenteoriginal inmediatamente se entiende asimismo cualquier modi�cación posterior, puesto que lamisma entra exactamente en el mismo esquema de trabajo.

A continuación se listan las modi�caciones realizadas.

3.1.1. Tiempos de adquisición y timeout digital

Para el problema del excesivo tiempo de respuesta de la función de adquisición de retar-dos digitales (mayor al timeout esperado) se plantearon diversas estrategias. Si bien es posibledetener la adquisición cuando se supera un numero dado de mediciones incorrectas, o cuandose registre un excesivo tiempo de medición esto haría que el programa sea menos robusto. Porlo que se decidió utilizar la siguiente estrategia: cuando el canal digital �naliza la adquisicióncon un error de timeout en el paso siguiente no se adquiere el mismo, sino que se adquiere soloel canal analógico. De esta forma cuando se supera la distancia máxima por un corto periodode tiempo o permanentemente (supongamos el caso extremo de con�gurar la adquisición delMotion detector y no tenerlo conectado o dejarlo apartado sin usarlo) la medición de los canalesanalógicos no pierde sincronismo, lo cual hace que el programa sea robusto y con�able.

16

CAPÍTULO 3. MODIFICACIÓN DEL CÓDIGO 17

3.1.2. Formato del trazo de grá�cos

Se cumplió con el requerimiento opcional de la elección del formato del trazo de cada gra�-co (continuo o por puntos), agregándose una función al conjunto de funciones �Graph ChartPropty Module�. La opción de formato se almacena en la variable booleana �Mostrar puntos�.

3.1.3. Agregado de la función FFT

Para mantener las funciones del software anteriormente utilizado (MPLI) se agrego lafunción FFT, la misma se integro al conjunto de funciones de análisis existente en el Sensor-DAQ. De esta forma trabaja exactamente igual que el resto de las funciones, se elije un rangode datos y se aplica la función de análisis. La forma de onda resultante luego de efectuarse latransformada rápida de Fourier se pueden almacenar en un archivo para su posterior análisis oel gra�cado e inclusión de los datos en un trabajo practico.

3.1.4. Correcciones del código

Se corrigieron algunos errores mínimos de cableado, por ejemplo en los items de análisisde datos del bucle de eventos faltaba cablear las referencias a los grá�cos. Se corrigió el iconode �Data Collection Setup� que presentaba una linea blanca que no acompañaba el resto deldiseño general del programa. Se corrigió la función de �Pre-Trigger� que no se comportaba cor-rectamente ya que había que esperar un tiempo igual al de la adquisición para poder dispararel comienzo de la misma.

3.2. Modi�caciones por nivel de anidamiento

En esta sección se listan todos los archivos modi�cados, se hace una breve descripción delgrupo funcional contenido en el archivo, los motivos de la modi�caciones y una descripción delas mismas. En todos los archivos en los cuales se almacenan mensajes al usuario se conservola leyenda en ingles dentro del código y se agregaron las leyendas en castellano. Para podervisualizar las funciones modi�cadas y su nivel de anidamiento se puede ingresar al menú View! Show VI Hierarchy, luego haciendo click derecho sobre el VI principal seleccionar Show AllSubVIs. Las funciones modi�cadas tienen una marca distintiva que las identi�ca. Las funcionesse ubican en el nivel mas alto que las puede invocar, por ejemplo una función de nivel 9 puede

CAPÍTULO 3. MODIFICACIÓN DEL CÓDIGO 18

ser invocada desde los niveles 8,7,6,1, etc.

3.2.1. Nivel 0

SDAQ Data Collection VI.vi Archivo principal del programa, en el mismo se observatoda la estructura explicada anteriormente. Se agregó el gra�co del Motion Detector al clusterque gestiona los Charts y Graphs y se agrego el gra�co al arreglo de Graphs. Se agregó lacarga de una calibración por defecto para el Motion Detector y una inicialización de la variable�Mostrar Puntos� que almacena la con�guración de formato del trazo del grá�co. Asimismopara esta nueva función se agregó el evento y el caso �Mostrar puntos� que es activado por elcontrol correspondiente en el menú del programa.

3.2.2. Nivel 1

LinuxPro_Functions.ctl De�nición del enumerativo que lista las acciones manejadaspor la estructura basada en casos (ver Capítulo 1), se agregaron los items �Mostrar puntos�y �Calcular FFT�.

MouseDownRegistering.vi Función que gestiona el cluster de almacenamiento de lasreferencias al número de grá�co donde el usuario está ubicado o hace click. Se agregó ladetección de la posición del cursor y click para el grá�co Motion Detector.

SDAQ_Initialize.vi Función de inicialización del hardware SensorDAQ y formato delos grá�cos. Se agregó la con�guración del tipo de trazo según la con�guración establecidapor el usuario.

UserAndDynamicEvent.vi Función de gestión del cluster de almacenamiento de even-tos generados por el usuario. Se agregó el registro de la posición del mouse y clicks en elgrá�co �Motion Detector�.

SDAQ_FFT.vi (creado) Nueva función de cálculo de la transformada de Fouri-er. La misma puede ser invocada por el usuario haciendo click en el iconocorrespondiente, junto al botón �Collect�.

3.2.3. Nivel 2

SDAQ_Module.vi Esta función es la principal y más importante modi�cación real-izada. Aunque es sencilla para lograrla se hicieron extensas pruebas de diferentes com-

CAPÍTULO 3. MODIFICACIÓN DEL CÓDIGO 19

binaciones de con�guraciones e inicializaciones del modo de medición. Las principalesmodi�caciones se observan en el modulo �Start� donde se con�gura la placa para laadquisición, modi�cándose el cluster �Setup Parameters�; y en el modo �RT Collect�,donde se adquieren los canales analógicos y luego el digital, estableciéndose su timeoutcomo se describió anteriormente.

Chart Graphs Properties_Module.vi Se modi�caron las 33 funciones que gestionanpropiedades de los grá�cos para agregar el grá�co �Motion Detector�. Se agregó una nuevafunción que permite mostrar puntos y lineas o solamente lineas. Se modi�caron algunasfunciones que usaban el grá�co del Canal 1 como variable para almacenar con�guraciones,ya que esto impedía implementar la función de formato de linea o punto, para reemplazareste esquema de trabajo se introdujo una variable global.

BuildDataArray.vi Se agregó el canal de datos del sensor Motion Detector, para estofue necesario modi�car todas las funciones que manipulan estos datos, creando un nuevocanal para dicho sensor.

FFT_Popup.vi (creado) Se creó la ventana que muestra la transformada rápida deFourier (FFT).

3.2.4. Nivel 3

Chart Graph Properties_Functions.vi De�nición del enumerativo que lista los méto-dos aplicados a los grá�cos. Se agregó el item �Chart Graph Mostrar Estilo de Punto�.

SetChartPosition5.vi Función de posicionamiento de los grá�cos dinámicos. Fue agre-gada la con�guración del gra�co �Motion Detector�.

SetChartGraphsScales.vi Función de con�guración de las escalas de los grá�cos apartir de la con�guración establecida para cada canal de adquisición. Fue agregada lacon�guración del grá�co �Motion Detector�.

SetChartGraphsLegend.vi Método de con�guración de las leyendas de los grá�cos es-táticos y dinámicos a partir de la con�guración establecida para cada canal de adquisición.Fue agregada la con�guración del grá�co �Motion Detector�.

SetChartGraphsScalesFromParams.vi Función de con�guración de las escalas delos grá�cos a partir de la con�guración establecida para cada canal de adquisición. Fueagregada la con�guración del grá�co �Motion Detector�.

ChartScaleFromGraphScale.vi Función de copia de las propiedades de los grá�cosestáticos hacia los dinámicos. Fue agregada la con�guración del grá�co �Motion Detector�.

CAPÍTULO 3. MODIFICACIÓN DEL CÓDIGO 20

GraphScaleFromChartScale.vi Función de copia de las propiedades de los grá�cosdinámicos hacia los estáticos. Fue agregada la con�guración del grá�co �Motion Detector�.

GraphSetCursorMaxMin.vi Establece la posición de los cursores en el inicio y �naldel gra�co, de esta forma al generar un análisis el mismo por defecto se efectúa sobre latotalidad de los datos adquiridos. Se agrego el grá�co �Motion Detector�

GraphSetCursorMaxMinZoom.vi Idem que la función anterior pero teniendo encuenta el incremento en la escala de los grá�cos.

SetGraphScaleColor.vi Función que permite mostrar u ocultar las escalas para losgrá�cos estáticos (alterna entre color blanco o negro). Fue agregado el grá�co �MotionDetector�.

Graph Data_Module.vi Método de gestión de los datos guardados en memoria. Seagregó el grá�co �Motion Detector� y el canal de datos correspondiente.

3.2.5. Nivel 4

Reference cluster.ctl Cluster de referencia a los grá�cos estáticos y dinámicos. Fueagregado el grá�co estático y dinámico �Motion Detector�.

SensorDAQ_DataCollectionPopup Función de con�guración de los tiempos de medi-ción y número de muestras por segundo. Fue agregada la restricción de 60Hz máximo parael Motion Detector.

SensorDAQ_CalibrationFilePopup Función de calibración de los canales activos ysus unidades, fue agregada la solapa �DIG Channel� que permite activar el Motion De-tector. Al momento de la activación carga automáticamente una calibración por defecto,pero permite cargar desde un archivo o generarla manualmente.

3.2.6. Nivel 5

Calibracion_Motion_Detector.vi (agregado) Función de calibración del sensor demovimiento, permite medir 2 tiempos de retardo y asignarle a cada uno una distancia.Luego se efectúan los cálculos que permiten determinar los coe�cientes de calibración delsensor.

3.2.7. Nivel 6

SensorDAQ_Setup_only_motion_detector (agregado) Debido a que al realizarla calibración automática es necesario utilizar el sensor de movimiento, el mismo debeser con�gurado con la función �Setup�. Esta función invoca a la función �Modify�, dentro

CAPÍTULO 3. MODIFICACIÓN DEL CÓDIGO 21

de la cual esta la misma función de calibración por lo que Labview detecta un llamadorecurrente de autoinvocación y no permite ejecutar el código. Por esta razón fue necesariomodi�car la función �Setup� para evitar esta recurrencia, eliminando la invocación a lafunción �Modify�.

3.2.8. Nivel 8

SensorDAQ_ReadSinglePt.vi Función de adquisición de un dato de cada canal analógi-co. Se modi�có para contemplar la posibilidad de un timeout en la lectura del canalanalógico debido a un excesivo retardo de la función de adquisición digital.

3.2.9. Nivel 9

SensorDAQ_AverageSinglePt.vi Cuando el Motion Detector esta activado se modi-�co la frecuencia de adquisición del modo promedio de 5000 a 1000.

3.2.10. Nivel 15

SensorDAQ_Con�gAITask.vi Función de con�guración de la adquisición a bajo niv-el. Se programa el tiempo entre cada medición, diferenciándose los casos �RT Collect� y�NRT Collect�. En el primer caso se discrimina la con�guración por �Averaging� o �NoAv-eraging�. Cuando el Motion Detector esta activado se modi�có la frecuencia de adquisicióndel modo promedio de 5000 a 1000.

3.3. Conclusiones y prueba

Finalmente se obtuvo un código que conserva las propiedades del original. Continua sien-do visible, escalable y robusto. Se corrigieron algunos errores de estilo y funcionales. Si biense realizo en test exhaustivo durante todo el proceso de modi�cación se deben continuar laspruebas para adaptarse a las necesidades del usuario.

Para probar el sincronismo entre la adquisición digital y analógica se procedió a conectaren Canal 1 a una señal senoidal que excitaba, mediante un ampli�cador, a un desplazadorvertical. El sensor de movimiento registraba el desplazamiento mientras el Canal 1 registrabala tensión aplicada. La frecuencia de adquisición se estableció en 60Hz y la frecuencia de laseñal en 1Hz aproximadamente (del orden de la utilizada en las practicas convencionales dedesplazamiento con resorte). Los resultados se observan en la Fig. 3.1. También se efectuó una

CAPÍTULO 3. MODIFICACIÓN DEL CÓDIGO 22

medición a 7Hz como se observa en la Fig. 3.2. Como se puede apreciar el sincronismo es correc-to entre ambas mediciones, esto se logro gracias al análisis de tiempos de adquisición explicadoanteriormente.

Figura 3.1: Medición simultánea de tensión y distancia a 60Hz. Frecuencia medida de 1Hzaprox.

Figura 3.2: Medición simultánea de tensión y distancia a 60Hz. Frecuencia medida de 7Hzaprox.

Bibliografía

[1] Claudio Iemmi Cómo trabaja la MPLI? ; Depto. Física, FCEN.

[2] Vernier Technology SensorDAQ - User Manual ; 2010.

[3] National Instruments Labview 8.5 - User Manual ; 2008.

[4] J. Padulo Caracterización del sensor de posición de la �rma Pasco; Depto. Física, FCEN,Julio, 2008.

[5] Cátedra Chimento Guia 6 - Elasticidad - Laboratorio Física 1 (Química); Depto. Física,FCEN, 2011

[6] David J. Eck, Anban Pillay Object-Oriented Programming ; February 5, 2007

[7] Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli Fundamentals of Software Engineering ;Prentice Hall, 1991

23