Sei sulla pagina 1di 83

CONTROL SUPERVISORIO DE UN ROBOT MANIPULADOR INDUSTRIAL MITSUBISHI MELFA

UTILIZANDO LA PLATAFORMA LABVIEW

DIEGO FERNANDO QUINTANA PEÑA

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA ELECTRONICA

BOGOTÁ DC.

2011
CONTROL SUPERVISORIO DE UN ROBOT MANIPULADOR INDUSTRIAL MITSUBISHI MELFA
UTILIZANDO LA PLATAFORMA LABVIEW

DIEGO FERNANDO QUINTANA PEÑA

TRABAJO DE GRADO PARA OPTAR POR EL TITULO DE INGENIERO ELECTRONICO

DIRECTOR

SERGIO RAMIRO GONZALEZ BAUTISTA I.E.

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA ELECTRONICA

BOGOTÁ DC.

2011

  2  
PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA ELECTRONICA

RECTOR MAGNÍFICO: JOAQUIN EMILIO SANCHEZ GARCIA, S.J.

DECANO ACADÉMICO: Ing. FRANCISCO JAVIER REBOLLEDO MUÑOZ

DECANO DEL MEDIO UNIVERSITARIO: P. SERGIO BERNAL RESTREPO, S.J.

DIRECTOR DE CARRERA: Ing. JUAN MANUEL CRUZ BOHORQUEZ M.Sc.

DIRECTOR DEL PROYECTO: Ing. SERGIO RAMIRO GONZALEZ BAUTISTA M.Sc(C).

  3  
CONTENIDO
1 INTRODUCCIÓN.…..……………………………………………….….……………….9
2 MARCO TEÓRICO….…………….………………………………….………………..12
2.1 FMS – Sistema de Manufactura Flexible……...…………………………….…………...12
2.2 Robot industrial.………………….……………………………………...…….…………15
2.2.1 Robot MELFA serie RV-2A……..…………………………………………………….……….…15
2.2.2 Controlador CR1………..…………………………………………………………….……….…..16
2.3 Protocolo comunicación TCP/IP……………………………..……………………..........20
2.4 LabVIEW®...…………………………………………………………………………….23
2.4.1 Instrumentos virtuales………………………………………………………………………….....23
2.4.2 Comunicación de datos…………………………………………………………….....................25
2.4.3 Enlace con bases de datos………………………………………………………………………..25
3 DESCRIPCION GENERAL Y ESPECIFICACIONES…………………...................27
3.1 Apariencia de la herramienta……………………………………………………………..29
3.2 Sistema de alarmas………………………………………………………………...……..29
3.3 Base de datos……………………………………………………………………………..27
3.4 Programa robot…………………………………………………………………………...31
4 DESARROLLOS…………………………………………………………………..……32
4.1 Definición de protocolos de comunicación……………………………………..………..32
4.2 Establecimiento de Comunicación……………………………………………………….35
4.2.1 Diseño servidor y cliente en LabVIEW®..……………………………………...………...……36
4.2.2 Comunicación TCP/IP servidor LabVIEW® – Cliente robot Melfa……….……………….38
4.3 Definición tareas y código de instrucciones……………………………………..……….40
4.4 Lectura y envío de instrucciones………………………………………………………....42
4.5 Lectura de sensores de la estación de trabajo y configuración de alarmas….....................43
4.6 Configuración programa Robot…………………………………………………………..44
4.6.1 Establecimiento de comunicación y lectura de instrucciones
……………………………………………………………………………………………...………………….45
4.6.2 Configuración tareas……………………………………………………………………………...45
4.7 HMI…………………………………………………………………………………………...……..51
4.8 Aplicación…………………………………………………………………...……………52
4.8.1 Establecimiento del enlace……………………………………………………….............53
4.8.2 Selección de instrucción……………………………………………………………..…...53
4.8.3 Envío de instrucción y recepción respuesta robot………………………………………..54
4.8.4 Análisis respuesta………………………………………………………………………...54
4.8.5 Conexión base de datos…………………………………………………………………..55

  4  
4.9 Mejoras a la aplicación .………………………………………………………………….56
4.9.1 Herramienta principal LabVIEW®.……………………………………………...………56
4.9.2 Programa robot………………………………………………………………………..…57
5 ANÁLISIS DE RESULTADOS…...……………………………………………………59
5.1 Pruebas realizadas………………………………………………………………………...59
5.1.1 Proceso y tiempo de conexión……………………………………………………………59
5.1.2 Tiempo ejecución de tareas…….………………………………………………………...60
5.1.3 Generación de alarmas…………………………………………………………………...63
5.2 Alcances de operación……………………………………………………………………63
6 CONCLUSIONES Y RECOMENDACIONES ………………………………………65
7 BIBLIOGRAFIA ………………………………………………………………….........67
8 ANEXOS…………………………………………………………………………………69

  5  
INDICE FIGURAS
[Figura 1] Interfaz usuario Herramienta LabVIEW……………………………………..………......10
[Figura 2] FMS de Pontificia Universidad Javeriana………………………………………..………14
[Figura 3] Especificaciones técnicas controlador CR1………………………………………….…...16
[Figura 4] Comandos Melfa BasicIV para comunicación…………………………………………...19
[Figura 5] Modelo OSI………………………………………………………………………………21
[Figura 6] Modelo OSI, proceso de comunicación…………………………………………….…….22
[Figura 7] Modelo TCP/IP……………………………………………………………………….…..23
[Figura 8] Panel frontal instrumento virtual………………………………………………………....24
[Figura 9] Código fuente instrumento virtual……..……………………………………....................24
[Figura 10] Funciones para comunicación protocolo TCP/IP LabVIEW …………………….........25
[Figura 11] Funciones Database Connectivity Toolkit………………………………………………..26
[Figura 12] Proceso modificación base de datos……………………………………………………...27
[Figura 13] Diagrama de bloques de herramienta principal LabVIEW®..……………………………28
[Figura 14] Diagrama de bloques programa robot…………………….....……………………………28
[Figura 15] Ventana principal…………………………………………………………………………28
[Figura 16] Base de datos……………………………………………………………………………..29
[Figura 17] Metodología del proyecto………………………………………………………………...32
[Figura 18] Topología de red FMS…………………...………………………………………….........33
[Figura 19] Posibilidades de comunicación robot……………………………………………….........33
[Figura 20] Modelo cliente……………………………………………………………………………34
[Figura 21] Modelo de comunicación –Servidor/cliente……………………………………...………35
[Figura 22] Verificación de conexión en red…………………………………………….....................36
[Figura 23] Base de cliente LabVIEW…….…………………………………………………….........37
[Figura 24] Base de servidor LabVIEW…..…………………………………………………………..37
[Figura 25] Programa cliente para comunicación en robot……………………………………………39
[Figura 26] Servidor comunicación con robot………………………………………………………...39
[Figura 27] Estación robot……………………………………………………………….....................40
[Figura 28] Secuencia de programa en robot lectura instrucciones e instrumento virtual.. …….........42
[Figura 29] Diagrama de flujo ejecución de alarmas………………………………………………….44
[Figura 30] Establecimiento de comunicación y recepción de instrucciones…………………………45
[Figura 31] Movimiento pallet..……………………………………………………………………….46
[Figura 32] Movimiento de barras…………………………………………………………….………48
[Figura 33] Movimiento de cilindros………………………………………………………….………49
[Figura 34] Movimiento de botellas…………………………………………………………………..50

  6  
[Figura 35] Lista tareas posible…………………………………………………………………..…...51
[Figura 36] Status celda de trabajo………………………………...……………………………..…...53
[Figura 37] Diagrama en bloques herramienta principal LabVIEW……………………………..…...53
[Figura 38] Establecimiento del enlace……………………………………………………………….53
[Figura 39] Selección de instrucción…………………………………………………….....................54
[Figura 40] Envío de instrucción y recepción respuesta robot………………………………...……...54
[Figura 41] Análisis de respuesta……………………………………………………………………...54
[Figura 42] VI Database…………………………………………………………………....................55
[Figura 43] Entradas VI Database……………………………………………………………….........56
[Figura 44] Mejoras selección y envío de instrucción….………………………………......................56
[Figura 45] Mejoras bloque lectura, generación de alarmas y control de escritura base de datos
….…………………………………………………………………………………………………………..57
[Figura 46] Captura Wireshark® - conexión………………………………………………………….60
[Figura 47] Registro movimiento de pallet base de datos………...…………………………………..61
[Figura 48] Registro movimiento de barras base de datos………………...……………………..........61
[Figura 49] Registro movimiento de cilindros base de datos……………………...…………….........62
[Figura 50] Registro movimiento proceso análisis cilindros base de datos……………...……………62
[Figura 51] Case análisis de alarma base de datos……………………………………………………63
[Figura 52] Registro alarmas base de datos…………………………………………………………...63
[Figura 53] Prueba tiempo de utilización de la aplicación.....………………………………………...63

  7  
TABLAS
[Tabla 1] Parámetros a configurar para comunicación DL……………………………...……….....19
[Tabla 2] Parámetros configurados en controlador…………………………………………………36
[Tabla 3] Definición de instrucciones…………………………………………………....................38
[Tabla 4] Señales de sensores en el controlador CR1…………………………………....................41
[Tabla 5] Código de alarmas………………………………………………………………………..41

  8  
1 INTRODUCCIÓN

La Pontificia Universidad Javeriana dispone del Centro Tecnológico de Automatización Industrial


(CTAI)1. Espacio con los suficientes recursos para el estudio de procesos industriales y manufactura. En
su interior, CTAI cuenta con diferentes estaciones de trabajo que abarcan diferentes escenarios posibles en
el área de la automatización, manufactura y la producción. En especial, dispone de una celda de
manufactura integrada por un almacén de materia prima y producto terminado, una estación de
mecanizado, una banda transportadora y un robot manipulador industrial fabricación Japonesa Mitsubishi
MELFA serie RV-2A.

El control se lleva a cabo desde un SCADA configurado en una estación central mediante un software
especializado, COSIMIR® CONTROL, llevando un control supervisorio de manufactura. Software
propietario con limitaciones al integrar nuevas aplicaciones lo cual limita la flexibilidad de un sistema de
manufactura. Por esta razón, en proyectos anteriores se han desarrollado aplicaciones por medio de
herramientas flexibles para el control de la celda. Trabajos de grado como “Control de un almacén de
AS/RS2 desarrollado en una herramienta gráfica para pruebas y control” por el ingeniero Christian Camilo
Vallejo Castañeda y “Control supervisorio de una banda transportadora en LABVIEW®” por el ingeniero
Oscar David Forero Martínez, desarrollaron aplicaciones para el almacén y la banda transportadora
respectivamente a través de LabVIEW® por su programación grafica, funciones para comunicación y la
posibilidad de integración de nuevas tecnologías de diferentes fabricantes.

La siguiente etapa en este proceso es la realización de una herramienta para el establecimiento de las
tareas del robot. Este proyecto tiene como objetivo general diseñar un sistema de control supervisorio de
el robot industrial mediante la plataforma LabVIEW®, para esto se definen tres objetivos específicos
como metas para su desarrollo:
- Generar la comunicación de un robot manipulador industrial fabricación Japonesa Mitsubishi
MELFA serie RV-2A y una plataforma de simulación en LabVIEW®.
- Desarrollar una interfaz grafica de usuario en LabVIEW® para la supervisión y control del robot.
- Establecer las tareas de manipulación de material propias del robot.
Los diferentes desarrollos llevados a cabo para alcanzar cada uno de estos objetivos se muestran
detalladamente en el capitulo Desarrollos de este documento. Como premisa del proyecto del proyecto es
necesaria la posibilidad de incluir nuevas tareas por parte del robot ya que CTAI adquiere nuevas
estaciones además de tipos de materiales para ser transportados.

                                                                                                               
1  En este punto y en todo el documento se hará referencia a las siglas CTAI como “Centro Tecnológico de
Automatización Industrial”
2
AS/RS Automated Storage and Retrieval System o sistemas de almacenamiento/recuperación automáticos. Sistemas de
almacenamiento automatico donde la funcion del operador es minima o casi nula[16].

  9  
Para el diseño de la aplicación fue necesario llevar tanto los desarrollos de una herramienta principal en
LabVIEW® como un programa almacenado en el robot, los cuales al ser ejecutados conjuntamente,
permiten la realización de tareas de manipulación de material por parte del robot. Además, la posibilidad
de tener información sobre el material disponible para ser transportado y el almacenamiento de las tareas
ejecutadas en una base de datos a disposición del operador, es decir la generación de históricos de
operación importante en un control de carácter supervisorio.

La totalidad de la herramienta principal se llevó a cabo en LabVIEW® 9.0, el cual la universidad cuenta
con licencia. Se diseñó una interfaz a usuario de fácil ejecución por parte de un operario [figura 1] en
donde se observan las posibilidades de movimientos con la aplicación, al igual salidas de interés como el
numero de tarea realizado y el tiempo de ejecución de cierta tarea.

[Figura 1] Interfaz usuario Herramienta LabVIEW

Por su parte, en el robot fue desarrollado un programa en su propio lenguaje de programación para uso
exclusivo con la aplicación, el cual según instrucciones enviadas desde la estación base llevarían al robot a
la ejecución de una serie de movimientos para cumplir con la totalidad de tareas. Lo anterior después de
haber sido establecida la comunicación mediante un protocolo de comunicaciones entre aplicación y
robot, y haciendo uso de una conexión física existente con el controlador del robot. Comunicación
seleccionada después de el análisis de las posibles vías de comunicación entre las partes.

Después de todos los desarrollos fue necesario el análisis de los resultados obtenidos y así llevar el
proyecto a unas conclusiones. Los resultados se evidencian en pruebas finales de funcionamiento de la

  10  
aplicación en conjunto con el desarrollo de las tareas por parte del robot, que se discuten en capítulos
posteriores en el documento.

  11  
2. MARCO TEÓRICO

