sergi molina mellado control telemÁtico de ...deeea.urv.cat/public/propostes/pub/pdf/2175pub.pdf2...

Sergi Molina Mellado

CONTROL TELEMÁTICO DE EQUIPOS DE TEST CLIMÁTICO EN ENTORNO LABVIEW

TRABAJO FINAL DE GRADO

dirigido por el Prof. Pedro Iñiguez Galbete Ponente: Marc Teruel

Grado de Ingenieria Electrónica Industrial y Automá tica

Tarragona

2014

2

Agradecimientos

Quiero agradecer a mi familia por apoyarme siempre en mis decisiones, a los tutores Marc

y Pedro por ayudarme en la realización del trabajo y a la empresa Lear, lugar donde se me

dio la oportunidad de realizar este proyecto.

3

Índice

1 Introducción ................................................................................................................... 4

2 Justificación .................................................................................................................... 5

3 Objetivos ........................................................................................................................ 7

4 Desarrollo e Implementación ......................................................................................... 8

4.1 Las Cámaras Climáticas .......................................................................................... 8

4.1.1 ¿Qué Es una Cámara Climática y para Qué Sirve? ......................................... 8

4.1.2 Tipos de Cámaras ............................................................................................ 9

4.1.3 Localización de las Cámaras Climáticas ....................................................... 11

4.1.4 Comunicación con las Cámaras ..................................................................... 12

4.2 LabVIEW .............................................................................................................. 18

4.2.1 ¿Qué Es LabVIEW? ...................................................................................... 18

4.2.2 ¿Por qué LabVIEW? ...................................................................................... 19

4.3 Estructura del Software ......................................................................................... 20

4.4 Adquisición y Decodificación de los Datos .......................................................... 22

4.4.1 Cámaras ACS ................................................................................................ 22

4.4.2 Cámaras Vötsch ............................................................................................. 39

4.5 Compartir los Datos .............................................................................................. 60

4.5.1 Escritura en las Variables de Red .................................................................. 61

4.5.2 Lectura de las Variables de Red .................................................................... 63

4.6 Visualización de los Datos (Interfaz Gráfica) ....................................................... 63

5 Próximos Pasos ............................................................................................................ 69

6 Conclusiones ................................................................................................................ 70

7 Bibliografía................................................................................................................... 71

8 Anexos .......................................................................................................................... 73

8.1 Anexo A ................................................................................................................ 73

8.2 Anexo B ................................................................................................................ 82

8.3 Anexo C .............................................................................................................. 110

8.4 Anexo D .............................................................................................................. 136

8.5 Anexo E .............................................................................................................. 146

4

1 Introducción

El Laboratorio de Lear Corporation en Valls, empresa donde se ha llevado a cabo este

proyecto, cuenta con alrededor de 20 equipos de test climático repartidos en diferentes

edificios para poder reproducir las condiciones ambientales en los sistemas y componentes

electrónicos de un automóvil. En general, los ensayos climáticos consisten en exponer un

número concreto de muestras de módulos electrónicos, a unas condiciones de estrés de

temperatura, humedad y vibración extremas, para que mediante estas simulaciones

climáticas y de funcionamiento, se pueda asegurar que los estos módulos cumplirán con su

función a lo largo de toda la vida útil de un vehículo.

Lo que se pretende hacer en este proyecto, es crear una red telemática para poder

monitorizar mediante una interfaz, las diferentes cámaras climáticas del Laboratorio sin la

necesidad de estar delante. Esta interfaz deberá poderse instalar en cualquier PC que se

encuentre dentro de la empresa, para que así el técnico de laboratorio pueda acceder a un

equipo de trabajo concreto de forma remota, y leer su estado y valores de consigna para

confirmar que el test que se está llevando a cabo continúa sin problemas.

5

2 Justificación

Tal y como se ha comentado en el apartado anterior, este proyecto se ha realizado

íntegramente en la empresa Lear Corporation. Ésta es una importante multinacional

dedicada al diseño y fabricación de electrónica para el automóvil, la cual tiene una gran

cantidad de plantas repartidas por todo el mundo. Dentro de las plantas que se encuentran

en Europa, Lear Corporation EPMS ubicada en Valls, es la única que se ocupa del diseño,

desarrollo y producción de todo tipo de tecnologías electrónicas aplicadas a la automoción,

como es el control de los diferentes sistemas eléctricos y electrónicos, la conexión y

multiplexación de cableado y conectores, y también la aplicación de nuevas tecnologías.

Además, en la planta de Valls, se encuentra el único Centro Tecnológico de investigación y

desarrollo de Lear en Europa.

Así pues, como empresa líder en su sector, Lear Corporation tiene que cumplir un altísimo

estándar de calidad para satisfacer a los clientes con sus productos. Para poder dar un

producto y/o servicio de esta calidad, es importante optimizar todo el proceso de

fabricación, garantizando su correcto funcionamiento al mismo tiempo que se cumplen las

normativas y especificaciones correspondientes.

El proceso de fabricación de cualquier producto electrónico pasa por dos fases claramente

diferenciadas:

La primera de ellas es la fase del diseño. En ésta, el producto se encuentra en vías de

desarrollo, y no se dispone de un producto acabado, sino de un prototipo.

Y la segunda fase, es cuando el producto ya está acabado, y se encuentra en fase de

producción. El producto ya ha superado la fase de diseño, ha estado homologado y puede

ser fabricado en serie.

A continuación se muestra un esquema con las fases y sus etapas:

Figura 1: Esquema del proceso de fabricación de un producto

Este proyecto se contextualiza dentro de la fase de diseño, más concretamente en la etapa

de validación, que está marcada en rojo. En ésta, el prototipo es validado por los diferentes

departamentos donde se desarrolla, pero para poder ser producido en serie éste tiene que

ser validado y homologado por el departamento llamado Laboratorio de ensayos y

homologación. En el Laboratorio se llevan a cabo todo tipo de ensayos sobre el producto

que son requeridos por el cliente según unas normativas a nivel internacional. En estos test,

los prototipos se exponen a varias condiciones de entorno, como por ejemplo: cambios de

temperatura y humedad, exposición a líquidos, ensayos de vibración, compatibilidad

electromagnética,… simulando entornos agresivos a los cuales se pueden encontrar éstos

durante la vida del vehículo.

6

Para simular estos entornos y realizar dichas pruebas/ensayos son necesarias las cámaras

climáticas. Éstas están repartidas en diferentes zonas, y en ocasiones, pueden estar

relativamente lejos del lugar de trabajo habitual, por lo tanto cada vez que se quiere

comprobar el estado de dichas cámaras per ver si continúan funcionando de forma correcta,

el usuario tiene que desplazarse, con la consiguiente pérdida de tiempo y la interrupción en

el flujo de trabajo, disminuyendo así productividad y eficiencia.

Actualmente hay principalmente dos zonas diferenciadas. La primera de ellas es el

laboratorio que se encuentra en el edificio del CTE (Centro Tecnológico Europeo) donde

están alojadas la mayoría de las cámaras climáticas, y la segunda se encuentra en otra nave

aparte situada a unos 500 metros de lo que es el núcleo principal. Aunque no se descarta

que en un futuro próximo este número de zonas pueda aumentar, ya que se quieren realizar

ampliaciones en lo que respecta al número de equipos climáticos, y en los lugares actuales

el espacio disponible ya está muy limitado.

Otro punto derivado del hecho de tener que desplazarse, es la corrección de posibles

errores en los equipos. Como es necesario estar delante para ver el estado, en caso de que

produzca un fallo en alguna de las cámaras (apertura de la puerta accidentalmente, fallo en

compresor, falta de agua para humidificación, etc.), no nos será posible notificarlo de

manera inmediata, sino que pueden llegar a pasar días hasta que nos demos cuenta de que

se ha producido un error, por lo que se perdería tiempo útil de trabajo con ese equipo,

tiempo que podría haber invertido otro usuario, o que se podría haber utilizado para la

reparación de la misma.

Es de aquí donde surge la necesidad de crear un proyecto con las aplicaciones necesarias

que permitan subsanar estos puntos de la forma más efectiva, así como también de tener un

mayor control sobre que cámaras están libres y cuáles no, para que un usuario pueda saber

cuándo poder ejecutar sus test y así organizarse de forma más eficiente con otros

compañeros.

Hasta el momento de empezar a trabajar en este proyecto, no se había contemplado

ninguna posibilidad ni se había iniciado ninguna investigación sobre de como emprenderlo

y sobre qué pasos, por lo que se tuvo que empezar desde bien el inicio contemplando todas

las posibilidades.

7

3 Objetivos

En este trabajo de final de carrera se quiere conseguir crear una serie de aplicaciones

que permitan la correcta monitorización de cualquier cámara climática que se encuentre en

los laboratorios de Lear Corporation en tiempo real a través de una interfaz visual. Además

el programa debería ser modular y fácilmente adaptable, para poder añadir o quitar

cámaras, y también reutilizable, en caso que se quiera ampliar con nuevas funciones.

A parte de ver el estado de los equipos también se quiere implementar un sistema de

detección y notificación de errores más rápido, así como un sistema para poder hacer una

planificación de la ocupación y liberación de las cámaras.

En lo que respecta al tema más académico, se quiere profundizar en la utilización y manejo

del software LabVIEW, así como poner en práctica los conocimientos adquiridos durante

el transcurso de la carrera. Y ya que se me ha concedido la oportunidad de realizar el PFG

en Lear Corporation, nunca estás de más observar y aprender formas de proceder,

metodologías de trabajo y funcionamiento de una empresa de esta entidad.

8

4 Desarrollo e Implementación

4.1 Las Cámaras Climáticas

Antes de empezar a desarrollar es fundamental entender con qué equipos se va a

trabajar, como funcionan y si hay más de un tipo, ya que de ser así, habría que hacer

modificaciones para abordar las diferencias entre ellas.

4.1.1 ¿Qué Es una Cámara Climática y para Qué Sirve?

Una cámara de ensayo climático, es básicamente un recinto cerrado, el cual puede

variar mucho en tamaño según las necesidades específicas, en el que se reproducen

artificialmente condiciones medioambientales a las que el equipo, prototipo, componentes,

etc. pueden están sometidos durante su funcionamiento, transporte o almacenaje. También

son usadas para acelerar los efectos a la exposición medioambiental, a veces en

condiciones no esperadas.

Estas condiciones pueden incluir:

- Temperaturas extremas

- Variaciones súbitas y extremas de temperatura

- Humedad

- Vibraciones

- Radiación electromagnética

- Niebla salina

- Lluvia

- Desgaste

- Exposición al sol, causando la degradación UV

- Vacío

Realizar estos ensayos climáticos en el plan de validación de un producto de nuevo diseño,

antes de su producción en serie, sirve para prever el comportamiento del equipo en sus

condiciones ambientales de uso y así prevenir funcionamientos defectuosos una vez

puestos en el mercado. Todos estos ensayos están regulados por diversas normativas,

siendo las más comunes las siguientes: DIN 40046, IEC 68-2, BS 2011, MIL-STD 810 D,

MIL-E 5272, IEC 60068, MIL-STD 883, MIL-STD 202, DIN 50014, DIN 60068, UNE-

EN 60068… de esta forma el cliente puede saber si el producto está dentro de la legalidad.

Para realizar estos ensayos de la forma más precisa y siguiendo las normas, las cámaras se

someten a revisiones y calibraciones periódicamente por parte del organismo ENAC, para

asegurar que las condiciones simuladas son las correctas. A continuación se muestran dos

certificados de calibraciones llevados a cabo en dos cámaras distintas:

Figura 2: Certificados de las calibraciones

9

4.1.2 Tipos de Cámaras

Las cámaras medioambientales, aparte de variar en tamaño según necesidades,

también varían según las condiciones que tengan que simular, tales como las comentadas

en el punto anterior. Sin embargo, en el Laboratorio de Lear Corporation, las

aproximadamente 20 cámaras existentes que habrá que controlar están divididas solamente

en 3 clases y provienen de 2 fabricantes distintos, ACS del grupo Angelantoni y Vötsch.

Estos 3 tipos son:

- Temperatura y humedad

La mayoría de las cámaras pertenecen a este grupo. Tal y como su nombre indica son

capaces de recrear cualquier temperatura, en un rango que normalmente oscila entre los -70

grados Celsius y los 200, y cualquier tanto por ciento de humedad, pudiendo estar en

régimen estacionario (mismos valores a lo largo del tiempo) que sería el modo manual o

seguir unos patrones de tiempo, tal como el que se muetra a continuación, que sería el

modo programa:

Figura 3: Ejemplo 2 de perfil de test de ensayo

Figura 4: Ejemplo de cámaras climáticas de temperatura y humedad con diferentes tamaños del fabricante ACS

Voltage: 12V/14V Duration: 20 h per axis Temperature: -40ºC / +105ºC / +23ºC Ramp rate: 1-1.5ºC/min

10

- Vibración

En el laboratorio hay dos máquinas para simular vibraciones. Éstas constan de dos partes,

un tambor que es el encargado de fabricar las vibraciones con diferentes intensidades y

frecuencias, así como también de un reciento aislado, para que en el caso que sea

necesario, se pueda ensayar estas vibraciones con un temperatura fuera del rango de lo que

se considera temperatura ambiente. En la figura inferior se puede observar las dos partes

comentadas.

Figura 5: Equipo de vibración del fabricante ACS

- Choque térmico

De este tipo, también hay solamente dos, ambas situadas en el polígono 2 y del mismo

fabricante, ACS Angelantoni. Éstas tienen la particularidad de tener dos cavidades

interiores diferenciadas, cada una de ellas con una temperatura diferente. La parte superior

está con una temperatura muy caliente y la inferior todo al contrario, es decir, muy fría.

Entonces mediante una bandeja que puede desplazarse en dirección vertical, se pasa el

prototipo que se está testeando de un ambiente extremo a otro de forma rápida, pudiendo

evaluar entonces cómo se comporta en cambios de temperatura muy bruscos.

Figura 6: Imagen de una cámara de choque térmico del fabricante ACS

