Академический Документы
Профессиональный Документы
Культура Документы
FACULTAD TECNOLÓGICA
Presentado por:
Andrés Camilo Torrez Martínez
Jonathan Fernando Amaya Benavides
1. Contenido
Anexos……………………………………………………………………………………………………………………………….62
1
Hoja De Aceptación
Observaciones
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
____________________________
Ing. Eduardo Alberto Delgadillo
____________________________
Firma Jurado 1
____________________________
Firma Jurado 2
Bogota D.C.
2
Agradecimientos
Los autores expresan sus agradecimientos a todos nuestros familiares y amigos que
sirvieron como apoyo durante nuestro desarrollo profesional hasta este punto.
Al profesor Eduardo Alberto Delgadillo por sus conocimientos durante el desarrollo de
la carrera y del proyecto en cuestión.
A Variadores S.A. por permitirnos usar los recursos con los que se realizaron pruebas de
laboratorio.
A todos los docentes que a lo largo de la carrera brindaron su conocimiento y apoyo con
los que se logró dar desarrollo a este proyecto, y con los que se creció cada día de
manera profesional y personal.
A los compañeros y amigos que estuvieron durante estos años brindando su compañía
y su apoyo en cada una de las etapas que se llevaron a cabo en la Universidad.
3
2. Resumen
4
3. Objetivos
3.1 Generales.
Desarrollar un sistema lógico de control para ascensores, el cual almacene y permita un
monitoreo de variables del consumo energético principalmente voltaje y corriente en la
nube y haciendo uso de Machine Learning analizar el comportamiento de las mismas.
3.2 Específicos.
5
4. Marcó Teórico
- Bus DC: Consta de un conjunto de condensadores los cuales cumplen con dos
funciones dentro del variador, por un lado, suaviza el voltaje resultante de la
etapa de rectificación eliminando el rizado restante y por otro se encarga de dar
la energía necesaria para la salida del equipo. Con la implementación de esta
etapa se obtiene una señal DC más limpia que mejora el trabajo del variador en
sí.
6
Fig. 2 Etapa de bus DC en el variador de frecuencia [1]
- Etapa Inversora: Esta etapa está compuesta por una serie de módulos IGBT los
cuales toman el voltaje DC almacenado en los condensadores y aplicando una
modulación PWM construyen una señal que se asemeja a una AC en sus valores
de voltaje en el tiempo. La principal ventaja de manejar el voltaje en el motor
por este medio es la posibilidad de tener un mejor control sobre el torque y el
comportamiento del voltaje en los diferentes valores de frecuencia.
En la imagen siguiente se puede observar como es la salida real del variador teniendo
en cuenta que es una serie de pulsos de voltajes DC que en promedio forman una señal
con similitud a una AC.
Los variadores con el tiempo han ganado confiabilidad gracias a los beneficios que
tienen frente a otros tipos de arranque como el directo, o los arrancadores suaves.
Principalmente al momento de romper inercia en donde las corrientes pueden elevarse
a valores mucho más altos de los nominales de trabajo, es donde se ven los beneficios
de sistemas de arranques con variador ya que permiten tener un control sobre el
funcionamiento que suaviza el trabajo. Las protecciones con las que cuenta cada equipo
7
permiten que la vida útil tanto del mismo como del motor sean mayores en comparación
con un funcionamiento no controlado.
Para este proyecto en específico se implementó un Variador marca Yaskawa, esta es una
compañía que se ha enfocado en la comercialización de equipos para el control de
movimiento desde el año 1915, tiene presencia alrededor de todo el mundo.
En el rango de productos con los que cuenta la empresa se encuentran variadores
especializados en ciertas aplicaciones comunes como lo son el modelo A1000 para uso
general, IQPump 1000 para sistemas de bombeo, Z1000 para sistemas de aire y el usado
en este proyecto L1000E para el control de máquinas en ascensores. También existe el
modelo L1000A el cual tiene varias similitudes con el mencionado anteriormente, pero
este se usa en la región de Norte América.
El modelo L1000E presenta ciertas configuraciones que para el caso específico de los
ascensores se hacen necesarias y facilitan su implementación, como lo son el manejo
del freno, parámetros de nivelación y confort que permiten configurar el sistema para
que trabaje dentro de los mejores estándares.
El variador L1000E cuenta con las siguientes características que permiten un control y
monitoreo sobre el mismo implementando varios protocolos de comunicación, o
contactos secos de marcha y parada:
- 8 entradas digitales multi-función
- 2 entradas análogas multi-función
- 3 salidas digitales relevadas multi función
- 2 salidas digitales optoacopladas multi función
8
- 1 rele de fallas
- 2 entradas de seguridad
- Comunicación integrada Modbus RTU RS-422, RS-485
Un sistema de ascensor está compuesto por una serie de componentes tanto mecánicos
como eléctricos, la parte mecánica la cual consta principalmente de una polea acoplada
al eje del motor, la cabina y el contrapeso como se observa en la siguiente imagen.
9
es el que facilita el trabajo del motor cuando debe levantar la carga del ascensor, este
debe ser calculado de acuerdo a la carga máxima que soporta el sistema para que el
motor trabaje con los mismos valores tanto en subida como en bajada.
Otro componente importante que cuenta tanto en la parte mecánica como eléctrica es
el motor, este es el que específicamente se encarga de convertir la energía eléctrica en
mecánica para generar el movimiento del ascensor. Para el manejo de ascensores
actualmente se suelen utilizar dos tipos de motores los cuales serán explicados
brevemente:
- Motor De Inducción
EL motor de inducción es uno de los más usados actualmente en diferentes aplicaciones,
este se encuentra compuesto por 3 partes principales que son el rotor, el estator y la
carcasa. Tanto el rotor como el estator están conectados a unos bobinados que son los
encargados de transformar la energía eléctrica en mecánica. Cuando se aplica una
corriente sobre el bobinado del estator se genera un campo electromagnético que
induce una corriente sobre el bobinado del rotor, de esta manera es que estos campos
son los que llevan al motor a que tenga un movimiento.
- Maquina Gearless
Estas máquinas son motores que cuentan con unos imanes coloques en posiciones
predefinidas para su funcionamiento, las ventajas que presenta principalmente son que
la relación entre el consumo de corriente y la potencia generada es mejor que en un
motor de inducción por lo que el tamaño de los mismos también se ve disminuido al
hablar de potencias de valores similares.
10
Fig. 7 Maquina Gearless. [6]
Debido a que la carga que mueve un sistema de ascensores es tan crítica como lo es la
vida de las personas, es necesario contar con una serie de seguridades que eviten se
llegue a presentar algún accidente. Por ejemplo, casos de incendio, terremoto, excesos
de velocidad y otros que llevan al ascensor a presentar algún inconveniente en su
funcionamiento.
También se suele hacer uso de algún equipo de frenado junto con el variador, esto
debido a que se presenta el fenómeno de regeneración constantemente en los sistemas.
La regeneración consiste en el momento en que el motor debe cambiar de estado en
tiempos muy cortos por lo que su construcción lo lleva a trabajar como un generador y
entregar energía al variador, usualmente se instala una resistencia de frenado la cual se
encarga de disipar esta energía sobrante en forma de calor.
4.3. Codesys
11
Soporta los cinco lenguajes de programación del estándar los cuales son; lenguaje en
escalera (Ladder Diagram LD), Diagrama de bloques funcionales (Function Block Diagram
FBD), Texto estructurado (Structured Text ST), Bloque de función secuenciales
(Sequential Function Chart SFC) y Bloque de funciones continuas (Continuous function
Chart CFC), además dispone de visualización integrada, como también de un simulador
online. [11]
4.3.1. Lenguajes de programación.
Un programa escrito en Ladder está compuesto de una serie de circuitos que son
ejecutados secuencialmente por un autómata. La representación gráfica se asemeja a la
de un esquema eléctrico de control clásico, ya que se emplean símbolos similares a los
utilizados en estos esquemas, siendo mucho más intuitivos para los profesionales
familiarizados con este tipo de instalaciones que el uso de lenguajes de formato texto.
[12]
Dada su sencillez, es el lenguaje más utilizado en los relés programables y autómatas.
Entre los símbolos básicos podemos hacer mención de los mostrados en la siguiente
tabla 1.
12
En la siguiente figura 7, podremos observar la manera de programación del lenguaje
FBD.
13
Sequential Function Chart: Podríamos considerarlo un lenguaje orientado a gráficos que
nos permiten representar el desarrollo en el tiempo de las distintas acciones de un
programa. El SFC es similar a un diagrama de flujo, en el que podemos organizar
subprogramas o subrutinas programadas en ST, LD, FBD, IL y que forman parte del
programa de control. El lenguaje SFC se emplea frecuentemente en el diseño de
soluciones asociadas a sistemas secuenciales donde el programa se ejecuta paso a paso
conforme se cumplen determinadas condiciones. [12]
La programación SFC dispone de tres elementos principales encargados de organizar el
programa de control: pasos o etapas, transiciones o condiciones y acciones. Nuestro
programa se irá ejecutando de una etapa a otra conforme se vayan cumpliendo las
condiciones y en cada etapa se ejecutará las acciones que se hayan definido. [12]
En la figura 9 observaremos un ejemplo básico de la programación del lenguaje SFC.
14
Fig. 11 Ejemplo básico del lenguaje CFC.
15
Para poder direccionar correctamente el dato que se quiere transmitir, a cada valor se
le asigna una dirección, de acuerdo a lo establecido por el protocolo dependiendo de si
es una entrada, una salida y si es un valor digital o análogo se le asigna una dirección
dentro de un rango. En la siguiente tabla se observa la asignación de las direcciones de
acuerdo al tipo de dato que se desea trabajar.
Fig. 13 Direcciones establecidas para cada tipo de dato en el protocolo Modbus [7]
Cuando el bus no está siendo usado las dos líneas están a nivel alto y cualquier maestro
puede acceder al bus poniendo a nivel bajo la línea SDA, luego podrá la dirección del
receptor y, finalmente, se establecerá un dialogo que terminará con la vuelta de la línea
16
SDA a nivel alto. [14] En términos generales, una transacción obedecerá a alguna de las
siguientes estructuras de la figura 14: [15]
Fig. 15 Formatos de una transacción: a) sin cambio de sentido, b) con re-direccionamiento y posible
cambio de sentido. [15]
MQTT es un protocolo de red liviano y flexible que logra el equilibrio adecuado para los
desarrolladores de IoT: [16]
17
El cliente se conecta con el intermediario. Se puede suscribir a cualquier “tema” de
mensajes de intermediario. Esta conexión puede ser una conexión TCP/IP simple o una
conexión TLS cifrada para mensajes confidenciales.
El cliente publica el mensaje, sobre un tema, enviando el mensaje y el tema al
intermediario.
Después, el intermediario redirige el mensaje a todos los clientes que están suscritos a
ese tema.
El software que es usado en esta tarjeta es Open Source, el cual su sistema operativo es
adaptado de Debian, denominada Raspbian, aunque también la placa puede trabajar
bajo otros sistemas operativos, incluyendo la versión 10 de Windows. A continuación,
en la figura 16, observaremos las partes que componen la mayoría de las versiones de
Raspberry.
18
Fig. 17. Placa Raspberry Pi Modelo 3. [17]
A) Procesador.
En las versiones principales de Raspberry Pi, encontramos 4 puertos USB 2.0 para
conectar periféricos tales como el teclado, el ratón, controladores e impresoras.
Mientras más dispositivos se alimenten de los puertos, es recomendable considerar el
uso de una fuente externa alimentando a los dispositivos que necesiten más energía,
como un disco duro. [17]
E) Puerto Ethernet.
19
F) Conector HDMI.
El puerto HDMI brinda salida de audio y video digital. Soporta 14 diferentes resoluciones
de video, y la señal HDMI puede ser convertida a DVI (usado por muchos monitores),
compuesta (Señal análoga de video con un conector RCA amarillo), o SCART (un
equipamiento de estándar europeo para conexión audiovisual) con adaptadores
externos. [17]
G) Alimentación de entrada.
Notaras que la Raspberry Pi no tiene disco duro, todo es almacenado en una memoria
MicroSD. En los modelos recientes, deberás insertar la memoria oprimiéndola en el Slot,
y de la misma manera la podrás remover. En esta memoria deberás ingresar primero el
sistema operativo para luego hacer uso de la Raspberry Pi. [17]
I) Conector para la interfaz del display serial DSI
El conector acepta 15 pines, cable de cinta plana puede ser usado para la comunicación
con un Display Touch oficial de la Raspberry Pi. [17]
J) Entradas y salidas GPIO y otros pines.
Actualmente la Raspberry Pi tiene un conector que tiene 2x20 pines GPIO. Estos pines
pueden leer interruptores y botones, como también controlar actuadores, Leds, relés y
motores. [17]
K) Conector para la interfaz de la cámara serial CSI
Este puerto permite un módulo cámara que se conectará directamente con la tarjeta
por medio del cable cinta. [17]
4.8. PSoC (Programmable System On Chip)
Es la denominación que tienen los microcontroladores programables desarrollados por
Cypress Semiconductor. Esta tecnología constituye un arreglo configurable de señal
mezclada (Parte análoga y digital) con controlador para una tarjeta. Estos dispositivos
conjugan las ventajas de los SoC, con la flexibilidad de los sistemas programables. [18]
20
Los bloques análogos están compuestos de capacitadores conmutados, Op-amp,
comparadores, ADC, DAC, y bloque de filtros digitales, permitiendo flujos complejos de
señales análogas. [18]
PSoC además ofrece un subsistema CPU sostificado con SRAM, EEPROM, una memoria
flash, varios núcleos y una variedad de sistemas incluyendo: [18]
- Un oscilador interno principal de baja velocidad.
- Conectividad con un oscilador cristal externo para precisión.
- Interrupciones internas y Watchdog.
- Múltiples relojes que incluyen un PLL.
Los dispositivos PSoC también están dedicados a comunicaciones tales como I2C, USB
2.0, CAN 2.0 y capacidades de depuración en el Chip usando JTAG y Serial Wire Debug.
Los nuevos PSoC estas construidos bajo un estándar de procesadores como los 8051,
ISSP y ARM Cortex M3. [18]
22
5. Desarrollo
El desarrollo llevado a cabo se puede dividir en una serie de etapas la cual en donde
cada una se compone de sus propios elementos tanto de Hardware como de Software.
Para explicar el procedimiento realizado se explicará la composición de cada uno de los
bloques y así mismo como fue el proceso de construcción.
Antes de iniciar con la explicación de cada uno de los bloques, se hace necesario aclarar
algunos conceptos:
- Llamadas de carro: Las llamadas de carro son aquellas que se realizan desde el
interior de la cabina del ascensor, estas le indican al sistema cual es el destino
del pasajero para que se decida cuál es la mejor ruta a seguir.
- Llamadas de piso: Estas llamadas son las que se realizan desde el panel presente
en cada uno de los pisos donde trabaje el ascensor, en el caso de este sistema se
cuenta con la posibilidad de solicitar el equipo para bajada y subida de manera
separada.
23
Fig. 19 Diagrama de conexiones comunicación Modbus, Variador Yaskawa. [8]
24
La configuración del variador se realiza por medio del operador digital del mismo el cual
es la interfaz que permite interactuar con los parámetros de configuración del mismo.
En el caso del variador Yaskawa los parámetros de configuración se encuentran
agrupados como lo muestra la siguiente tabla, en esta se puede ver que los parámetros
se encuentran agrupados de acuerdo a la función que cumplen, lo que permite que sea
más sencillo realizar su configuración. Se pueden encontrar parámetros para el control
de velocidad de aceleración y desaceleración, valores del motor, protecciones entre
otros. Los que en este caso se necesitan principalmente son los relacionados con el
grupo H5, los cuales son los encargados de configurar la comunicación por medio del
protocolo MODBUS.
Fig.
20
H5-01: Establece la dirección de esclavo que va a tener cada uno de los variadores, en
este caso debe coincidir con la que es buscada por parte del control o Raspberry.
H5-03: Este parametro permite seleccionar el tipo de paridad con el que va a trabajar el
sistema por predeterminado viene sin paridad.
25
Por el lado de codesys y la raspberry se añade un dispositivo de tipo Modbus como se
observa en la imagen, las configuraciones del mismo deben corresponder a las
realizadas en el variador, en codesys es posible determinar si la comunicación se esta
realizando de manera correcta si al momento de iniciar el programa se observa un icono
de color verde al lado de los dispositivos añadidos.
26
Los que nos interesan principalmente son los correspondientes a la referencia de
velocidad y a los comandos de marcha, como se observa en lo descrito por el manual en
la dirección 1 se escribe el valor que permite dar marcha al equipo tanto en el sentido
superior como en el inferior, y en la dirección 2 se puede ingresar la referencia de
velocidad con la cual trabajara el equipo, la modificación de este parámetro es la que
permite realizar el cambio a velocidad intermedia antes de parar en el piso
correspondiente.
Para realizar la lectura de los monitores del equipo se utiliza la función con código 3 que
permite realizar la lectura de un registro del mapa Modbus, como en la escritura de
parámetros, en el manual se encuentran todas las direcciones correspondientes a los
valores de lectura.
27
con esto es posible llamar cualquiera de los datos que mide el variador, tanto de
corriente como potencia, etc.
28
Fig. 26 Entorno de desarrollo Codesys. Fuente Autor
Codesys permite implementar una interfaz visual tipo HDMI que permite controlar el
sistema, para poder llevar a cabo pruebas y como un sistema de manejo opcional se
realiza el desarrollo de una pantalla que permita realizar las solicitudes de llamados y
observar el estado del funcionamiento la cual se puede observar en la siguiente imagen,
con esta se puede simular todo un ciclo de trabajo con lo que es posible rectificar fallos
en la lógica o así mismo realizar un proceso de rescate o similar.
29
Fig. 28 Panel para llamadas de carro. Fuente Autor
Como se observa a continuación cada una de las variables asignadas a los botones se
encargan de cambiar a verdadero la posición de un vector que almacena los
correspondientes llamados a piso, de esta manera a pesar de ser una señal no enclavada
permite que se maneje el llamado como un espacio de memoria que será consultado al
momento de realizar los viajes. Esta lógica se encuentra escrita en lenguaje Ladder
dentro del software Codesys.
Fig. 29 Código en ladder para detectar los llamados de carro. Fuente Autor
30
Fig. 30. Bloque de comunicación I2C
31
Fig. 32 Pines de entrada.
Del código que podemos ver en la figura 33 observamos unas variables creadas para la
comunicación I2C, estas variables se encargan de guardar la información que será
envidad o recibida por el protocolo I2C, además también encontramos una variable
‘status’ la cual indica la solicitud que es recibida por el dispositivo Maestro. También en
el inicio del código se tiene una variable llamada ‘piso’, la cual guardara el piso en el que
se encuentra el ascensor. Posteriormente encontramos unas instrucciones para
inicializar los bloques implementados anteriormente y además unos parámetros
iniciales necesarios para el protocolo I2C. En la figura 34 encontraremos la continuación
del código.
32
Fig. 34 Segunda visualización del código de la cabina.
La figura 34 nos muestra el comienzo del bucle infinito del código donde se ejecutará la
parte principal del programa. Para realizar el envío de datos por I2C se crea un
condicional que es usado para preguntar por una solicitud de lectura enviado por el
dispositivo maestro, al cumplir dicha condición se procede a limpiar el buffer de lectura
y posteriormente asignar a las variables que serán enviadas el estado de los pines de
entradas creados con el fin de indicar el piso de destino del ascensor, como también
algunos botones necesarios dentro de la cabina. Por último, en la figura 35 podemos ver
la parte final del código implementado.
De la misma manera que se envían los datos por I2C, para recibir los datos enviados por
el dispositivo maestro se crea un condicional que pregunta por la solicitud escritura o
como se puede apreciar es una rutina para recibir datos. Como se realizó anteriormente,
se limpia el buffer de escritura y luego se procede a recorrer el vector donde queda
guardado los datos recibidos, y así poder asignar a la variable ‘piso’ la posición del piso
33
donde se encuentra el ascensor, con el fin de usar esta información y con la última
instrucción poder visualizarlo con el Display 7 segmentos. En el anexo podremos
apreciar el código completo el cual se ejecutará en la PSoC encargada de las llamadas
desde la cabina o carro, como también el plano del circuito PCB desarrollado. A
continuación, en la figura 36 se puede observar el circuito PCB ya con los componentes
montados.
Fig. 36 Circuito PCB con sus componentes encargado de llamadas desde la cabina.
Desde la interfaz, las llamadas de piso pueden ser simuladas por medio de los paneles
que se observan en la siguiente imagen, cada uno de estos consta de un botón
correspondiente al llamado de subida y de baja dependiendo del piso, además de un
panel indicando cual es el piso actual en el que se encuentra el ascensor.
De igual manera que con los llamados de carro, cada uno de los botones cambia a
verdadero el valor de una variable booleana que se encuentra en un vector, debido a
que el sistema diferencia los llamados de subida y de bajada, cada uno de estos cuenta
con un vector diferente para almacenar sus respectivos llamados.
34
Fig. 38 Programa en ladder para detectar las llamadas de piso. Fuente Autor
Cabe mencionar que el código de programación para hacer el llamado del ascensor e
indicar hacia donde se dirige, es muy similar al código anteriormente visto, así que se
mostrará los pocos cambios realizados. A continuación, podemos observar en la figura
38 algunos cambios en asignación y nombre de los pines de entradas.
Fig. 39 Esquema de la programación para el llamado del ascensor desde los pisos.
Para comenzar el PSoC 4 esclavo se configura con la dirección 0x08 = 0001000. Luego
podemos observar que los pines de entrada están asignados de tal manera que indican
la acción que debe realizar ascensor para dirigirse al piso de destino. Y encontramos
además un led que funciona igual que el programa anterior, solo se usa con el fin de
observar si la comunicación está funcionando.
Al terminar el esquema de la programación, procedemos a realizar la lógica de
programación en C de este programa, el cuál no varía mucho. Por lo tanto,
observaremos el cambio realizado para el llamado del ascensor en la figura 39.
35
Fig. 40 Rutina para envío de datos por I2C.
Como ya habíamos analizado anteriormente, el envío de datos por I2C se realiza usando
un condicional, pero el cambio realizado se encuentra en que las variables asignadas
indican en esta ocasión la acción y el destino que debe realizar el ascensor. En el anexo
podremos observar el código completo para el PSoC encargado del llamado del ascensor
desde cada piso, como su esquema y a su vez el circuito PCB desarrollado. A
continuación, podemos apreciar en la figura 40 (a) el circuito con sus componentes
donde se encuentra el PSoC y en la figura 40 (b) el circuito PCB el cual irá en cada uno
de los 5 pisos para el llamado del ascensor.
Fig. 41 (a) (arriba) Circuito PCB donde se el PSoC, (b) (abajo) Circuito PCB el cual se reparte en cada uno
de los 5 pisos.
36
- Programación de la comunicación I2C para la Raspberry Pi en Codesys.
Posteriormente de haber realizado los programas de las tarjetas que hacen los llamados
del ascensor e indican el destino del piso que se desea, se procede a mostrar el
desarrollo hecho por la Raspberry Pi (Maestro) para la comunicación I2C usando el
entorno del software CODESYS. Para comenzar, se agrega un dispositivo maestro I2C al
proyecto, cabe resaltar que para que realmente funcione la comunicación I2C se debe
habilitar esta opción por el terminal de Raspbian o por el escritorio. A continuación,
podemos observar en la figura 40 las variables creadas para enviar o recibir la
información de los PSoC esclavos.
Luego de crear las variables para la comunicación I2C procedemos a realizar la lógica
para recibir los datos envidas por los esclavos y asignarlos a variables que usaremos para
el sistema de control del ascensor. La lógica de programación de este proceso se realiza
en el lenguaje de texto estructurado, como podemos ver en la figura 41.
37
5.2.3. Sistema de sensores para pisos
Para poder detectar la llegada a cada uno de los pisos se utilizan las señales de unos
sensores que se encuentran en uno de los costados de la cabina, a continuación, se
procederá a explicar el funcionamiento de la detección de los pisos. Como se puede
observar la cabina cuenta con dos sensores, que en la mayoría de los casos son activados
por medio de imanes, uno ubicado encima del otro que están conectados directamente
como señal a la tarjeta de control, en la imagen se puede observar la ubicación
aproximada de los mismos, lo importante en este caso es que se encuentren a distancias
iguales de cada uno de los extremos para que la ubicación de parada no varíe entre
subida y bajada.
Sensor Superior
Cabina
Sensor Inferior
Cada uno de estos sensores detectara una señal correspondiente a los activadores del
piso, en el caso de ser imanes estos se encontrarán ubicados dentro del trayecto del
ascensor en una de las paredes de manera que cuando la cabina pase por su ubicación
estos sean detectados. De la misma manera que es importante la ubicación de los
sensores de cabina, los que se encuentran en las paredes del trayecto también deben
ser colocados de manera correcta para que el sistema no presente problemas de
nivelación.
Cabina
Sensores de piso
38
Si el ascensor va de bajada está a la espera de que el sensor inferior de la cabina detecte
un imán, esto le indica que se acerca al piso siguiente y en caso de ser necesario parar,
hace el cambio a una velocidad intermedia para que la parada no sea tan brusca, al
momento de detectar el imán superior una señal le indica que esta en el punto de
nivelación por lo que envía la señal de parada y espera a una próxima indicación. En caso
de que se encuentre el ascensor en subida el funcionamiento es el mismo pero el orden
de detección de los sensores se invierte.
En la interfaz de prueba los sensores superior e inferior son los que se observan en la
siguiente imagen, donde cada botón simula los sensores superior e inferior
respectivamente. Con esto es posible enviar ordenes de parada y de nivelación al
variador.
Los sensores también son configurados como entradas externas al control que permiten
que sean conectados cualquier tipo de sensor que se quiera utilizar.
5.2.4. Lógica del ascensor
El código principal del programa está escrito en Ladder como se observa en la figura, se
encarga de realizar la activación y desactivación de acciones que se encuentran como
subprogramas, donde cada una de estas se encarga de los posibles estados del ascensor,
siendo estos subida, bajada y quieto. Además de activar el estado de emergencia en
caso de que alguna de las seguridades sea activada o se evidencie algún problema de
funcionamiento.
39
Fig. 47 Programa de control principal. Fuente Autor
- Principal
El código que se encuentra en el programa principal se encarga de establecer cuál es la
siguiente acción a realizar por el ascensor, el mismo se activa cada vez que se cierra la
puerta después de un llamado y no tenía ninguna llamada previa en el mismo sentido
en el que se estaba realizando el viaje anterior. Este código se ejecuta constantemente
mientras no se tenga ningún llamado para que en el caso de presentarse alguno se
reaccione inmediatamente.
La línea 1 se encarga de colocar la referencia de velocidad nominal con la que debe
trabajar el variador al momento de iniciar algún viaje, después de esto el programa
ejecuta un ciclo alrededor de los posibles llamados que tenga el sistema en alguno de
los pisos con los que cuenta lo que se observa en la línea 2, en caso de encontrar un
llamado analiza cual es el sentido del viaje desde la línea 6 para que entre a trabajar otro
de los programas encargados de las funciones de subida o bajada.
1. G.Referencia_W := 6000;
2. FOR G.counter:=1 TO 5 BY 1 DO
3. //Si el llamado esta hecho
4. IF G.SP[G.Counter] OR G.LPD[G.Counter] OR
G.lpU[G.Counter] THEN
5. //Pregunta para subir o bajar
6. IF G.Piso < G.Counter THEN
7. G.LSubida := TRUE;
8. G.LPrin := FALSE;
9. ELSIF G.Piso > G.Counter THEN
10. G.LBajada :=TRUE;
11. G.LPrin := FALSE;
12. ELSE
13. G.Lpuertas := TRUE;
14. G.LPrin := FALSE;
15. G.SP[G.Piso] := FALSE;
16. G.LPU[G.Piso] := FALSE;
17. G.LPD[G.Piso] := FALSE;
18. END_IF
19. END_IF
20. END_FOR
40
El código encargado de la subida y de la bajada trabajan de manera similar, la línea 1
activa un booleano que sirve para la lógica interna del sistema, en la línea 2 se cambia
la variable de comandos del variador, la cual al tomar el valor de 2 para activar el bit 1
de la trama Modbus y así el Variador ande en uno de los sentidos de marcha. La línea 3
también funciona como una lógica interna para que el sistema sepa cuál es el último
estado de movimiento del ascensor.
1. G.On2 := TRUE;
2. G.Comandos := 2;
3. G.Subiendo := TRUE;
En caso de que no hubiera llamado de piso se espera a que se detecte el sensor superior
con lo que se dará por dicho que este piso ya fue pasado y la bandera volver a tomar el
valor de 0.
1. IF Bandera = 1 THEN
2. IF G.ISuperior THEN
3. Bandera := 0;
4. END_IF
5. END_IF
41
1. IF Bandera = 2 THEN
2. IF G.ISuperior THEN
3. //Mantiene media hasta que llegue el inferior
4. G.On2 := FALSE;
5. G.Comandos := 0;
6. G.Lpuertas := TRUE;
7. ////Si no hay mas llamados de subida de ahi para arriba
apagar subida
8. IF G.Piso = 5 THEN
9. G.Subiendo := FALSE;
10. ELSE
11. FOR G.counter_b:= G.Piso + 1 TO 5 BY 1 DO
12. IF G.SP[G.Counter_b] OR G.LPU[G.Counter_b] THEN
13. G.Subiendo := TRUE;
14. Bandera := 0;
15.
16. G.SP[G.Piso] := FALSE;
17. G.LPU[G.Piso] := FALSE;
18.
19. G.LSubida := FALSE;
20.
21. RETURN;
22. ELSE
23. G.Subiendo := FALSE;
24. END_IF
25. END_FOR
26. END_IF
27.
28. //Resetear Piso Al LLegar
29. G.SP[G.Piso] := FALSE;
30. G.LPU[G.Piso] := FALSE;
31.
32. G.LSubida := FALSE;
33.
34. Bandera := 0;
35. END_IF
36. END_IF
37.
El código de bajada cumple con el mismo funcionamiento que subida solo teniendo en
cuenta los llamados en otro sentido y el orden de los imanes en sentido inverso.
42
18. G.LPD[G.Piso] := FALSE;
19.
20. G.LBajada := FALSE;
21.
22. RETURN;
23. ELSE
24. G.Bajando := FALSE;
25. END_IF
26. END_FOR
27. END_IF
28.
29. //Resetear Piso Al LLegar
30. G.SP[G.Piso] := FALSE;
31. G.LPD[G.Piso] := FALSE;
32.
33. G.LBajada := FALSE;
34.
35. Bandera := 0;
36. END_IF
37. END_IF
38.
39. //Esta esperando Superior
40. IF G.ISuperior AND Bandera = 0 THEN
41. //Numero menos de piso y si esta solicitado parar
42. G.Piso := G.Piso - 1;
43. //Si esta solicitado bajar a media y esperar segundo iman
44. IF G.SP[G.Piso] OR G.LPD[G.Piso] OR G.LPU[G.Piso] THEN
45. Bandera := 2;
46. G.Referencia_W := 3000;
47. ELSE
48. Bandera := 1;
49. END_IF
50. END_IF
1. IF bandera_p THEN
2. G.Apuertas := TRUE;
3.
4. G.Delay(IN:=TRUE, PT:=T#3S);
5. IF NOT(G.Delay.Q) THEN
6. RETURN;
7. END_IF
8.
9. G.Delay(IN:=FALSE);
10. END_IF
11.
12. //Escribir Logica De puertas
13. //Esperar tiempo y no cerrar si esta activo sensor
14. //Cuando puertas termina activa principal
15.
43
16. bandera_p := FALSE;
17. IF G.puerta_obs THEN
18. G.Apuertas := TRUE;
19. ELSE
20. G.Apuertas := FALSE;
21. IF G.Puerta_Cerrada THEN
22. G.Lpuertas := FALSE;
23. Bandera_p := True;
24. IF G.Bajando THEN
25. G.LBajada := TRUE;
26. ELSIF G.Subiendo THEN
27. G.LSubida := TRUE;
28. ELSE
29. G.LPrin := TRUE;
30. END_IF
31. END_IF
32. END_IF
En el caso de activarse una emergencia se enviará una orden de bloqueo al variador, con
esta el mismo no recibe comandos de marcha de ningún tipo hasta que la señal sea
levantada por lo que se mantendrá en el punto en el que se presentó el inconveniente.
Luego de detectarse la alarma iniciará un conteo por un tiempo determinado después
del cual se dará inicio a un viaje el cual llevará la cabina al primer piso para en este abrir
las puertas y evitar cualquier problema de seguridad.
1. //Apagar todo
2. G.On1 := FALSE;
3. G.On2 := FALSE;
4. G.Comandos := 64;
5.
6. G.Delay(IN:=TRUE, PT:=T#20S);
7. IF NOT(G.Delay.Q) THEN
8. RETURN;
9. END_IF
10.
11. G.Delay(IN:=FALSE);
12.
13. IF NOT g.IEInferior THEN
44
14. G.On1 := TRUE;
15. ELSE
16. G.On1 := FALSE;
17. END_IF
18.
45
algún tipo de inconveniente con que no se detectaron bien los sensores de los
pisos.
- Piso inicial: en el caso de que el sistema sea encendido por primera vez se utilizan
dos sensores extremos para enviar el ascensor a un punto conocido y posterior
a eso iniciar su funcionamiento normal.
- Sensores De Extremos de trayecto: son un par de sensores que se encuentran en
los puntos más extremos del trayecto, su función es impedir que el ascensor por
razones de mal funcionamiento suba demasiado o baje demasiado, esto lo
consigue activando el estado de emergencia del equipo.
Fig. 50 Arriba grafica de referencias de frecuencia al momento del arranque, abajo grafica de
referencias de frecuencia al momento de nivelar.
El voltaje del bus DC permite saber dos cosas, por un lado, si este tiene un valor muy
bajo quiere decir que la alimentación de este no se encuentra en los valores en los que
debería estar lo que fuerza al variador para que entregue la corriente de salida
solicitada. Además, en el caso de que este voltaje suba en algún punto, se puede deber
47
a la regeneración del sistema lo que indica una carga demasiado grande para el variador
o un equipo de frenado mal dimensionado.
Como parte de los objetivos del proyecto a realizar está establecer una comunicación
con la nube de código abierto. Por consiguiente, la manera que se utilizó para subir datos
al internet fue usar el protocolo de comunicación MQTT en Codesys e implementarlo a
la Raspberry Pi.
Como primer paso para realizar este proceso es necesario que la Raspberry Pi posea
conexión con internet, la cual puede recibir tanto por conexión Ethernet o usando una
conexión Wifi.
El segundo paso por realizar es usar la página https://www.cloudmqtt.com/ con la cual
se puede crear una instancia con un plan gratuito, y al cual subiremos la información
48
que deseamos con la Raspberry Pi. Al crear la instancia esta nos brinda los parámetros
tales como el servidor, un usuario, una contraseña, un puerto, etc. Necesarios para
poder establecer la comunicación con esta instancia, como podemos observar a
continuación en la figura 46.
El lenguaje que se utilizó para realizar la comunicación Mqtt fue CFC, el cual podemos
observar en la figura 48, allí encontraremos el bloque que exige todas las variables
anteriormente creadas con el fin de poder conectarse al servidor de CloudMqtt, y el cuál
sabremos si hubo conexión al ver el estado de la variable ‘conectado’.
49
Fig. 55 Esquema para establecer comunicación por protocolo Mqtt.
Al realizar estos pasos se obtuvo una conexión correcta con la nube siempre y cuando la
Raspberry Pi tenga internet. A continuación, se desarrolla la lógica para poder publicar
la información al servidor, para ello la figura 49 se muestra la lógica de programación
para subir información, que para este proyecto los son datos de la corriente del motor
que mueve el ascensor y el voltaje DC de entrada.
50
Primero se registró una cuenta a IBM Cloud obteniendo el plan Lite, este plan permite
usar algunos servicios que distribuye IBM de forma gratuita, aunque posee algunas
limitaciones. Allí al tener la cuenta ya creada procedemos a agregar el recurso de una
base de datos llamada Cloudant, el cual podemos observar en la figura 50.
Al tener el servicio agregado en nuestra cuenta, ingresamos a este recurso para obtener
las credenciales, ya que estas son necesarias para realizar una conexión a esta base de
datos desde node-red. Al estar dentro el entorno de Cloudant procedemos a crear una
base de datos en la cual se almacenará los datos que publicamos con la Raspberry Pi,
por lo tanto, la figura 51 muestra la base de datos creada con el nombre ‘database1’.
Al tener nuestra base de datos ya creada procedemos a usar node-red para realizar la
conexión entre Cloudmqtt y la base de datos Cloudant. Para ello primero se instaló los
flujos necesarios para node-red. A continuación, la figura 52 muestra los flujos usados
para este proyecto y el esquema de las variables que serán almacenadas en la base de
datos.
51
Fig. 59 Flujos para envío datos de Mqtt a la base de datos.
Para que los flujos funcionen correctamente se ingresan unos parámetros necesarios
que permitirán conectar primero el Servidor CloudMqtt al flujo Mqtt de node-red y
luego del flujo Cloudant a la base de datos de Cloudant. Por consiguiente, primero los
datos que exige el flujo mqtt son los mostrados en la figura 53.
Al configurar el flujo Mqtt como fue mostrado en la figura anterior, permitirá una
conexión con el servidor de CloudMqtt anteriormente creado. El siguiente paso que se
realizo fue configurar el flujo de Cloudant de node-red para realizar la conexión con el
recurso de IBM que creamos anteriormente llamado Cloudant, como podemos observar
en la figura 54.
52
Los parámetros ingresados en el flujo de node-red son las credenciales que fueron
brindados al crear el recurso de IBM Cloudant. Lo único faltante para poder almacenar
la información es indicar la base de datos que fue creada en el recurso de IBM, de tal
manera que la figura 55 muestra la configuración faltante.
También podemos observar en node red otros flujos tales como “Split” encargado de
dividir los datos obtenidos del flujo Mqtt usando un carácter divisor, “Fecha_hora”
encargada de agregar al flujo de datos la fecha y hora en que fue publicado el mensaje
proveniente del servidor cloudmqtt, además de clasificar las variables publicadas
asignándoles un número del 1 a 5 respectivamente con “Corriente”, “Voltaje_BUS”,
“Referencia_R”, “Frecuencia_Salida” y “Alarmas”, en la figura 56 podremos observar el
código que realiza esa función, y por último el flujo “delete” encargado de borrar
información no tan relevante.
53
Fig. 64 Base de datos ‘database1’ con datos almacenados.
Para llevar a cabo la etapa de manejo de los datos con Machine Learning se hace uso de
la plataforma de Microsoft Azure con la cual es posible realizar proyectos de machine
learning en primera instacia lo que se necesita es llevar la base de datos obtenida desde
la raspberry a la plataforma de Microsoft, esto se puede realizar importándola
directamente como el archivo csv generado, ya que la plataforma de Microsoft es
totalmente en línea estos datos quedan almacenados en la nube para que sea posible
acceder a los mismos desde cualquier parte.
54
Fig. 66 Datasets subidos a la plataforma de azure
Para el caso de este proyecto se decidio hacer uso de las maqunas de soporte vectorial
o SVM, esta es entrenada con una serie de datos como se observa en la siguiente figura.
55
Lo primero que se realiza con el conjunto de datos obtenido es seleccionar las columnas
que serán necesarias para realizar el proceso, posterior a esto se realiza la normalización
de los datos y la división de los mismos, con una de las partes se entrena el modelo de
soporte vectorial y con la otra se realiza una evaluación de los datos buscando que el
porcentaje de exactitud sea lo suficientemente alto.
Luego de realizar este análisis es posible determinar la probabilidad con la que aparecerá
cada uno de los valores en el tiempo como se observa en la siguiente imagen, el dato
payload es el valor que es enviado en este caso de potencia en el sistema. Observando
que a pesar de que la mayor presencia esta en los valores positivos, aunque es posible
encontrar varios valores negativos los cuales están presentes en la regeneración del
sistema.
56
Con la evaluación de datos se obtiene unos valores estadísticos que permiten determinar qué
tan preciso es todo el proceso realizado.
A continuación, se puede observar los valores asignados a una base de datos de entrada
preestablecida en la cual se ingresan una serie de valores de tiempo con los que el
modelo entrenado devuelve los posibles valores de corriente. Para esta prueba se
tomaron lapsos de tiempo cortos debido a las limitaciones en la raspberry y en las
pruebas, se observa que 3 valores son los que principalmente se encontraran durante la
ejecución según la predicción realizada los cuales son 14.4 que equivale a 1.4 amperios
que es el consumo en la velocidad nominal del sistema 0.9 amperios para la velocidad
de nivelación y 0 durante los lapsos en los cuales el ascensor no se encuentra realizando
ningún viaje.
57
6. Conclusiones
58
limitante en cantidad de datos que se manejan. Por lo tanto, al realizar las pruebas en
ciertos casos nos veíamos cohibidos para probar otras opciones que pudiesen haber sido
más útiles pero que a su vez no son gratuitos.
59
7. Referencias
[15] _ © Antonio and M. Fernández, “Tema 5: El bus I2C TEMA 5 EL BUS I2C,” 2004.
[16] D. Oasis, “¿ Por qué MQTT es uno de los mejores protocolos de red para,” pp. 1–9, 2017.
[17] F. Mocq, Raspberry Pi 2 : utilice todo el potencial de su nano-ordenador. Ediciones ENI,
2016.
60
[19] A. F. G. Viera, «Técnicas de aprendizaje de máquina utilizadas para la minería de texto,»
SciELO Analytics, 2017.
61
8. ANEXOS
Anexo 1.
Código completo desarrollado para las llamadas desde el carro y esquema, además del
circuito PCB desarrollado.
#include <project.h>
#include <stdio.h>
#include <stdlib.h>
int piso = 0;
int main(void)
{
int i=0, LED;
////VARIABLES I2C
uint8 wrBuf[8];
uint8 rdBuf[8];
uint8 userArray[8];
uint8 byteCnt;
uint8 indexCntr;
uint32 status;
rdBuf[0]=Piso1_Read();
rdBuf[1]=Piso2_Read();
rdBuf[2]=Piso3_Read();
rdBuf[3]=Piso4_Read();
rdBuf[4]=Piso5_Read();
rdBuf[5]=Abrir_Read();
rdBuf[6]=Cerrar_Read();
rdBuf[7]=Emergencia_Read();
}
// Fin de la rutina para enviar datos ------------------------
62
I2C_I2CSlaveClearWriteStatus();
LED = userArray[1];
piso = userArray[2]; //En esta posición del arreglo
guardamos el piso del ascensor
}
I2C_I2CSlaveClearWriteBuf();
}
// Fin de la rutina para enviar datos ------------------------
if(LED == 1){led_Write(1);}
if(LED == 0){led_Write(0);}
}
//Fin del bucle infito ----------------------------------------
}
/* [] END OF FILE */
Código llamadas de cabina.
63
Circuito PCB desarrollado para llamadas de la cabina.
Anexo 2.
Código completo desarrollado para las llamadas desde los pisos y esquema, además de
los dos circuitos PCB desarrollados.
#include <project.h>
#include <stdio.h>
#include <stdlib.h>
int piso = 0;
int main(void)
{
int i=0, LED;
////VARIABLES I2C
uint8 wrBuf[8];
uint8 rdBuf[8];
uint8 userArray[8];
uint8 byteCnt;
uint8 indexCntr;
uint32 status;
//SPIS_Start();
CyGlobalIntEnable; /* Enable global interrupts. */
LCD_Seg_Start();
Clock_Start();
64
I2C_Start();
I2C_I2CSlaveInitWriteBuf((uint8 *) wrBuf, 8);
I2C_I2CSlaveInitReadBuf((uint8 *) rdBuf, 8);
for(;;)
{
/* Place your application code here. */
rdBuf[0]=UpP1_Read();
rdBuf[1]=DownP2_Read();
rdBuf[2]=UpP2_Read();
rdBuf[3]=DownP3_Read();
rdBuf[4]=UpP3_Read();
rdBuf[5]=DownP4_Read();
rdBuf[6]=UpP4_Read();
rdBuf[7]=DownP5_Read();
}
// Fin de la rutina para enviar datos ------------------------
LED = userArray[1];
piso = userArray[2];
}
I2C_I2CSlaveClearWriteBuf();
}
// Fin de la rutina para enviar datos ------------------------
if(LED == 1){led_Write(1);}
if(LED == 0){led_Write(0);}
}
}
/* [] END OF FILE */
Código llamado desde los pisos.
65
Esquema del código llamadas desde los pisos.
66
Anexo 2
Equipos Para pruebas
Durante el desarrollo del proyecto las principales pruebas fueron realizada utilizando un
demo de variador A1000, ya que en sus parámetros principales y funcionamiento no
difiere del modelo L1000. El demo consiste en un variador modelo A1000 el cual tiene
acoplada en su alimentación un arreglo de condensadores que permiten alimentarlo de
una línea de 120.
Junto con el demo usado se utilizó un motor trifásico para comprobar que todos los
comandos funcionaran de manera correcta.
67
Motor usado junto con el Demo Fuente Autor
Los datos de prueba enviados a la base en la nube son tomados de estas pruebas de
funcionamiento. Debido a la facilidad de manipulación de este demo es posible realizar
pruebas sin necesidad de la instalación de
Las simulaciones realizadas con este tablero permiten una más alta fiabilidad debido a
que en este caso se utiliza una alimentación de 220 V y un motor de más capacidad.
Además, una de las salidas del tablero es utilizada para alimentar el electrofreno de la
misma máquina que por seguridad si no es activado impide el movimiento del motor.
también en este caso es posible trabajar un control de velocidad en lazo cerrado, esto
gracias a que la maquina cuenta con un encoder instalado que permite la realimentación
al variador de la velocidad de salida.
68
Planos del tablero de pruebas con variador L1000A
69
70