Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
FACULTAD DE INGENIERIA
BOGOTÁ DC.
2011
CONTROL SUPERVISORIO DE UN ROBOT MANIPULADOR INDUSTRIAL MITSUBISHI MELFA
UTILIZANDO LA PLATAFORMA LABVIEW
DIRECTOR
FACULTAD DE INGENIERIA
BOGOTÁ DC.
2011
2
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERIA
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
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.
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.
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.
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].
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].
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.
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.
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.
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.
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.
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]
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:
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]
21
[Figura 6] modelo OSI, proceso 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].
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®
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.
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.
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]
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].
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]:
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]
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.
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.
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]
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
Revision de manuales del robot Comunicación mediante LabVIEW Con?iguración y conexión actuales de FMS
De?inición de protocolo de comunicacion Com cliente/servidor en LabVIEW TCP/IP Com LabVIEW -‐ controlador robot TCP/IP
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.
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.
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
Mayor velocidad de
transmisión de datos
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
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
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.
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.
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
COMDEV(8) OPT18
NETHSTIP(8) 10.21.7.10
NETMODE(8) 0
CPRCE18 2
NETHSTIP(8) 10.21.7.10
NETPORT(9) 10008
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.
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.
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]
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.
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.
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]).
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.
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.
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.
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.
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.
- 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
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.
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
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.
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)
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
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).
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.
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.
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]
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.
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.
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:
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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 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
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.
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
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.
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.
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
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.
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
74
ANEXO 4
-‐ 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
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.
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