11

4.1.3 Localización de las Cámaras Climáticas

Actualmente, las 20 cámaras existentes están repartidas en 2 zonas distintas de la empresa

Lear. 18 de ellas están situadas en el Laboratorio del edificio del CTE y las 2 restantes, que

son las de choque térmico, están en el Polígono 2. Aunque en un futuro próximo, no se

descarta ampliar el número de zonas, ya que en los lugares actuales el espacio se ha

quedado muy reducido. Estas zonas de laboratorios donde están dispuestas las cámaras

deben cumplen la normativa internacional de Calidad ISO 17025 en la que se establecen

los requisitos que deben cumplir los laboratorios de ensayo y calibración, y es por eso que

se hacen revisiones periódicas, cada año aproximadamente, de las que se encarga ENAC,

para comprobar si todo está correcto.

A continuación se muestra una relación de las diferentes cámaras climáticas con su

disposición en planta:

# Modelo Fabricante Tipo

1 Discovery 600 ACS Angelantoni Temperatura y humedad

2 HC 4055 Vötsch Sin funcionar

3 Challenge 600 ACS Angelantoni Temperatura y humedad

4 Hygros 50 ACS Angelantoni Sin funcionar

5 Discovery 600 ACS Angelantoni Temperatura y humedad

6 VCS 7033 Vötsch Temperatura y humedad

7 VT 7150-5 Vötsch Temperatura y humedad







14 VCV7100 + Vibrador L.E. Vötsch Vibración

15 H1440VT + Vibrador L.D.S. ACS Angelantoni Vibración

16 VCS 7034 Vötsch Temperatura y humedad



19 CST 320/2T ACS Angelantoni Choque térmico

20 CST 320/2T ACS Angelantoni Choque térmico Figura 7: Listado de cámaras de las zonas de laboratorio

Figura 8: Distribución de los equipos de test climático

12

4.1.4 Comunicación con las Cámaras

Este es un punto muy importante a entender, ya que de ello depende que se coja

correctamente toda la información que proporciona la cámara climática para que llegue al

usuario final.

Todos los equipos de test tienen adjunto un PC con el cual se comunican mediante la

interfaz RS232 a través del puerto serie, con conectores DB9.

Figura 9: Conexión PC - Cámara

El PC actúa como master mientras que la cámara climática actúa como esclavo, es decir,

que hasta que el ordenador no envía una pregunta, no se recibe una respuesta por parte de

la cámara.

Figura 10: Esquema de la comunicación

Pero hay que tener en cuenta que en el Laboratorio hay cámaras provenientes de dos

fabricantes distintos, tal y como se ha comentado en el punto 4.1.2, ACS y Vötsch, y

aunque comparten la forma de conexión de la cámara con el PC, existen como es lógico

diferencias, como el software de control que utilizan y el protocolo de comunicación. Así

que ahora se pasará a explicar con más detalle, cada una de ellas.

13

4.1.4.1 ACS Angelantoni

El software propietario de esta empresa para el control de las cámaras es el llamado

WinKratos:

Figura 11: Ejemplo de la interfaz de WinKratos

Éste programa es compatible con las 3 familias de cámaras presentes en Lear del fabricante

ACS. Todas ellas utilizan el protocolo Modbus, con los siguientes parámetros de

comunicación:

- Velocidad de transmisión: 9600

- Paridad: No

- Bits de parada: 1

- Bits de datos: 8

Pero hay pequeñas diferencias en la sintaxis de las funciones, debido a que tienen

diferentes PLC en su interior (Las Challenge tienen MicroPLC, las Discovery SAIA y las

de Choque Térmico Siemens S7).

Este protocolo permite realizar principalmente dos acciones, escritura o lectura de los

registros internos del controlador cámara, aunque la función que interesa para el correcto

desarrollo del proyecto, es la función de lectura, ya que es la que proporciona información

de la cámara en ese momento para su monitorización, por lo tanto es de vital importancia

entender bien cuál es la estructura de la pregunta, como es la respuesta de la función

lectura, y cada cuando WinKratos ejecuta dicha función, para tener consciencia de la

velocidad de refresco de los datos a la que se podrá llegar.

Para esclarecer estas dos cuestiones se ha hecho uso de un sniffer. Este software permite

ver el tráfico y capturar las tramas que se envían y se reciben a través del puerto serie del

PC, mientras el programa WinKratos se está ejecutando. De esta forma, nos posibilita

saber cómo actúa, y con la ayuda de los manuales de las cámaras, descifrar la tramas.

Estas tramas varían según a la serie/familia a la cual pertenece la cámara, por lo que se

analizaran por separado.

14

Serie Challenge

Después de observar con el sniffer las comunicaciones que se llevan a cabo por el puerto,

se puede extraer que WinKratos, independientemente del modo de funcionamiento

(manual o programa), está continuamente realizando preguntas de lectura del estado de la

cámara, repitiendo una rutina cada segundo y medio aproximadamente, en la cual se llevan

a cabo dos preguntas a la cámara, para poder leer todos los registros al completo. La rutina

se muestra a continuación:

Pedido:

11 03 07 D0 00 7C 46 36

Respuesta: (+0.5000 segundos)

11 03 F8 21 33 00 00 9C 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1C 38 00 00

1C B1 00 00 24 60 00 00 2F 78 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 21 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 00 00 00 00 00 00 01 01 00

00 00 00 00 00 21 34 00 00 21 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 83 98

Pedido: (+0.2031 segundos)

11 03 08 38 00 7D 04 D6

Respuesta: (+0.5000 segundos)

11 03 FA 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 21 34 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 36 00 00 04 32 00 04 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 23 00 00 00 00 00 00 69 B7 00 00 00 00 00 00 23 D5 0E 6C 2C 88 13 6E 00 00 00 00 00

00 00 00 00 00 00 00 33 FA 9F C7 00 00 00 00 00 00 00 00 0D 98 00 00 21 32 00 00 21 33 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

3E D5

Análisis:

Pedido1: 11 03 07 D0 00 7C 46 36

11 [17(dec)]: Dirección de la cámara

03 [03(dec)]: Función de lectura

07 [07(dec)]: Dirección de memoria H

D0 [208(dec)]: Dirección de memoria L

00 [00(dec)]: Leer 0 registros H = 0 bytes

7C [124(dec)]: Leer 124 registros L = 248 bytes

46 [70(dec)]: Comprobación de errores


Respuesta 1: 11 03 F8 [248 bytes de info] 83 98



F8 [248(dec)]: Hay que leer 248 bytes

07D0 [2000(dec)]: Empezar en la dirección 2000

15

[248 bytes de info]: Registros que contienen información de la cámara. Por ejemplo: si se

mira el manual, dice que la temperatura interna está en la dirección de memoria 2000, con

un valor multiplicado por 100. Si se coge la trama de ejemplo, en esa dirección tenemos

2133 en hexadecimal, si se convierte a decimal es 8499, y si se divide por 100 da como

resultado final una temperatura de 84.99 ºC.



Pedido2: 11 03 08 38 00 7d 04 D6




38 [56(dec)]: Dirección de memoria L


7D [125(dec)]: Leer 125 registros L = 250 bytes



Respuesta 2: 11 03 FA [250 bytes de info] 50 F6



FA [250(dec)]: Hay que leer 250 bytes

[250 bytes de info]: Registros que contienen información de la cámara. Esta vez se

empieza a partir de la @2014 por lo que la información es diferentes a la de la respuesta

anterior.



Serie Discovery

Para esta serie, la temporización es igual que en la anterior, y la rutina también está

formada por dos preguntas y dos respuestas con la misma cantidad de bytes, pero esta vez

el direccionamiento a la memoria es otro, así como la forma de convertir las tramas en

información utilizable.

Pedido1: 11 03 00 00 00 7C 46 BB




00 [00(dec)]: Dirección de memoria L


7C [124(dec)]: Leer 124 registros L = 248 bytes


BB [187(dec)]: Comprobación de errores

Respuesta 1: 11 03 F8 [248 bytes de info] CRC



F8 [248(dec)]: Hay que leer 248 bytes

0828 [2104(dec)]: Empezar en la dirección 2104

0000 [0000(dec)]: Empezar en la dirección 0000

16

[248 bytes de info]: Registros que contienen información de la cámara. A diferencia de las

Challenge donde se tenía que convertir de hexadecimal a decimal, en este caso hay que

hacerlo de hexadecimal a coma flotante (IEEE 754). Por ejemplo: para una temperatura

habría 4 bytes en la trama, correspondientes a una dirección del mapeado de memoria

concreta, como podría ser 42 A9 F6 26, que pasados a ese formato daría un valor de

84.98076 ºC. Si lo comparamos con la familia anterior, se ve que se consigue una precisión

mayor.

CRC: Comprobación de errores (2 bytes)

Pedido2: 11 03 00 7D 00 7D 17 63




7D [125(dec)]: Dirección de memoria L


7D [125(dec)]: Leer 125 registros L = 250 bytes



Respuesta 2: 11 03 FA [250 bytes de info] CRC



FA [250(dec)]: Hay que leer 250 bytes

[250 bytes de info]: Registros que contienen información de la cámara. Esta vez se

empieza a partir de la @125 por lo que la información es diferentes a la de la respuesta

anterior.

CRC: Comprobación de errores (2 bytes)

Serie cámaras de choque térmico

La estructura es la misma que en la serie Discovery, en lo único que hay que fijarse es que

el mapeado de memoria es un poco distinto.

4.1.4.2 Vötsch

El software para la comunicación con las cámaras Vötsch, es un programa llamado

Simpati:

Figura 12: Editor de programas del Simpati

007D [0125(dec)]: Empezar en la dirección 125

17

El protocolo utilizado por este programa es el JBUS y los parámetros de comunicación son

los siguientes:

- Velocidad de transmisión: 9600

- Bits de inicio: 1

- Bits de datos : 8

- Bits de parada: 1

- Paridad: No

- Handshake: No

Con la ayuda del programa sniffer comentado antes, se ha podido extraer la rutina que

envía el Simpati a la cámara de forma continua, que es la siguiente:

[14/11/2013 12:14:20] - Written data

01 04 0c 1c 00 08 33 50

[14/11/2013 12:14:20] - Read data

01 04 10 c2 70 00 00 43 0c 00 00 00 00 00 00 42 c8 00 00 5b d4

[14/11/2013 12:14:21] - Written data

01 04 80 10 00 03 98 0e

[14/11/2013 12:14:21] - Read data

01 04 06 00 00 00 00 00 00 60 93

[14/11/2013 12:14:21] - Written data

01 04 80 20 00 06 58 02

[14/11/2013 12:14:21] - Read data

01 04 0c c7 96 29 46 40 c7 df 48 00 00 00 00 0a 0c .

[14/11/2013 12:14:21] - Written data

01 10 00 63 00 04 08 00 03 00 01 00 02 00 03 dd

[14/11/2013 12:14:21] - Read data

01 10 00 63 00 04 31 d4

[14/11/2013 12:14:21] - Written data

01 04 80 04 00 06 18 09

[14/11/2013 12:14:21] - Read data

01 04 0c 00 00 00 00 00 00 00 00 00 00 00 00 95 b7 ·

[14/11/2013 12:14:21] - Written data

01 04 0d 48 00 0c 72 b5

[14/11/2013 12:14:21] - Read data

01 04 18 c2 b4 00 00 43 3e 00 00 00 00 00 00 42 c8 00 00 c2 b4 00 00 43 3e 00 00 2f 18

[14/11/2013 12:14:22] - Written data

01 04 0c e4 00 0c b3 68

[14/11/2013 12:14:22] - Read data

01 04 18 c2 b4 00 00 43 3e 00 00 00 00 00 00 42 c8 00 00 c2 a0 00 00 43 34 00 00 5b 1b

[14/11/2013 12:14:22] - Written data

01 10 80 01 00 08 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bb d4

[14/11/2013 12:14:22] - Read data

01 10 80 01 00 08 b9 cf

[14/11/2013 12:14:22] - Written data

01 04 80 01 00 0c 88 0f

[14/11/2013 12:14:22] - Read data

01 04 18 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e2 cf

[14/11/2013 12:14:23] - Written data

01 04 80 01 00 0c 88 0f

[14/11/2013 12:14:23] - Read data

01 04 18 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e2 cf

[14/11/2013 12:14:23] - Written data

18

01 04 80 02 00 04 79 c9

[14/11/2013 12:14:23] - Read data

01 04 08 43 15 b8 41 0f 33 c4 42 22 74

[14/11/2013 12:14:23] - Written data

01 04 80 08 00 23 19 d1

[14/11/2013 12:14:23] - Read data

01 04 46 00 00 20 41 00 00 70 c2 00 00 f0 42 00 00 00 00 c4 42 00 00 00 00 00 00 c8 42 00 00 00

00 f0 41 00 00 a0 41 00 00 20 42 00 00 00 00 16 44 00 80 13 44 00 80 18 44 00 00 00 00 20 41 00

00 00 00 00 00 a0 41 00 00 ae c1

El problema es que aun teniendo estas tramas, en el manual proporcionado por el

fabricante solo se explican dos de los tres protocolos soportados por la cámara (ASCII-1 y

ASCII-2), y dejan sin detallar el protocolo que utiliza el Simpati (JBUS) por un tema de

confidencialidad y hermetismo, por lo que desgraciadamente no se ha podido hacer el

análisis para descifrar el contenido de las preguntas y respuestas que lleva a cabo este

programa. Más adelante se explica cómo se ha sobrellevado este contratiempo, y que

solución se ha propuesto para la continuación del proyecto.

4.2 LabVIEW

Desde un inicio se ha pensado en usar el entorno LabVIEW para la creación de las

aplicaciones necesarias para cumplir los objetivos propuestos. A continuación se explica en

que consiste este software y el porqué de su elección.

4.2.1 ¿Qué Es LabVIEW?

LabVIEW (acrónimo para Laboratory Virtual Intrument Engineering Workbench)

que pertenece a la empresa National Intruments, es una plataforma y entorno de desarrollo

