sistema de adquisicion supervision y control de plantas de proceso
TRANSCRIPT
UNIVERSIDAD DE ORIENTE
NÚCLEO ANZOÁTEGUI
ESCUELA DE INGENIERÍA Y CIENCIAS APLICADAS
DEPARTAMENTO DE ELECTRICIDAD
“SISTEMA DE ADQUISICIÓN, SUPERVISIÓN Y CONTROL DE
PEQUEÑAS PLANTA DE PROCESOS BASADO EN
TECNOLOGÍA LIBRES”
Realizado Por:
CESAR JESÚS BRITO BOLÍVAR
C.I. 19.675.148
Trabajo de Grado Presentado Ante la Universidad de Oriente Como
Requisito Parcial para Obtener el Título de:
INGENIERO ELECTRICISTA.
Barcelona, Febrero 2013
UNIVERSIDAD DE ORIENTE
NÚCLEO ANZOÁTEGUI
ESCUELA DE INGENIERÍA Y CIENCIAS APLICADAS
DEPARTAMENTO DE ELECTRICIDAD
“SISTEMA DE ADQUISICIÓN, SUPERVISIÓN Y CONTROL DE
PEQUEÑAS PLANTA DE PROCESOS BASADO EN
TECNOLOGÍA LIBRES”
ASESOR:
_____________________
Barcelona, Febrero 2013
Ing. Danilo Navarro
UNIVERSIDAD DE ORIENTE
NÚCLEO ANZOÁTEGUI
ESCUELA DE INGENIERÍA Y CIENCIAS APLICADAS
DEPARTAMENTO DE ELECTRICIDAD
“SISTEMA DE ADQUISICIÓN, SUPERVISIÓN Y CONTROL DE
PEQUEÑAS PLANTA DE PROCESOS BASADO EN
TECNOLOGÍA LIBRES””
TRABAJO DE GRADO APROBADO POR EL DEPARTAMENTO DE
ELECTRICIDAD DE LA UNIVERSIDAD DE ORIENTE.
El Jurado hace constar que asignó a esta Tesis la calificación de:
_______________________ _______________________
Barcelona, Febrero 2013
Ing. Verena Mercado
Jurado Principal
Ing. Luis Parraguez
Jurado Principal
iv
RESOLUCIÓN
De acuerdo al artículo 41 del Reglamento de Trabajos de Grado
de la Universidad de Oriente:
“Los trabajos de grado son exclusiva propiedad de la
Universidad de Oriente y solo podrán ser utilizados a otros
fines con el consentimiento del Consejo de Núcleo
respectivo, quien lo participará al Consejo Universitario”
v
DEDICATORIA
vi
AGRADECIMIENTOS
vii
RESUMEN
El sistema desarrollado en este trabajo de investigación es una
alternativa metodológica para el diseño e implementación de un sistema de
adquisición supervisión y control de bajo costo, utilizando herramientas de
software y hardware libres. Esta se basara en dos partes, el primero es el
desarrollo de un hardware de adquisición, centrado en un microcontrolador
con conexión USB, que se encarga de recibir la señales emanadas de los
sensores luego de ser tratadas por unos circuitos de acondicionamiento,
intervenir en el proceso a través de los actuadores, y a su vez enviar esos
datos a través del puerto USB a un ordenador, donde se encontrara un
software multiplataforma llamado HmiUdo (segunda parte) el cual es una
interfaz hombre-máquina (HMI) que se encargara de muestrear los datos del
proceso de forma gráfica para luego almacenarlas en una base de datos.
Para la verificación y validación de la metodología se utilizó 3
micrcontroladores uno de 28 pin que es el 18f2550, uno de 40 pin 18f4550 y
el atmega 328 junto a otros componentes electrónicos.
viii
ÍNDICE
RESOLUCIÓN ............................................................................................... IV
DEDICATORIA ............................................................................................... V
AGRADECIMIENTOS ................................................................................... VI
RESUMEN .................................................................................................... VII
ÍNDICE ......................................................................................................... VIII
LISTA DE FIGURAS ................................................................................... XIII
LISTA DE TABLAS ..................................................................................... XV
CAPITULO1: INTRODUCCIÓN .................................................................... 16
1.1 PLANTEAMIENTO DEL PROBLEMA................................................. 16
1.2. JUSTIFICACIÓN Y ALCANCE. ......................................................... 18
1.3. OBJETIVOS. .................................................................................. 18
1.3.1. Objetivo General. ......................................................................... 18
1.3.2. Objetivos Específicos ................................................................... 18
1.4. MARCO METODOLÓGICO ............................................................ 19
1.4.1. Tipo de Investigación. .................................................................. 19
1.4.2. Nivel de Investigación .................................................................. 19
1.4.3. Técnicas de Investigación ........................................................... 20
1.5 ETAPAS DEL PROYECTO .................................................................. 20
1.5.1. Etapa 1. Revisión Bibliográfica. ................................................... 20
1.5.2. Etapa 2. Descripción de las Premisas y Criterios para el Diseño. 21
1.5.3. Etapa 3. Establecimiento de una Estructura Base para la
utilización de los Microcontroladores de Gama media-alta como tarjetas
de adquisición de datos. ........................................................................ 21
1.5.4. Etapa 4. Desarrollo del Programa para la Interfaz Hombre-
Maquina utilizando Software Libre. ........................................................ 21
ix
1.5.5. Etapa 5. Validación del Funcionamiento del Sistema Diseñado. . 22
1.5.6. Etapa 6. Redacción y Presentación de Trabajo de Grado. ......... 22
1.6. ORGANIZACIÓN DEL TEXTO ........................................................... 22
CAPITULO 2: MARCO TEÓRICO ................................................................ 24
2.1. FUNDAMENTO TEÓRICOS. ............................................................ 24
2.1.1. Interfaz Hombre Maquina (HMI) .................................................. 24
2.1.2. Adquisición de Datos. .................................................................. 26
2.1.3. Tarjetas de Adquisición de Datos. ............................................... 27
2.1.4. Microcontroladores. ..................................................................... 27
2.1.3. Hardware Libre. ........................................................................... 30
2.1.4. Arduino ........................................................................................ 30
2.1.5. Pingüino. ...................................................................................... 31
2.1.6. Interfaz Serie ............................................................................... 32
2.1.7. Bus Serie Universal (USB) ........................................................... 33
2.1.8. Simulador de Circuitos ISIS Proteus. ........................................... 41
2.1.9. MPLAB IDE .................................................................................. 42
2.1.10. MPLAB C18 ............................................................................... 43
2.1.11. Software Libre (Free Software) y Software de Código Abierto
(Open Source Software) ........................................................................ 43
2.1.12. Python ........................................................................................ 48
2.1.13. wxPython ................................................................................... 49
2.1.14. PyUSB ....................................................................................... 50
2.1.15. PySerial ..................................................................................... 50
2.1.17. Sqlite3 ........................................................................................ 52
CAPITULO 3. PREMISAS DE DISEÑO DEL SISTEMA .............................. 54
3.1 SISTEMAS HMI/SCADAS ................................................................... 54
3.2 FUNCIONES DEL SOFTWARE DE DESARROLLO DE SISTEMAS
HMI/SCADA. ............................................................................................. 55
3.3 DESARROLLO DE APLICACIONES HMI. ........................................... 57
x
3.4. ESTÁNDAR ANSI /ISA 5.1 2009 ......................................................... 57
3.4.1. Identificación y Símbolos de Instrumentación. ............................. 57
3.5 ESTÁNDAR ISA-5.5-1985. ................................................................. 66
3.5.1. Símbolos Gráficos para Visualización de Procesos. .................... 66
3.5.2. Color. ........................................................................................... 66
3.6. OPCIONES DE CONECTIVIDAD USB. .............................................. 68
3.6.1. Transceivers USB. ...................................................................... 68
3.6.2. Conversores USB a Interfaz Serial o Paralela. ........................... 69
3.6.3. Controladores de Periféricos. ..................................................... 71
3.7. DISEÑO ESTRUCTURAL DEL SISTEMA .......................................... 73
CAPITULO 4 HARDWARE DE ADQUISICIÓN ............................................ 77
4.1. HARDWARE DE ADQUISICIÓN DE DATOS UTILIZANDO ARDUINO Y
PINGÜINO. ................................................................................................ 77
4.1.1. Estructura Firmware Archivo principal Arduino (Arduino Tarjeta
Adq.pde). ............................................................................................... 78
4.1.2. Estructura Firmware Archivo Principal Pingüino (Pingüino
TarjetaAdq.pde) ..................................................................................... 80
4.2. HARDWARE DE ADQUISICIÓN UTILIZANDO
MICROCONTROLADDOR PIC Y COMPILADOR C18 DE MPLAB IDE. ... 82
4.2.1 Estructura Firmware Main.c (Programa principal) ....................... 84
4.2.2 Ejemplo de Aplicación de Estructura ........................................... 88
4.2.3. Circuito Electrónico de la Tarjeta de Adquisición de Datos basado
en Microcontrolador pic 18f2550 y 18f4550. .......................................... 99
CAPITULO 5. DISEÑO SOFTWARE HMIUDO .......................................... 101
5.1 SOFTWARE HMI_UDO. .................................................................... 101
5.2 ESTRUCTURA DEL SOFTWARE HMI_UDO. ................................... 101
5.2.1 HMI_UDO.py .............................................................................. 102
5.2.2 Proceso_Virtual.py ...................................................................... 105
5.2.3. Obj_Comando.py ....................................................................... 108
xi
5.2.4. Graficar_Proceso.py .................................................................. 122
5.2.5. Mando_Proceso.py .................................................................... 127
5.2.6. Base_Datos.py. ......................................................................... 130
5.2.7. Serial_Conect.py ....................................................................... 133
5.2.8. USB_Pic_Conect.py .................................................................. 136
5.2.9. CrearBaseDatos.py .................................................................... 138
CAPITULO 6. .VALIDACIÓN DEL SISTEMA HMI_UDO ........................... 139
6.1. VERIFICACIÓN CON PLANTA P1. ........................................................... 144
6.2. VERIFICACIÓN CON PLANTA ARMFIELD FM-51. ...................................... 155
6.2.1- Sensor Flujo .............................................................................. 156
6.2.2-Sensor de presión 6CF6G .......................................................... 157
6.2.3. El Sensor LM35. ........................................................................ 158
6.2.4. Adaptación del Sistema HMI_UDO a la Planta Armifield Fm51. 159
CONCLUSIÓN ............................................................................................ 164
RECOMENDACIÓN Y TRABAJOS A FUTURO. ....................................... 166
BIBLIOGRAFÍA .......................................................................................... 167
APENDICE ................................................................................................. 168
APÉNDICE. 1 GUÍA REFERENCIAL LENGUAJE ARDUINO. ............... 169
APÉNDICE 2. GUÍA REFERENCIAL LENGUAJE ARDUINO. ................ 171
APÉNDICE 3. GUÍA REFERENCIAL LENGUAJE PYTHON. .................. 172
APÉNDICE 4. GUÍA REFERENCIAL WXPYTHON ................................. 176
APÉNDICE 5. GUÍA REFERENCIAL C18 COMPILER ........................... 180
APÉNDICE 6. SCRIPT PRINCIPAL HMI_UDO.PY .................................. 190
APÉNDICE 7. SCRIPT PARA CREAR BASE DE DATOS ....................... 191
APÉNDICE 8. SCRIPT BASE_DATOS.PY (18F2550) ................................. 192
APÉNDICE 9. SCRIPT PROCESO_VIRTUAL.PY (18F2550) ........................ 193
APÉNDICE 10. SCRIPT OBJ_COMANDO.PY (18F2550) ............................ 194
APÉNDICE 11. SCRIPT GRAFICAR_PROCESO.PY (18F2550) .................... 199
xii
APÉNDICE 12. SCRIPT MANDO_PROCESO.PY (18F2550) ........................ 201
APÉNDICE 13. SCRIPT PROCESO_VIRTUAL.PY (18F4550) ...................... 202
APÉNDICE 14. SCRIPT OBJ_COMANDO.PY (18F4550) ............................ 203
APÉNDICE 15. SCRIPT BASE_DATOS.PY (18F4550) ............................... 209
APÉNDICE 16. SCRIPT GRAFICAR_PROCESO.PY (18F4550) .................... 210
APÉNDICE 17. SCRIPT MANDO_PROCESO.PY (18F4550) ........................ 212
APÉNDICE 18. SCRIPT BASE_DATOS.PY (FM51) ..................................... 213
APÉNDICE 19. SCRIPT SERIAL_CONECT.PY (FM51) ................................ 213
APÉNDICE 20. SCRIPT PROCESO_VIRTUAL.PY (FM51) ............................ 213
APÉNDICE 21. SCRIPT OBJ_COMANDO.PY (FM51) .................................. 213
APÉNDICE 22. SCRIPT GRAFICAR_PROCESO.PY (FM51) ......................... 213
APÉNDICE 23. SCRIPT GRAFICAR_PROCESO.PY (FM51) ......................... 213
APÉNDICE 24. SCRIPT MANDO_PROCESO.PY (FM51) ............................. 213
ANEXOS ..................................................................................................... 214
ANEXO A. LISTA DE MATERIALES PARA LA CONSTRUCCIÓN DE TARJETA
ADQ18F2550 ........................................................................................... 216
ANEXO B. LISTA DE MATERIALES PARA LA CONSTRUCCIÓN DE TARJETA
ADQ18F4550 ........................................................................................... 217
ANEXO C. CIRCUITO ELECTRÓNICO DE LA TARJETA ADQ PIC 18F4550. ...... 218
ANEXO D. CIRCUITO ELECTRÓNICO DE LA TARJETA ADQ PIC 18F2550. ....... 219
xiii
LISTA DE FIGURAS
Figura 2.0.1 Esquema de una HMI.Fuente:(Rodriguez, p, (2007)) ............... 25
Figura 2.0.2 Estructura General de un microcontrolador. ............................ 28
Figura 2.0.3 Conector USB tipo A (izquierda) y tipo B (derecha). ................. 38
Figura 2.0.4 Conector USB Mini tipo A (izquierda) y tipo B (derecha) .......... 38
Figura 3.0.1 Diagrama lógico y tabla de verdad del Transceiver USB .......... 68
Figura 3.0.2 Diagrama de bloques del FT232 ............................................... 70
Figura 3.0.3 Esquema estructural del Sistema ............................................. 74
Figura 3.0.4 Esquema estructural del sistema (Interfaces) ........................... 75
Figura 3.0.5 Esquema estructural del sistema (Interfaces detallada) ........... 76
Figura 4.0.1 Diagrama de Flujo del Firmware Arduino. ................................. 79
Figura 4.0.2 Diagrama Flujo Firmware Pingüino ........................................... 81
Figura 4.0.3 Estructura del directorio Firmware Framework Usb ................. 83
Figura 4.0.4 Tarjeta de Adquisicion con pic 18f4550 .................................... 99
Figura 4.0.5 Tarjeta de Adquisición con pic 18f2550 .................................. 100
Figura 5.0.1 Estructura de Software HMI_UDO .......................................... 102
Figura 5.0.2 HMI_UDO ventana principal ................................................... 103
Figura 5.0.3 Proceso Virtual ....................................................................... 108
Figura 5.0.4 Animación Texto ..................................................................... 109
Figura 5.0.5 Animación Corte Rectagular .................................................. 110
Figura 5.0.6 Tuberia Horizontal................................................................... 111
Figura 5.0.7 Tuberia Vertical ....................................................................... 112
Figura 5.0.8 Escala Verical Izquierda ......................................................... 112
Figura 5.0.9 Escala Verical Derecha ........................................................... 113
Figura 5.0.10 Escala Horizontal Inferior ...................................................... 114
Figura 5.0.11 Escala Horizontal Superior ................................................... 114
Figura 5.0.12 Imagen importada por el Comando....................................... 115
Figura 5.0.13 Datos Recibidos Arduino ...................................................... 135
xiv
Figura 5.0.14 Datos Recibido Arduino Organizado en un Array ................. 136
Figura 5.0.15 Datos Recibidos Por Puerto USB PIC 18f ............................ 138
Figura 6.0.1 Pasos para utilizar Paquete HMI_UDO ................................... 141
Figura 6.0.2 Pasos para Utilizar Paquete HMI_UDO (Continuación) .......... 142
Figura 6.0.3 Pasos para Utilizar Paquete HMI_UDO (Continuación) ......... 143
Figura 6.0.4 Planta P1 ................................................................................ 144
Figura 6.0.5 Archivo base dato hmi.db sin datos ........................................ 146
Figura 6.0.6 Archivo BasesDatosPlantaP1_4550.db sin datos ................... 146
Figura 6.0.7 HMI DE LA PLANTA P1 (MODELO 1) .................................... 147
Figura 6.0.8 HMI Planta P1 (Modelo 2) ....................................................... 147
Figura 6.0.9 Graficas Entradas Analógica Planta P1 (18f2550) .................. 148
Figura 6.0.10 Graficas Entradas Analógica Planta P1 (18f4550) ................ 148
Figura 6.0.11 Interfaz para Control de Salida (Modelo 1). .......................... 149
Figura 6.0.12 Interfaz para Control de Salida (Modelo 2) ........................... 149
Figura 6.0.13 Base de Datos Planta P1 18f2550 (Sqlite Administrador) ..... 150
Figura 6.0.14 Base de Datos Planta P1 18f2550 (Archivo Texto) ............... 151
Figura 6.0.15 Base de Datos Planta P1 18f4550 (Sqlite Administrador) .... 152
Figura 6.0.16 Base de Datos Planta P1 18f4550 (Archivo Texto) ............... 153
Figura 6.0.17 Vista Diagonal Planta FM51 ................................................. 156
Figura 6.0.18 Especificaciones Técnicas del Sensor de Presión ................ 157
Figura 6.0.19 HMI DE LA PLANTA FM51. .................................................. 160
Figura 6.0.20 Graficas Entradas Analógica Planta FM51 ........................... 160
Figura 6.0.21 Interfaz para Control de Salidas............................................ 161
Figura 6.0.22 Base de Datos Planta FM51 (Sqlite Administrador) .............. 162
Figura 6.23 Base de Datos Planta FM51 (Archivo Texto) ........................... 163
xv
LISTA DE TABLAS
Tabla 2.0.1 Modelos de Arduino ................................................................... 31
Tabla 2.0.2 Velocidades de transferencias USB .......................................... 34
Tabla 2.0.3 Pines del bus USB ..................................................................... 37
Tabla 2.0.4 Clases de dispositivos USB ....................................................... 41
Tabla 2.0.5 Términos SQL ............................................................................ 53
Tabla 2.0.6 Tipos de datos ........................................................................... 53
Tabla 3.0.1 Características de algunos Sistemas SCADAS ......................... 56
Tabla 3.0.2 Ejemplo de designación de la identificación de un instrumento
usando el estándar ANSI/ISA ....................................................................... 63
Tabla 3.0.3 Significado e identificación de letras, para la designación de
instrumentos funciones o variables mediante tags. ...................................... 64
Tabla 3.0.4 Significado e identificación de letras, para la designación de
instrumentos funciones o variables mediante tags. Continuación................. 65
Tabla 3.0.5 Significado de Colores Sugerido, para el diseño de despliegues
...................................................................................................................... 67
Tabla 4.0.1 características del sistema ......................................................... 89
Tabla 6.0.1 Característica de la Planta P1 .................................................. 145
Tabla 6.0.2 Características de Prueba Placa ADQ 18F2550 ...................... 145
Tabla 6.3 Características de Prueba Placa ADQ 18F4450 ......................... 145
Tabla 6.0.4 Característica de la Planta FM51 ............................................. 159
Tabla 6.0.5 Características de Prueba Placa Arduino para FM51. ............. 159
16
CAPITULO1: INTRODUCCIÓN
En este trabajo de investigación se describe el diseño y desarrollo de
un sistema de adquisición, supervisión y control, el cual está enfocado en ser
una alternativa económica y libre a la hora de probar sensores, actuadores,
monitorear plantas pilotos e incluso aplicarles control. El sistema se basa en
la comunicación entre un hardware de adquisición (Tarjeta de adquisición de
datos) y un ordenador a través del protocolo USB. Donde el circuito
electrónico del hardware esta compuesto principalmente de un
microcontrolador, el cual se le cargara un programa (firmware), para que
este pueda habilitar las entradas y salidas digitales, conversión Analógicas-
Digital y salidas PWM, a su vez él envió y recepción de datos por el protocolo
ya mencionado, del lado del ordenador se encontrara un driver genérico del
dispositivo USB proporcionado por microchip y un software que permite la
interacción entre el operador y el sistema a monitorear y/o controlar, todo
esto basándose en los criterios del software y hardware libre.
1.1 PLANTEAMIENTO DEL PROBLEMA.
En la actualidad los equipos utilizados para medir variables físicas que
intervienen en los sistemas, presentan dificultades para apreciar su medición,
ya que en ocasiones se encuentran alojados en lugares de difícil acceso,
además las señales emanadas por los sensores, generalmente son voltajes y
corrientes, que deben ser acondicionadas según los requerimientos de las
tarjetas de adquisición de datos (TAD) a utilizar, las cuales convierten las
señales analógicas en digitales, para ser aprovechada por herramientas
computacionales o software encargadas de aplicar control y de proporcionar
una representación grafica de estas variables, brindando la posibilidad de
17
modificar o tomar acciones sobre el sistema a través de los actuadores, la
combinación de estos dispositivos y herramientas computacionales forman lo
que se conoce como sistema de adquisición, supervisión y control facilitando
la interacción entre el operador y la planta.
Existen empresas que comercializan dispositivos electrónicos de
adquisición de datos (TAD) y software (HMI) los cuales generalmente su
licencia son muy costosos y con código fuente cerrado, quizás sean
rentables económicamente su implementación a nivel industrial, pero cabe
destacar que al ser de código fuente cerrado limita ajustar el software a
diversos cambios o exigencias funcionales, en el caso de plantas pilotos,
utilizadas en laboratorios universitarios seria muy costoso económicamente,
y a nivel de estudio no permiten su modificación para la investigación en
diversos escenarios.
En tal sentido, surge la problemática de diseñar un Sistema de
adquisición, supervisión y control que este desarrollado con software y
hardware libres, un ejemplo es el arduino, que son dispositivos electrónicos
basados en microcontroladores, que pueden ser utilizados como tarjetas de
adquisición de datos, logrando así una alternativa, rápida y económica,
manteniendo un funcionamiento robusto con respecto a la necesidad de
centralizar la información de las variables y la capacidad de ser adaptable a
varios sistemas, sin necesidad de adquirir nuevas licencias.
En base a este planteamiento se formula las siguiente interrogante,
¿Cómo aprovechar las características de los microcontroladores, para ser
utilizados como dispositivos electrónicos de adquisición de datos?, tomando
en consideración la compatibilidad de comunicación con los algoritmos del
software de supervisión y control que se va a diseñar.
18
1.2. JUSTIFICACIÓN Y ALCANCE.
El alcance del trabajo abarca el desarrollo de una alternativa
procedimental y metodológica, para diseñar un sistema de adquisición
supervisión y control con software y hardware libre, permitiendo al operador o
al estudiante la posibilidad de mejorar y optimizar el código, tanto del
software como del hardware (firmware), Esta idea surge de la inquietud a la
cantidad limitada de tarjetas de adquisición de datos en el laboratorio de
control del departamento de electricidad de la Universidad de Oriente, núcleo
de Anzoátegui, limitando la realización y desarrollo de prácticas que permiten
reafirmar los conocimientos teóricos en el área de la instrumentación y
control. Dichas tarjetas además de ser insuficientes, cuentan con un
software y hardware específico de código fuente cerrado y cabe destacar el
costo elevado que tienen estos productos privativos.
1.3. OBJETIVOS.
1.3.1. Objetivo General.
Diseñar un sistema de adquisición, supervisión y control de variables
de pequeñas plantas de proceso basándose en tecnologías libres.
1.3.2. Objetivos Específicos
1. Describir las premisas y criterios para el diseño, realizando un
estudio de las variables típicas de adquisición y los sistemas
comerciales existentes.
19
2. Establecer una estructura base para la utilización de los
microcontroladores de gama media-alta como tarjetas de
adquisición de datos.
3. Desarrollar el programa para la Interfaz Hombre-Máquina utilizando
software libre.
4. Validar el funcionamiento del sistema diseñado.
1.4. MARCO METODOLÓGICO
1.4.1. Tipo de Investigación.
El tipo de investigación es el esquema general o marco estratégico
que le da unidad, coherencia, secuencia y sentido práctico a todas las
actividades que se emprenden para buscar respuesta al problema y los
objetivos que fueron planteados. De este modo, la investigación, según el
grado de abstracción, es de tipo aplicada (Zorrilla, 1993), ya que el objetivo
que se persigue es diseñar un sistema de adquisición, supervisión y control
para ser aplicada en pequeñas plantas de proceso.
1.4.2. Nivel de Investigación
Según Sabino C. (1994) una investigación descriptiva es donde se
propone conocer grupos homogéneos de fenómenos, utilizando criterios
sistemáticos que permitan poner en manifiesto su estructura. En esta
investigación se pretender describir las características y funciones que
20
ocurren en los sistemas de adquisición, supervisión y control que presenta la
problemática de estudio así como también los equipos, y tecnologías para
abordar la solución, partiendo de las especificaciones de diseño.
1.4.3. Técnicas de Investigación
1.4.3.1. Observación Directa.
La observación directa se utilizará como una técnica para describir los
sistemas de adquisición y supervisión, identificando las variables que
intervienen.
1.4.3.1. Recolección de Datos.
Esta técnica se utilizará para el reconocimiento de la información que
se encuentra en las hojas datos de cada componente, manuales de
programación y bibliografías que intervendrá en el sistema a diseñar.
1.5 ETAPAS DEL PROYECTO
1.5.1. Etapa 1. Revisión Bibliográfica.
Se recolecto toda la información documental concerniente al tópico
general de estudio, para su compresión y descripción durante todo el
proceso de desarrollo de este trabajo de investigación.
21
1.5.2. Etapa 2. Descripción de las Premisas y Criterios para el Diseño.
Durante esta etapa se procede al estudio de unas series de software
comerciales HMI/SCADA, para obtener información de las variables típicas
de adquisición de procesos que manejan, las funciones y los protocolos de
comunicación que ofrecen, con la finalidad de establecer especificaciones
para el sistema a diseñar.
1.5.3. Etapa 3. Establecimiento de una Estructura Base para la
utilización de los Microcontroladores de Gama media-alta como tarjetas
de adquisición de datos.
En esta tapa se estudiaran las hojas de datos de los
microcontroladores de la familia 18fX550, para proceder a la configuración y
programación del firmware base, utilizando el software mplab junto con la
librería c18 de microchip.
1.5.4. Etapa 4. Desarrollo del Programa para la Interfaz Hombre-Máquina
utilizando Software Libre.
Luego de cumplirse las etapas anteriores, se partirá a la programación
del software HMI utilizando el lenguaje de programación Python, wxPython
para el entrono gráfico, pySerial para la comunicación serie, pyUSbB para la
comunicación por el puerto USB y sqlite3 para la base de datos.
22
1.5.5. Etapa 5. Validación del Funcionamiento del Sistema Diseñado.
Luego de diseñar el sistema se procede a verificar su funcionamiento para
ello se utilizara una planta de proceso a escala, la cual permitirá dar a
conocer el uso de las funciones y la robustez de cada scripts codificado y la
posibilidad de sus respectivas modificaciones.
1.5.6. Etapa 6. Redacción y Presentación de Trabajo de Grado.
Esta etapa consiste en la preparación de manera ordenada, la
interpretación de la información adquirida en el transcurso de la investigación
durante el periodo ya mencionado siguiendo los reglamentos establecidos
por la universidad de oriente, posteriormente se efectuara la presentación
antes la autoridades competentes.
1.6. ORGANIZACIÓN DEL TEXTO
El contenido del presente trabajo de grado está estructurado en seis
capítulos, conclusiones, recomendaciones, y apéndices, dispuesto de tal
forma que el lector pueda comprender los planteamientos que se exponen y
el proceso de desarrollo del mismo, todo esto de manera gradual, vinculado
al cumplimiento de los objetivos planteados.
El capítulo dos presenta el marco teórico que da formalidad
bibliográfica al trabajo de grado. Aquí el lector podrá ubicar los antecedentes
de la investigación y las bases teóricas que la fundamenta,
23
Finalizando con las conclusiones, recomendaciones del trabajo de
grado. Así como también una sección de apéndice, donde se colocan los
extensos de los códigos diseñados.
24
CAPITULO 2: MARCO TEÓRICO
En función del objetivo uno, en este capítulo se presente el marco
teórico que da formalidad bibliográfica al trabajo de grado. Aquí el lector
podrá ubicar los antecedentes de la investigación que sirvieron como
consulta, y que presentan los aspectos relevantes en relación al problema
tratado. Luego se muestra las bases teóricas que fundamenta la
investigación.
2.1. FUNDAMENTO TEÓRICOS.
2.1.1. Interfaz Hombre Maquina (HMI)
Es el entorno visual que brinda el sistema para que el operador se
adapte al proceso desarrollado por la planta .Permite la interacción del ser
humano con los medios tecnológicos implementados. Las señales del
proceso son conducidas al HMI por medio de dispositivos como tarjetas de
entrada/salida en la computadora, PLC, RTU o DRIVER. Todos estos
dispositivos deben de tener un protocolo de comunicación que entienda el
HMI. En la figura 1.1 se muestra una representación gráfica de los elemento
que comúnmente está presente en estos sistemas (Rodríguez, P, 2007, 110).
25
Figura 2.0.1 Esquema de una HMI.Fuente:(Rodriguez, p, (2007))
2.1.1.1. Tipos de HMI:
2.1.1.1.1. Terminal de Operador.
Consiste en un dispositivo, generalmente construido para ser instalado
en ambientes agresivos, donde pueden ser solamente de despliegues
numéricos, o alfanuméricos o gráficos. Pueden ser además con pantalla
sensible al tacto (touchscreen).
2.1.1.1.2. PC + Software
Esto constituye otra alternativa basada en un PC, en donde se carga
un software apropiado para la aplicación. Como PC se puede utilizar
cualquiera según lo exija el proyecto, en donde existen los llamados
Industriales (para ambientes agresivos), los de panel (Panel PC) que se
26
instalan en gabinetes dando una apariencia de terminal de operador, y en
general se verán muchas formas de hacer un PC, pasando por el tradicional
PC de escritorio.
Estos software permiten entre otras cosas las siguientes funciones:
Interfaces gráficas que permitan ver el proceso e interactuar con él, registro
en tiempo real e histórico de datos y manejo de alarmas. Si bien es
cierto sólo con la primera función enunciada es la propiamente HMI,
casi todos los proveedores incluyen las otras dos ya sea en el mismo
paquete o bien como opcionales. También es normal que dispongan de
muchas más herramientas.
Por otro lado, este software puede comunicarse directamente con los
dispositivos externos (proceso) o bien hacerlo a través de un software
especializado en la comunicación, la cual es la tendencia actual.
2.1.2. Adquisición de Datos.
Este proceso consiste en digitalizar las variables física que se obtiene
de un determinado sistema. A la adquisición del valor de un solo punto de
datos se le llama muestreo de la señal. Este tiene las siguientes etapas:
1. Los sensores o transductores convierten un fenómeno o magnitud
física en una magnitud o señal eléctrica.
2. Un conjunto de circuitos electrónicos para el acondicionamiento de
la señal.
27
3. Un dispositivo electrónico que convierta la señal analógica en
digital (tarjeta de adquisición de datos).
4. Una interfaz que va a transformar la información digital presentada
por el bloque anterior, en información útil al usuario.
2.1.3. Tarjetas de Adquisición de Datos.
Es un dispositivo electrónico que se encarga de obtener o generar
información de manera automatizada desde recursos de medidas analógicas
y digitales como sensores y dispositivos bajo prueba. Utiliza una combinación
de hardware y software basados en PC para brindar un sistema de medida
flexible y definido por el usuario, la interfaz de comunicación entre el
dispositivo y la PC generalmente es serie o USB.
Es por lo anterior que estos dispositivos son instrumentos, ideales
para una gran variedad de aplicaciones, desde registros de datos simples
hasta sistemas integrados, ya que han sido diseñados con el propósito
general de medir señales de voltaje. (Ríos, F. (2006)).
Para este proyecto se utilizaran el Arduino UNO y el Pingüino BD4550
que ambos son dispositivos electrónicos de hardware libre, que pueden ser
utilizados como tarjetas de adquisición de datos.
2.1.4. Microcontroladores.
Un microcontrolador es un circuito integrado que incorpora
procesador, memoria ROM y RAM, puertos de entrada/salida y otros
dispositivos de propósito especial como conversores A/D, contadores,
28
temporizadores y puertos de comunicación. En otras palabras, un
microcontrolador es un computador en miniatura.
Estos elementos se convierten en una solución completa para el
diseño de sistemas empotrados. Los podemos encontrar en todos los
aparatos, instrumentos o maquinaria, desde juguetes, electrodomésticos
hasta unidades de disco, impresoras o coches. Hay fabricantes que ofrecen
una amplia variedad de microcontroladores, siendo el diseñador del
dispositivo el que hace la elección, en la figura 2.2 se muestra la estructura
general de un microcontrolador.
Figura 2.0.2 Estructura General de un microcontrolador.
Las empresas fabricantes de microcontroladores habitualmente
desarrollan una serie de microcontroladores basados en un microprocesador
o CPU (en alguna literatura se menciona como núcleo), a cada uno de ellos
se le acondicionan diferentes cantidades de memoria RAM, memoria ROM,
con más o menos puertos de entradas y salidas simple o con puertos de
29
comunicación especializado. Al conjunto de microcontroladores que poseen
un mismo núcleo se le conoce como familia.
De las especificaciones del microcontrolador, el más preponderante es
el que tiene que ver con la cantidad de bits que puede transmitir en un
momento dado. Y de acuerdo al tamaño del bus se tiene la siguiente
clasificación de las familias de microcontroladores:
Gama Baja: Las CPU más pequeñas son de 8 bits y cubren un
amplio abanico de aplicaciones de propósito general, de bajo
costo, compactas, pero a la vez potentes. Dedicados
fundamentalmente a tareas de control (electrodomésticos, cabinas
telefónicas, smart-cards, algunos periféricos de ordenadores, etc.).
También se usan mucho como periféricos de otros micros más
grandes.
Gama Media: Las CPU de 16 bits, están destinadas a aumentar la
potencia de cálculo, principalmente, y a aumentar las capacidades
de memoria de programa y memoria de datos, pudiendo expandir
el bus externamente. Usados en tareas de control con cierto grado
de procesamiento (control de automóvil, teléfonos móviles,
PDAs,...).
Gama Alta: Las CPU de 32 y 64 bits, están destinadas a cubrir
campos como multimedia, alta capacidad de proceso, así como un
mayor direccionamiento. Normalmente pueden expandir los buses
externamente. Usados en aplicaciones como celulares inteligentes,
videoconsolas, tablet-pc, etc.
30
2.1.3. Hardware Libre.
El Hardware libre se puede definir como una materialización particular
del conocimiento libre en el área del hardware. En otras palabras, se podrá
considerar que un hardware es libre, cuando el conocimiento asociado al
mismo es libre.
En este sentido, tomando en referencia las libertades que han sido
asociadas a una de las formas de entender al software libre, una manera
más explícita de definir al hardware libre sería establecer que el mismo es
aquel cuyo código d fuente, especificaciones de proceso de fabricación y
diseño conceptual están disponible de forma tal que ofrezcan: libertad de
uso, estudio, modificación, distribución y redistribución de las mejoras.
En base a esta definición, desde la fundación Cenditel se está
concretando una plataforma de Desarrollo de hardware donde se puedan
desarrollar prototipos funcionales para construir, estudiar, y mejorar diseños
de hardware libre que aseguren la soberanía tecnológica y estén acores con
la sociedad democrática, participativa y protagónica de la nación.
2.1.4. Arduino
Arduino es una plataforma de hardware libre, basado en una sencilla
placa con un microcontrolador Atmel AVR y un entorno de desarrollo,
diseñada para facilitar el uso de la electrónica en proyectos
multidisciplinares, ya que posee puertos de entrada/salida digitales,
analógicas y PWM, el número de entrada/salida va a depender del modelo.
31
Los microcontroladores más usados son el Atmega168, Atmega328,
Atmega1280, ATmega8 por su sencillez y bajo coste que permiten el
desarrollo de múltiples diseños. Por otro lado el software consiste en un
entorno de desarrollo que implementa el lenguaje de programación
Processing/Wiring y el cargador de arranque (boot loader) que corre en la
placa. Arduino se puede utilizar para desarrollar objetos interactivos
autónomos o puede ser conectado a software del ordenador (por ejemplo:
Macromedia Flash, Processing, Max/MSP, Pure Data). Las placas se pueden
montar a mano o adquirirse. El entorno de desarrollo integrado libre se puede
descargar gratuitamente.
Tabla 2.0.1 Modelos de Arduino
Arduino Microcontrolador Digital
I/O Entradas
Analogicas PWM
Flash
SRAM EEPROM Clock Speed
Interfaz USB
Memory
UNO ATmega328 14 6 6 32KB 2KB 1KB 16 MHz
ATmega8U2
Decimila ATmega168 14 6 6 16KB 1KB 512 bytes 16 MHz
FTDI
Duemilanove
ATmega168/328P 14 6 6 16KB/32KB
1KB/2KB
512bytes/1KB
16 MHz
FTDI
Mega ATmega1280 54 16 14 128KB 8KB 4KB 16 MHz
FTDI
Mega2560 ATmega2560 54 16 15 256KB 8KB 4KB 16 MHz
ATmega8U2
Nano ATmega168/328 14 8 6 128KB 8KB 4KB 16 MHz
FTDI
2.1.5. Pingüino.
Pingüino es un proyecto open-hardware similar a Arduino, su
diferencia radica en que está basado en un Microcontrolador PIC de
Microchip, al igual que el arduino también es capaz de actuar como
un Controlador Lógico de Procesos Embebido , pues puede recibir y
procesar datos del exterior a través de sensores o
transductores conectados a sus entradas (de luz, temperatura, sonido,
otros), para procesarlos lógicamente, y en función de ello, generar cambios
32
sobre su entorno a través de actuadores o transductores conectados a sus
salidas (lámparas, motores, pistones, otros) con total autonomía de un
computador personal, aunque puede permanecer conectado a éste, aún
luego de ser programado, para enviar y recibir datos desde y hacia el mismo.
La programación se realiza utilizando el puerto USB mediante un bootloader
y el IDE de pingüino.
Arduino y Pingüino Comparten el mismo lenguaje de programación así
que no es tan difícil de migrar a una o la otra, esto ya dependerá del gusto o
necesidades del usuario. En la tabla 1.2 se puede observar las
características del dispositivo. (hackinglab Pingüino, (2011))
El hardware de Pingüino está basado en el microcontrolador PIC
18F2550 o PIC 18F4550, que tiene un módulo nativo USB y una UART para
comunicación serial.
2.1.6. Interfaz Serie
En este tipo de comunicación la información viaja por una línea de bit
en bit. Esta transmisión puede ser sincrónica o asincrónica, es decir, si se
utiliza una señal de reloj o no durante la transmisión de la información. La
gran ventaja de la comunicación serie es su simplicidad y economía al estar
implementada por un par de líneas. Aunque la comunicación serie es
básicamente enviar datos digitales sobre una línea de bit en bit, existen
varias maneras de hacerlo y el proceso de compresión entre el transmisor y
el receptor puede variar. Esto da lugar a diversas normas y métodos de
comunicación serie que son conocidos como protocolos. (Hoffman, P. 2006).
33
2.1.7. Bus Serie Universal (USB)
El Universal Serial Bus (USB) es un estándar diseñado para conectar
dispositivos, a través de un bus serie. Fue originalmente pensado para
conectar dispositivos a computadoras, eliminando la necesidad de conectar
tarjetas PCI (o similares), como así también conectar y desconectar los
dispositivos sin tener que reiniciar la PC (hot-swap). Sin embargo, hoy en día
también se utiliza en consolas de juegos e incluso en algunos equipos de
audio y video.
El diseño del protocolo USB está a cargo del USB Implementers
Forum (USBIF), una organización compuesta por varias empresas del ramo
de la computación y la electrónica, entre las que se encuentran Apple
Computer, Hewlett-Packard, Microsoft e Intel.
Existen tres versiones del protocolo (1.0, 1.1 y 2.0). A diferencia de las
anteriores, la última versión (2.0) soporta tasas de transferencia de altas
velocidades, comparables (o incluso superiores) a la de un disco duro o
almacenamiento magnético, lo cual ha permitido ampliar el uso del USB a
aplicaciones de video y almacenamiento (discos duros externos). Una de las
razones a la cual se atribuye su gran popularidad es que todas las versiones
del protocolo son compatibles hacia atrás. Es decir, que cualquier dispositivo
2.0 puede ser conectado a un dispositivo 1.0, aunque funcionará la
velocidad del más lento.
34
Existen tres tipos de velocidades en la comunicación. Ellas son:
Tabla 2.0.2 Velocidades de transferencias USB
TIPO VELOCIDAD
Baja velocidad (low speed) 183 Kbytes/s (1.5Mbit/s)
Velocidad completa (full speed) 1.4 Mbytes/s (12Mbit/s)
Alta velocidad (high speed) 57 Mbytes/s (480 Mbit/s)
2.1.7.1. Topología
USB tiene un diseño asimétrico ya que consiste de un host controlador
conectado a múltiples dispositivos conectados en daisy-chain. USB conecta
varios dispositivos a un_host controlador a través de una cadena de hubs.
Los hubs (al igual que en redes) son dispositivos que permiten, a partir de un
único punto de conexión, poder conectar varios dispositivos, es decir,
disponer de varios puntos de conexión. De esta forma se crea una especie
de estructura de árbol. El estándar admite hasta 5 niveles de ramificación por
host controlador con un límite absoluto de 127 dispositivos conectados al
mismo bus (incluyendo los hubs). Siempre existe un hub principal (conocido
como el hub raíz) que está conectado directo al host controlador.
Un mismo dispositivo USB puede cumplir varias funciones. Por
ejemplo, un mouse puede ser también lector de tarjetas, y de esa forma sería
como dos dispositivos conectados al bus USB. Por lo tanto es muy común
hablar de funciones en lugar de dispositivos.
35
2.1.7.2. Funcionamiento.
Los dispositivos tienen asociados unos canales lógicos
unidireccionales (llamados pipes) que conectan al host controlador con una
entidad lógica en el dispositivo llamada endpoint. Los datos son enviados en
paquetes; típicamente estos paquetes son de 64, 128 o más bytes. Estos
endpoints (y sus respectivos pipes) son numerados del 0 al 15 en cada
dirección, por lo cual un dispositivo puede tener hasta 32 endpoints (16 de
entrada y 16 de salida). La dirección se considera siempre desde el punto de
vista del host controlador, así un endpoint de salida será un canal que
transmite datos desde el host controlador al dispositivo, solo puede tener una
única dirección, asimismo endpoint 0 (en ambas direcciones) está reservado
para el control del bus.
Cuando un dispositivo es conectado al bus USB, el host controlador le
asigna una dirección única de 7 bit (llamado proceso de enumeración) que es
utilizada luego en la comunicación para identificar el dispositivo o en
particular, la función. Luego el host controlador consulta continuamente a los
dispositivos para ver si tiene algo para mandar, de manera que ningún
dispositivo puede enviar datos sin la solicitud previa explícita del host
controlador.
Para acceder a un endpoint se utiliza una configuración jerárquica de
la siguiente manera: un dispositivo/función conectado al bus tiene un único
descriptor de dispositivo, quien a su vez tiene uno o varios descriptores de
configuración. Estos últimos guardan generalmente el estado del dispositivo
(ej: activo, suspendida, ahorro de energía, etc). Cada descriptor de
configuración tiene uno o más descriptores de interfaz, y éstos a su vez
tienen una configuración por defecto (aunque puede tener otras). Y éstos
últimos finalmente son los que contienen los endpoint, que a su vez pueden
36
ser reutilizados entre varias interfaces y distintas configuraciones.
La comunicación USB es bastante compleja y extremadamente más
complicada que una simple comunicación serie.
2.1.7.3. Tipos de Transferencia
Los canales también se dividen en cuatro categorías según el tipo de
transmisión:
Transferencias de Control: usada para comandos y respuestas
cortos y simples. Es el tipo de transferencia usada por el pipe 0
Transferencias isócronas: proveen un ancho de banda asegurado
pero con posibles pérdidas de datos. Usado típicamente para audio y
video en tiempo real
Transferencias interruptivas: para dispositivos que necesitan una
respuesta rápida (poca latencia), por ejemplo, mouse y otros
dispositivos de interacción humana
Transferencias Masivas: para transferencias grandes y esporádicas
utilizando todo el ancho de banda disponible, pero sin garantías de
velocidad o latencia. Por ejemplo, transferencias de archivos.
En realidad las transferencias interruptivas no son tales ya que los
dispositivos no pueden enviar datos sin recibir autorización del host
controlador, por lo tanto simplemente le dan más prioridad al sondeo del host
controlador.
37
2.1.7.4. Señalización y Conectores
Las señales USB son transmitidas en un par trenzado (cuyos hilos son
denominados D+ y D-) utilizando señalización diferencial half-duplex
minimizando el ruido electromagnético en tramos largos. El diseño eléctrico
permite un largo máximo de 5 metros (sin precisar un repetidor intermedio).
Existen dos tipos de conectores estándar y mini. Los estándar son los
que típicamente encontramos en un computador y vienen en dos tipos: A y B.
El tipo A es el que es chato y se encuentra del lado del host controlador,
mientras que el tipo B es el cuadrado y se encuentra del lado del dispositivo.
Todos los cables son machos, mientras que los enchufes (ya sea en la
computadora o los dispositivos) son hembra. No existen intercambiadores de
género puesto que las conexiones cíclicas no están permitidas en un bus
USB. Los conectores mini siguen la misma política que los estándar pero son
utilizados para dispositivos pequeños como Palm y celulares. Los pines de
un cable USB son los siguientes:
Tabla 2.0.3 Pines del bus USB
Pin Color Función
1 Rojo BUS(4.4 - 5.25 V)
2 Blanco D-
3 Verde D+
4 Tierra
5 En corto con pin 4 en conector Mini-
A, utilizado para USB On-The-Go
A continuación se muestra un diagrama de los conectores (las
medidas están en mm) y los números de los pines se corresponden con la
tabla anterior.
38
Figura 2.0.3 Conector USB tipo A (izquierda) y tipo B (derecha).
Figura 2.0.4 Conector USB Mini tipo A (izquierda) y tipo B (derecha)
39
2.1.7.5. Potencia
El bus USB suministra 5V de continua regulados por cada uno de sus
puertos, entre los pines 1 y 4. Por lo tanto, dispositivos de bajo consumo de
potencia (que de otra forma vendría con una fuente de alimentación) puede
obtener de allí la corriente necesaria para el funcionamiento. El límite de
corriente suministrada es de 500mA por cada puerto. Además, el estándar
exige no más de 5.25V en ningún caso, ni menos de 4.375V en el peor caso.
Típicamente el voltaje se mantiene en los 5V.
Algunos hubs se alimentan directamente del bus USB, en cuyo caso la
corriente total de todos los dispositivos conectados a él no puede superar los
500mA. Sin embargo, la especificación permite solo un nivel de hub
alimentados por el bus, de forma que no es posible conectado un hub sin
alimentación a otro hub sin alimentación. Los hubs con alimentación propia
no tienen esta restricción y generalmente son necesarios para conectar
dispositivos de alto consumo como impresoras o discos duros.
Cuando un dispositivo es conectado le reporta al host controlador
cuando potencia va a consumir. De esta manera el host controlador lleva un
registro de los requisitos de cada puerto y generalmente cuando un
dispositivo se excede generalmente se apaga, cortándole el suministro de
corriente, de forma de no afectar al resto de los dispositivos. El estándar
exige que los dispositivos se conecten en un modo de bajo consumo (100
mA máximo) y luego le comuniquen al host controlador cuanta corriente
precisan, para luego cambiar a un modo de alto consumo (si el host se lo
permite).
Los dispositivos que superen los límites de consumo deben utilizar su
propia fuente de poder.
40
Los dispositivos que no cumplan con los requisitos de potencia y
consuman más corriente de la negociada con el host puede dejar de
funcionar sin previo aviso 0, en algunos casos, dejar todo el bus inoperativo.
2.1.7.6. Clases de Dispositivos
Los dispositivos que se conectan puede tener sus propios drivers
personalizados. Sin embargo, existe lo que se llaman clases de dispositivos
que son pequeños estándar para distintos tipos de dispositivos y especifican
como deben compartirse los dispositivos en términos de los descriptores de
interfaz y de dispositivo, endpoints, etc. Esto permite que todos los
dispositivos sean fácilmente intercambiables y/o sustituibles puesto que
hablan el "mismo idioma". Por su parte, los sistemas operativos solo tienen
que implementar drivers genéricos para todas las clases conocidas de
dispositivos lo cual alivia el alto costo de desarrollar y mantener un driver
particular para cada producto y modelo.
En conclusión, las clases de dispositivos son una estandarización de
funcionalidades a un nivel superior al del bus BUS y que utiliza a éste último
como medio de comunicación e intercambio de datos.
Tanto los descriptores de dispositivos como los descriptores de
interfaz tiene un byte que identifica la clase. En el primer caso, todo el
dispositivo/función pertenece a la misma clase, mientras que en el segundo
un mismo dispositivo puede tener diferentes clases, cada una asociada a su
descriptor de interfaz.
41
Dado que el identificador de la clase es un byte, existe un máximo de
253 clases diferentes (0x00 y 0xFF están reservados). Los códigos de las
clases son asignados por el USB Implementers Forum, y a continuación se
presenta una lista de los más comunes.
Tabla 2.0.4 Clases de dispositivos USB
Código Clase
0x00 Reservado. Usado en el descriptor de dispositivo para indicar que la clase está identificada en él (o los) descriptores de interfaz.
0x01 Dispositivo de audio. Por ejemplo; tarjetas de sonidos
0x03 Dispositivo de interfaz humana (HID). Por ejemplo: mouses, teclados, joystick.
0x07 Impresoras
0x08 Dispositivo de almacenamiento masivo. Por ejemplo: discos duros, lectores de memoria, cámaras digitales, reproductores MP3.
0x09 Hubs
0x0A Dispositivo de comunicación (CDC por sus siglas en inglés). Por ejemplo: módems, tarjetas de red.
0x0E Dispositivo de video. Por ejemplo: webcams
0xE0 Controladores inalámbricos. Por ejemplo: adaptadores Bluetooth.
0xFF Reservado. Usado para indicar que el dispositivo tiene un driver personalizado propio que no pertenece a ninguna clase.
2.1.8. Simulador de Circuitos ISIS Proteus.
El paquete electrónico Proteus es una compilación de programas de
diseño y simulación electrónica, desarrollado por Labcenter Electronics.
Consta de los dos programas principales, ARES e ISIS, y los módulos VSM y
Electra (Labcenter, 2011). Proteus está pensado para construir, simular, y
realizar la placa de circuito impreso de circuitos electrónicos analógicos,
42
digitales y mixtos. Con una librería que supera los 6000 modelos de
componentes, abacá todo el proceso de diseño de cualquier proyecto
electrónico.
Específicamente, el programa ISIS (Inteligent Schemantic Input
Sistem, siglas en ingles), permite diseñar el plano eléctrico del circuito que
se desea realizar con componentes muy variados, desde simples
resistencias, hasta alguno que otro microprocesador o microcontrolador,
incluyendo fuentes de alimentación, generador de señales y muchos otros
componentes con prestaciones diferentes. Los diseños realizados es ISIS
pueden ser simulados en tiempo de ejecución, mediante el módulo VSM
(Virtual System Modelling), asociado directamente con ISIS.
Lo que diferencia enormemente a Proteus de otros paquetes de CAD
electrónico que existen en el mercado, es la poderosa capacidad de simular
varios tipos de microcontroladores y microprocesadores: PIC, Atmel,
Motorola, Zilog, etc., ya que trata al microcontrolador como un componente
más del circuito (Tojeiro, 2009).
2.1.9. MPLAB IDE
Ensamblador, enlazador, gestión de proyectos, depurador y simulador.
La interfaz gráfica del usuario MPLAB IDE sirve como un único entorno para
escribir, compilar y depurar código para aplicaciones embebidas. Permite
manejar la mayoría de los detalles del compilador, ensamblador y enlazador,
quedando la tarea de escribir y depurar la aplicación como foco principal del
programador (usuario).
43
2.1.10. MPLAB C18
El compilador MPLAB C18 es un compilador que optimiza el estándar
ANSI C en los microcontroladores PIC18. El compilador modifica el estándar
ANSI X3.159 -1989 sólo en los puntos en los que se puedan crear conflictos
con el soporte del microcontrolador.
El MPLAB C18 tiene las siguientes características:
Compatibilidad ANSI ‟89.
Integración con el MLAB IDE para una mayor facilidad de
realización y debugg de proyectos.
Admite ensamblador empotrado.
Gran variedad de librerías.
2.1.11. Software Libre (Free Software) y Software de Código Abierto
(Open Source Software)
En la actualidad existen dos movimientos importantes que promueven el
desarrollo de Software de libre distribución, estos son:
La Fundación de Software Libre (Free Software Foundation).
La Iniciativa de Código Abierto (Open Source Initiative).
44
2.1.11.1 Fundación de Software Libre (Free Software Foundation).
2.1.11.1.1. Descripción General.
La Fundación de Software libre, desarrolló la Licencia Pública
General (GPL: General Public Licence) GNU/GPL, la misma que promueve la
libre distribución de Software, incluyendo su código fuente. El objetivo
principal es permitir a la comunidad de programadores realizar cambios al
código fuente. De acuerdo a la licencia GNU/GPL ninguna aplicación que
declare el uso de esta licencia puede ser distribuida sin su código fuente.
Compartir entre los programadores el código fuente permite responder a
defectos y problemas en las aplicaciones de manera más rápida y efectiva.
Por ejemplo, un problema detectado en una distribución de Linux puede
solucionarse en días; en cambio, aplicaciones comerciales pueden tardar
meses en solucionar un determinado error [10].
2.1.11.1.2. Características Definidas por la Fundación de Software Libre.
Las siguientes características son definidas por la Fundación de
Software libre, y determinan si un programa o aplicación cumple con las
características de un software libre (Free Software).
La Fundación de Software Libre (Free Software Foundation), define lo
siguiente:
“El software libre es una cuestión de libertad, no de precio”, esto permite
que los usuarios finales tengan la capacidad de ejecutar, estudiar, copiar,
cambiar, distribuir y mejorar un determinado Software bajo el concepto de 4
libertades definidas a continuación [10]:
45
Libertad 0: Libertad de ejecutar el software, para cualquier aplicación
final.
Libertad 1: Libertad de entender y estudiar el funcionamiento del
programa, y modificarlo para adaptarlo de acuerdo a las necesidades
del usuario.
Libertad 2: Libertad para distribuir copias del software, con el objetivo
de beneficiar a la comunidad.
Libertad 3: Libertad de mejorar el programa y publicar la versión
modificada y mejorada, con el objetivo de beneficiar a toda la
comunidad, para esto el acceso al código fuente del programa es
necesario.
En conclusión, un programa es considerado como software libre (Free
Software) si los usuarios poseen las libertades mencionadas anteriormente.
Además, el propósito del software libre radica en el principio de ejecución y
uso del usuario, y no del programador original, por lo que es necesario y
obligatorio el acceso al código fuente y la libre distribución de los manuales
del software desarrollado. Finalmente, software libre no significa que no sea
comercial. El usuario puede haber obtenido una copia de software libre,
mediante un pago, o puede haber obtenido una copia sin costo. Sin
embargo, sin tener en cuenta como se obtuvo una copia, el usuario tiene la
libertad de copiar, modificar y redistribuir el software.
46
2.1.11.2 Iniciativa de Código Abierto (Open Source Initiative)
2.1.11.2.1. Descripción General.
La Iniciativa de Código Abierto difiere un poco del movimiento de
Software Libre, aunque comparten el objetivo principal de distribuir
libremente el software. El movimiento de Código Abierto no se preocupa
mucho si cierta persona obtiene ganancias de un determinado sistema, el
movimiento está más preocupado de la distribución libre del mismo y su
código fuente, lo que no implica que sea gratis. (Se debe garantizar que sin
importar que el sistema tenga un costo inicial, su posterior distribución libre
debe ser asegurada) [10].
2.1.11.2.2. Características Definidas por la Iniciativa de Código Abierto.
La Iniciativa de Código Abierto (OSI Open Source Initiative) se
encarga de mantener la definición de código abierto en beneficio de la
comunidad y transmitir los beneficios del código abierto [11].
Código Abierto (Open Source) no solo significa acceso al código
fuente de un determinado programa. Para que un software o aplicación sea
catalogada de código abierto debe cumplir con las siguientes características
[11]:
Redistribución libre: Permite a los usuarios vender o distribuir el
software libremente.
47
Código fuente: El Software debe incluir el código fuente, o que pueda
ser obtenido libremente. El código fuente debe ser distribuido en forma
adecuada, en la cual el programador pueda realizar cambios.
Trabajos derivados: Las modificaciones y los trabajos derivados,
pueden ser distribuidos.
Integridad del código fuente del autor: Existe la posibilidad de que
la licencia establezca que las modificaciones en el código fuente solo
puedan ser distribuidas en forma de parches. Caso contrario, la
licencia debe especificar el permiso de distribución del software con su
código fuente modificado.
Sin Discriminación a personas o grupos: Todas las personas
pueden acceder al Software de Código Abierto.
Sin Discriminación en contra de los campos de aplicación: No se
puede restringir el uso en un determinado campo de aplicación. Por
ejemplo, en el uso en un negocio particular.
Distribución de la licencia: Todas los usuarios a quienes se
redistribuyó el programa, tienen los derechos especificados sobre el
mismo.
La licencia no debe ser específica a un determinado producto:
Los derechos establecidos de un determinado programa no deben
depender en el hecho que el mismo este formando parte de una
distribución particular de software.
48
La licencia no debe restringir otro software: La licencia no puede
obligar a otro software que se distribuya de manera conjunta con el
Software de Código Abierto, a que sea necesariamente de código
abierto.
La licencia debe ser tecnológicamente neutral: No se requiere
ninguna aceptación de la licencia.
2.1.12. Python
Python es un lenguaje de programación interpretado y orientado a
objetos creado por Guido Van Rossum en 1991. Python es un lenguaje de
programación poderoso, pero a su vez muy fácil de aprender y entender,
posee las siguientes características:
La implementación de Python se desarrolla bajo la licencia de código
abierto, lo que hace que Python pueda ser libremente usado y
distribuido, inclusive para propósito comercial. La Licencia de Python
es administrada por la Fundación de Software de Python (Python
Software Foundation).
Python es un lenguaje de programación modular. El usuario puede
generar módulos reutilizables por otros programas.
Es un lenguaje de programación multiparadigma (varios estilos):
o Programación orientada a objetos.
o Programación estructurada.
o Programación funcional.
49
Puede usar un intérprete (Modo interactivo, como Matlab)
Python soporta herencia múltiple y polimorfismo.
Python puede ser ejecutado en Windows, Linux/Unix, Mac OS X,
inclusive existe versiones de Python que corren sobre máquinas
virtuales .NET y Java.
Python posee un extenso número de librerías estándar y módulos
especiales desarrollados para diversas tareas.
Python se enfoca en desarrollar códigos entendibles, coherentes, y de
calidad. El código de Python es desarrollado para ser entendible, y
como consecuencia, reusable y fácil de mantener, de manera más
profunda comparado con otros lenguajes de programación.
2.1.13. wxPython
wxPython es un conjunto de herramientas que permite el desarrollo de
programas para la generación de interfaces gráficas de usuario reales (GUIs)
muy poderosa, pero a su vez muy simple de usar. wxPython permite al
usuario crear y manipular elementos comunes de las interfaces tal como
botones y menús, pero también permite crear y manipular elementos menos
comunes, como tablas, árboles y editores de texto. Tal como Python,
wxPython es un proyecto de código abierto y multiplataforma. (N. Rappin R.
Dunn, 2006).
50
2.1.14. PyUSB
PyUSB tiene como objetivo proporcionar fácil USB acceso
al Python lenguaje. El proyecto está dividido en dos versiones principales: la
0.x estable y las versiones en desarrollo 1.0. Todos los esfuerzos se
concentran ahora en el nuevo (0.x incompatible) API 1.0. PyUSB 1,0 realza
la biblioteca de varias maneras:
Apoyo a libusb 0,1 , 1,0 libusb y OpenUSB .
API fácil de comunicarse con los dispositivos.
Apoyo a backends biblioteca personalizada.
Transferencia isócrono soporte tipo.
100% escrito en Python por ctypes .
Funciona en cualquier versión de Python.
2.1.15. PySerial
PySerial es un módulo de Pyton que administra el acceso al puerto
serial. Presenta las siguientes características:
Estado de desarrollo: Módulo Estable.
Licencia: aprobada por la Iniciativa de Código Abierto (OSI Open
Source Initiative) y por la Fundación Python Software.
Lenguaje: Inglés.
Sistemas Operativos: Windows, Linux.
51
Lenguaje de Programación: Python.
Permite acceder a las propiedades del puerto serial a través de
Python.
Soporta diferentes tamaños de bits de datos, bits de parada, paridad y
control de flujo.
El usuario puede emplear o no un tiempo de espera (timeout), para la
recepción de datos.
2.1.16. Matplolib
Matplotlib es una librería que permite realizar gráficas en dos
dimensiones mediante Python. Sin embargo, los comandos de Matplotlib
fueron desarrollados emulando los comandos de generación de gráficas de
Matlab; pero, los desarrolladores le agregaron la idea de programación
orientada a objetos. Para un mejor uso de los datos a graficar, Matplotlib,
hace uso de la librería Numpy, la misma que constituye el paquete
fundamental utilizado para realizar cálculos científicos en Python [20].
El código de Matplotlib se divide básicamente en las siguientes
interfaces:
Interfaz pylab: Conjunto de funciones provistas por matplotlib. pylab el
cual permite al usuario crear gráficas con comandos similares a
Matlab.
52
Interfaz de aplicación de Matplotlib: Es un conjunto de clases las
cuales permiten crear y manejar las figuras, gráficas, texto, líneas,
etc.
2.1.17. Sqlite3
SQLite es una biblioteca de C que proporciona una base de datos
ligera basada en disco que no requiere un proceso de servidor independiente
y permite el acceso a la base de datos utilizando una variante no estándar
del lenguaje de consulta SQL. Algunas aplicaciones pueden utilizar SQLite
para el almacenamiento de datos interno. También es posible que un
prototipo de una aplicación utilizando SQLite y después portar el código a
una base de datos más grande como PostgreSQL o Oracle.
El módulo del sqlite3 fue escrito por Gerhard Häring. Proporciona una
interfaz de SQL compatible con la especificación de DB-API 2.0 descrito por
PEP 249
53
Tabla 2.0.5 Términos SQL
Termino Definición
SQL
El Lenguaje de Consulta Estructurado (del inglés Structured Query Language) es un lenguaje utilizado para crear, actualizar, eliminar, y consultar información de
una base de datos.
Consulta Búsqueda de información determinada en la base de
datos.
Cursos Objeto utilizado para navegar por los registros resultantes
de una consulta SQL.
Resultados Conjunto de registros que entrega la consulta SQL.
Registro Unidad de información dentro de una tabla. También
llamado fila.
Transaccion Operación con el sistema de manejo de la base de datos.
Tabla 2.0.6 Tipos de datos
SQLite Python
NULL None
INTEGER int or long, depending on size
REAL float
TEXT depends on text_factory, unicode by default
54
CAPITULO 3. PREMISAS DE DISEÑO DEL SISTEMA
En este capítulo se dará a conocer las características y funciones que
tendrá el sistema de adquisición, supervisión y control desarrollado, a través
del estudio de sistemas comerciales HMI/SCADA, estándares para el diseño
de la interfaz hombre maquina (HMI), opciones de conectividad USB entre
PC y hardware de adquisición.
3.1 SISTEMAS HMI/SCADAS
Las primeras herramientas para la creación de sistemas Scada fueron
desarrolladas para aplicaciones específicas, dependiendo de las
características del proceso a supervisar y controlar; por esta razón los
sistemas Scada eran adaptados a las necesidades de un proceso específico,
como resultado, los proveedores de software de desarrollo de sistemas
Scada adaptaron su trabajo previo en aplicaciones específicas, para que el
software pueda ser utilizado en otro tipo de industria. Con el tiempo, varios
fabricantes desarrollaron paquetes de software capaces de comunicarse con
los sistemas y dispositivos de control de una determinada planta, y le dieron
al sistema en general escalabilidad y flexibilidad. Sin embargo, ciertos
procesos requerían de aplicaciones adicionales, las cuales fueron
desarrolladas como módulos específicos [4]. En la actualidad, el objetivo de
los proveedores de software para sistemas HMI/Scada es desarrollar una
arquitectura abierta que permita su utilización en diversos procesos
industriales, con la adición de módulos específicos para determinadas
industrias.
55
3.2 FUNCIONES DEL SOFTWARE DE DESARROLLO DE
SISTEMAS HMI/SCADA.
Supervisar el proceso: El sistema HMI/Scada genera aplicaciones
que permiten modificar el estado de una determinada variable de
manera remota, a partir del análisis del proceso en un determinado
instante de tiempo.
Generar Reportes y Alarmas: El Sistema HMI/Scada permite
configurar el sistema para determinar si ha ocurrido un evento no
deseado dentro del sistema para después generar la alarma y el
reporte respectivo. Estas alarmas se determinan a partir de límites
establecidos por el supervisor del sistema.
Generar Algoritmos de Control: Actualmente el software para
desarrollo de HMIs permite generar algoritmos de control. Es decir,
permite modificar o ajustar el valor de una determinada variable
(variable manipulada) del proceso a partir de los valores de ciertas
señales de entrada, con el objetivo de mantener una variable (variable
controlada) del proceso dentro de valores preestablecidos.
Configura el sistema de Comunicación: Mediante el software de
desarrollo de sistemas HMI/Scada, se configura los canales de
comunicación con los diversos dispositivos de campo.
Desarrollar despliegues: El software de desarrollo de sistemas
Scada tiene módulos que permiten generar los despliegues que
describen gráficamente el proceso.
56
Configurar los sistemas de Gestión de Base de datos: El software
de desarrollo de sistemas HMI/Scada permite configurar la base de
datos del proceso y las funciones específicas a realizar con los datos
almacenados mediante este módulo se estructura el sistema de
control y supervisión del proceso, ya que define el grupo de variables
involucradas en el sistema.
Tabla 3.0.1 Características de algunos Sistemas SCADAS
Nombre Ignition Stantor Proview Argos NI
LabVIEW
Tipo LICENCIA GPL LICENCIA LIBRE LICENCIA
Compañia Inductive
Automation Stantor
Mandator and SSAB Oxelosund
CINTAL National
Instruments
Sitio inductive
automation.com stantor.free.fr proview.se cintal.com.ve ni.com
Pais USA Francia Suiza Venezuela EE.UU
Estado ACTIVO ACTIVO ACTIVO ACTIVO ACTIVO
Año 2010 2010 2010 2009 2012
Lenguaje Java C, C++ C, C++ y algo de Java
C++ / Fltk C
S.O. Linux, Windows,
Mac
Linux Fedora, Ubuntu and Mandriva
Linux Linux
Windows (Linux,
Mandriva, RedHat,
SUSE), Mac OS
Multilenguaje Si Si Si No Si
Web HMI Si Si Si Si Si
Scripts Si Si Si Si Si
Archivado Si Si Si Si Si
Tendencia a
avance Si Si Si Si Si
Control Si Si Si Si y Alarmas Si
Protocolos OPC UA Modbus, TCP/IP Proibus, OPC Modbus, TCP/IP
CanBus, DeviceNet, Ethernet, Fieldbus, Modbus, Profibus,
Usb/Serial.
Dispositivos OPC UA K8000/K8055/K8061/ Arduino, X10 CM11A
ABB, Siemens, Inor, entre otros.
PLCs ADQ,
Arduino, PLCs
57
3.3 DESARROLLO DE APLICACIONES HMI.
Las aplicaciones HMI son un conjunto de despliegues que le permiten
al operador determinar el comportamiento en tiempo real del proceso. El
software de desarrollo de sistemas HMI/Scada presentan módulos que
permiten generar despliegues, estos son generados y caracterizados de
acuerdo al proceso que representan, sin embargo existen organizaciones
que desarrollan estándares con el objetivo de normalizar el desarrollo de
interfaces Hombre-Máquina dentro de sistemas de control distribuido. El
objetivo de estas organizaciones es que los desarrolladores de despliegues
sigan ciertas reglas a la hora de representar a las variables de manera
gráfica o mediante identificaciones (Tags), además intentan normalizar el uso
de colores y los significados de los mismos.
Como resultado, se tiene una normalización en la presentación del
proceso desde el punto de vista estructural, pero no así desde el punto de
vista funcional, que depende de las características del proceso.
3.4. ESTÁNDAR ANSI /ISA 5.1 2009
3.4.1. Identificación y Símbolos de Instrumentación.
3.4.1. 1. Propósito.
El propósito de este estándar es establecer medios uniformes a la
hora de identificar instrumentos y sistemas de instrumentación. Generar un
sistema de designación de símbolos y códigos de los instrumentos y
sistemas de instrumentación [8].
58
3.4.1. 2. Aplicación en la Industria.
El estándar es adecuado para el uso en la industria química,
petroquímica, generación de energía, y entre otros numerosos procesos
industriales.
3.4.1. 3. Aplicaciones en Actividades de Trabajo.
El estándar ANSI/ISA 5.1 tiene su aplicación especialmente en las
siguientes áreas:
Diseño de planos de construcción.
Ejemplos académicos.
Documentos científicos, literatura, y discusiones.
Diagramas de sistemas de instrumentación, diagramas tipo bucle, o
diagramas lógicos.
Especificaciones, entre otros.
Identificación (tagging) de los instrumentos y funciones de control.
El estándar tiene la intención de proveer la suficiente información que
permita a cualquier persona conocedora del proceso, y que este revisando
un documento de control de procesos o un despliegue en un sistema de
control, entender los medios de medida y control del proceso. Los símbolos y
59
el sistema de identificación provistos por el estándar son aplicables para toda
clase de medida dentro del proceso y a toda la instrumentación de control [8].
El estándar define diversos términos de aplicación en los procesos
industriales, entre los principales términos definidos para el uso y
entendimiento del estándar se tiene los siguientes [8]:
Alarma (Alarm): Un dispositivo o función que señala la existencia de
una condición que no es normal, por medio de un cambio discreto
visible y/o audible, con el objetivo de atraer la atención del operador.
Binario (Binary): Término aplicado a una señal o dispositivo que
posee dos estados o posiciones discretas, contrario a una señal
análoga, el término es usado para identificar o denotar dos estados
por ejemplo: “prendido-apagado”, “alto-bajo”, “abierto-cerrado”
Dispositivo de Computación (Computing Device): Dispositivo que
permite realizar uno o varios cálculos, operaciones lógicas, o ambas y
transmite los resultados mediante señales de salida.
Controlador (Controller): Un dispositivo que tiene una salida que varía
para regular una variable controlada de una manera específica.
Existen controladores automáticos los cuales varían su salida
automáticamente en respuesta a una señal de entrada directa o
indirecta de una variable medida del proceso. Por otro lado, tenemos
el controlador manual el mismo que no depende del valor de una
variable medida y puede ser asignado de manera manual mediante un
ajuste.
60
Conversor (Converter): Un dispositivo que recibe una señal de un
instrumento de una forma, y transmite la señal de salida de otro forma.
Digital: Un término aplicado a una señal o dispositivo que usa datos
binarios para representar datos continuos o discretos.
Sistema de control Distribuido (Distributed Control System): Un
sistema que es funcionalmente integrado, y consiste de varios
subsistemas que se encuentran físicamente separados y remotamente
ubicados uno de otro.
Elemento de Control Final (Final Control Element): Un dispositivo
que directamente controla el valor de una variable manipulada de un
determinado bucle de control.
Identificación (Identification): La secuencia de letras o dígitos usados
para designar un instrumento individual.
Instrumento (Instrument): Un dispositivo usado directa o
indirectamente para medir y/o controlar una determinada variable. El
término incluye: elementos primarios, elementos finales de control,
dispositivos de computación, y dispositivos eléctricos.
Bucle (Loop): La combinación de dos o más instrumentos o funciones
de control agrupadas para que las señales pasen de un lugar a otro
con el propósito de medir y/o controlar una variable del proceso.
Medida (Measurement): Magnitud de una variable.
61
Elemento primario (Primary Element): Sinónimo de sensor.
Proceso (process): Cualquier operación o secuencia de operaciones
que envuelven el cambio de energía, estado, composición, dimensión
u otras propiedades.
Variable del proceso (Process variable): Cualquier variable
proveniente del proceso. El término variable del proceso en este
estándar es usado para todas las variables cuyas señales provienen
de la instrumentación.
Programa (Program): Una secuencia repetitiva de acciones que
define el estado de las salidas que son modificadas en relación a un
grupo de entradas.
Controlador Lógico Programable (Programmable logic controller):
Controlador con múltiples entradas y salidas que contiene un
programa alterable.
Sensor: Parte de un bucle o instrumento que primero determina el
valor de una variable del proceso y asume una correspondiente y
predeterminada salida. El sensor también es conocido como elemento
primario.
Transductor (Transducer): Término general para un dispositivo que
recibe información en una o varias cantidades físicas, modifica la
información y/o su forma y produce una señal de salida resultante.
62
3.4.1. 4. Descripción del Sistema de Identificación:
Cada instrumento o función a ser identificada es designada por un código
alfanumérico o tag como se muestra en la tabla 2.26.
3.4.1. 5. Características de las identificaciones (Tags).
La identificación dentro de un bucle de control determinado
generalmente es común a todos los instrumentos y funciones que
componen un bucle de control.
El usuario puede adicionar prefijos o sufijos de manera opcional, y así
completar la información necesaria para describir el instrumento.
El número del bucle de control incluye información codificada, tal como
área determinada de la planta, o función dentro del proceso, etc.
La función de un determinado instrumento se identifica mediante una
primera letrade identificación que designa la medida o la variable,
seguido de una o varias letras subsiguientes que designan las
funciones realizadas.
63
Tabla 3.0.2 Ejemplo de designación de la identificación de un instrumento usando el estándar ANSI/ISA
Composición típica de una identificación o tag
TIC 103 Identificación del instrumento (TAG)
T 103 Identificación dentro de un Bucle de
control determinado.
103 Número del Bucle de control determinado
TIC Identificación funcional
T Primera letra de identificación
IC Letras subsiguientes de identificación
Identificación o tag expandida
10-PAH-5A Identificación del instrumento
10 Prefijo opcional
A Sufijo opcional
3.4.1. 6. Análisis de la Tabla.
Una letra cuya designación es “Opción de usuario” será utilizada de
manera repetida en un proyecto en particular, y tendrá que ser
presentado su significado tanto para una primera letra, o para letras
subsiguientes.
Una letra cuya designación es “no clasificada”, será utilizada en una
ocasión, o en un número limitado de ocasiones. Las Definiciones
deben ser especificadas fuera del diagrama de flujo del proceso.
64
Si una primera letra es usada en combinación con una letra
modificadora Diferencial), F (Radio), M (Momentáneo), K (Tasa de
Cambio), Q (Totalizador), o cualquier combinación de estas letras es
usada para representar una nueva y separada variable de medida.
Dicha combinación es tratado como una primera letra. Por lo tanto, los
instrumentos PDI y PI identifican dos variables diferentes, designadas
como: Indicador de Presión Diferencial e Indicador de Presión. Los
Modificadores deben ser usados solo cuando sean aplicables.
Los términos modificadores alto, bajo, medio e intermedio
corresponden a valores de la variable medida. Por ejemplo, una
alarma de nivel alto debe ser designada como LAH (Primera Letra =
“Level”, Función Pasiva= “Alarm”, Modificador=”High”) [8].
Tabla 3.0.3 Significado e identificación de letras, para la designación de instrumentos funciones o variables mediante tags.
Primera Letra Letras Subsiguientes
Medida o inicio de variables Modificador
Lectura de Salida o Función Pasiva
Función de Salida
Modificador
A Análisis Alarma
B Quemador, Combustión Opción de
usuario Opción de
usuario Opción de
usuario
C Opción de usuario Control
D Opción de usuario Diferencial
E Voltaje Sensor
(Elemento Primario)
F Flujo Radio
(Fracción)
G Opción de usuario Vidrio,
Dispositivo de Visualización
H Mano Alto
I Corriente Eléctrica Indicador
J Potencia Escaneo
65
Tabla 3.0.4 Significado e identificación de letras, para la designación de instrumentos funciones o variables mediante tags. Continuación.
Primera Letra Letras Subsiguientes
Medida o inicio de variables Modificador
Lectura de Salida o Función Pasiva
Función de Salida
Modificador
M Opción de usuario Momentáneo Medio,
Intermedio
N Opción de usuario Opción de
usuario Opción de
usuario Opción de
usuario
O Opción de usuario Oficio,
Restricción
P Presión, Vacio Punto de
Prueba de conexión
Q Cantidad Integrado, Totalizador
R Radiación Registro
S Velocidad, Frecuencia Seguridad Conmutador
T Temperatura Transmisión
U Multivariable Multifunción Multifunción Multifunción
V Vibración, Análisis Mecánico Válvula,
Amortiguador
W Peso, Fuerza Pozo
X No Clasificado Eje X No Clasificado No
Clasificado No Clasificado
Y Evento, Estado o Presencia Eje Y Relé,
Conversor, calculo
Z Posición, Dimensión Eje Z
Actuador, Elemento final de Control no
clasificado
66
3.5 ESTÁNDAR ISA-5.5-1985.
3.5.1. Símbolos Gráficos para Visualización de Procesos.
El propósito de este estándar es desarrollar un sistema de símbolos
gráficos y colores para los despliegues del proceso que son usados para
controlar y monitorear un determinado proceso industrial. El sistema tiene
como objetivo facilitar la rápida comprensión por parte del usuario de la
información que es presentada en los diferentes despliegues o pantallas de
visualización, y establecer una uniformidad en la presentación de la
información por parte de las diferentes industrias. Además, el estándar se
complementa con el Estándar ISA-5.1 “Símbolos de Instrumentación e
Identificación”
Los resultados que se buscan al desarrollar este estándar son los
siguientes:
Reducir los tiempos de entrenamiento de los operadores.
Reducir los errores de los operadores.
Mejor comunicación y entendimiento entre el diseñador del sistema de
control y los usuarios del sistema.
3.5.2. Color.
El color es una técnica efectiva de codificación con símbolos, formas y
códigos alfanuméricos.
67
La siguiente tabla muestra un ejemplo de planificación de colores, que
establece una relación entre los colores, su significado genérico, y la
asociación con los diferentes significados y procesos dentro de una pantalla
de visualización del proceso [9].
Tabla 3.0.5 Significado de Colores Sugerido, para el diseño de despliegues
Color Significado
Genérico
Elemento
Asociado
Negro Fondo
Rojo Emergencia
a)Parada
b)Alarma de alta prioridad c)Cerrado
d)Apagado(Off)
Amarillo Alerta
a) Condición fuera de lo normal. b) Alarma de prioridad media.
Verde Seguro
a) Operación Normal
b) Inicio
c) Abierto
Celeste Estático y significante a) Equipo de Proceso en servicio b) Etiquetas Principales
Azul No es esencial
a) Equipo de Proceso en espera
b) Tags, etiquetas, etc.
Morado Radiación
a) Alarmas de Radiación
b) Valores Cuestionables
Blanco Datos Dinámicos
a) Medidas e informaciones de estado
b) Mensajes del sistema
c) Tendencias
d) Pasos secuenciales activos
68
3.6. OPCIONES DE CONECTIVIDAD USB.
3.6.1. Transceivers USB.
La principal responsabilidad de los transceptores (transceivers) USB
es encapsular la capa física y realizar una interfaz con otros dispositivos
programables. Esto sólo incluye una traducción de los voltajes que codifican
la transmisión de información en dos señales D+ y D-, a un conjunto de
señales para su posterior procesamiento de capas superiores realizadas por
otros dispositivos.
En las capas superiores se debe realizar un manejo de transacciones
y endpoints, entre otros. De esta forma estos son dispositivos muy simples,
que a los sumo incorporan reguladores de voltaje, y detectores de conexión,
lo que los hace muy baratos. Como representantes de esta categoría se
seleccionaron el USB1T20 de Fairchild, y el Philips ISP110x. En la figura 3.1
se muestra un diagrama lógico de las señales que traduce y la tabla de
verdad de los valores lógicos que convierte.
Figura 3.0.1 Diagrama lógico y tabla de verdad del Transceiver USB
69
3.6.2. Conversores USB a Interfaz Serial o Paralela.
Otra de las posibilidades existentes para facilitar la conectividad entre
el PC y un hardware vía USB es mediante el uso de conversores. La idea
aquí, es que el conversor funciona como caja negra, en donde uno de los
extremos de la interfaz utilizada es USB y en el otro es serial o paralelo,
según el conversor en cuestión. De esta forma, para el hardware que se
desea conectar es transparente la forma en que los datos llegan al PC. Si se
hace la analogía con conectividad en redes, podría pensarse que se crea un
túnel entre el Host USB y el conversor por donde pasa la información de la
interfaz del hardware externo. El conversor es visto en general por el PC
como un puerto serial y así lo utilizan también las aplicaciones de usuario. El
representante elegido en este caso es el FT232BM de FTDI y su diagrama
en bloques se muestra en la figura 3.2. Los componentes más importantes
de izquierda a derecha son: el transceiver USB, el motor de interfaz serial
(serial interface engine) (SIE), el motor de protocolo USB y el transmisor-
receptor asíncrono universal (universal asynchronous receiver-transmitter)
(UART). Del transceiver ya se ha hablado con anterioridad, el SIE junto con
el motor de protocolos USB tiene la responsabilidad de manejar
transferencias en endpoints predeterminados por la interfaz CDC. Luego el
componente controlador UART FIFO, que con ayuda de los buffers de
memoria compartida realizan las transferencias de datos con el Host USB.
Este componente también sirve para setear la configuración del UART
(velocidad, paridad, etc). Finalmente a la derecha de la figura se encuentra el
UART que es donde se conecta el hardware vía una interfaz serial.
70
Otras características que tiene este conversor son:
Cumple con el estándar USB 2.0 (Full speed)
Velocidad de 300 a 3M baudios
Manejo de handshaking y señales de modem.
Bit Bang mode: Transforma las señales de control en puerto de E/S de
8 bits.
Interfaz con EEPROM para caracterizar VID, PID, etc.
Drivers de puerto COM virtual para Windows, MacOS y Linux.
Figura 3.0.2 Diagrama de bloques del FT232
71
3.6.3. Controladores de Periféricos.
Estos dispositivos incorporan un transceiver USB y la lógica para el
manejo del protocolo. En estos es configurable además un número variable
de endpoints y tipos de transferencias, así como también descriptores de
dispositivo, interfaz, VID, PID, etc. Pueden encontrarse en dos modalidades:
externos o embebidos en un microcontrolador.
3.6.3. 1. Controladores de Periféricos Externos.
Estos dispositivos, como ya dijimos, manejan las comunicaciones USB
al nivel de transacciones y endpoints y además es visto como otro periférico
más para los microcontroladores o microprocesadores con los cuales
interactúan. Vale la pena aclarar que estos dispositivos no son autónomos
sino que deben interactuar con microcontroladores o microprocesadores para
realizar parte de sus tareas, a diferencia de los conversores que se
presentaron en la sección 3.6.2. Una de las ventajas más importantes que
tiene, es el poco impacto que causa su aplicación en sistemas ya existentes,
es decir, si se quiere agregar la funcionalidad a un dispositivo ya existente en
un microcontrolador, sólo hay que agregar firmware necesario para el manejo
del USB y no migrar todo a otra solución que utilice un controlador de
periféricos embebido. En esta sección se tomó como representante el
ISP1581 de Philips.
A continuación se presentan las principales características
relacionadas con la conectividad USB:
Cumplen con el estándar USB 2.0 y soporta velocidades high y full.
72
7 Endpoints de entrada, 7 de salida. Soporta double buffer.
Soporta todos los tipos de transferencias
8Kb de memoria FIFO integrada.
Interfaces con un microcontrolador:
o Interfaz de bus independiente para la mayoría de los
microcontroladores /microprocesadores (12.5 MByte/s)
o Interfaz DMA de alta velocidad (12.8 Mbyes/s)
o Interfaz directa con periféricos ATA/ATAPI
Conexión al bus USB controlada por software (SoftConnect tm)
Data transceiver y regulador de voltaje de 3.3 V integrados
3.6.3. 2. Controladores de Periféricos Embebidos.
En este tipo de soluciones, se incorpora dentro del mismo
microcontrolador el hardware necesario para conectarse directamente al Host
USB. Brinda las mismas funciones que el controlador de periféricos externo
pero con algunas diferencias. Normalmente es utilizado como un periférico
más y utiliza registros dedicados y un tipo de memoria especial, a veces
llamada RAM de doble puerto (Dual Port RAM) para intercambiar información
con el microcontrolador, además de poseer una rama completa de
interrupciones asociadas a los eventos USB. La comunicación en los casos
73
relevados se maneja a nivel de endpoints y el manejo de transferencias es
manejado por firmware con el soporte de hardware de este periférico
especial, comúnmente conocido como SIE. Una desventaja que genera el
hecho de que se utiliza un recurso embebido en un microcontrolador, es que
se genera una dependencia con la arquitectura de éste. Un ejemplo es el
microcontrolador PIC 18F.
3.7. DISEÑO ESTRUCTURAL DEL SISTEMA
En este apartado se muestra la estructura funcional del sistema
diseñado luego de realizarse un estudio de los Sofware HMI/Scada
comerciales, de las opciones de conexión USB y estándares internacionales.
Básicamente el sistema es controlado por el usuario a través de un
ordenador, que transmite los datos al Hardware de adquisición de datos y
viceversa a través de una conexión USB. El dispositivo procesa los datos y
en función de las tareas, maneja los actuadores. El PC muestra los datos de
los sensores y los estados de los actuadores a través del software HmiUDO
el cual se encarga de hacer una representación gráfica del proceso, a su vez
muestra graficas de tendencias y gestión de bases de datos. El dispositivo
puede ser programado por ICSP (In Circuit Serial Programming), por
intermedio de un programador para incluir nuevas funciones o
actualizaciones del firmware. La interacción entre este dispositivo electrónico
y elementos de adquisición (sensor) o actuación dependerán si lo requieren
de un circuito electrónico de acondicionamiento de señal. La estructura de
sistema diseñado se muestra en la figura 3.3.
74
Figura 3.0.3 Esquema estructural del Sistema
El sistema de adquisición diseñado se desgloso en sus interfaces para
lograr facilitar el entendimiento de su estructura, elementos que lo componen
y su funcionamiento. Como se puede observar en la figura 3.4 y 3.5 el
sistema está compuesto por tres interfaces que interactúan en cadena, en la
primera interfaz (usuario-pc), el usuario interactúa con el proceso a través del
software (HmiUDO), el cual es una interfaz gráfica, donde se ve de manera
virtual toda la instrumentación, actuadores, en sí todo el proceso. El puente
entre las dos primeras interfaces es el software junto a tres archivos que
forman el driver: .sys con información para el sistema, .inf, con información
del dispositivo y .dll con funciones para la comunicación entre el Pc y el
dispositivo. En la segunda interfaz (pc-hardware), los datos son
encapsulados y transmitidos al dispositivo a través de la conexión usb. El
firmware del dispositivo procesa estos datos, y según su programación este
habilita los periféricos. El puente entre las interfaces siguientes es el
firmware, que se encarga de recibir y procesar datos, además de manejar los
puertos de entrada, salida y procesar datos adquiridos. En la tercera interfaz,
los datos pasan por un circuito de acondicionamiento de señal y luego a los
actuadores (motores, luces, válvulas motorizadas, etc)
75
El camino inverso, para la monitorización u otras funcionalidades, es
recorrido por los datos de la siguiente manera:
En la tercera interfaz (Hardware-Planta) el dispositivo de adquisición
recibe las señales emanadas por los sensores luego de pasar por un
circuito electrónico de acondicionamiento de señal. En la segunda
interfaz son encapsulados y reenviados al Pc, donde serán
preparados para su visualización o virtualización. En la primera
interfaz, los datos de estado del periférico están visualizados, tratados
y/o archivados. Cabe destacar que al principio, para poder establecer
comunicación el dispositivo debe ser reconocido por el sistema
operativo (los archivos .sys y .inf). En la segunda interfaz, como
primera operación, se realiza la instalación del dispositivo. La
instalación, normalmente, se ejecuta una sola vez por puerto USB.
Figura 3.0.4 Esquema estructural del sistema (Interfaces)
76
Figura 3.0.5 Esquema estructural del sistema (Interfaces detallada)
77
CAPITULO 4 HARDWARE DE ADQUISICIÓN
En este capítulo se vera de forma detallada el desarrollo del hardware
de adquisición, el cual está centrado en un microcontrolador, primero se
analizará la utilización del arduino y el pingüino como tarjetas de adquisición
de datos, que son proyectos de software y hardware libre, como se
mencionó anteriormente en el capítulo I , existen limitaciones a la hora de
usar estos dispositivos, como es el número de entradas y salidas digitales y
analogías, que son seleccionadas por el fabricante, lo que no aprovecha la
cantidad máxima que traen los microcontroladores que incorporan, cabe
destacar que esta limitación es recompensada por la facilidad de programar
el dispositivo, ya que utiliza un lenguaje de programación llamado
Processing/Wiring que es de fácil sintaxis, rápido y bien documentada.
Para aprovechar más el microcontrolador se decidió añadir al
proyecto, el desarrollo de una tarjeta de adquisición de datos utilizando los
microcontroladores pic 18f2550/4550, el firmware estará programado con la
librería c18 de mplab de la empresa microchip.
4.1. HARDWARE DE ADQUISICIÓN DE DATOS UTILIZANDO
ARDUINO Y PINGÜINO.
Antes de ver el código de fuente, su explicación y funcionamiento del
dispositivo, se proporcionara un resumen de la sintaxis que manejan, el cual
pueden visualizar en el apéndice Ap1 (Arduino) y Ap2 (Pingüino).
78
4.1.1. Estructura Firmware Archivo principal Arduino (Arduino Tarjeta
Adq.pde).
/********************************Variables***********************************/
char buff[]= "0000000000"; // Array que almacena los datos recibidos
//por el puerto serial.
/**********************************Setup**************************************/
void setup() {
Serial.begin(9600); //Velocidad de Comunicación Serial
pinMode(Pin, OUTPUT); // Definir los pin que son de salida como
} //OUTPUT
/************************************Lazo************************************/
void loop() {
while (Serial.available()>0) { // Mientras haya datos entrantes
for (int i=0; i<10; i++) { // Para cada elemento de la matriz del búfer
buff[i]=buff[i+1]; // Toma el valor del elemento siguiente
}
buff[10]=Serial.read(); // Colocar los datos de entrada en el último
//elemento
switch (buff[10]){
case 'Opción':
Acción;
break;
} // Fin switch
} // Fin Bucle While
} //Fin Void Loop()
79
Figura 4.0.1 Diagrama de Flujo del Firmware Arduino.
80
4.1.2. Estructura Firmware Archivo Principal Pingüino (Pingüino
TarjetaAdq.pde)
/*************************************Variables***************************************/
u8 Opción[];
/**************************************setup******************************************/
void setup()
{
pinMode( i, OUTPUT );
}
/*****************************************Lazo*****************************************
*/
void loop()
{
if (USB.available()>0)
{
Opción= USB.read();
if ( Opción[0]=='variable' ){
//Acción
}
}//Fin usb
}//Fin void loop
81
Figura 4.0.2 Diagrama Flujo Firmware Pingüino
82
4.2. HARDWARE DE ADQUISICIÓN UTILIZANDO
MICROCONTROLADDOR PIC Y COMPILADOR C18 DE
MPLAB IDE.
En este subcapítulo desarrollara una estructura, para utilizar los
micrcontroladores como dispositivos de adquisición, conectable a pc. Como
se mencionó anteriormente la comunicación será a través del puerto USB,
además en este se podrá habilitar entradas y salidas digitales y analógicas,
para ello microchip proporciona un conjunto de librerías, una librería es una
colección de funciones agrupadas por referencia y facilidad de llamada.
Para otorgar comunicación USB debemos utilizar, la aplicación
Microchip Application Libraries, que se puede descargar de forma gratuita
en la página de Microchip en la sección USB Framework for PIC18, PIC24 &
PIC32.
Esta aplicación proporciona unas series de ejemplos, entre ellos hay
una donde se trabaja la comunicación USB, dependiendo de la clase (HID,
MSD, GEN o CDC). En la figura 4.1 se puede observar el framework de la
clase genérica.
83
Figura 4.0.3 Estructura del directorio Firmware Framework Usb
a) HID b)CDC c)GEN
a) b)
c)
84
Para realizar una conexión sin características específicas, lo
recomendable es utilizar la clase genérica (GEN) ya que permite una
velocidad más alta que la clase CDC, aunque esta última se utiliza por
resultar más fácil la programación del host. La clase que se utilizó en este
proyecto es la genérica.
Para la programación del micrcontrolador se utilizó como base el
ejemplo Libusb-Generic Driver -C18-PICDEM FUSB que proporciona
Microchip Application Libraries, este ejemplo y fue copiado junto con otras
librerías de microchip, ya que algunas serán modificadas, según las
necesidades de este proyecto.
4.2.1 Estructura Firmware Main.c (Programa principal)
Para la facilidad de modificación, configuración y lectura, se utilizó la
siguiente estructura.
//------------------------------Includes----------------------------------------
#include "USB/usb.h
#include "HardwareProfile.h"
#include "USB/usb_function_generic.h"
En el apartado de los includes, se añade las librerías necesarias para
la ejecución del código del main.c. las anteriores son obligatorias para la
ejecución de la comunicación USB.
//---------------------------------Fuses----------------------------------------
Esta sección es donde vamos a definir los valores de configl y configh,
que es donde se encuentra la configuración de oscilador, uso de
watchdogtimer, funciones de Poweron reset, brown out detect etc. La
85
configuración depende de cada PIC a usar. Su sintaxis es: #pragma config
nombre de fuse = estado. Por ejemplo #pragma config OSC = HS
//-------------------------------Variables--------------------------------------
En esta sección es donde se crean las variables globales, una variable
global es usada por todo nuestro programa y funciones en todo momento.
//---------------------------Prototipos Privados-------------------------------
En esta sección es donde definimos los prototipos de las funciones o
las funciones en sí. Un prototipo de funcion es la manera en que se
construyen la funciones a usar por ejemplo: void myfuncion(void) la cual
posteriormente será llamada por la función principal main y deberá ser
construida de manera correcta bajo la sección de main. En los fragmentos
siguientes se describirán los prototipos que se utilizaron en esta estructura.
static void InitializeSystem(void);
/**En esta función se denominan Todas las rutinas requeridas para la
inicialización USB**/
void USBDeviceTasks(void);
/**Mediante esta función se recibe y trasmiten paquetes a través del
stack, por lo tanto debe ser llamada periódicamente. Esta función se
debe llamar al menos una vez cada 1.8ms durante el proceso de
enumeración USB. Hay dos formas de implementarlo y según como se
haya definido en usb_config.h. Mediante polling debe ser llamada de
forma periódica dentro del bucle principal, en cambio mediante
interrupción debe ser llamada por medio un servicio de interrupción
de alta prioridad. Ver los comentarios de código en línea en la parte
superior de usb_device.c para más detalles sobre los requisitos
mínimos de tiempo al llamar USBDeviceTasks ()**/
void YourHighPriorityISRCode(void);
/**Este retorno será un "rápido retfie", ya que este se encuentra en una
sección de alarmas.**/
void YourLowPriorityISRCode(void);
86
/** Este retorno será un "retfie", ya que este se encuentra en una
sección**/
void USBCBSendResume(void);
/**El USBCBSendResume () "devolución de llamada" función se utiliza
para enviar esta señalización especial USB que despierta la PC. Esta
función puede ser llamada por firmware de aplicación a despertar el
PC.**/
void UserInit(void);
/**En esta función agregamos las condiciones iniciales en las que
trabajara el microcontrolador, generalmente las salidas digitales y
pwm la inicializamos a cero, también se indica que pines son
entradas ya sean digitales o analógicas.**/
void ProcessIO(void);
/**Esta función es un marcador de posición para las rutinas de otros
usuarios. Es una mezcla de ambos, es decir aquí se ejecutaras las
tareas USB y las anexadas por el usuarios como los son convertidores
análogo-digital, pwm, etc.**/
//---------------------------Remapeo de Vector-----------------------------
Se define los vectores de reset, interrupción de prioridad alta y baja.
En los dispositivos PIC18, aborda 0x08 0x00, 0x18 respectivamente, Sin
embargo si se desea utilizar los USB bootloader estos ocuparan las
direcciones 0x00 o 0x00-0x7FF 0xFFF- en función del que se va a utilizar.
//-----------------------------Declaraciones----------------------------------
void main(void){ //Función principal.
InitializeSystem();
#if defined(USB_INTERRUPT)
USBDeviceAttach();
#endif
While(1){
#if defined(USB_POLLING)
87
USBDeviceTasks();
#endif
ProcessIO(); // Función de tareas y comunicación USB.
}//end while
}//end main
void UserInit(void)
{
}
void ProcessIO(void)
{
if((USBDeviceState < CONFIGURED_STATE)||(USBSuspendControl==1))
return;
if(!USBHandleBusy(USBGenericOutHandle))
//Check if the endpoint has received any data from the host.
{
switch(OUTPacket[0])
//Data arrived, check what kind of command might be in the packet of data.
{
case 0x80:
Accion; // Generalmente esta acción es activar una salida
//digital.
break;
case 0x81:
Dato0=Valor
INPacket[0]=Dato0
88
if(!USBHandleBusy(USBGenericInHandle))
{
USBGenericInHandle = USBGenWrite(USBGEN_EP_NUM,(BYTE*)
&INPacket,USBGEN_EP_SIZE);
}
break;
}
USBGenericOutHandle = USBGenRead (USBGEN_EP_NUM,(BYTE*)
&OUTPacket,USBGEN_EP_SIZE);
}
}//end ProcessIO
//-------------------------USB Callback Functions------------------------
En este segmento como el mismo nombre lo indica, se declararán las
funciones USB Callback. La modificación de la estructura diseñada de este
renglón es totalmente opcional.
// Fin de Estructura
Antes de explicar con más detalle la aplicación de esta estructura, se
describirán brevemente las librerías encargadas de administrar los timer, las
interrupciones, los conversores A/D, los PWM y la conexión usb.
4.2.2 Ejemplo de Aplicación de Estructura
Para entender mejor la estructura, se adaptó para que cumpla con las
características de la tabla 4.9. Se colocara solo las partes de la estructura
que se deben modificar, como lo son el apartado de los includes, los fuses, la
función void UserInit(void) y void ProcessIO(void) el código completo se
puede apreciar en el anexo n°1xx.
89
Tabla 4.0.1 características del sistema
Microcontrolador 18f4550
Entrada Digitales 6
Analógicas 13
Salida Digitales 8
PWM 2
Crystal 4Mhz
Comunicación USB
//------------------------------Includes----------------------------------------
#include "USB/usb.h
#include "HardwareProfile.h"
#include "USB/usb_function_generic.h"
#include <p18cxxx.h>
#include <portb.h>
#include <pwm.h>
#include <timers.h>
#include <adc.h>
#include <delays.h>
//---------------------------------Fuses----------------------------------------
#pragma config PLLDIV = 1
#pragma config CPUDIV = OSC1_PLL2
#pragma config USBDIV = 2
#pragma config FOSC = HSPLL_HS
#pragma config FCMEN = OFF
#pragma config IESO = OFF
#pragma config PWRT = OFF
#pragma config BOR = ON
90
#pragma config BORV = 3
#pragma config VREGEN = ON //USB Voltage Regulator
#pragma config WDT = OFF
#pragma config WDTPS = 32768
#pragma config MCLRE = ON
#pragma config LPT1OSC = OFF
#pragma config PBADEN = OFF
#pragma config STVREN = ON
#pragma config LVP = OFF
#pragma config ICPRT = OFF
#pragma config XINST = OFF
#pragma config CP0 = OFF
#pragma config CP1 = OFF
#pragma config CPB = OFF
#pragma config WRT0 = OFF
#pragma config WRT1 = OFF
#pragma config WRTB = OFF
#pragma config WRTC = OFF
#pragma config EBTR0 = OFF
#pragma config EBTR1 = OFF
#pragma config EBTRB = OFF
//-------------------------------Variables--------------------------------------
#if defined(__18F14K50) || defined(__18F13K50) ||
defined(__18LF14K50) || defined(__18LF13K50)
#pragma udata usbram2
#elif defined(__18F2455) || defined(__18F2550) || defined(__18F4455)
91
|| defined(__18F4550)\|| defined(__18F2458) ||
defined(__18F2453) || defined(__18F4558)
||defined(__18F4553)
#pragma udata USB_VARIABLES=0x500
#elif defined(__18F4450) || defined(__18F2450)
#pragma udata USB_VARIABLES=0x480
#else
#pragma udata
#endif
unsigned char OUTPacket[64];
unsigned char INPacket[64];
#pragma udata
int anlg1=0;
int anlg2=0;
unsigned int ch0;
unsigned int ch1;
unsigned int ch2;
unsigned int ch3;
unsigned int ch4;
unsigned int ch5;
unsigned int ch6;
unsigned int ch7;
unsigned int ch8;
unsigned int ch9;
unsigned int ch10;
unsigned int ch11;
92
unsigned int ch12;
//-----------------------------Declaraciones----------------------------------
void main(void){ //Función principal.
InitializeSystem();
#if defined(USB_INTERRUPT)
USBDeviceAttach();
#endif
While(1){
#if defined(USB_POLLING)
USBDeviceTasks();
#endif
ProcessIO(); // Función de tareas y comunicación USB.
}//end while
}//end main
void UserInit(void)
{
//Salidas
PORTD=0x00; //Inicializo las salidas puerto D a cero.
PORTCbits.RC1=0; //Inicializo las salidas puerto C1 y C2 a cero
PORTCbits.RC2=0; //para las 2 salidas de PWM.
TRISD=0x00; //Pines puerto D como salida.
LATD=0x00;
//Entradas digitales
TRISB=0xFF; //Pines del puerto B como entrada.
//Salidas analógicas
93
OpenTimer2(TIMER_INT_OFF & T2_PS_1_16 & T2_POST_1_1);
//Temporizador para módulo PWM: Interrupt disabled, 1:16
//prescale, 1:1 postscale
OpenPWM1(0xFF);
//PWMperiod=[(period)+1]x4xTOSCxTMR2_prescaler =
//[(0xFF)+1]x4x2/96E6x16=341,3us --> 2,9KHz
SetDCPWM1(0x1FF); //Ciclo trabajo PWM --> 50%
OpenPWM2(0xFF);
SetDCPWM2(0x1FF);
}//Fin de UserInit()
void ProcessIO(void)
{
if((USBDeviceState < CONFIGURED_STATE)||(USBSuspendControl==1))
return;
if(!USBHandleBusy(USBGenericOutHandle))
{
anlg1=OUTPacket[1];
anlg2=OUTPacket[2];
SetDCPWM2(anlg2);
SetDCPWM1(anlg1);
switch(OUTPacket[0])
{
case 0x80:
LATDbits.LATD0 = !LATDbits.LATD0;//Salida Digital D0 On/Off
break;
case 0x82:
94
LATDbits.LATD1 = !LATDbits.LATD1;//Salida Digital D1 On/Off
break;
case 0x83:
LATDbits.LATD2 = !LATDbits.LATD2;//Salida Digital D2 On/Off
Break;
case 0x84:
LATDbits.LATD3 = !LATDbits.LATD3;//Salida Digital D3 On/Off
break;
case 0x85:
LATDbits.LATD4 = !LATDbits.LATD4;//Salida Digital D4 On/Off
break;
case 0x86:
LATDbits.LATD5 = !LATDbits.LATD5;//Salida Digital D5 On/Off
Break;
case 0x87:
LATDbits.LATD6 = !LATDbits.LATD6;//Salida Digital D6 On/Off
break;
case 0x88:
LATDbits.LATD7 = !LATDbits.LATD7;//Salida Digtal D7 On/Off
break;
case 0x81:
INPacket[0] = 0x81;
OpenADC(ADC_FOSC_32 & ADC_RIGHT_JUST &
ADC_12_TAD,ADC_CH0 & ADC_INT_OFF &
DC_VREFPLUS_VDD & ADC_VREFMINUS_VSS,12);
SetChanADC(ADC_CH0);
// Esperar que la conversión este completa “canal 0”
95
ConvertADC();
while(BusyADC()==1){}
ch0=ReadADC();
SetChanADC(ADC_CH1);
// Esperar que la conversión este completa “canal 1”
ConvertADC();
while(BusyADC()==1){}
ch1=ReadADC();
SetChanADC(ADC_CH2);
// Esperar que la conversión este completa “canal 2”
ConvertADC();
while(BusyADC()==1){}
ch2=ReadADC();
SetChanADC(ADC_CH3);
// Esperar que la conversión este completa “canal 3”
ConvertADC();
while(BusyADC()==1){}
ch3=ReadADC();
SetChanADC(ADC_CH4);
// Esperar que la conversión este completa “canal 4”
ConvertADC();
while(BusyADC()==1){}
ch4=ReadADC();
96
SetChanADC(ADC_CH5);
// Esperar que la conversión este completa “canal 5”
ConvertADC();
while(BusyADC()==1){}
ch5=ReadADC();
SetChanADC(ADC_CH6);
// Esperar que la conversión este completa “canal 6”
ConvertADC();
while(BusyADC()==1){}
ch6=ReadADC();
SetChanADC(ADC_CH7);
// Esperar que la conversión este completa “canal 7”
ConvertADC();
while(BusyADC()==1){}
ch7=ReadADC();
SetChanADC(ADC_CH8);
// Esperar que la conversión este completa “canal 8”
ConvertADC();
while(BusyADC()==1){}
ch8=ReadADC();
SetChanADC(ADC_CH9);
// Esperar que la conversión este completa “canal 9”
ConvertADC();
while(BusyADC()==1){}
97
ch9=ReadADC();
SetChanADC(ADC_CH10);
// Esperar que la conversión este completa “canal 10”
ConvertADC();
while(BusyADC()==1){}
ch10=ReadADC();
SetChanADC(ADC_CH11);
//Esperar que la conversión este completa “canal 11”
ConvertADC();
while(BusyADC()==1){}
ch11=ReadADC();
SetChanADC(ADC_CH12);
//Esperar que la conversión este completa “canal 12”
ConvertADC();
while(BusyADC()==1){}
ch12=ReadADC();
INPacket[1] = ch0; //Asignar Valor analog A0
INPacket[2] = ch1; //Asignar Valor analog A1
INPacket[3] = ch2; //Asignar Valor analog A2
INPacket[4] = ch3; //Asignar Valor analog A3
INPacket[5] = ch4; //Asignar Valor analog A4
INPacket[6] = ch5; //Asignar Valor analog A5
INPacket[7] = ch6; //Asignar Valor analog A6
INPacket[8] = ch7; //Asignar Valor analog A7
98
INPacket[9] = ch8; //Asignar Valor analog A8
INPacket[10] = ch9; //Asignar Valor analog A9
INPacket[11] = ch10; //Asignar Valor analog A10
INPacket[12] = ch11; //Asignar Valor analog A11
INPacket[13] = PORTBbits.RB0; //Asignar Entrada D1
INPacket[14] =PORTCbits.RC6; //Asignar Entrada D2
INPacket[15] =PORTCbits.RC7; //Asignar Entrada D3
INPacket[18] =PORTBbits.RB1; //Asignar Entrada D4
INPacket[19] =PORTAbits.RA4; //Asignar Entrada D5
INPacket[23] =PORTBbits.RB3; //Estado de Salida D4
INPacket[24] =PORTBbits.RB4; //Estado de Salida D5
INPacket[25] =PORTBbits.RB5; //Estado de Salida D6
INPacket[26] =PORTBbits.RB6; //Estado de Salida D7
INPacket[27] =PORTBbits.RB7; //Estado de Salida D8
if(!USBHandleBusy(USBGenericInHandle))
{
USBGenericInHandle = USBGenWrite(USBGEN_EP_NUM,(BYTE*)
&INPacket,USBGEN_EP_SIZE);
/**Se envia los datos contenidos en el array INPacket[] sobre el
endpoint USBGEN_EP_NUM.**/
}
break;
}
USBGenericOutHandle = USBGenRead (USBGEN_EP_NUM,(BYTE*)
&OUTPacket,USBGEN_EP_SIZE);
99
/**Se recibe los datos contenidos en el array OUTPacket[] sobre el
endpoint USBGEN_EP_NUM.**/
}
}//Fin ProcessIO
4.2.3. Circuito Electrónico de la Tarjeta de Adquisición de Datos basado
en Microcontrolador pic 18f2550 y 18f4550.
En la figura 4.4 Y 4.5 Se puede apreciar la placa que se consideró
más conveniente a la hora de su utilización en el control y monitoreo de
variables de un proceso.
Figura 4.0.4 Tarjeta de Adquisicion con pic 18f4550
100
Figura 4.0.5 Tarjeta de Adquisición con pic 18f2550
101
CAPITULO 5. DISEÑO SOFTWARE HMIUDO
Este capítulo se explicara lo concerniente al desarrollo del software
HMI_UDO, el cual estará separado en varios scripts cada uno con una
función específica, estos se desarrollaron con el lenguaje de programación
python, conjuntamente con las librerías wxpython, pyserial, pyusb, matplotlib,
numpy, scipy y sqlite3, como python es un lenguaje de programación
multiparadigma se utilizó la programación estilo orientada a objetos, además
este estilo es empleado para programar las interfaces graficas utilizando
wxpython.
5.1 SOFTWARE HMI_UDO.
El software HMI_UDO es un paquete multiplataforma, basado en
software libre, que permite visualizar y administrar datos de una planta, a
través del ordenador, cuenta con bases de datos, graficas de tendencias, y
librerías para el desarrollo de interfaces graficas (animaciones de proceso),
los protocolo de comunicación que admite son serial y USB.
5.2 ESTRUCTURA DEL SOFTWARE HMI_UDO.
El software esta distribuidos en 7 scripts para su fácil entendimiento y
modificación. En la figura 5.1 se muestra un diagrama sobre la estructuración
de los scripts que conforman el software.
Los script estarán adaptados a la placa arduino, esto solo es por
comodidad para explicar el funcionamiento de esta estructura, para identificar
102
que partes de los códigos deben ser modificadas para ser compatibles con
las otras placas de adquisición (Placa Pingüino y Placa Pic 18f2550/4550)
tienen como formato-fuente color verde olivo y cursiva, esto cambios están
regidos por el tipo de protocolos de comunicación que las placas incorporan.
Figura 5.0.1 Estructura de Software HMI_UDO
5.2.1 HMI_UDO.py
Este es el script principal está encargado de invocar los script
Mando_Proceso, Graficar_Proceso y Proceso_Virtual. En la figura 5.2 se
muestra la interfaz gráfica principal del sistema.
103
Figura 5.0.2 HMI_UDO ventana principal
5.2.1.1 Código Fuente
# Importación de librerías y scripts.
import wx
from Graficar_Proceso import HmiUdoDemo
from Mando_Proceso import MandoManualUdoDemo
from Proceso_Virtual import ProcesoVirtualUdoDemo
#Definición clase principal
class Frame_Principal(wx.Frame):
def __init__(self):
wx.Frame.__init__(self, None, -1, title= 'Ventana Principal',
size=(325, 180))
sizer=wx.BoxSizer(wx.HORIZONTAL)
panel=wx.Panel(self, wx.ID_ANY)
hbox1=wx.BoxSizer(wx.HORIZONTAL)
Sbox=wx.StaticBox(panel, -1, "Ver")
boxsizer=wx.StaticBoxSizer(Sbox, wx.VERTICAL)
104
self.boton=wx.Button(panel, -1, "Graficas Entradas")
self.boton2=wx.Button(panel, -1, "Proceso Virtual")
self.boton3=wx.Button(panel, -1, "Mandos Manual ")
boxsizer.Add(self.boton, flag=wx.LEFT|wx.TOP|wx.EXPAND,
border=5)
boxsizer.Add(self.boton2, flag=wx.LEFT|wx.TOP|wx.EXPAND,
border=5)
boxsizer.Add (self.boton3, flag=wx.LEFT|wx.TOP|wx.BORDER|
wx.EXPAND, border=5)
self.FotoUdo=wx.StaticBitmap(panel)
self.FotoUdo.SetBitmap(wx.Bitmap('udo.PNG'))
hbox1.Add(boxsizer,0,wx.ALL,10)
hbox1.Add( self.FotoUdo, 0, wx.ALL, 10)
panel.SetSizer(hbox1)
self.boton.Bind(wx.EVT_BUTTON, self.onGraficasEntradas)
self.boton2.Bind(wx.EVT_BUTTON, self.onProcesoVirtual)
self.boton3.Bind(wx.EVT_BUTTON, self.onMandoManual)
# Definición de las funciones de los eventos de los botones de
#invocación de frames secundarios.
def onGraficasEntradas(self, event):
frame = HmiUdoDemo(self)
frame.Show()
105
def onProcesoVirtual(self, event):
frame = ProcesoVirtualUdoDemo(self)
frame.Show()
def onMandoManual(self, event):
frame = MandoManualUdoDemo(self)
frame.Show()
# Bucle de ejecución wxpython
if __name__ == "__main__":
app = wx.PySimpleApp()
frame = Frame_Principal()
frame.Show()
app.MainLoop()
# No es necesario la modificación de este escripts, solo sí no hay
#cambios en los nombres de los escript de los frames secundarios o la
#agregación de nuevos frames desarrollados por el usuario.
5.2.2 Proceso_Virtual.py
Este subprograma está encargado de mostrar representación virtual
del proceso y la actualización de la base de datos, está formado
principalmente del script Obj_Comando.py.
5.2.2.1 Código Fuente
# Importación de librerías y scripts.
import wx
import Obj_Comando as OHC
#--------------------------------------------------------------------------------------------------
106
import Serial_Conect as SC
#--------------------------------------------------------------------------------------------------
import Base_Datos as BD
#Definición clase frame ProcesosVirtualDemo
class ProcesoVirtualUdoDemo(wx.Frame):
def __init__(self, parent):
wx.Frame.__init__(self, None, -1, 'Proceso Virtual',
wx.DefaultPosition,
size=(750, 530), style=wx.DEFAULT_FRAME_STYLE |
wx.NO_FULL_REPAINT_ON_RESIZE)
# Evento para que la interfaz gráfica ProcesoVirtual se actualice cada
#90mseg.
self.redraw_timer = wx.Timer(self)
self.Bind(wx.EVT_TIMER, self.on_redraw_timer, self.redraw_timer)
self.redraw_timer.Start(90)
panel=wx.Panel(self, wx.ID_ANY)
sizer=wx.BoxSizer(wx.VERTICAL)
self.PlantaHmi=OHC.DrawWindow(panel, -1)
sizer.Add(self.PlantaHmi, 1, flag=wx.EXPAND|wx.LEFT|wx.RIGHT,
border=5)
panel.SetSizer(sizer)
# Definicion de la función que esta enlazada con el evento
#wx.EVT_TIMER, se añaden las actualización de base de
# datos y animación del proceso.
107
def on_redraw_timer(self, event):
datosentradas=SC.read()
byteread=SC.readarduino(datosentradas)
# Como se puede observar aquí se asignara una variable a los valores
#adquiridos por el puerto usb o serial, en este caso seis entradas
#analógicas, las cuales si son de 8 bit se recibirá un valor de 0 a 255,
#en este fragmento de código es necesario la conversión al valor real
#de la lectura del sensor.
a=byteread[0][0]
b=byteread[0][1]
c=byteread[0][2]
d=byteread[0][3]
e=byteread[0][4]
f=byteread[0][5]
self.PlantaHmi.UpdateDrawing(a, b, c, d, e, f)
BD.escribir_registro(byteread[0][0], byteread[0][1], byteread[0][2],
byteread[0][3], byteread[0][4], byteread[0][5],
byteread[0][6], byteread[0][7], byteread[0][8],
byteread[0][9],byteread[0][10],
byteread[0][11],byteread[0][12],
byteread[0][13],byteread[0][14],
byteread[0][15],byteread[0][16],
byteread[0][17], byteread[1],
byteread[2])
108
Figura 5.0.3 Proceso Virtual
5.2.3. Obj_Comando.py
En este scripts se definen los comandos para la realización de la
representación gráfica del proceso a monitorear. Los comandos
desarrollados se ven a continuación.
AnimacionText
Este comando se utiliza para agregar en la area de
virtualizacion, una cadena de caracteres que representa un valor
enviado por el dispositivo de adquisición.
Sintaxis
AnimacionText (x, y, sensor, color, unidad), donde
109
x: posición en el eje de las x
y: posición en el eje de las y
sensor: dato del dispositivo de adquisición que se quiera
muestrear.
color: color de texto
unidad: la unidad del dato, si no tiene color un espacio entre
comilla (“ “)
ej: AnimacionText (20, 50, a1, '#FFF720', '°C'); en la figura 5.4
muestra el resultado de este comando.
Figura 5.0.4 Animación Texto
AnimacionCorteRectangular
Este comando da como resultado un corte rectangular que su
altura varia con respecto a la asignación de una entrada del
dispositivo de adquisición.
Sintaxis
AnimacionCorteRectangualr(x, y, Ancho, AltInicial , sensor ,
color), donde:
x: posición en el eje de las x.
y: posición en el eje de las y.
Ancho: Ancho de la tuberia.
largo: longitud de la tuberia.
color: color de la tuberia.
110
Ej:
AnimacionCorteRectangualr(59, 205, 51, 10, a1, '#30E2FF')
En la figura 5.5 se puede observar, como varia la altura de los corte
con respecto a una entrada, iniciando en su valor minimo ya que la entrada
es 0 y terminando en el valor más alto q es 255 ya que es una entrada de 8
bits.
Figura 5.0.5 Animación Corte Rectagular
TuberiaHorizontal
Este comando se encaga de dibujar una tubería horizontal.
Sintaxis
tuberiaHorizontal(x, y, ancho, largo,color), donde:
x: posición en el eje de las x.
y: posición en el eje de las y.
Ancho: Ancho de la tuberia.
largo: longitud de la tuberia.
color: color de la tuberia.
111
Ej:
tuberiaHorizontal(80, 80, 18, 160, '#ffec00')
Figura 5.0.6 Tuberia Horizontal
TuberiaVertical
Este comando se encaga de dibujar una tubería vertical.
tuberiaVertical(x, y, ancho, largo, color)
x: posición en el eje de las x.
y: posición en el eje de las y.
Ancho: Ancho de la tuberia.
largo: longitud de la tuberia.
color: color de la tuberia.
Ej:
tuberiaVertical(50, 60, 18, 160,'#ffec00')
112
Figura 5.0.7 Tuberia Vertical
MdVerticalIzq
Este pequeño algoritmo crea una cinta métrica en la ventana de
proceso virtual, la escala puede ser variada.
Sintaxis
MdVerticalIzq(self, dc, x, y, l, color), donde:
x: posición en el eje de las x.
y: posición en el eje de las y.
l: longitud. l=el valor deseado +1
color: color de la cinta.
Ej
MdVerticalIzq( 30, 60, 121, „#7700A0’)
Figura 5.0.8 Escala Verical Izquierda
113
MdVerticalDch
Este pequeño algoritmo crea una cinta métrica en la ventana de
proceso virtual, la escala puede ser variada.
Sintaxis
MdVerticalIzq(self, dc, x, y, l, color), donde:
x: posición en el eje de las x.
y: posición en el eje de las y.
l: longitud. l=el valor deseado +1
color: color de la cinta.
Ej
MdVerticalIzq( 80, 100, 101, „#07DF00’)
Figura 5.0.9 Escala Verical Derecha
MdHorizontalInf
Este pequeño algoritmo crea una cinta métrica en la ventana de
proceso virtual, la escala puede ser variada.
Sintaxis
MdHorizontalInf (self, dc, x, y, l, color), donde:
x: posición en el eje de las x.
y: posición en el eje de las y.
114
l: longitud. l=el valor deseado +1
color: color de la cinta.
Ej
MdHorizontalInf ( 100, 80, 101, „#FFFFFF’)
Figura 5.0.10 Escala Horizontal Inferior
MdHorizontalSup
Este pequeño algoritmo crea una cinta métrica en la ventana de
proceso virtual, la escala puede ser variada.
Sintaxis
MdHorizontalSup (self, dc, x, y, l, color), donde:
x: posición en el eje de las x.
y: posición en el eje de las y.
l: longitud. l=el valor deseado +1
color: color de la cinta.
Ej
MdHorizontalSup( 50, 180, 201, „#060089’)
Figura 5.0.11 Escala Horizontal Superior
115
Imagen
Psudocodigo encargado de agregar una imagen al la ventana de
virtualizacion.
Sintaxis:
Imagen(x, y, i), donde:
x: posición en el eje de las x.
y: posición en el eje de las y.
i: nombre de la imagen, sino esta en el mismo archivo del
programa, anexar la ubicación.
Ej:
Imagen(150,364, 'ImagenesHMI/BombaUp.png')
Figura 5.0.12 Imagen importada por el Comando
5.2.3.1 Código Fuente
# Importación de librerías y scripts.
import wx
USE_BUFFERED_DC = True
#Definición clase BufferedWindow
class BufferedWindow(wx.Window):
def __init__(self, parent, ID):
116
wx.Window.__init__(self, parent, ID)
wx.EVT_PAINT(self, self.OnPaint)
wx.EVT_SIZE(self, self.OnSize)
self.Bind(wx.EVT_ERASE_BACKGROUND, lambda x: None)
self.OnSize(None)
def Draw(self, dc):
pass
def OnPaint(self, event):
if USE_BUFFERED_DC:
dc = wx.BufferedPaintDC(self, self._Buffer)
else:
dc = wx.PaintDC(self)
dc.DrawBitmap(self._Buffer, 0, 0)
def OnSize(self,event):
Size = self.ClientSize
self._Buffer = wx.EmptyBitmap(*Size)
def UpdateDrawing(self, a, b, c, d, e, f):
a1=a
a2=b
a3=c
a4=d
a5=e
a6=f
dc = wx.MemoryDC()
117
dc.SelectObject(self._Buffer)
self.Draw(dc, a, b, c, d, e, f)
del dc
self.Refresh()
self.Update()
class DrawWindow(BufferedWindow):
def __init__(self, parent, ID):
BufferedWindow.__init__(self, parent, ID)
def Draw(self, dc, a1, a2, a3, a4, a5,a6):
def AnimacionText(x, y, sensor, color, Unidad):
font = wx.Font(18, wx.ROMAN,wx.NORMAL, wx.NORMAL)
dc.SetTextForeground('#008d84')
dc.SetFont(font)
dc.DrawText(str(sensor), x, y)
dc.DrawText(Unidad, x, y)
def AnimacionCorteRectangualr(x, y, Ancho, AltInicial , ec, color):
dc.SetPen(wx.Pen(color, 1))
dc.SetBrush(wx.Brush(color, wx.SOLID))
DeltaY=y-ec
DeltaAlto=AltInicial+ec
dc.DrawRectangle(x, DeltaY, Ancho, DeltaAlto)
def tuberiaHorizontal(x, y, ancho, largo):
dc.GradientFillLinear((x, y,largo, ancho/2), color, '#000000',
wx.NORTH)
118
dc.GradientFillLinear((x, y+ancho/2, largo, ancho/2), color,
'#000000', wx.SOUTH)
def tuberiaVertical(x, y, ancho, largo):
dc.GradientFillLinear((x, y,ancho/2, largo), color, '#000000',
wx.WEST)
dc.GradientFillLinear((x+ancho/2, y, ancho/2, largo), color,
'#000000', wx.EAST)
def MdVerticalIzq(self, dc, x, y, l, s, color):
for i in range(l):
if not (i % 20):
dc.DrawLine(10+x, i+y, 20+x, i+y)
w, h = dc.GetTextExtent(str(i))
font = wx.Font(6, wx.ROMAN,wx.NORMAL, wx.NORMAL)
dc.SetTextForeground(color)
dc.SetFont(font)
dc.DrawText(str(i), 21+x, -i+y+l-5)
elif not (i % 10):
dc.DrawLine(10+x, i+y, 18+x, i+y)
elif not (i % 2): dc.DrawLine(10+x, i+y, 14+x, i+y)
def MdVerticalDch(self, dc, x, y, l, s, color):
for i in range(l):
if not (i % 20):
dc.DrawLine(10+x, i+y, 20+x, i+y)
w, h = dc.GetTextExtent(str(i))
font = wx.Font(6, wx.ROMAN,wx.NORMAL, wx.NORMAL)
dc.SetTextForeground(color)
119
dc.SetFont(font)
dc.DrawText(str(i), 21+x, -i+y+l-5)
elif not (i % 10):
dc.DrawLine(10+x, i+y, 18+x, i+y)
elif not (i % 2): dc.DrawLine(10+x, i+y, 14+x, i+y)
def MdHorizontalInf(self, dc, x, y, l, s, color):
for i in range(RW):
if not (i % 20):
dc.DrawLine(i+x, 0+y, i+x, 10+y)
w, h = dc.GetTextExtent(str(i))
font = wx.Font(6, wx.ROMAN,wx.NORMAL, wx.NORMAL)
dc.SetTextForeground(color)
dc.SetFont(font)
dc.DrawText(str(i), i+x-w/2, 11+y)
elif not (i % 10):
dc.DrawLine(i+x, 0+y, i+x, 8+y)
elif not (i % 2): dc.DrawLine(i+x, 0+y, i+x, 4+y)
def MdHorizontalSup(self, dc, x, y, l, s, color):
for i in range(RW):
if not (i % 20):
dc.DrawLine(i+x, 10+y, i+x, 20+y)
w, h = dc.GetTextExtent(str(i))
font = wx.Font(6, wx.ROMAN,wx.NORMAL, wx.NORMAL)
dc.SetTextForeground(color)
120
dc.SetFont(font)
dc.DrawText(str(i), i+x-w/2, y)
elif not (i % 10):
dc.DrawLine(i+x, 12+y, i+x, 20+y)
elif not (i % 2): dc.DrawLine(i+x, 16+y, i+x, 20+y)
def Imagen(x, y, modelo):
bitmap = wx.BitmapFromImage(wx.Image(modelo))
dc.DrawBitmap(bitmap, x, y)
dc.BeginDrawing()
# Aquí se anexara los comandos con las características deseadas por
#el usuario.
dc.EndDrawing()
En el siguiente apartado se verá el código necesario para
formar la interfaz grafica, que se mostro en la figura 5.3
dc.BeginDrawing()
dc.SetBackground( wx.Brush("Black") )
dc.Clear()
Imagen(76,69, 'ImagenesHMI/codo1.png')
Imagen(245,69, 'ImagenesHMI/codo2.png')
Imagen(50, 100, 'ImagenesHMI/TanqCorte.png')
Imagen(116,190, 'ImagenesHMI/valve1.png')
Imagen(164,199, 'ImagenesHMI/codo2.png')
121
dc.SetPen(wx.Pen('#545454', 4))
dc.SetBrush(wx.Brush('#545454', wx.TRANSPARENT))
dc.DrawRectangle(50, 235, 250, 80)
tuberiaHorizontal(105, 67, 18, 140)
tuberiaVertical(179, 231, 18, 50)
tuberiaVertical(259, 99, 18, 100)
tuberiaVertical(277, 232, 18, 50)
Imagen(259,154, 'ImagenesHMI/BombaUp.png')
AnimacionCorteRectangualr(51, 236, 248, 78, -a1/6.6, '#30E2FF')
AnimacionCorteRectangualr(59, 205, 51, 10, a1/3.0725, ' #30E2FF')
Imagen(720, 370, 'ImagenesHMI/Tanque2.png')
Imagen(80, 440, 'ImagenesHMI/tanque3.png')
Imagen(363, 320, 'ImagenesHMI/ValvulaManual1.png')
tuberiaHorizontal(184, 335, 15, 180)
Imagen(490,236, 'ImagenesHMI/CalentadoTuberia.png')
tuberiaHorizontal(395, 335, 15, 100)
Imagen(150,364, 'ImagenesHMI/BombaUp.png')
Imagen(151,335, 'ImagenesHMI/codo1.png')
Imagen(630,334, 'ImagenesHMI/codo2.png')
tuberiaVertical(647, 366, 15, 79)
Imagen(647,445, 'ImagenesHMI/codo3.png')
tuberiaHorizontal(680, 462, 15, 40)
dc.EndDrawing()
122
5.2.4. Graficar_Proceso.py
Pseudocódigo encargado de incorporar las graficas de las variables
que intervienen en el proceso en función del tiempo.
5.2.4.1. Código Fuente
# Importación de librerías y scripts.
import wx
#--------------------------------------------------------------------------------------------------
import Serial_Conect as SC
#--------------------------------------------------------------------------------------------------
import matplotlib
matplotlib.use('WXAgg')
from matplotlib.figure import Figure
from matplotlib.backends.backend_wxagg import \
FigureCanvasWxAgg as FigCanvas, \
NavigationToolbar2WxAgg as NavigationToolbar
import numpy as np
import pylab
from datetime import datetime
#Definición clase GraficaUdoDemo
class GraficaUdoDemo(wx.Frame):
def __init__(self, parent):
wx.Frame.__init__(self, None, -1, 'Graficas', wx.DefaultPosition,
123
size=(310, 340), style=wx.DEFAULT_FRAME_STYLE |
wx.NO_FULL_REPAINT_ON_RESIZE)
self.redraw_timer = wx.Timer(self)
self.Bind(wx.EVT_TIMER, self.on_redraw_timer, self.redraw_timer)
self.redraw_timer.Start(90)
self.panel=wx.Panel(self, wx.ID_ANY)
self.vbox1=wx.BoxSizer(wx.VERTICAL)
self.hbox1=wx.BoxSizer(wx.HORIZONTAL)
#-----------------------------------------------------------------------------------
self.datagen = SC.read()
byteread=SC.readarduino(self.datagen)
self.data=[byteread[0][0]]
self.avgData=[byteread[0][1]]
self.data2=[byteread[0][2]]
self.data3=[byteread[0][3]]
self.data4=[byteread[0][4]]
self.data5=[byteread[0][5]]
#-----------------------------------------------------------------------------------
self.init_plot()
self.canvas = FigCanvas(self.panel, -1, self.fig)
self.hbox1.Add(self.canvas,-1,flag=wx.LEFT | wx.TOP | wx.GROW)
self.panel.SetSizer(self.hbox1)
def init_plot(self):
self.dpi = 100
self.fig = Figure((3.0, 3.0), dpi=self.dpi)
self.axes = self.fig.add_subplot(111)
124
self.axes.set_axis_bgcolor('black')
self.axes.set_title('Entradas Analogicas', size=12)
pylab.setp(self.axes.get_xticklabels(), fontsize=8)
pylab.setp(self.axes.get_yticklabels(), fontsize=8)
#-------------------------------------------------------------------------------------------------
self.plot_data = self.axes.plot(
self.data,
linewidth=1,
color=(1, 1, 0),
)[0]
self.plotAvg = self.axes.plot(
self.avgData,
linewidth=1,
color=(0, 0, 1),
)[0]
self.plot_data2 = self.axes.plot(
self.data2,
linewidth=1,
color=(0.5, 0.5, 0.5),
)[0]
self.plot_data3 = self.axes.plot(
self.data3,
linewidth=1,
color=(0.8, 0.8, 0.8),
125
)[0]
self.plot_data4 = self.axes.plot(
self.data4,
linewidth=1,
color=(0.0, 0.5019607843137255, 0.0),
)[0]
self.plot_data5 = self.axes.plot(
self.data5,
linewidth=1,
color=(1.0, 0.0, 1.0),
)[0]
#---------------------------------------------------------------------------------------------------
def draw_plot(self):
xmax = len(self.data) if len(self.data) > 50 else 50
xmin = xmax - 50
ymin = round(min(self.data), 0) - 1
ymax = round(max(self.data), 0) + 1
self.axes.set_xbound(lower=xmin, upper=xmax)
self.axes.set_ybound(lower=ymin, upper=ymax)
self.axes.grid(True, color='gray')
self.plot_data.set_xdata(np.arange(len(self.data)))
self.plot_data.set_ydata(np.array(self.data))
126
self.plotAvg.set_xdata(np.arange(len(self.avgData)))
self.plotAvg.set_ydata(np.array(self.avgData))
self.plot_data2.set_xdata(np.arange(len(self.data2)))
self.plot_data2.set_ydata(np.array(self.data2))
self.plot_data3.set_xdata(np.arange(len(self.data3)))
self.plot_data3.set_ydata(np.array(self.data3))
self.plot_data4.set_xdata(np.arange(len(self.data4)))
self.plot_data4.set_ydata(np.array(self.data4))
self.plot_data5.set_xdata(np.arange(len(self.data5)))
self.plot_data5.set_ydata(np.array(self.data5))
self.canvas.draw()
def on_redraw_timer(self, event):
#---------------------------------------------------------------------------------------------------
datosentradas=SC.read()
byteread=SC.readarduino(datosentradas)
self.data.append(byteread[0][0])
self.avgData.append(byteread[0][1])
self.data2.append(byteread[0][2])
self.data3.append(byteread[0][3])
self.data4.append(byteread[0][4])
self.data5.append(byteread[0][5])
#-------------------------------------------------------------------------------------------------
self.draw_plot()
127
5.2.5. Mando_Proceso.py
En este script se anexara los botones, slider, etc, encargados de
modificar el estado de los actuadores o en si el estado de una determinada
variable. Para ello se le recomienda al lector familiarizarse con los widgets
relacianodos a los sizer, boxsizer, gridsizer y a los manojadores eventos de
wxpython, en el apéndice A-x se puede apreciar un resumen de estos
widgets.
5.2.5.1 Código Fuente
import wx
#--------------------------------------------------------------------------------------------------
import Serial_Conect as SC
#--------------------------------------------------------------------------------------------------
class MandoManualUdoDemo(wx.Frame):
def __init__(self, parent):
wx.Frame.__init__(self, None, -1, 'Mando Manual',
wx.DefaultPosition,size=(340, 400),
style=wx.DEFAULT_FRAME_STYLE |
wx.NO_FULL_REPAINT_ON_RESIZE)
self.redraw_timer = wx.Timer(self)
self.Bind(wx.EVT_TIMER, self.on_redraw_timer, self.redraw_timer)
self.redraw_timer.Start(90)
panel=wx.Panel(self, wx.ID_ANY)
128
Sbox=wx.StaticBox(panel, -1, "Salida Digital")
Sbox1=wx.StaticBox(panel, -1, "Salida Analogica")
boxsizer=wx.StaticBoxSizer(Sbox, wx.HORIZONTAL)
boxsizer1=wx.StaticBoxSizer(Sbox1, wx.VERTICAL)
vbox=wx.BoxSizer(wx.VERTICAL)
self.button1 = wx.Button(panel, -1, "Salida1On", size=(70, 30))
self.button2 = wx.Button(panel, -1, "Salida1Off", size=(70, 30))
self.button3 = wx.Button(panel, -1, "Salida2 On", size=(70, 30))
self.button4 = wx.Button(panel, -1, "Salida2 Off", size=(70, 30))
boxsizer.Add(self.button1,-1,wx.LEFT|wx.TOP,5)
boxsizer.Add(self.button2,-1,wx.LEFT|wx.TOP,5)
boxsizer.Add(self.button3,-1,wx.LEFT|wx.TOP,5)
boxsizer.Add(self.button4,-1,wx.LEFT|wx.TOP,5)
self.Bind(wx.EVT_BUTTON, self.Out1On, self.button1)
self.Bind(wx.EVT_BUTTON, self.Out2On, self.button2)
self.Bind(wx.EVT_BUTTON, self.Out3On, self.button3)
self.Bind(wx.EVT_BUTTON, self.Out4On, self.button4)
self.slider1 = wx.Slider(panel, 100, 0, 0, 255, size=(250, -1),
style=wx.SL_HORIZONTAL | wx.SL_AUTOTICKS |
wx.SL_LABELS )
self.slider2 = wx.Slider(panel, 100, 0, 0, 255, size=(250, -1),
style=wx.SL_HORIZONTAL | wx.SL_AUTOTICKS |
129
wx.SL_LABELS )
self.slider3 = wx.Slider(panel, 100, 0, 0, 255, size=(250, -1),
style=wx.SL_HORIZONTAL | wx.SL_AUTOTICKS |
wx.SL_LABELS )
self.lbl = wx.StaticText(panel,-1,"PWM1")
self.lbl2 = wx.StaticText(panel,-1,"PWM2")
self.lbl3 = wx.StaticText(panel,-1,"PWM3")
boxsizer1.Add(self.slider1,-1,wx.CENTER,1)
boxsizer1.Add(self.lbl,-1,wx.CENTER,1)
boxsizer1.Add(self.slider2,-1,wx.CENTER,1)
boxsizer1.Add(self.lbl2,-1,wx.CENTER,1)
boxsizer1.Add(self.slider3,-1,wx.CENTER,1)
boxsizer1.Add(self.lbl3,-1,wx.CENTER,1)
vbox.Add(boxsizer, 0, wx.CENTER, 5)
vbox.Add(boxsizer1, 0, wx.CENTER, 5)
panel.SetSizer(vbox)
def outanlg1(self, valor1):
SC.writeAnalog(valor1, 'R')
def outanlg2(self, valor2):
SC.writeAnalog(valor2, 'G')
def outanlg3(self, valor3):
SC.writeAnalog(valor3, 'B')
130
def on_redraw_timer(self, event):
self.outanlg1(self.slider1.GetValue())
self.outanlg2(self.slider2.GetValue())
self.outanlg3(self.slider3.GetValue())
def Out1On(self, event):
return SC.write('b')
def Out1Off(self, event):
return SC.write('f')
def Out2On(self, event):
return SC.write('c')
def Out2Off(self, event):
return SC.write('e')
5.2.6. Base_Datos.py.
Esta librería se encargada de gestionar la base de datos, añade los
datos recibidos a un archivo .db y a su vez un archivo .txt. , el archivo .db se
crea con el script CrearBaseDatos.py, la cantidad de datos a registrar
dependerá del usuario.
5.2.6.1. Código Fuente.
import sqlite3 as sq3
from datetime import datetime
#Asignando nombre del archivo .db creado a la variable db.
db='basedathmi.db'
131
def leer_registros():
con = sq3.connect(db)
cur = con.cursor()
cur.execute("SELECT * FROM datosplanta1")
registros=cur.fetchall()
cur.close()
con.close()
#Definición de función escribir_registro, está regida por la cantidad de
#variable que el usuario quiera almacenar en este caso 6 entradas
#analógicas, 5 digitales, 4 salidas analógicas, 3 pwm, fecha y tiempo
#la cantidad de atributos de esta función deben coincidir con el
#numero de slot de registro del archivo .db.
def escribir_registro(anlg1, anlg2, anlg3, anlg4, anlg5, anlg6, dg1, dg2,
dg3, dg4, dg5, od1, od2, od3, od4, oa1, oa2, oa3,
fecha, tiempo):
con = sq3.connect(db)
cur = con.cursor()
#matriz de asignación de datos de planta.
matr=(anlg1, anlg2, anlg3, anlg4, anlg5, anlg6, dg1, dg2, dg3, dg4,
dg5, od1, od2, od3, od4, oa1, oa2, oa3, fecha, tiempo)
#Insertando datos de variables dentro de la base de datos,
#recordando que los nombres deben de coincidir con el nombre de
132
#cada campo del archivo .db y con el nombre de la tabla del
#archivo .db.
#---------------------------Nombre de Tabla------Nombres de Campos------
cur.execute("insert into datosplanta1 (anlg1, anlg2, anlg3, anlg4,
anlg5, anlg6, dg1, dg2, dg3, dg4, dg5, od1, od2, od3,
od4, oa1, oa2, oa3, fecha, tiempo) values
(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)",(matr))
con.commit()
#cerrando cursor
cur.close()
#cerrando conexión
con.close()
#Abriendo archivo texto para iniciar el registro de las variables en este.
f=open("datos.txt", "a")
#Escribiendo datos del proceso en el archivo texto.
f.write('%f\t' % anlg1)
f.write('%f\t' % anlg2)
f.write('%f\t' % anlg3)
f.write('%f\t' % anlg4)
f.write('%f\t' % anlg5)
f.write('%f\t' % anlg6)
f.write('%s\t' % dg1)
f.write('%s\t' % dg2)
f.write('%s\t' % dg3)
f.write('%s\t' % dg4)
f.write('%s\t' % dg5)
f.write('%s\t' % od1)
133
f.write('%s\t' % od2)
f.write('%s\t' % od3)
f.write('%s\t' % od4)
f.write('%f\t' % oa1)
f.write('%f\t' % oa2)
f.write('%f\t' % oa3)
f.write('%s\t' % fecha)
f.write('%f\n' % tiempo)
#cerrando archivo texto
f.close()
5.2.7. Serial_Conect.py
Script encargado de la comunicación puerto serie, y la recopilación de
los datos enviados por el hardware de adquisición, está regido por dos
variables, la primera es la asignación del puerto que le dio el ordenador al
dispositivo (port), y la segunda es la velocidad de la comunicación
(velocidad).
5.2.7.1. Código Fuente
import serial
import time
from datetime import datetime
#ser=serial.Serial(port, velocidad)
134
ser=serial.Serial('COM3', 9600)
time.sleep(1)
def desconectar():
ser.close()
def is_number(s):
try:
int(s)
return True
except ValueError:
return False
def readarduino(newdata):
iterations = newdata.count(',')
i=1
itergrid=[-1]
datagrid=[]
while i <= iterations:
newcomma=newdata.find(',',itergrid[i-1]+1)
itergrid.append(newcomma)
databit=newdata[itergrid[i-1]+1:itergrid[i]]
if is_number(databit)==True:
databit=int(databit)
datagrid.append(databit)
i+=1
databit=newdata[itergrid[i-1]+1:]
if is_number(databit)==True:
135
databit=int(databit)
datagrid.append(databit)
return datagrid, datetime.now(), time.clock()
def read():
ser.write("a".encode('ascii'))
return ser.readline()
def writeAnalog(valor, caracter):
ser.write(str(valor).rjust(3,'0'))
return ser.write(caracter.encode('ascii'))
def write(caracter):
return ser.write(caracter.encode('ascii'))
En la figura 5.1 se puede observar los datos recibidos desde el
arduino al utilizar el comando read().
La función readarduino(newdata); donde newdata= read(), es
básicamente un organizador de elementos en un array, tomando como
referencia de culminación de elementos el carácter separador especial la
coma („,‟) en la figura 5.2 se puede apreciar el resultado de este comando.
Figura 5.0.13 Datos Recibidos Arduino
136
Figura 5.0.14 Datos Recibido Arduino Organizado en un Array
5.2.8. USB_Pic_Conect.py
Este script esta en cargado de administrar la conexión USB para la
placas basadas en microcontroladores pic.
5.2.8.1 Código Fuente
#!/usr/bin/python
import sys, usb
from datetime import datetime
import time
IdVendedor=0xXXXX
IdProducto=0xXXXX
busses = usb.busses() # enumerate busses
for bus in busses:
devices = bus.devices
for dev in devices:
if dev.idVendor==IdVendedor and dev.idProduct==IdProducto
dev = dev
137
conf = dev.configurations[0]
intf = conf.interfaces[0][0]
endpoints = []
handle = dev.open()
handle.detachKernelDriver(0)
handle.detachKernelDriver(1)
handle.setConfiguration(conf)
handle.claimInterface(intf)
handle.setAltInterface(intf)
def write(ep, buff, timeout = 100):
try:
return handle.interruptWrite(ep, buff, timeout)
except:
return 0
def read(ep, size, timeout = 100):
try:
return handle.interruptRead(ep, size, timeout)
except:
return []
A diferencia del puerto serie los datos enviados por el dispositivo por
puerto USB, ya viene organizados y separados en un array. En la figura 5.3
se ven estos datos.
138
Figura 5.0.15 Datos Recibidos Por Puerto USB PIC 18f
5.2.9. CrearBaseDatos.py
Este Script tiene como función principal crear un archivo .db, para
luego ser utilizada por el script Base_Datos.py.
5.2.9.1. Código Fuente
import sqlite3
conn=sqlite3.connect('BasesDeDatosPlantaPrueba.db')
c=conn.cursor()
c.execute('''CREATE TABLE PlantaPrueba(anlg1 int, anlg2 int, anlg3 int,
anlg4 int, anlg5 int, anlg6, dg1 int, dg2 int, dg3 int, dg4 int,
dg5 int, od1 int, od2 int, od3 int, od4 int, oa1 int, oa2 int,
oa3 int, fecha TEXT, tiempo TEXT)''')
conn.commit()
c.close()
139
CAPITULO 6. .VALIDACIÓN DEL SISTEMA HMI_UDO
A continuación se presenta la aplicación del sistema diseñado, con el
objeto de verificar su funcionamiento, para ellos se utilizó 2 plantas pilotos,
de diferentes características, la primera es una tarjeta de verificación de
entradas y salidas, llamada Planta P1 y la segunda es la unidad Armfield
FM51. Para realizar dicha validación se estableció una secuencia de pasos.
Paso 1. Identificar el número de entradas y salidas del proceso, y comprobar
si estas cumplen con la capacidad de entradas y salidas de los dispositivos
de adquisición ya mencionados.
Paso 2. Crear el archivo .db para la gestión de base de datos utilizando el
script Crear_Base_Datos.py y crear un archivo .txt con el nombre de su
preferencia.
Paso 3. Programar el dispositivo de adquisición para que tenga las
características deseadas por el usuario y el ajuste de los array de
transferencias ligado al protocolo de comunicación a utilizar.
Paso 4. Luego De elegir el protocolo de comunicación configurar en los script
los parámetros Puerto y velocidad en el caso de utilizar puerto serie y PID y
VID en el caso del puerto USB.
Paso 5. Crear la representación gráfica animada del proceso modificando el
pseudocódigo Obj_Comando.py, para el script Proceso_Virtual.py, se
recomienda utilizar el programa FacilitadoHMI.py.
140
Paso 6. Si se desea añadir las gráficas de las variables del proceso con
respecto al tiempo, utilizar el script Graficas_Proceso.py
Paso 7. Incorporación de botones, gaugues, slider, etc para intervenir en el
proceso, modificando o adaptando a las necesidades del usuario el script
Mando_Proceso.py.
Paso 8. Ejecutar el script HMI_UDO.py para poner en funcionamiento el
sistema.
En la Figura 6.1 se puede apreciar el flujograma de las secuencias de paso
para aplicar el sistema.
141
Figura 6.0.1 Pasos para utilizar Paquete HMI_UDO
142
Figura 6.0.2 Pasos para Utilizar Paquete HMI_UDO (Continuación)
143
Figura 6.0.3 Pasos para Utilizar Paquete HMI_UDO (Continuación)
144
6.1. Verificación con Planta P1.
La Planta P1 es un circuito impreso compuesto de 13 trimmers, que
representan entradas analógicas, una barra led de 10 slot para identificar
salidas digitales, 6 led para visualizar salidas analógicas o digital y 1 Dip
switches de 8 slot para simular entradas digitales. En la figura 6.1 se observa
la placa de prueba.
Figura 6.0.4 Planta P1
En la tabla 6.1 se muestra un resumen de las características de la
plata P1; en la tabla 6.2 y 6.3 las características que tendrán los dispositivos
de adquisición ADQ18f2550 y 4550 respectivamente para que interactúe con
la planta P1 así culminar con el paso 1.
145
Tabla 6.0.1 Característica de la Planta P1
Planta P1
Pruebas
Digitales 10
Analógicas 13
Digitales 10
PWM 6
Tabla 6.0.2 Características de Prueba Placa ADQ 18F2550
Microcontrolador 18f2550
Entrada Digitales 6
Analógicas 6
Salida Digitales 5
PWM 2
Crystal 4Mhz
Comunicación USB
Tabla 6.3 Características de Prueba Placa ADQ 18F4450
Microcontrolador 18f4550
Entrada Digitales 6
Analógicas 13
Salida Digitales 8
PWM 2
Crystal 20Mhz
Comunicación USB
En el paso 2 se crearan las bases de datos en sqlit3 y en un archivo
txt, para facilidad de concretar este paso se puede utilizar el script
CrearBaseDatos.py, en el apéndice 7 se observa la utilización de este
script para almacenar los datos recibidos de las tarjetas respectivamente. Se
146
puede apreciar en la figura 6.5 y 6.6 como quedan los slot de registro del
archivo .db. Para almacenar en archivo txt solo se debe crear un archivo txt
con el nombre de su preferencia.
Figura 6.0.5 Archivo base dato hmi.db sin datos
Figura 6.0.6 Archivo BasesDatosPlantaP1_4550.db sin datos
La modificación de los script para la adaptación a las características
presentadas en las tablas 6.2 y 6.3 se pueden observar de manera
consecutiva en los apéndices 8-12 para el pic 18f2550 y los apéndices 13-
17 los correspondientes al pic 18f4550. En las figuras 6.7 y 6.8 se observa
las hmi resultantes de la modificación del script Virtual_Proceso.py y
Obj_Comando.py, en las imágenes 6.9 y 6.10 las gráficas de las variables
obtenidas del proceso, resultado de la modificación del script
Graficar_Proceso.py, las figuras 6.11 y 6.12 representan la interfaz gráfica
para la modificación de las salidas del proceso, la adaptación de estas
vienen ligada a la modificación del código Mando_Proceso.py y por ultimo las
imágenes correspondiente las bases de datos luego de la ejecución del
sistema son las 6.13, 6.14, 6.15 y 6.16.
147
Figura 6.0.7 HMI DE LA PLANTA P1 (MODELO 1)
Figura 6.0.8 HMI Planta P1 (Modelo 2)
148
Figura 6.0.9 Graficas Entradas Analógica Planta P1 (18f2550)
Figura 6.0.10 Graficas Entradas Analógica Planta P1 (18f4550)
149
Figura 6.0.11 Interfaz para Control de Salida (Modelo 1).
Figura 6.0.12 Interfaz para Control de Salida (Modelo 2)
150
Figura 6.0.13 Base de Datos Planta P1 18f2550 (Sqlite Administrador)
151
Figura 6.0.14 Base de Datos Planta P1 18f2550 (Archivo Texto)
152
Figura 6.0.15 Base de Datos Planta P1 18f4550 (Sqlite Administrador)
153
Figura 6.0.16 Base de Datos Planta P1 18f4550 (Archivo Texto)
154
155
6.2. Verificación con Planta Armfield Fm-51.
La unidad Armfield FM-51 es una unidad a pequeña escala de
demostración del funcionamiento de dos bombas usadas en serie y en
paralelo. Esta consiste en un tanque conectado a un sistema de tuberías y a
dos bombas. Una de las bombas es monofásica trabaja a velocidad
constante, mientras que la segunda bomba monofásica necesita un variador
de frecuencia para ponerla en funcionamiento.
El sistema cuenta con una serie de sensores colocados en las tuberías
que miden las variables correspondientes a temperatura, presión y flujo, de
los fluidos que se estén estudiando en el proceso.
Mediante el posicionamiento de las válvulas, se puede direccionar el
camino del fluido, y trabajar con las dos bombas en serie o en paralelo.
Además, mediante el variador de velocidad se puede cambiar la velocidad de
la segunda bomba, lo que crearía un cambio en el nivel de flujo y presión, del
fluido.
La idea de variar el flujo mediante las válvulas del sistema o el variador
de frecuencia de la segunda bomba, es estudiar las propiedades o
características de cualquier fluido, mediante el uso de los sensores.
156
Figura 6.0.17 Vista Diagonal Planta FM51
6.2.1- Sensor Flujo
El sensor de flujo que contiene la planta es un sensor de flujo de
paletas modelo 8030, marca Bürket. Está compuesto por un módulo fitting
S030 y un módulo electrónico SE30. En el fitting se encuentran las paletas,
las cuales al pasar el flujo, se mueven haciendo girar un eje, cuya frecuencia
es proporcional a un valor de flujo, cumpliendo la siguiente fórmula:
f = K ⋅ Q (6.1)
f : es la frecuencia a la que gira el eje conectado a las paletas (Hz)
K : es una constante que depende del diámetro de la tubería (1/L)
Q: es el valor de flujo (L/s)
157
6.2.2-Sensor de presión 6CF6G
Figura 6.0.18 Especificaciones Técnicas del Sensor de Presión
158
Según datos obtenidos por el manual de la planta FM51 se encuentra
dos tipos de sensores de presión, uno de 0-30 psi y otro de 0-15 psi.
Esta planta contiene tres sensores de presión.
Sensor Bomba1: su rango es de (0-15) psi
Sensor Bomba2: su rango es de (0-30) psi
Sensor salida-Tanque: su rango es de (0-15) psi
6.2.3. El Sensor LM35.
El LM35 es un sensor de temperatura con una precisión calibrada de
1ºC y un rango que abarca desde -55º a +150ºC. Funciona en un rango de
alimentación comprendido entre 4 y 30 voltios.
El sensor se presenta en diferentes encapsulados pero el más común
es el to-92 de igual forma que un típico transistor con 3 patas, dos de ellas
para alimentarlo y la tercera nos entrega un valor de tensión proporcional a la
temperatura medida por el dispositivo. El LM35 se puede describir como se
observa en la figura 1, en donde, con las letras del encapsulado hacia arriba
tenemos que de izquierda a derecha los pines son: VCC - Vout - GND.
El sensor de temperatura de la planta FM51 es de tipo integrado, LM35,
explicado anteriormente.
159
6.2.4. Adaptación del Sistema HMI_UDO a la Planta Armifield Fm51.
En la tabla 6.4 y 6.5 se proporcionan un resumen de las
características que tiene la planta armfield fm51 y que tendrá el dispositivo
de adquisición en este caso arduino UNO.
Tabla 6.0.4 Característica de la Planta FM51
Planta FM51
Pruebas
Digitales 0
Analógicas 5
Digitales 1
PWM 1
Tabla 6.0.5 Características de Prueba Placa Arduino para FM51.
Arduino UNO
Entrada Digitales 0
Analógicas 5
Salida Digitales 1
PWM 1
Comunicación Serie
Al igual que la validación utilizando la plantaP1 los códigos modificados
para la adaptación del sistema a la planta armfield fm 51, se encuentra en los
apéndices 18-24. Los resultados de estas modificaciones se pueden
observar en las imágenes siguientes:
160
Figura 6.0.19 HMI DE LA PLANTA FM51.
Figura 6.0.20 Graficas Entradas Analógica Planta FM51
161
Figura 6.0.21 Interfaz para Control de Salidas
162
Figura 6.0.22 Base de Datos Planta FM51 (Sqlite Administrador)
163
Figura 6.23 Base de Datos Planta FM51 (Archivo Texto)
164
Conclusión
Se diseñó un sistema de adquisición, supervisión y control de bajo
costo basado en software y hardware libre.
las herramientas de desarrollo de hardware libre pingüino y arduino
facilitaron la comprobación de compatibilidad entre el lenguaje de
programación python y los puertos de comunicación serie y USB para
la supervisión de datos.
La estructura de firmware para la facilidad de realizar tareas de
comunicación USB desarrollado con el lenguaje c18 es compatible
con la familia de microcontroladores pic 18f
.
Se diseñó y codifico un algoritmo para el desarrollo de Interfaz
Hombre Maquina compatible con microcontroladores.
La utilización de este sistema en los procesos depende de la cantidad
de entradas y salidas que puedan soportar los dispositivos de
adquisición.
Se logró adaptar las características de los microcontroladores para ser
utilizados como dispositivos de adquisición de datos tomando en
cuenta el lenguaje de programación python.
La velocidad de transacción de datos entre el dispositivo de
adquisición y el software HMI_UDO dependen principalmente de la
potencia del ordenador donde se está ejecutado.
165
El sistema es multiplataforma debido a que su núcleo esta
programado con python y además las librerías utilizadas son
implementadas en diversos sistemas operativos. Dentro del alcance
de este proyecto solo se centró en las plataformas Linux y Windows.
Se determina después de la validación que el sistema garantiza un
buen desempeño, y se puede tomar en consideración cuando se
desee utilizar una alternativa basada en software y hardware libre a
pesar de la limitación en el número de entradas y salidas de este.
166
Recomendación y trabajos a futuro.
Desarrollar un script que facilite y reduzca el tiempo de elaboración de
HMI utilizando el criterio drag and drop (Arrastrar y soltar).
Migrar El software HMI_UDO y sus script a un lenguaje de
programación compilado o de más bajo nivel para aumentar la
velocidad de ejecución.
Crear scripts que permitan al sistema aumentar la compatibilidad con
otros protocolos de comunicación como por ejemplo modbus.
Añadir al firmware del microcontrolador la capacidad de comunicarse
con otros micrcontroladores a través de protocolo de comunicación i2c
logrando así aumentar número de entradas y salidas digitales y
analógicas; y aprovechar las características especiales de estos.
167
Bibliografía
Aquilo, P.(2007). Sistemas SCADAS. 2da Edición. Editorial: MACOMBO.
Skoog, D.(2001). Instrumentación Industrial. 5ta Edición España: Editorial
McGraw-Hill/interamericana
Díaz, H (2007). Instrumentación virtual industrial 2da Edicion. PERÚ Editorial:
MMVI.
González, G. (2007). Conexión al puerto USB mediante un microcontrolador,
Universidad de Salamanca, España.
González, R.(2006). Python para todos, Este libro se distribuye bajo una
licencia CreativeCommons Reconocimiento2.5 España.
Hoffman, P. (2006). Osciloscopio USB. Universidad ORT, Uruguay.
Rappin, N. (2006).wxPython IN ACTION, Manning Publications Co: Estados
Unidos.
Ríos, F. (2006). Diseño de una tarjeta programable de adquisición,
procesamiento de datos y control, Universidad de Salamanca, España.
Rodriguez, A (2007). Sistemas Scada. 2da Edicion. España Editorial:
Marcombo.
Tocci, W.(2003). Sistemas digitales Principios y aplicaciones. 8va Edición.
Editorial Prentice hall.
168
APENDICE
169
APÉNDICE. 1 GUÍA REFERENCIAL LENGUAJE ARDUINO.
170
171
APÉNDICE 2. GUÍA REFERENCIAL LENGUAJE ARDUINO.
PINGÜINO
172
APÉNDICE 3. GUÍA REFERENCIAL LENGUAJE PYTHON.
173
174
175
176
APÉNDICE 4. GUÍA REFERENCIAL WXPYTHON
}
177
178
179
180
APÉNDICE 5. GUÍA REFERENCIAL C18 COMPILER
181
182
183
184
185
186
187
188
189
190
APÉNDICE 6. SCRIPT PRINCIPAL HMI_UDO.PY
191
APÉNDICE 7. SCRIPT PARA CREAR BASE DE DATOS
192
APÉNDICE 8. SCRIPT Base_Datos.py (18F2550)
193
APÉNDICE 9. SCRIPT Proceso_Virtual.py (18F2550)
194
APÉNDICE 10. SCRIPT Obj_Comando.py (18F2550)
195
196
197
198
199
APÉNDICE 11. SCRIPT Graficar_Proceso.py (18F2550)
200
201
APÉNDICE 12. SCRIPT Mando_Proceso.py (18F2550)
202
APÉNDICE 13. SCRIPT Proceso_Virtual.py (18F4550)
203
APÉNDICE 14. SCRIPT Obj_Comando.py (18F4550)
204
205
206
207
208
209
APÉNDICE 15. SCRIPT Base_Datos.py (18F4550)
210
APÉNDICE 16. SCRIPT Graficar_Proceso.py (18F4550)
211
212
APÉNDICE 17. SCRIPT Mando_Proceso.py (18F4550)
213
APÉNDICE 18. SCRIPT Base_Datos.py (Fm51)
APÉNDICE 19. SCRIPT Serial_Conect.py (Fm51)
APÉNDICE 20. SCRIPT Proceso_Virtual.py (Fm51)
APÉNDICE 21. SCRIPT Obj_Comando.py (Fm51)
APÉNDICE 22. SCRIPT Graficar_Proceso.py (Fm51)
APÉNDICE 23. SCRIPT Graficar_Proceso.py (Fm51)
APÉNDICE 24. SCRIPT Mando_Proceso.py (Fm51)
214
ANEXOS
215
216
ANEXO A. Lista de Materiales para la construcción de tarjeta ADQ18f2550
217
ANEXO B. Lista de Materiales para la construcción de tarjeta ADQ18f4550
218
ANEXO C. Circuito Electrónico de la Tarjeta Adq Pic 18f4550.
219
ANEXO D. Circuito Electrónico de la Tarjeta Adq Pic 18f2550.