Como marco teórico de este proyecto es necesario el conocimiento de conceptos previos como Sistema de
Manufactura Flexible, sus componentes y similitud con el que cuenta el CTAI; robótica industrial y
características importantes en el robot utilizado en este trabajo, comunicación vía protocolo TCP/IP y
finalmente LabVIEW, sus características y funciones para el desarrollo de la aplicación principal.

2.1 FMS – Sistema de Manufactura Flexible

Un sistema de manufactura flexible (FMS, por su sigla en ingles) es una celda mecanizada altamente
automatizada, la cual la compone un grupo de estaciones de trabajo como maquinas CNC 3, sistemas de
manejo de material y sistemas de almacenamiento y ensamble, controlados por una estación central de
computo. Sistema interconectado con la finalidad de una producción de partes o productos dentro de un
rango de estilos, tamaños y procesamientos.

Hay diferentes requerimientos que debe cumplir un sistema para ser catalogado como flexible. Como
primero debe tener la capacidad de hacer un seguimiento del producto distinguiendo entre los diferentes
estilos de productos procesados por la celda, segundo permitir un rápido cambio de instrucciones de
operación y por ultimo permitir el cambio en una configuración física como la adquisición de nuevas
estaciones de trabajo. Un FMS es entonces el conjunto de soluciones tanto de maquinaria como software
para incrementar la flexibilidad a través del uso adecuado de sus diferentes componentes.

Un FMS básicamente se compone de cuatro partes:


-­‐ Estaciones de trabajo: Se encuentran las maquinas usadas para el procesamiento o ensamblaje
dependiendo del tipo de trabajo llevado a acabo por el sistema. Un ejemplo las maquinas CNC.
-­‐ Manejo de material y sistema de almacenamiento: Compuesto por diferentes estaciones las cuales
llevan a cabo funciones como el transporte de material entre las estaciones de trabajo, el
almacenamiento de material para ser procesado, o en tiempo de espera para ello como un
almacenamiento temporal, entre otros. Entre estos sobresalen las bandas transportadoras y los
robots manipuladores industriales.
-­‐ Sistema de control por computadora: Consiste en un computador central interconectado con las
estaciones de trabajo, sistemas de manejo de material y almacenamiento y otros componentes

                                                                                                               
3  CNC
computer numerical control hace referencia a maquinas las cuales los movimientos de la herramienta u otro
equipamiento son controlados por programas que contienen datos alphanumericos[1].

  12  
hardware de la celda, controlando los sistemas individualmente. Además coordina las actividades
de los diferentes componentes para alcanzar los objetivos de la producción. Entre sus funciones
sobresalen:
o Control de las estaciones de trabajo
o Control de las instrucciones a las estaciones de trabajo
o Control de producción
o Control de trafico
o Monitoreo de la pieza de trabajo
-­‐ Recursos humanos: Aunque un FMS es altamente automatizada, se necesita de personal para el
manejo y operar los sistemas. Funciones como por ejemplo, descarga de piezas finalizadas del
sistema o el cambio y la instalación de herramientas.[1]

El FMS del CTAI esta ubicado en la sala CIM4, espacio a disposición de los estudiantes y la comunidad
para temas relacionados con la automatización industrial como el control de procesos industriales.

Cuenta con cuatro estaciones que llevan a cabo un proceso de mecanizado de piezas cilíndricas por medio
de una maquina de torneado de control numérico. Las estaciones se pueden observar en la [figura 2].

- Almacén de materia prima y producto terminado (AS/RS): Sistema de almacenamiento


automático adquirido a la empresa FESTO, el cual cuenta con 40 contenedores los cuales un brazo
robótico tiene la capacidad de recoger o entrega de productos sobre una banda transportadora
próximo a este. Cada uno de los productos almacenados se encuentra ubicado sobre un pallet el
cual permite al brazo mecánico llevar a cabo la recolección, además permite el transporte de este
en la banda transportadora, próxima estación en el FMS.
- Banda transportadora: Tiene una forma rectangular y cumple la función del transporte de material
desde el almacén hacia el centro de mecanizado, y viceversa. Para el control de trafico y la
operación conjunta con las estaciones próximas posee actuadores electro-neumáticos los cuales
detienen los carriers5 en cada una de las 4 estaciones que posee.

                                                                                                               
4  CIM  –  Computer integrated manufacturing o manufactura integrada por computador  
5  Los Carriers son los “carritos” o transportadores de las piezas a procesar en el sistema, éstos viajan por toda la banda
transportadora; actualmente existen 8 carriers.  
 

  13  
[Figura 2] FMS de Pontificia Universidad Javeriana

- Robot manipulador industrial: Cumple funciones de manejo de materia prima para ser procesado
por el centro de mecanizado alimentando el torno y así terminar con un proceso de manufactura.
Siguiendo en el proceso, devuelve la pieza terminada a la banda transportadora para que esta lleve
el producto terminado a ser almacenado terminando con el proceso.
- Centro de mecanizado: Lo comprende un torno de control numérico, el cual una vez alimentado
por el robot industrial por la materia prima determinada, realiza un proceso de mecanizado dando
una pieza terminada.
- Estación de control central: Computador conectado al sistema de manufactura el cual se le fue
instalado un software para el control de esta, llevando un control de cada uno de las estaciones y
además la posibilidad de configurar diferentes planes de proceso para ser ejecutados por el FMS.
El software es un SCADA configurado en COSIMIR CONTROL

  14  
2.2 Robot industrial

Actualmente el uso de robots manipuladores es cada vez mas común en tareas repetitivas que necesitan
fuerza y precisión, siendo un actor principal en el área de automatización industrial. los avances
tecnológicos de los últimos años, la computadora y las capacidades de procesamiento cada vez mayores de
los microprocesadores han constituido en factores importantes para su avance[2].

Básicamente el sistema de robot industrial lo comprenden:

-­‐ Manipulador: Conjunto de articulaciones mecánicas, actuadores y sensores de posición, es decir el


conjunto de partes que componen el brazo robotico.
-­‐ Herramienta de producción: Efector final el cual define la utilidad del robot. Según el método de
sujeción se definen tres grupos:
o Sujeción mecánica: pinzas de dos o mas dedos los cuales tienen posibilidad de apertura y
cierre.
o Sujeción por contacto: por succión, atracción magnética o materiales adhesivos en sus
terminales.
o Sujeción por enganche: palas o ganchos diseñados según objeto.
-­‐ Fuente de potencia: Unidad que alimenta los motores que actúan. Tipo eléctrico, neumático o
hidráulico.
-­‐ Controlador: Recibe señales de sensores de posición existentes y lleva a cabo el control de los
diferentes actuadores para una ejecución de tareas programadas.
-­‐ Control de enseñanza (teach-pendant): Dispositivo mediante el cual se puede llevar a cabo la
enseñanza de posiciones, así como acceso de comandos, ejecución de programas y edición de
estos.[3]

2.2.1 Robot MELFA serie RV-2A.

En el CTAI de la Universidad Javeriana se cuenta con un robot manipulador fabricación japonesa


Mitsubishi modelo MELFA serie RV-2A parte de el sistema de manufactura flexible. El robot cuenta con
seis grados de libertad, una capacidad de carga máxima útil de 1 kg y una precisión +/- 0.02mm. Como
herramienta de producción utiliza el método de sujeción mecánica mediante una pinza de funcionamiento
electro-neumático instalada. Conectado a su propio controlador modelo CR1 y su respectivo teach-
pendant para el control de movimientos, almacenamiento de posiciones y ejecución de programas[6].

  15  
Posee un lenguaje de programación propio llamado MELFA-BASICIV por su similitud con el conocido
BASIC, por lo que no es una tarea difícil el aprender de este. Al igual que otro lenguaje propio
MOVEMASTER COMMAND bastantes similares entre si.

2.2.2 Controlador CR1

El robot manipulador para su funcionamiento cuenta con un controlador serie CR1 de su mismo
fabricante, el cual cumple funciones de fuente de poder, CPU y controla los diferentes movimientos de sus
junturas para la ejecución de un desplazamiento, a través de cada uno de sus módulos en su interior. Entre
las facilidades para su operación, a disposición de los usuarios se cuenta con capacidades de memoria de
hasta 88 programas, un numero máximo de tareas simultaneas de 32 y la posibilidades de comunicación
con periféricos como sensores y PC`s a través de sus puertos de comunicación.

El controlador dispone de puertos de comunicaciones instalados previamente por el fabricante para


posibilidades de comunicación con este. En la [Figura 3] se puede observar la disponibilidad de una
interfaz RS-232 para comunicación con un PC. Igualmente 16 señales de entrada y 16 señales de salida
para propósito general mediante un conector DB32 y como tercera opción, el espacio para instalación de
tarjetas.

[Figura 3] Especificaciones técnicas controlador CR1[6]

Entre sus opciones, Mitsubishi permite la posibilidad de adquirir tarjetas para la configuración de redes
según las aplicaciones en industria. Las posibilidades que brinda son las siguientes:

o Ethernet: tarjeta para comunicación usando protocolo TCP/IP de alta velocidad para
establecer comunicación entre robot y PC`s o sensores.

  16  
o CC-link: a partir de esta opción se pueden obtener un gran numero de entradas/salidas
virtuales para comunicación con un PLC.
o Profibus/DP: para aplicaciones particulares donde el factor tiempo es un factor critico.

CTAI instaló una tarjeta Ethernet para comunicación vía TCP, por lo tanto la comunicación con el robot
es posible a través de el modulo adquirido de fabrica RS232 para interfaz con computadores personales, el
uso de las señales entrada/salida o el modulo extra Ethernet. El proceso de análisis para determinar el
medio físico a comunicarse con el controlador se explica de manera detallada en el capitulo de desarrollos
de este documento.

Como punto de referencia el manual de operación e instrucciones adquirido con el modulo Ethernet [7] se
dispone de funciones especializadas para aplicaciones con computadores personales mediante tres Modos
de Comunicación, los cuales varían dependiendo el tipo de información que se desea enviar y/o recibir y
la forma de acceder a esta información, es decir los fines de la aplicación desarrollada.

Para la ejecución de sus tareas, la programación previa de estas se hace mediante su propio lenguaje a
través de comandos MELFA BASICIV, lenguaje con un amplio directorio de instrucciones a partir de las
cuales se pueden realizar tareas como movimiento del robot, programación de rutinas y comunicación
mediante señales de entrada y salida o variables cuyo dato puede ser enviado a través de uno de sus
puertos. En particular, las posibilidades de comunicación del controlador permiten tener la posibilidad de
sumar funciones de red al robot, como por ejemplo el control de este a través de un puerto de
comunicación.

- Lenguaje MELFA BASICIV

Los movimientos de los robots fabricación Mitsubishi son controlados en programas escritos en su
lenguaje de programación propio. Las comandos conocidos y demás adicionales propias para el manejo
del robot constituyen un lenguaje con suficientes instrucciones para realizar complejas tareas.

Para la escritura de un programa se debe seguir determinado orden, lo que constituye su estructura. En [3]
se definen ciertos pasos a seguir para la escritura de un programa, básicamente dos partes los cuales son:
o Declaración de variables: definición de la totalidad de variables utilizadas en el programa
previo a la utilización de las mismas. Definiciones de
• Señales de entrada/salida - DEF IO
• Posiciones - DEF POS
• Aceleración y desaceleración del robot (pueden ser cambiados posteriormente) -
ACCEL
• Velocidad de los movimientos.

  17  
 JOVRD – movimientos basados en junturas
 SPD – movimientos basados en ejes coordenados
o Código: instrucciones propias para el movimiento del robot así como demás tareas a realizar a
lo largo de su ejecución
• Ejecución de movimientos
 MOV - movimientos basados en junturas.
 MVS - movimientos basados en ejes coordenados.

- Modos de Comunicación
El controlador para suplir necesidades de comunicación, ofrece tres modos de comunicación diferenciados
en el tipo de información a que se quiere acceder o el tipo de comunicación que se quiere entablar. Para
esto es necesario una configuración previa de ciertos parámetros del controlador para habilitar ciertas
funciones, todo esto es posible mediante el respectivo teach-pendant del robot. Estos modos de
comunicación dependiendo de la conexión física y protocolo a utilizar según interfaces disponibles o
aspectos preliminares del diseño tienen características a considerar. Los modos son tres: modo
Controlador, Control Externo En Tiempo Real y Enlace De Datos, Cada uno utilizado según los fines de la
comunicación con el robot, por lo que el escoger el modo de comunicación debe ser de gran
importancia[7].
Trabajos anteriores con un robot de la misma familia [4] evaluaron el desempeño y las limitaciones en la
comunicación con el robot a través de los tres diferentes posibles los cuales se nombran a continuación.

o Modo Controlador
Comunicación para tener acceso a datos del robot como leer su estatus, además de configuración de
parámetros del robot. Obtener información es solo posible mientras el robot no este en movimiento.
Luego, establecer comunicación con el robot para la ejecución de tareas ya sea almacenadas en este o
enviada a través de comandos no seria posible.

o Modo Control en Tiempo Real (RTCM)


Útil para un control directo del robot donde la trayectoria a seguir es calculada previamente de manera
manual. La comunicación es basada en el protocolo de transporte UDP, en donde el datagrama UDP es
enviado de una manera rápida debido a su encabezado pequeño pero la limitación en una recepción segura
de las tramas de datos es un punto en contra en este modo. Aunque para aplicaciones punto a punto de
corta distancia de las cuales se desean establecer no significaría una barrera de mucha importancia, la

  18  
perdida de información significaría un movimiento discontinuo del robot. Además, el uso de este modo no
esta disponible para la serie de controlador del robot del centro de manufactura del CTAI.

o Modo enlace de datos (DL)