para diseñar sistemas, con un lenguaje de programación visual gráfico. La última versión

es la 2013, que es con la que se ha contado para realizar este proyecto.

El lenguaje de programación utilizado en LabVIEW, conocido como lenguaje G, es un

lenguaje de programación de flujo de datos. La ejecución está determinada por la

estructura de un diagrama de bloques, donde el programador conecta las diferentes

funciones-nodos (que son los bloques) mediante el dibujo de cables. Estos cables propagan

las variables y cualquier nodo se puede ejecutar tan pronto como todas inputs estén

disponibles. Dado que esto podría llevar a múltiples nodos simultáneamente, el lenguaje G

es intrínsecamente capaz de una ejecución en paralelo. El hardware multiproceso y

multihilo es explotado de forma automática por el planificador incorporado, que multiplexa

múltiples hilos del SO en los nodos listos para su ejecución.

A continuación se muestra un ejemplo muy simple de como es el lenguaje G que se ha

descrito. En este caso vemos que primero se ejecutaría la suma, posteriormente la resta y

por último la multiplicación, ya que este es el orden por el cual los nodos tienen

disponibles sus variables de entrada.

Figura 13: Ejemplo del lenguaje G de LabVIEW

19

Los programas desarrollados con LabVIEW se llaman instrumentos virtuales, o VIs, y su

origen proviene del control de instrumentos, aunque hoy en día se ha expandido

ampliamente no solo al control de todo tipo de electrónica sino también a su programación

embebida, comunicaciones, matemáticas, etc.

Cada VI está compuesto principalmente por 2 partes: el panel frontal y el diagrama de

bloques. El panel frontal se construye usando controles e indicadores. Los controles

permiten al usuario proveer información al VI, es decir, son las entradas, y luego están los

indicadores, que muestran o representan los resultados basados en las inputs dados al VI,

es decir, que son las salidas. Por otro lado tenemos el diagrama de bloques, que contiene el

código fuente de forma gráfica. Todos los objetos puestos en el panel frontal aparecerán en

este diagrama como terminales, además se pueden añadir estructuras y funciones de todo

tipo para realizar operaciones sobre los controles y enviar la información a los indicadores.

Figura 14: Ejemplo de VI: Panel frontal a la izquierda y diagrama de bloques a la derecha

4.2.2 ¿Por qué LabVIEW?

Desde un inicio se pensó casi sin dudarlo en utilizar la plataforma LabVIEW, ya

que nos ofrece unos beneficios muy grandes comparados con otros entornos de

programación, como son:

- Interfaces de comunicaciones

Una de las claves de LabVIEW sobre otros entornos de desarrollo es el amplio soporte

para el acceso al hardware de instrumentación. Se incluyen o están disponibles para su

inclusión controladores y capas de abstracción para todo tipo de instrumentos y buses, lo

cual para nuestro proyecto es idóneo, ya que uno de los puntos principales del proyecto es

la comunicación con las cámaras climáticas mediante el puerto serie (RS232),

ahorrándonos así tiempo de desarrollo para poder invertirlo en otros temas.

- Código

Dada la naturaleza modular de LabVIEW, el código puede ser modificado o ampliado de

manera sencilla, pudiendo intercambiar diferentes sub-VI de forma totalmente compatible.

Y como es un lenguaje totalmente gráfico, la curva de aprendizaje es mucho rápida

comparada con otras opciones, pudiendo así llegar a niveles más altos en un menor tiempo.

Además, el entorno permite crear aplicaciones autoejecutables, es decir, que una vez

20

creada la aplicación se puede hacer un ejecutable para su distribución en otros PC, sin la

necesidad de tener LabVIEW instalados en todos ellos.

- Grandes librerías

Tanto para el panel frontal como para el panel del diagrama de bloques, hay disponibles

multitud de librerías con un gran número de funciones para adquisición de datos,

generación de señales, matemáticas, estadísticas, condicionamiento de señales, análisis,

etc., hecho que debería permitir realizar todas las funcionalidades de nuestro proyecto y

obtener una interfaz gráfica de usuario muy clara, dinámica y sobretodo amigable y

sencilla de usar.

- Amplio ecosistema

Debido a la popularidad y el largo tiempo que lleva en el mercado LabVIEW, hay muchos

add-ons desarrollados por terceros y amplios foros de ayuda, que permitiría la resolución

de cualquier aspecto o duda que pudiese surgir durante el desarrollo.

4.3 Estructura del Software

Una vez conocidas todas las cámaras y su forma de comunicarse, así como también

que posibilidades ofrece el entorno LabVIEW, es momento de afrontar que hacer para

poder cumplir los objetivos del inicio.

Para la monitorización de los equipos se ha desarrollado una serie de software el cual se

puede dividir en 3 fases principalmente. Estas son: coger los datos provenientes de las

cámaras climáticas, compartir estos datos a través de la red, y finalmente mostrar toda la

información en una interfaz gráfica al usuario final.

El primer y segundo punto, se ejecutaran en los PC adjuntos de las cámaras climáticas en

las zonas de laboratorio, y la última podrá ejecutarse en cualquier ordenador remoto que

esté conectado la red de Lear, ya sea un ordenador de sobremesa o un portátil con conexión

wi-fi.

Para poder tener una mejor organización temporal de todas las cámaras (cual se está

utilizando, cual está libre o cuando lo estará, etc.) se ha montado un sistema para que el

propio usuario que esté utilizando un equipo climático en concreto, informe al resto de

usuarios hasta cuando lo estará utilizando con una fecha de finalización de test de ensayo,

para que así los otros se puedan organizar de manera más eficiente.

Y finalmente, para el tema del control y manejo de errores se ha hecho un sistema que vaya

independiente de la interfaz de usuario, ya que si no lo fuera, hasta que el usuario no se

conectara a la interfaz gráfica, no podría ver qué sucede con la cámara y si ha surgido

algún error, por lo que se estaría en la misma situación anterior de una pérdida de tiempo,

ya que es obvio que el usuario no estará constantemente con el panel de control abierto.

Así que se ha propuesto un sistema para que en caso de que aparezca algún fallo en alguna

cámara, se envíe un correo electrónico a quien se desee (p.ej. responsable de laboratorio)

para informar de manera inmediata que equipo ha sido afectado y que ha ocurrido.

21

En la figura que hay a continuación, se muestra un esquema con todas las partes

mencionadas que componen el proyecto y su interrlación:

Figura 15: Esquema de la estructura del software

A continuación se pasará a explicar cada uno de los 3 módulos principales: el primero

tratará de la recopilación de datos (también se hablará del manejo de errores), el segundo

todo lo que implica el compartir estos datos en la red, y por último todo lo relacionado con

la interfaz gráfica final.

22

4.4 Adquisición y Decodificación de los Datos

La adquisición y la decodificación de los datos es el primer paso que hay que

desarrollar, ya que es en éste donde se sustenta todo. Por eso, es importante que sea un

sistema fiable y sólido, para que no se produzcan errores indeseados.

Tal y como se ha mencionado varias veces anteriormente hay presentes dos fabricantes

distintos con diferentes protocolos, así que se han llevado a cabo 2 programas

completamente distintos, uno para cada marca de cámaras climáticas, los cuales se van a

comentar a continuación.

4.4.1 Cámaras ACS

Para el programa de los equipos ACS tenemos en disposición todo el

funcionamiento del protocolo, así pues, la única labor es conseguir interceptar las tramas

que van desde la cámara hasta el puerto serial del PC, para de esa forma poder leer toda la

información que transmite ésta y decodificarla.

En primera instancia se pensó que ya que LabVIEW da herramientas para la comunicación

con la interfaz serial, sería posible la creación de una pequeña aplicación que pudiera leer

las tramas enviadas y recibidas del puerto. El inconveniente que surgió rápidamente es que

en entorno Windows no permite que dos aplicaciones tomen el control del mismo puerto,

por lo que como WinKratos siempre tiene que estar encendido y conectado al puerto para

comunicarse, a la aplicación de LabVIEW le era imposible el acceso, imposibilitando

realizar su función.

Figura 16: Esquema problema de la aplicación inicial

Para intentar resolver este problema se buscaron soluciones utilizando algún programa de

terceros o algún dispositivo que permitiera la comunicación del programa hecho con

LabVIEW con el puerto, mientras el WinKratos se estuviera comunicando de forma usual.

Serial Port Monitor ActiveX Control

La primera opción que se encontró fue un sniffer llamado Serial Port Monitor ActiveX

Control de la compañía Eltima Software. Este componente permite la completa

monitorización de toda la actividad del puerto serie del sistema, pero lo más importante es

que incorpora los controles ActiveX. Estos controles permiten proveer su juego de

funcionalidades en otros entornos para la creación de programas, como por ejemplo en

LabVIEW.

Así pues, se hizo una pequeña aplicación muy simple para probar su funcionamiento. Esta

aplicación que se muestra en la figura 17 se encarga de iniciar la monitorización del puerto

COM1 y ver qué datos transmite la cámara al PC hasta que se pulse el botón de parada.

23

Para ello, primero se abre la librería que contiene los controles ActiveX que proporciona el

programa Serial Port Monitor con el bloque Automation Open, para poco seguido iniciar la

monitorización con un Invoke Node de la función Start en el puerto especificado COM1.

Para que el programa siga ejecutándose hasta nueva orden, se ha puesto un bucle que se

repite cada 100 ms, con condición de salida la pulsación del botón Stop que aparece en el

panel frontal (Figuras 18 y 19). Dentro de este bucle simplemente lo que se hace es leer la

variable global Read Data y mostrarla mediante un indicador en el panel frontal, para

poder saber que valores coge.

Esta variable global se va actualizando gracias al Register Event Callback y su VI asociado

llamado callbackmonitor.vi. El evento es llamado cada vez que se detecta nuevos datos en

el puerto serie, entonces, gracias al VI conectado al nodo VI ref, se extrae la información

necesaria del Bundle con un Unbundle by Name, para luego transformarla a string con el

bloque Variant to Data y la función Byte Array to String, y así poder pasar estos datos a la

variable global Read Data, que se estará leyendo en el bucle principal.

Cuando se quiera detener el programa se deberá pulsar el botón de Stop, para de esta forma

salir del bucle y llamar al Invoke Node de Stop, cerrar el refnum abierto al principio y

cerrar el evento creado con los bloques Close Reference y Unregister for events, para

finalmente ejecutar el bloque Simple Error Handler el cual hará aparecer un cuadro de

dialogo en caso que durante la ejecución se haya producido un error en alguno de los

bloques.

Aquí se muestra el diagrama de bloques explicado:

Figura 17: Diagrama de bloques de la aplicación de prueba

callbackmonitor.vi

24

Y este es el panel frontal para el control. En esta ocasión, muy simple, al ser únicamente

una prueba:

Figura 18 y Figura 19: Panel frontal de la aplicación en dos momentos distintos

Los resultados de dicha aplicación fueron muy satisfactorios, obteniendo los 2 tipos de

tramas diferentes provenientes de la cámara si ningún tipo de perdida de datos, una que es

la que empieza por 11 03 F8 y la otra que empieza por 11 03 FA, tal y como aparecen en

las Figuras 18 y 19.

Él porque de que finalmente no se aplicara esta solución, derivó de problemas con la

licencia al querer convertir la versión trial (que es la que se estaba usando para hacer las

pruebas) a modo completo, para evitar las restricciones y poderlo utilizar en la empresa.

Así que fue necesario el plantear nuevas alternativas.

Splitters

Como segunda opción se pensó en usar algún tipo de splitter que permitiera de alguna

forma poder dividir el puerto en dos, para que de esta forma, más de una aplicación pudiera

ver que ocurría a través de él.

En primera instancia se estudió la posibilidad de utilizar unos dispositivos físicos que

literalmente dividían el cable que venía de la cámara climática en dos, para poder

conectarlo a dos puertos distintos del PC. Lo que ocurre es que los PCs instalados en los

equipos de test tienen un solo puerto COM, así que aparte de este splitter también haría

falta un dispositivo para poder adaptar una conexión serial DB9 a uno de los puertos USB

disponibles.

Figura 20: Splitter hardware del puerto serie Figura 21: Adaptador USB – Puerto Serial DB9

25

Así que como la implementación se tornó un poco ruda y vasta, se dejó un poco de lado o

como último recurso en pro de buscar un solución que fuera software para que quedara

todo más integrado.

La opción que finalmente se ha adoptado para el desarrollo de esta parte del proyecto, es la

utilización del software llamado Serial Port Splitter de la compañía FabulaTech.

¿Cómo funciona?

Serial Port Splitter crea el número necesario de puertos COM virtuales vinculados al

puerto COM físico especificado. Estos puertos virtuales aparecen como los puertos

hardware COM habituales.

Cuando los puertos serie virtuales son abiertos por las aplicaciones de comunicación

correspondientes, los datos del puerto físico son enviados a todos los puertos virtuales

abiertos de manera simultánea. Y viceversa, los datos de cada aplicación escritos en los

puertos virtuales son enviados al puerto COM físico.

De esta forma, con la aplicación LabVIEW se puede recoger los datos necesarios, mientras

que WinKratos continúa con su funcionamiento habitual sin crear ninguna tipo de

violación de permisos al intentar compartir un mismo puerto.

De las dos formas de compartir puerto físico que ofrece este programa, que son Splitting

physical COM-port y Sharing physical COM-port, se ha elegido la segunda debido a que a

diferencia de la primera opción, en esta última los puertos virtuales creados conservan el

mismo nombre que el puerto físico, de esta forma no sería necesario hacer ningún cambio

en la configuración de los programas (WinKratos) que se están ejecutando en los PCs

adjuntos a las cámaras climáticas.

Figura 22: Esquema de las comunicaciones con la utilización del nuevo programa

Con la ayuda de este splitter, se ha elaborado una aplicación en LabVIEW, la cual una vez

configurada, trabajará en segundo plano con la función de recoger los datos que vienen de

la cámara y de compartirlos en red (esta parte no se explicara en detalle ahora, sino que se

hará en el punto siguiente).

