sergi molina mellado control telemÁtico de ...deeea.urv.cat/public/propostes/pub/pdf/2175pub.pdf2...
Post on 26-Apr-2018
219 Views
Preview:
TRANSCRIPT
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
1
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
8 Challenge 600 ACS Angelantoni Temperatura y humedad
9 VT 7150-5 Vötsch Temperatura y humedad
10 Challenge 600 ACS Angelantoni Temperatura y humedad
11 VT 7100-5 Vötsch Temperatura y humedad
12 Challenge 1200 ACS Angelantoni Temperatura y humedad
13 VT 7100-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
17 Challenge 160 ACS Angelantoni Temperatura y humedad
18 Challenge 160 ACS Angelantoni 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
36 [54(dec)]: Comprobación de errores
Respuesta 1: 11 03 F8 [248 bytes de info] 83 98
11 [17(dec)]: Dirección de la cámara
03 [03(dec)]: Función de lectura
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.
93 [131(dec)]: Comprobación de errores
98 [152(dec)]: Comprobación de errores
Pedido2: 11 03 08 38 00 7d 04 D6
11 [17(dec)]: Dirección de la cámara
03 [03(dec)]: Función de lectura
08 [08(dec)]: Dirección de memoria H
38 [56(dec)]: Dirección de memoria L
00 [00(dec)]: Leer 0 registros H = 0 bytes
7D [125(dec)]: Leer 125 registros L = 250 bytes
46 [70(dec)]: Comprobación de errores
36 [54(dec)]: Comprobación de errores
Respuesta 2: 11 03 FA [250 bytes de info] 50 F6
11 [17(dec)]: Dirección de la cámara
03 [03(dec)]: Función de lectura
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.
93 [131(dec)]: Comprobación de errores
98 [152(dec)]: Comprobación de errores
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
11 [17(dec)]: Dirección de la cámara
03 [03(dec)]: Función de lectura
00 [00(dec)]: Dirección de memoria H
00 [00(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
BB [187(dec)]: Comprobación de errores
Respuesta 1: 11 03 F8 [248 bytes de info] CRC
11 [17(dec)]: Dirección de la cámara
03 [03(dec)]: Función de lectura
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
11 [17(dec)]: Dirección de la cámara
03 [03(dec)]: Función de lectura
00 [00(dec)]: Dirección de memoria H
7D [125(dec)]: Dirección de memoria L
00 [00(dec)]: Leer 0 registros H = 0 bytes
7D [125(dec)]: Leer 125 registros L = 250 bytes
46 [70(dec)]: Comprobación de errores
36 [54(dec)]: Comprobación de errores
Respuesta 2: 11 03 FA [250 bytes de info] CRC
11 [17(dec)]: Dirección de la cámara
03 [03(dec)]: Función de lectura
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
- <CR> Retorno de carro
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
- <CR> Retorno de carro
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.
Figura 44: Diagrama de bloques del caso 1
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
- <CR> Retorno de carro
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
- <CR> Retorno de carro
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:
Figura 46: Diagrama de bloques del caso 2
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:
Tiempos Valores T Valores H Valores F Gradientes T Gradientes H Gradientes F
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:
Tiempos Valores T Valores H Valores F Gradientes T Gradientes H Gradientes F
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
presente un error y rojo se la cámara está apagada.
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
presente un error y rojo se la cámara está apagada.
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
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:
http://www.ni.com/white-paper/12176/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/
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.
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
8.3 Anexo C
Manual del protocolo de comunicación de las cámaras climáticas de la familia Discovery
del fabricante ACS.
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
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.
137
138
139
140
141
142
143
144
145
146
8.5 Anexo E
Manual del protocolo de comunicación de las cámaras climáticas del fabricante Vötsch.
147
148
149
150
151
152
153
154
155
156
top related