Sistema de adquisicion supervision y control de plantas de proceso

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:

_____________________ Ing. Danilo Navarro

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””

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:

_______________________ Ing. Verena Mercado Jurado Principal

_______________________ Ing. Luis Parraguez Jurado Principal

Barcelona, Febrero 2013

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”

iv

DEDICATORIA

v

AGRADECIMIENTOS

vi

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.

vii

Í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 HombreMaquina utilizando Software Libre. ........................................................ 21

viii

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 ix

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 x

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

xi

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

xii

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

xiii

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

xiv

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

xv

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

electrónico

un ordenador a través del protocolo USB. Donde el circuito 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ógicasDigital 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

Flash PWM

SRAM

EEPROM

Clock Speed

Interfaz USB

Memory UNO

ATmega328

14

6

6

32KB

2KB

1KB

Decimila

ATmega168

14

6

6

16KB

1KB

512 bytes

1KB/2K B

512bytes/1K B

Duemilanov e

ATmega168/328P

14

6

6

16KB/32K B

Mega

ATmega1280

54

16

14

128KB

8KB

4KB

Mega2560

ATmega2560

54

16

15

256KB

8KB

4KB

Nano

ATmega168/328

14

8

6

128KB

8KB

4KB

16 MHz 16 MHz 16 MHz 16 MHz 16 MHz 16 MHz

ATmega8U 2 FTDI FTDI FTDI ATmega8U 2 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, velocidad del más lento.

aunque funcionará la

34

Existen tres tipos de velocidades en la comunicación. Ellas son:

Tabla 2.0.2 Velocidades de transferencias USB

TIPO Baja velocidad (low speed)

VELOCIDAD 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 D3 Verde D+ 4 Tierra En corto con pin 4 en conector Mini5 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 0x00 0x01 0x03 0x07 0x08 0x09 0x0A 0x0E 0xE0 0xFF

Clase Reservado. Usado en el descriptor de dispositivo para indicar que la clase está identificada en él (o los) descriptores de interfaz. Dispositivo de audio. Por ejemplo; tarjetas de sonidos Dispositivo de interfaz humana (HID). Por ejemplo: mouses, teclados, joystick. Impresoras Dispositivo de almacenamiento masivo. Por ejemplo: discos duros, lectores de memoria, cámaras digitales, reproductores MP3. Hubs Dispositivo de comunicación (CDC por sus siglas en inglés). Por ejemplo: módems, tarjetas de red. Dispositivo de video. Por ejemplo: webcams Controladores inalámbricos. Por ejemplo: adaptadores Bluetooth. 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 Cursos

Búsqueda de información determinada en la base de datos. 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 NULL INTEGER REAL TEXT

Python None

int or long, depending on size float

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 Año

ACTIVO 2010

ACTIVO 2010

ACTIVO 2010

ACTIVO 2009

ACTIVO 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 Medida o inicio de variables

Letras Subsiguientes

Modificador

Lectura de Salida o Función Pasiva

A

Análisis

Alarma

B

Quemador, Combustión

Opción de usuario

C

Opción de usuario

Control

D

Opción de usuario

E

Voltaje

F

Flujo

G

Opción de usuario

H

Mano

I

Corriente Eléctrica

J

Potencia

Función de Salida

Modificador

Opción de usuario

Opción de usuario

Diferencial Sensor (Elemento Primario) Radio (Fracción) Vidrio, Dispositivo de Visualización Alto Indicador 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 Lectura de Salida o Función Pasiva

Función de Salida

Medida o inicio de variables

Modificador

M

Opción de usuario

Momentáneo

N

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

R

Radiación

S

Velocidad, Frecuencia

T

Temperatura

U

Multivariable

V

Vibración, Análisis Mecánico

W

Peso, Fuerza

X

No Clasificado

Eje X

Y

Evento, Estado o Presencia

Eje Y

Relé, Conversor, calculo

Z

Posición, Dimensión

Eje Z

Actuador, Elemento final de Control no clasificado

Modificador

Medio, Intermedio Opción de usuario

Opción de usuario

Integrado, Totalizador Registro Seguridad

Conmutador Transmisión Multifunción

Multifunción

Multifunción

Válvula, Amortiguador Pozo No Clasificado

No Clasificado

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

Negro

Fondo

Elemento Asociado a)Parada

Rojo

Emergencia

b)Alarma de alta prioridad c)Cerrado d)Apagado(Off)

Amarillo

Alerta

a) Condición fuera de lo normal. b) Alarma de prioridad media. a) Operación Normal

Verde

Seguro

b) Inicio c) Abierto

Celeste

Azul

Morado

Estático y significante

No es esencial

Radiación

a) Equipo de Proceso en servicio b) Etiquetas Principales a) Equipo de Proceso en espera b) Tags, etiquetas, etc. a) Alarmas de Radiación b) Valores Cuestionables a) Medidas e informaciones de estado

Blanco

Datos Dinámicos

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 transmisorreceptor 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

Figura 3.0.2 Diagrama de bloques del FT232

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.

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; i0) { 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

a)

b)

c)

Figura 4.0.3 Estructura del directorio Firmware Framework Usb a) HID b)CDC c)GEN

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 Digitales

Entrada

Analógicas

Salida

6 13

Digitales

8

PWM

2

Crystal

4Mhz

Comunicación

USB

//------------------------------Includes---------------------------------------#include "USB/usb.h #include "HardwareProfile.h" #include "USB/usb_function_generic.h" #include #include #include #include #include #include //---------------------------------Fuses---------------------------------------#pragma config PLLDIV = 1 #pragma config CPUDIV = OSC1_PLL2 #pragma config USBDIV = 2 #pragma config FOSC #pragma config FCMEN #pragma config IESO

= HSPLL_HS = OFF = OFF

#pragma config PWRT

= OFF

#pragma config BOR

= ON

90

#pragma config BORV

=3

#pragma config VREGEN = ON #pragma config WDT

//USB Voltage Regulator

= 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(__18F2453)

defined(__18F2458)

||

||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;

||

defined(__18F4558)

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