El panel frontal de dicha aplicación es de aspecto muy minimalista, consta de 4 casillas

para la configuración de la cámara, dos botones de inicio y de parada, y un led indicador.

De izquierda a derecha aparecen:

26

- Port: desplegable para elegir a que puerto está conectado la cámara de los

disponibles en el PC (normalmente es COM1)

- Baud rate: casilla para indicar la velocidad de comunicación

- Chamber type: lista para elegir la familia a la cual pertenece el equipo, a saber:

Challenger, Discovery o Thermal Shock,

- Chamber model: control para escribir que modelo es exactamente, para que en caso

que se produzca un error, en el email que es enviado al supervisor de laboratorio, se

pueda identificar en qué cámara concretamente se ha producido la anormalidad.

- Start sniffing: pulsador para iniciar el programa

- Led verde para indicar que está en funcionamiento

- Stop: botón de parada

Figura 23: Panel frontal del programa para las ACS

Una vez comentado el panel frontal, pasamos al diagrama de bloques, que es donde

realmente se ve reflejado el funcionamiento de la aplicación.

Primero se empezará explicando el nivel más superior (Main), para luego pasar a los

SubVI (rutinas). El VI principal consta de 2 bucles while, el primero de ellos (Figura 24) es

en el que se entra justo iniciar el programa. En éste, mediante el bloque VISA Configure

Serial Port y los controles mostrados en el panel frontal, se configura el puerto serial al

cual se quiere conectar. Una vez elegidas las propiedades correctas, para salir de bucle, se

debe presionar el botón Start Sniffing, lo que hará encender el led verde de inicio y además

activará la condición de salida del bucle, dando paso al bucle siguiente.

Figura 24: Primer bucle con la configuración del puerto serial

El segundo bucle, el principal de la aplicación, es el que se muestra en la Figura 25.

Una vez dentro de este bucle, lo que se hace en cada vuelta es leer del puerto serie

mediante la función VISA Read, los 1000 bytes que son indicados, y luego se hace un

borrado de este buffer de lectura con VISA Clear para que no provoque errores en la

siguiente lectura. Se han definido 1000 bytes, para tener un margen de error en caso de que

la lectura de estos bytes no empiece justo en el inicio de una trama. En realidad, para caso

más desfavorable se tendrían que leer 762 bytes, pero se han puesto unos cuantos más

hasta llegar a 1000 para conseguir un tasa de refresco de datos de unos 3 segundos, que

para los cambios tan lentos que se producen en las variables (temperatura, humedad) y los

test de varias decenas de horas, es más que suficiente.

27

Entonces, en caso de leer correctamente estos 1000 bytes se pasará al estado Verdadero del

case selector, que viene a ser como un if en programación convencional. Dentro de este

estado, se busca de entre estos 1000 bytes, las dos tramas que se vieron en el análisis del

protocolo (una que empieza por 11 03 F8 y tiene 253 bytes, y la otra que empieza por 11

03 FA y tiene 255 bytes) con la ayuda de las funciones Search/Split string y String subset,

y se extraen por separado, enviándose estas dos al SubVI encargado de la decodificación y

la compartición de los datos en red, junto con el tipo de cámara con la cual se está

comunicando, para poder hacer la conversión de los datos de forma correcta.

Dentro de este estado también se actualiza la variable LAST UPDATE con la fecha en la

cual se ha ejecutado gracias a la función Get Data/Time in seconds, para de esta forma

saber luego en la interfaz gráfica general, cuál es el último instante en el cual se han

refrescado todos los datos (esta variable es una variable de red, que se explicaran más tarde

la forma de escribir o leer de ellas).

El caso Falso esta el cuadrado totalmente en blanco, ya que no se quiere ejecutar ningún

código en una situación en la cual no se hayan leído completamente estos 1000 bytes, ya

que podría darse el caso en el que las tramas no están del todo completas, lo que podría

llevar a datos erróneos.

Dentro del bucle, en la parte inferior izquierda, también se escribe en una variable global el

nombre del modelo de la cámara puesto en el panel frontal, ya que esta variable es

necesaria en otros VIs, y la manera más fácil de hacerla llegar, es esta.

Para salir del bucle hay que pulsar el botón de Stop del panel frontal, lo que hará apagar el

led que estaba encendido y activará la condición de salida. Una vez fuera se hace otra

limpieza del buffer de lectura con el VISA Clear y se ejecuta el Simple Error Handler para

comprobar que no se haya producido ningún error.

Figura 25: Bucle principal de la aplicación

28

Dentro de este bucle se encuentra, tal y como se ha mencionado, el SubVI “Decode and

Share Data”, que se pasará a explicar a continuación:

Esta rutina se encarga de no solo hacer la conversión de las dos tramas a unos datos que se

puedan aprovechar, sino que también se encarga de una vez hechas las decodificaciones,

guardar los datos en variables de red para que luego las pueda leer el programa que estará

utilizando el usuario final.

Las tres entradas que tiene son: el tipo de cámara, que de ello dependerá que clase de

conversiones se hagan, y las dos tramas, que proporcionan la información con la que

trabajar.

El SubVI se basa principalmente en una Case Structure, con tres casos disponibles a elegir,

cada uno de ellos perteneciente a una familia, que es escogida mediante el selector del

panel frontal de la aplicación.

En la Figura 26 se muestra el primero de los 3 casos disponibles, que es de las cámaras

Challenger. En el recuadro rojo están las entradas de la rutina, provenientes del nivel

superior. En azul esta todo lo que involucra la obtención de los datos de las trama de

caracteres. Y por último, la parte en verde, que corresponde a la de compartir los datos, la

cual se explicará más adelante (en el punto 4.5), pero que básicamente corresponde a

guarda cada dato en una variable de red distinta.

En la primera de las tramas (la que empieza por 11 03 F8) viene la información sobre la

presión de los compresores, las variables de temperatura y de humedad, y además, datos

con lógica binaria (booleanos) que informan si se está funcionando en modo manual o

automático, que variables de control hay activas, así como también de los errores que se

producen en la cámara, es por eso que dentro de esta rutina también está alojado el

programa, que no es más que otro SubVI, encargado del control y la notificación de

errores al usuario.

Para entender cómo se coge toda esta información, se explicara mediante un ejemplo de

cada tipo aparecido:

29

Figura 26: Caso 1 de 3 del SubVI

Entradas Parte de decodificación Guardar datos en variables de red

30

- Ejemplo de la temperatura interior de la cámara: como dentro de la trama se sigue

un orden respecto a lo que es el mapeado de memoria, se ha creado una rutina

llamada 2 bytes from @, en la cual especificando la dirección base en la cual

empieza la trama de caracteres y la dirección donde está la información que

queremos, en este caso 2036 (esto se sabe mirando el manual), ésta localiza los dos

bytes de toda la trama que nos interesan para poder hacer la conversión. Luego,

mediante Type Cast se cogen estos dos bytes en hexadecimal para convertirlos en

un número (integer de 16bits), el cual deberá dividirse entre 100 por orden expresa

del manual de la cámara, para así obtener el valor correcto de la temperatura.

Trozo del diagrama de bloques:

Figura 27: Ejemplo de la obtención de la temperatura

- Ejemplo de los datos binarios: hasta el punto que viene después de aplicar la

función Type Cast, es lo mismo que en el ejemplo anterior. Pero esta ocasión, una

vez obtenido el número (integer 16bits), se le aplican las funciones Number to

Boolean Array y Array to Cluster para así poder extraer los bits de forma individual

con la ayuda del Unbundle by Name, que permite elegir cuál de los bits en concreto

leer. En este caso se leen los bits 0, 8 y 9, cada cual significando cosas distintas.

Este es el trozo del diagrama de bloques tomado como ejemplo:

Figura 28: Ejemplo de la obtención de los booleanos

Para finalizar el análisis de esta trama es oportuno comentar también el SubVI creado para

encargarse del control de los errores específicos de la familia Challenger, ya que viene

implícito en la información que ésta da. Por lo tanto, la trama se ha puesto como entrada a

esta función.

31

Dentro de la función se analizan todos los bits que pertenecen a los errores, para saber si

alguno de ellos está activo. En total, para este tipo de cámaras, pueden surgir 32 tipo de

errores distintos, por lo que hay que mirar 32 bits de diferentes direcciones del mapeado de

memoria, tal y como se muestra en la Figura 29.

Luego de separar cada uno de los bits, se ejecuta para cada caso un mini rutina creada

[ ], que mira el estado del bit, si está a 1 devuelve el nombre del error que se le ha

pasado, si por el contrario el bit está a 0, devuelve una cadena de caracteres vacía.

Una vez hecho esto con todos los errores, se juntan todas las cadenas gracias a la función

Concatenate String, obteniendo un cadena con el nombre o nombres de los errores,

dependiendo de cuantos se hayan producido, o una cadena totalmente vacía en el caso de

que no haiga ningún error en la cámara.

Diagrama de bloques del SubVI:

Figura 29: Diagrama de bloques del SubVI del tratamiento de errores de las Challenger

Bit de error = 0 Bit de error = 1

32

Una vez se tiene esa cadena que engloba a todas las demás, se analiza mediante la rutina

Analize errors and Mail.

En caso de no aparecer ningún error (cadena vacía), no se envía ningún correo y en las

variables de red se guarda que no hay ningún fallo. Pero en el caso que la cadena tenga

algún nombre de error que haga que no esté vacía, se informará al usuario final mediante la

interfaz gráfica con las variables de red, pero además, en caso que esté activado el sistema

para el envío de mails, se enviará un correo electrónico a la dirección especificada

informando que se ha producido un error en la cámara climática modelo X con el nombre

concreto del error que se ha producido, para así poder valorar la urgencia del fallo que se

ha producido. Para poder enviar el correo se ha utilizado el SubVI Send Outlook mail

activeX, el cual mediante ActiveX se conecta a Microsoft Outlook del PC donde se está

ejecutando y envía el mail con los datos que se le pasan, que son: dirección del correo

electrónico al cual se quiere enviar el mail, el asunto y el cuerpo.

Y este es el diagrama del bloque de Analize errors and Mail:

Figura 30: Diagrama de bloques del SubVI del tratamiento de errores de las Challenger contemplando ambos casos

No

hay

err

ore

s Si

hay

err

or/

es

33

Y volviendo a un nivel superior nos encontramos con la segunda de la tramas a analizar

(11 03 FA). En ésta hay información sobre los parámetros del programa que se esté

ejecutando en la cámara, siempre y cuando se encuentre en modo programa y no manual,

claro está. Y es por eso que se encuentran dentro de un Case Structure y solo se leen

cuando el bit de modo de funcionamiento está a 1, que significa modo programa. Estos

datos van desde el ciclo de repetición en el cual se encuentra el programa hasta el tiempo

transcurrido o el segmento actual. Para coger todos estos datos se hace de la misma forma

que con la trama anterior, solo que esta vez la dirección base cambia y hay algún caso

donde es necesario coger 4 bytes en lugar de los 2 que se cogían hasta ahora, como por

ejemplo para la duración del segmento de programa actual que se muestra a continuación,

por lo que también se ha creado una rutina para abarcar estos casos llamada 4 bytes from

@.

Figura 31: Ejemplo de obtención de datos de la segunda trama de caracteres

Hasta ahora dentro de la rutina de “Decodificar y Compartir” solo se ha comentado el caso

para la familia de cámaras Challenger que es el primero de los tres casos distintos. El

segundo pertenece a las Discovery (Figura 32) y el tercero es el de las Thermal Shock

(Figura 33).

34

Diagrama de bloques para las cámaras Discovery:

Figura 32: Caso 2 de 3 del SubVI “Decode and Share Data”

35

Diagrama de bloques del último tipo de equipos de ACS, las Thermal Shock:

Figura 33: Caso 3 de 3 del SubVI “Decode and Share Data”

36

Tal y como se puede observar, todos los 3 casos comparten una estructura idéntica o muy

similar. En el punto donde sí que se diferencian éstas dos últimas respecto al de la

Challenger es cuando se quiere convertir la información que viene de la trama de

caracteres a unos datos medibles. Primero, que las direcciones a la memoria son

completamente diferentes, y segundo, que el método de conversión es distinto, tal y como

se vio en el apartado de los protocolos.

Si bien para el caso donde se deben coger únicamente datos binarios se procede de la

misma forma, cuando hay que recabar información sobre temperaturas, setpoints, etc., es

diferente, ya que se cogen 4 bytes de la trama en lugar de los 2 de antes, y luego al hacer la

transformación de esta cadena de 4 bytes con la función Type Cast a un número, se usa

Single Precision que tiene un total de 32 bits y utiliza coma flotante, en lugar del Integer

de 16 bits que se usaba antes. De esta forma se obtiene el dato con varios decimales sin

tener que ir dividiendo entre 100, o 1000 como se hacía en el caso de las Challenger.

Este es un ejemplo donde se puede apreciar la diferencia. En este caso se extraen los 4

bytes de la dirección de memoria, obteniendo la temperatura interior de la cámara:

Figura 34: Ejemplo que ilustra una conversión para la familia Discovery o Thermal Shock

Como es obvio, dentro de estos dos casos también se ha incluido el tratamiento de errores

correspondiente a cada caso, cada uno de ellos con el número de errores y los nombres de

ellos correspondientes. La estructura del SubVI es la misma que para el primer caso, se

cogen todos los bits de error obteniendo una cadena final, la cual puede estar vacía o

contener el nombre de uno o varios errores, una vez obtenida esta cadena, se ejecuta la

misma rutina utilizada antes llamada Analize errors and Mail.

A continuación se muestran los bloques de los SubVI creados y sus respectivos diagramas

de bloques:

SGL

37

Los errores para las Discovery serían los siguientes, sumando un total de 57 tipos de

errores diferentes:

Figura 35: Diagrama de bloques del SubVI para el tratamiento de errores de la familia Discovery

38

Y este es el diagrama de bloques de las Thermal Shock, sumando 58 en total:

Figura 36: Diagrama de bloques del SubVI para el tratamiento de errores de la familia Discovery

39

4.4.2 Cámaras Vötsch

Para las cámaras Vötsch, la solución adoptada finalmente para el fabricante ACS

(utilización del programa Serial Port Splitter), aquí no es posible aplicarla. Porque a

diferencia de las ACS, de los equipos Vötsch no se puede obtener el protocolo de

comunicación que utiliza el Software propio de la empresa para comunicarse con la

cámara, así que por mucho que se pudiera obtener las tramas que el Simpati envia a su

correspondiente cámara climática, no serviría de nada.

Así pues, la solución que se ha propuesto es la creación de un programa que sustituye por

completo al Simpati. Para comunicarse con la cámara utilizaria el protocolo ASCII-2 del

que si se da información en el manual de cómo poder utilizarlo, todo al contrario que para

el JBUS.

De esta forma, con la utilización de esta nueva aplicación, se puede controlar la cámara al

mismo tiempo que se coge toda la información necesaria, para luego informar al usuario en

la Interfaz gráfica principal.

Para la creación del Panel Frontal se ha intentado colocar los controles y los indicadores

de la forma más funcional e intuitiva posible. El resultado obtenido es el siguiente:

Figura 37: Panel Frontal de la aplicación de reemplazo del Simpati

Donde:

a) Puerto utilizado para la comunicación con la cámara climática.

b) Control del Baud Rate establecido para la comunicación: 9600, 19200, etc.

40

c) Control para la escritura del modelo de la cámara para poder ser identificada en

caso del envío del email de error.

d) Botón de inicio.

e) Control para elegir el modo de funcionamiento: solo monitorizar, control

manual o modo programa.

f) Control de la temperatura, la humedad y la velocidad del ventilador de forma

manual

g) Encender/apagar la cámara y el control de la humedad.

h) Botones para la localización del archivo del programa y la puesta en marcha del

mismo.

i) Parámetros del test en ejecución.

j) Botón para abrir el editor de programas.

k) Abortar la ejecución del programa en funcionamiento.

l) Última actualización de los datos mostrados en el panel de monitorización.

m) Indicador del sistema de mail: en caso de estar activo, se reportará mediante

correo si aparece algún error.

n) Cerrar ejecución del programa.

o) Indicador para mostrar el número y el nombre del error en caso de producirse

uno.

p) Indicador del valor actual, valor nominal y del bit de encendido de la velocidad

del ventilador.

q) Indicador del valor actual, valor nominal y del bit de encendido de la humedad.

r) Indicador del valor actual, valor nominal y del bit de encendido de la

temperatura.

s) Semáforo de estado: verde si la cámara está en funcionamiento, amarillo si hay

presente un error y rojo se la cámara está apagada.

A continuación se pasará a explicar el funcionamiento interno del programa, es decir, lo

que es el diagrama de bloques.

Para empezar, el programa se inicia dentro de un bucle While en el cual se realiza la

configuración del puerto serial y se inicializan las variables globales que se utilizaran en el

desarrollo del programa (Figura 38).

Una vez elegidas las configuraciones deseadas a través de las casillas correspondientes, se

debe pulsar el botón Start para salir del bucle y encender el led para informar que se ha

iniciado la recogida de datos y ya se puede realizar la comunicación con la cámara.

41

Los bloques que están enmarcados en el cuadro rojo, y que aparecen también más adelante

el programa, sirven para ensombrecer o quitar la sombra a determinadas zonas del panel

frontal, de esta forma se hace más fácil la comprensión por parte del usuario de qué se

puede controlar y está activo, y qué no. Por ejemplo, si se activa el Modo Manual se

ensombrecerá la zona del Modo Programa y viceversa.

Inicialización de variables Configuración puerto serial

Figura 38: Bucle inicial de configuración e inicialización de variables

Una vez se sale de la parte de configuración e inicialización se pasa al bucle principal. En

este bucle se ha creado como una especie de sistema de estados con la utilización de un

Case Structure. Entonces, en cada repetición del bucle se ejecuta un caso distinto de esta

estructura, que es elegido por el estado anterior.

42

Este sistema queda de la siguiente forma:

Figura 39: Diagrama de estados

Como se puede observar en la figura anterior, siempre se pasa por el caso 0, que

corresponde a la recopilación de datos de la cámara, antes de ir a cualquier otro, ya que de

esta forma se asegura un refresco rápido de la información. Para seleccionar a que estado

deberá entrar el bucle después del 0, se debe utilizar la pestaña Working Mode donde

aparecen los 3 casos posibles: Only Monitor, Manual Mode o Progam Mode. Dependiendo

de cual se elija, se entrará en un estado u otro, ejecutándose diferentes partes del código.

Ahora se procederá a explicar cada uno de los casos y que sucede/ejecuta en cada uno de

ellos:

Caso 0: Coger Datos

Tal y como su nombre indica esta parte es la encargada de recoger información

proveniente de la cámara climática, tanto para mostrarla en el panel frontal de la aplicación

como para poder compartirla para que también pueda ser aprovechada por la interfaz de

usuario general.

Para realizar dicha tarea se ejecuta un SubVI llamado Monitor Chamber, el cual tiene la

función de comunicarse con la cámara. Durante esta comunicación se envían preguntas de

PC a cámara, para que ésta última devuelva las información en la cual se está interesado.

43

Este es el diagrama de bloques del caso 0, donde se ve como la rutina ejectuda devuelve

todos los parametros del equipo: temperatura (actual y nominal), humedad (actual y

nominal), si hay algún error….

Figura 40: Diagrama de bloques del caso 0

Para poder obtener todos los datos, es necesario que dicha rutina envíe concretamente 2

preguntas de manera secuencial, esperando después de cada pregunta la correspondiente

respuesta claro está. Para realizar tal secuencia, se ha utilizado una Flat Sequence

Structure, que permite ejecutar el código siguiendo un orden indicado.

Por lo tanto, la estructura de la Flat Sequence Structure quedaría así:

Figura 41: Secuencia para poder leer todos los valores

Enviar pregunta

1

Leer respuesta

1

Enviar pregunta

2

Leer respuesta

2

44

La primera de las preguntas sirve para conocer el estado actual en el cual se encuentra la

unidad, para ello se debe enviar la siguiente cadena de caracteres:

$01I<CR>

Donde :

- 01 Dirección del bus de la unidad

- I Solicitud para enviar el estado actual

- <CR> Retorno de carro

Con esta pregunta, se espera que la unidad responda con una cadena de 130 caracteres,

como por ejemplo la mostrada a continuación:

0023.0 0020.5 0050.0 0041.0 0080.0 0080.0 0000.0 0000.0 0000.0 0000.0 0000.0 0000.0

0000.0 0000.0 01101010101010101010101010101010<CR>

Donde:

- 0023.0 Valor nominal de la temperatura

- 0020.5 Valor actual de la temperatura

- 0050.0 Valor nominal de la humedad

- 0041.0 Valor actual de la humedad

- 0080.0 Valor nominal de la velocidad del ventilador

- 0080.0 Valor actual de la velocidad el ventilador

- 0000.0 No usado

- 0000.0 No usado

- 0000.0 No usado

- 0000.0 No usado

- 0000.0 No usado

- 0000.0 No usado

- 0000.0 No usado

- 0000.0 No usado

- 0 No usado

- 1/0 Cámara en funcionamiento o parada

- 1/0 Sistema de humidifación en funcionamiento o parado

- 01010101010101010101010101010 No usados


En el diagrama de bloques (Figura 42) se observa como en el primer paso mediante la

función VISA Write se escribe la cadena inicial. Una vez ejecutada esta función y habiendo

esperado 100ms como mínimo, se pasa al siguiente paso de la secuencia. En éste, se lee la

cadena de 130 caracteres con la función VISA Read y se desglosa para tener por separdo

los diferentes datos. Todos estos datos se definen como outputs de la función, pero además

tambien se guardan en las variables de red correspondientes.

45

Paso 1 (escritura 1) Paso 2 (Lectura 1) Desglose de la trama y guardado en var de red

Figura 42: Parte 1 de 2 de la rutina “Monitor Chamber”, que incluye los pasos 1 y 2 de la secuencia

La segunda pregunta trata sobre la lectura de los errores de la cámara. Para ello se debe

enviar la siguiente trama:

$01F<CR>

Donde:

- 01 Dirección del bus de la unidad


Con esta pregunta, se espera que la unidad responda con una cadena en la que se

especifique cuantos errores hay o no hay ninguno, y en caso de haber alguno saber cual es.

Como por ejemplo la mostrada a continuación:

0<CR> (No error) 2 Power fail <CR>(Con algún error)

Donde:

- 0/2 Numero de erroros presentes

- Power fail Nombre del primer error aparecido

46

La estructura de esta segunda parte del diagrama de bloques es muy parecida a la primera.

Primero se escribe la pregunta y luego se lee la respuesta, solo que esta vez la respuesta

puede tener un numero variable de caracteres, por lo que no se especifica en la función

VISA Read el número exacto, sino que se utiliza la propiedad Bytes at Port que se encarga

de contar todos los bytes que se reciben.

Una vez se ha leido la respuesta, en el caso de que el numero de errores sea diferente a 0,

se enciende el led del panel frontal informando que hay un error y se separa de la trama

recibida, el nombre del error presente. Además, se envia por correo al supervisor del

laboratorio, siempre y cuando el sistema de envio de errores este activo, el informe de

dicho error, tal y como se hacia de la misma manera con las cámaras del fabricante ACS.

Dentro del paso 4 de la Flat Sequence Strucuture también se actualiza la variable Last

Update con la hora que se ha ejecutado esta rutina, de esta forma, se sabe cual ha sido el

último instante en el que las variables se han refrescado.

Paso 3 (escritura 2) Outputs de la funcíón y guardado en var de red

Paso 4(lectura 2) Envio del correo

Figura 43: Parte 2 de 2 de la rutina “Monitor Chamber”, que incluye los pasos 3 y 4 de la secuencia

47

Caso 1: Solo Monitorizar

En este caso los bloques de funciones que se ejecutan solo sirven para ensombrecer las

zonas de modo manual y modo programa, ya que lo único que nos interesa es ver en qué

estado se encuentra la máquina en la zona de monitorización del panel frotnal.


Caso 2: Modo Manual

Este caso es el encargado de controlar la cámara climática en caso de que se quiera hacer

de forma manual, es decir, que es el usuario quien decidirá que valores deberá tener cada

parámetro, en lugar de estar todo controlado por un programa.

Para poder cambiar los parámetros, tanto si se está funcionando en modo manual o

programa, es necesario enviar dos tramas con una estructura y caracteres determinados,

que se especifican claramente en el manual del protocolo ASCII-2 (Anexo E).

48

Una trama sirve para modificar los valores nominales de los parámetros, y la otra para

establecer los gradientes de velocidad de cambio de los valores nominales, tanto para la

temperatura como para la humedad relativa.

La primera es así:

$01E 0023.0 0050.0 0080.0 0000.0 0000.0 0000.0 0000.0 011

01010101010101010101010101010<CR>

Donde:

- 01 Dirección de la unidad

- 0023.0 Valor nominal de la temperatura

- 0050.0 Valor nominal de la humedad relativa

- 0080.0 Valor nominal de la velocidad del ventilador

- 0000.0 No usado

- 0000.0 No usado

- 0000.0 No usado

- 0000.0 No usado

- 0 No usado

- 0/1 Apagar o encender cámara climática

- 0/1 Apagar o encender sistema de humidificación

- 01010101010101010101010101010 No usados


Y la segunda consta de las siguientes partes:

$01U 0003.0 0000.0 0002.5 0000.0<CR>

Donde:

- 01 Dirección de la unidad

- 0003.0 Gradiente de calentamiento (0003.0 = 3 K/min)

- 0000.0 Gradiente de enfriamiento

- 0002.5 Gradiente de humidificación (0002.5 = 2.5 % h.r./min)

- 0000.0 Gradiente de deshumidificación


Es importante que siempre se configure únicamente un gradiente por variable. Es decir,

que por ejemplo, si se le dice un valor concreto de calentamiento a la variable de

temperatura como el que aparece de 3K/min, es importante que el gradiente de

enfriamiento este a 0, ya que si no se producirían errores.

49

Para enviar estas dos tramas se ha creado una función llamada Manual Mode que se

encarga de ello, la cual tiene como entradas los 5 controles de la zona del Modo Manual

del panel frontal y se ejecuta cada vez que se entra en este caso.

Este es el diagrama de bloques de dicha función. Está formado básicamente por una Flat

Sequence Structure constituida por 2 pasos. En el primero de ellos, con las 5 variables que

se le pasan a la rutina se construye la trama de los valores nominales y se envía, se limpia

el buffer y se pasa al siguiente paso de la secuencia en el cual se escribe la trama de los

gradientes. Como se está en modo manual, se han puesto todos los gradientes a 0, lo que

significa que la maquina utilizará el gradiente máximo que admita, para hacer un cambio

de valores lo más rápido posible.

Figura 45: Diagrama de bloques del SubVI llamado Manual Mode

50

Este es el diagrama de bloques del caso 2, donde se puede observar la función comentada

además de algunas escrituras en variables de red que permitan la correcta información al

usuario final:


Caso 3: Modo Programa

Y para finalizar esta el Modo Programa. Si se elige este modo de funcionamiento será la

aplicación y no el usuario quien se encargue del control de la cámara, es decir, que la

propia aplicación se encarga de cambiar los valores de los parámetros en los tiempos

marcados por el perfil del programa que se esté ejecutando.

Para cambiar los valores se envían las mismas tramas que para el Modo Manual, solo que

esta vez no se deben crear a través de unas variables, sino que las tramas ya vienen

incluidas en el archivo del programa.

51

La aplicación ha estado creada para funcionar y seguir una estructura determinada del

archivo del perfil del programa. Esta estructura, que se basa en columnas y filas, es la

siguiente:

Loops # de repeticiones

Tiempo 1 (s) Trama parámetros 1 Trama gradientes 1

