Implementación de interfaz de comunicación entre ...
182
Transcript of Implementación de interfaz de comunicación entre ...
INSTITUTO TECNOLOGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY
CAMPUS ESTADO DE MEXICO
"' ,W • I ,,:
IMPLEMENTACIÓN DE INTERFAZ DE COMUNICACION ENTRE CONTROLADOR Y ELEMENTOS DE UNA CELDA DE MANUFACTURA
FLEXIBLE
TESIS QUE PRESENTA
EDGAR MORALES SARDANETA
MAESTRIA EN CIENCIAS DE LA COMPUTACION MCCR93
DICIEMBRE, 1999
;, ,_1:)
INSTITUTO TECNOLOGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY
CAMPUS ESTADO DE MEXICO
IMPLEMENTACIÓN DE INTERFAZ DE COMUNICACION ENTRE CONTROLADOR Y
ELEMENTOS DE UNA CELDA DE MANUFACTURA FLEXIBLE
Asesor:
Jurado:
TESIS QUE PARA OBTENER EL GRADO DE
MAESTRO EN CIENCIAS COMPUTACIONALES
PRESENTA
EDGAR MORALES SARDANETA
Dr. Jesús Antonio Sánchez Velázquez
Dr. Fabian García Nocetti
M.C. Rafael San Vicente Cisneros
Dr. Isaac Rudamin Goldberg
Dr. Carlos Rodriguez Lucatero
Dr. Jesús Antonio Sánchez Velázquez
Dr. Fabian García Nocetti
M.C. Rafael San Vicente Cisneros
Presidente
Secretario
Vocal
Vocal
Vocal
Atizapan de Zaragoza, Edo. de Méx., Diciembre 1999
A mi familia.
RESUMEN
En esta tesis se hace la implementación de una interfaz entre el controlador y los
elementos de una Celda de Manufactura Flexible (CMF) que permite la tolerancia
a fallas por medio de redundancia en hardware. Esta tesis forma parte del
proyecto "Tecnologías de Comunicación Avanzadas en Robótica y Celdas
Flexibles de Manufactura" el cual está financiado por la National Science
Foundation (NSF) y el Consejo Nacional de Ciencia y Tecnología (CONACyT).
Para poder realizar la tolerancia a fallas la implementación de la interfaz esta
basada en el uso de switches. Lo anterior es posible gracias a que la interfaz
hacia el robot tiene la característica de manejar dos enlaces a sus robots
correspondientes y conmutar un enlace de un robot a otro por medio de una
matriz de conexión 2x2.
Debido a las características de la interfaz utilizada para la comunicación con los
elementos de la celda, la parte de programación del sistema está hecha en
lenguaje Occam, por lo que se proporciona además el código de los programas
utilizados.
CONTENIDO
1. INTRODUCCION ................................. .. ....................... ..... ... ............ ...... .. ..... ... ............... ... .. , ... . 5
1.1 CIM (Centro de Manufactura Integrada) ... ..... ...... .. .. .... .... ..... .. .... .... .... .. ... .. ...... .... .. .... ... ... ..... . 9
1.2 CMF (Celda de Manufactura Flexible) . ........................ .. ... ................. .. .. .. .. .................. .. .. ... 10
1.3 Antecedentes ................................ .... .. .. ................... .. ... ... .................. .. .. ......................... .. .. 10
1.4 Planteamiento del problema ............. ..... ......................... ............. .. .. .. ...... .. ... ... .. .......... .. ... .. 13
1.5 Justificación .. .... .. ....... ... ..... ..... .... .... .. ........ ... .. ... .... .. .. .. ..... ... ..... .. ....... ...... ..... ...... ................. 14
2. CARACTERISTICAS DE LOS ELEMENTOS DE LA CELDA DE MANUFACTURA. ...... .. ......... 16
2.1 Robot Mitsubishi. .. ........................... ......................... ... .... ................... ... ... .. .......... .. ...... .... .. 18
2.2 Robot Puma ........ .. ................................................................................. ... .... .............. .. ..... . 19
2.3 Robot Júpiter ...... ..... ..... ............................... .. ............ ...... .... .. .... ........ ... ..... ... .................. .... 20
2.4 Torno y Fresa ...... ...................... ............. .. ............. .......... .. ........... ......... ....... ..... .... ...... ...... . 20
2.5 AS/RS ................. ............................................................ .......................... .. .. ............... ...... 21
2.6 Comunicación con los elementos de la Celda ..................................................................... 21
2.7 Descripción del controlador PARDICO (PARallel and Distributed lntelligent Controller) ... ... 23
3. CARACTERÍSTICAS DE LOS ELEMENTOS A UTILIZAR CON EL CONTROLADOR. ......... .. . 25
3.1 Computadora huésped .. ............. ... ..... ...... ... ........ ..... .. ........................... ............................ .. 26
3.1.1 Características ............................................................................................................. 26
3.1.2 Elementos ... ... .. .... ........................... ........................ .. .......................... ... .............. .. ..... . 26
3.2 Módulos IMS 8426 (T805 - 25 MHz) . ........ ........... .. .. .. ...... ... ............................... .. ...... .. ...... 27
3.2.1 Descripción . ... ........ .. ... ... .... .. ....... ..... ..... ..... ... ... ... ... ..... ..... ...... .. ... .. ... ...... ... ... ... ............. 27
3.2.2 Características . .. .................... .. ... .. .......... .. ..... .... ..................... .. ........................ ... ..... ... 27
3.3 Tarjeta IMS 8008 ...... ..................... ........ ............................................... .... .......................... 28
3.4 Interfaz de comunicación 810232 . ....... ...... .. .... ... .... ...... .. .... ... ...... .. .. .. ................ ................. 31
3.4.1 Introducción .. ... .. ...... ... .................... .............. ......... .. .................. ........... ........................ 31
3.4.2 Instalación ... .. .... ..................... ..... .. ....... .. .. .... ................................... .... .. .. ... .... ... .. ... .. .. .. 32
3.5 Interfaz de comunicación 810422 ..................................... ... .. ....... .. .................................. .. 33
3.5.1 Introducción .... ... .. ..................... .... ......................................................... .................... ... 33
4. SOLUCION PROPUESTA. .... ....... ...... ........... .. .................................. .............. ... ............ ...... .... 35
2
4.1 Propuesta .......................................................... ................................................................ . 35
4.2 Conexión interfaz RS232 ... ................................................................. .......... .. ................... . 37
4.3 Conexión interfaz RS422 .................................................................................................... 38
4.4 Diseño e implementación convertidor RS422/RS232 ...................................................... ... . 39
Señal TTL H=5V, L=OV. ..................... .. ............................................................................. . 39
Señal Diferencial -+ 5V RS422 ...... .. .......................... .................................................... 40
Señal -+ 12V RS232 ...... ........ ........... ... .. .. ...................................................................... 40
4.4.1 Instalación ................................. .... ......................... ... ................................................... 41
4.4.2 Descripción del Hardware ........ .. ......................... ... .. ........................ ... .......................... 41
4.5 Tolerancia a fallas . .......................... .... ..................... .. ........................ ... .. .... ..... .............. .. .. 42
5. RESULTADOS ...................... ........................... .. ........ .. .... ..... .... .... .. .... .. ..... ..... ........... ... ... .. ...... 55
5.1 Prueba 1. Redundancia con dos procesadores ......................................................... .......... . 61
5.2 Prueba 2.Redundancia con dos Robots ....................... ... ........................ .. ... ...................... 61
6. CONCLUSIONES Y RECOMENDACIONES A FUTURO ........................... ........ ................. ... .. 68
6.1 Conclusiones ........................................................................................... ... ... ....... ..... ...... .. . 68
6.2 Recomendaciones . ... ...... ............. .... .... ........................................................................ .... .. . 69
7. 818LIOGRAFIA ................................................................................................. ... .................. .. 70
APENDICE A. DESCRIPCIÓN DE HARDWARE SIO RS232 Y/O SIO RS422 ............................ 72
A.1 Mapeo de la memoria del transputer. ....................................................... ...................... .. .. 72
A.1.1 Figura 3. 7 Configuración de la memoria del Transputer ........................................ 73
A.2 Conexión pinouts RS232 . .... .... .... .................. ..... .... ..... ... .......... .... .... ... .. ... .. .. ............. ... .... .. 74
A.2.1 Conector estándar 089 .......................................................................................... 75
A.3 Conexión pinouts 422 ......................................................................................................... 76
A.4 Registros de programación ..... ........................................................................... ...... ........... 77
A.5 Registros Internos del Duart ...................................... .. ............................................ ......... . 81
A.6 Descripción de los registros de lectura ................................................................................ 83
A.7 Descripción de los registros de escritura ...................................................... ....................... 85
APENDICE 8 . DESCRIPCIÓN DE SOFTWARE SIO RS232 Y/O SIO RS422 ... .. ......................... 88
8 .1 Protocolos de comunicación ......... .. ...... .. .. ........... ................ .. .... ... ... ..... ... .... ... .. ... .. ......... ... . 88
8.2 Comandos del controlador. ................................................................................................. 89
8.3 Protocolo de comando ....................................................................................................... 89
B.4 Descripción comando de configuración .. ............................................................................ 91
B.5 Comunicación del controlador. .................................................................... ...... ...... ......... .. 93
APENDICE C. REGISTROS DEL SI0232 y SI0422 ...... ........................................................ .. ... 95
APENDICE D PSEUDOCÓDIGOS Y PROGRAMAS .......... .. .. .. .... ........ .... .. .......... ... .......... .. .... .. . 108
Pseudocódigo y Programas ................... ...... ........................................................................... 108
D.1 Esquema 1. Un proceso controlador y dos elementos robot: ............................................ 108
~
·'
D .1 .1 Archivo de Configuración .. ...... ..... ......... .... ... ..... .. ........ ........................................... 108
D.1.2 Proceso APLIC ............... ............. ....... ... ...... ....................................................... .. .. 111
Programa en Occam : ...................................................................... .... .. ...................... 111
Nodo en el archivo de configuración: ................. ... ........................... .......... ... ......... ...... 111
Descripción .. ..... ..... ...................................................................................................... 111
Flujo ............................ ........................................................................... .... ........ ..... .. ... 111
Código: .... .... .................................... .................................. .. ..... ....... .. ............ ........ ...... 113
Forma de compilarlo: .................................... .. ........ .................................................. ... 119
D.1.3 Proceso ENLACEO ......................................... .. ............................. .. ....... ... ..... .. .... . 120
Programa en Occam : ............. ...... .................. .. .... .. ... .................. ... .... .... ................ .. ... 120
Nodo en el archivo de configuración: .... ............. .... .... .. .............. ... ......... .. .... .. .............. 120
Descripción .... .. ........ ....... ............. ................ ....... .............................. ... .................... .... 120
Flujo ................. ....... ............ .. ... .. .... .................... ...... ...................... ...... ... ................ .... . 120
Código: .................................... .. ............... .. .......... ...... ............................................... .. 122
Forma de compilarlo: ................. ........................ ...... ......................... ... ..... ......... ..... .. ... 128
D.1.4 Proceso $10232.DRIVER .. ..... ........ ... .. .... .. ... ... .. ....... ... .............. ... .... ..... .. .......... ..... 128
Programa en Occam : ................................ ........... ... ....................... ... .... ................. ... .. 128
Nodo en el archivo de configuración: ......................................................................... .. 128
Descripción ..... ......................................................................................................... .... 128
Flujo ............................... .............................................................................................. 129
Codigo: .... ........ ........................... .............. ... .... ......... ........... .... .. ............................. ..... 131
Forma de compilarlo: ............ ....................................................................................... 152
D.1.5 Forma de Ejecutar el Programa: ............................................................................. 152
D.2 Esquema 2. Dos procesos controladores y un elemento robot: .. ........ ..... ... .... ... .. .... ... ... 153
D.2.1 Archivo de Configuración .. ............. ... ..................................................... ........... ..... 153
D.2.2 Proceso CONTROLADOR .. ..... ..................... .. .... ........................................... ..... .... 155
Descripción .. ...... ......................... ...................... ... ...... ....... .. ............ ............................. 155
D.2.3 Proceso CONTROLADOR Back ................... .... ....... .......................................... ... .. 155
Descripción ... .... ...................... ...... ..... .. ....... .................. ............................... ......... .. ..... 155
D.2.4 Proceso SIO .... ...... .... ... ....... ........ .. .... .. ...... ... ....... ............ ...... ................................. 156
Programa en Occam : .............. ...... .............................................................................. 156
Nodo en el archivo de configuración: .................. .... ... ....................... .. ... ...................... 156
Descripción ... .. ......... ........ .. ....... ....... ..... ...... ....... ......... .... ......................... ........ ............ 156
Flujo .. ............... ............. .. ... ...... ...... ... ..... ...... .... ........ .. ......... ...... ................... .. .............. 156
Código: ... .... .. .... .. .............. .. .... .. ..... ........ .... ..... ...... ......................................... .. ... .... ..... 157
Forma de compilarlo: ........... ...... ......................... ... .... .................................................. 163
D.2.5 Forma de Ejecutar el Programa: ... ........ ... ... .. ..... ....... .... .......................................... 164
APENDICE E. DOCUMENTACIÓN PROBLEMAS 810442 .. .. .. .................... .. ........ .................... 165
APENDICE F. ENCENDIDO, APAGADO Y COMANDOS BASICOS DEL ROBOT PUMA... 174
E4
LISTA DE FIGURAS
Fig. Descripción Página
1.1 Esquema del CIM 10
1.2 Diagrama a bloques del Sistema 11
1.3 Celda de Manufacturas Flexible (CMF) 14
2.1 Esquema del CIM 18
2.2 Red de Interconexión dinámica del PARDICO 24
3.1 Vista del IMS 8426 y Pin's. 28
3.2 Tarjeta Madre IMS 8008 29
3.3 Enlaces y Switch C004 30
3.4 Distribución de los TRAMS T805 y SIO'S 31
3.5 Diagrama a bloques del Sf 0232 32
3.6 Vista superior del 810232 33
3.7 Diagrama a bloques del 810422 34
3.8 Vista superior del 810422 34
4.1 Interfaz 36
4.2 Cntrolador Paralelo Distribuido. 36
4.3 Configuración de pins entre dos PC 37
4.4 Conexión interfaz 232 38
4.5 Conexión interfaz 422 39
4.6 Tipos de señales 40
4.7 Procedimiento para cambiar de RS422 y RS232 41
(i
4.8 Convertidor 422/232 43
4.9 Descripción de Pins 43
4.10 Esquema de respaldo de 2 transputers-1 interfaz SIO en operación 44
normal
4.11 squema de respaldo de 2 transputers-1 interfaz SIO después de un 45
error
4.12 Envio de mensajes al robot utilizando el proceso activo 46
4.13 Envio de mensajes al robot utilizando el proceso respaldo 47
4.14 Esquema de respaldo de 2 robots-1 interfaz ISO en operación 48
normal
4.15 Esquema de respaldo de 2 robots-i interfaz SIO después de un 49
error
4.16 Envio de mensajes al robot en operación normal 50
4.17 Intercambio de mensajes en operación normal 50
4.18 Intercambio de mensajes con E I ror b,, :::i transmisión 51
4.19 Intercambio de mensajes con error en la recepción 52
4.20 Topología con Rutas Alternas, Canales Virtuales y elementos de la 54
Celda de Manufactura Flexible.
5.1 Distribución de los elementos de la celda y el controlador 56
5.2 Distribución de los procesadores y procesos en el controlador 56
5.3 Contenido del archivo log. txt 57
5.4 Archivos que contienen el plan de trabajo 57
5.5 Inicio de la aplicación 58
5.6 Ejecución de la aplicación 59
5.7 Ejecución de la aplicación e inducción de un error 60
5.8 Distribución de los elementos de la celda y el controlador 62
5.9 Distribución de los procesadores en el controlador 62
5.10 Mensajes de inicio del robot 63
5.11 Mensajes del robot 64
5.12 Flujo de información del controlador en operación normal 65
7
5.13 Flujo de información del controlador después de ocurrido un error 66
A.1 Configuración de la memoria del Transputer 73
A.2 Pinouts SI0232 76
A.3 Pinouts SI0422 77
A.5.1 Registros 82
A.5.2 Registros del Duart 82
0.1 Distribución de procesos según el archivo de configuración 110
0.2 Distribución de canales según el archivo de configuración 110
0.3 a Envío al robot y despliegue de contestacion del robot 111
0.3 b Recepción de comandos desde el host 112
0.3 c Fin del proceso Aplicación 112
0.4 a Proceso de enlace que envía comandos al sio 232 120
0.4 b Proceso de enlace que envía comandos al sio 232 121
0.4 c Proceso de enlace que recibe comandos del sio 232 121
0.5 a Definición de variables y configuración inicial dentro del driver SIO 129
D.5 b Atención a peticiones de transmisión e interrrupciones de eventos. 130
Lectura y escritura de los buffers de transmisión y recepción.
0.5 c Atención a interrupciones de lectura y escritura en puerto 130
0.5 d Envio de caracteres a la red de transputers. Recepción de 131
información de la red de transputers ( caracteres, comandos y
configuración).
0.6 Distribución de procesos y canales según el archivo de 155
configuración
D.7 a Proceso de SIO que recibe y envía comandos del controlador 156
principal al DRIVER
0.7 b Proceso de SIO que recibe y envía comandos del controlador de 157
respaldo al DRIVER
8
1. INTRODUCCION.
La presente tesis es un trabajo dentro del proyecto "Tecnologías de comunicación
Avanzadas en Robótica y Celdas Flexibles de Manufactura" (3] financiado por la
National Science Foundation (NSF) y por el Consejo Nacional de Ciencia y
Tecnología (CONACyT); en él participan los Campus Estado de México y Morelos
del Instituto Tecnológico y de Estudios Superiores de Monterrey (ITESM), y la
Universidad de Texas (UT) en Austin.
El proyecto está estructurado de tal manera que la UT estudiará el problema de
las comunicaciones dentro de robots inteligentes, mientras que el ITESM
analizará el problema de comunicaciones entre los componentes de la celda de
manufactura. El objetivo principal del proyecto consiste en contribuir a resolver el
problema de las comunicaciones entre los elementos de una Celda de
Manufactura Flexible, mejorar la flexibilidad en la planeación de tareas e implantar
tolerancia a fallas.
9
tolerancia a fallas.
La presente tesis está enfocada en lo relacionado a la capa física del modelo OSI
(Open System lnterconection). Se pretende implementar un conmutador el cual
interconectará a un controlador paralelo distribuido (red transputers) con la
interfaz de los elementos (robots) de la Celda de Manufactura Flexible.
1.1 CIM (Centro de Manufactura Integrada).
Un Centro de Manufactura Integrada por Computadora (CIM, ver figura 1.1 ), es
un sistema basado en computadoras que controlan y supervisan una Celda de
Manufactura, la cual consiste a su vez de un grupo de robots y máquinas que de
manera coordinada fabrican productos. Si bien este tipo de centros existen en un
buen número de fábricas en todo el mundo, empiezan a ser inadecuados para las
necesidades actuales. Actualmente un CIM requiere no solamente ser capaz de
producir partes sino ser flexible en cuanto a:
* Planeación: habilidad de reconocer planes en varios formatos, y adaptarse a los
cambios de ambiente o metas.
* Reconfigurabilidad: habilidad de manufacturar nuevos productos o tolerancia a
fallas.
* Detección de fallas y aislamiento: habilidad de detectar, identificar y aislar fallas.
CONTROL ASlRS
CONTROL PUMA
e
80 N i MOITSUBISHI
~-CONVEYOR
CONTROLADOR
Figura 1.1 Esquema del CIM
1.2 CMF (Celda de Manufactura Flexible).
10
Una Celda de Manufactura Flexible (CMF) responde a estos requerimientos.
Específicamente, es una configuración controlada por computadora de lugares de
trabajo que pueden ser adaptados a cambios en la producción (reconfiguración,
detección de fallas) y un sistema de manejo de materiales para fabricar
eficientemente más de un tipo de partes (flexibilidad de planeación) [3].
En este trabajo de tesis se pretende contribuir al mejoramiento de la flexibilidad
del Centro de Manufactura del ITESM-CEM (figura 1) mediante la implantación de
una arquitectura de comunicación entre los elementos de una CMF (robots), y su
controlador.
1.3 ANTECEDENTES.
El ITESM en sus Campus Estado de México (CEM) y Campus Morelos (CM)
11
tienen años de experiencia estudiando celdas de manufactura, enfocándose
principalmente en el diseño de la estructura del hardware del control de la celda,
del software operacional y de comunicaciones entre los elementos de la celda.
Desde princ1p1os de los 90's el ITESM ha participado fuertemente en la
automatización total de Celdas de Manufactura. Primero se trabajó en el diseño y
construcción de un controlador de celda (ver figura 1.2)La figura 1.2 ilustra este
controlador llamado MIP (Módulo de Interfaz). Una PC funge como control de Piso
para que el usuario final pueda administrar al MIP y a los robots conectados a
éste. El MIP está conformado por una tarjeta madre que se encarga de todas las
funciones de multiplexión, y los UPl's que son dispositivos periféricos que se
encargan de empaquetar los bytes que les mandan para ser transmitidos
serialmente. Estos últimos tienen la capacidad de ser programables por el usuario
para efectuar distintas operaciones[1] .
MIP
Taiieta; Perifericas
RS232
RS232
PS232
RS232
Maquinas
Ci.ticuui.a.ti
Maho
Figura 1.2 Diagrama a bloques del sistema
Este diseño trajo consigo las siguientes limitaciones[1 ]:
* Al utilizar una interfaz RS232 entre la computadora (control de piso) y la tarjeta
madre del controlador la cual se encarga de todas las comunicaciones, a
12
velocidades de 2400 bauds se creó un cuello de botella en la transferencia de
datos.
* El envío de información era demasiado lento debido a que la información tenia
que fluir por tres interfaces:
Computadora ----> Interfaz ----> Tarjeta Madre ----> Interfaz ----> UPl's ---->
Interfaz----> Robots
* La arquitectura diseñada no era tolerante a fallas debido a que existían tres
puntos únicos de falla (interfaz) en los que si se generaba un error, producía un
aislamiento en uno o varios elementos (robots).
Tomando en cuenta las limitaciones anteriores se propuso en [3] que el
controlador de la Celda de Manufactura Flexible (CMF) sea un sistema de
procesamiento distribuido (ya que físicamente los componentes se encuentran
físicamente distribuidos); paralelo (porque un grupo de procesadores trabajaran
juntos para tener redundancia) y reconfigurable (para resolver el problema de
tolerancia a fallas).
El Centro de Tecnología de la Información del ITESM Campus Estado de México
continuó con sus investigaciones y se desarrollaron prácticas con alumnos de
Licenciatura en Ingeniería Electrónica, enfocadas al estudio de los transputers
INMOS T805. Aprovechando el estudio realizado sobre los transputers, un grupo
de alumnos de Licenciatura realizaron en Enero 1996 un sistema de Integración
de la Celda de Manufactura que permitiría comunicar el transputer con un robot
(en este caso fue con el robot IBM 7575). Sin embargo en este proyecto no se
contempló que el sistema fuera tolerante a fallas [7].
1.4 PLANTEAMIENTO DEL PROBLEMA.
1 ~ .1
En base a lo expuesto anteriormente se desea implementar una interfaz eficiente
y tolerante a fallas entre el controlador y los elementos de una Celda de
Manufactura Flexible. Esta implementación propondrá mejoras con respecto a los
trabajos en [1 ], [7].
Esta propuesta de tesis está relacionada con la de Mima Salmerón [6], la cual
estuvo enfocada en el estudio y diseño del controlador (transputers) a nivel de la
capa física. Este trabajo de tesis estará enfocado en el estudio de los elementos
de la celda (robots) y las interfaces entre robots y controlador.
Conjuntando ambas tesis se logrará la integración de una Celda de Manufactura
Flexible a nivel de capa física.
La arquitectura del controlador estará conformada por transputers, montados en
una tarjeta (IMS 8008), la cual se instalará en el bus de una computadora
huésped. Vea el capítulo 3 para más detalles de la arquitectura del controlador.
Cada transputer tiene cuatro enlaces de entrada/salida que proporcionan
conexiones punto a punto hacia otros transputers. Esto permite tener sistemas
basados en multi-transputers de varias topologías y tamaños.
La arquitectura de multi-transputers del controlador asegurará un procesamiento
en tiempo real, paralelo y tolerante a fallas [2].
Los elementos de la celda requerirán de una interfaz para comunicarse con el
controlador (figura 1.3), debido a los requerimientos de tolerancia a fallas
explicados en la sección 2.6. Para ello se estudiarán las características de
1-+
comunicación de los elementos de la Celda de Manufactura Flexible.
Entre las características a examinar se tiene: la velocidad, señalización, tipo de
transmisión, líneas de datos, líneas de control, protocolo de comunicación
(RS232, RS422, RS449, Centronics, Cable Coaxial), etc [4].
c:::J Conmutadores
•Inte~
CONTROLADOR
( / ......____ _ ___.
AS~ TORNO
CONVEYOR
Figura 1.3 Celda de Manufactura Flexible (CMF).
1.5 JUSTIFICACIÓN.
El ITESM ha realizado investigaciones sobre tecnología de transputers desde
1994. Entre los proyectos realizados se tuvo la integración de un sistema que
permitiera comunicar el transputer con uno de los robots de la celda de
manufactura del Campus Estado de México. La limitante que presentó esta
investigación es que la comunicación se realizó por medio de mapeo de memoria
y no se contempló el tener dentro de su sistema tolerancia a fallas[?].
También, se desarrolló una interfaz reconfigurable que permite realizar la
comunicación entre los diferentes elementos que constituyen a la CFM,
empleando para ello el transputer T805 de INMOS. La limitante que presentó este
15
sistema es que la reconfiguración de la red de transputers se hace por medio de
alambrado de hardware y no dinámicamente.
En esta tesis se pretende contribuir a la flexibilidad y robustez de la celda de
Manufactura en los siguientes puntos:
1. Reconfigurabilidad: habilidad de manufacturar nuevos productos y tolerancia a
fallas.
2. Detección de fallas y aislamiento: habilidad de detectar, identificar y aislar
fallas.
Mediante la interfaz que se implementará se dispondrán de caminos redundantes
entre robots y controlador, los cuales ayudarán a implantar la tolerancia a fallas.
Respecto a la interfaz con los robots, en esta fase del proyecto se pretende el uso
de RS-232. Esto es porque es más simple y barato que otras interfaces, y la
mayoría de los robots de los cuales está conformada la celda del ITESM-CEM
utilizan dicha interfaz.
El contenido por capítulos de la presente tesis es el siguiente:
Capítulo 1. Se proporcionan los antecedentes, objetivo y justificación del trabajo
de tesis.
Capítulo 2. Se hace un estudio de los robots, que incluye la descripción de los
mismos y sus características para poder interconectarlos con el controlador. Entre
los robots a describir se tienen: Mitsubishi, Puma, Jupiter, etc.
1 (¡
Capítulo 3. Incluye el estudio y descripción de todos los elementos a utilizar con
el controlador. Entre los elementos a mencionar se tienen: Tarjeta IMS 8008,
TRAM 8426, Módulos de comunicación RS232 y RS422, etc.
Capítulo 4. Se presenta la solución planteada en [3] a la problemática actual que
presenta la Celda de Manufactura Flexible (CMF). Dicha solución incluye los
dispositivos de comunicación entre los elementos y el controlador que
incrementen la redundancia en hardware para la entrada y salida de información,
así como todos los programas utilizados; estos programas fueron realizados en
lenguaje Occam.
Capítulo 5. Describe los trabajos realizados para obtener una interfaz
reconfigurable y tolerante a fallas entre el controlador y los elementos de la Celda
de Manufactura Flexible.
Capítulo 6. Se proporcionan las conclusiones y recomendaciones a futuro, con base en las experiencias obtenidas durante el desarrollo de la tesis.
17
2. CARACTERISTICAS DE LOS ELEMENTOS DE LA CELDA DE MANUFACTURA.
En este capítulo se estudian y describen los robots que conforman la Celda de
Manufactura (CIM) del ITESM-CEM. Los robots se clasificaron en dos grupos:
herramientas estándares y de control numérico.
Existe otro conjunto de elementos llamado sistema de control que engloba
aquellos programas utilizados por los robots, pero que tienen la deficiencia de
operar independientemente. Esto es, no son programas capaces de controlar
conjuntamente a todos los elementos de la celda.
La celda de Manufactura del ITESM-CEM está compuesta de los siguientes
elementos (ver figura 2.1)
a) Herramientas estándares y de control numérico.
Fresadora MAHO 700S
Torno GRAZIANO GR300S
b) Dispositivos para mover partes.
Bandas transportadoras ( conveyor 2)
Almacenamiento AS/RS
Robot PUMA
Robot Mitsubishi
Robot Júpiter
c) Sistema de control.
18
Conjunto de programas computacionales que permiten controlar la
operación de cada una de las partes de la celda. Actualmente no coordinan
a todos los elementos de la celda en conjunto; cada uno de ellos se
programa de manera independiente para hacer tareas rutinarias, sin
capacidad de tomar decisiones.
ASIRS
CONTROL ASfRS
CONTROL PUMA
MITSUBISHI
OEl CONVEYOR
CONTROLADOR
Figura 2.1 Esquema del CIM
La figura 2.1 se diseñó en base a la distribución actual del CIM del Tecnológico
de Monterrey Campus Estado de México. A continuación se hace una descripción
general de los diferentes robots de la celda de manufactura [4].
2.1 ROBOT MITSUBISHI.
Este robot es de fabricación Japonesa, constituido por un total de cinco ejes de
libertad servocontrolados y con un actuador final eléctrico; además es de tipo
19
esférico.
El Mitsubishi utiliza como interfaz de comunicación tres diferentes tipos de
conectores. Una interfaz paralela con un centronics, una interfaz serial con un
RS-232-C y una interfaz con equipo externo 1/0.
2.2 ROBOT PUMA.
Este robot es de fabricación sueca y tiene cinco ejes de libertad todos controlados
por servomotores. El actuador es una tenaza de accionamiento neumático. Este
robot es de tipo esférico y su función es interactuar con el torno y la fresa.
Los componentes periféricos para el sistema del PUMA son usados para enviar y
recibir información. Estos periféricos consisten de una terminal CRT y TIY, un
teach pendant (control), disco duro, memoria adicional, y módulos de 1/0.
La transmisión y recepción de datos es a través de la interfaz RS232.
Descripción eléctrica.
Tipo de transmisión
Velocidad
Stop bit
Paridad
Asíncrona: 8 bits
9600
1
ninguna
Cada motor localizado en el Puma contiene un encoder incremental y un
potenciómetro. Los potenciómetros (encoders análogos de nivel alto) son usados
para inicializar el robot.
Los encoders son montados en los ejes (shaft) de cada motor y proveen cambios
de posición y señales de velocidad.
Los motores servo para los ejes más importantes (Joints 1,2,3) están equipados
con frenos electromagnéticos. Estos frenos son activados cuando la energía es
retirada de los motores, así logrando bloquear el brazo en una posición estática.
De esta manera se evita que el brazo colapse.
A continuación se describen las características de cada eje.
Cintura articulación 1 5.7 deg -320 a +320 rotación
Hombro articulación2 3.3 deg -250 a + 250 rotación
Codo articulación3 6.7 deg -270 a +270 rotación
Muñeca articulación4 5.0 deg -200 a +200 rotación
muñeca articulación5 4.6 deg -532 a +532 rotación
2.3 ROBOT JÚPITER.
20
Este robot es de fabricación Norteamericana, constituido por un total de cuatro
ejes de libertad servocontrolados; además cada eje tiene consigo sensores
inductivos para detectar metales ferrosos y no ferrosos hasta una distancia de 50
mm. El actuador es una tenaza de accionamiento neumático.
El controlador servo robot (899-CC) puede comunicarse con otras computadoras
a través del puerto de comunicaciones serial RS232-C, y la programación o
control puede darse desde el Kit (825-TP).
2.4 TORNO Y FRESA.
Son maquinas herrramientas de la celda que funcionan con un programa de
control numérico computarizado.
21
2.5 AS/RS.
Este robot es de fabricación Norteamericana. Todos sus movimientos con los ejes
servo pueden ser descritos en el plano XY: X es la distancia horizontal entre
compartimientos, mientras que Y es la distancia vertical entre compartimientos.
Otros ejes que usa son Z y C. El primero indica movimientos lineales para
desplazarse hacia el interior y exterior del compartimiento, mientras que el
segundo es un movimiento de rotación para poner o quitar paletas en el
compartimiento.
2.6 COMUNICACIÓN CON LOS ELEMENTOS DE LA CELDA.
Debido a la necesidad de comunicación, se requiere de un dispositivo de
comunicación entre el controlador y los elementos de la celda de Manufactura
Flexible ( interfaz y/o conmutador). Para escoger el mejor dispositivo se realizó un
estudio de las características de comunicación de los robots y de los dispositivos
existentes en el mercado actual de Manufactura.
Los elementos (robots), en su mayoría utilizan interfaz RS232, motivo por el cual
el estudio del dispositivo se enfocó a RS232.
A continuación se describen algunas opciones de dispositivos existentes en el
mercado actual de Manufactura.
Controladores de Línea Serie LO RS232 a RS422
Este controlador permite distancias de más de 50 pies entre una PC y cualquier
dispositivo. Además convierte señales RS232 a señales estándares de la
industria RS422 [12]. No ofrece tolerancia a fallas, porque su principal función
esta enfocada a la conversión de señales de RS232 a RS422.
22
Conmutadores serie CA8
Este conmutador permite controlar a través de un dispositivo con interfaz R8232
diversos dispositivos. Este switch tiene excelentes características técnicas como:
comunicación bidireccional, opción para interfaz R8422, switcheo rápido, etc.,
que pudieran ayudar a controlar una celda de manufactura(13].
Conmutadores serie MD8
Permite la conexión de múltiples dispositivos R8232.
Interfaz 810232 y 810422 de INM08
Algunas de las características técnicas son: interfaz R8 232 y 422, protección de
transmisión de datos en ambientes ruidosos utilizando R8 422, comunicación
bidireccional, distancias mayores de 50 pies, tolerancia a fallas mediante el uso
de caminos alternos, control de dos dispositivos a través de una interfaz, etc.
Todos los conmutadores y controladores que se describieron requieren de algún
tipo de adaptación para comunicarse con la tarjeta 8008. Esto es porque ninguno
de ellos cuenta con un driver capaz de interactuar con la familia de Transputer
Transtech, por lo que sería necesario adaptar un tipo de interfaz como la
desarrollada en el trabajo de tesis (5).
Los únicos que son completamente compatibles con la familia de transputers
transtech son la interfaz 810232 y 810422. Además tienen la característica de
poder conmutar como los dispositivos mencionados anteriormente.
La interfaz 810232 así como el 810422 están compuestos de un transputer de 16
bits T2, memoria 64 Kbytes, y un DUART (Dual universal asyncrhronous
-, ~ --'
receiver/transmitter).
El DUART proporciona dos canales de comunicación (transmisión y recepción)
asíncronos bidireccionales que se comunican directamente con dispositivos
RS232 como: monitores, impresoras, modems, instrumentos de laboratorio, etc.
El transputer permite la comunicación con una red de transputers externa y aloja
los drivers los cuales manejan las interrupciones y funciones que realizará el
DUART para enviar información a los puertos de comunicación.
2.7 DESCRIPCIÓN DEL CONTROLADOR PARDICO (PARALLEL ANO DISTRIBUTED INTELLIGENT CONTROLLER).
PARDICO es un controlador paralero distribuido para un celda de manufactura
flexible, que consiste de varios robots y máquinas interactuando en la
construcción de productos. Los objetivos de diseño de este controlador son:
a) Flexibilidad en la planeación
b) Reconfigurabilidad.
c) Tolerancia a fallas.
Para poder alcanzar los objetivos planeados, se propone el uso de una
arquitectura reconfigurable basada en transputers T805.[2]
Las redes dinámicas no tienen enlaces fijos sino conmutados conectando
cualquier entrada con cualquier salida del conmutador. Las posiciones del
conmutador se establecen con software, ya sea por datos o control de mensajes.
Los conmutadores grandes son difíciles de construir por lo que se usan redes
dinámicas hechas por conmutadores de 2x2.
2-l-
Las redes dinámicas tienen dos ventajas sobre las redes estáticas. Primero,
permite la reconfiguración que necesita la celda de manufactura flexible.
Segundo, ayuda a aislar y recuperarse de fallas.
Los enlaces de los transputers establecen comunicaciones punto a punto. Para
lograr la reconfigurabilidad, el PARDICO usa el conmutador C004, que es un
conmutador programable de 32x32 que nos permite construir una topología
dinámica en la red de procesadores, como lo muestra la siguiente figura.
Celda de Manufactura
t i i Conmutador 1/0 G G i t t i
I· ·I I· ·I I· -G 1 2 3 )111
i • • t C004
Figura 2.2 Red de interconexión dinámica del PARDICO
3. CARACTERÍSTICAS DE LOS ELEMENTOS A UTILIZAR CON EL CONTROLADOR.
2:'i
En este capítulo se estudian y describen todos los elementos que conforman al
controlador. Los elementos son explicados e ilustrados detalladamente, para
poder entender la tecnología que utiliza el controlador. Los elementos que utiliza
el controlador son: Tarjeta IMS 8008, módulos TRAM's, y las interfaz 232 y 422.
Estos elementos residen físicamente en una computadora llamada huésped. Esta
computadora se encarga de centralizar toda la Información de la celda de
Manufactura Flexible, y posteriormente distribuir todas las tareas a cada uno de
los elementos correspondientes. Ver sección 3.1 características del huésped.
El controlador se basa principalmente en una Tarjeta IMS 8008, la cual se
encarga de realizar todas las conexiones de enlaces entre los módulos TRAM's
formando una red de transputers redundante. Los módulos TRAM 's residen en la
tarjeta, así como también los SIO 232 y 422 que se conectan a los elementos de
la celda a través de un cable 089. Cada módulo SIO tiene la característica de
tener integrado dos puertos seriales, y a cada uno se le conecta un robots. De
esta manera cada SIO puede controlar dos robots al mismo tiempo.
Cada transputer estará realizando diversas tareas específicas entre las cuales se
tiene la asignación de funciones para los robots. Estas funciones son transmitidas
2 (¡
desde los transputers pasando por cualquiera de los SIO's, para finalmente llegar
a los elementos de la celda de manufactura (robots); y viceversa.
3.1 COMPUTADORA HUÉSPED
La computadora huésped está conformada de ciertas características y elementos
que a continuación se listan.
3.1.1 CARACTERÍSTICAS
Procesador:
Monitor:
Disco duro:
Memoria:
Pentium 166 MHz.
SVGA.
1 GB.
24 MB RAM
Sistema operativo: Windows 95
Software: Occam y C Tool Set
El huésped utiliza Occam para los procesos que corren en los SIO's 232 y 422,
mientras que C Tool Set es utilizado para los procesos que corren en la red de los
transputers T805. Todos los procesos ya sean de "Occam" o "C" son llamados
desde Occam
3.1.2 ELEMENTOS
Tarjetas:
Transputers:
4MB en RAM).
Módulo:
Módulo:
IMS 8008 (Tarjeta Base para los transputers).
5-8 Módulos TRAM IMS 8426 (T805 - 25 MHz con
ALX-232 conmutador para la interconexión.
ALX-422 conmutador para la interconexión.
Estos elementos serán descritos a detalle a continuación.
27
3.2 MÓDULOS IMS 8426 (T805 - 25 MHZ).
3.2.1 DESCRIPCIÓN.
El transputer es un microprocesador para arquitecturas paralelas desarrollado por
INMOS. El nombre de transputer se deriva de la palabra transistor y computadora
(trans de transistor y puter de computer) [12].
El transputer es un microprocesador de propósito general que integra en un sólo
circuito las facilidades de procesamiento, comunicaciones y memoria. Fue
desarrollado en 1980, con un lenguaje de programación llamado OCCAM. Este
microprocesador tiene características de concurrencia y sincronización.
Los transputers son poderosos microprocesadores debido a su hardware, pues
incluyen protocolos de comunicación que han sido incorporados en el circuito
integrado.
Los módulos IMS 8426 son TRAM's constituidos por un transputer T805 - 25
MHz con 4 M8 en RAM. Estos módulos se colocan en las ranuras (slots) de la
tarjeta IMS 8008 descrita anteriormente. Dependiendo de su colocación dentro de
la tarjeta madre, forman diferentes topologías de transputers.
Los transputers una vez colocados en la tarjeta IMS, esta en conjunto con los
transputers proporcionan las señales eléctricas necesarias, soporte mecánico y
usualmente una interfaz con la tarjeta 8008.
3.2.2 CARACTERÍSTICAS.
A continuación se muestra la configuración de los pines del módulo IMS 8426 y la
descripción correspondiente de cada pin.
o Lllk2out O Link2r, o vcc o Link101.1t o Link1 in o LinkSpeedA o LuSpeed8 o Oockln (5 MHi)
Unk3in o Lir.k3out e Gf\O o LinkOin o LinkOout o notError o Res et O
Anafyse O
Figura 3.1 Vista del IMS 8426 y pin's.
Pin In/Out Función Servicios del Sistema
VCC,GND Fuente de alimenta v retorno
Clockln in Señal de reloj 5 MHz
Reset in Inicio del transputer
Analvse in Análisis de error del transouter
notError out Indicador de error del transouter
Enlaces
Linkln0-3 in Entradas enlace serie INMOS al
Transputer
Linkout0-3 out Salidas enlace serie INMOS del
transputer
LinkspeedA,B in Selección de velocidad del enlace del
transouter
Tabla 3.1 Descripción pines IMS 8426.
3.3 Tarjeta IMS 8008
28
No. Pin
3, 14
8
10
9
11
13,5,2, 16
12,4,1,15
6,7
La familia de transputers T805 son procesadores que físicamente pueden
conectarse en las ranuras de una tarjeta madre de formato PC-AT llamada IMS
8008 (8]. Esta tarjeta soporta hasta 1 O transputers conectados en ranuras, cada
una de las cuales tiene cuatro conexiones para enlaces INMOS. Estos enlaces
son numerados de O a 3 y las ranuras son numeradas de O a 9 (ver figura 3.2).
s 6
TRAM slots
2 o 4 7
Jumpers
3 8
Slot 9
Patch header socket, P1
Switches
/
D-type cónnector, P2
Figura 3.2 Tarjeta Madre IMS 8008
29
La comunicación entre los transputers es asíncrona, y punto a punto . Un enlace
es una implementación física del concepto de Occam de un canal. Cada enlace
es bidireccional, por lo que implementa dos canales con direcciones opuestas.
Cada enlace consiste de dos pins, "out" y "in", logrando así la interconexión de
transputers mediante el pin "out" de uno y el pin "in" de otro. La comunicación en
los enlaces se lleva a cabo de acuerdo a un protocolo que nos dará una
sincronización dinámica.
La velocidad de un transputer es de 25 MHz y sus señalizaciones eléctricas en
los enlaces corresponden a los estándares de TIL.
:rn
Las 1 O ranuras del IMS 8008 están conectadas en pipeline, de tal manera que el
enlace 2 de la ranura O es conectado con enlace 1 de la ranura 1, y así
sucesivamente con el resto de las ranuras. Los enlaces O y 3 de cada ranura
están conectados al conmutador de enlace IMS C004, y éste a su vez es
controlado por un transputer T225 que viene integrado en la tarjeta IMS 8008.
o so
al bus PC
1 T1
S1 [fü tfD S6
2 1 2 1 21 21 21 2 1
...._. T3 ...._.SIO
2
º! !' o 3 :! 3
o t' º! t, ,t !' o 10 1 11 2 14 5 i15 6 16
IMSC004
Puntos de conexión del C004
Número del enlace correspondiente al transputer conectado en la ranura (slot) sx = número de la ranura (slot) en la tarjeta IMS 8008
Figura 3.3 Enlaces y Switch C004
S7
2
o 3
En el caso de que no hubiera algún procesador en alguna de las ranuras, se
utilizan unos jumpers que permiten interconectar a las ranuras que se encuentran
a los extremos de la ranura que no tiene procesador .
El IMS C004 es un conmutador de enlace programable con 32 caminos en modo
crossbar. Esto permite la configuración de los transputers en diferentes redes
mediante el uso de un software.
También estarán conectados a las ranuras de la tarjeta madre IMS 8008 las
interfaces de comunicación SI0232 y 810422. Estas interfaces de comunicación
se utilizarán para realizar la interconexión entre el controlador paralelo distribuido
31
y la interfaz de cada uno de los elementos de la celda. Ver figura 3.4
5 6 2 o 4 7 3 8 9
SI01
1 1
tJ 1805 1805
n tJtJ
Figura 3.4 Distribución de los TRAM's T805 y SIO's.
En la figura 3.4 se ilustra que los SIO's están conectados a los slots 1,5,6, y 2 respectivamente.
3.4 INTERFAZ DE COMUNICACIÓN 510232.
3.4.1 INTRODUCCIÓN.
Esta interfaz permite realizar la conversión del enlace serial del transputer a un
enlace serie estándar RS232. La interfaz se coloca dentro de las ranuras (slots)
de la tarjeta base IMS 8008. Sus dimensiones son del tamaño de 2 TRAM (T805)
por lo que ocupa dos ranuras de la tarjeta.
El módulo está conformado por los siguientes elementos (ver figura 3.3).
• Un TRAM (225) de 16 bits
• 64 Kbytes SRAM
• Dual Universal Asynchronous Receiver/transmiter (DUART).
• Drivers
• Puertos de comunicación de entrada y salida.
32
El OUART permite programar la velocidad de baudios, bits de paro, paridad, y
tamaño de la palabra. Además provee dos canales asíncronos full-duplex
(transmisión I recepción) que pueden conectarse directamente bajo estándares
industriales con monitores, impresoras, modems o cual otro dispositivo RS-232. El
SRAM permite que drivers, software y el OUART residan en el mismo TRAM.
16-Bit RS-232
Transputer Dual ú Driver
-UART ~ RS-232
Driver
64 KBytes 1 SRAM
. lnterrupt Controller
Figura 3.5 Diagrama a bloques del 510232
3.4.2 INSTALACIÓN.
La interfaz 810232 puede colocarse en cualquier tarjeta TRAM estándar. Para
colocar la interfaz es necesario alinear la pestaña (un triángulo pequeño de color
blanco cerca del conector J1) con una marca similar localizada en la tarjeta madre
TRAM (ver figura 3.6).
La tarjeta madre TRAM provee todas las señales necesarias para que el TRAM
opere correctamente. Estas señales incluyen + 5 Volts y tierra, reloj de 5 Mhz,
parámetros de velocidad de enlace y cuatro conexiones de enlace por TRAM. Los
+- 12 Volts son generados por un convertidor OC a OC.
JPS es una cabeza de dos pines usado para definir interrupción. Esta interrupción
es programable para que sea positivo o negativo.
El pin1 de la cabeza va conectado directamente al controlador de interrupción
PAL el cual es conectado a un resistencia de 1 OK ohms. Pin2 es conectado
directamente a tierra.
I DC-DC CVTR ! !RS-232 DRIVER!
! RS-232 DRIVER!
TRANSPUTER I J16•1 PORT B
1 • • 1 JPS
""--- Pin 1
Figura 3.6 Vista superior del 510232
3.5 INTERFAZ DE COMUNICACIÓN 510422
3.5.1 INTRODUCCIÓN.
Esta interfaz tiene algunas características diferentes a la interfaz RS232 descrita
en la sección 3.4. A continuación se ilustra el diagrama a bloques del 810422.
Esta figura muestra la diferencia entre el tipo de driver de la figura 3. 7 con la
figura 3.4 de la sección 3.4.
16-Bit Transputer
64 KBytes SRAM
Dual UART
lnterrupt Controller
RS-422 Driver
RS-422 Driver
Figura 3. 7 Diagrama a bloques del 510422
La instalación, descripción de hardware, mapeo de la memoria del transputer,
programación de registros, registros del Duart, protocolo de comunicación, etc.,
son iguales a los del SI0232 descrito en la sección 3.4.
A continuación se ilustra en la figura 3.5 una vista superior del SI0422, el cual
varía en algunos de sus componentes en comparación con el SI0232. Ver figura
3.6 sección 3.4.1 para ver las diferencias entre los SIO's .
....-------.""l
PORT 8 1 Address Decode I
i:l D l 1nterrupt Control!
[J D RS422 DRIVERS
=ORT AD Pin1 tJ .. ~T-R_A_N-SP_l_lT-ER---,
1 • • 1 JPS
""-._ Pin 1
Figura 3.8 Vista superior del 510422
15
4. SOLUCION PROPUESTA.
4.1 PROPUESTA.
En esta tesis se implementaron dispositivos de comunicación entre los elementos
y el controlador que incrementan la redundancia en hardware para la entrada y
salida de información. Estos dispositivos están basados en el uso de switches, y
permitirán que la Celda de Manufactura Flexible (CMF) sea tolerante a fallas (ver
figura 1.3).
La figura siguiente muestra la interfaz propuesta. Es una arquitectura de conexión
con una interfaz como dispositivo intermedio para el control de dos transputers
con dos robots (ver figura 4.1 ).
Esta arquitectura permite la reconfiguración dinámica. Esta configuración se lleva
a cabo mediante los enlaces de los transputer, el switch C004 y las interfaces
SIO's 232 y 422 utilizadas para la intercomunicación entre el controlador y los
elementos de la celda de manufactura permitiendo recuperarse en caso de
cualquier falla.
Es importante hacer mención (sección 2.6) que las investigaciones realizadas
anteriormente por el ITESM [1,5,7] no soportaban reconfiguración dinámica. Con
esta nueva arquitectura propuesta se pueden recuperar las fallas, pues utilizando
la red dinámica de los transputers y las interfaces SIO's, se tienen diversos
36
caminos entre los transputers y los elementos de la celda de manufactura, y así
poder sobre pasar cualquier enlace o procesador que falle.
CONTROLADOR
TRANS1 TRANS2
CONMUT.11.DOR RS23.oRS422
ROBOT1 ROBOT2
e-= CELDA DE ROBOTS
Figura 4.1 Interfaz
La figura 4.2 muestra a detalle el controlador paralelo distribuido el cual incluye:
a) Tarjeta base IM8 8008 (Arquitectura reconfigurable de t805).
b) 810232
c) 810422.
Las letras w. x, y, z representan a cualquier elemento de la celda, que se requiera
conectar a las interfaces 810232 o 810422 (ver figura 4.2).
Figura 4.2 Controlador paralelo distribuido.
Las ventajas de este esquema es que cada transputer puede dedicarse a
controlar un robot, además de que si un transputer falla entonces la interfaz
permitirá que el otro transputer conectado se encargue de las tareas de los dos
robots Por otro lado, se tiene el riesgo que si el switch 810232 o 810422 falla ,
ocasiona el aislamiento total de los robots con el controlador. Este último
problema no será atacado en esta tesis, sino en una fase posterior del proyecto
[3].
Una vez descritos los componentes principales que se utilizan en el desarrollo de
esta tesis, a continuación explicaremos de qué manera se conectó el conmutador
con los diferentes robots.
4.2 CONEXIÓN INTERFAZ RS232.
Para la interconexión entre el controlador paralelo distribuido y los elementos de
la celda se diseñaron cables con conectores 089 en sus extremos con la
configuración especificada en la figura 4.3.
PC 1 Pin Pin PC2 TX 3 2 RX RX 2 3 TX RT8 7 1 DCD CTS 8 D8R 6 4 DTR DCD 1 7 RTS
8 CT8 DTR 4 6 DSR
Figura 4.3 Configuración de Pins entre dos PC's
38
Los Pin 7 y 8 se conectan entre ellos en cada uno de los conectores para
completar las señales y no se queden los dispositivos (PC o robot) esperando una
señal de RTS (Ready To Send).
A continuación se muestra en la figura 4.4 la conexión física del controlador con 2
robots.
ROBOT1
Puer1o A o
DB9 PC
IMS 8008 SI0232:~ Cable
ROBOT2 o
J DB9 PC
Puerto B
Figura 4.4 Conexión inteñaz 232.
4.3 CONEXIÓN INTERFAZ RS422.
Debido a que en la Celda de Manufactura Flexible no existe actualmente ningún
robot que maneje la interfaz RS422, se diseñaron cables con conectores 089 y
un convertidor RS422/232 para la interconexión entre el controlador paralelo
distribuido y los dispositivos ya sean Robots o Pc's, como se muestra en la figura
4.5.
IMS 8008
089 089 PLlerto B
Convertidor RS422 a RS232
Convertidor RS422 a RS232
Figura 4.5 Conexión interfaz 422.
ROB011 o
PC
ROB012 o
PC
4.4 DISEÑO E IMPLEMENTACIÓN CONVERTIDOR RS422/RS232
.19
El convertidor de RS422 a RS232 que se muestra en la figura 4.6, es una tarjeta
que mide 4cm de largo x 3cm de ancho, la cual es utilizada para poder convertir
las señalizaciones de la interfaz 422 a 232 .
Las señales que se utilizarán son transmitidas mediante una comunicación digital
ya sea paralela o serial. En este caso se uso la comunicación serial. Las señales
que se utilizan son señales Diferencial, TTL (simple), y señal RS232.
5 1----+
o
Señal TTL H=5V, L=OV
.j.()
5
+ o
:1 >------+ 1
Señal Diferencial -+ SV RS422
+12 ---+------
-12
Señal -+ 12V RS232
Figura 4.6 Tipos de Señales.
Debido a que el protocolo RS422 transmite señales diferenciales, es necesario
covertirlas a señales TTL y después a señales RS232 (Figura 4. 7). Para ello, es
necesario utilizar el convertidor RS422/RS232.
Se utilizaron dos chips SN75176A Differential Bus Transceiver y un chip MAX232
Dual EIA-232 Driver/Receiver.
-l-1
422 TX TTL 232
TX
SN75176A MAX232
RX 1
1
TIL 1
RX
/
SN75176A \ I Señal Diferencial Señal Simple Señal RS232
Figura 4. 7 Procedimiento para cambiar de RS422 a RS232.
4.4.1 INSTALACIÓN.
El convertidor se instala de un extremo a una punta del cable 089 que esta
conectado en el puerto A o 8 del 810422, y en el otro extremo se conecta directo
a cualquier dispositivo externo (PC o robot). La figura 4.5 ilustra la instalación del
convertidor.
4.4.2 DESCRIPCIÓN DEL HARDWARE.
A continuación se describen los elementos que conforman al convertidor como se
muestra en la figura 4.8.
Cantidad
2
1
1
1
1
Descripción
SN75176A Differential Bus Transceiver.
MAX232 Dual EIA-232 Driver/Receiver.
Eliminador de Baterías.
Circuito Integrado 7805.
Conector 089 conexión al módulo 422.
1 Conector DB9 conexión a la PC o Robot.
El convertidor que se ilustra en la figura 4.8 tiene 6 pins en el lado izquierdo, los
cuales se conectan a una punta del cable DB9 que esta conectado directamente
al 810422. Así mismo del lado derecho hay 3 pins, los cuales se conectan
directamente al puerto serial de un dispositivo externo (PC o Robot).
En la figura 4. 9 se describen cada uno de los pins mencionados anteriormente y
que se muestran en la figura 4.8.
4.5 TOLERANCIA A FALLAS.
Para la implementación de Tolerancia a Fallas en la Celda de Manufactura
Flexible, se proponen dos esquemas de redundancia en Hardware, es decir
usando replicacion en alguno de los elementos de la celda. Para el primer
esquema la redundancia se encuentra en los procesadores; existirán dos
procesadores por cada robot . En el segundo esquema se hará la redundancia
con ayuda de los elementos de la Celda de Manufactura (robots); existirán dos
robots por cada procesador. A continuación se describen ambos casos.
4.5.1 REDUNDANCIA CON DOS PROCESADORES.
Para resolver la falla de un procesador , se usa la redundancia en hardware
mediante un procesador de respaldo. Dicho esquema ya fue probado en
desarrollos anteriores[14].
En nuestro diseño, en caso de que falle un procesador, el procesador que está
conectado a la misma interfaz puede tomar el lugar del otro, ejecutando el
programa que estaba ejecutando el primero.
Lo anterior es posible gracias a que la interfaz 810232 hacia el robot tiene la
característica de manejar dos enlaces a sus robots correspondientes y conmutar
un enlace de un robot a otro por medio de una matriz de conexión 2X2 [2].
Además, como el transputer puede ejecutar varios procesos de forma
[ ·-·®· :J 12ov de
Baterías
o o = o 9\/
rn y Pins ~\ 7 PC X 2 8 o '.) ROBOT
rn 2 9 e p
E
ºo
Figura 4.8 Convertidor 422/232.
Pin Descripción Pins conectados al puerto del cable 089 1 GND 2 Tx+A 3 Tx- B 4 Rx+ B 5 Rx- A 6 5 Volts Pins conectados al puerto serial (PC o Robot) 7 GND 8 Rx 9 Tx
Figura 4.9 Descripción de Pins.
concurrente, un solo procesador puede, de ser necesario, encargarse de manejar
a dos elementos de la celda ejecutando dos procesos, uno primario ( operación
normal) y uno secundario que sirva como respaldo de su procesador vecino.[14]
T1 T8cri
PROCESO . PROCESO PRINCIPAL ' RESPALDO
DE T1 DE T2
ELEMENTO 1
T2 T8cri
PROCESO : PROCESO PRINCIPAL ' RESPALDO
DET2 : DET1
;
SIO 1 T225
ELEMENTO 2
Figura 4.1 O Esquema de respaldo de 2 transputers -1 interfaz 510 en
operación normal
Durante la operación normal (figura 4.1 O), cada proceso principal manda
instrucciones a su elemento correspondiente de la celda, mientras los procesos
de respaldo se encuentran en espera de un error. En el momento en que ocurre
un error (figura 4.11) en el transputer T2, por ejemplo, el proceso en T1 que sirve
como respaldo del proceso en T2 es notificado e inicia un proceso idéntico al que
se encuentra en T2 , según el último estado válido en el que se quedó T2, y
continúa enviando instrucciones al elemento de la celda que controlaba el
transputer T2 antes de ocurrir el error . En la figura 4.11 puede observarse que el
elemento de la celda sigue recibiendo instrucciones de forma transparente
gracias a que la interfaz SIO 232 puede conmutar la fuente de donde recibe sus
comandos [14].
T1 T805
PROCESO ; PROCESO PRINCIPAL ' RESPALDO
DE T1 : DE T2
' ¡ I
_ J~-E-LE-M-1E-NT-O~
SIO 1
T2 T805
PROCESO : PROCESO PRINCIPAL , RESPALDO
DE T2 : DE T1
T225 * ERROR i t t
ELEMENTO 2
Figura 4.11 Esquema de respaldo de 2 transputers - 1 interfaz 510 después
de un error
Para la interacción entre la interfaz y la red de transputers se utilizó un proceso
adicional, que llamaremos" proceso enlace". Dicho proceso está configurado para
recibir instrucciones tanto del proceso activo como del proceso de respaldo y
enviarlas de forma adecuada al driver, de tal forma que lleguen al puerto
correspondiente del robot. En la figura 4.12 se ilustra el intercambio de mensajes
en el caso en el cual el proceso activo envia comandos al elemento de la celda de
Manufactura (robot). El proceso activo envía un carácter al proceso enlace, el
proceso enlace agrega las etiquetas necesarias para construir un mensaje que
será interpretado por el driver de tal forma que lo reenviará al puerto A como el
caracter original para finalmente llegar al robot. Cuando el robot contesta se sigue
el mismo intercambio de mensajes pero en sentido inverso; de tal forma que
ahora el robot envía un caracter de regreso, el driver lo estructura para ser
enviado al proceso enlace y finalmente el proceso activo recibe el caracter
original.
IU-:D DE TIUNSPl TERS SIO 232 ... - - . -~ - - -- .. - . : Tl
1 I Proceso Aceivo
: T2
- . '
' T225
' . , _ 1 '¡ t ' , '', j Pl'Oceso EnJace i ,, '
, ' ' , ' .
Puerto A:
ca,·acter
n L....J
Puerto n:
1
, 1 ' ; o-- : [ ___ ----- -- ------- ----------------_: J PnK'.l'SO lh-spald«j !
D Robot
Figura 4.12 Envio de mensajes al robot utilizando el proceso activo
En el momento en que falla el proceso activo entrará en su lugar el proceso de
respaldo usando el mismo intercambio de mensajes que se mencionó en el
parrafo anterior. Esto es posible gracias a que el proceso enlace esta preparado
para recibir información tanto del proceso activo como del proceso de respaldo y
procesarla de tal forma que se puede seguir enviando mensajesa por medio del
proceso driver al mismo puerto. Para el ejemplo ilustrado en la figura 4.12 y 4.13
se utiliza el puerto A. ( Ver Diagrama de Flujo y Pseudocódigo en APENDICE D)
RED DE TIU\Sl'l ºTERS SIO 232 ----------- ----------, Tt . : - ---- - -- - - - - - -- ------- - - . -- - - -- - - -,
l'ue110 B:
() "----../ ·----- --- - - - - - - ------ - - - - - - - -------
Proceso Rcspahh
Figura 4.13 Envio de mensajes al robot utilizando el proceso respaldo
4.5.2 REDUNDANCIA CON DOS ROBOTS.
Para resolver la falla de un robot , se usa la redundancia en hardware mediante
un robot de respaldo.
En nuestro diseño, en caso de que falle un robot , otro robot con las mismas
características del primero y conectado a la misma interfaz puede tomar su lugar,
de tal manera que el proceso controlador del robot ejecuta el cambio de puerto
del puerto principal al puerto secundario , para que el robot de respaldo pueda
reemplazar al robot primario.
Lo anterior también es posible gracias a que la interfaz SI0232 hacia el robot
tiene la característica de manejar dos enlaces a sus robots correspondientes y
conmutar un enlace de un robot a otro por medio de una matriz de conexión 2X2
[2].
1
____ , , __
T1 T805
8
• . . . . . . . . .
ELEMENTO Robot 1
SIO 1
PC= Proceso Controlador
T225
ELEMENTO Respaldo
Figura 4.14. Esquema de respaldo de 2 Robots -1 interfaz 510 en operación
normal
Durante la operación normal (figura 4.14), el proceso controlador manda
instrucciones a su elemento correspondiente de la celda (robot 1 ), mientras el
elemento respaldo se encuentran en espera de un error. En el momento en que
ocurre un error (figura 4.15) en el robot 1, el proceso controlador se percata de la
falla y automáticamente cambia de puerto para asignar tareas al elemento de
respaldo.
~----·-·
I . . . _os
1 ~ 1 "-/
. X
t
* ELEMENTO Robot 1
SIO 1 T225
¡ ELEMENTO
Respaldo
PC= Proceso Controlador
Figura 4.15 Esquema de respaldo de 2 Robots - 1 interfaz 510 después de un
error
Para la interacción entre la interfaz y el transputer se utilizó un proceso adicional,
también llamado " proceso enlace" el cual esta dividido en proceso de transmisión
tx y proceso de recepción rx. Dicho proceso está configurado para recibir
instrucciones del proceso controlador y enviarlas de forma adecuada al driver, de
tal forma que lleguen al puerto correspondiente del robot. En la figura 4.16 y 4.17
se ilustra el intercambio de mensajes en el caso en el cual el proceso controlador
envia comandos al elemento de la celda de Manufactura (robot). El proceso
controlador envía un carácter al proceso enlace, el proceso enlace agrega las
etiquetas necesarias para construir un mensaje que será interpretado por el driver
de tal forma que lo reenviará al puerto A como el carácter original para finalmente
llegar al robot. Cuando el robot contesta se sigue el mismo intercambio de
mensajes pero en sentido inverso; de tal forma que ahora el robot envia un
carácter de regreso, el driver lo estructura para ser enviado al proceso enlace y
finalmente el proceso controlador recibe el carácter original.
RED DE TRANSPUTERS SIO 232 r--·s----- · --- ------- ------ --.
Tl : : T225 : 1' 1 1
1 : : a¿ T, ,__.:+t-iq,.....1..-e+--a-;c_a_r.acter Puerto A:
1
caracter
1 1
Robotl
Proceso I G ' on1.-olado1· : R\ 4+--;-.~--
I I
~_'!_o~<'~ ~n~c~ _ J Proceso Driyer
0)--1 Robot2 I Puerto B:
' 1 '----- --------------- -- --------------- - .
Figura 4.16 Envio de mensajes al robot en operación normal
caracter
en ter activar
etiqueta;enter
time out
ack etiqueta; ack
Proceso Tx Rx
Controlador Proceso Enlace Proceso Enlace Proceso Driver
ac
Robot
Figura 4.17 Intercambio de mensajes en operación normal
50
En el momento en que el caracter es enviado del proceso controlador al proceso
enlace se inicia un temporizador el cual especifica que después de cierto tiempo
si el proceso enlace "Tx" no puede transmitir entonces envia un mensaje de error
al proceso controlador. El proceso controlador de inmediato cambia de puerto
para enviar el caracter nuevamente. Ver figura 4.18.
caracter
time out
cambio puerto
caracter
ca1·acte1·
Proceso Tx Rx Controlador Proceso Enlace Proceso Enlace
Proceso Driver
Robot
Figura 4.18 Intercambio de mensajes con error en la transmisión
.'il
En el caso en que el carácter enviado del proceso controlador al proceso enlace
sea un "ENTER" o fin de comando, se inicia un temporizador el cual especifica
que después de cierto tiempo si el proceso enlace "Rx" no ha recibido un
reconocimiento de comando del robot a través del driver, se asume que el robot
generó un error por lo que el proceso enlace Rx envia al proceso controlador un
mensaje de error. El proceso controlador envia un mensaje de cambio de puerto
Ver figura 4.19.
caracter
en ter
ambio de puert enter
eti
time out
error
tivar
ack
Proceso Tx Rx
time out
time out
e 1queta;ack
Controlador Proceso Enlace Proceso Enlace Proceso Driver
ack
Robot
Figura 4.19 Intercambio de mensajes con error en la recepción
52
Al evaluar los dos esquemas de tolerancia a fallas en donde en el primero se
hace uso de un procesador extra y en el segundo de un robot extra, se concluyó
que el segundo repercute en el incremento del costo del sistema debido al uso de
un robot idéntico adicional . Por consiguiente, se propone el primer esquema el
cual es menos costoso y complementa la tolerancia a fallas. Considerando lo
anterior, el esquema de tolerancia a fallas para la Celda de Manufactura Flexible
queda complementado con el trabajo desarrollado en la tesis [14) como se ilustra
a continuación .
En la figura 4.20 se presenta la topología de la red de transputers con las rutas
alternas y los canales virtuales propuesta en el trabajo [6] y la distribución de
procesos para el controlador de la celda de Manufactura Flexible propuesta en el
trabajo [14]. Los transputers T1 al T 4 contienen un proceso controlador primario
(PC) y un proceso controlador de respaldo correspondiente a su transputer
vecino. Los transputers son vecinos si se encuentran conectados al mismo
módulo SIO, por lo que son vecinos entre sí el transputer T1 con el T2, y el
transputer T3 con el transputer T 4 . El transputer del módulo SIO y que no
pertenece a la red del controlador, contiene un proceso D o driver; que es el
proceso interfaz entre el elemento de la celda y la red de transputers, y dos
procesos S o SIO, que son los encargados de recibir mensajes de la red de
transputers y construir un nuevo mensaje que pueda interpretar el proceso Driver
para ser mandado posteriormente al robot. En este transputer se tienen dos
procesos SIO porque cada proceso SIO debe estar conectado a un proceso
controlador. De esta forma un módulo SIO con dos procesos SIO manejará a dos
procesos Controladores vecinos. Existe además un procesador T5 que contiene a
un proceso monitor el cual, con ayuda de otros monitores distribuídos en la red ,
detecta algún error en los procesos controladores o en los procesadores e inicia
las medidas de contención adecuadas; iniciar un proceso de respaldo o reiniciar
el sistema en caso de error fatal.
Mediante el uso de rutas alternas y canales virtuales los transputers o
procesadores tienen varias opciones de respaldo para comunicarse en caso de
que un enlace entre procesadores falle. Por otro lado, la interfaz SI0232 hacia los
robots tienen la característica de manejar dos enlaces a sus robots
correspondientes y conmutar un enlace de un robot a otro por medio de una
matriz de conexión 2X2 [2]. Las rutas virtuales también hacen posible que el
proceso M o monitor tenga comunicación con todos los procesos controladores y
pueda determinar el momento en que ocurre un error. Para este esquema de
respaldo, los procesos SIO (S) estan preparados para recibir instrucciones tanto
del proceso controlador (PC) principal como del proceso controlador de respaldo
(dormido en el procesador vecino). Cuando ocurre un error simplemente deja de
recibir mensajes del proceso principal y recibe los del proceso que entra en
sustitución, y construye un nuevo mensaje para el proceso driver, por lo que dicha
transición es transparente para el proceso driver, que sigue recibiendo mensajes
con un contenido, el puerto destino del SIO y alguna información de configuración
extra. Para el caso planteado el módulo SIO funciona como una matriz de 2
entradas ( el proceso controlador principal y el proceso controlador de respaldo) y
una salida (el puerto correspondiente al elemento de la celda).
Elemento 3
R.l7'TAALTER~:\ 1 r•- 11••-
11• .. ••-
11•
11••-
11••-
'i =
TI
® ··~ Al host ,,,,,,,,,,,,,,, ,....._---,--.---'#\ ·~ •,:::::
Elemento 4
____ ..... 1 ·-, ••:::::,,:::;:¡, lht,¡
-----.;~~ -, ••.:::::.,~ • ..a'•_ ........ _ !Hi'L\ ,\LTER.'\A J
® SI02 ®
Ti= Número <le tr:msputcr SJOi= Número <le Interface SIO S= Proceso Sio D= Proceso Dri,cr l'C= i'roccso Controlador M= Monitor
\ ·. T2
·•
.-------......... ·- .. , T4 T5
@ ¡¡
·-·-·-..... ·-........... ·-...• J
..... -... Enla(; t."S totalm!!nk virluaks
EnlaCL-'S físicos. con colocacionc:s de can.ak-s vi11ualcs
Eolai;.;1..~ físicos. con colocacion.:s Ji.: canak-s diri.:ctos
Figura 4.20 Topología con Rutas Alternas,Canales Virtuales y elementos de
la Celda de Manufactura Flexible
55
5. RESULTADOS
5.1 PRUEBA 1. REDUNDANCIA CON DOS PROCESADORES
En este esquema se usaron dos transputers conectados a un elemento 810232.
Un transputer controla al elemento conectado al puerto A y el otro controla al otro
elemento que está conectado al puerto B. Ambos transputers tienen dos
procesos controladores. T1 tiene un controlador dedicado al robot principal y otro
de respaldo para sustituir al controlator principal de T2 en caso de que falle y
viceversa. Los elementos de la celda pueden ser idénticos o diferentes pero cada
uno esta haciendo tareas independientes. (Ver figura 5.1 y 5.2).
Para la prueba que se realizó en el trabajo [14] se usó una pe para el controlador,
el robot PUMA como elemento de la celda conectado al puerto A y una segunda
pe simulando a un segundo robot En la pe con el controlador se encuentra la
tarjeta 8008 que contiene a un transputer haciendo las veces de la red de
transputers (controlador) y un módulo SIO para la conexión con el robot (ver
figura 4.20).
1u:n DE TRA",SPLTERS
: sici--ru.,..to ,\
Puerto H
TI
T2
('0 'iTROI ,A DOR
,, ,, ,, ,, :•
Robot I Prindpal l
Robot Prindpal 2
Fig. 5.1 Distribución de los elementos de la celda y el controlador
SIO
Robot Principal 1
Puerto A
Driver
Robot Principal 2
Fig. 5.2 Distribución de los procesadores y procesos en el controlador
56
57
En la pe que simula al robot se encuentra un programa que recibe peticiones del
controlador desde el puerto serial . En el momento que recibe la instrucción , la
interpreta y deja correr un tiempo antes de contestar con un reconocimiento.
Como requisito para la prueba, es necesario un archivo que contiene el último
estado válido del sistema, para el inicio se usa como último estado válido el
estado cero. También es necesario un archivo por elemento de la celda con su
respectivo plan de trabajo. (Figuras 5.3 y 5.4)
00
Figura 5.3 Contenido del archivo Log.txt
Pruebaa.txt
Rigth 2 10 move 2 10 left 2 10 stop 2 10
Pruebab.txt
Move 2 10 stop 2 10
Figura 5.4 Archivos que contienen el plan de trabajo
58
Cuando un controlador ejecuta toda su lista de instrucciones según su plan,
volverá a empezar con la primera instrucción.
En la figura 5.5 se muestra el incio de la aplicación, que incluye la lectura y
distribución del estado inicial y el plan de trabajo a los controladores primarios y
de respaldo, así como la señalización del inicio de ejecución de los procesos
monitores locales, el monitor global y los controladores primarios.
********•••••••fil*** Inicio Aplicación ••••••••••••••• ••• ,, ** •• ***"' ........... ** ****** ................. * *"'* ............. .
Archivo : prueba Procesos : 2 Archivo O: prueba a .txt Archivo 1: pruebab.txt PROCESO FIN CORRIENDO•• PROCESO TRANSMISION CORRIENDO•• PROCESO TX(O) -> Edolnicial: O PROCESO TX(1) -> Edolnicial: O PROCESO TX(O) -> O : rigth PROCESO TX(1) -> O : move PROCESO TX(O) -> 1 : move PROCESO TX(1) -> 1 : stop PROCESO TX(O) -> 2 : left PROCESO TX(1) FIN •· PROCESO TX(O) -> 3 : stop PROCESO TX(O) FIN •• PROCESO TRANSMISION BACK CORRIENDO •• PROCESO TX(O) -> Edolnicial: O PROCESO TX(1) -> Edolnicial: O PROCESO TX(O) -> O : rigth PROCESO TX(1) -> O : move PROCESO TX(O) -> 1 : move PROCESO TX(1) -> 1 : stop PROCESO TX(O) -> 2 : left PROCESO TX(1) FIN •• PROCESO TX(O) -> 3 : stop PROCESO TX(O) FIN ••
Lextura del plan de trabajo
Lextura estado inicial
Transmisión del plan de trabajo a los elementos primarios de la celda
Transmisión del plan de trabajo a los elementos respaldo de la celda
PROCESO INICIAR MONITORES CORRIENDO •r-• ---~----~ PROCESO INICIARMON(O) -> INICIOMON PROCESO INICIARMON(1)-> INICIOMON PROCESO INICIARMON(O) ->FIN•• PROCESO INICIARMON(1) ->FIN••
Inicio de monitores locales
PROCESO INICIAR APLICACIONES CORRIENDf-L-" • .,_. --~----~ PROCESO MONITOR CORRIENDO•• PROCESO INICIARAPP(O) -> INICIO PROCESO INICIARAPP(1) -> INICIO MONITOR : Empieza monitoreo normal PROCESO INICIARAPP(O) -> FIN ·• PROCESO INICIARAPP(1)-> FIN••
Inicio de monitor Global
Inicio aplicación
Figura 5.5 Inicio de la Aplicación
59
Cuando cada controlador ejecuta sus comandos respectivos, el monitor global le
envía al proceso conectado a la PC el estado actual, de tal forma que puede
desplegarse en la pantalla y escribirse en el archivo log.txt.
Cuando la aplicación está operando de forma normal, aparece un listado como el
de la figura 5.6 en donde se muestra el estado actual de cada proceso, y lo que
se escribe como estado actual en el archivo log.txt. El estado actual se escribe
hasta que el módulo SIO contesta con un reconocimiento de que se ha ejecutado
el comando. Ejecutar un comando implica que el SIO transmite, por medio del
driver , una intrucción al elemento que se encuentra en su puerto
correspondiente, el emento le contesta con un reconocimiento, el SIO retransmite
a su vez el reconocimiento al controlador y finalmente el controlador despliega y
escribe el último comando ejecutado.
Controladores
INICIO APLICACIÓN•• Estados escritos en el archivo
LogFile o 1 Log.Txt (estado global)
MONITOR MOVE LogFile o 2 MONITOR STOP Comando reconociido por el monitor
LogFile 1 2 y ya escrito en el archivo Log .txt
MONITOR RIGTH LogFile 1 1 MONITOR MOVE El controlador 2 ejecuta un segundo
Lag File 2 2 ciclo del plan de trabajo
MONITOR MOVE
Figura 5.6 Ejecucion de la aplicación
Cuando se genera un error, entra en operación el controlador de respaldo
sustituyendo al controlador principal. Ahora el SIO ya no recibe la siguiente
instrucción del controlador principal , sino del respaldo, cuando recibe la nueva
instrucción se comporta de la misma forma que con el controlador principal, es
60
decir, recibe una instrucción (por el canal de respaldo) la transmite de forma
adecuada al driver y el driver finalmente la retransmite al elemento de la celda. El
elemento de la celda contesta con un reconocimiento, el cual se transmite de
regreso hasta el controlador de respaldo por medio del driver y del módulo SIO.
De esta forma, el monitor sigue desplegando el estado actual del controlador de
respaldo a partir de los reconocimientos de los elementos de la celda (ver figura
5.7)
Controladores
INICIO APLICACIÓ . LogFile o 1 MONITOR MOVE LogFile o 2 MONITOR STOP LogFile 1 2 MONITOR RIGTH LogFile 1 MONITOR MOVE LogFile 2 2 MONITOR MOVE
Proceso Terminar 48 Introducción de error en el
Logfile 2 1 controlador 1
MONITOR MOVE LogFile 2 2 MONITOR STOP LogFile 3 2 MONITOR LEFT LogFile 3 1 MONITOR MOVE
Back LogFile 4 Respuesta del proceso de respaldo
MONITORBACK STOP LogFile 4 2 MONITOR STOP
Figura 5. 7 Ejecución de la aplicación e inducción de un error.
El mismo proceso se sigue cuando se ejecuta un error en el segundo controlador.
En caso de que el error ocurra en ambos controladores, el módulo SIO sigue
recibiendo instrucciones sólo que por medio de sus dos canales de respaldo (que
corresponden a los controladores de respaldo) de tal forma que el módulo
61
continúa contestando al monitor con un reconocimiento del elemento de la celda
a travez de los canales secundarios correspondientes .
Como puede verse, el módulo SIO simplemente está preparado para recibir
instrucciones ya sea del controlador primario o del controlador secundario, ya que
la tolerancia a fallas en éste esquema recae completamente en el controlador de
la celda, a diferencia del siguiente esquema en el cual el módulo SIO es capaz de
reconocer errores en los elementos de la celda y continuar trabajando con otro
nuevo elemento (idéntico al primero) sin necesidad de notificar al controlador.
Para referencia del código ver la sección D.2 del APENDICE D, y para una
consulta más detallada ver el trabajo [14)
5.2 PRUEBA 2. REDUNDANCIA CON DOS ROBOTS
En este esquema se usó un transputer conectado a un elemento SI0232 el cual
está controlando al elemento de la celda que tiene comunicación con el puerto A
(Robot). Existe un elemento idéntico en el puerto B esperando sustituir al
elemento del puerto A cuando ocurra un error en el robot. (Ver figura 5.8 y 5.9).
Para la prueba se usó el robot PUMA como elemento de la celda conectado al
puerto A y una pe simulando a un segundo robot PUMA . En la pe se encuentra la
tarjeta 8008 que contiene a un transputer haciendo las veces de la red de
transputers (controlador) y un módulo SIO para la conexión con el robot (ver
figura 5.8).
RED DE TR\NSl'lTER$ 1- -- - --- - - - - • - • -- • • -- -- - --- 1 ' ., ' ,, : TI :; ' ,, ' '• ' '• ' , ,
SIO
,, •, ,, ,, ,, ,, :: ,, ,, :·
Robot P1incipal
Pul.'rto :\ ,--.,...¡.._.;....-...i , , ~--~ ,,
'' '' '' '' '' '' '' '. ' .
Put>rto B
,, , , ,, ,, ,, ,, ,, ,, ., ,, ,, ,, :: ,, ,,
'' '' 1 ¡ 11
: ~------ -------------------!: ' ' ' : : _ - - -- - ------- -- -- ---- - - - - -- -·
COI\TROL\DOR
Robot S!.'cundaria
(PC)
__ Fig. 5.8 _ Distribución de los elementos de la celda y el controlador.
so SIO Puerto A
DT222 Puerto B
Robot Principal
Robot Secundario
(PC)
Fig. 5.9 Distribución de los procesadores en el controlador.
62
Una vez hechas las conexiones se ejecutó en la pe el programa del controlador, el
cual sigue el flujo descrito en la seccion 4.5.2 . La forma en que se envían los
comandos a la pe no es automática sino que se escriben los comandos en el
teclado con una rutina de lectura y se envían los comandos carácter por carácter
al proceso controlador.
Como inicio; el proceso controlador envía la configuración del puerto serial al
driver . La configuración del robot PUMA es la siguiente:
Velocidad: 9600 bps,
8 bits de datos,
sin paridad
sin bit de paro
Despues indica al robot que está listo para recibir comandos con lo que reconoce
la existenca del robot al recibir el siquiente mensaje en la pantalla (ver figura
5.10)
Load V AL-11 from floppy (Y IN)?
lnitialize (Y IN)?
•
Fig. 5.10 Mensajes de inicio del robot
En el momento de recibir el prompt del robot (el símbolo de punto), puede
transcurrir cualquier tiempo antes de que se envíe la primera letra del siguiente
comando.
Se envió al robot la instrucción CAL, que significa calibrar y el robot ejecutó la
instrucción contestando con el siguiente mensaje y el prompt (ver figura 5.11 ).
• cal
Are you sure (Y /N)?
• do ready
•
Fig. 5.11 Mensajes del robot
Despues se le envió la instrucción "do ready" a lo que igualmente el robot
contesto con el posicionamiento a un punto y el prompt de espera de la siguiente
instrucción. El flujo de mensajes en operación normal se ilustra en la figura 5.12,
donde, como se describió en la sección 4.5.2, al escribir una letra se envía a un
proceso Tx del módulo SIO , el proceso Tx lo retransmite de la forma adecuada al
proceso driver y finalmente el driver lo retransmite al elemento que se encuentra
en el puerto A. Cuando el controlador envía un "enter'' como señal de fin de
comando, el proceso Tx envía una señal de inicio de temporizador al proceso Rx .
El robot contesta al proceso driver con un prompt (.) para recibir el siguiente
comando, el driver reenvía la contestación al proceso Rx el cual prepara el
mensaje para ser nuevamente retransmitido al proceso controlador, de tal forma
que se despliega el prompt (.) en la pantalla para esperar la siguiente instrucción.
SIO
TI
Robot Prim:ipal
Robot Secunda1io
(PC)
Puerto B
Controlador
Fig. 5.12 Flujo de informacion del controlador en operación normal
65
En caso de que el proceso Rx no reciba el reconocimiento (prompt) de espera de
la siguiente instrucción, enviará una señal de error al controlador. Para simular
dicho error se desconectó el robot del puerto A antes de que el proceso driver
recibiera el prompt de espera del siguiente comando (ver figura 5.13).
Pucl1o A
SIO
T1
Controlador
Robot Secundario
(PC)
66
Fig 5.13 Flujo de informacion del controlador despues de ocurrido un error
El proceso Rx espera a que expire el temporizador de espera del reconocimiento
del robot, notifica al proceso controlador y desde el proceso controlador se
configura el proceso Rx y Tx para que ahora reciban y transmitan por el puerto B.
De esta forma se vuelve a enviar un comando al robot y lo recibe el segundo
robot PUMA (PC), este robot contesta de la misma forma en que lo haría el PUMA
y se recibe nuevamente el prompt de espera del siguiente comando pero ahora
desde el segundo robot.
Se siguió con la operación normal ahora desde este nuevo robot y se simuló
nuevamente un error en el mismo desconectándolo del puerto de comunicación
(imposibilitándolo para mandar el prompt de espera de comando), y como ya se
había vuelto a conectar el primer robot, éste entró en el lugar del segundo.
67
Cuando los dos se encuentran en error, el controlador envía un mensaje de que
se intenta cambiar de un puerto a otro sin conseguir respuesta de ninguno de los
dos puertos.
Para efectos de la prueba se asumió que no hay un primer intercambio de
mensajes entre el segundo robot y el controlador, pero en caso de que se hiciera
realmente con un segundo robot PUMA , es necesario tomar en cuenta el inicio
del robot.
Para consulta del código y descripción del software, refiérese a la sección 0 .1 del
APENDICE O
6. CONCLUSIONES Y RECOMENDACIONES A FUTURO
6.1 CONCLUSIONES.
68
En este trabajo se buscó la forma de comunicar la red de transputers que
contiene el PARDICO con los elementos de la Celda de Manufactura Flexible.
La solución fue el uso de una interfaz SIO que tiene un transputer que permite
hacer la conexión con la red de transputers y que cuenta con dos puertos por
elemento que realiza la función de conmutador 2x2.
Es decir, que dos procesos dentro de un procesador pueden manipular a dos
elementos de la Celda de Manufactura Flexible al mismo tiempo.
Para la implantación del esquema de Tolerancia a Fallas se hicieron dos
esquemas donde en uno se sustituye a un procesador erróneo y en el otro se
sustituye a un robot erróneo.
Debido a la relación costo beneficio que implica el segundo esquema al sustituir
un robot, finalmente se optó por el desarrollo de un software que permita a un
procesador manejar tanto a su elemento respectivo como al elemento que está
conectado a la misma interfaz SIO. Este trabajo fue complementado en la
tesis[14].
69
Dentro del trabajo que se realizó en esta tesis se utilizó también otra interfaz SIO
que maneja los estándares 422. El mismo programa que se usa como driver para
el SIO 232 aplica también para el 422. Sin embargo no fue posible realizar las
pruebas con el 422 debido a una falla de fabricación. Sin embargo, se construyó
un convertidor para poder conectar al SIO 422 con una interfaz de protocolo
RS232, como se especifica en la sección 4.4.
6.2 RECOMENDACIONES.
1 . Para efectos de prueba, la implementación se llevó a cabo con un solo
elemento de la Celda de Manufactura Flexible (el robot PUMA) y una pe
haciendo las veces de un segundo robot PUMA de respaldo idéntico al
primero.
En trabajos posteriores, la implementación que se llevó acabo en esta tesis tendrá
que realizarse con el resto de los elementos de la celda de Manufactura Flexible
para poder lograr una comunicación entre todos los robots .
2. Se recomienda para trabajos posteriores las pruebas con la interfaz 422. En
esta tesis se incluye el APENDICE G donde se explican los problemas con los
que nos topamos y se propone la solución.
70
7. BIBLIOGRAFIA
(1] Bottle H. Raúl. A. Módulo de lnterfazlnterfaz Programable. Tesis de
Maestría. ITESM Estado de México, 1992.
[2] Sánchez V. Jesús. "PARDICO: Un controlador paralelo/distribuido para
celdas flexibles de manufactura" 2o. Taller Internacional de Procesamiento
Paralelo. IIMAS, UNAM 1996.
[3] Corona J., Hooper R., Ramos F., Rodríguez C., Rudomin l., Sánchez J. ,
Tesar D., Valdivia R., "Tecnologías de Comunicación Avanzadas en
Robótica y Celdas de Manufactura". Proyecto NSF-Conacyt, ITESM Estado
de México y Universidad de Austin, Texas. México, 1996.
[4] Manuales de los elementos del CIM. ITESM Estado de México.
[5] Alarcón Celis Jaime. "Diseño de una arquitectura reconfigurable basada en
transputers". Propuesta de tesis. ITESM Estado de México. Mayo, 1996.
[6] Salmerón G. M. "Diseño de una arquitectura de Hardware utilizando
Transputers para el control de una CMF" Propuesta de Tesis de Maestría
en Ciencias Computacionales Especialidad en Redes. ITESM Estado de
México. Junio, 1996.
[7] Martínez S.M., Sánchez F.H. Sánchez T.A. "Integración de Celda de
Manufactura Flexible" Reporte de Investigación de Prácticas Profesionales.
ITESM Estado de México Mayo 1996.
[8] SGS-THOMSON MICROELECTRONICS "Artículo de IMS 8008". Agosto,
1994.
[9] SI0232 Dual RS - 232 TRAM "Manual de Usuario".
[1 O) 810422 Dual RS - 422 TRAM "Manual de Usuario".
[11] SGS Microelectronics. IMS 8426. Num. doc. 42 1269 OO. February, 1995.
Dirección Internet: http://www.st.com.
[12] Wti Western Telematic inc.
Dirección Internet: http://www.westtel.com
[13] Wti Western Telematic inc.
Dirección Internet: http://www.westtel.com
71
[14] Laura Zavala Vega. "Implementación de Distintas Técnicas de Tolerancia a
Fallas en una Celda de Manufactura". Tesis de Maestrial ITESM CEM.
Diciembre 1998
APENDICE A. DESCRIPCIÓN DE HARDWARE 510 RS232 Y/O 510 RS422
72
Los registros del DUART son mapeados en el espacio de memoria del transputer
con palabras de 16-bits. Sin embargo, solo los 8-bits bajos de cada 16-bits de
palabra son los válidos. Los 8-bits altos de cada palabra deberán descartarse.
A.1 MAPEO DE LA MEMORIA DEL TRANSPUTER.
Cada registro del DUART es mapeado a una dirección separada del transputer;
comenzando en HEX 7COO y continuando a HEX 7C1 E. Los registros de lectura y
escritura del DUART son accesados leyendo y/o escribiendo una dirección en
particular del transputer que se encuentre en el rango mencionado.
Una dirección de memoria del transputer puede tener dos funciones: lectura y
escritura. La figura A.1 muestra la configuración de memoria del transputer, la
cual está dividida en Interna! RAM y Externa! RAM, registros DUART, y registros
de interrupciones.
lrrtVVr
nlrrtRd
Uart.read I Uart.wrte
Externa! RAM
lnernal RAM
7EOO - 7E04 (output only)
7000- 7004 (input only)
7COO- 7COE (input and output)
Figura A.1 Configuración de la memoria del Transputer
7.,
A continuación se ilustra el código utilizado para el mapeo de registros de la
memoria del transputer. El mapeo de memoria se realiza utilizando el comando
PLACE. Para mayor información ver APENDICE c.
[16]1NT Uart.read : PLACE Uart.read AT (#7COO >< (MOSTNEG INT)) >> 1 : --PLACE Uart.read AT #7COO : [16]1NT Uart.write : PLACE Uart.write AT (#7COO >< (MOSTNEG INT)) >> 1 : --PLACE Uart.write AT #7COO : [4]1NT nlntRd : PLAC!; nlntAd AT (#7000 >-»«< (MOSTN!;G INT)) >-»>-» 1 :
--PLACE nlntRd AT #7000 : [4]1NT lntWr : PLACE lntWr AT (#7EOO >< (MOSTNEG INT)) >> 1 : --PLACE lntWr AT #7EOO :
En el código anterior se puede apreciar como cada registro es mapeado a una
dirección hexdecimal.
La forma de recibir o enviar datos al driver (registros de memoria del transputer
del SI0232 o SIO 422) se especifica en los siguientes ejemplos.
Ejemplo 1:
Envio de datos al SIO desde un T805.
out t sio.charA;char ---- Utilizando puerto A
out ! sio.charB;char ---- Utilizando puerto B
Ejemplo 2:
Envio de datos a un T805 desde el SIO.
In? sio.charA; char ---- Utilizando puerto A
In? sio.charB; char ---- Utilizando puerto B
A.2 CONEXIÓN PINOUTS RS232.
El estándar RS232 es ampliamente utilizado en computación y en técnicas de
comunicación. Este estándar utiliza desde 3 hasta 25 alambres para
interconectarse. La mayor parte de la información en un puerto serial está en
código ASCII. A continuación se muestra la tram del estándar RS232.
1
Bit Inicio
7
Código ASCII
1 1
Bit de Paridad Bit de Paro
7~
La velocidad a la que se transmiten los bits se conoce como "baud rate". (bps =
bits per second). Los dispositivos interconectados vía RS-232 pueden ser: Data
Terminal Equipment (DTE), o Data Communications Equipment (DCE). La
conexión debe ser entre un DTE y un DCE pin a pin.
El medio físico para utilizar RS232 entre los robots y el controlador es el estándar
089, porque la interfaz y los robots manejan dicho estándar.
Conector estándar 089
Número Descripción Función Dirección Pin de la señal de la señal
1 DCD data carrier detect (entrada) polled for status
2 RxD receive data (entrada) 3 TxD transmit data (salida) 4 DTR data terminal ready (salida)
set and cleared in software
5 SG Signal ground 6 DSR data set ready (entrada)
polled, or interrupt driven
7 RTS ready to send (salida) software or auto handshake
8 CTS clear to send (entrada) interrupt or auto handshake
9 RI ring indicator (entrada)
76
10 (~ o 9
8 e) C1 7
6 ~ ~- o 5
4 e--:) C) 3
2 .,,..-...... t__ __ ) •
Figura A.2 Pinouts 510232
A.3 CONEXIÓN PINOUTS 422.
El medio físico para utilizar RS422 entre los robots y el controlador es el estándar
089, debido a que las interfazs y los robots manejan dicho estándar. A
continuación se muestra la configuración del pin out del Sio422, donde se utilizará
el estándar 089.
Conector estándar 089
Número Pin
1 2 3 4 5 6
7
8
Descripción de la señal
Tx-Tx+ RxRx+ Ground Rts-
Rts+
Cts-
Función
transmit data -transmit data+ receive data -receive data +
Dirección de la señal
(salida)
(entrada)
ready to send - (salida) software or auto handshake
ready to send for character control
clear to send- (entrada) interrupt or auto handshake
77
9 Cts+ clear to send+ far character control
10 SG Signa! Ground 11 Pin removed 12 Pin removed 13 Otr- data terminal ready-(salida)
set and cleared in software
14 Dtr+ data terminal ready+ 15 Aux.int- ( interruptor)
RS422 user interrupt 16 Aux.lnt+
El conector de 16 pins usado en el 810422 ha sido modificado para permitir el uso
de diferentes tipos de conectores: 1 O pin a 08 25; 1 O pin a 08 9, etc.
16 (¡ \._,·
() ......_,. 15
14 r-.... 1 o 13 , . ..._./
12 11
10 C) r~ l __ ) 9
8 (=) (_J 7
6 () (__) ,: ,_, "
4 (=) ,,--,, (J 3
2 (_) e 1
Figura A.3 Pinouts 510422
A.4 REGISTROS DE PROGRAMACIÓN.
78
Existen 7 registros de programación para controlar las interrupciones. Sus
funciones son: Habilitar o deshabilitar interrupciones, limpiar bits en los registros,
restablecimiento del DUART, etc. Estos registros están conformados por los
siguientes campos.
Nombre de registro. Arreglo
Dirección hexadecimal.
Ejemplo:
Especificación del nombre Es un arreglo de números enteros en los que se encuentra dividido cada registro correspondiente Es el valor absoluto del registro.
lnt.enable or lntWr[O], (address #7EOO) donde: lnt.enable or lntWr [O] (address #7EOO)
--- Nombre del registro. --- Arreglo. --- Dirección hexadecimal.
1. Registro int.enable or lntWr[O], (address #7EOO), Read only.
Este registro es usado para habilitar una o más interrupciones de proceso. Los
cuatro bits menos significativos corresponden a las cuatro interrupciones del
proceso implementado en el 810232 o 810422. Para habilitar una interrupción en
particular el bit correspondiente deberá ser configurado. Por ejemplo, para
habilitar la interrupción 2, el bit 2 del registro debe de configurarse de la siguiente
forma:
int.enable . = #4
Nota: Después de que ocurre una interrupción de proceso, el registro int.poll debe
ser leído para determinar cual de los cuatro bits externos ocasionó la interrupción.
Antes de atender otra interrupción el bit correspondiente del registro int.enable
debe ser limpiado y restablecido de la siguiente manera:
int.mask := # 2 V# 4 int.enable :=ínt.mask
79
master : =master. int. enable event ? dummy icheck :=int.poll /\ # F ... check who did interrupt (1) int.enable := int.mask /\ (-icheck) (2) int.enable :=int.mask
El código de la linea (1) limpia todos los bits de int.enable que fueron usados
durante la interrupción ocurrida, y en la línea (2) todas las interrupciones son
restablecidas.
2. Registro int.clear or lntWr[1],(address #7E02), read only.
Este registro es usado para limpiar los bits del registro int.enable. Poniendo el bit
en int.clear limpiará el bit correspondiente en el registro int.enable. Solamente los
bits menos significativos son los válidos.
Cuando una interrupción ocurre, este registro puede ser usado para limpiar
cualquier bit en particular, y después usar int.enable para restablecer el bit. Esto
asegura que ninguna interrupción se pierda. Por ejemplo,
even? dummy int.clear := # 4 int.enable := int.mask
puede ser usado para limpiar el bit-2 (Hex 4), y después int.enable para
restablecer el bit. Ningún otro bit en cualquier registro es afectado.
3. Registro CSR or lntWr[2], (address #7E04), Read only.
Este es un registro de propósito general usado para restablecer el DUART y
controlar las interrupciones. Los cuatro bists menos significativos del registro
controlan las interrupciones y DUART.
Csr bit 1 (#1) not used Csr bit 2 (#2) invert spare interrupt Csr bit 3 (#4) ínvert ring (aux) interrupt Csr bit 4 (#8) reset DUART
4. Registro master or lntEr[3], (address #7E06), Read only.
80
Este registro es usado para habilitar o deshabilitar todas las interrupciones sin
importar el valor del registro int.enable.
5. Registro int.poll or nlntRd[O], (address #7000), Read only.
Este registro contiene los estatus del reloj de las cuatro señales de interrupción
que se efectúan cuando el transputer es interrumpido. Los cuatro bits menos
significativos de este registro corresponden a las cuatro interrupciones de
proceso disponibles.
bita~ int O bit2 ~ int 2
bit1 ~ int1 bit3 ~ int3
6. Registro int.status or nlnt[1], (address #7E02), Read only.
Este registro es usado para obtener el estatus de entrada del bit de interrupción.
lnt.status es similar al int.poll excepto que int.status lee el bit de interrupción
enfrente del latch. El mapeo de bits es igual al del int.poll.
7. Registro is.master or nlnt[2], (address #7E03), Read only.
Este registro es usado para saber si la interrupción master se ha establecido.
Is.master es usado principalmente para propósitos de prueba y debugeo.
is.master := 1 if master is set
81
is.master:= O if master is clear
A.5 REGISTROS INTERNOS DEL DUART.
Las 16 localidades de registro del DUART son mapeadas a las 16 direcciones del
transputer empezando en HEX ?COO y terminando en HEX 7C1 E (ver figura 3.1 O).
La forma de mapear a los registros del DUART es utilizando el comando PLACED
de Occam. Una vez definidos los registros con sus respectivas direcciones
hexadecimales; dichos registros pueden ser utilizados para escribir o leer. A
continuación se explica la forma de escribir y leer para la red de transputers y los
puertos A o B.
• Leyendo y escribiendo desde la red de transputers.
En la figura A.5.1 se ilustra la forma en que la red de transputers escribe en el
registro transmit.reg.B o transmit.reg.A, y por otro lado puede leer de los registros
receive.reg.B o receive.reg.A la información que escribieron los puertos.
• Leyendo y escribiendo desde los puertos A y B.
En la figura A.5.1 se ilustra la forma en que los puertos escriben en los registros
receive.reg.B o receive.reg.A, y por otro lado pueden leer de los registros
transmit.reg.B o transmit.reg.A la información que escribió la red de transputers.
PUERTO B ~ ,
. PUERTO A .....
REGISTROS INTERNOS DEL DUART
LECTURA ESCRITURA
receive.reg.B 1
._ Transmit.reg.~ ... I
J/ \ ) 1 '\,. --\. ~
/ / I
I -r----...
)/ • \ 1
receive.reg.A transmit.reg.A
Figura A.5.1 Registros
15 14 13 12 11 10 9 8 7 6 5 4 3 2
o
lnterrupt 1/0
stop .counter start .counter input.por!
receive .reg .B
stalus.reg.B mode.reg.B rd.count.time.lo rd .counl .time .hl uart .int .status port .change .reg receive .reg .A
status .reg .A mode.reg.A
Externa! RAM
Interna! RAM
clear .output .bits set .output .bits output .conf .reg
transmit .reg .B command .reg .B clock .sel .reg .B mode.reg.B count .time .lo counl .time .hl int .mask .reg aux .control.reg transmit .reg .A command.reg clock .sel .reg .A mode.reg.A
-. ~
-
7C1E 7C1C 7C1A 7C18 7C16 7C14 7C12 7C10 7COE 7COC 7COA 7C08 7C06 7C04 7C02 7COO
Figura A.5.2 Registros del Duart
RED DE TRANSPUTERS
A continuación se describen cada uno de los registros internos del DUART.
82
83
A.6 DESCRIPCIÓN DE LOS REGISTROS DE LECTURA.
• mode.reg.A or Uart.read[O], (address #7COO), Read/Write register.
Este registro es mapeado a la dirección #7COO. Tal registro corresponde a MRO,
MR1, MR2; ver descripción en el APENDICE A
• status.reg.A or Uart.read[1 ], (address #7C02), Read only.
Este registro es mapeado a la dirección #7C02. Tal registro corresponde a SRA;
ver descripción en el APENDICE A
RESERVED --Uart.read[2], (address #7C04).
• receive.reg.A or Uart.read[3], (address #7C06), Read only.
Este registro es mapeado a la dirección #7C06. Tal registro corresponde a RHR
para el canal A o B. El receive holding register RHR son utilizados para
almacenar temporalmente caracteres.
• port.change.reg or Uart.read[4], (address #7C08), Read only.
Este registro es mapeado a la dirección #7C08. Tal registro corresponde a IPCR;
ver descripción en el APENDICE A
• uart.int.status or Uart.read[5], (address #7COA), Read only.
Este registro es mapeado a la dirección #7COA. Tal registro corresponde a ISR;
ver descripción en el APENDICE A
8-+
• rd.count.time.hi or Uart.read[6], (address #7COC), Read only.
• rd.count.time.lo or Uart.read[7], (address #7COE), Read only.
Estos registros son mapeados a las direcciones #7COC y #7COE respectivamente.
Tales registros corresponden a CTUR y CTLR; ver descripción en el APENDICE
A.
• mode.reg.B or Uart.read[8], (address #7C1 O), Read I Write register.
Este registro es mapeado a la dirección #7C10. Tal registro corresponde a MRO,
MR1, MR2; ver descripción en el APENDICE A.
• status.reg.B or Uart.read[9], (address #7C12), Read only.
Este registro es mapeado a la dirección #7C12. Tal registro corresponde a SRB;
ver descripción en el APENDICE A.
RESERVED -- Uart.read[10], (address #7C14).
• receive.reg.B or Uart.read[11], (address #7C16), Read only.
Este registro es mapeado a la dirección #7C16. Tal registro corresponde a RHR
para el canal A o B.
RESERVED -- Uart.read[12], (address #7C18).
• input.port or Uart.read[13], (address #7C1A), Read only.
Este registro es mapeado a la dirección #7C 1 A Es un registro de 7 bits, y
funciona como un registro de entrada. Permite leer los estados de señalización de
entradas al UART.
• start.counter or Uart.read[14], (address #7C1C), Read only.
Este registro es mapeado a la dirección #7C1 C. Utilizado para medir o generar
frecuencias.
• stop.counter or Uart.read[15), (address #7C1 E), Read only.
Este registro es mapeado a la dirección #7C1 E. Utilizado para medir o generar
frecuencias.
A.7 DESCRIPCIÓN DE LOS REGISTROS DE ESCRITURA.
• mode.reg.A (address #7COO) Read /Write register.
Este registro es mapeado a la dirección #7COO. Tal registro corresponde a MRO,
MR1 , MR2; ver descripción en el APENDICE A
• Clock.sel.reg.A or Uart.write[1], (address #7C02), Write only.
Este registro es mapeado a la dirección #7C02. Tal registro corresponde a CSRA;
ver descripción en el APENDICE A
• command.reg.A or Uart.write[2], (address #7C04), Write only.
Este registro es mapeado a la dirección #7C04. Tal registro corresponde a CRA;
ver descripción en el APENDICE A
86
• transmit.reg.A or Uart.write[3], (address #7C06), Write only.
Este registro es mapeado a la dirección #7C06. Tal registro corresponde a THR
para el canal A o B. El transmiter holding register THR son utilizados para alertar
al procesador de la existencia de caracteres que no han sido transmitidos.
• aux.control.reg or Uart.write[4], (address #7C08), Write only.
Este registro es mapeado a la dirección #7C08. Tal registro corresponde a ACR;
ver descripción en el APENDICE A.
• int.mask.reg or Uart.write[5], (address #?COA), Write only.
Este registro es mapeado a la dirección #?COA. Tal registro corresponde a IMR;
ver descripción en el APENDICE A.
• count.time.hi or Uart.write[6], (address #?COC), Write only.
• count.time.lo or Uart.write[7], (address #7COE), Write only.
Estos registros son mapeados a las direcciones #7COC y #7COE respectivamente.
Tales registros corresponden a CTUR y CTLR; ver descripción en el subcapítulo
3.4.2.5.
• mode.reg.B (address #7C10), Read I Write only.
Este registro es mapeado a la dirección #7C10. Tal registro corresponde a MRO,
MR1, MR2; ver descripción en el APENDICE A.
• clock.sel.reg.B or Uart.write[9], (address #7C12), Write only.
87
Este registro es mapeado a la dirección #7C12. Tal registro corresponde a CSRB;
ver descripción en el APENDICE A
• command.reg.B or Uart.write[10], (address #7C14), Write only.
Este registro es mapeado a la dirección #7C14. Tal registro corresponde a CRB;
ver descripción en el APENDICE A
• transmit.reg.B or Uart.write[11], (address #7C16), Write only.
Este registro es mapeado a la dirección #7C16. Tal registro corresponde a THR
para el canal A o B. El transmiter holding register THR son utilizados para alertar
al procesador de la existencia de caracteres que no han sido transmitidos.
RESERVED -- (address #7C18).
• output.conf.reg or Uart.write[13], (address #7C1A), Write only.
Este registro es mapeado a la dirección #7C1A. Tal registro corresponde a
OPCR; ver descripción en el APENDICE A
• set.output.bits or Uart.write[14], (address #7C1C), Write only.
• Clear.output.bits or Uart.write[15], (address #7C1 E), Write only.
Son registros mapeados a las direcciones 7C1 C y 7C1 E. Son registros de salida
de 8 bits y permiten el control de señalizaciones de salida del UART.
88
APENDICE B. DESCRIPCIÓN DE SOFTWARE SIO
RS232 Y/O SIO RS422
La versión de software que utiliza el driver SIO está escrita en OCCAM. Este
driver es un programa stand alone que se carga en el TRAM del SIO, el cual
permite establecer los parámetros de configuración para la comunicación entre la
red de transputers y los elementos de la celda de manufactura.
El driver permite definir los canales de entrada y salida, memoria de los
transputers, asignación de registros a la memoria del UART, canales internos del
driver "A" o "B", registros para los canales internos, inicialización de buffers, etc.
Una vez definidos todos los parámetros anteriores, la transmisión de los datos se
puede enviar individualmente o en cadenas entre la red de transputers y los
elementos de la celda de manufactura; siempre y cuando pasen por el driver (ver
APENDICE O "Diagrama de Flujo del driver).
8.1 PROTOCOLOS DE COMUNICACIÓN.
El driver del SIO utiliza dos protocolos de comunicación:
Tag; char BYTE;BYTE
Tag;word.count ::string BYTE; INT16 :: BYTE
89
Estos protocolos permiten enviar comandos, cadenas, y comandos de información
al proceso driver del SIO. La diferencia entre los comandos es que en uno se
puede enviar caracteres y en el otro cadenas.
La información es regresada por el driver como un solo caracter de información.
La entrega de los datos siempre utilizará el siguiente formato:
Tag; char BYTE;BYTE
8.2 COMANDOS DEL CONTROLADOR.
Un comando es usado para habilitar o deshabilitar establecimiento de
comunicaciones, seleccionar velocidad en baudios, etc. La manera de programar
los rangos de velocidad es utilizando los siguientes registros del UARTs.
Auxiliary Control Register (ACR)
Mode Register O (MROA)
Clock Select Register (CSR)
Los valores que pueden tomar estos registros están especificados en la tabla 1 de
la sección 3.4.3.4.
8.3 PROTOCOLO DE COMANDO
Estos comandos son utilizados para enviar y recibir información entre la red de
transputers y el SIO. Existen dos etiquetas, ambas son usadas para establecer las
características del puerto A y/o B.
Command Protocol:
out ! sio.cmd.A; char
90
out ! sio.cmd B; char
sio.cmd.A permite que el caracter de comando siguiente cambie las
características del puerto A.
sio.cmd.B permite que el caracter de comando siguiente cambie las
características del puerto B.
Los caracteres ( char) que siguen después de las etiquetas de comando deberán
ser uno de los siguientes comandos de instrucciones bytes:
sio.enable.hs
hardware.
sio.disable.hs
sio. baud. 1200
sio.baud.2400
sio.baud.4800
sio.baud.9600
sio. baud.19.2K
sio.baud.28.8K
sio.baud.57.6K
sio.baud.115.2K
sio. timer. mode
Comando de establecimiento de comunicaciones de
Velocidad normal en baudios.
Velocidad extendida en baudios.
Velocidad Contador!Tiempo en baudios.
91
A continuación se da un ejemplo de una etiqueta de comando seguida de un
caracter:
Ejemplo:
Out! sio.cmd.A; sio.baud.1200
8.4 DESCRIPCIÓN COMANDO DE CONFIGURACIÓN
sio.enable.hs Habilita establecimiento de comunicaciones RTS/CTS de
hardware checándolo en el puerto de comunicaciones especificado.
sio.disable.hs Deshabilita establecimiento de comunicaciones RTS/CTS de
hardware checándolo en el puerto de comunicaciones especificado.
La velocidad en baudios es programada con la utilización de dos grupos de
valores preset llamados velocidad normal en baudios y velocidad extendidad en
baudios los cuales se describen adelante . Esta versión de software utiliza por
default ACR Bit[7]:=1 para poder tener la opción de escoger cualquier velocidad,
ya sea normal o extendida.
ACR[7]:=1
MR[O]:=O o 1
La diferencia entre los dos grupos de velocidad de baudios es el valor MROA[O]
que puede ser O o 1. Los cambios que se realicen a MROA[O ] se verán reflejados
automáticamente en MROB[O].
Grupo de velocidad normal.
sio.baud.1200
sio.baud.2400
sio. baud. 4800
sio.baud.9600
sio.baud.19.2K
Establece la velocidad a 1200
Establece la velocidad a 2400
Establece la velocidad a 4800
Establece la velocidad a 9600
Establece la velocidad a 19.2K
Grupo de velocidad extendida.
sio.baud.28.8K Establece la velocidad a 28.BK
sio.baud.57.6K Establece la velocidad a 57.6K
sio.baud.115.2K Establece la velocidad a 115.2K
MRO 01=0 CSRA[7:4] ACR[7]=0 ACR[7]=1
0000 50 75 0001 11 O 110 0010 134.5 134.5 0011 200 150 0100 300 300 0101 600 600 0110 1,200 1,200 0111 1,050 2,000 1000 2,400 2,400 1001 4,800 4,800 1010 7,200 1,800 1011 9,600 9,600 1100 38.4k 19.2k 1101 Timer Timer 111 O IP4-16X IP4-16X 1111 IP4-1X IP4-1X
Tabla 1. Velocidades.
92
MRO 01=1 ACR[7]=0 ACR[7]=1
50 450 100 110
134.5 230.4k 200 900
1,800 1,800 3,600 3,600 7,200 7,200 1,050 2,000 14.4k 14.4k 28.8k 28.8k 7,200 1,800 57.6k 57.6k
230.4k 115.2k Timer Timer
IP4-16X IP4-16X IP4-1X IP4-1X
La versión del driver que se utilizó para el desarrollo de esta tesis se configuró
con una velocidad de 9600 para poder ser compatible con los robots.
8.5 COMUNICACIÓN DEL CONTROLADOR.
Para tener una comunicación con el driver del SIO es necesario tener conectado
un dispositivo externo hacia uno de los puertos del SIO y este a su vez tiene que
estar conectado a la red de los transputers.
Una vez lista la comunicación, los datos son enviados al driver desde la red de
transputers o desde un dispositivo externo en forma de bytes o caracteres. Estos
datos posteriormente son enviados por el driver a un canal específico del UART
para ser transmitidos por RS-232 o RS-422.
A continuación se presentan unos ejemplos de la transmisión y recepción de los
datos.
Para enviar caracteres o cadenas de datos desde un T805 hacia el SIO, y
después transmitirlo por el canal A o B del UART se requiere ejecutar el siguiente
código de OCCAM
Ejemplo 1:
Envio de datos al SIO desde un T805.
out ! sio.charA;char ---- Utilizando puerto A
out ! sio.charB;char ---- Utilizando puerto B
9-t
Para enviar caracteres o cadenas de datos desde los puertos del SIO hacia un
T805, se requiere ejecutar el siguiente código de OCCAM
Ejemplo 2:
Envio de datos a un T805 desde el SIO.
In? sio.charA; char ---- Utilizando puerto A
In? sio.charB; char ---- Utilizando puerto B
9.'i
APENDICE C. REGISTROS DEL 510232 y 510422.
Descripción de los Registros para los puertos A o B.
MRO es accesible cuando el apuntador del canal A o B MR apunta a MRO.
BIT 7 BIT 6 BIT 5 BIT 4 BIT 3 BIT 2 BIT 1 BIT O
Rx WATCH Rx TxlNT (1 :O) Don't Test 1 Test 2 Baud Rate
MROA DOG INT(2) Care Extend
MROB O= Disable Set to O Set to O Set to O O= Normal
1= Enable 1= Extend
MR0[7]. Este bit controla el recibidor del tiempo watch dog. O=disable, 1 =enable.
Cuando está habilitado, el tiempo del watch dog generará una interrupción de
recepción si el receptor FIFO no ha accesado en un lapso de 64 tiempos bit del
reloj receptor 1 x. Este es usado para alertar al procesador control que los datos
están en RHR los cuales no han sido leídos. Este caso se puede dar cuando la
última parte del mensaje no es suficientemente grande para generar una
interrupción.
MR0[6]. Bit 2 nivel de interrupción del receptor FIFO. Este bit en conjunto con bit
6 de MR1 establece el llenado del nivel de los 8 byte FIFO que genera la
interrupción de recepción.
MRO[S:4]. Tx Interrupción llenado de nivel.
MR0[3]. No usado. Debe estar establecido a O.
MR0[2: 1 ]. Test 1 y Test 2. Usados para pruebas de fabricación. Debe estar
establecido a O.
MRO[O]. Rango de velocidad extendida. O = Rango de velocidad normal. 1 =
Rango de velocidad extendida. 57.6kB, 115.2kB, 230.4kB.
MR1 es accessible cuando el apuntador del canal A o B MR apunta a MR1.
BIT 7 BIT 6 BIT 5 BIT 4 BIT 3 BIT 2 BIT 1 BIT O Rx Rx INT Error Parity Mode Parity Bits per
Controls BIT 1 Mode Type Character
RTS
MR1A O= No O= RxRDY O= Char 00 = With Parity O= Even 00 = 5
MR1B 1 = Yes 1 = FULL 1 = Block 01 = Force Parity 1 = Odd 01 = 6
1 o = No Parity 10 = 7
11 = Multidrop 11 = 8
Mode
MR1 [7]. Este bit controla la desactivación de la salida RTSAN (OPO) por el
receptor.
MR1 [6]. Bit 1 control de interrupción del receptor. Ver descripción MR0[6].
MR1 [5]. Este bit selecciona el modo de operación del status de bits de FIFO (FE,
PE, corte recepción) para los canales A o B. En el modo de carácter, el status es
carácter por carácter; este status aplica solo al carácter que se encuentra en la
parte superior del FIFO. En el modo block, el status generado en SR para estos
bits es la acumulación (logical-OR) del status para todos los caracteres que llegan
97
a la parte superior del FIFO desde el último "reseteo de error'' comando que fue
generado para cualquiera de los dos canales.
MR1 [4:3]. Selección del modo de paridad. Si "with parity" o "force parity" es
seleccionada una paridad de bit es agregada al carácter de transmisión y el
receptor realiza un chequeo de paridad en los datos de entrada.
MR1[2J. Este bit selecciona el tipo de paridad (odd o even).
MR1 (1 :O]. Este campo selecciona el número de bits de datos por carácter para ser
transmitido y recibido. La longitud de carácter no incluye bits de start , parity, y
stop.
MR2 es accesible cuando el apuntador del canal A o B MR apunta a MR2.
BIT 7 BIT 6 BIT 5 BIT 4 BIT 3 BIT2 BIT1 BITO
Channel Mode Tx Controls CTS Stop Bit Length
RTS Enable TX
MR2A 00 = Normal O= No O= No 0=0.563 4=0.813 8=1.563
MR2B 01 = Auto Echo 1 = Yes 1 = Yes C=1.813
1 O = Local Loop 1=0.625 5=0.875 9=1.625
11 = Remote 0=1 .875
Loop 2=0.688 6=0.938 A=1 .688
E=1.938
3=0.750 7=1.000 8=1.750
F= 2.000
MR2[7:6J. Cada canal de DUART puede operar en cuatro modos. 00 = modo
normal, con operación independiente entre el transmisor y receptor. 01 = pone el
canal en modo automático, el cual retransmite los datos recibidos
automáticamente. 1 O = modo loopback. 11 = modo remate loopback.
98
MR2[5]. Este bit controla la desactivación de la salida RTSAN (OPO) por el
transmisor.
MR2[4]. Si el bit es O, CTSAN no tiene efecto en el transmisor. Si el bit es 1, el
transmisor checa el estado de CTSAN (IPO) cada vez que esta listo para enviar
un carácter.
MR2[3:0]. Este campo programa la longitud del bit stop agregado al carácter
transmitido.
SRA y SRB. Status del registro del canal A o B.
BIT 7 BIT 6 BIT 5 BIT 4 BIT 3 BIT 2 BIT 1 BITO
RECEIVED FRAMING PARITY OVERRUN TxEMT TxRDY FFULL RxRDY
BREAK ERROR ERROR ERROR
O= No. O= No. O= No. O= No. O= No. O= No. O= No. O= No.
SRA 1 = Yes. 1 = Yes. 1 = Yes. 1 = Yes. 1 = Yes. 1 = Yes. 1 = Yes. 1 = Yes.
SRB
SRA y SRB[7]. Received break . Este bit significa que un carácter cero de la
longitud del programa ha sido recibido sin bit de paro. Solo una posición FIFO es
ocupada cuando se recibe un break.
SRA y SRB[6]. Framing Error. Cuando se establece este bit, nos indica que el bit
de paro no fue detectado cuando el carácter de datos correspondiente en el FIFO
fue recibido.
SRA y SRB[5]. Parity Error. Este bit se establece cuando se programa el modo de
paridad y el carácter correspondiente en el FIFO fue recibido con paridad
incorrecta.
SRA y SRB[4].0verrun Error. Este bit establecido indica que uno o más
caracteres en la trama de datos recibidos se han perdido.
99
SRA y SRB[3].Transmitter Empty. Este bit se establece cuando los canales de
transmisión A o B se encuentran vacíos.
SRA y SRB[2]. Transmitter Ready. Este bit cuando se establece, nos indica que el
FIFO de transmisión no esta lleno y esta listo para ser cargado con otro carácter.
SRA y SRB[1].Full. Este bit se establece cuando un caracter es transmitido del
registro receptor al FIFO receptor y la transferencia ocasiona que el FIFO se
llene.
SRA y SRB[O]. Receiver Ready. Este bit indica que un caracter ha sido recibido y
esta en el FIFO para ser leído por el CPU.
IPCR. Input Port Change Register.
BIT 7 BIT 6 BIT 5 BIT 4 BIT 3 BIT 2 BIT 1 BIT O
DELTA DELTA DELTA DELTA IP3 IP2 IP1 IPO
IP3 IP2 IP1 IPO
O= No. O= No. O= No. O= No. O= low O= low O= low O= low IPCR 1 = Yes. 1 = Yes. 1 = Yes. 1 = Yes. 1 = high 1 = high 1 = high 1 = high
IPCR[?:4] IP3,IP2,IP1 ,IPO Estos bits se establecen cuando existe un cambio de
estado.
I P3. Channel A transmitter externa! clock input. Usado cuando el externa!
clock es usado por el transmisor.
IP2. Counter/tímer externa! clock input.
IP1. Channel B clear to send.
IPO. Channel A clear to send.
100
IPCR[3:0] IP3,IP2,IP1 ,IPO Estos bits proveen el estado actual de las entradas
respectivas.
ISR. lnterrupt Status Register.
BIT 7 BIT 6 BIT 5 BIT 4 BIT 3 BIT 2 BIT 1 BIT O
INPUT DELTA RxRDY/F TxRDYB COUNTER DELTA RxRDY/ TxRDYA
PORT BREAK 8 FULLB READY BREAK A FFULLA
CHANGE
O= No. O= No. O= No. O= No. O= low O= low O= low O= low
ISR 1 = Yes. 1 = Yes. 1 = Yes. 1 = Yes. 1 = high 1 = high 1 = high 1 = high
Este registro nos proporciona el status de todas las interrupciones importantes. El
contenido del registro es enmascarado por IMR (lnterrupt Mask Register). Si un
bit del ISR es 1 ; la salida INTRN (salida de interrupción en estado low) se
establecerá low. Si el bit es O no tendrá efecto en la salida INTRN.
ISR[7] Input Port Change Status. Este bit es 1 cuando existe algún cambio en las
entradas IPO, IP1, IP2, o IP3 y el evento se ha seleccionado para causar una
interrupción por el programa de ACR[3:0]. Los bits se borran cuando el CPU lee el
IPCR.
ISR[6] Channel B Change in Break. Este bit cuando se establece, indica que el
canal de recepción B ha detectado el inicio o fin del break receptor.
ISR[S] Rx RDY/FULL. Este bit indica que el canal de recepción B es interrumpido
de acuerdo a los niveles de programación que realicen los registros MRO y MR1.
ISR[4] Tx RDY/FULL. Este bit indica que el canal de transmisión B es
interrumpido de acuerdo a los niveles de interrupciones que realicen en el registro
MRO[S:4]
I O I
ISR[3] Counter Ready. En el modo counter, este bit se establece cuando el
counter alcanza el conteo final y se restablece cuando el counter se para
mediante el uso del comando stop.
ISR[2] Channel A Change in Break. Este bit cuando se establece indica que el
canal receptor A ha detectado el inico o fin del break receptor.
ISR[1] Rx RDY/FULL. Este bit indica que el canal de recepción A es interrumpido
de acuerdo a los niveles de programación que realicen los registros MRO y MR1.
ISR[O] Tx Rdy/FULL. Este bit indica que el canal de transmisión A es interrumpido
de acuerdo a los niveles de interrupciones que realicen en el registro MRO[S:4]
CTUR and CTLR. Counter/Timer Registers.
BIT 7 BIT 6 BIT 5 BIT 4 BIT 3 BIT 2 BIT 1 BIT O C/T[15] C!T[14) C!T[13] C!T[12] C!T[11] C!T[10) C!T[9) C!T[B]
CTUR
BIT 7 BIT 6 BIT 5 BIT 4 BIT 3 BIT 2 BIT 1 BIT O C!T[7] C!T[6) C!T[5] C!T[4] C!T[3] C!T[2] C!T[1] C/T[O]
CTLR
Los registros CTUR y CTLR mantienen los 8 MSB's y 8 LSB 's, respectivamente,
de los valores a ser usados por el counter/timer.
CSRA. Channel A and B Clock Select Register.
BIT 7 BIT 6 BITS BIT4 BIT3 BIT2 BIT1 BITO CSRA RECEIVER CLOCK SELECT TRANSMITTER CLOCK SELECT CSRB
102
CSRA[7:4] Canal de recepción A o B Clock Select. Este campo selecciona la
velocidad para el canal A o B de transmisión.
CSRA[3:0] Canal de transmisión A o B Clock Select. Este campo selecciona la
velocidad para el canal A o B de transmisión. La definición de los campos se
especifica en la tabla 1.
CRA. Channel A Command Register.
BIT 7 BIT 6 BIT5 BIT4 BIT3 BIT2 BIT1 BITO
CRA MISCELLANEOUS COMMANDS O isa ble Enable Di sable Enable
CRB Tx Tx Rx Rx
O= No O= No O= No O= No
1 = Yes 1 = Yes 1 = Yes 1 = Yes
CRA es un registro usado para proporcionar comandos a los canales A y B.
Múltiples comandos pueden ser especificados en una escritura al CRA siempre y
cuando los comandos no tengan conflictos. Por ejemplo: los comandos "enable
transmitter" y "reset transmitter" no pueden ser especificados en un comando de
palabra sencilla.
CRA[7:4]. Miscellaneous Commands.
Los valores seleccionados para estos campos pueden ser usados para
especificar un comando único de la siguiente manera:
CRA[6:4]. Command.
0000 No comando.
0001 Restablece apuntador MR.
001 O Restablece recepter.
0011 Restablece transmisor.
0100 Restablece error status.
0101 Restablece interruptor
011 O Forza Tx a low
0111 Forza Tx a high
1000 Forza RTSN a low
1001 Forza RTSN a high
101 O Restablece el time-out a modo on
1011 Establece apuntador MR a O
1100 Desabilita el modo time-out
1101 Reservado
111 O El DUART se apaga
1111 El DUART se inicia.
CRA[3]. Disable Channel A Transmitter
I o.:,
Este comando se encarga de las operaciones de transmisión y restablecimiento
del status de bits de TxDRY y TxEMT.
CRA[2]. Enable Channel A Transmitter
Habilita operaciones del canal de transmisión. El status del bit del TxRDY se
establece.
CRA[1 ]. Disable Channel A Receiver
Este comando se encarga de las operaciones del receptor.
10-t
ACR. Auxiliary Control Register.
BIT 7 BIT 6 BITS BIT3 BIT2 BIT1 BITO
BIT4
BRG SET COUNTER/TIMER DELTA DELTA DELTA DELTA
SELECT MODEAND IP 3 INT IP21NT IP 1 INT IP O INT
SOURCE
ACR O= set 1 O= Off O= Off O= Off O= Off
1 = set 2 1 = On 1 = On 1 = On 1 = On
ACR[7]. Baud Rate Generator Set Select.
Este bit selecciona uno o dos formatos de velocidad para ser generados por el
BRG ver tabla1.
ACR[6:4]. Counter/Timer Mode and Clock Source Select.
Este campo selecciona el modo de operación del counter/timer, ver tabla 2
ACR 6:4 MODE CLOCK SOURCE 000 Counter Externa! (IP2) 001 Counter TxCA-1X clock of Channel A tx 010 Counter TxCB-1 X clock of Channel B tx 011 Counter Crystal or externa! clock
(X1/CLK) divided by 16 100 Timer Externa! (IP2) 101 Timer Externa! (IP2) divided by 16 11 O Timer Crystal or externa! clock 111 Timer (X1/CLK)
Crystal or externa! clock (XI/CLK) divided by 16
Tabla 2
ACR[3:0] IP3, IP2, IP1, IPO Change of State lnterrupt Enable.
Este campo selecciona cuales bits del input port change register (IPCR) ocasiona
que el input change bit en el interrupt status register ISR[?] se establesca.
I O:i
IMR. lnterrupt Mask Register.
BIT 7 BITS BIT 5 BIT 4 BIT 3 BIT 2 BIT 1 BIT O
IN.PORT DELTA RxRDY/F TxRDYB COUNTER DELTA RxRDY/ TxRDYA
CHANGE BREAK B FULLB INT READY BREAK A FFULLA INT
INT INT INT INT INT INT
IMR O= off O= off O= off O= off O= off O= off O= off O= off
1 = on 1 = on 1 = on 1 = on 1 = on 1 = on 1 = on 1 = on
La programación de estos registros selecciona cual bit en el ISR ocasiona una
interrupción output. Si el bit en el ISR es "1" y el correspondiente bit en el IMR es
también "1" el output INTRN será seleccionado. Si el bit correspondiente en el
IMR es un cero, el estado del bit en el ISR no tendrá efecto en el output INTRN.
OPCR. Output Port Configuration Register.
BIT 7 BIT 6 BIT 5 BIT 4 BIT 3 BIT 2 BIT 1 BIT
o OP7 OP6 OP5 OP4 OP3 OP2
OPCR O= OPR[7] O= OPR[6] O= OPR[5] O= OPR[4] 00 = OPR[3] 00 = OPR[2]
1 = 1 = 1 = 1 = 01 = C!T OUTPUT 01 = TxCA(16X)
TxRDYB TxRDYA RxRDY/FF RxRDY/FF 10 = TxCB(1 X) 1 O = TxCA(1 X)
ULLB ULLA 11 = RxCB(1 x) 11 = RxCA(1 x)
OPCR(7]. OP7 Output Select.
Este bit programa el output del OP7 para proveer una de las siguientes
condiciones:
El complemento de OPR[7].
El Channel B transmitter interrrupt output el cual es el complemento de TxRDYB.
OPCR[6]. OP6 Output Select.
106
Este bit programa el output del OP6 para proveer una de las siguientes
condiciones:
El complemento de OPR[6].
El Channel A transmitter interrrupt output el cual es el complemento de TxRDY A
OPCR[5]. OP5 Output Select.
Este bit programa el output del OP5 para proveer una de las siguientes
condiciones:
El complemento de OPR[5].
El Channel B transmitter interrrupt output el cual es el complemento de ISR[5]
OPCR(5]. OP4 Output Select.
Este bit programa el output del OP4 para proveer una de las siguientes
condiciones:
El complemento de OPR[5].
El Channel A transmitter interrrupt output el cual es el complemento de ISR[1]
OPCR[3:2]. OP3 Output Select.
Este bit programa el output del OP3 para proveer una de las siguientes
condiciones:
El complemento de OPR[3].
El counter/timer output, en tal caso OP3 actua como un open-drain output.
El reloj 1 X para el canal de transmisión B , el cual se encarga de cambiar la
transmisión de datos.
El reloj 1 X para el canal de recepción B, el cual se encarga de tomar muestra de
los datos recibidos.
[()7
OPCR[1 :O]. OP2 Output Select.
Este bit programa el output del OP2 para proveer una de las siguientes
condiciones:
El complemento de OPR[2].
El counter/timer output, en tal caso OP3 actua como un open-drain output.
El reloj 1 X para el canal de transmisión A , el cual se encarga de cambiar la
transmísión de datos.
El reloj 1 X para el canal de recepción A, el cual se encarga de tomar muestra de
los datos recibidos.
108
APENDICE D PSEUDOCÓDIGOS Y PROGRAMAS
Pseudocódigo y Programas
El esquema de comunicación entre el controlador y los elementos de la celda de
manufactura consiste en un proceso interface que intercambia comandos entre la
red de transputers y un proceso driver, el cual a su vez comunica a los elementos
de la celda . El proceso interface es en donde se encuentra la definición del tipo
de tolerancia a fallas que tiene el sistema. La tolerancia se puede realizar usando
redundancia en hardware de dos formas; con redundancia en los procesadores o
redundancia en los robots.
D.1 ESQUEMA 1. UN PROCESO CONTROLADOR Y DOS ELEMENTOS ROBOT:
El proceso de interface entre la red de transputers y el driver está dividio a su vez
en un proceso de transmisión y un proceso de recepción. El proceso de
transmisión recibe instrucciones del controlador y las transmite al driver, el de
recepción recibe las contestaciones del driver y las retransmite al controlador.
D.1.1 ARCHIVO DE CONFIGURACIÓN
Este archivo contiene la distribución de procesos y canales en los procesadores
además de la llamada a los mismos . En general se tienen dos procesadores, uno
que hace las veces de la red de transputers y el otro que contiene al driver que
109
sirve de interface para la comunicación con el robot (ver figura D.1 ). Se usa un
arco para la comunicación con el host y también un nuevo arco para la
comunicación entre procesadores, éste arco es necesario para poder hacer uso
de las funciones que corresponden al uso extraordinario de enlaces , las cuales
pueden señalizar un error en la comunicación entre procesos.
Archivo : Conf. pgm
#INCLUDE "occonf.inc"
NODE p1 : NODE p2: ARC hostarc : ARC procarc :
NETWORK DO SET p 1 (type, memsize := "T805", 1 *M) SET p2(type, memsize := "T225", 16*K) CONNECT p1 [link)[OJ TO HOST WITH hostarc CONNECT p1 [link}[2] TO p2[1ink}[1] WITH procarc
#INCLUDE "hostio.inc" #INCLUDE "proto.inc" #INCLUDE "hostio.inc" #USE "aplic.lku" #USE "enlacei.lku" #USE "enlaceo.lku" #USE "robot.lku" #USE "driver.lku"
CONFIG CHAN OF SP fs, ts : CHAN OF ANY ch1 , ch2: --CHAN OF A.E a.a.e: CHAN OF ANY a.a.e: CHAN OF E.A e.a.a: CHAN OF A.El a.a.ei: --CHAN OF E.Al e.a.ai:
CHAN OF ANY e.a.ai: CHAN OF ANY e.a.r: CHAN OF ANY r.a.e: PLACE fs, ts ON hostarc : PLACE e.a.r,r.a.e ON procarc : PAR PROCESSOR p1 --SIOFEED(fs, ts,ch1 ,ch2) PAR aplic(fs,ts,a.a.e,e.a.a,a.a.ei,e.a.ai) enlaceo(a.a.e, e.a.a, e.a.r, a.a.ei, e.a.ai, r.a.e) --enlaceo(a.a.e,e.a.a,e.a.r) --enlacei(a.a.ei,e.a.ai,r.a.e) --robot( e .a.r,r.a.e)
PROCESSOR p2 810232.DRIVER(e.a.r,r.a.e) --robot(e.a.r ,r.a.e) --enlaceo(a.a.e, e.a.a, e.a.r, a.a.ei, e.a.ai, r.a.e)
~ HOSTARC
I o
HOST
P1 '
1
L,
APLIC
: 3
ENLACE O
-· ·-2
P1
PROARC
o
·-SI0232. DRIVER ; ; ;3 _
1
-- --- ·· 2
Figura D.1 Distribucion de procesos según el archivo de configuración.
T1
fs Is
APLIC
a.a .e I e .a.a
a.a.ei I I e.a.a,
SIO 232
' UNO ,=' - · e=.a=.r=====a 1
ch]ch2
-
r.a.e · DOS==-===-==;
ENLACE O SI0232.DRIVER
Figura D.2 Distribución de canales según el archivo de configuración
1 1 O
111
D.1.2 PROCESO APLIC
Programa en Occam: Aplic.occ
Nodo en el archivo de configuración: Aplic
Descripción:
Se encarga de recibir comandos desde la pe y transmitirlos al proceso de
interface, recibe los mensajes de la interface con la contestación del robot y
anuncia el cambio de puerto en caso de un error.
Flujo:
Carácter= enter 6
carácler = caracter
ENLACE0.1---~----,,. DOS
fENLACE0.1 DOS
1
cb
Configuracion del puerlo A y B del driver
ENLACE. J---~ UNO
EN LACEO. UNO
EN LACEO. UNO
Figura D.3a. Envío al robot y despliegue de contestación del robot
112
~'.' ~mensaJe
NO
Mensaje = Ack
ENLACE. UNO
EN LACEO. DOS
Figura D.3b. Recepción de comandos desde el host
ENLACE. UNO
Mensaje~ ack.final
Figura D.3c. Fin del proceso Aplicacion
Código:
#INCLUDE "hostio.inc" #INCLUDE "proto.inc"
PROC aplic(CHAN OF SP fs,ts, CHAN OF ANY a.a.e, CHAN OF E.A e.a.a, CHAN OF A.El a.a.ei, CHAN OF E.Al e.a.ai) #USE "hostio.lib" #INCLUDE "const.inc" BOOL sigue,finin,flagBack: INT hora,momento: TIMER reloj: [1]BYTE puerto:
--}}} --{{{ Protocol T AGS
-- SIO Driver Protocol T AGS
VAL BYTE sio.cmd.A VAL BYTE sio.cmd.B VAL BYTE sio.char.A VAL BYTE sio.char.B VAL BYTE sio.string.A VAL BYTE sio.string.B VAL BYTE sio.error VAL BYTE sio.set.ACR VAL BYTE sio.set.MROA VAL BYTE sio.set.CSRA VAL BYTE sio.set.CSRB VAL BYTE sio.set.CTR
IS 1 (BYTE) : IS 2 (BYTE): IS 3 (BYTE): IS 4 (BYTE): IS 5 (BYTE): IS 6 (BYTE):
IS 11 (BYTE) : IS 12 (BYTE) : -- set aux. control register IS 13 (BYTE) : -- set to MRO, write MROA IS 14 (BYTE) : -- set clock select register A IS 15 (BYTE) : -- set clock select register B
IS 16 (BYTE) : -- set CTUR and CTLR
VAL BYTE sio.enable.hs IS 31 (BYTE): -- enable RTS/CTS handshake VAL BYTE sio.disable.hs IS 32 (BYTE): -- disable RTS/CTS handshake
VAL BYTE sio.baud.1200 IS 40 (BYTE) : VAL BYTE sio.baud.2400 IS 41 (BYTE): VAL BYTE sio.baud.4800 IS 42 (BYTE) : VAL BYTE sio.baud.9600 IS 43 (BYTE) : VAL BYTE sio.baud.19.2K IS 44 (BYTE): VAL BYTE sio.baud.28.8K IS 45 (BYTE) : VAL BYTE sio.baud.57.6K IS 46 (BYTE): VAL BYTE sio.baud.115.2K IS 47 (BYTE): VAL BYTE sio.timer.mode IS (BYTE #DO) :
JU
--}}}
SEQ sigue:=TRUE finin:=TRUE flagBack:= TRUE
a.a.e ! sio.cmd.A; sio.baud.9600 so.write.string.nl(fs,ts,"Se mando configuracion puerto A") a.a.e ! sio.cmd.B; sio.baud.9600 so.write.string.nl(fs,ts,"Se mando configuracion puerto B") puerto[O]:= sio.char.A a.a.e ! sio.char.A
WHILE sigue BYTE cara: SEQ reloj? hora ALT e.a.ai? CASE carac.e.ai; cara BOOL continua: SEQ continua:= TRUE WHILE continua SEQ so.write.char(fs,ts,cara) IF cara <> salir SEQ --a.a.ei ! ack.carac.e.ai SKIP
TRUE SEQ SKIP --a.a.ei ! final.a.ei reloj ? momento ALT e.a.ai ? CASE carac.e.ai ; cara
SKIP final.e.ai
SKIP reloj ? AFTER (momento PLUS limrobot)
11~
IF
so.write.string.nl(fs,ts,"enlace no contesta fin") so.write.string.nl(fs,ts,"termino") continua:=FALSE sigue:=FALSE
cara= ni SEQ so.write .nl(fs,ts) continua:=FALSE
cara= salir SKIP
TRUE SEQ reloj ? momento ALT e.a.ai ? CASE carac.e .ai ;cara SKIP
final.e.ai SEQ sigue:=FALSE continua:=FALSE so.write.nl(fs,ts)
reloj ? AFTER (momento PLUS limrobot) continua:=FALSE
final.e.ai SEQ so.write.string.nl(fs,ts,"fin de proceso") sigue:= FALSE
error.p SEQ IF puerto[OJ = sio.char.A
SEQ a.a.e ! sio.char.B puerto[O] := sio.char.B so.write.string.nl(fs,ts,"cambio a puerto B") flagBack:=FALSE
puerto[OJ = sio.char.B SEQ a.a.e ! sio.char.A puerto[O] := sio.char.A so.write.string.nl(fs,ts,"cambio a puerto A") flagBack:=FALSE
115
TRUE SEO so .write .string .nl(fs ,ts, "fin") sigue:= FALSE
reloj ? AFTER (hora PLUS limite) BYTE resultado, caracter: SEO reloj? hora ALT e.a.a? CASE error SEO so.write.string.nl(fs,ts,"erro capa fisica no funciona")
ack.carac.a.e SEO so.write.string.nl(fs,ts,"ack")
reloj ? AFTER (hora PLUS lim2) SEO so.pollkey(fs,ts,caracter,resultado) IF resultado<>O(BYTE) SKIP
TRUE BOOL continua: SEO continua := TRUE WHILE continua
SEO IF resultado <> O(BYTE) SKIP
TRUE SEO so.write.char(fs,ts,caracter) IF caracter = ni SEO so.write.nl(fs,ts) continua:= FALSE
caracter = '\' SEO sigue:=FALSE continua:= FALSE finin:=FALSE
TRUE
116
IF
SKIP IF caracter <> '\' TIMER clock: INT tiempo: SEQ a.a.e ! carac.a.e;caracter clock ? tiempo ALT e.a.a? CASE error
SEQ so.write.string.nl(fs,ts,"error, no se pudo enviar al robot")
ack.carac.a.e SEQ so.write.string.nl(fs,ts,"ack")
clock ? AFTER (tiempo PLUS timeout) SEQ so.write.string.nl(fs,ts, "enlace no contesta") continua:= FALSE sigue:= FALSE finin := FALSE
TRUE TIMER clock: INTtiempo: SEQ a.a.e ! final.a.e clock ? tiempo ALT e.a.a? CASE error so.write.string.nl(fs,ts,"enlace no pudo usar link")
ack.carac.a.e SKIP
final.e.a SKIP
clock ? AFTER(tiempo PLUS timeout) SEQ so.write.string.nl(fs,ts,"No llega ack de fin") continua:=FALSE sigue:=FALSE finin:=FALSE
so.pollkey(fs,ts,caracter,resultado)
11 7
fin in TIMER reloj: INTtiempo: SEQ a.a.e ! final.a.e reloj ? tiempo ALT e.a.a? CASE final.e.a so.write.string.nl(fs,ts, "termino")
reloj ? AFTER (tiempo PLUS timeout) so.write.string.nl(fs,ts, "enlace no contesto")
TRUE ........ SKIP so.exit(fs,ts,sps.success)
118
119
Forma de compilarlo:
Compilar el archivo en occam: Ejecutar los siguientes comandos desde el prompt
de DOS:
oc t805 aplic.occ /t805 /y
Crear un archivo aplic.lnk como el siguiente:
aplic.tco
convert.lib hostio.lib
occamuti.lib occam8.lib virtual.lib
Ligar el archivo compilado aplic.tco con sus librerías
ilink /f aplic.lnk /me aplic /t805 /y
120
D.1.3 PROCESO ENLACEO
Programa en Occam: Enlaceo.occ
Nodo en el archivo de configuración: Enlaceo
Descripción:
Recibe los comando del proceso APLIC y los retransmite de forma adecuada al
driver SIO, recibe la contestación
Se encarga de recibir comandos desde la pe y transmitirlos al proceso de
interface, recibe los mensajes de la interface con la contestación del robot y
anuncia el cambio de puerto en caso de un error.
Flujo:
APLIC
Enviar sio.cmd.A . caracter SI0 .232
Enviar ·sio.char A ENLACE OOS
APLIC
ENLACE UNO
APLIC Recibir caracter
Enviar sio. cmd. B . caracter SI0.232
Enviar :s10 char,8 ENLACE. OOS
ENLACE OOS
Enviar .fm
Figura D.4a. Proceso de enlace que envía comandos al sio 232
APLIC
121
APLIC
510.232
510.232
APLIC
Enviar :error APLIC
Enviar :inicio reloj ENLACE.DOS
SI0.232
Figura D.4b. Proceso de enlace que envía comandos al sio 232
I Enviar •dato~
caracter = sio.char.A
ENLACE UNO Recibir: Caracter
caracter = inicio relej
Flag Enter
Figura D.4c. Proceso de enlace que recibe comandos del sio 232
Código:
#INCLUDE "hostio.inc" #INCLUDE "proto.inc" #INCLUDE "const.inc" #INCLUDE "proto.inc"
PROC enlaceo(CHAN OF ANY a.a.e, CHAN OF E.A e.a.a, CHAN OF ANY e.a.r,CHAN OF A.El a.a.ei, CHAN OF ANY e.a.ai, CHAN OF ANY r.a.e)
122
PROC dos(CHAN OF A.El a.a.ei, CHAN OF ANY e.a.ai, CHAN OF ANY r.a.e,CHAN OF ANY ch1 ,CHAN OF ANY ch2)
#USE "hostio.lib" #USE "xlink.lib" --{{{ Protocol T AGS
-- SIO Driver Protocol T AGS
VAL BYTE sio.cmd.A VAL BYTE sio.cmd.B VAL BYTE sio.char.A VAL BYTE sio.char.B VAL BYTE sio.string.A VAL BYTE sio.string.B VAL BYTE sio.error VAL BYTE sio.set.ACR VAL BYTE sio.set.MROA VAL BYTE sio.set.CSRA VAL BYTE sio.set.CSRB VAL BYTE sio.set.CTR
IS 1 (BYTE): IS 2 (BYTE): IS 3 (BYTE): IS 4 (BYTE): IS 5 (BYTE): IS 6 (BYTE):
IS 11 (BYTE) : IS 12 (BYTE) : -- set aux. control register IS 13 (BYTE) : -- set to MRO, write MROA IS 14 (BYTE) : -- set clock select register A IS 15 (BYTE) : -- set clock select register B
IS 16 (BYTE) : -- set CTUR and CTLR
VAL BYTE sio.enable.hs IS 31 (BYTE): -- enable RTS/CTS handshake VAL BYTE sio.disable.hs IS 32 (BYTE) : -- disable RTS/CTS handshake
VAL BYTE sio.baud.1200 IS 40 (BYTE): VAL BYTE sio.baud.2400 IS 41 (BYTE): VAL BYTE sio.baud.4800 IS 42 (BYTE): VAL BYTE sio.baud.9600 IS 43 (BYTE) : VAL BYTE sio.baud.19.2K IS 44 (BYTE): VAL BYTE sio.baud.28.8K IS 45 (BYTE): VAL BYTE sio.baud.57.6K IS 46 (BYTE): VAL BYTE sio.baud.115.2K IS 47 (BYTE) : VAL BYTE sio.timer.mode IS (BYTE #DO):
--}}}
BOOL sigue,enter,flagBack: VAL limvuel IS 4: SEO sigue:=TRUE enter:=FALSE flagBack:= TRUE WHILE sigue
f1 JBYTE caracter: [1]BYTE a: [1]BYTE tag, tagin,puerto: BOOL banderror, abortado: TIMER reloj,reloj2: INT hora,hora2,vuelta: SEO abortado:=FALSE reloj2 ? hora2 --lnputOrFail.t(r.a.e,tag,reloj,hora,abortado) ALT --r.a.e ? tag -- SEO -- r.a.e ? caracter -- vuelta:= O -- WHILE(vuelta<limvuel)
SEO e.a.ai!carac.e.ai ; caracter vuelta:=limvuel --lzv reloj? hora --ALT -- a.a.ei ? CASE -- ack.carac.e.ai
SEO vuelta:=limvuel
-- final.a.ei SEO e.a.ai!final.e.ai sigue:=FALSE vuelta:=limvuel
-- reloj ? AFTER(hora PLUS timeout) -- SEO
vuelta:= vuelta + 1 IF vuelta>=limvuel
12.:l
sigue:=FALSE TRUE SKIP
r.a.e? tag SEQ r.a.e ? caracter vuelta:= O enter:=FALSE WHILE(vuelta<limvuel) SEQ IF tag[O] = puerto[O] SEQ e.a.ai!carac.e.ai ; caracter
TRUE SEQ
a[O]:= '$' ., . e.a.a1.carac.e.a1 ; a --SKIP
vuelta:=limvuel --lzv reloj2 ? AFTER(hora2 PLUS 100000)
SEQ IF enter
SEQ --e.a.ai!final.e.ai ., e.a.a1.error.p
TRUE SEQ SKIP
ch1 ? tagin SEQ CASE tagin[O] sio.char.A
SEQ puerto[O]:=sío.char.A
sio.char.B SEQ puerto[O]:=sio.char.B
1 (BYTE) SEQ enter :=TRUE
: PROC uno(CHAN OF ANY a.a.e, CHAN OF E.A e.a.a,
124
CHAN OF ANY e.a.r,CHAN OF ANY ch1 ,CHAN OF ANY ch2)
#USE "hostio.lib" #USE "xlink.lib" --{{{ Protocol TAGS
-- SIO Driver Protocol T AGS
VAL BYTE sio.cmd.A VAL BYTE sio.cmd.B VAL BYTE sio.char.A VAL BYTE sio.char.B VAL BYTE sio.string.A VAL BYTE sio.string.B VAL BYTE sio.error VAL BYTE sio.set.ACR VAL BYTE sio.set.MROA VAL BYTE sio.set.CSRA VAL BYTE sio.set.CSRB VAL BYTE sio.set.CTR
IS 1 (BYTE): IS 2 (BYTE): IS 3 (BYTE) : IS 4 (BYTE) : IS 5 (BYTE): IS 6 (BYTE):
IS 11 (BYTE): IS 12 (BYTE) : -- set aux. control register IS 13 (BYTE) : -- set to MRO, write MROA IS 14 (BYTE) : -- set clock select register A IS 15 (BYTE) : -- set clock select register B
IS 16 (BYTE) : -- set CTUR and CTLR
VAL BYTE sio.enable.hs IS 31 (BYTE) : -- enable RTS/CTS handshake VAL BYTE sio.disable.hs IS 32 (BYTE) : -- disable RTS/CTS handshake
VAL BYTE sio.baud.1200 IS 40 (BYTE): VAL BYTE sio.baud.2400 IS 41 (BYTE): VAL BYTE sio.baud.4800 IS 42 (BYTE): VAL BYTE sio.baud.9600 IS 43 (BYTE): VAL BYTE sio.baud.19.2K IS 44 (BYTE): VAL BYTE sio.baud.28.BK IS 45 (BYTE) : VAL BYTE sio.baud.57.6K IS 46 (BYTE) : VAL BYTE sio.baud.115.2K IS 47 (BYTE) : VAL BYTE sio.timer.mode IS (BYTE #DO):
--}}}
VAL limvuel IS 4: BOOL sigue: TIMER reloj2: INT hora2:
[1]BYTE tag: SEQ sigue:=TRUE reloj2 ? hora2
125
WHILE sigue [1 ]BYTE caracter: [1]BYTE temp: BOOL banderror, abortado: TIMER reloj: INT hora.vuelta: SEQ abortado:=FALSE ALT a.a.e? tag CASE tag[OJ sio.cmd.A SEQ a.a.e ? caracter e.a.r ! sio.cmd.A;caracter temp[OJ:=sio.char.A ch1 !sio.char.A
sio.cmd.B SEQ a.a.e ? caracter e.a.r ! sio.cmd.B;caracter temp[OJ:=sio.char.B ch1 !sio.char.B
sio.char.A SEQ temp[OJ:=sio.char.A ch1 !sio.char.A
sio.char.B SEQ temp[O]:=sio.char.B ch1 !sio.char.B
carac.a.e INT vuelta: SEQ a.a.e ? caracter vuelta:= O WHILE(vuelta<limvuel) SEQ reloj? hora hora := hora PLUS 100 OutputOrFail.t(e.a.r, temp, reloj, hora, abortado) IF abortado= FALSE SEQ reloj? hora
126
SEQ
hora := hora PLUS 100 OutputOrFail.t(e.a.r, caracter, reloj, hora, abortado)
TRUE SEQ SKIP
IF abortado SEQ vuelta:=vuelta+ 1
TRUE vuelta:=limvuel
IF abortado SEQ e.a.a ! error --e .a.a!final .e .a
TRUE SEQ e.a.a!ack.carac.a.e IF caracter[O] = ni SEQ ch 1 ! 1 (BYTE)
TRUE SEQ SKIP
final.a.e SEQ e.a.a!final.e.a sigue:=FALSE
--reloj2 ? AFTER(hora2 PLUS 1000) -- SEQ -- SKIP
CHAN OF ANY ch1,ch2: PAR uno(a.a.e, e.a.a, e.a.r ,ch1 ,ch2 ) dos(a.a.ei,e.a.ai,r.a.e ,ch1 ,ch2)
127
128
Forma de compilarlo:
Compilar el archivo en occam: Ejecutar los siguientes comandos desde el prompt
de DOS:
oc t805 enlaceo.occ /t805 /y
Crear un archivo enlaceo.lnk como el siguiente:
enlaceo.tco
convert.lib hostio.lib xlink.lib
occamutl.lib occam8.lib virtual.lib
Ligar el archivo compilado enlaceo.tco con sus librerías
ilink /f enlaceo.lnk /me enlaceo /t805 /y
D.1.4 PROCESO 510232.DRIVER
Programa en Occam: Driver.occ
Nodo en el archivo de configuración: Sio232.Driver
Descripción:
Recibe los caracteres del proceso enlaceo los cuales convierte de forma
adecuada para enviarlos al puerto correspondiente del SIO RS232, tambien lee
información del puerto y la envia de igual forma a la parte del proceso enlaceo
que se encarga de la recepción.
Flujo:
510232.DRIVER
Asignar direcciones físicas a registros de 110
Asignar aliases para registros de 1/0
Definir mensajes del protocolo
Definir configuración de comunicación de default ; puerto A
Definir configuración de comunicación de default ; puerto B
puerto A: Iniciar transmisor Iniciar receptor Iniciar estado de error Habilitar transmisor y receptor
puertoB: Iniciar transmisor Iniciar receptor Iniciar estado de error Habilitar transmisor y receptor
129
Figura D.Sa Definición de variables y configuracion inicial dentro del driver 510
Send.c:har ? :arader ANO
Flag.xmit.BufferConEspacio
SI
Flag.xmit.BufferConEspacio =FALSE
vvanl.dlan.dlar? Petidon ANO
Flag,rcvr.Buffc-NoVacio
SI
Flag.rcvr.BufferNoVacio = FALSE
Registro.~ntos? evento
NO
Figura D.5b Atencion a peticiones de transmisión e interrupciones de eventos. Lectura y escritura de los buffer de transmisión y recepción
NO
Rcvr.buffer =dato en registro
Flag.rcvrBufferNoVacio = TRUE
SI
dato en registro = xmítbuffer
FJag.xmit.BufferConEspacio= TRUE
Deshabilitar la inlerrupc1on de escritura en puerto
Figura O.Se Atención a interrupción de lectura y escritura en puerto
130
Mux.out? Sio.char:caracter
Get.chan ? result
ENLACE UNO
SI
ENLACE UNO
+
ENLACE DOS
Send.char • caracter
Temp = Habilitar RTS I CTS en el puerto Temp = Deshabilltar RTS I CTS en el puerto Temp = Configurar velocidad
Configuracion Registro= Temp
Figura 0.5 d. Envío de caracteres a la red de transputers. Recepción de información de la red de transputers (caracteres, comandos y
configuración).
Codigo:
--{{{ sorne notes for the user
PROC SI0232.DRIVER (CHAN OF ANY in , out) --{{{ Global Declarations --{{{ hardware declarations
-- Hardware register declarations
[16]1NT Uart.read : PLACE Uart.read AT {#7COO >< (MOSTNEG INT)) » 1 : --PLACE Uart.read AT #7COO: [16]1NT Uart.write :
111
PLACE Uart.write AT (#7COO >< (MOSTNEG INT)) » 1 : --PLACE Uart.write AT #7COO: [4]1NT nlntRd : PLACE nlntRd AT (#7000 >< (MOSTNEG INT)) » 1 : --PLACE nlntRd AT #7000 : [4]1NT lntWr : PLACE lntWr AT (#7EOO >< (MOSTNEG INT)) » 1 : --PLACE lntWr AT #7EOO : --}}} --{{{ io.page retypes
-- Register aliases
INT mode.reg.A IS Uart.read[O] : -- Read Registers INT status.reg.A IS Uart.read[1] : INT receive.reg.A IS Uart.read[3] : INT port.change.reg IS Uart.read[4] : INT uart.int.status IS Uart.read[S] : INT mode.reg.B IS Uart.read[8] : INT status.reg.B IS Uart.read[9] : INT receive.reg.B IS Uart.read[11]: INT input.port IS Uart.read[13] : INT start.counter IS Uart.read[14] : INT stop.counter IS Uart.read[15] :
INT clock.sel.reg.A IS Uart.write[1] : -- Write registers INT command.reg.A IS Uart.write[2] : INT transmit.reg.A IS Uart.write[3] : INT aux.control.reg IS Uart.write[4] : INT int.mask.reg IS Uart.write[S] : INT count.fime.hi IS Uart.write[6] : INT count.fime.lo IS Uart.write[7] : INT clock.sel.reg.B IS Uart.write[9] : INT command.reg.B IS Uart.write[1 O] : INT transmit.reg.B IS Uart.write[11] : INT output.conf.reg IS Uart.write[13] : INT set.output.bits IS Uart.write[14] : INT clear.output.bits IS Uart.write[15] :
INT int.enable IS lntWr(O] : INT int.clear IS lntWr[1] : INT Csr IS lntWr[2] : INT master IS lntWr[3]:
INT int.poll IS nlntRd[O] :
INT int.status IS nlntRd[1] : INT Csr.readback IS nlntRd[2]: INT is.master IS nlntRd[3] :
--}}} --{{{ masks and constants
-- UART Masks
VAL INT uart.int VAL INT spare.int VAL INT aux.int.A VAL INT aux.int.B
VAL INT master.int.en VAL INT invert.spare VAL INT invert.aux VAL INT CpuRst
VAL INT RxRdyStatus VAL INT status.fifo.full VAL INT TxRdyStatus VAL INT TxRdyA VAL INT RxRdyA VAL INT delta.break.A VAL INT counter.ready VAL INT TxRdyB VAL INT RxRdyB
IS #1 : -- level sensitive IS#2: IS#4: IS#8:
18#1: IS#2:
IS#4: 18#8:
IS #1 : -- Both status registers IS #2 : -- Both status registers
IS #8 : -- Both status registers IS #1 : IS#2 : IS#4:
VAL INT delta.break.B VAL INT input.port.change
IS#8 : 18#10: 18#20: 18#40:
18#80:
VAL INT ready.to.send.A IS #1 : VAL INT ready.to.send.B IS #2 : VAL INT data.terminal.ready.A IS #4 : VAL INT data.terminal.ready.B IS #8 :
VAL INT clear.to.send.A IS #1 : VAL INT clear.to.send.B IS #2 : VAL INT data.set.ready.A IS #4 : VAL INT data.set.ready.B IS #8 : VAL INT data.carrier.detect.A IS #10: VAL INT data.carrier.detect.B IS #20:
--}}} --{{{ channels
-- Interna! Channels
CHAN OF INT get.chan.A, get.chan.B, send.chan.A, send.chan.B : CHAN OF INT want.chan.A.char, want.chan.B.char:
--}}} --{{{ Protocol T AGS
-- SIO Driver Protocol T AGS
VAL BYTE sio.cmd.A VAL BYTE sio.cmd.B VAL BYTE sio.char.A VAL BYTE sio.char.B VAL BYTE sio.string.A VAL BYTE sio.string.B VAL BYTE sio.error VAL BYTE sio.set.ACR VAL BYTE sio.set.MROA VAL BYTE sio.set.CSRA VAL BYTE sio.set.CSRB VAL BYTE sio.set.CTR
IS 1 (BYTE) : IS 2 (BYTE): IS 3 (BYTE) : IS 4 (BYTE) : IS 5 (BYTE): IS 6 (BYTE):
IS 11 (BYTE) : IS 12 (BYTE) : -- set aux. control register IS 13 (BYTE) : -- set to MRO, write MROA IS 14 (BYTE) : -- set clock select register A IS 15 (BYTE) : -- set clock select register B
IS 16 (BYTE) : -- set CTUR and CTLR
VAL BYTE sio.enable.hs IS 31 (BYTE) : -- enable RTS/CTS handshake VAL BYTE sio.disable.hs IS 32 (BYTE): -- disable RTS/CTS handshake
VAL BYTE sio.baud.1200 IS 40 (BYTE): VAL BYTE sio.baud.2400 IS 41 (BYTE) : VAL BYTE sio.baud.4800 IS 42 (BYTE): VAL BYTE sio.baud.9600 IS 43 (BYTE): VAL BYTE sio.baud.19.2K IS 44 (BYTE): VAL BYTE sio.baud.28.BK IS 45 (BYTE) : VAL BYTE sio.baud.57.6K IS 46 (BYTE): VAL BYTE sio.baud.115.2K IS 47 (BYTE): VAL BYTE sio.timer.mode IS (BYTE #DO) :
--}}} --{{{ setup Parameters
-- change mode register masks
VAL sio.set.hs.1 VAL sio.set.hs.2 VAL sio.clear.hs.1
IS #93: -- MR1 value IS #17 : -- MR2 value IS #13: -- MR1 value
VAL sio.clear.hs.2 IS #07: -- MR2 value
-- Other baude rates available, see Signetics manual pp15.
VAL DINT set.baud.1200 IS [#00, #66) : VAL DINT set.baud.2400 IS [#00, #88] : VAL DINT set.baud.4800 IS [#00, #99) : VAL DINT set.baud.9600 IS [#00, #88) : VAL DINT set.baud.19.2K IS [#00, #CC] : VAL DINT set.baud.28.8K IS [#01, #99] : VAL DINT set.baud.57.6K IS [#01, #88) : VAL DINT set.baud.115.2K IS [#01, #CC]:
--}}} --{{{ default REGISTER values
-- Default setup is for 19.2K 8aud, NO RTS/CTS handshake, be carefull with ACR -- ACR: -- all delta interrupts are DISA8LED -- baud rate generator set = 2 -- TIMER set for 1 X externa! source
VAL DINT Def.A.Setup IS [#EO, -- aux.control.reg #01 , -- MROA - no watchdog, normal baud #13, -- MR1A-noparity881TSDATOS #07, -- MR2A - 1 stop bits,DESA8LE CTS, NO RTS #CC] : -- clock.sel.reg RX,TX 19200
VAL DINT Def.B.Setup IS [#EO, -- aux.control.reg
--}}} --{{{ setup buffers
#00, -- MR08- same as A reg bank #13, -- MR18 #07, -- MR2B #CC] : -- clock.sel.reg
[5]1NT Reg.Setup.A : -- setup values of auxiliary, [5]1NT Reg.Setup.8 : -- mode reg's and clock reg.
--}}}
BYTE tx: INT result :
1]5
INT should.be :
--}}} --{{{ PROCS --{{{ wait () PROC wait (VAL INT num.ticks) TIMER clock : INTtime: SEQ clock? time time := time PLUS num.ticks clock ? AFTER time
--}}} --{{{ ResetUart () PROC ResetUart () -- Reset DUART, toggle reset bit INT result : INT should.be : SEQ Csr := CpuRst result := Csr.readback /\ #F should.be := CpuRst f\ #F --{{{ check result IF
--}}}
result <> should.be CAUSEERROR()
TRUE SKIP
Csr := O output.conf.reg := O -- initialize so OP2 & OP3 can be toggled
--}}} --{{{ COMMENT Mode register notes --:::A O O
-- The mode registers are set by writing to the same address three -- consecutive times; the first write sets MRO, the second write -- sets MR1, and the third write set MR2. -- See text in manual at paragraph 9 of page 1 O
136
-- The mode register pointer is set by the command register.
--}}} --{{{ SetupAReg () PROC SetupAReg (VAL OINT Reg.8ase) SEQ aux.control.reg := Reg.8ase[O] --A and 8 are same value
command.reg.A := #80 wait (1) command.reg.A := #20 wait (1) command.reg.A := #30 wait (1) command.reg.A := #40 wait (1) command.reg.A := #85
-- reset pointer to MROA
-- reset transmitter
-- reset receiver
-- reset error status
-- enable xmitter & rcvr, assert RTSA
mode.reg.A mode.reg.A mode.reg.A
:= Reg.8ase[1] -- MROA := Reg.Base[2] -- MR1A := Reg.8ase[3] -- MR2A
clock.sel.reg.A := Reg.Base[4]
--}}} --{{{ SetupBReg () PROC Setup8Reg (VAL OINT Reg.8ase) SEQ command.reg.B := #80 wait (1) command.reg.B := #20 wait (1) command.reg.8 := #30 wait (1) command.reg.8 := #40 wait (1) command.reg.8 := #85
-- reset pointer to MR08
-- reset transmitter
-- reset receiver
-- reset error status
-- enable xmitter & rcvr, assert RTS8
mode.reg.8 mode.reg.8 mode.reg.8
:= Reg.8ase[1] -- MROB := Reg.Base[2] -- MR18 := Reg.Base[3] -- MR2B
clock.sel.reg.B := Reg.Base[4]
U 7
--}}} --}}} SEQ --{{{ copy register setup values
SEQ i = O FOR 5 SEQ
--}}}
Reg.Setup.A[i] := Def.A.Setup[i] Reg.Setup.B[i] := Def.B.Setupp]
--Csr := CpuRst --result := Csr.readback !\ #F --should.be := CpuRst !\ #F --VAL [2]BYTE info.b RETYPES result:
--out! [info.b FROM O FOR 2]
--IF -- result <> should.be -- SEQ -- tx:='E' -- out! tx -- CAUSEERROR() -- TRUE -- SEQ -- tx:='M' -- out! tx
--Csr := O --output.conf.reg := O -- initialize so OP2 & OP3 can be toggled
ResetUart()
SetupAReg (Reg.Setup.A) SetupBReg (Reg.Setup.B)
WHILETRUE PAR
--{{{ UART 1/0 process, fills and empties ring buffers --{{{ NOTES
138
-- The user should be careful about changing this code. Make sure that -- you understand how the UART operates before you modify this code.
--}}} --{{{ declarations CHAN OF ANY event : PLACE event AT 8 :
BYTE event.byte :
VAL INT A.xmit.buffer.size IS 64 : VAL INT A.rcvr.buffer.size IS 64 : VAL INT B.xmit.buffer.size IS 64 : VAL INT B.rcvr.buffer.size IS 64 :
INT chan.A.rcvr.count : INT chan.A.xmit.count: INT chan.B.rcvr.count: INT chan.B.xmit.count : INT chan.A.status : INT chan.B.status : INT uart.poll: INT poli : INT request : INT result: INT send.char.A : INT send.char.B : INT send.A.rcvr : INT send.B.rcvr : INT store.A.rcvr : INT store.B.rcvr : INT send.A.xmit : INT send.B.xmit : INT store.A.xmit : INT store.B.xmit : INT uart.int.mask :
[A.xmit.buffer.size]INT A.xmit.buffer: [A.rcvr.buffer.size]INT B.xmit.buffer: [B.xmit.buffer.size]INT A.rcvr.buffer : [B.rcvr.buffer.size]INT B.rcvr.buffer :
BOOL fifo.A.been.full : BOOL fifo.B.been.full :
139
BOOL chan.A.not.empty : BOOL chan.B.not.empty : BOOL chan.A.room: BOOL chan.B.room :
--}}} SEQ
--{{{ lnitialize UART interrupts
uart.int.mask int.mask.reg int.enable
:= RxRdyA V RxRdyB -- UART interrupt masks := uart.int.mask -- Load UART mask register
:= O -- Clear Transputer interrupts
--}}} --{{{ initialize ring buffer control variables
result := O -- general usage chan.A.xmit.count := O chan.A.rcvr.count := O chan.B.xmit.count := O chan.B.rcvr.count := O store.A.xmit := O store.B.xmit := O send.A.xmit := O send.B.xmit := O store.A.rcvr := O store.B.rcvr := O send.A.rcvr := O send.B.rcvr := O
chan.A.room := TRUE chan.A.not.empty := FALSE chan.B.room := TRUE chan.B.not.empty := FALSE fifo.A.been.full := FALSE fifo.B.been.full := FALSE
--}}}
-- Ring buffer CHAR counters
-- Ring buffer input and -- output pointers
WHILE TRUE -- could use (flagA OR flagB) SEQ --{{{ transputer interrupts int.enable := uart.int master := master.int.en --}}}
1 ~()
ALT chan.A.room & send.chan.A? send.char.A --{{{ channel A transmit SEO IF (uart.int.mask A TxRdyA) <> TxRdyA
SEO uart.int.mask := uart.int.mask V TxRdyA int.mask.reg := uart.int.mask
TRUE SKIP
-- Enabling TxRdyA (above) will cause an immediate interrupt, -- if the UART transmit FIFO is not full.
A.xmit.buffer[store.A.xmit] := send.char.A store.A.xmit := (store.A.xmit PLUS 1) A (A.xmit.buffer.size - 1) -- cause modulo indexing, requires power of two buffer size
chan.A.xmit.count := chan.A.xmit.count PLUS 1 IF chan.A.xmit.count >= A.xmit.buffer.size
chan.A.room := FALSE TRUE
SKIP
--}}} chan.B.room & send.chan.B ? send.char.B --{{{ channel B transmit SEO IF (uart.int.mask A TxRdyB) <> TxRdyB
SEQ uart.int.mask := uart.int.mask V TxRdyB int.mask.reg := uart.int.mask
TRUE SKIP
-- Enabling TxRdyB (above) will cause an immediate interrupt, -- if the UART transmit FI FO is not full.
B.xmit.buffer[store.B.xmit] := send.char.B store.B.xmit := (store.B.xmit PLUS 1) A (B.xmit.buffer.size - 1) -- cause modulo indexing, requires power of two buffer size
l~I
chan.B.xmit.count := chan.B.xmit.count PLUS 1 IF chan.B.xmit.count >= B.xmit.buffer.size
chan.B.room := FALSE TRUE
SKIP
--}}} chan.A.not.empty & want.chan.A.char? request --{{{ channel A recieve SEO result := A.rcvr.buffer[send.A.rcvr] get.chan.A ! result send.A.rcvr := (send.A.rcvr PLUS 1) /\ (A.rcvr.buffer.size - 1) chan.A.rcvr.count := chan.A.rcvr.count MINUS 1 IF chan.A.rcvr.count < O
CAUSEERROR() chan.A.rcvr.count = O
chan.A.not.empty := FALSE TRUE
SKIP
--}}} chan.B.not.empty & want.chan.B.char? request --{{{ channel B recieve SEO result := B.rcvr.buffer[send.B.rcvr] get.chan.B ! result send.B.rcvr := (send.B.rcvr PLUS 1) /\ (B.rcvr.buffer.size - 1) chan.B.rcvr.count := chan.B.rcvr.count MINUS 1 IF chan.B.rcvr.count < O
CAUSEERROR() chan.B.rcvr.count = O
chan.B.not.empty := FALSE TRUE
SKIP
--}}} event? event.byte --{{{ event service routine SEO poll := int.poll /\ #F int.enable := O
l-l-2
IF (poli /\ uart.int) = uart.int
--{{{ service uart ínterrupt SEO uart.poll := uart.ínt.status /\ #FF chan.A.status := status.reg.A /\ #FF chan.B.status := status.reg.B /\ #FF --{{{ channel A recieve IF ((uart.poll /\ RxRdyA) = RxRdyA) ANO
((chan.A.status /\ RxRdyStatus) = RxRdyStatus) SEO
result := (status.reg.A /\ #FF) « 8 A.rcvr.buffer[store.A.rcvr] := (receive.reg.A /\ #FF) V result store.A.rcvr := (store.A.rcvr PLUS 1) /\ (A.rcvr.buffer.síze - 1)
-- the high byte contains the status of the character, ie. overrun, -- parity error, framing error or received break.
chan.A.rcvr.count := chan.A.rcvr.count PLUS 1 chan.A.not.empty := TRUE
TRUE SKIP
--}}} --{{{ channel B recieve IF ((uart.poll /\ RxRdyB) = RxRdyB) ANO
((chan.B.status /\ RxRdyStatus) = RxRdyStatus) SEO
result := (status.reg.B /\ #FF) « 8 B.rcvr.buffer[store.B.rcvr] := (receive.reg.B f\ #FF) V result store.B.rcvr := (store.B.rcvr PLUS 1) /\ (B.rcvr.buffer.size - 1)
-- the high byte contains the status of the character, ie. overrun, -- parity error, framing error or received break.
chan.B.rcvr.count := chan.B.rcvr.count PLUS 1 chan.B.not.empty := TRUE
TRUE SKIP
--}}} --{{{ channel A transmit
1-B
IF (((uart.poll /\ TxRdyA) = TxRdyA) ANO
((chan.A.status /\ TxRdyStatus) = TxRdyStatus)) ANO (chan.A.xmit.count > O)
SEQ transmit.reg.A := A.xmit.buffer[send.A.xmit] send.A.xmit := (send.A.xmit PLUS 1) /\ (A.xmit.buffer.size - 1) chan.A.xmit.count := chan.A.xmit.count MINUS 1 IF chan.A.xmit.count = O SEQ uart.int.mask := uart.int.mask /\ (-TxRdyA) int.mask.reg := uart.int.mask
chan.A.xmit.count < O CAUSEERROR()
TRUE SKIP
IF chan.A.xmit.count < A.xmit.buffer.size chan.A.room := TRUE
TRUE SKIP
TRUE SKIP
--}}} --{{{ channel B transmit IF (((uart.poll /\ TxRdyB) = TxRdyB) ANO
((chan.B.status /\ TxRdyStatus) = TxRdyStatus)) ANO (chan.B.xmit.count > O)
SEQ transmit.reg.B := B.xmit.buffer[send.B.xmit] send.B.xmit := (send.B.xmit PLUS 1) /\ (B.xmit.buffer.size - 1) chan.B.xmit.count := chan.B.xmit.count MINUS 1 IF chan.B.xmit.count = O SEQ uart.int.mask := uart.int.mask /\ (-TxRdyB) int.mask.reg := uart.int.mask
chan.B.xmit.count < O CAUSEERROR()
TRUE SKIP
IF chan.B.xmit.count < B.xmit.buffer.size
TRUE SKIP
--}}} --}}}
TRUE
chan.B.room := TRUE TRUE SKIP
CAUSEERROR() -- unexpected interrupt
--}}}
--}}} --{{{ main program --{{{ COMMENT --:::A O O
-- note: characters are sent as integers. The UART only uses the low 8 bits. -- The top 8 bits are discarded when transmitted. -- When characters are returned from the UART the high eight (8) bits -- contain the received status for the character, it can be ignored under -- most circumstances. -- Conversion is required [somewhere in the path] if BYTEs are to be sent. -- send.char.A := INT("a") converts the letter "a" to an integer.
--}}} --{{{ declarations (2]CHAN OF ANY mux.out : --}}} PAR --{{{ Channel B input, send out link INT get.char.B : SEQ WHILETRUE
SEQ want.chan.B.char ! O -- request a character get.chan.B? get.char.B mux.out[O] ! sio.char.B; (BYTE (get.char.B f\ #FF))
--}}} --{{{ Channel A input, send out link INT get.char.A : SEQ WHILETRUE
SEQ
--}}}
want.chan.A.char ! O -- request a character get.chan.A? get.char.A mux.out[1] ! sio.char.A; (BYTE (get.char.A /\ #FF))
--{{{ output link muxer WHILETRUE
BYTE ctag, char: ALT
mux.out[OJ ? ctag; char out ! ctag; char --SKIP
mux.out[1]? ctag; char out ! ctag; char --SKIP
--}}}
--{{{ Link input, character and commands --{{{ declarations BYTE tag:
--}}} WHILETRUE SEO in? tag CASE (tag)
--{{{ chan B char output sio.char.B BYTE char: SEO in? char send.chan.B ! (INT char)
--}}} --{{{ chan A char output sio.char.A
BYTE char: SEO
in? char send.chan.A ! (INT char)
--out! '1 '; 'E'
] .J6
--}}} --{{{ chan B string output sio.string.B INT wcount: [255]BYTE string: SEQ in ? wcount: :string SEQ i = O FOR wcount send.chan.B ! (INT string[i])
--}}} --{{{ chan A string output sio.string.A INTwcount : [255]BYTE string : SEQ
in ? wcount::string SEQ i = O FOR wcount send.chan.A ! (INT string[i])
--}}} --{{{ chan A command sio.cmd.A
BYTE cmd : SEQ in? cmd CASE (cmd) --{{{ enable RTS/CTS sio.enable.hs
--}}}
SEQ Reg.Setup.A[2] := sio.set.hs.1 Reg.Setup.A[3] := sio.set.hs.2
--{{{ disable RTS/CTS sio.disable.hs
SEQ
--}}}
Reg.Setup.A[2] := sio.clear.hs.1 Reg.Setup.A[3] := sio.clear.hs.2
--{{{ set baud rates sio.baud.1200
SEQ
1-P
Reg.Setup.A[1] := set.baud.1200(0] Reg.Setup.A(4] := set.baud.1200(11
sio.baud.2400 SEQ Reg.Setup.A[1 J := set.baud.2400[0] Reg.Setup.A[4] := set.baud.2400[1 J
sio.baud.4800 SEQ Reg.Setup.A[1 J := set.baud.4800[0] Reg.Setup.A[4] := set.baud.4800[11
sio.baud.9600 SEQ Reg.Setup.A[1] := set.baud.9600(01 Reg.Setup.A[4] := set.baud.9600[1 J
sio.baud.19.2K SEQ Reg.Setup.A[1] := set.baud.19.2K[OJ Reg.Setup.A[4) := set.baud.19.2K[1]
sio.baud.28.8K SEQ Reg.Setup.A[1] := set.baud.28.8K[O] Reg.Setup.A[4] := set.baud.28.8K[1]
sio.baud.57 .6K SEQ Reg.Setup.A[1] := set.baud.57 .6K[O] Reg.Setup.A[4) := set.baud.57 .6K[1 J
sio.baud.115.2K SEQ
--}}}
Reg.Setup.A[1] := set.baud.115.2K[OJ Reg.Setup.A(4] := set.baud.115.2K[1]
--{{{ unknown ELSE
SKIP --}}}
SetupAReg (Reg.Setup.A)
l-l-8
--}}} --{{{ chan B command sio.cmd.B BYTEcmd: SEO in? cmd CASE (cmd) --{{{ enable RTS/CTS sio.enable.hs
--}}}
SEO Reg.Setup.B[2] := sio.set.hs.1 Reg.Setup.B[3] := sio.set.hs.2
--{{{ disable RTS/CTS sio.disable.hs
SEO
--}}}
Reg.Setup.B[2] := sio.clear.hs.1 Reg.Setup.B[3] := sio.clear.hs.2
--{{{ set baud rates sio.baud.1200
SEQ Reg.Setup.B[1] := set.baud.1200[0] Reg.Setup.B[4] := set.baud.1200[1]
sio.baud.2400 SEO Reg.Setup.B[1] := set.baud.2400[0] Reg.Setup.B[4] := set.baud.2400[1]
sio.baud.4800 SEQ Reg.Setup.B[1] := set.baud.4800[01 Reg.Setup.B[4) := set.baud.4800[1 J
sio.baud.9600 SEQ Reg.Setup.B[1] := set.baud.9600[01 Reg.Setup.B[4) := set.baud.9600[1]
sio.baud.19.2K SEQ
1~9
Reg.Setup.8[1] := set.baud.19.2K[O] Reg.Setup.8[4] := set.baud.19.2K[1]
sio.baud.28.BK SEQ Reg.Setup.8[1] := set.baud.28.BK[O] Reg.Setup.8[4] := set.baud.28.8K[1]
sio.baud.57.6K SEQ Reg.Setup.8[1] := set.baud.57 .6K[O] Reg.Setup.8[4] := set.baud.57 .6K[1]
sio.baud.115.2K SEQ Reg.Setup.8[1] := set.baud.115.2K[O] Reg.Setup.B[4] := set.baud.115.2K[1]
--}}} --{{{ unknown ELSE
SKIP --}}}
SetupBReg (Reg.Setup.B)
--}}} --{{{ set ACR sio.set.ACR
BYTE char : SEQ in? char aux.control.reg := (INT char)
--}}} --{{{ set MROA sio.set.MROA BYTE char: SEQ in? char command.reg.A := #BO mode.reg.A := (INT char)
--}}} --{{{ set CSRA
-- reset pointer to MROA -- write mode register value
150
--}}}
--}}}
sio.set.CSRA BYTE char: SEQ in? char clock.sel.reg.A := (INT char)
--}}} --{{{ set CSRB sio.set.CSRB BYTE char: SEO in? char clock.sel.reg.B := (INT char)
--}}} --{{{ set CTR sio.set.CTR
BYTE lower, upper: INT result: SEQ in? lower count.time.lo := (INT lower) -- load lower eight bits or timer in? upper count.time.hi := (INT upper) -- load upper eight bits of timer result := start.counter -- must be read to start timer
--}}} --{{{ unknown ELSE SKIP
--}}}
151
152
Forma de compilarlo:
Compilar el archivo en occam: Ejecutar los siguientes comandos desde el prompt
de DOS:
oc driver.occ /t225
Ligar el archivo compilado driver.tea con sus librerías
ilink driver.tea /f occama.lnk /t225
Ligar el archivo compilado driver.tea con sus librerías
D.1.5 FORMA DE EJECUTAR EL PROGRAMA:
Una vez que se tienen compilados y ligados los archivos necesarios, se debe
crear el archivo booteable . Como el archivo de configuración Conf. pgm está
hecho en occam, los siguientes pasos corresponden a la creación normal de un
archivo booteable en occam, sólo se agrega la opción "/y" para poder hacer uso
de las las funciones para el uso extraordinario de enlaces:
1. Compilar el archivo de configuración Conf.pgm para crer el archivo Conf.btl
occonf eonf.pgm /y
2. Crear el archivo booteable Conf.btk
ieolleet eonf .efb
3. Abrir una sesión de iserver para hacer la ejecución.
iserver /sb conf.btl /si
D.2 ESQUEMA 2. DOS PROCESOS CONTROLADORES Y UN ELEMENTO ROBOT.
153
Dentro de este esquema , la parte que tiene la capacidad de recuperarse de algún
error se encuentra en el controlador de la red, mientras que la interface entre la
red y los robots sólo retransmite y reenvía de forma adecuada los mensajes que
se intercambian entre ellos.
0.2.1 ARCHIVO DE CONFIGURACIÓN
Este archivo contiene la distribución de procesos y canales en los procesadores
además de la llamada a los mismos. Es necesario incluir sólo los procesos SIO y
Driver para poder trabajar (ver figura D.6). Como en éste caso no se usan
funciones que corresponden al uso extraordinario de enlaces, no se usaron arcos
para la definición de los canales comunicados con el driver.
Archivo de configuración : Conf. pgm
Codigo:
#INCLUDE "occonf.inc"
NODE p1 :
NODE pn: ARC hostarc :
NETWORK DO SET p1(type, memsize := "T805", 1*M)
SET pn(type, memsize := "T225", 16*K) CONNECT p1 [link][O] TO HOST WITH hostarc
CONNECT pn-1 [link][2] TO pn[link][1]
#INCLUDE "hostio.inc"
#USE "sio.lku" --unidad ligada del proceso SIO #USE "driver.lku" - driver del SI0232
-- unides ligadas del controlador
CONFIG CHAN OF SP fs, ts : [4]CHAN OF COMM aTOs, sTOa: [4]CHAN OF COMM bTOs, sTOb:
respaldo
--de controlador a sic , de sic a controlador --de controlador de respaldo a sic , de sic a controlador de
-- canales entre procesos del controlador
CHAN OF ANY sTOd,dTOs: --de sic a driver y de driver a sic
-- definicion de ejecucion de procesos
PAR PROCESOR controlador Callc.proc(sTOa[O],aTOs[O] ... )
PROCESOR controladorBack Callc.pbck (sTOb[O],bTOs[O] ... )
PROCESOR Sio.A.p Siofeed(aTOs[O], sTOa[O], bTOs[O], sTOb[O],dTOs,sTOd)
PROCESOR SI0232.Driver SI0232.driver(sTOd ,dTOs)
15-l-
T1 510 232
I -------------- .... atas
.,. -------, fs \ 1
1 1 1 1 1 1 CONTROLADOR SIOFEED.A.P ts 1 . -, 1 1 1 1 1
~ stoa 1 1 1 1 1
1 '--------------1 1 1 I , ______________ .,
dts i std
T2 ,- - - - - - - - - - - - ' 1 1
1
: 510232.DRIVER 1
-------------- ..... 1 I \ btos 1 1 1 1
\ _____________ ., 1 CONTROLADOR 1 1 1 1
Back 1 . 1 1 stob 1 1 1 1 1 I '--------------""
Figura D.6. Distribución de procesos y canales según el archivo de configuración
D.2.2 PROCESO CONTROLADOR
Descripción
155
Es un conjunto de procesos que se encargan de distribuir y mandar ejecutar el
plan de trabajo y de llevar a cabo el esquema de tolerancia a fallas, en el trabajo
(de laura**) se hace una descripción más detallada del mismo. En éste trabajo se
hace énfasis en que también se encarga de enviar comandos al robot por medio
del proceso inteface SIO cuando se está funcionando de forma normal (sin error).
Para una mayor referencia a su funcionamiento ve la seccion (**) y el trabajo (**)
D.2.3 PROCESO CONTROLADOR BACK
Descripción
Es un conjunto de procesos los cuales pueden entrar en sustitución de algún
proceso o procesadores que se encuentren en estado de error. Lo anterior es
posible gracias al esquema de tolerancia que maneja el controlador principal por
medio de monitores . En éste trabajo se hace énfasis en que a partir de un error,
el controlador principal deja de enviar instrucciones al proceso interface SIO y
156
entra en funcionamiento dicho respaldo, el proceso SIO debe estar preparado
para recibir comandos del controlador.. Para una mayor referencia a su
funcionamiento ve la seccion () y el trabajo ()
0.2.4 PROCESO 510
Programa en Occam: Sio.occ
Nodo en el archivo de configuración: Sio.A.p
Descripción
Proceso que realiza la comunicación entre el driver y el controlador , y se
encuenrta alojado en el transputer de la interfaz SIO. Lee los comandos que le
envía ya sea el controlador principal o el controlador de respaldo , le agrega las
etiquetas adecuadas y los retransmite al proceso driver RS232. De esta forma ,
cuando falla el controlador principal, el de respaldo cuenta con un canal de
comunicación para seguir enviando comandos al SIO.
Flujo
tONTROLADORi
B ,- -
B -
1 ,. :• atos ? M_ensaj_:
... Mensai'e • SI ~ornando ?
NO'
Mensaje= Fin?
NO
SI I
SIO
- .._ FIN
- y - -Slod I Petic_ion
1
- _l'_ dtos? resol!
'!'
GONTROLADOR, Back
ROBOT
! - T
' - ..,: SIOORIVER !
í stoa-1 ACK . ~ONTROLAOORI
,.
"-.. btos 1 MensaJe . . - · - - -
_,. A
Figura D.7a. Proceso de 510 que recibe y envía comandos del controlador principal al DRIVER
Stod ' Peticion
dtos ? result
NO
stob' ACK
SIO DRIVER
---.. ~ONTROLADOR Back
157
Figura D. 7b. Proceso de 510 que recibe y envía comandos del controlador de respaldo al DRIVER
Código:
PROTOCOL COMM IS ANY: PROC sio (CHAN OF COMM input,output.back.in,back.out)
VAL BYTE ack IS 1 (BYTE): VAL BYTE next IS 2 (BYTE) : VAL BYTE end IS 3 (BYTE) : VAL BYTE data IS 4 (BYTE) : VAL BYTE command IS 5 (BYTE) :
-- etiquetas para los comandos del robot
VAL BYTE c.move VAL BYTE c.rigth VAL BYTE c.left VAL BYTE e.stop
IS 1 (BYTE): IS 2 (BYTE):
IS 3 (BYTE): IS 4 (BYTE) :
PROC wait (VAL INT num.ticks) --VAL TicksPerSecond IS 15625: VAL TicksPerSecond IS 7000: TIMER clock :
INT time: SEQ clock? time time := time PLUS (num.ticks * TicksPerSecond) clock ? AFTER time
BYTE tag: BOOL ready: BOOL original: BYTE n: BYTE label: BYTE comando: [20]BYTE O.Orden: [20]BYTE O.Etiqueta: INT Total.Ordenes: INTi: SEQ Total.Ordenes:= O ready:= TRUE original:= TRUE
WHILE ready SEQ ALT original & input? tag
SEQ CASEtag ack SEQ input ? label wait (1) output ! ack output ! label
next SEQ wait (1) output ! next
end SEQ --wait (1) --output ! end --ready:= FALSE
data SEQ input? n
158
input ? label wait (1) output ! ack output ! label
command SEQ input ? comando input ? label --0.0rden[Total.Ordenes] := comando --0.Etiqueta[Total.Ordenes] := label wait (4) output ! ack output ! label
ELSE SEQ output ! end
back.in ? tag SEQ original:= FALSE CASE tag ack SEQ back.in ? label wait (1) back.out ! ack back.out ! label
next SEQ wait (1) back.out ! next
end SEQ --wait (1) --output ! end ready:= FALSE
data SEQ back.in? n back.in ? label wait (1) back.out ! ack back.out ! label
command SEQ back.in ? comando
159
back.in ? label --0.0rden[Total.Ordenes] := comando --0.Etiqueta[Total.Ordenes] := label wait (4) back.out ! ack back.out ! label
ELSE SEQ back.out ! end
PROTOCOL COMM IS ANY: PROC sio (CHAN OF COMM input,output,back.in,back.out)
VAL BYTE ack IS 1 (BYTE) : VAL BYTE next IS 2 (BYTE) : VAL BYTE end IS 3 (BYTE) : VAL BYTE data IS 4 (BYTE) : VAL BYTE command IS 5 (BYTE) :
-- etiquetas para los comandos del robot
IS 1 (BYTE): VAL BYTE c.move VAL BYTE c.rigth VAL BYTE c.left VAL BYTE e.stop
IS 2 (BYTE): IS 3 (BYTE): IS 4 (BYTE):
PROC wait (VAL INT num.ticks) --VAL TicksPerSecond IS 15625: VAL TicksPerSecond IS 7000: TIMER clock : INT time : SEQ clock? time time := time PLUS (num.ticks * TicksPerSecond) clock ? AFTER time
BYTE tag: BOOL ready: BOOL original: BYTE n: BYTE label: BYTE comando: [20]BYTE O.Orden: [20]BYTE O.Etiqueta: INT Total.Ordenes:
1 (¡()
INTi: SEQ Total.Ordenes:= O ready:= TRUE original:= TRUE
WHILE ready SEQ ALT original & input? tag SEQ CASEtag
ack SEQ input ? label wait (1) output ! ack output ! label
next SEQ wait (1) output ! next
end SEQ --wait(1) --output ! end --ready:= FALSE
data SEQ input? n input ? label wait (1) output ! ack output ! label
command SEQ input ? comando input ? label --0.0rden[Total.Ordenes] := comando --0.Etiqueta[Total.Ordenes] := label wait (4) output ! ack output ! label
ELSE SEQ
161
output ! end back.in? tag
SEQ original:= FALSE CASE tag ack SEQ back.in ? label wait (1) back.out ! ack back.out ! label
next SEQ wait (1) back.out ! next
end SEQ --wait (1) --output ! end ready:= FALSE
data SEQ back.in? n back.in ? label wait (1) back.out ! ack back.out ! label
command SEQ back.in ? comando back.in? label --0.0rden[Total.Ordenes] := comando --0.Etiqueta[Total.Ordenes] := label wait (4) back.out ! ack back.out ! label
ELSE SEQ back.out ! end
-- ready := TRUE -- i:=O -- WHILE ready
SEQ ALT
162
input? tag CASEtag end
SEQ ready:= FALSE wait (1) output ! end
ready & SKIP SEQ wait(2) output ! ack output ! O.Etiqueta[i] i:=i+1 IF i >= Total.Ordenes
i:=O TRUE
SKIP
Forma de compilarlo:
Crear un archivo siofeed. lnk para hacer una unidad ligada:
Siofeed1 .tco
convert.lib hostio.lib
occamutl.lib occam8.lib virtual.lib
Compilar y ligar el archivo en occam:
Ejecutar los siguientes comandos desde el prompt de DOS:
oc siofeed1 .occ /t225
163
16-+
ilink /f siofeed.lnk /t225
Con lo anterior se ha creado el archivo siofeed1 .lku, que es el que se va a ligar
desde el archivo de configuración.
D.2.5 FORMA DE EJECUTAR EL PROGRAMA:
Una vez que se tienen compilados y ligados los archivos necesarios, se debe
crear el archivo booteable . Como el archivo de configuración Conf.pgm está
hecho en occam, los siguientes pasos corresponden a la creación normal de un
archivo booteable en occam, sólo se agrega la opción "/y" para poder hacer uso
de las las funciones para el uso extraordinario de enlaces:
1. Compilar el archivo de configuración Conf.pgm para crear el archivo Conf.btl
occonf conf.pgm
2. Crear el archivo booteable Conf.btk
icollect conf.cfb
3. Abrir una sesión de iserver para hacer la ejecución.
iserver /sb conf.btl /si
APENDICE E. DOCUMENTACIÓN PROBLEMAS 510442
16:i
En este APENDICE se incluyen todos los correos que fueron enviados y recibidos
al fabricante, así como algunos URL y datos personales de los ingenieros de
Transtech que estuvieron involucrados en el soporte. El fabricante se encuentra
en Estados Unidos de Norteamérica y la empresa se llama Transtech.
Tienen página de Internet y el URL es:
http://www.transtech.com.
http://www. transtech-dsp. com
Las personas involucradas en este problema por parte de Transtech son:
Jeff Bateman
20 Thornwood Dirve, lthaca,
NewYork 14850-1263, USA
Voice 607 2578678 Ext. 22
Fax 607 2578679
email: [email protected]
email: [email protected]
Rod Jensen
email: [email protected]
email: [email protected]
A continuación se listan todos los correos.
Subject: Problem with sio422
Date: Mon, 21 Sep 1998 10:57:26 -0500
From:emorales <[email protected]>
Helio Jeff:
16(i
Once again is me ( Edgar Morales From México, City), hope you remember me. 1
am the student working with the transputers at the University UNAM. 1 have sorne
problems with the SI0422.
I have not had problems with the SI0232 and it's driver (DRIVER.OCC), this is the
version that you sent me about 6 months ago. Now l'm working with the SI0422
using the same program (DRIVER.OCC) but I can't make it work out. The SIO's
transputer is OK because I can load other occam programs on it, so
I tried to debug the driver.occ code:
In the following procedure there is a writing operation over a register, it can't be
executed and the program remains in hold
PROC ResetUart ()
-- Reset DUART, toggle reset bit
INT result:
INT should.be :
SEO
Csr := CpuRst
result := Csr.readback /\ #F
should.be := CpuRst /\ #F
--{{{ check result
IF
result <> should.be
CAUSEERROR()
TRUE
SKIP
--}}}
Csr := O
output.conf.reg := O -- initialize so OP2 & OP3 can be
toggled
*********************** (this couldn't be done)
167
this line correponds to a writing operation over Uart.write[13) which was placed in
memory with the following lines
[16)1NT Uart.write :
PLACE Uart.write AT (#?COO >< (MOSTNEG INT)) >> 1 :
I commented this line (output.conf.reg := O) but happened the same with the
following procedure:
168
SetupAReg (Reg.Setup.A)
because it tries again a writing operation:
aux.control.reg := Reg.Base[O] --A and B are same value
which has the following mapping:
[16]1NT Uart.write:
PLACE Uart.write AT (#7COO >< (MOSTNEG INT)) >> 1 :
So, 1 can't write in any register, Is the PLACE operation wrong? should I use a
diferent driver program (l'm using the one that already worked with the 810232)
hope you can help me out
Subject: RE: [Fwd: Problem with sio422]
Date: Tue, 22 Sep 1998 14:37:13 -0400
From: Andys <[email protected]>
To: "'[email protected]"' <[email protected]>
CC: 'jb' <[email protected]>
Hi Edgar,
Rod Jensen left Transtech this past spring. Until we hire a replacement, l'm
looking after his sales area. 1 did speak with our systems engineer, and he has
taken a quick look at yourcode.
169
As things worked satisfactorily with the 810232, and not with the 810422, we are
wondering about whether you might have a cabling issue. lt is our understanding
that the driver software used to program the 810232 and 810422 are one and the
same.
Let us know how you make out, and please communicate with us if you still are
encountering difficulties.
Regards,
Andy 8tevens
Subject: Re: [Fwd: Problem with sio422]
Date: Tue, 22 Sep 1998 18:45:44 -0500
From: emorales <[email protected]>
To: Andys <[email protected]>
CC: jb' <[email protected]>
References: 1
Andy:
it is not a cabling issue because the problem is coming from the driver software, as
I told you befare, the program holds when it reaches a writing command over any
register (those named Uart.write) and can not reset the UART:
the specific procedure is:
--}}}
--{{{ ResetUart ()
PROC ResetUart ()
-- Reset DUART, toggle reset bit
INT result:
INT should.be:
SEO
Csr := CpuRst
result := Csr.readback /\ #F
should.be := CpuRst /\ #F
--{{{ check result
/F
result <> should.be
CAUSEERROR()
TRUE
SKIP
--}}}
Csr := O
output.conf.reg := O -- this is the specific line
170
if I can't write in these registers I won't be able to send anything over the SIO, 1
don't know if it is a jumper problem, or if the memory mapping (for writing and
reading registers) is different from 510232 to 510422. Is there any chance that it
was a hardware problem or something like this ? .
Can you let me know how can I build a loop for further testings in 510422 ? ( 1
don't know if it is Rx+ with Tx+ or Rx+ with Rx- )
regards,
Subject:RE: [Fwd: Problem with sio422]
Date:Wed, 23 Sep 1998 13:00:46 -0400
From: Jeff Bateman <[email protected]>
Organization:Transtech DSP
To: "'[email protected]"' <[email protected]>,
Andys <[email protected]>
Dear Edgar,
171
l'm sorry to hear you are having trouble with the SI0422 board driver. 1 did receive
the email you sent to me today, and the one you sent Andy. As far as I can tell ,
there should be no difference at the driver level between the SI0232 and SI0422.
You need a jumper on JP1 between pins 1 & 2. This is the default; it selects a
clock source far the DUART from the on-board oscillator.
Loop back connector: you need to connect Tx to Rx. lf handshaking is used, also
connect RTS to CTS. So, to loop back a port to itself connect as follows:
1 Tx- --> Rx- 3
2 Tx+ --> Rx+ 4
6 RTS- --> CTS- 8
7 RTS+ --> CTS+ 9
You can easily do this with tour jumpers.
Similar connections can be used far linking the two ports.
Subject: Re: [Fwd: Problem with sio422]
Date: Wed, 23 Sep 199815:11:18 -0500
From: emorales <[email protected]>
To: Jeff Bateman <[email protected]>
References: 1
Hi Jeff:
17.?
l've been using the default jumper configuration , besides the jumper configuration,
what else do you think it migth be the problem if l'm using the same software?,
hardware (at register level) could be failing?.
Subject:RE: [Fwd: Problem with sio422]
Date: Thu, 24 Sep 1998 21:41:07 -0400
From: Jeff Bateman <[email protected]>
To: "'[email protected]"' <[email protected]>
CC: "Andy Stevens (E-mail)" <[email protected]>
Hi again Edgar,
Sorry it still doesn't work. 1'11 check further with someone who knows a little more
about the SI0-232 and SI0-422 differences, to see if there's any simple
explanation. Right now l'm on the road, so I can't promise to have any information
until next week.
Subject: RE: [Fwd: Problem with sio422]
Date: Tue, 29 Sep 1998 14:26:25 -0400
From: Jeff Bateman <[email protected]>
Organization: Transtech DSP
To: "'[email protected]"' <[email protected]>
173
CC: "Andy Stevens (E-mail)" <[email protected]>
Dear Edgar,
I have checked further on whether there could be any driver incompatibilities
between the SI0-232 and SI0-422. There are none known: the two products are
identical in all respects other than the logic levels used far the 1/0 signals. Of
course you need different cables far the two boards, but even if there were cable
problems the ResetUart() function would not be affected.
lt looks like there are only two possibilities now:
1) The memory map far output.conf.reg is wrong - an access to the wrong location
might cause a lock-up. lf you are using exactly the same files for both board types,
this possibility is eliminated - could you double check?.
2) The hardware is faulty. Far fastest turn-around, you can send the board back to
our associated office in California:
FAO Rodney Taylor
Transtech DSP
3338 Bryan Avenue
Simi Valley
CA 93063
USA
Please contact Jean here in lthaca far a Return Materials Authorization (RMA)
number prior to returning the board.
APENDICE F. ENCENDIDO, APAGADO Y COMANDOS BASICOS DEL ROBOT PUMA
17-1-
Para encender, apagar y calibrar el robot es necesario llevar acabo los siguientes
pasos
ENCENDIDO.
1. Checar que el botón rojo (PANIC BUTTON) del teach, se encuentre liberado.
EN el caso de no ser así, se asegurará girando el botón en el sentido de las
manecillas del reloj.
2.Prender el switch del controlador (POWER ON) colocandolo hacia arriba, en el
momento en que se haga se encenderá el foco localizado en la parte superior del
switch.
En la pantalla aparecerá la siguiente pregunta:
Load VAL - 11 from floppy (Y/N? N ENTER
Siempre se debe contestar "N", ya que VAL II se encuentra residente en la
memoria del controlador y se da ENTER.
17:i
A continuación aparece otro desplegado, seguido de la pregunta si se desea
inicializar, siempre se debe contestar con "N", ya que de lo contrario se
borrará el contenido de la memoria.
lnitialize (Y/N)? N ENTER.
3.Se procede a cambiar de HAL Ta RUN, la palanca negra del controlador.
4.A continuación se oprime el botón ARM POWER ON, en le momento se
encenderá un foco localizado arriba del mismo.
5.Después se escribe
.cal ENTER
Are you sure (Y/N)? Y ENTER
.do ready ENTER
.cal ENTER
Are you sure (Y/N)? Y ENTER
.do ready ENTER
Se repitirá las veces que sea necesario hasta que las marcas coincidan, para
asegurarse de que estén bien calibrados.
APAGADO.
Primero se debe llevar a una posición cercana a READY
1.Se debe estar en modo COMP del Teach.
2.Se debe escribir en la pantalla
.do ready ENTER
176
3. Se oprime el botón ARM POWER OFF.
4.La palanca negra se coloca nuevamente en HAL T.
5.Luego se baja el switch POWER ON.