La ejecución de movimientos del robot es posible gracias a la comunicación mediante el uso de comandos
de su propio lenguaje de programación, MELFA BASICIV. Se habilitan ciertos comandos especiales para
la comunicación con un computador personal con la que es permitido la lectura y el envío de tramas IP
sobre la red. Es de gran ayuda debido a que se facilita el control de ejecución de los movimientos mientras
se puede obtener información del status del robot, y como la ejecución de los movimientos es posible solo
a través de los comandos de su mismo lenguaje de programación, el controlador calcula la trayectoria a
seguir. Estos comandos pueden ser enviados en cualquier momento sobre Ethernet o puerto serial, con la
ventaja de no llegar a tener paradas en la ejecución del movimiento por lecturas. El posible control de
ejecución de tareas seria viable con estas características, debido a la compatibilidad con los puertos
existentes en el controlador instalados en la actualidad.

Para este modo de comunicación se dispone de ciertos comandos específicos para la lectura y envío de
datos en la red. Los comandos son tres, con los cuales es posible la apertura del puerto de comunicaciones
para inicio en el proceso de establecimiento de una comunicación y dos comandos para la lectura y el
envío de datos. [Figura 4]

[Figura 4] Comandos Melfa BasicIV para comunicación

Para el uso del controlador en este modo de comunicación es necesaria la configuración de ciertos
parámetros como asignación de puertos y definir el modo el cual es requerido, además de protocolos a
usar. Como se plantea la posible comunicación acorde a un modelo cliente/servidor mediante un protocolo
de comunicación, dicha arquitectura es posible realizando una configuración de ciertos parámetros en el
controlador los cuales toman valores distintos. En este proyecto gracias a la versión del software del

  19  
controlador (versión H7) es posible la configuración tanto de cliente como de servidor. (versiones menores
solo aceptan configuración como servidor del controlador).

Con alguna similitud a la configuración de una red, los parámetros a reconfigurar en el controlador son los
siguientes:

Parámetro Descripción Valores

NETIP Configuración de la dirección IP del controlador en la red Cualquier valor de direccionamiento IP

Configuración número de puerto para comunicación. Un total de


nueve puertos posibles donde el primero de ellos es reservado para
la función control en tiempo real, los ocho restantes se disponen Numeros desde 0 a 32767. por defecto se tienen
NETPORT para la función enlace de datos. preconfigurados 10000-10009

0: no-procedure: protocolo para ser usado cuando se


desea establecer comunicación con el software de
soporte.
1: procedure: reservado
2: DataLink: con esto se habilitan comandos para
CPRCE Configuración de modo de comunicación comunicación como open/input/print.

n:1 OPT11 para espicificar NETPORT(2) n:2 OPT12


para espicificar NETPORT(3) n:3 OPT13 para
espicificar NETPORT(4) n:4 OPT14 para espicificar
NETPORT(5) n:5 OPT15 para espicificar
Configuración necesaria cuando la función DataLink es utilizada, NETPORT(6) n:6 OPT16 para espicificar
ya que se dispone de ocho puertos, se necesita definir en cuales se NETPORT(7) n:7 OPT17 para espicificar
desea habilitar el comando OPEN de un programa del robot. Este NETPORT(8) n:8 OPT18 para espicificar
parámetro esta relacionado con el previamente configurado NETPORT(9) n:9 OPT19 para espicificar
COMDEV NETPORT ya que deben coincidir NETPORT(10)

Configuración de la comunicación TCP/IP en el modo de


NETMODE comunicación DataLink como servidor o como cliente 0: cliente 1:servidor

Es necesario la configuración de este parámetro cuando se usa el


robot como cliente para establecer la dirección del servidor con la Cualquier valor de direccionamiento IP (del servidor
NETHSTIP cual se espera establecer la comunicación correspondiente)

[Tabla 1] parámetros a configurar para comunicación DL

2.3 Protocolo comunicación TCP/IP

Un protocolo en términos de comunicaciones, se define como “el formato y el orden de los mensajes
intercambiados entre dos o mas entidades que se comunican, así como las acciones que se toman en la

  20  
transmisión y/o recepción de un mensaje u otro evento”[5]. En un escenario de comunicación de datos se
utilizan diferentes protocolos para llevar a cabo diferentes tareas de comunicación.

La comunicación se da entre lo que se denomina sus componentes de red. Entre estos, sobresalen los
sistemas terminales con los cuales se esta mucho mas familiarizado, aunque En el proceso de
comunicación intervienen otros componentes los cuales tienen funciones relacionadas con conmutación y
enrutamiento fuera de los alcances de este documento. Los sistemas terminales, llamados así por estar
ubicados en los extremos de la red, son también llamados host por dar lugar a aplicaciones y su ejecución,
programas de aplicación. Estos host son divididos regularmente en dos categorías: clientes y servidores.
Un cliente se puede definir como un programa que se ejecuta en un sistema terminal que solicita y recibe
un servicio de un servidor que se ejecuta en otro sistema terminal. Esta arquitectura cliente/servidor es de
gran aceptación en el campo de redes de comunicación en donde interactúan entre si enviándose mensajes
de datos.

Estos programas o aplicaciones deben estar soportados sobre una base para el envío de dichos mensajes
por la red. Para explicar esto se ha definido un modelo globalmente aceptado conocido como modelo OSI
(Open System Interconnection) el cual define el proceso de comunicación dentro de una jerarquía de siete
niveles, no es un protocolo o un conjunto de reglas, simplemente define las funciones o servicios que
tienen que ser brindados por cada uno de sus niveles para permitir la cooperación entre sistemas abiertos.
Cada uno de estos niveles establece una comunicación con su par en el otro punto de comunicación
[Figura 5] pasando por cada uno de las capas subsecuentes [Figura 6]

[Figura 5] modelo OSI[8].

  21  
[Figura 6] modelo OSI, proceso de comunicación[8]

Como se puede observar en la [figura 5] los 7 niveles son los siguientes:


o Aplicación: responsable de soportar las aplicaciones de red
o Presentación: convierte los datos dentro de un formato de representación externo que permita
la recepción segura de los datos, como por ejemplo encriptación de datos.
o Sesión: controla la comunicación entre los usuarios. Mensajes de coordinación por ejemplo.
o Transporte: Proporciona el servicio de transporte de mensajes de la capa de aplicación entre
los lados de cliente y servidor de una aplicación, un ejemplo es el protocolo de transporte TCP
el cual garantiza la entrega de mensajes a su destino y controla el flujo (velocidad), Además
segmenta los mensajes según su longitud.
o Red: es el responsable de enrutar los datagramas de una maquina a otra, además del
direccionamiento de la red. un ejemplo el protocolo IP el cual define un direccionamiento
lógico compuesto por un numero único de 32 bits ordenado en cuatro grupos de números.
Ejemplo. 192.68.21.10 (equivalente decimal)
o Enlace: es el responsable del movimiento de los marcos de datos desde un sistema a otro, para
seguridad de esto hace uso de técnicas para detección de errores.
o Físico: define las conexiones eléctricas y mecánicas del canal de comunicación[8].

El protocolo TCP/IP es entonces una representación del modelo OSI reducido a cuatro capas como se
puede ver en la [Figura 7]. Debido al crecimiento y la evolución en las redes de computadores y
aplicaciones de Internet se define un modelo estándar para entender su funcionamiento evitando conceptos

  22  
complejos de operación para conocer acerca del funcionamiento de por ejemplo un servidor Web TCP/IP
[9].

[Figura 7] modelo TCP/IP [9]

Se reduce entonces a las cuatro capas explicadas anteriormente, en las cuales transporte y red
corresponden a protocolo TCP e IP respectivamente.

2.4 LabVIEW®

LabVIEW (Laboratory Virtual Instrument Engineering Workbench) es una herramienta de


programación de gran ayuda el cual utiliza su propio lenguaje de programación denominado lenguaje “G”.
Su naturaleza grafica lo hace ideal al momento de desarrollar aplicaciones para medición y test,
automatización, control, adquisición de datos y su respectivo análisis. Para su programación se utilizan
diferentes bloques o iconos para cada función, estos serán conectados mediante cables por las entradas y
salidas del mismo. Esta programación se realiza en archivos denominados como instrumentos virtuales o
VI’s.

2.4.1. Instrumentos virtuales


Un instrumento virtual (VI) consiste en un panel frontal, un diagrama de bloques y un icono el cual
representa el programa. El panel frontal muestra los controles e indicadores a usuario, y el diagrama en
bloques contiene la totalidad de la programación en su respectivo lenguaje, el código para el VI.

En la [Figura 8] se puede observar un panel frontal el cual contiene por ejemplo el mando para seleccionar
un numero de medidas promedio, un control para seleccionar el tipo de medida, un display de un valor de
salida digital y un botón de parada. Todo esto utilizado para una aplicación de usuario desarrollada gracias

  23  
a las distintas herramientas disponibles en su menú de funciones. Igualmente en la [Figura 9] se muestra el
diagrama en bloque de la aplicación, también llamado código fuente. En este se pueden ver ciertas
funciones disponibles para la programación como lo es por ejemplo la disponibilidad de estructuras como
“while loop” exterior y en su interior “case structure”. En el centro el icono de un VI el cual recibe el
numero de mediciones promedio como entrada y retorna el valor de frecuencia como salida[18]. Viendo la
naturaleza del diagrama de bloques se puede interpretar el funcionamiento de LabVIEW, el proceso de
ejecución es de acuerdo a la configuración para el paso de información de izquierda a derecha siendo una
ventaja por darle una característica intuitiva para el desarrollo de aplicaciones, luego la programación
puede ser llevada a cabo por personas incluso con pocas experiencias en este campo.

[figura 8] Panel frontal instrumento virtual

[figura 9] Código fuente instrumento virtual

  24  
Para este proyecto la necesidad de establecer una comunicación con un equipo remoto mediante el uso de
un protocolo es necesario el conocimiento de características de aplicación en este campo con LabVIEW.

2.4.2 Comunicación de datos


LabVIEW tiene funciones especificas para comunicación en red, por lo que la adquisición de datos y el
monitoreo remoto se simplifica en su lenguaje de programación a través de los distintos bloques
funcionales que se tienen según el protocolo de comunicación.

Ciertas ventajas llevan a LabVIEW en una buena opción en desarrollo de aplicaciones donde es
necesario funciones de comunicación. Soporta tiempos largos y grandes capacidades de muestreo de
datos, lo cual se traduce en ventajas como la alta precisión en las medidas y captura de datos, así como la
facilidad en su operación. En particular la comunicación mediante el protocolo TCP/IP es soportado, el
proceso de transmisión de datos tiene el mismo comportamiento señalado anteriormente a través de
bloques específicos, los cuales se pueden observar en la [Figura 10]. [10]

[Figura 10] funciones para comunicación protocolo TCP/IP LabVIEW

Mediante cada uno de estos bloques es posible establecer la comunicación entre dos puntos, además la
posibilidad de escritura y lectura de datos en la red. Las características especificas de cada uno de estos
bloques y explicaciones de su funcionamiento se pueden encontrar en [11].

2.4.3 Enlace con bases de datos

Para establecer la conexión con la base de datos que se requiere se contemplaron diferentes posibilidades
que fueron útiles en proyectos anteriores para aplicaciones en las cuales se desea tener tanto acceso a una
base datos como la modificación de estas desde LabVIEW®, las cuales son las siguientes [12]:

- El uso de interfaz DLL (dynamic link library) para acceder indirectamente.


- El uso de tecnología DDE (dynamic data exchange) disponible en sus funciones.
- El uso de tecnología ADO (ActiveX Data Exchange) para acceder usando lenguaje SQL

  25  
- El uso de paquetes gratuitos como LabSQL
- El uso de NI company special database access toolkit Database Connectivity Toolkit.

Los tres primeros son considerados como de bajo nivel y mas complejos de operar, el cuarto en cambio es
de gran popularidad por su facilidad de uso además de ser una opción gratuita disponible en la red. El
quinto método es la opción predilecta cuando se dispone de un capital de inversión para disponer de la
herramienta. Desarrollada por National Instruments específicamente para aplicaciones en las cuales las
bases de datos juegan un papel importante. La versión de LabVIEW en la cual se desarrollo gran parte
de este trabajo de grado se disponía de este paquete de funciones. Por otra parte opciones como LabSQL
fueron utilizadas anteriormente arrojando resultados exitosos por lo que se mantuvo como una segunda
opción.

Database Connectivity Toolkit usa lenguaje SQL para acceder, modificar y ver información en una base
de datos. Estas “líneas de datos” son ejecutadas a través de una tecnología Microsft, OLE DB (object
linking and embedding database) que permite la comunicación entre LabVIEW y la base de datos. Dentro
de LabVIEW nodos hacen un llamado a ActiveX Data Objects (ADO). ADO conectara luego con la base
de datos según un DSN o UDL [13]