Tiempo 2 (s) Trama parámetros 2 Trama gradientes 2

··· ··· ···

Tiempo n (s) Trama parámetros n Trama gradientes n Figura 47: Estructura del archivo del perfil del programa

En las casillas de tiempos, hay que escribir en que instante (en segundos) se quiere que se

envíen a la cámara las 2 tramas que están en la misma fila.

Un ejemplo seria:

Loops 3

0 $01E -040.0 0050.0 0090.0 0000.0 0000.0 0000.0 0000.0 01100000000000000000000000000000

$01U 0000.0 0001.3 0001.7 0000.0

1800 $01E -040.0 0050.0 0090.0 0000.0 0000.0 0000.0 0000.0 01100000000000000000000000000000

$01U 0000.0 0000.0 0000.0 0000.0

5400 $01E 0100.0 0050.0 0090.0 0000.0 0000.0 0000.0 0000.0 01100000000000000000000000000000

$01U 0004.7 0000.0 0000.0 0000.0

7200 $01E 0100.0 0050.0 0090.0 0000.0 0000.0 0000.0 0000.0 01100000000000000000000000000000

$01U 0000.0 0000.0 0000.0 0000.0

10800 $01E 0000.0 0050.0 0090.0 0000.0 0000.0 0000.0 0000.0 01100000000000000000000000000000

$01U 0000.0 0003.3 0000.0 0000.0

12600 $01E 0000.0 0010.0 0030.0 0000.0 0000.0 0000.0 0000.0 00000000000000000000000000000000

$01U 0000.0 0000.0 0000.0 0000.0

Se ve como este programa consta de 3 repeticiones y tiene un total de 5 segmentos (cada

segmento es el tramo que va desde un instante de tiempo a otro).

Una vez que se conoce la estructura que hay seguir para que la aplicación pueda interpretar

bien el archivo, así como también el hecho de elaborar ambas tramas, para crear el archivo

sería tan fácil como abrir el bloc de notas y escribir los caracteres y números

correspondientes.

El problema es que el protocolo con el que se han elaborado las tramas no ha sido utilizado

por los usuarios en ninguna ocasión, al igual que el formato de la estructura, ya que se ha

creado de nuevo, por lo que todo esto requeriría un proceso de aprendizaje. Además, que

viendo solo esta secuencia de números sería difícil interpretar como es el perfil de una

forma relativamente rápida, así que, para evitar todas estas problemáticas, se ha creado un

editor de programas que permite su creación de una forma más rápida, en formato gráfico y

más entendible, lo que permite al usuario no tener que preocuparse por nada.

Para abrir este editor es necesario pulsar el botón Open Program Editor de la zona del

Modo Programa en el panel principal de la aplicación.

52

El panel frontal del Editor de Programas es el siguiente, el cual una vez pulsado el botón,

se abrirá en una nueva ventana independiente:

Figura 48: Panel Frontal del Editor de Programas

Donde:

a) Segmento actual.

b) Parámetros del segmento actual: tiempo, valor final y rampa.

c) Añadir segmento.

d) Eliminar segmento actual.

e) Borrar todos los segmentos.

f) Habilitar/deshabilitar el control de humedad.

g) Representación gráfica del programa con las 3 variables controlables:

temperatura, humedad y velocidad del ventilador.

h) Cerrar el editor de programas.

i) Guardar el programa.

j) Bucles/repeticiones totales del programa.

53

k) Velocidad del ventilador.

l) Humedad.

m) Temperatura.

En el diagrama de bloques de este editor se ejecuta una Flat Sequence Structure. En el

primer paso de la secuencia se limpian todas las variables y se ejecuta un Invoke Node con

la función FP.Open, que hará aparecer el panel frontal de este VI (en las otras rutinas

creadas hasta ahora ejecutar esta función no era necesario, ya que el usuario no tenía que

interactuar en ningún momento con el panel frontal, todo lo contrario que para este caso,

que es fundamental).

Luego, se inicializan todos los arrays y variables que se utilizan durante la ejecución del

programa.

Figura 49: Parte 1 de 2 del diagrama de bloques del Editor de Programas

54

En el tercer paso de la secuencia es donde se ejecuta el bucle while, tal y como se muestra

en la Figura 50, que permite mantener la aplicación abierta hasta que el usuario pulse el

botón de salir del editor o se complete la creación del archivo. Un vez se ejecute cualquiera

de estas dos acciones, no solo se saldrá del bucle y finalizará en el programa, sino que

también se llama a la función FP.Close mediante un Invoke Node que cerrará la ventana

nueva que se había creado al abrir el Editor.

Figura 50: Parte 2 de 2 del diagrama de bloques del Editor de Programas

El bucle se puede dividir en 3 sub-apartados según la funcionalidad. Primero están los

Event Structure encargados de la botonera destinada al control de los segmentos (recuadro

azul). Cada vez que se pulse uno de estos botones, se ejecutara el Event Case

correspondiente con su código en el interior, permitiendo agregar un segmento, borrar el

segmento en el que nos encontremos o borrarlos todos y empezar de nuevo.

Luego están las funciones encargadas de calcular los slopes de los diferentes tramos, de

controlar que no se pasen los límites en los valores y de lo más importante, que es crear los

arrays de los tiempos, temperatura, humedad y velocidad del ventilador de los diferentes

segmentos, lo que permitirá ir haciendo la representación gráfica en tiempo real en el panel

frontal del perfil del test de ensayo, y posteriormente, crear el archivo que podrá ser

ejecutado en la aplicación principal de la cámara climática.

Estas son las 3 funciones (marcadas con el recuadro rojo el diagrama):

55

Como entrada a cada una de las rutinas, hay la matriz correspondiente a cada una de las

variables y su referencia, ya que es necesario escribir en la 5ª columna los valores del

gradiente calculado. Y como salida cada función devuelve los arrays 1D de los respectivos

tiempos, valores y gradientes, así como también un array 2D (matriz) que permite la

representación. Por ejemplo, este es el caso para el de la Temperatura:

Figura 51: Entradas y salidas de la función Array Temp

Una vez ya se ha conseguido el perfil querido, para poder guardar el archivo se debe pulsar

el botón Save Program. Una vez pulsado se ejecuta la última función que falta por

comentar del bucle, que se ha llamado Create File (marcada en verde), y es la responsable

de convertir los 9 arrays provenientes de las 3 funciones anteriores, en lo que es

propiamente el archivo que luego podrá ser ejecutado.

Para llevar a cabo dicha tarea, se siguen unos pasos hasta llegar al objetivo final. A

continuación se pasará a explicar dichos pasos, y a medida que se vayan comentado se

ejemplificará con un pequeño caso para hacer más fácil la comprensión.

Todo empieza con los 9 vectores:

Tiempos T 0 1800 3600 5400

Valores T 100 100 25 0

Gradientes T 3.33 0 -2.5 0

Tiempos H 0 900 3600 5400

Valores H 50 50 10 0

Gradientes H 3.33 0 -1.33 0

Tiempos F 0 0 5400

Valores F 80 80 0

Gradientes F 0 0 0

56

Luego, estos 9 vectores se agrupan en 3 matrices, una para cada parámetro. En la primera

columna de cada matriz se ponen los tiempos, en la segunda los valores y en la tercera los

gradientes:

Temperatura Humedad Vel del ventilador

0 100 3.33 0 50 3.33 0 80 0

1800 100 0 900 50 0 0 80 0

3600 25 -2.5 3600 10 -1.33 5400 0 0

5400 0 0 5400 0 0

Una vez se tienen la 3 matrices, se pasan cada una de ellas a una matriz mayor que las

engloba a todas, pero con la particularidad que se pasaran mirando fila a fila, en caso de

encontrar un tiempo que aún no haya aparecido se creará una nueva fila, en caso de que el

instante de tiempo ya esté presente, los valores y los gradientes se añadirán en la misma

fila sin crear una nueva:

Tiempos Valores T Valores H Valores F Gradientes T Gradientes H Gradientes F

0 100 50 80 3.33 3.33 0

1800 100 0

3600 25 10 -2.5 -1.33

5400 0 0 0 0 0 0

900 50 3.33

Seguidamente se ordenan todas las filas por la columna de tiempos de menor a mayor:


0 100 50 80 3.33 3.33 0

900 50 3.33

1800 100 0

3600 25 10 -2.5 -1.33

5400 0 0 0 0 0 0

Después se completan las casillas que se han quedado vacías con el valor de la fila

superior, de esta forma, el segmento puede continuar con normalidad:


0 100 50 80 3.33 3.33 0

900 100 50 80 3.33 3.33 0

1800 100 500 80 0 3.33 0

3600 25 10 80 -2.5 -1.33 0

5400 0 0 0 0 0 0

Y finalmente, esta matriz se convierte a las tramas del protocolo ASCII-2, y se crea la

estructura del programa para después guárdalo en un archivo en el lugar indicado por el

usuario:

Loops 2

0 $01E 0100.0 0050.0 0080.0 0000.0 0000.0 0000.0 0000.0

01100000000000000000000000000000

$01U 0003.3 0000.0 0003.3 0000.0

900 $01E 0100.0 0050.0 0080.0 0000.0 0000.0 0000.0 0000.0

01100000000000000000000000000000

$01U 0003.3 0000.0 0000.0 0000.0

1800 $01E 0100.0 0050.0 0080.0 0000.0 0000.0 0000.0 0000.0

01100000000000000000000000000000

$01U 0000.0 0000.0 0000.0 0000.0

57

3600 $01E 0025.0 0010.0 0080.0 0000.0 0000.0 0000.0 0000.0

01100000000000000000000000000000

$01U 0000.0 0002.5 0000.0 0001.3

5400 $01E 0000.0 0010.0 0030.0 0000.0 0000.0 0000.0 0000.0

00000000000000000000000000000000

$01U 0000.0 0000.0 0000.0 0000.0

Una vez ya se tiene un perfil creado, desde el panel de control principal, éste se puede

buscar con el explorar de archivos pulsando el botón Open. Una vez encontrado el

programa, se puede poner en marcha con Start, apareciendo de inmediato en las casillas

inferiores los parámetros de dicho programa como las duraciones y el segmento y

repetición en el cual se encuentra.

Figura 52: Zona del Panel Frontal para el Modo Programa

Una vez se pulsa Start entra en acción otro bucle que corre en paralelo que se encarga de

controlar los tiempos con un contador. Se ha puesto que funcione de forma paralela y no

dentro del sistema de estados, para evitar que pueda haber retrasos en los tiempos:

Figura 53: Bucle encargado del control del tiempo

58

Las dos variables más importantes a tener en cuenta de este bucle son las globales Time

target (s) y Time has Elapsed (marcadas en rojo). La primera es la que dice al timer en que

momento deberá activar el bit de salida a 1, y la segunda es precisamente este bit. Cada vez

que Time has Elapsed tenga valor 1 (verdadero), dentro del caso 3 del bucle principal

(Figura 54), se ejecutará la rutina Prog Mode, que se encuentra enmarcada en rojo.

Esta rutina se encarga de que cada vez que se cumpla el instante de tiempo marcado en el

archivo del programa, se envíen las dos tramas (valores y gradientes) a la cámara de la

misma fila, así como de también guardar el nuevo valor del tiempo en la variable Time

target (s) para que el contador pueda seguir su curso. En caso de tener el perfil del

programa más de una repetición, esta función también lleva a cabo la función de activar el

Reset del timer para que todo vuelva a empezar de nuevo, tantas veces como sea necesario.

Figura 54: Diagrama de bloques del caso 3 del sistema de estados

59

Y para finalizar esta sección de las cámaras Vötsch, comentar que aparte de la aplicación

principal, también se ha creado una versión reducida la cual solo lleva cabo la

monitorización, es decir, que la parte de control manual y programa no existen. La razón

de esto, es que hay dos cámaras, concretamente las más nuevas del laboratorio del

fabricante Vötsch (modelo VT7100-5), que tienen un panel táctil en el frontal para realizar

la comunicación con la cámara, que va de manera independiente al PC adjunto, y no como

las otras donde todos las acciones debían hacerse des del ordenador. Así pues, en el

ordenador conectado a la máquina se ejecutará el programa de monitorización, mientras el

usuario del laboratorio continúa con las tareas habituales mediante el panel táctil sin

problema a interferir. El único problema que surge es que solo es posible conocer los

valores de los parámetros (temp, hum…) pero no si está funcionando en modo manual o

programa y saber cuánto tiempo resta.

Figura 55: Panel Frontal de la versión reducida de la aplicación Vötsch

60

4.5 Compartir los Datos

Durante la ejecución de los programas, se obtienen una serie de datos con

información de la cámara, que se consiguen mediante la decodificación o desglose de las

tramas que el equipo de test envía al PC mediante el puerto serial. Estos datos, algunas

veces es necesario que se muestren en panel frontal, como es el caso de las cámaras

Vötsch, y otras no, como en las ACS. Lo que sí que se hace siempre es guardar toda la

información en variables de red, para que luego la aplicación final, que se estará

ejecutando en cualquier PC remoto de la empresa ya sea de sobremesa o portátil, pueda

leer todas estas variables de la librería de manera actualizada y en tiempo real, para que así

el usuario tenga una idea de que está sucediendo en las cámaras climáticas del Laboratorio

sin estar presente.

Para poder realizar esta parte de compartir datos por red, se ha tenido poner un punto de

red al lado de todos y cada uno de los PC adjuntos. De esta forma, tanto los ordenadores de

los usuarios como los de las cámaras están conectados a la misma red local de Lear

Corporation.

Cada uno de los ordenadores de la red tiene una dirección virtual (identificador) única, lo

que permite crear una relación entre cada cámara y cada identificador, lo que servirá para

poder leer la librería del ordenador que se quiera de forma individual.

Figura 56: Esquema de la red local de Lear

Una vez conectados todos lo PCs a la misma red local, es importante entender cómo se

trabaja con las variables globales.

Hay dos partes básicamente, la de escritura y la de lectura, que se pasará a explicarse a

continuación.

61

4.5.1 Escritura en las Variables de Red

El primer paso es crear una librería que contenga todas la variables que se van a

utilizar. Es importante dar un nombre adecuado a cada una de ellas, para luego poder

identificarlas y utilizarlas de la forma más rápida y clara.

Figura 57: Librerías con las variables utilizadas en ambos programas

Como se puede observar el número de variables varía según el fabricante de cámaras con

el que se esté trabajando, ya que los protocolos son distintos y ofrecen más o menos

información sobre la cámara.

Para escribir en las variables se han creado unas rutinas, ya que es un proceso que siempre

se hace de la misma manera, de esta forma se simplifica la comprensión del diagrama de

bloques y se reduce en tamaño.

Se ha dicho rutinas y no rutina, ya que no todas las variables pertenecen al mismo tipo de

datos, por eso es necesario una función para cada tipo, ya que al abrir la conexión de un

variable con la función Open Variable Connection se debe especificar qué tipo de variable

es. En total hay 4 clases diferentes: booleanas (verde), datos numéricos (naranja), cadenas

de caracteres (rosa) y timestamp (hora y fecha) (marrón).

62

Estos son los bloques de las funciones creadas, junto con el ejemplo del diagrama de

bloques de las variables booleanas:

Figura 58: Funciones de escritura y diagrama de bloques de una de ellas

Todas las funciones tienen dos entradas, la superior, que es común en todas ellas, es la

Shared Variable Refnum In que es simplemente el identificador de la variable con la que se

quiere trabajar, y la entrada inferior son los datos que se guardarán en la variable

especificada.

La URL para identificar la variable requiere de una sintaxis adecuada, tanto si es para

escritura o para lectura, y es la siguiente:

[Variable Engine]://[Host Name]/[Container Name]/[Variable Name]

Donde:

- [Variable Engine]: ni.var.psp

- [Host Name]: aquí se debe escribir el identificador del PC donde se quiere guardar

la variable o de donde se quiere leer. Para ello se debe especificar la VLS (p.ej.

VLS-20-2625). En el caso de que se desee escribir o leer del mismo ordenador se

puede usar localhost.

- [Container Name]: nombre de la librería donde esta guardada la variable. En

nuestro caso solo tenemos dos: ACSParamenters o VOTSCHParameters.

- [Variable Name]: nombre de la variable que se quiera leer/escribir.

Ejemplo: si se quisiera acceder a la variable Current Temp de las cámaras Vötsch en el

mismo ordenador donde se está ejecutando el LabVIEW, la cadena quedaría así:

63

4.5.2 Lectura de las Variables de Red

La estructura de las rutinas es la misma que para el modo escritura, solo que esta

vez en lugar de usar la función Write Variable se usa la función Read Variable.

Figura 59: Funciones de escritura y diagrama de bloques de una de ellas

4.6 Visualización de los Datos (Interfaz Gráfica)

Una vez ya se tienen corriendo las aplicaciones destinadas a ambas cámaras en los

ordenadores adjuntos, y recogen y comparten los datos de ellas de forma exitosa, es

momento de pasar a la interfaz gráfica final, donde se engloban todos los equipos de test

con todas sus respectivas variables.

Para el diseño de esta interfaz se han creado unos iconos basados en las cámaras, para una

identificación más rápida y sencilla, que funcionan también como pulsador para abrir el

submenú correspondiente a cada cámara (esta funcionalidad se explica más adelante).

Además para ayudar aún más, estos iconos se han distribuido en el panel frontal formando

lo que es el layout de la planta del laboratorio tal y como se ve en la Figura 60. De esta

forma, los iconos de la interfaz, coinciden con la realidad y en caso de mover alguna de las

máquinas también sería posible hacerlo con su equivalente virtual.

En el lado derecho de cada icono hay un semáforo para indicar el estado en el que se

encuentra la cámara: verde si la cámara está en funcionamiento, amarillo si hay presente un

error y rojo se la cámara está apagada. Y en la parte superior se encuentra un indicador de

la fecha de finalización del test. Esta fecha que es escrita por el usuario que está utilizando

la cámara, sirve para que otros usuarios tengan en constancia cuando puede quedar libre el

equipo, de esta forma se puede realizar una mayor organización de todo el laboratorio.

Debajo del semáforo también hay una pequeña casilla que sirve para indicar la cámara de

la cual se quiere obtener información, ya que no es necesario tener todo el sistema activo

consumiendo recursos del ordenador, cuando en realidad el usuario solo quiere obtener

datos de una en concreto. Hasta el momento de hacer clic en la casilla, no se muestra

ninguna información (ni fecha ni semáforo), estando el icono de la cámara ensombrecido

64

para indicarlo. En caso de no poderse comunicar incluso después de activar la casilla, en el

indicador de finalización de fecha aparecerá Can’t connect.

Aquí se muestra la interfaz gráfica descrita:

Figura 60: Panel frontal de las 2 zonas de la aplicación de la interfaz de usuario

Donde:

a) Pestaña para el cambio de zona.

b) Indicador de la fecha de finalización del test.

c) Casilla para habilitar la comunicación con la cámara climática seleccionada.

d) Semáforo de estado

e) Icono de la cámara y pulsador para entrar el submenú correspondiente a cada

cámara

65

Para el funcionamiento de los semáforos y los indicadores de la fecha, se han creado 20

bloques como el que aparece en la Figura 61, cada uno correspondiente a una cámara en

particular, en el caso mostrado en la Figura 61 es el de la ACS Discovery600C(1). Todos

los bloques están funcionando dentro de bucle while que no parará hasta pulsar el botón

de parada del programa. Cada uno de ellos se encarga de leer las variables RUN, ERROR y

END DATE, del ordenador correspondiente (el de esta cámara se puede ver que tiene la

dirección VLS-20-2625), siempre y cuando, claro está, la variable on/off (que es la casilla

que habilita la comunicación) este activada. Estas 3 variables leídas son las que permiten el

cambio de estado del semáforo (verde, amarillo o rojo) y la escritura de la fecha en el

indicador.

Se ha realizado en bloques, ya que en el caso de ampliar o reducir el número de cámaras, la

modificación del código sería muy fácil.

Figura 61: Diagrama de bloques de la parte correspondiente a una solo cámara del Bucle Principal

Como se ha comentado al principio de este apartado 4.6, los iconos no solo sirven como

identificador de cada equipo, sino que también son pulsadores que permiten acceder al

subpanel correspondiente a cada cámara. En estos subpaneles se da información más

detallada sobre el estado del equipo, como por ejemplo: temperatura, setpoints, modo de

funcionamiento, etc., por lo tanto, es dentro de estos SubVI donde se lleva a cabo la mayor

parte de la lectura de todas esas variables de red que están esperando a ser leídas desde los

PCs adjuntos a las cámaras climáticas.

Para poder controlar las pulsaciones en los iconos, se ha puesto un bucle while en paralelo

con el principal, cuyo principal elemento es una Event Structure. Esta estructura detecta

cada vez que se produce un cambio de valor en cualquiera de los 20 iconos existentes, y en

caso de producirse uno, se ejecuta el código del interior de caso al cual se ha asignado ese

cambio. En todos los casos ese código consiste en la apertura del subpanel correspondiente

a la cámara del icono pulsado.

En la Figura 62, se muestra el diagrama de bloques de este bucle, con el estructura interior

mostrando el caso para la ACS Discovery 600C, que en caso de ser ejecutado, se abriría el

VI llamado Discovery600C(1).vi (Figura 63).

66

Figura 62: Bucle encargado del control de la apertura de los submenús de la cámaras

Este panel, que pertenece a las ACS Discovery 600C, se abre en una nueva ventana

independiente de la interfaz principal después de pulsar el icono de la cámara. Cada panel

está adaptado a un equipo en concreto con sus propias variables, ya que por ejemplo, no se

tiene el mismo número si se comparan los dos fabricantes.

Figura 63: Panel frontal del submenú para la cámara ACS Discovery 600

67

Donde:

a) Parámetros relacionados con la temperatura de la cámara: temperatura actual,

valor de consigna actual, valor de consigna final e indicador LED de activación.

b) Parámetros relacionados con la humedad relativa de la cámara: humedad actual,

valor de consigna actual, valor de consigna final e indicador LED de activación.

c) Parámetros del test en ejecución.

d) Modo de funcionamiento: manual o programa.

e) Control para cambiar la fecha de finalización del test.

f) Semáforo de estado: verde si la cámara está en funcionamiento, amarillo si hay


g) Última actualización de los datos mostrados en pantalla.

h) Control de activación del sistema de mail: en caso de estar activo, si aparece

algún error en la cámara se reportará mediante mail.

i) Botón para cerrar la ventana.

j) Indicador para mostrar el nombre del error en caso de producirse uno.

k) Indicadores de las presiones en los compresores.

Y este es un ejemplo para una de las cámaras Vötsch:

Figura 64: Panel frontal del submenú para la cámara Vötsch VT7150-5

Donde:

a) Parámetros relacionados con la temperatura de la cámara: temperatura actual,

valor de consigna e indicador LED de activación.

b) Parámetros relacionados con la humedad relativa de la cámara: humedad actual,

valor de consigna e indicador LED de activación.

c) Parámetros del test en ejecución.

d) Modo de funcionamiento: manual o programa.

e) Control para cambiar la fecha de finalización del test.

f) Semáforo de estado: verde si la cámara está en funcionamiento, amarillo si hay


68

g) Última actualización de los datos mostrados en pantalla.

h) Control de activación del sistema de mail: en caso de estar activo, se reportará

mediante correo si aparece algún error.

i) Botón para cerrar la ventana.

j) Indicador para mostrar el nombre del error en caso de producirse uno.

k) Parámetros relacionados con la velocidad del ventilador: valor actual, valor de

consigna e indicador LED de activación.

Para poder actualizar todos los parámetros que aparecen en estos paneles, sea de la cámara

que sea, en la parte del diagrama de bloques, se ha dispuesto de un bucle, en el interior del

cual se leen de forma ininterrumpida, todas las variables de la librería del ordenador

especificado con la dirección. En este caso, la dirección es VLS-20-2625, y al ser única e

invariable a lo largo del tiempo, es rápido establecer una relación entre cada ordenador con

su dirección, cosa que facilita el desarrollo de los subpaneles.

Figura 65: Bucle del subpanel encargado de leer todos los parámetros

69

5 Próximos Pasos

Durante el desarrollo del proyecto han surgido nuevas ideas y propuestas, varias de

ellas gracias al poder comentar las aplicaciones con otros compañeros de la empresa y ver

las necesidades reales que hay, las cuales se han descartado por el tiempo limitado del cual

se disponía pero que son muy interesantes para seguir ampliando el proyecto:

- Monitorizar las cámaras desde el exterior de la empresa

Actualmente, durante los periodos vacacionales (por ejemplo Navidad) los trabajadores

hacen turnos para ir a la empresa y comprobar que los test que se habían puesto en marcha

siguen con normalidad. Para evitar estos desplazamientos, una buena solución sería la

publicación del Panel Frontal de la aplicación final en una página web privada, de esta

forma, desde un ordenador personal en casa se podría saber si todo funciona

correctamente.

- Control de las cámaras en lugar de solo monitorizarlas

Con la realización de este proyecto se ha conseguido poder monitorizar el estado de las

cámaras climáticas remotamente, pero el siguiente paso lógico comporta no solo

monitorizarlas sino también controlarlas. Para conseguirlo, sería necesario crear una

comunicación bidireccional, para poder enviar datos tanto de los ordenadores adjuntos de

las cámaras a los ordenadores remotos como viceversa. Además, se tendría que hacer una

aplicación como la que se ha creado para este proyecto en las Vötsch pero para las ACS

(sustituiría al WinKratos), de esta forma con la ayuda de las variables globales se podrían

cambiar los parámetros de los equipos al tener los programas hechos totalmente con

LabVIEW, lo que llevaría un control absoluto de las comunicaciones.

- Enviar datos del datalogger

Y una última mejora pasaría por enviar los datos del datalogger, que es toda la

información que se extrae del ensayo realizado (parámetros cámara/valores del prototipo),

al ordenador remoto que se eligiera. De esta forma quedaría centralizada toda información

en el PC del lugar de trabajo del usuario, mejorando la productividad.

70

6 Conclusiones

- Entorno LabVIEW:

La plataforma LabVIEW ha proporcionado una herramienta muy eficaz para poder

elaborar cualquier aplicación que se tuviera en mente gracias a la gran cantidad de

posibilidades y funciones que ofrece en cualquier ámbito.

Además, gracias al lenguaje G, la curva de aprendizaje ha sido muy elevada, es decir, que

en poco tiempo he podido mejorar substancialmente las habilidades de programación con

este entorno, empezando desde un punto casi nulo.

Y por último, LabVIEW ha permitido la creación de unas interfaces visuales profesionales

y de gran calidad, punto clave sobre todo para la aplicación final, sin un coste de tiempo

demasiado alto, cosa que he agradecido para poder dedicar más tiempo a lo que a código se

refiere.

- Académicas:

Al finalizar el periodo de desarrollo, se han podido cumplir todos los objetivos que se

plantearon al principio de una manera muy positiva, obteniendo una serie de software

completamente funcional y actualmente operativo en los ordenadores, que ayuda a la

empresa a ser más eficiente y productiva en la etapa del proceso en la cual se engloba este

proyecto.

- Personales:

Gracias a la oportunidad de poder elaborar el trabajo de final de grado dentro de la empresa

Lear de Valls, he podido obtener una aproximación y nuevos conocimientos del mundo

laboral y del funcionamiento y desarrollo de proyectos de una empresa puntera en el

ámbito tecnológico como es Lear Corporation.

Así como también, conseguir gran base de conocimientos en un programa ampliamente

utilizado en todo lo que es el sector industrial, como es LabVIEW, cosa que nunca está de

más y que muy posiblemente pueda utilizar o me pueda servir en un futuro.

71

7 Bibliografía

1. LabVIEW Basics II Development Course Manual. Course Software Version 8.0.

Edición de Mayo de 2009