Para entrar a modificar determinada base de datos, LabVIEW permite llevar un proceso de conexión,
inserción de información y desconexión con la base de datos especificada por usuario a través de VI`s que
se pueden observar en la [Figura 11]

[Figura 11] funciones Database Connectivity Toolkit

Luego, el proceso consiste en establecer la conexión con la base de datos mediante DB Tools Open
Connection.vi a través de un sistema DSN, un archivo DSN o el UDL. Después desarrollar operaciones en
la base de datos como escritura de información o actualización de archivos mediante DB Tools insert.vi
finalizando con el proceso la desconexión de la base de datos DB Close Connection.vi. [Figura 12].

  26  
[Figura 12] Proceso modificación base de datos

  27  
3. DESCRIPCIÓN GENERAL Y ESPECIFICACIONES

En este capitulo se lleva a cabo una descripción detallada de la aplicación para el control de las tareas, y
demás características desarrolladas para el control supervisorio del robot.

En este proyecto se desarrolló una aplicación para el control de la ejecución de tareas de manipulación de
material del robot Mitsubishi MELFA RV-2A instalado en el CTAI de la Pontificia Universidad Javeriana
de Bogotá. Para esto, se necesitó del desarrollo de dos programas conjuntos de ejecución simultanea, uno
en el robot y otro un instrumento virtual desarrollado en LabVIEW comunicados vía TCP/IP haciendo
uso de las instalaciones actuales en el sistema de manufactura. El diagrama en bloques de cada uno se
muestra a continuación.

[Figura 13] Diagrama en bloques herramienta principal LabVIEW®

[Figura 14] Diagrama en bloques Programa robot

Para su funcionamiento primero se establece una comunicación entre el robot y la herramienta


desarrollada en LabVIEW®. Una vez esta comunicación ha sido exitosa, el usuario selecciona la tarea a
realizar y una instrucción asociada a este movimiento requerido es enviada al robot. El robot lee esta
instrucción y analiza el movimiento generando una alarma en caso de ser un movimiento invalido, es decir
el transporte de material no disponible, o ejecuta la tarea con una confirmación de este movimiento.
Cualquiera de estas dos respuestas es analizada por la herramienta para generar la alarma correspondiente
o seguir en el proceso de asignación de tareas. Diferentes datos de interés son almacenados en una base de
datos al terminar cada tarea.

  28  
3.1 Apariencia de la herramienta

La herramienta principal desarrollada en LabVIEW [Figura 15] consta de una ventana principal la cual
tiene un listado de materiales y los diferentes lugares para ser transportada dicha pieza. Además está en
capacidad de tener una visualización del estado de la estación de trabajo del robot mediante el uso de la
instrucción “status”, es decir información de lectura de sensores es mostrada. A través de esta, el usuario
tiene conocimiento de la presencia de material o no para ser transportado por el robot, información
actualizada útil y de la cual no se dispone en la actualidad. Tiene un indicador de conexión con el robot y
un botón “Start” para la ejecución de las tareas. Además datos relacionados como numero de tarea
realizada y su tiempo de ejecución. Finalmente un indicador de alarma relacionado a una tarea invalida.

[Figura 15] Ventana principal

3.2 Sistema de alarmas

La herramienta dispone de un sistema de alarmas el cual es activado una vez se ha generado una
asignación de tarea invalida, es decir un transporte de material el cual no es reconocido por el sistema.
Señales adquiridas de sensores instalados en la estación de trabajo del robot, se analizan en el evento de
una tarea requerida de material no disponible o sin lugar para ser ubicado, generando una alarma con el
mensaje respectivo asociado al error. La alarmas consisten en ventanas emergentes que necesitan del
reconocimiento del operador para seguir siendo utilizada la aplicación.

  29  
3.3 Base de datos

Como característica importante en todo control supervisorio, la generación de históricos para análisis
posteriores o a manera de registro, la aplicación cuenta con una conexión a una base de datos la cual es
modificada en el transcurso de su operación teniendo un histórico de movimientos generados así como las
alarmas generadas.

La base de datos contiene diferentes datos importantes en la ejecución de tareas con el robot. [Figura 16]

[Figura 16] Base de datos

o Task Number: numero de tarea correspondiente. Una vez es inicializada la aplicación las
tareas son contadas con incrementos en una unidad.
o Instruction: código de la tarea que ha sido realizada o la cual se ha querido realizar. Para su
interpretación tiene la posición inicial y posición final, separados por la palabra TO. Su
significado movimiento desde posición inicial a posición final.
o Date task: fecha en la cual tuvo lugar la tarea, en el formato día – mes – año.
o Start time: hora en la cual se llevo a cabo dicha tarea en formato horas – minutos – segundos.
o Type: tipo de mensaje que ha sido generado por el sistema, ya sea una alarma generada o un
movimiento valido por el robot.
o Work time: tiempo de trabajo en la ejecución de dicha tarea por parte el robot
o Message: mensaje generado por la alarma asociado al movimiento invalido o en caso de ser
un movimiento valido un mensaje de confirmación de movimiento.

  30  
3.4 Programa robot

Por otra parte en el robot se llevó a cabo un programa el cual se pudiera establecer comunicación con la
aplicación y así esperar por las instrucciones a realizar, estas instrucciones son las tareas de movimiento
de material entre diferentes puntos de la estación que se explican en detalle en el capitulo 4.3 de este
documento, movimientos entre posiciones que fueron enseñadas al robot mediante una programación
manual, acercando el robot a las posiciones deseadas y grabándolas haciendo uso del teach-pendant.

En el robot se dispone del programa correspondiente desarrollado para la ejecución de las tareas, SG1, el
cual lo componen dos archivos. Un archivo .mb4 el cual contiene el programa desarrollado con el
conjunto de movimientos para la ejecución de tareas. Por otra parte un archivo .pos el cual contiene los
diferentes vectores creados para guardar las distintas posiciones en las cuales el robot se mueve
dependiendo de la tarea asignada.

  31  
4. DESARROLLOS

Para el desarrollo de la herramienta se definió una metodología dividida en 5 fases dependientes, con el
fin de alcanzar los distintos objetivos propuestos en el proyecto. En la [Figura 17] se muestra el diagrama
de la metodología utilizada

Documentación  y  revision  del  estado  de  arte  

Revision  de  manuales  del  robot   Comunicación  mediante  LabVIEW   Con?iguración  y  conexión  actuales  de  FMS  

Establecimeinto  de  comunicación  

De?inición  de  protocolo  de  comunicacion   Com  cliente/servidor  en  LabVIEW  TCP/IP   Com  LabVIEW  -­‐  controlador  robot  TCP/IP  

Desarrollo  programa  robot  


De?inición  de  tareas  y  codigo  de   Lectura  de  censores  de  la  celda  de  
instrucciones   Lectura  de  instrucciones  por  el  robot   trabajo  y  con?iguración  de  alarmas   Con?iguración  programa  Robot  

herramienta  principal  LabVIEW  


Diseño  interfaz  de   Envio  instruccion  y  
usuario   Inicio  de  comunicacion   Seleccion  de  instruccion   lectura  respuesta     Analisis  de  respuesta   Conexion  Base  de  datos    

Mejoras  aplicacion  y  pruebas  ?inales  


Herramienta  principal   Programa  robot  

[Figura 17] Metodología del proyecto

Después de la revisión previa señalada anteriormente en el marco teórico de este documento tanto
manuales de funcionamiento del robot [6][7], como experiencias en trabajos de comunicación de datos
mediante LabVIEW [4][10][19][20], se adelanta en el proceso del desarrollo de la herramienta.

4.1 Definición de protocolos de comunicación:

En una primera fase del proyecto el establecimiento de la comunicación con el robot definiría la base
sobre la cual los diferente desarrollos tanto en el robot como LabVIEW tomarían lugar. Para ello el
estudio de las conexiones existentes con el robot y las posibilidades de comunicación con este permitirían
definir tanto la conexión física como el protocolo de comunicaciones a utilizar.

La FMS tiene configurada una red interna Ethernet a través de un switch de comunicaciones [Figura 18].
Los tres computadores con sus respectivas direcciones IP tienen conexión con el robot vía Ethernet, el

  32  
tercer computador con dirección IP 10.21.7.10 es el computador destinado para el desarrollo de este
proyecto. Además existe la conexión vía RS-232 del primer computador, conexión utilizada en la
actualidad por el software COSIMIR CONTROL para comunicarse con el controlador del robot.

[Figura 18] Topología de red FMS

La posibles soluciones para la comunicación entre la aplicación LabVIEW y el controlador del robot se
reducen a tres, las cuales son las siguientes:

CR1-571

RS-232 I/O
Ethernet – TCP/IP

Comunicación actual con el


Protocolo actual controlador
Es orientado a la adquisición
de señales de perifericos,
ejemplo sensores en la celda
de trabajo.
seguridad recepcion de
tramas
Se deben tener ciertos
parametros extras a
configurar

Mayor velocidad de
transmisión de datos

[Figura 19] Posibilidades de comunicación robot

  33  
La primera opción utilizando protocolo TCP/IP y las conexiones existentes del FMS mediante la tarjeta de
Ethernet del robot. La segunda opción, utilizar la conexión existente con la estación base vía RS-232 y la
tercera opción mediante su conector DB32 de señales entrada/salida que dispone el robot. Esta ultima
opción es reservada para conexión de periféricos del robot y utilización de ciertas señales en la ejecución
de sus tareas, como por ejemplo sensores en su pinza y sensores en la celda de trabajo como es el caso
actual. Luego se redujo a dos opciones de comunicación. Utilizando su interfaz Ethernet sería una primera
opción ya que no se encuentran antecedentes de una comunicación de este tipo con robots de esta familia
y se permite una velocidad de transmisión de datos mucho mayor. Como protocolo de transporte y red,
TCP/IP, un protocolo confiable el cual no se esperaría una perdida de tramas de datos en la ejecución de la
aplicación, además un protocolo actual de gran uso en redes como Internet. En este orden de ideas se
definió el modelo a seguir [Figura 20] para el desarrollo del cliente en el robot y una posible
comunicación con el servidor LabVIEW®, en la cual se desarrolla una aplicación gracias a el modo de
comunicaciones DataLink, y llevando a cabo la configuración correspondiente permitiendo el uso de los
protocolos definidos.

DL  
mode  
TCP-­‐IP  

Ethernet  

[Figura 20] Modelo cliente

Paralelamente se define el modelo de la herramienta del control de tareas en LabVIEW® (servidor) para
establecer una conexión y permitir el flujo de datos bidireccional mediante el protocolo de
comunicaciones [Figura 21].

  34  
[Figura 21] Modelo de comunicación –Servidor/cliente

4.2 Establecimiento de Comunicación:

Uno de los objetivos del proyecto era el poder establecer comunicación con el robot, el cual a partir de las
posibilidades de conexión existentes a nivel de hardware y la lectura previa de sus respectivos catálogos,
se desarrollo un modelo y distintas pruebas para concluir con la comunicación exitosa entre un
instrumento virtual configurado en LabVIEW® y el robot.

Para la comunicación se determino un modelo cliente/servidor entre dos terminales en donde fuera posible
el envío y recepción de datos que serán de uso posteriormente en el desarrollo de la aplicación con el
robot.

Primero era indispensable saber que la red interna del CTAI permitía un desarrollo del proyecto desde uno
de los computadores destinados a trabajos de grado y grupos de investigación del departamento. Es decir
que se contaba con conexión a la red y a su vez a el robot desde uno de estos computadores, para esto se
hizo uso del comando PING6 para la evaluación de envío y recepción de paquetes con la dirección IP
requerida. La conexión satisfactoria se muestra a continuación.

                                                                                                               
6  PING
utilidad para el diagnositoco de redes en el cual se envian paquetes ICMP de solicitud analizando la
respuesta, verificando asi la conexión.

  35  
[Figura 22] verificación de conexión en red

Con la seguridad de conexión entre estos se comenzó a desarrollar un servidor en LabVIEW® el cual
recibiera la solicitud de comunicación por parte de un cliente y respondiera con una trama de datos. Para
tener certeza de un servidor en funcionamiento y en el cual nos basaríamos para la futura conexión con el
robot, se decidió establecer una conexión Cliente/servidor a través de dos instrumentos virtuales.

4.2.1 Diseño servidor y cliente en LabView®

La comunicación a través de dos instrumentos virtuales se desarrollo simulando el tipo de comunicación


que se deseaba establecer entre el controlador del robot y LabVIEW. Lo anterior además de lograr el
servidor base para la aplicación, conocer acerca de la estructura de las tramas, el manejo de los datos por
parte del software y el funcionamiento de las herramientas disponibles para comunicación de datos en su
menú de funciones. La comunicación buscaba el envío de un dato de un instrumento virtual haciendo las
veces de servidor a otro en la red que solicitaba su conexión haciendo las veces de cliente. Los
computadores usados fueron los mismos de la red interna del CIM del CTAI de la universidad por lo que
configuración de una red no fue necesaria, además se disponía del software en versiones actuales en
ambos computadores por lo que la instalación tampoco era necesaria.

Primero, se diseño un cliente el cual solicita conexión con un servidor mediante el bloque TCP connection
con la dirección IP y puerto especifico [Figura 23] para este caso 10.21.7.9 y numero de puerto 10008. Se
espera por una respuesta del servidor y una vez se establezca la comunicación, el cliente lee los datos a
través de los dos bloques TCP read (1 en [Figura 23]).

  36  
[Figura 23] Base de cliente LabVIEW
Para el diseño del servidor, se necesita responder a la solicitud de conexión por parte del cliente, para esto
el uso del bloque TCP listen el cual escucharía por cierta conexión en el puerto especificado. Al realizarse
la conexión responde con una trama de datos donde el dato a enviar en este caso corresponde al numero
“20”. Para el correcto funcionamiento se restringe el numero de bytes a leer por el cliente, enviando
primero la longitud del dato “20” (es decir 2)7 y luego el dato, esto para limitar el numero de bytes de
lectura por parte del cliente. Con esta configuración fue posible la lectura del dato en el cliente terminando
con el proceso de comunicación esperado.

[Figura 24] Base de servidor LabVIEW

Como gran avance en el proceso del desarrollo del proyecto se conoció acerca del funcionamiento de
bloques para comunicaciones TCP/IP, en los cuales es de gran importancia restringir el número de bits a
leer ya que de esta manera se limita el proceso de lectura y así su funcionamiento, las lecturas erróneas en
estas pruebas fueron resultado a lecturas de datos aleatorios presentes en la red los cuales con la anterior
restricción fueron superadas.

                                                                                                               
7  LabVIEW® utiliza un byte para el envio de un dato en la red en codigo ASCII, en este caso el envio de el numero
20 necesita de dos bytes.  

  37  
Con un servidor base para la aplicación y la certeza de su funcionamiento se paso a establecer la
comunicación con el controlador del robot, donde la configuración de cliente por parte del robot y algunas
modificaciones en el servidor eran necesarias.

4.2.2 Comunicación TCP/IP servidor LabVIEW – Cliente controlador CR1-571 robot Melfa RV-2A

Ya con un servidor base en funcionamiento configurado se procede a la comunicación con el controlador


del robot base para el desarrollo de la aplicación. Basados en la arquitectura ya existente se configuraron
los distintos parámetros para una comunicación TCP/IP a través de su tarjeta Ethernet. Comunicación
exclusiva por uno de sus puertos con el equipo en donde se desarrolla la aplicación del servidor. Los
parámetros configurados y sus valores correspondientes se muestran en la [Tabla 2]. Con esta
configuración es posible la comunicación con el controlador a través de su modulo Ethernet utilizando los
comandos MELFA BASICIV para comunicación con periféricos, por medio de su puerto 8 de
comunicaciones, en modo cliente y estableciendo una comunicación punto a punto con un servidor de
dirección IP 10.21.7.10 que es el computador en donde se creara un servidor y por el cual se enviaran las
diferentes instrucciones para el control de la ejecución de tareas en el robot.

COMDEV(8) OPT18

NETHSTIP(8) 10.21.7.10

NETMODE(8) 0

CPRCE18 2

NETHSTIP(8) 10.21.7.10

NETPORT(9) 10008

[Tabla 2] Parámetros configurados en controlador

Los pasos para llevar esta configuración se muestran en el ANEXO 2 de este documento. Con esta
configuración es posible habilitar los comandos MELFA-BASIC IV para aplicaciones de comunicación de
datos. Haciendo uso de estos comandos se configuro además un primer programa cliente prueba para
comunicación con el servidor, en donde una señal de START es enviada como señal de petición de
comunicación, el servidor en LabVIEW® luego esperará esta señal para enviar un numero el cual
dependiendo de su magnitud, el dato se devuelve o no. Como el puerto de comunicación modificado para
comunicación exclusivamente con el servidor de dirección IP 10.21.7.10 fue el 8, el programa fue el
siguiente:

  38  
[Figura 25] programa cliente para comunicación en robot

Utilizando el servidor base que se desarrollo para la comunicación entre los dos PC´s, y ciertas
modificaciones, como la espera de la señal START para el inicio de información, se logra una
comunicación entre LabVIEW y el controlador del robot.

[Figura 26] servidor comunicación con robot

Después de haber sido establecida la comunicación entre el robot y LabVIEW®, se continuó con la
metodología definida en donde los pasos a seguir serían los distintos desarrollos tanto en el robot como
LabVIEW® y así alcanzar los siguientes objetivos propuestos para el desarrollo de la aplicación. Para el
establecimientos de las tareas fue necesario el conocimiento de la estación de trabajo del robot, su
programación y la definición de un código de instrucciones para la ejecución de ellas.

  39  
4.3 Definición tareas y código de instrucciones

En la [Figura 27] se puede observar la estación de trabajo del robot. Ciertos movimientos son solo
utilizados como una tarea de transición entre la banda transportadora y el robot, ya que por ejemplo el
movimiento de un cilindro que está en almacén y viene en la banda transportadora para ser analizado en la
estación de calidad, deberá primero moverse junto con su pallet en el cual es transportado a la estación
Pallet 1 o Pallet 2 y finalizar con el movimiento del cilindro a la estación de calidad.

[Figura 27] estación robot

Las tareas requeridas que deben ser realizadas por el robot como objetivo pensando en la integración de la
aplicación en un control global del FMS para simulación de procesos de manufactura son las siguientes:

  40  
-­‐ Transporte de pallet entre la banda transportadora y la estación Pallet 1 y Pallet 2 respectivamente.

-­‐ Transporte de cilindros para el análisis en la estación de calidad, teniendo en cuenta que los
cilindros pueden estar ubicados en algún pallet.

-­‐ Transporte de barras entre su estación de almacenamiento y los pallet como un punto de transición
con la banda trasportadora.

-­‐ Transporte de botellas para ser analizadas en estación de calidad, al igual teniendo en cuenta que
pueden estar ubicados en los pallet como un punto de transición con la banda transportadora.

Para definir las instrucciones se relacionó con un número cada uno de los puntos de la estación
considerando las posibilidades de diferentes tipos de material en un punto. La instrucción de movimiento
entre estos dos puntos será entonces el par ordenado (source, terget), punto de inicial y final de
movimiento. Esto se puede observar en las [Tabla 3]

Elemento Estación Código


Pallete Banda transportadora 10
Pallete 1 1
Pallete 2 2
Barras Almacenamiento barras 5
Pallete 1 6
Pallete 2 7
Cilindros Pallete 1 3
Pallete 2 4
Almacenamiento cilindros 8
aluminio
Almacenamiento cilindros 9
bronce
Control de calidad 11
Botellas Pallete 1 12
Pallete 2 13
Estación botellas 14
Calidad 15
[Tabla 3] Definición de instrucciones

Se define el código de la instrucción como la abreviación del movimiento realizado por el robot, de fácil
interpretación. Consiste en el punto inicial y final de movimiento separados por la palabra “TO” indicando

  41  
dirección de movimiento. es decir movimiento desde la posición inicial a posición final.
“P”SOURCE“TO”“P”TARGET, por ejemplo para un movimiento requerido de un pallete de la posición
Banda transportadora a estación Pallet 1, el código de la instrucción asociado a este movimiento
correspondiente es P10TOP1.

4.4 Lectura y envío de instrucciones:

En esta etapa del proyecto era necesario poder tener lectura de las instrucciones por parte del robot para
seguir en el desarrollo del mismo, por lo que era necesario un primer programa de prueba para la lectura
de estas instrucciones y el envío del código de la instrucción por parte del robot. Teniendo los adelantos en
la comunicación ya establecida entre robot y LabVIEW® se diseña un programa el cual permitiera la
lectura de la instrucción en dos variables, es decir el par (SOURCE,TARGET) fuera leído en dos variables
que serian de uso posterior en el desarrollo de un programa en el robot el cual ejecutara ciertos
movimientos según el valor de estas. Por facilidad se definieron con el mismo nombre. Además, se
necesitaba un tipo de comunicación bidireccional, para esto el programa devolvería el código de la
instrucción como verificación de la lectura correcta. La instrucción sería enviada desde el servidor ya en
funcionamiento con diferentes pruebas para varias instrucciones. La secuencia del programa se muestra en
el diagrama de flujo de la [Figura 28] junto a las salidas en el panel frontal del VI servidor para varias
instrucciones enviadas. Las líneas de código de programa en el robot se muestran en el ANEXO 4.

[Figura 28] Secuencia de programa en robot lectura instrucciones e instrumento virtual

  42  
4.5 Lectura de sensores de la estación de trabajo y configuración de alarmas

Para la validez de una instrucción enviada por usuario era necesario corroborar cierto movimiento a través
de los diferentes sensores instalados en la estación de trabajo, es decir el estado de las señales de los
sensores de los diferentes puntos de almacenamiento de material de la estación validarían cierto moviendo
o se generaría un evento de alarma. En la [Figura 27] las estaciones Barras, Cilindros Aluminio, Cilindros
Bronce, Pallet 1 y Pallet 2 se tienen instalados sensores capacitivos para la identificación de piezas
metálicas en ellos.

Las señales provenientes de estos sensores son parte de las señales entrada/salida que dispone el
controlador, pero lastimosamente no se encontraba documentación disponible para ello. De esta manera se
investigó específicamente por la ubicación y el poder acceder a estas señales. Como se especificó
anteriormente un total de 16 señales de entrada y 16 de salida dispone el controlador, las cuales para poder
leer cada una de estas se necesita a través de un programa definir cada una de estas señales. Después de
analizar ciertos programas en el robot, las señales de interés se observan en la [Tabla 4].

En el proceso del diseño del programa cliente en el robot para la aplicación, se desarrolló una rutina en
donde a respuesta a una nueva instrucción especifica de estatus (1,0) se enviaría el “Status” o estado de
cada uno de estos sensores, de igual manera, a respuesta de las instrucciones de movimiento ya definidas
se validaría este movimiento a través del estado de los sensores, devolviendo el código de la instrucción
para un movimiento valido o una alarma con un mensaje relacionado a el movimiento invalido (ver [Tabla
5]).

Tipo Numero Sensor estación Señal


Bit 8 Pallet 1 1 = material
0 = no material
Bit 9 Pallete 2 1 = material
0 = no material
Bit 10 Cilindros bronce 1 = material
0 = no material
Bit 11 Cilindros aluminio 1= material
0 = no material
Bit 12 Barras 1 = material
0 = no material
[Tabla 4] Señales de sensores en el controlador CR1.

  43  
[Tabla 5] Código de alarmas.

La rutina programada en el robot a manera de diagrama de flujo se muestra en la [Figura 29]. El conjunto
de líneas de código en ANEXO 5.

[Figura 29] Diagrama de flujo ejecución de alarmas

4.6 Configuración programa Robot

Con los adelantos llevados a cabo especificados en las etapas anteriores, el programa principal en el robot
se basaría en un establecimiento de la comunicación y luego una etapa de lectura de las instrucciones,
dependiendo del código de esta instrucción la ejecución de determinada tarea de manipulación de material
o la generación de una alarma asociada a un movimiento invalido.

  44  
4.6.1 Configuración establecimiento de comunicación y recepción de instrucciones

Como lado cliente de la comunicación, el robot iniciaría por lo tanto el proceso de comunicación con la
apertura de su respectivo puerto de comunicaciones a la espera de las instrucciones enviadas desde la
aplicación (servidor), el programa se representa por el diagrama de flujo de la [Figura 30].

Siguiendo con la jerarquía definida por el lenguaje de programación MELFA BASICIV definido
anteriormente, primero se define las señales de entrada y salida las cuales serán necesitadas para la
ejecución del programa y vectores de posición a ser enseñados manualmente a través del teach-pedant.
Luego de esto, se encienden los servos del robot y la apertura de su puerto de comunicaciones ya
configurado. Con lo anterior el robot esta listo para la ejecución de tareas y recepción de instrucciones por
parte de la aplicación en el servidor. Esperará por la instrucción determinada y según esta seguirá su
ejecución.

[Figura 30] Establecimiento de comunicación y recepción de instrucciones

4.6.2 Configuración tareas

El robot según la instrucción enviada seguirá determinado código correspondiente a la opción deseada por
usuario, es decir el grupo de movimientos que darán como resultado la ejecución de una tarea. La
configuración de los movimientos del robot se llevo a cabo siguiendo igualmente el esquema definido por

  45  
su propio lenguaje de programación definido anteriormente. Fue necesario la enseñanza de las posiciones
tanto SOURCE como TARGET para cada una de las tareas, además de ciertas posiciones para seguridad
del robot que se explicaran a continuación.

Según el código de instrucciones definido anteriormente, las tareas están diferenciadas según el material a
ser manipulado por el robot. Es decir movimiento de pallet, barras, cilindros o botellas.

-­‐ Movimiento de pallet:

El diagrama de flujo se muestra en la [Figura 31], en donde se define un valor entero el cual será la
distancia de seguridad a la cual el robot se sitúa antes de coger (PICK) o soltar (PLACE) la pieza en
un movimiento. Con estos valores definidos comienza la ejecución de movimientos que dan como
resultado el movimiento de pallet desde y hacia las posiciones requeridas.

[Figura 31] Movimiento pallet

  46  
-­‐ Movimiento de barras:

De manera análoga, se define las longitudes de seguridad para el agarre o ubicación de las barras. Los
métodos de sujeción en la estación de almacenamiento de barras son diferentes de la sujeción cuando
estas son manipuladas en los pallet, es necesario un cambio de sujeción de la pieza para ejecutar la
tarea correctamente. Para esto, se dispone de una estación de transición solo para efectos de cambio
de sujeción de la pieza.

Se diseña un programa el cual dependiendo del par (SOURCE,TARGET) es diferente la ejecución de


movimientos por lo que en casos será necesario el cambio de sujeción de la pieza [Figura 32]. Si la
posición SOURCE es 6 o 7, el agarre de la pieza es por su parte posterior por lo que no se necesita
cambio de sujeción si se desea mover a un siguiente pallet. Debido a que la estación almacenamiento
de barras la sujeción es frontal, el transporte a uno de los pallet y viceversa necesita de una cambio de
sujeción. La estación cambio de sujeción se denota como POSITION(change), paso intermedio entre
el destino y punto final de la pieza.

- Movimiento de cilindros:

El transporte de cilindros se puede observar en el diagrama de flujo [Figura 33], en el cual el análisis
de estos en la estación de calidad hacen de un nuevo movimiento a desarrollar. Ya que es una estación
que se encuentra a las espaldas del robot, para su ejecución es de gran importancia un correcto giro
para efectos de seguridad del robot como la pieza. Para esto se crea un a posición de seguridad de giro
antes de dirigirse a esta estación. Al igual que la configuración de las tareas anteriores se definen
distancia de seguridad de agarre y ubicación de la pieza para una correcta ejecución de movimiento.

  47  
[Figura 32] Movimiento de barras

  48  
[Figura 33] Movimiento de cilindros

- Movimiento de botellas

La necesidad del transporte de botellas para su análisis en la estación de calidad es necesario al


igual un movimiento de giro. Similar a la programación de tareas anteriores se definen distancias
de seguridad tanto de agarre como de ubicación de la pieza a transportar. La ejecución de
movimientos para una tarea se observa en el siguiente diagrama de flujo.

  49  
[Figura 34] Movimiento de botellas

Después de terminada la ejecución de la tarea hace un salto para la espera de una nueva instrucción para la
asignacion de una tarea determinada, cerrando así el ciclo.

Después de los diferentes desarrollos realizados en el robot la siguiente fase son lo adelantos necesarios en
la estación de envío de las instrucciones esperadas por el robot para la ejecución de sus movimientos, la
herramienta principal elaborada en LabVIEW®. Para esto de gran importancia el diseño de una interfaz a
usuario de fácil asimilación por parte de un operario.

  50  
4.7 HMI

El diseño de la interfaz con el usuario era una etapa importante en el desarrollo de la aplicación debido a
que el éxito en la ejecución de las tareas del robot dependerá de que tan bien haya sido diseñado este en
las etapas previas. Por ello se consideró la posibilidad de una interfaz en donde se restringiera la escritura
de las instrucciones a realizar, una interfaz inteligente y funcional de fácil interpretación por parte de el
usuario. LabVIEW® permite diferentes posibilidades con indicadores, tablas y listas en forma de árbol.

Las tareas por parte del robot se reducen en una ejecución pick and place8, por lo que una lista en donde se
especifique el origen y el objetivo de movimiento fue la mejor opción. Igualmente, este movimiento esta
diferenciado por el material a ser transportado por lo que la primera opción a escoger seria el material a
transportar. En este orden de ideas la interfaz usuario tomó la representación que se puede observar en la
[Figura 35]. Primero el usuario encuentra una lista con los diferente materiales a ser transportados por el
robot, luego dependiendo de la opción requerida las diferentes opciones en las cuales se puede recoger
dicha pieza terminando con la posición objetivo o final a ser transportado.

[Figura 35] Lista de tareas posibles

Debido a la posibilidad de tener el status de la celda de trabajo del robot a través de la lectura de los
sensores instalados, se añaden indicadores lógicos los cuales un color amarillo correspondería a la
presencia de material para ser transportado o la no disponibilidad de la estación para recibir una pieza, de
lo contrario la no disponibilidad de material para ser transportado o la posibilidad de ubicar material en
dicha estación [Figura 36].

                                                                                                               
8  pick  and  place  esta  definido  al  tipo  de  taras  en  robotica  industrial  en  donde  se  reducen  a  un  movimiento  de  

recoger  y  ubicar  piezas  

  51  
[Figura 36] Status de la celda de trabajo

4.8 Aplicación

La etapa de implementación de la aplicación se ha diseñado con base en los resultados obtenidos en las
etapas anteriores, configurando un sistema el cual envíe diferentes tipos de instrucciones según las tareas a
efectuar por parte del robot. Además la posibilidad de visualizar por pantalla el estado de la celda de
trabajo del robot a partir de sus sensores instalados.

Era necesario tener un control de históricos de movimientos así como las diferentes alarmas generadas en
la utilización del robot, por lo que se creo una base de datos a ser modificada desde la aplicación a manera
que se generen las diferentes tareas.

El diagrama en bloques se puede observar en la [Figura 37], en el cual como primero se inicializa la
comunicación a la espera de conectarse con el robot. Una vez establecida la comunicación el robot se
encuentra a disposición para la recepción de instrucciones y ejecución de ellas según corresponda, en la
aplicación una de las opciones es escogida. Para el envío de la instrucción se pulsa la señal de START en
el panel frontal de la aplicación. Esto permitirá el envío de la instrucción por alguno de los bloques
designados a ello, como un ejemplo el envío de la instrucción (1,2) correspondiente al movimiento de
pallete de la posición Pallet 1 a Pallet 2. Una vez se envíe cierta instrucción se espera la respuesta del
robot, ya sea la ejecución de la tarea o el código de error generado. Al leer esta respuesta el sistema activa
variables para el control de la escritura de los datos en la base de datos y se ejecuta el subVI
correspondiente, además dado un evento de alarma se visualiza en pantalla el error relacionado. El sistema

  52  
vuelve y espera por una nueva selección de tarea a ejecutar o terminar con la ejecución de este pulsando
STOP.

[Figura 37] Diagrama en bloques herramienta principal LabVIEW®

4.8.1 Establecimiento del enlace

Se define el puerto por el cual se establece la comunicación de acuerdo a la configuración hecha en pasos
anteriores en el robot [Tabla 2] el puerto es el 10008, y espera por la señal de START, en este momento
hay una indicación a usuario que se ha establecido la comunicación. Esta señal es utilizada para el control
del envío de las instrucciones (1)

[Figura 38] Establecimiento del enlace

4.8.2 Selección de instrucción

Cada una de las opciones es comparada con el TAG – identificación generado por LabVIEW® para cada
opción, la ejecución de esta opción dependerá entonces de la señal (1) y una señal de control de usuario
“start”.

  53  
[Figura 39] Selección de instrucción

4.8.3 Envío de instrucción y recepción respuesta robot

Una vez es confirmado el envío de datos, el bloque de envío de instrucción se activa mandando el código
de la instrucción de la opción requerida, para este caso (1,2). Después de un envío correcto el FLAT
siguiente espera por la lectura de la respuesta del robot a esa instrucción (2).

[Figura 40] Envío de instrucción y recepción respuesta robot

4.8.4 Análisis respuesta

El dato leído es analizado en caso de alarma, dependiendo de su valor es un error en la opción requerida
por usuario. En esta etapa además, variables locales del programa toman valores, como el control de la
escritura en la base de datos y el mensaje a ser enviado.

[Figura 41] análisis de respuesta

  54  
4.8.5 Conexión base de datos

Primero fue necesario la creación de una base de datos la cual iba a ser modificada por la aplicación.
El conjunto de datos históricos que se desean guardar en la base de datos tienen relación con la tarea que
se esta realizando, identificado por el código de la instrucción, adicionalmente la fecha y hora a la cual se
ha realizado la tarea como el tiempo determinado de esa ejecución. Debido a que el sistema cuenta con un
sistema de alarmas el cual es activado si se especifica una tarea invalida por usuario también era necesario
el envío de este dato. Se crea entonces una base de datos a ser modificada desde labVIEW® por DB insert
data VI.
Para la conexión con la base de datos y llevar a cabo la modificación, fue necesario del desarrollo de un
subVI llamado Database [Figura 42] el cual recibiría los datos a modificar desde la aplicación principal.

[Figura 42] VI Database

  55  
Para la modificación de la base de datos se especificó la ruta del archivo guardado en el mismo
computador, además el nombre de la tabla a ser modificada y las columnas definidas con el mismo
nombre que fueron creadas en la base de datos previamente para evitar errores. [Figura 43]

[Figura 43] Entradas VI Database

4.9 Mejoras de la aplicación

4.9.1Herramienta principal LabVIEW®

Finalmente debido a la redundancia de ciclos para el envió de los datos correspondientes a la instrucción a
realizar se decidió realizar un bloque general para ello. En la [Figura 44] se observa el bloque general para
envío de instrucciones en donde las variables globales S/T toman los distintos valores que se especificaron
anteriormente para source/target.

[Figura 44] Mejoras selección y envío de instrucción

  56  
Ejecutando varias pruebas se presenciaban ciertas demoras en la generación de alarmas lo cual fue
solucionado desarrollando una lógica de control sobre el tiempo de funcionamiento del bloque de lectura
TCP. En la [Figura 45] se observa los desarrollos en el bloque para finalidades de lectura y activación de
alarmas, además de habilitar el control para la escritura de los datos en la base de datos. La lectura de
datos fue limitada dependiendo del numero de bytes esperados a leer, donde fue necesario cambiar el
modo de lectura del bloque TCPread a inmediato, en este los bytes de salida toman valores tan pronto se
leen por el bloque, de otra manera seria necesario señales de sincronismo o esperar por tiempos los cuales
para nuestro caso no era viable debido a la variación de los tamaños de los batos a leer y la variación de
los tiempos de ejecución de las tareas. Con esto la aplicación era independiente de la tardanza para obtener
un dato y escribirlo en una variable, para así depender tan solo del tiempo de ejecución de una tarea o la
generación de una alarma por parte del robot.

Por otra parte se presentaban errores en los mensajes guardados en la base de datos cuando era generada
una alarma, para su solución se decidió añadir un bloque lógico para el caso de una alarma generada e
independizar la lectura de error con la generación de la alarma.

[Figura 45] Mejoras bloque lectura, generación de alarmas y control de escritura base de datos

La apariencia del panel frontal con el cual tiene contacto el usuario se modifico para tener un mejor
aspecto y diseño acorde a una aplicación que va ser utilizada en la universidad.

4.9.2 Programa robot

Después de ejecutar un cierto número de tareas el robot paraba la ejecución de su programa generando un
error desconocido, algo no conveniente para las finalidades del proyecto en donde el tiempo o número de
tareas ejecutadas por el robot podía ser limitado. Después de una lectura en el manual de usuario de robot
se llego a que el problema radicaba en una limitante que tiene el lenguaje de programación cuando se usan
estructuras como IF o FOR. Estas estructuras para programación dependiendo de un valor lógico ya sea

  57  
verdadero o falso ejecutan una serie de pasos, con la característica de que para su correcto funcionamiento
estas estructuras deben especificar un final de análisis con ENDIF o ENDFOR dependiendo sea el caso.
Para aumentar criterios de análisis dentro de estas estructuras se puede usar una misma segunda estructura,
es decir un estructura anidada. El programa realizado de ejecución en el robot hacia uso de subrutinas las
cuales eran llamadas dependiendo de los movimientos requeridos para completar una tarea, es decir
situaciones analizadas verdaderas o falsas usando la estructura IF. Estos saltos de línea en el programa el
lenguaje de programación los lleva a cabo pasando por alto la terminación de la estructura, por lo que
ciclos sucesivos resultarían en anidaciones sumadas. El número máximo de anidaciones permite MELFA
BASICIV es un total de ocho, una reprogramación fue necesaria para solucionar este problema.

  58  
5 ANÁLISIS DE RESULTADOS

Una vez concluida la etapa de desarrollos se procedió con la realización de diferentes pruebas en la
aplicación, analizando aspectos importantes para evaluar su desempeño como son:

-­‐ Proceso y tiempo de conexión con el robot.


-­‐ Tiempo de ejecución de tareas.
-­‐ Generación de alarmas.
-­‐ Alcances de operación.

Los diferentes elementos utilizados para la realización de las pruebas fueron:

-­‐ Computador integrado a red FMS. Especificaciones:


o Procesador: Intel Core 2 Duo E8400 3.00 Ghz
o Memoria RAM: 3.48 Gb
o Sistema operativo: Windows XP professional
o LabVIEW 9.0
-­‐ Cable Ethernet de comunicación entre computador y el switch de FMS, al igual entre controlador
CR1 robot y el mismo switch.
-­‐ Robot manipulador industrial Mitsubishi MELFA RV-2A.

5.1 Pruebas realizadas

Las diferentes pruebas se llevaron a cabo en el Centro Tecnológico de Automatización Industrial de


Universidad Javeriana en presencia del director del proyecto el ingeniero Sergio Ramiro González
Bautista, simulando las diferentes situaciones de trabajo con el robot, futuras sesiones académicas así
como la posibilidad de integrar el proyecto a un plan de proceso requerido en el FMS.

5.1.1 Proceso y tiempo de conexión:

Para el análisis de este tiempo de conexión se utilizó un analizador de protocolo como Wireshark®, de
gran ayuda para captura de paquetes en una red de comunicaciones en especial una red Ethernet. La
captura es en tiempo real con detalles de tiempos por lo que es posible determinar el tiempo en establecer
el enlace.

  59  
Analizando la captura [Figura 46], el cliente (robot) el cual tiene una dirección IP 10.21.7.8 empieza con
el proceso de comunicación con el envío de un segmento TCP orientado a establecer una conexión con el
servidor ubicado en la dirección 10.21.7.10. El servidor no puede asociar en su tabla ARP a que dirección
física corresponde la IP que desea comunicarse con él, por lo que envía un mensaje broadcast preguntando
por tal dirección. El robot escucha este mensaje y asocia su dirección MAC, responde con un mensaje del
mismo tipo en donde especifica su dirección física MAC y su dirección IP. Con esta información el
servidor es capaz de enviar el segmento TCP de confirmación que ha recibido una petición para establecer
una comunicación. Finamente el robot al recibir la confirmación de que su solicitud de conexión fue leída
por el robot (línea #6) manda su señal de START como se diseño el proceso de comunicación.

[Figura 46] Captura Wireshark® conexión

Para este caso el tiempo transcurrido en establecer la conexión por la aplicación, es decir el recibimiento
de la señal START del robot han transcurrido un total de 5,27 s, aunque desde que el cliente empieza con
el proceso de comunicación y el servidor termina con la confirmación de la llegada de la señal START
transcurren tan solo 0,24 s. el proceso de comunicación. La etapa de conexión cumple con el
procedimiento de una conexión mediante protocolo TCP/IP.

5.1.2 Tiempo ejecución de tareas:

Para esta prueba fue analizada la ejecución de cada una de las tareas del robot. Su velocidad fue liberada
al 100% para tener el valor de tiempo mínimo posible en un trabajo por un usuario. Los tiempos son

  60  
calculados en la aplicación principal en LabVIEW® ya que es un dato a ser registrado en la base de datos.
Diferentes tareas fueron asignadas con los siguientes resultados.

-­‐ Movimiento de pallete:

[Figura 47] registro movimiento de pallet base de datos

En el registro en la base de datos se puede observar el código de la tarea que fue realizada por el robot,
así como el tiempo de ejecución para terminarla. Por ejemplo 17 segundos para el movimiento de
pallet desde la estación Banda transportadora a la estación Pallet 1. Finaliza un mensaje de OK como
un movimiento valido terminado sin problemas.

-­‐ Movimiento de barras:

[Figura 48] registro movimiento de barras base de datos

El registro en la base de datos de tres movimientos, la segunda tarea a realizar por el robot fue el
movimiento de una barra de la estación Pallet 1 a la estación Barras, tarea en la cual era necesario el
análisis de la totalidad de sus movimientos al existir ciertos riesgos al momento de manipular el
material. De igual manera se finalizo con devolver la pieza a su posición original. En la columna de
tiempos se puede observar un total de 40 segundos para realizar la segunda tarea y 37 segundos para
realizar la tercera tarea.

  61  
-­‐ Movimiento de cilindros

[Figura 49] registro movimiento de cilindros base de datos

Se analizó el transporte de material hacia la estación de calidad como caso de estudio por los
movimientos que intervienen para finalizar la tarea. La primera tarea a realizar era el transporte de un
cilindro a la estación de calidad desde la estación pallete 1, y luego retornarlo a su posición inicial. Un
total de 29 y 33 segundos respectivamente para la ejecución de cada una de las tareas.

Como ultima prueba se simulo el proceso de análisis de una pieza cilíndrica en la estación de calidad el
cual proviene del almacén, retornándolo nuevamente a la banda transportadora como ya es conocido. En la
[Figura 50] se observa el registro total de movimientos para cumplir con dicha etapa del proceso, y el
tiempo empleado para la ejecución de cada tarea.

[Figura 50] registro movimiento proceso análisis cilindros base de datos

Cada una de las tareas del robot se llevan en lapsos de tiempo rápidos a través de movimientos en donde la
seguridad del robot y la pieza a transportar se garantiza, generando reportes de tareas de fácil
interpretación guardados automáticamente para el análisis futuro por parte de operarios.

  62  
5.1.3 generación de alarmas

Era necesario el análisis de situaciones en los cuales el material a transportar no estaba disponible, y así la
prueba de funcionamiento de las diferentes alarmas que tiene el sistema. Al igual un reporte de las alarmas
para el operario.

En la [Figura 51] se puede observar el caso de análisis, en el cual solo se tiene material en las estaciones
cilindro aluminio, cilindro bronce y barras.

[Figura 51] case análisis de alarma base de datos

En la [Figura 52] se observan las distintas tareas requeridas por el usuario y los errores generados, al igual
el código de la instrucción y el mensaje relacionado.

[Figura 52] registro alarmas base de datos

Como se puede observar, la primera tarea requiere un movimiento de pallet de la estación Pallet 1 a
estación Pallet 2, el mensaje de error es entonces que SOURCE es una posición errónea para movimiento
ya que no tiene material disponible para ser transportado.

  63  
Después de varios casos de análisis, el sistema de alarmas funciona con el comportamiento deseado de
manera acorde a las situaciones de estudio que se presentan en la asignación de tareas por parte del
operario. El reporte contiene el mensaje de la alarma al igual de el código de la tarea que era requerida,
con su respectiva fecha a ser analizada por el operario.

5.2 Alcances de operación

Se probó la aplicación desarrollada asignando un número elevado de tareas en el robot, a su vez generando
alarmas para ver posibles fallas o interrupciones en su funcionamiento. Después de haber sido utilizada
por un periodo cercano a una hora [Figura 53] la aplicación no reporta fallas de funcionamiento ni
generación de errores en el controlador del robot por lo que la solución planteada para la ejecución de
tareas por asignación de instrucciones cumple con los objetivos propuestos.

[Figura 53] Prueba tiempo de utilización de la aplicación

Un total de 28 tareas abarcando diferentes movimientos posibles de material en su estación de trabajo.


Pallets, cilindros, barras y botellas fueron transportados por el robot entre cada uno de sus lugares
posibles.

  64  
La aplicación es capaz de llevar a cabo determinado número de tareas requeridas por usuario sin
restricciones en su número, estableciendo una conexión rápida y con tiempos casi inmediatos en la
recepción de alarmas. Las tareas al igual por parte del robot se realizan en tiempo de ejecución cortos por
lo que se puede decir es un sistema eficiente de fácil ejecución.

La posibilidad de incluir nuevas tareas por parte del robot es posible gracias al diseño tanto de la
herramienta en LabVIEW como el programa del robot, los cuales admiten modificaciones para
incluirlas. Ya que la ejecución de una tarea por parte del robot solo es posible mediante posiciones
enseñadas manualmente las cuales son únicas para determinada tarea, se necesitaría de esta programación
en el robot. En la herramienta desarrollada en LabVIEW seria solo necesario la configuración de la
nueva instrucción a ser enviada, es añadir un bloque igual al mostrado en la [Figura 44] en donde S y T
tomarían los valores para la nueva instrucción requerida.

  65  
5. CONCLUSIONES Y RECOMENDACIONES

Fue posible establecer comunicación con el Robot Melfa Rv-2A mediante el desarrollo de un instrumento
virtual en LabVIEW® y un programa específico almacenado en su controlador, a través de el protocolo de
comunicaciones TCP/IP y utilizando conexiones físicas disponibles, como una tarjeta de adquisición
Ethernet en el controlador del robot y la red interna del FMS.

Se diseñó una interfaz de usuario para el establecimiento de tareas de manipulación de material de un


robot industrial en la cual se restringe la posibilidad de errores en la operación de la aplicación por medio
de listas que contienen las posibilidades de movimiento, evitando así por ejemplo la escritura de
comandos.

La implementación de un sistema de asignación de tareas en el robot basado en el envío de instrucciones


desde una estación central, método con grandes ventajas para su entendimiento y programación, permite la
inclusión dinámica de futuras aplicaciones mediante nuevas instrucciones a ser enviadas.

Es de importancia el mantener un sincronismo y restricción para el envío y recepción de datos en


aplicaciones de comunicación de datos con labVIEW®, por esta razón es recomendable añadir
programación para el control del funcionamiento de los bloques destinados a lectura y escritura en una red
mediante un protocolo como TCP/IP, evitando la perdida de información y/o lecturas erróneas en los
desarrollos.

El analizador de protocolo se convierte en una herramienta fundamental para la transmisión de datos y su


especificación detallada en tiempo real, verificando tramas y tiempos en el proceso de comunicación. De
esta manera poder tener un conocimiento del flujo de los datos verificando en un caso de análisis la
posible perdida de información o ajustes en el sincronismo de la comunicación.

Con el desarrollo de esta aplicación se ha avanzado en el proceso de la búsqueda de un sistema supervisor


alterno del FMS del ya existente, COSIMIR CONTROL, mediante una herramienta que permita una
integración de nuevas tecnologías como lo es LabVIEW®

Se han abierto puertas para que futuros investigadores se interesen en el desarrollo de trabajos en el campo
de la robótica industrial. Aplicaciones con visión artificial y procesamiento de señales para dirigir el robot
en sus movimientos, o el reconocimiento de tipos de piezas a ser transportadas y así generar programas
generales para la ejecución de tareas sin depender del objeto a transportar.

  66  
7. BIBLIOGRAFIA

[1] Groover, Mikell P. Fundamentals of modern manufacturing materials, processes, and systems . 3era
ed. Prentice Hall. 2001.
[2] Zambrano, Gabriel. Apuntes de clase Automatizacion Industrial – robotica industrial. 2009. Pontificia
Universidad Javeriana
[3] Zambrano G. M.; Rosas L. F. Robótica Industrial: Manual de funcionamiento del robot Mitsubishi
Melfa IV y el software Cosimir® Professional, integrados al sistema de manufactura integrada por
computador CIM del Laboratorio de Automatización Industrial. Pontificia Universidad Javeriana, Bogotá,
Julio de 2008.
[4] Kohrt, C.; Pipe, A.; Schiedermeier, G.; Stamp, R.; Kiely, J.; , "A robot manipulator communications
and control framework," Mechatronics and Automation, 2008. ICMA 2008. IEEE International
Conference on , vol., no., pp.846-851, 5-8 Aug 2008.
[5] Kurose, James F. Ross, Keith W. Computer networking, a top-down approach. Fifth edition. Pearson.
2005
[6] Catalogo “MELFA Industrial Robots Consistent Quality – Precise Control”. Mitsubishi Electric
Factory Automation. 2009
[7] Manual “MITSUBISHI ELECTRIC CORPORATION. CRn-500 series INSTRUCTION MANUAL:
Ethernet interface”. Proporcionado por Mitsubishi Electric Corporation a la Pontificia Universidad
Javeriana
[8] Zimmermann, H.; , "OSI Reference Model--The ISO Model of Architecture for Open Systems
Interconnection," Communications, IEEE Transactions on , vol.28, no.4, pp.425-432, Apr1980.
[9] Arlitt, M.; Williamson, C.; , "The Extensive Challenges of Internet Application Measurement,"
Network, IEEE , vol.21, no.3, pp.41-46, May-June 2007
[10] Lang Li-ying; Shen Lan; , "Design and study of strain data communication system based on
LabVIEW," Computer Science and Information Technology, 2009. ICCSIT 2009. 2nd IEEE International
Conference on , vol., no., pp.66-68, 8-11 Aug. 2009
[11] C. F. Jiménez. “conexión TCP/IP entre dos estaciones usando LabVIEW 7 express”. Universidad
industrial de Santander UIS. Febrero de 2005.
[12] Wen Hao; Dong Xiao-rui; Ma Yu-cheng; Nan Jin-rui; , "The research of the databases connection
methods in LabVIEW based on ADO," Computer Application and System Modeling (ICCASM), 2010
International Conference on , vol.7, no., pp.V7-229-V7-233, 22-24 Oct. 2010
[13] LabVIEW Database Connectivity Toolkit guide.
[14] MITSUBISHI-ELECTRIC CORPORATION, MELFA Industrial Robots Instruction Manual
(Functions and Operations) CR1 Controller, Mitsubishi-Electric, 2003.

  67  
[15] J. Wolf; P. Robinson, Mitsubishi RV-2AJ Industrial Robot Programming and Calibration Lab Notes,
School of Computing Communication and Electronics, the university of Plymouth, Version 0.6 Nov 2005

[16 ]VALLEJO CASTAÑEDA, Christian Camilo. Control de un almacén de AS/RS desarrollado en una
herramienta gráfica para pruebas y control. Bogotá, 2010. Trabajo de grado (ingeniero electronico).
Pontificia Universidad Javeriana. Facultad de ingenieria. Departamento de ingenieria electronica

[17] FORERO MARTINEZ, Oscar David. Control supervisorio de una banda transportadora en
LabVIEW. Bogotá, 2008. Trabajo de grado (ingeniero electronico). Pontificia Universidad Javeriana.
Facultad de ingeniería. Departamento de ingeniería electrónica.

[18] Bitter, R. Mohiuddin, T. Nawrocki, M. LabVIEW Advance Programming Techniques. 2 ed. CRC
Press Taylor & Francis Group. 2007

[19] Huadong Li; Yufang Zhong; Mingguang Wu; , "Research on network of remote real-time
surveillance system based on LabVIEW," Industrial Informatics, 2009. INDIN 2009. 7th IEEE
International Conference on , vol., no., pp.60-65, 23-26 June 2009
[20] Bingsheng Wu; Chaozhi Cai; , "Remote Data Acquisition and Signal Processing System Based on
LabVIEW," Measuring Technology and Mechatronics Automation, 2009. ICMTMA '09. International
Conference on , vol.1, no., pp.308-311, 11-12 April 2009.

  68  
8. ANEXOS

  69  
ANEXO 1

Manual de funcionamiento

Para la ejecución de la aplicación es necesario el funcionamiento de tanto la herramienta LabVIEW


como el programa en el robot MELFA. Para facilidades de operación con el robot, en su memoria interna
se encuentra almacenado el programa y puede ser ejecutado desde su herramienta educacional COSIMIR
Professional. De otra manera, la herramienta LabVIEW se puede encontrar en la carpeta LABVIEW de
este trabajo, en donde un proyecto ha sido creado con los instrumentos virtuales correspondientes para la
ejecución de la aplicación.

Los diferentes pasos para la ejecución de la aplicación se muestran a continuación:

El trabajo contiene dos carpetas las cuales contienen los diferentes archivos desarrollados. La carpeta
LabVIEW desarrollos correspondientes la herramienta que deben ser ejecutada desde el computador
destinado a trabajos de grado y grupo de investigación ZENNITH. La segunda carpeta PROGRAMA
ROBOT contiene dos archivos que deben ser guardados en el controlador de robot. el archivo .mb4
corresponde a un programa escrito en lenguaje MELFA BASICIV con la totalidad de instrucciones
para llevar a cabo las diferentes tareas, así como el proceso de establecimiento de la comunicación con
la estación central y la recepción de instrucciones.

1. Proceso de instalación de la herramienta principal:

En su interior, la carpeta LabVIEW tiene diferentes archivos los cuales son de gran importancia para
el éxito en la ejecución de la herramienta. El archivo Control Supervisorio Robot Melfa RV-2A.lvproj
es el proyecto con los diferentes VI’s. Al abrir el proyecto se pueden encontrar dos VI’s, Control
Supervisorio Robot Melfa RV-2A.vi y database.vi. La herramienta principal la cual tiene el una
ventana principal es la primera, se selecciona para abrir la ventana principal. la segunda no es
necesario ya que es usada internamente por la herramienta para la modificación de la base de datos. La
base de datos Tmelfa.mdb, que se encuentra igualmente en esta carpeta, debe ser guardada en el
equipo en una ubicación específica para poder establecer conexión con ella y ser reconocida por la
herramienta. El sitio especifico es: Z=\CIM JAVERIANA xMII

2. Instalación del programa en el robot:

En la carpeta PROGAMA ROBOT se encuentran los archivos que deben ser guardados en el
controlador del robot. Para esto se dispone de la herramienta COSIMIR PROFESSIONAL con la cual
es posible tanto la descarga del programa al controlador como ordenar su ejecución, proceso posible

  70  
directamente en el robot con desventajas al ser mucho más extenso y con posibilidades de generar
errores y des configuraciones en una sesiones académica por ejemplo.

El computador disponible para esto se encuentra junto al robot en las instalaciones, se busca el
programa COSIMIR PROFESSIONAL y se ejecuta. Es necesario luego establecer concesión con el
robot y poder descargar el programa a el controlador, para esto se oprime el icono abrir, y se
selecciona el archivo Javeriana/CNC_Feeder/CNCCOUPLING necesario en el proceso de establecer
comunicación con el robot desde esta herramienta. Luego en la pestaña execute, se busca la opción
RCI Explorer en la cual es posible hacer configuración de la herramienta como visualizar programas
del robot. se verifica en la opción connection seleccionar RS232. Para establecer la conexión se
selecciona en el menú execute la opción init connection, al cabo de unos segundos debe aparecer una
verificación de su conexión a través de la siguiente ventana.

Una vez la conexión está establecida se debe buscar el programa reservado para el trabajo de este
mediante la aplicación desarrollada en este trabajo. en la misma ventana RCI Explorer se selecciona la
opción Programs, se despliega un listado de programas en el robot, y se busca el programa con
nombre SG1. Al ser ubicado, dando click derecho sobre el programa se selecciona la opción Debug.

3. ejecución de la aplicación:

Con la herramienta principal lista para su ejecución al igual que el programa en el robot, es posible dar
inicio a la aplicación. Para esto se necesita ejecutar cada uno de estos en un orden establecido, primero
la herramienta principal LabVIEW y después el programa en el controlador del robot. Para la

  71  
herramienta principal situados en la ventana principal se oprime run el cual se encuentra en la barra de
herramientas de LabVIEW, el primer botón de izquierda derecha.

Enseguida, se ejecuta el programa en el robot con el icono de la ventana Debugger de


COSIMIR PROFESSIONAL.

4. ejecución de tareas:

Para ejecutar las tareas de manipulación por parte del robot, situados en la ventana principal de la
herramienta LabVIEW se espera por la señal de conexión establecida con el robot, cuando el led
indicador cambie su estado. Una vez esta conexión haya sido confirmada, se escoge cualquier tipo de
tarea de material seleccionando la opción requerida dependiendo de la pieza a transportar, la posición
inicial y la posición final especifica seleccionando esta ultima opción, para confirmar se presiona
START y se empieza con la ejecución de determinada tarea. En caso de una evento de alarma pulsar
OK para confirma el reconocimiento de ella y seleccionar una opción válida de movimiento.

5. finalización de ejecución de tareas con la aplicación:

Para terminar con la utilización de la aplicación, se pulsa STOP en la ventana principal. se genera la
desconexión con el robot, en el cual su respectivo programa termina su ejecución igualmente.

  72  
ANEXO 2

Configuración modo cliente controlador

Para la configuración del controlador como cliente y así llevar a cabo la comunicación con el servidor vía
TCP/IP, se realizo mediante su teach-pendant como posibilidad de configuración de parámetros de red que
tiene esta herramienta. Los datos según la configuración de red existente se muestra en la tabla, la
secuencia de pasos se muestra a continuación.

1. En la pantalla menú se oprime la opción [5] para opciones de mantenimiento en el robot.

2. una vez dentro de la opción mantenimiento, se pueden encontrar 5 opciones de mantenimiento


posibles en el robot, como por ejemplo su posición inicial. Se selecciona la opción [1]
correspondiente a parámetros.

3. una vez dentro de la opción parámetros es posible entrar a configurar cualquiera de los parámetros
que tiene el robot para funcionamiento. Como los parámetros a configurar son solo los indicados
en capitulo, se escribe en el primer campo el nombre del parámetro. Para la escritura es necesario
habilitar los caracteres en el teach-pendant con el botón CHAR, sin dejarlo de oprimir se ingresan
los caracteres correspondientes. Para confirmar el botón RPL

“parámetro”

4. una vez escrito el parámetro a ser modificado aparecerá el valor que tiene en estos momentos el
parámetro, se borra y se introduce el valor requerido. Para confirmar se oprime el botos IMP/EXE

  73  
ANEXO 3

Manual de instrucciones

Pieza a manipular Movimiento Instrucción


Posición origen (source) Posicion destino (target) (source,target)
Pallete banda transportadora pallet 1 [10,1]
banda transportadora pallet 2 [10,2]
pallet 1 banda transportadora [1,10]
pallet 1 pallet 2 [1,2]
pallet 2 banda transportadora [2,10]
pallet 2 pallet 1 [2,1]
barras pallet 1 pallet 2 [6,7]
pallet 1 Almacenamiento de bar. [6,5]
pallet 2 pallet 1 [7,6]
pallet 2 Almacenamiento de bar. [7,5]
Almacenamiento de bar. pallet 1 [5,6]
Almacenamiento de bar. pallet 2 [5,7]
cilindros pallet 1 control de calidad [8,11]
pallet 2 control de calidad [9,11]
Almacenamiento cil.
Alu. control de calidad [3,11]
Almacenamiento cil. brc. control de calidad [4,11]
control de calidad pallet 1 [11,8]
control de calidad pallet 2 [11,9]
Botellas Pallet 1 Estacion embotellado [12,14]
Pallet 1 Estacion calidad [12,15]
Pallet 2 Estacion embotellado [12,14]
Pallet 2 Estacion calidad [12,15]
Estacion embotellado Pallet 1 [14,12]
Estacion embotellado Pallet 2 [14,13]
Estacion embotellado Estacion calidad [14,15]
Estacion calidad Pallet 1 [15,12]
Estacion calidad Pallet 2 [15,13]
Estacion calidad Estacion embotellado [15,14]

  74  
ANEXO 4

Adquisición y envío de instrucciones

-­‐ Líneas de código del programa para lectura de instrucciones y envío de código de la instrucción.
10 '|-----------------------------------------------------------------------------------------------------------------
-|
20 '| MAIND
30 ' Inputs
40 DEF IO P1AV = BIT,8 'palette 1 available
50 DEF IO P2AV = BIT,9 'palette 2 available
60 DEF IO P3AV = BIT,10 'brass workpiece available
70 DEF IO P4AV = BIT,11 'alu workpiece available
80 DEF IO P5AV = BIT,12 'Base plate available
90 DIM STA(5)
100 SERVO ON
110 OPEN "COM8:" AS #1 ' Open as communication line COM3
120 PRINT #1,"START" ' Send START character string
130 FOR M1=1 TO 2
140 IF M1=1 THEN
150 INPUT #1,SOURCE ' Wait for reception of value in SOURCE variable
160 ELSE
170 INPUT #1,TARGET ' Wait for reception of value in TARGET variable
180 ENDIF
190 NEXT M1
200'|--------------------------------------------------------------------------------
210'|--------------------------------------------------------------------------------
220'|--------------------------------------------------------------------------------
230'|--------------------------------------------------------------------------------
240 IF (SOURCE=1 AND TARGET=2) THEN
250 PRINT #1,"P1TOP2"
260 GOTO 230
270 ENDIF
280 IF (SOURCE=1 AND TARGET=10) THEN
290 PRINT #1,"P1TOP10"
300 GOTO 230
410 ENDIF

  75  
420 IF (SOURCE=2 AND TARGET=1) THEN
430 PRINT #1,"P2TOP1"
440 GOTO 230
450 ENDIF
460 IF (SOURCE=2 AND TARGET=10) THEN
470 PRINT #1,"P2TOP10"
480 GOTO 230
490 ENDIF
500 IF (SOURCE=10 AND TARGET=1) THEN
510 PRINT #1,"P10TOP1"
520 GOTO 230
530 ENDIF
540 IF (SOURCE=10 AND TARGET=2) THEN
550 PRINT #1,"P10TOP2"
560 M1=1
570 GOTO 230
580 ENDIF
590 D

  76  
ANEXO 5

Lectura de censores de la celda de trabajo y configuración de alarmas

-­‐ Programación LabVIEW

Para un caso, el envió de una instrucción de movimiento de pallete de posición pallet 1 a pallet 2 y
espera por respuesta ya sea un código de alarma el código de movimiento en el caso de un
movimiento valido

Para actualización del “status” de la celda de trabajo robot, es decir la disposición de material para ser
transportado un bloque de lectura para estas señales enviadas desde el robot.

-­‐ líneas de código MELFA BASICIV en robot

10 '|------------------------------------------------------------------------------------------------------------------|
20 '| MAIND

  77  
30 ' Inputs
40 DEF IO ASTART = BIT,1 'start control panel
50 DEF IO ASTOP = BIT,2 'stop control panel
60 DEF IO RRESET = BIT,4 'reset control panel
70 DEF IO P1AV = BIT,8 'palette 1 available
80 DEF IO P2AV = BIT,9 'palette 2 available
90 DEF IO P3AV = BIT,10 'brass workpiece available
100 DEF IO P4AV = BIT,11 'alu workpiece available
110 DEF IO P5AV = BIT,12 'Base plate available
120 DEF IO GROPEN = BIT,900 'gripper opened
130 DEF IO GRCLOSE = BIT,901 'gripper closed
140 ' Outputs
150 DEF IO HSTART = BIT,0 'lamp start control panel
160 DEF IO HRESET = BIT,1 'lamp reset control panel
170 DEF IO LEDQ1 = BIT,2 'lamp Q1 control panel
180 DEF IO LEDQ2 = BIT,3 'lamp Q2 control panel
190 DEF INTE ANS
200 DEF INTE TS
210 DEF INTE TT
220 DIM STA(5)
230 SERVO ON
240 OPEN "COM8:" AS #1 ' Open as communication line COM3
250 PRINT #1,"START" ' Send START character string
260 FOR M1=1 TO 2
270 IF M1=1 THEN
280 INPUT #1,SOURCE ' Wait for reception of value in SOURCE variable
290 ELSE
300 INPUT #1,TARGET ' Wait for reception of value in TARGET variable
310 ENDIF
320 NEXT M1
330 TS%=0
340 TT%=0
350 IF (SOURCE=1 AND TARGET=0) THEN 'status update is required by the user
360 STA(1)=P1AV
370 STA(2)=P2AV
380 STA(3)=P3AV

  78  
390 STA(4)=P4AV
400 STA(5)=P5AV
410 PRINT #1,STA(1)
420 PRINT #1,STA(2)
430 PRINT #1,STA(3)
440 PRINT #1,STA(4)
450 PRINT #1,STA(5)
460 GOTO 260
470 ENDIF
480 SELECT SOURCE 'test source
490 CASE 1
500 IF P1AV = 0 THEN
510 TS%=1
520 ENDIF
530 BREAK
540 CASE 2
550 IF P2AV = 0 THEN
560 TS%=1
570 ENDIF
580 BREAK
590 CASE 3
600 IF P3AV = 0 THEN
610 TS%=1
620 ENDIF
630 BREAK
640 CASE 4
650 IF P4AV = 0 THEN
660 TS%=1
670 ENDIF
680 BREAK
690 CASE 5
700 IF P5AV = 0 THEN
710 TS%=1
720 ENDIF
730 BREAK
740 CASE 6

  79  
750 IF P1AV = 0 THEN
760 TS%=1
770 ENDIF
780 BREAK
790 CASE 7
800 IF P2AV = 0 THEN
810 TS%=1
820 ENDIF
830 BREAK
840 CASE 8
850 IF P1AV = 0 THEN
860 TS%=1
870 ENDIF
880 BREAK
890 CASE 9
900 IF P2AV = 0 THEN
910 TS%=1
920 ENDIF
930 BREAK
940 END SELECT
950 '------------------------------------------------------------------------------
960 '------------------------------------------------------------------------------
970 '------------------------------------------------------------------------------
980 SELECT TARGET 'test target
990 CASE 1
1000 IF P1AV = 1 THEN
1010 TT%=1
1020 ENDIF
1030 BREAK
1040 CASE 2
1050 IF P2AV = 1 THEN
1060 TT%=1
1070 ENDIF
1080 BREAK
1090 CASE 3
1100 IF P3AV = 1 THEN

  80  
1110 TT%=1
1120 ENDIF
1130 BREAK
1140 CASE 4
1150 IF P4AV = 1 THEN
1160 TT%=1
1170 ENDIF
1180 BREAK
1190 CASE 5
1200 IF P5AV = 1 THEN
1210 TT%=1
1220 ENDIF
1230 CASE 6
1240 IF P1AV = 1 THEN
1250 TT%=1
1260 ENDIF
1270 BREAK
1280 CASE 7
1290 IF P2AV = 1 THEN
1300 TT%=1
1310 ENDIF
1320 BREAK
1330 CASE 8
1340 IF P1AV = 1 THEN
1350 TT%=1
1360 ENDIF
1370 BREAK
1380 CASE 9
1390 IF P2AV = 1 THEN
1400 TT%=1
1410 ENDIF
1420 BREAK
1430 END SELECT
1440 '------------------------------------------------------------------------------
1450 ' check the values of TS and TT
1460 '------------------------------------------------------------------------------

  81  
1470 IF (TS% = 1 OR TT% = 1) THEN 'verify if the source or target given by the user is ok
1480 IF TS% = 1 THEN
1490 IF TT% = 1 THEN
1500 ANS%=4
1510 ELSE
1520 ANS%=3
1530 ENDIF
1540 ELSE
1550 IF TT% = 1 THEN
1560 ANS%=2
1570 ENDIF
1580 ENDIF
1590 PRINT #1,ANS% 'Reply ANS = value
1600 GOTO 260
1610 ENDIF
1620 '------------------------------------------------------------------------------
1630 ' pallete movement
1640 '------------------------------------------------------------------------------
1650 IF (SOURCE = 10 OR SOURCE = 1 OR SOURCE = 2) THEN 'if source position is at conveyor
or palette - the only movement of pallets is from conveyor to pallet
1660 IF (TARGET= 10 OR TARGET= 1 OR TARGET= 2) THEN 'if target position is at
one of these, the movement is just palett.
1670 PRINT #1,"P"SOURCE"TOP"TARGET
1680 GOTO 260
1690 ENDIF
1700 ENDIF
1710 '------------------------------------------------------------------------------
1720 ' barra movement
1730 '------------------------------------------------------------------------------
1740 IF (SOURCE = 5 OR SOURCE = 7 OR SOURCE = 6) '
1750 IF (TARGET = 5 OR TARGET = 6 OR TARGET = 7)
1760 PRINT #1,"P"SOURCE"TOP"TARGET
1770 GOTO 260
1780 ENDIF
1790 ENDIF
1800 '------------------------------------------------------------------------------

  82  
1810 ' cylinder movement
1820 '------------------------------------------------------------------------------
1830 IF (SOURCE = 3 OR SOURCE = 4 OR SOURCE = 9 OR SOURCE = 8 OR SOURCE = 11)
'movimiento de cilindro a estacion de calidad
1840 IF (TARGET = 3 OR TARGET = 4 OR TARGET = 9 OR TARGET = 8 OR TARGET = 11)
'if the material to analyse is an cilinder
1850 PRINT #1,"P"SOURCE"TOP"TARGET
1860 GOTO 260
1870 ENDIF
1880 ENDIF
1890 END

  83  

Potrebbero piacerti anche