2. LabVIEW Core 3 Course Manual. Course Software Version 2009. Edición de Abril

de 2010

3. ACS Environmental Chambers [en línea]. Angelantoni Test Technologies.

[Consulta: noviembre de 2013]. Disponible en:

http://www.acsenvironmentaltestchambers.com/

4. Comunicaciones serie por puerto RS-232 y LabVIEW [en línea]. Jose Félix

[Consulta: noviembre de 2013]. Disponible en:

http://perso.wanadoo.es/jovilve/rs232.html

5. Utilización de los puertos serial y paralelo de una PC usando LabVIEW [en línea].

Rafael Chacón, Jose Andricksin, Juan Parada, 2003. [Consulta: Noviembre de

2013]. Disponible: http://www.unet.edu.ve/~ielectro/Guia%20de%20puertos.pdf

6. Finding, Reading and Writing Shared Variables Programmatically [en línea]. NI,

junio 2010. [Consulta: diciembre de 2013]. Disponible en:

http://zone.ni.com/reference/en-XX/help/371361G-01/lvconcepts/usingdynvarapi/

7. Making Shared Variables Available on a Network [en línea]. NI, junio 2011.

[Consulta: diciembre de 2013]. Disponible en: http://zone.ni.com/reference/en-

XX/help/371361H-01/lvconcepts/sv_deploying/

8. Using ActiveX with Labview [en línea]. NI, junio 2011. [Consulta: noviembre de

2013]. Disponible en: http://zone.ni.com/reference/en-XX/help/371361H-

01/lvconcepts/using_activex_with_labview/

9. Comunicación serial utilizando LabVIEW con un Microcontrolador [en línea].

Septiembre 2011. [Consulta: noviembre de 2013]. Disponible en:

http://www.ni.com/white-paper/7907/es/

10. Creating Qualitty UIs with LabVIEW [en línea]. Grant Hiembach, LabVIEW

Product Manager. [Consulta: enero de 2013]. Disponible en:

http://www.ieee.li/pdf/viewgraphs/creating_quality_uis_with_labview.pdf

11. How Do I Deply Network Shared Variables from a Compiled Executable? [en

línea].Septiembre 2013. [Consulta: diciembre de 2013]. Disponible en:

http://digital.ni.com/public.nsf/allkb/04D9A85B6967EE87862571140065EEC6

12. RS232 serial spy monitor cable [en línea].Febrero 2013. [Consulta: noviembre de

2013]. Disponible en: http://www.lammertbies.nl/comm/cable/RS-232-spy-

monitor.html

13. LabVIew Advanced Virtual Architects [en línea]. [Consulta: diciembre 2013].

Disponible en: http://lavag.org/

14. Sort 2D Array by First Column Values [en línea]. Jared_B, 23 junio 2010.

[Consulta: febrero 2014]. Disponible en: https://decibel.ni.com/content/docs/DOC-

12264

15. Get column from a 2D array [en línea]. LaRisa_M, 22 abril 2009. [Consulta:

febrero 2014]. Disponible en: https://decibel.ni.com/content/docs/DOC-4526

http://www.acsenvironmentaltestchambers.com/

http://perso.wanadoo.es/jovilve/rs232.html

http://www.unet.edu.ve/~ielectro/Guia%20de%20puertos.pdf

http://zone.ni.com/reference/en-XX/help/371361G-01/lvconcepts/usingdynvarapi/

http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/sv_deploying/

http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/sv_deploying/

http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/using_activex_with_labview/

http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/using_activex_with_labview/

http://www.ni.com/white-paper/7907/es/

http://www.ieee.li/pdf/viewgraphs/creating_quality_uis_with_labview.pdf

http://digital.ni.com/public.nsf/allkb/04D9A85B6967EE87862571140065EEC6

http://www.lammertbies.nl/comm/cable/RS-232-spy-monitor.html

http://www.lammertbies.nl/comm/cable/RS-232-spy-monitor.html

http://lavag.org/

https://decibel.ni.com/content/docs/DOC-12264



72

16. Hide close buttion of the front panel windows [en línea]. P@Anand, 6 febrero 2012.

[Consulta: marzo 2014]. Disponible en: http://forums.ni.com/t5/LabVIEW-Idea-

Exchange/Hide-close-button-of-the-front-panel-windows/idi-p/2014720

17. Remote Panels in LabVIEW – Distributed Applicaction Development [en línea]. 13

febrero 2013. [Consulta: noviembre de 2013]. Disponible en:

http://www.ni.com/white-paper/4791/en/

18. Buffered Network-Published Shared Variables: Components and Architecture [en

línea]. 9 septiembre 2013. [Consulta: enero de 2013]. Disponible en:


19. FabulaTech Serial Port Splitter [en línea]. Fabulatech, 2014. [Consulta: enero de

2013]. Disponible en: http://www.fabulatech.com/serial-port-splitter.html

20. Test systems & Instrumentation. Cámaras climáticas [en línea]. Aries Test systems

& Instrumentation, 2012. [Consulta: mayo de 2013]. Disponible en:

http://www.ariestesting.com/products/distributed-products/ensayos-

ambientales/camaras-climaticas/

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Hide-close-button-of-the-front-panel-windows/idi-p/2014720

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Hide-close-button-of-the-front-panel-windows/idi-p/2014720



http://www.fabulatech.com/serial-port-splitter.html

http://www.ariestesting.com/products/distributed-products/ensayos-ambientales/camaras-climaticas/

http://www.ariestesting.com/products/distributed-products/ensayos-ambientales/camaras-climaticas/

73

8 Anexos

8.1 Anexo A

Bloques e ítems utilizados en la realización del software con LabVIEW y que han

aparecido en las figuras durante el desarrollo de la memoria del proyecto:

Add Function: calcula y devuelve la suma de ambas entradas.

And Function: si las dos entradas son verdaderas, la función devuelve verdadero, en caso

contrario, devuelve falso.

Array Size Function: devuelve el número de elementos en cada dimensión del array.

Array to Cluster Function: convierte un array de 1 dimensión en un cluster de elementos

del mismo tipo que los del array.

Automation Open Function: devuelve un automation refnum, que apunta a un objeto

Active X concreto.

Build Array Function: concatena múltiples arrays o añade elementos a un array de n

dimensiones.

Byte Array to String Function: convierte un array de bytes sin signo representando

caracteres ASCII en una cadena de caracteres.

74

Case Structure: contiene uno o más subdiagramas, o casos, de los cuales se ejecuta uno

cuando se la estructura se ejecuta. El valor cableado al terminal selector, determina que

caso se debe ejecutar.

Close Reference Function: cierra un refnum asociado con un VI abierto, objeto VI, una

instancia de aplicación abierta, o un objeto .NET o ActiveX.

Close Variable Connection Function: cierra un refnum asociado a un VI abierto, objeto VI,

instancia abierta de una aplicación o un objeto .NET o ActiveX.

Concatenate String Function: concatena las cadenas y 1D arrays de la entrada, en una única

cadena de salida.

Current VI’s Path Function: devuelve la ruta de acceso al archivo del VI actual. Si el VI

nunca se ha guardado, esta función devuelve <Not a path>

Decimal String to Number Function: convierto los caracteres numéricos en una cadena,

empezando en un offset, a un entero de decimal.

Decrement Function: resta 1 al valor de entrada.

75

Delete from Array Function: elimina un elemento o subarray de un array de n-dimensión

empezando en un index y con una longitud determinada.

Divide Function: calcula el cociente de las dos entradas.

Elapsed Time Express VI: timer encargado de contar el número especificado de segundos.

Un vez cumplido el tiempo, la salida Time has Elapsed devuelve verdadero.

Equal to 0? Function: devuelve Verdadero si x es igual a 0, sino devuelve falso.

Equal? Function: devuelve Verdadero si x es igual a y, sino retorna Falso.

Event Strucuture: espera hasta que se produzca un evento, luego ejecuta el caso apropiado

para manejar ese evento. Esta estructura también puede agotar el tiempo de espera de una

notificación mediante la conexión de un valor al terminal del tiempo. En caso de agotarse

el tiempo se ejecutará el caso de dicho suceso.

76

Format into String Function: da formato a una cadena, ruta, timestamp, booleano o dato

numérico en forma de texto.

Get Date/ Time in Seconds: devuelve una marca de tiempo de la hora actual. LabVIEW

calcula esta marca de tiempo usando el número de segundos transcurridos desde las

12:00h, del viernes 1 de enero de 1904, Tiempo Universal.

Global Variable: usar las variables para acceder y transferir datos entre varios VIs.

Greater or Equal? Function: devuelve Verdadero si x es más grande o igual que y, sino

devuelve Falso.

Increment Function: suma 1 al valor de entrada.

Index Array Function: devuelve el elemento o subarray de un array de n-dimensión situado

en el index especificado.

Initialize Array Function: crea un array n-dimensional en el que cada elemento es

inicializado con el valor de la entrada element.

Insert into Array Function: inserta un elemento o subarray en un array de n-dimensión en

el punto especificado en la entrada index.

77

Invoke Node: invoca un método o acción en una referencia. La mayoría de métodos tienen

asociados parámetros.

Local Variable: usar las variables locales para escribir o leer de uno de los indicadores o

controles del panel frontal de un VI.

Merge Errors Function: fusiona clusters de errores de diferentes funciones.

Multiply Function: devuelve la el resultado de la multiplicación de las dos entradas.

Not Function: niega el valor de la entrada. Si x es Falso devuelve Verdadero, y viceversa.

Not Equal to 0? Function: devuelve Verdadero si x no es igual a 0, sino devuelve Falso.

Not Equal? Function: retorna Verdadero si x no es igual a y, sino devuelve Falso.

Number to Boolean Array Function: convierte un número entero o de punto fijo en un

array booleana. Si se conecta a la entrada un número entero, el array de booleanos devuelto

tendrá 8, 16, 32 o 64 bits dependiendo del número de bits el entero. El elemento 0 se

corresponde con el bit menos significativo.

Number to Decimal String: convierte un número a una cadena de dígitos decimales.

78

Open Variable Connection Function: obre una conexión de una variable compartida.

Open VI Reference Function: devuelve una referencia a un VI, control o variable global

especificada por una cadena o ruta a la ubicación del VI en el disco.

Or Function: si las dos entradas son Falsas la función retorna Falso, sino retorna

Verdadero.

Property Node: obtiene (lee) y/o edita (escribe) propiedades de una referencia.

Read Variable: lee una variable compartida en red, variable I/O, o contenedor de variables

I/O.

Register Event Callback Function: registra un VI que será llamado cuando se produzca un

evento. SE utiliza esta función para registrar y manejar eventos .NET y ActiveX.

LabVIEW utiliza el tipo de referencia de entrada conectado a cada elemento para

determinar los hechos por los cuales se puede registrar.

Scan from String Function: escanea la cadena de entrada y la convierte en otra cadena

acorde al formato indicado.

79

Search and Replace String Function: sustituye una o todas las instancias de una subcadena

por otra subcadena.

Search / Split String Function: busca un determinado carácter o subcadena en una cadena

de caracteres, y la divide en ese punto, entregando las dos subseries y el offset de la

búsqueda.

Send Outlook Mail ActiveX VI: envía un correo mediante Microsoft Outlook a la

dirección y con los datos especificados.

Simple Error Handler: indica si se ha producido un error. En caso de producirse uno, este

VI devuelve una descripción del error y, opcionalmente, muestra un cuadro de diálogo.

Start Asyncronous Call: inicia una llamada asíncrona al VI indicado en la entrada

reference.

String Subset Function: devuelve la subcadena de la cadena de entrada que empieza en el

offset indicado y que contiene el número de caracteres especificado.

Subtract Function: calcula diferencia entre las entradas.

80

Type Cast Function: convierte la entrada conectada a x al tipo de datos especificado en

type.

Unbundle by Name Function: retorna el elemento del cluster con el nombre que se

especifica.

Unregister for Events Function: anula todos los eventos asociados con un refnum de

registro de eventos.

Variant to Data Function: convierte datos con el formato variant a un tipo de datos

reconocido por LabVIEW.

VISA Clear Function: limpia los buffers de entrada y de salida del dispositivo.

VISA Close Function: cierra una sesión del dispositivo o un objeto de evento.

VISA Configure Serial Port Function: inicializa el puerto serial especificado por el VISA

resource name con la opciones elegidas.

81

VISA Read Function: lee el número especificado de bytes del dispositivo o interfaz

especificado por el VISA resource name y devuelve los datos por el read buffer.

VISA Write Function: escribe los datos de la entrada en el dispositivo o interfaz

especificada.

Wait (ms) Function: espera el número especificado de milisegundos y devuelve el valor del

temporizador de milisegundos. Esta función hace llamadas al sistema de manera asíncrona,

pero el nodo en sí mismo funciona de forma síncrona. Por lo tanto, no se completa la

acción hasta que el tiempo especificado se haya cumplido.

While Loop: Repite el código que está dentro de su subdiagrama hasta que se produce una

condición específica. Un bucle While siempre se ejecuta al menos una vez.

82

8.2 Anexo B

Manual del protocolo de comunicación de las cámaras climáticas de la familia Challenger

del fabricante ACS.

110

8.3 Anexo C

Manual del protocolo de comunicación de las cámaras climáticas de la familia Discovery

del fabricante ACS.

136

8.4 Anexo D

Manual del protocolo de comunicación de las cámaras climáticas de la familia Thermal

Shock del fabricante ACS. Dado que los apartados: Introduction, Error Detection,

Communication errors, Identification of a data packet, Modbus functions, Fields

Description, Modbus functions descriptions, Communication parameters, Code examples

Siemens S7 memory layout vers2.0 y Chamber control at a glance son iguales que los de

la familia Discovery (Anexo C), se empezara este anexo en el apartado Reading Area.

146

8.5 Anexo E

Manual del protocolo de comunicación de las cámaras climáticas del fabricante Vötsch.

sergi molina mellado control telemÁtico de ...deeea.urv.cat/public/propostes/pub/pdf/2175pub.pdf2...

Documents