Está en la página 1de 108

IMPLEMENTACION DE UNA RED MODBUS/TCP

ANDRES FELIPE RUIZ OLAYA

UNIVERSIDAD DEL VALLE

FACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA

PROGRAMA DE INGENIERÍA ELECTRÓNICA

SANTIAGO DE CALI

2002
IMPLEMENTACION DE UNA RED MODBUS/TCP

ANDRES FELIPE RUIZ OLAYA

Trabajo de grado para optar por el título de

INGENIERO ELECTRÓNICO

Directores

Ing. ASFUR BARANDICA LOPEZ

Ing. FABIO GERMAN GUERRERO, M. Sc.

UNIVERSIDAD DEL VALLE

FACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA

PROGRAMA DE INGENIERÍA ELECTRÓNICA

SANTIAGO DE CALI

2002
RESUMEN

En este proyecto se desarrolla e implementa una red de instrumentación y

control industrial con conectividad TCP/IP (como por ejemplo Internet), capaz

de ser supervisada y controlada remotamente a través del protocolo

Modbus/TCP usando el sistema embebido TINI de Dallas Semiconductor.

Además se desarrolla una interfaz de usuario gráfica para acceso desde

Internet vía Web .


Nota de Aprobación

El trabajo de grado titulado “IMPLEMENTACIÓN DE UNA RED

MODBUS/TCP”, presentado por el estudiante ANDRES FELIPE RUIZ OLAYA,

para optar al título de Ingeniero Electrónico fue revisado por el jurado y

calificado como:

Aprobado.

Ing. ASFUR BARANDICA LOPEZ


Director

Ing. FABIO GERMAN GUERRERO


Director

Ing. EDINSON FRANCO


Jurado

Ing. CARLOS RAFAEL PINEDO


Jurado
AGRADECIMIENTOS

El autor expresa sus agradecimientos a:

Los directores de tesis: Ing. Asfur Barandica e Ing. Fabio German Guerrero por

su grandísima colaboración en esta etapa final de la carrera y porque de ellos

aprendí mucho.

A todas aquellas personas que me acompañaron a lo largo de la carrera y en la

culminación de este trabajo de grado.

A mis compañeros, profesores y en general a la comunidad universitaria de

Univalle por la experiencia vivida en esta institución.


CONTENIDO

Pag.

0. INTRODUCCIÓN 1

1. EL PROTOCOLO MODBUS/TCP 8

1.1 DESCRIPCIÓN 8

1.1.1 Orientado a conexión 9

1.1.2 Codificación de datos 11

1.1.3 Interpretación del modelo de datos 11

1.1.4 Filosofía de longitud implicada 12

1.2 VENTAJAS DEL PROTOCOLO MODBUS/TCP 13

1.3 ESTRUCTURA DEL PROTOCOLO 14

1.4 ESQUEMA DE ENCAPSULACION 17

1.5 CONFORMACION DE CLASES 17

1.5.1 Comandos Clase 0 18

1.5.2 Comandos Clase 1 18

1.5.3 Comandos Clase 2 19

1.5.4 Comandos específicos de la máquina/red/vendedor 20

1.6 DESEMPEÑO REQUERIDO Y ESPERADO 21

1.7 GUIA DE IMPLEMENTACION DEL CLIENTE Y SERVIDOR 22

1.7.1 Diseño del Cliente 22

1.7.2 Diseño del Servidor 24


2. DESCRIPCION DEL HARDWARE 27

2.1 LA TARJETA TINI 27

2.1.1 Descripción 28

2.1.2 Características 28

2.1.3 Aplicaciones 29

2.1.4 Hardware de la TINI 31

2.1.5 Mapa de memoria del sistema 34

2.1.6 Sistema I/O integrado 36

2.1.7 Software de la TINI 37

2.1.8 Sistema operativo de la TINI 39

2.1.9 El Socket E10 40

2.2 LA TARJETA CPU08 41

2.2.1 Diagrama de bloques 42

2.2.2 Características 42

2.2.3 Programación de la CPU08 43

2.3 EL PLC DL05 DE KOYO 44

2.3.1 Diagrama de bloques 44

2.3.2 Características 45

2.3.3 Modos de operación 45

2.3.4 Mapa de memoria 46

2.3.5 Comunicación 47

2.3.6 Programación 49

2.4 CONTROLADORES 452 PLUS 49

2.4.1 Definición de caracteres especiales 50

2.4.2 Protocolo de Comunicación 50


2.4.2.1 Nivel 1 – El “Wrapping” 51

2.4.2.2 Nivel 2 – Contenido del mensaje 51

2.4.3 Contenido de posiciones análogas del controlador 452 Plus 52

3. DESCRIPCIÓN DEL SOFTWARE 53

3.1 DESARROLLO DE UN SERVIDOR MODBUS/TCP 54

3.1.1 Estructura de Clases 55

3.1.2 Descripción de las Clases 56

3.1.3 Ejemplo de código fuente 59

3.2 DESARROLLO DE UN SERVIDOR WEB 63

3.3 DESARROLLO DE UNA INTERFAZ PARA ACCESO WEB 66

3.3.1 El applet como un cliente Modbus/TCP 67

3.3.2 Sistema de acceso 70

3.3.3 Panel de Control 71

3.4 IMPLEMENTACIÓN DE UN ESCLAVO MODBUS EN LA CPU08 73

3.4.1 Algoritmo de la aplicación para la CPU08 74

3.4.2 La UART implementada por software 79

3.5 LA CPU08 MAESTRO DE UNA RED DE CONTROLADORES 80

3.5.1 Respuestas del controlador 452 Plus a solicitudes 81

3.5.2 Ejemplos de mensajes de lectura y escritura 83

3.6 CONFIGURACION DEL PLC DL05 COMO ESCLAVO MODBUS 84

3.7 CONFIGURACION DE LOS CONTROLADORES 452 PLUS 86

3.7.1 Conexiones físicas 88

4. CONCLUSIONES 89

BIBLIOGRAFÍA 93

ANEXO 95
LISTA DE TABLAS

Pag.

Tabla 1.1 Estructura del prefijo de Modbus/TCP 15

Tabla 1.2 Estructura de mensajes en Modbus/TCP 16

Tabla 1.3 Comandos de la Clase 0 18

Tabla 1.4 Comandos de la Clase 1 19

Tabla 1.5 Comandos Clase 2 19

Tabla 1.6 Funciones dependientes de la máquina 20

Tabla 2.1 Modos de operación del PLC DL05 46

Tabla 2.2 Tipos de memoria del PLC DL05 47

Tabla 2.3 Características del puerto 1 del PLC DL05 48

Tabla 2.4 Características del puerto 2 del PLC DL05 48

Tabla 2.5 Caracteres especiales ASCII del controlador 50

Tabla 2.6 Tipos de mensaje del controlador 452 Plus 52

Tabla 2.7 Posiciones de memoria del controlador 452 Plus 52

Tabla 3.1 Pines utilizados por la tarjeta CPU08 77

Tabla 3.2 Caracteres de error del controlador 452 Plus 81

Tabla 3.3 Ejemplo de trama de lectura del controlador 452 Plus 83

Tabla 3.4 Ejemplo de trama de escritura del controlador 452 Plus 84

Tabla 3.5 Variables de configuración del PLC DL05 84

Tabla 3.6 Funciones MODBUS soportadas por el PLC DL05 86

Tabla 3.7 Configuración de los controladores 452 Plus 87

Tabla 3.8 Interfaz serial del controlador 452 Plus 88


LISTA DE FIGURAS

Pag.

Figura 1.1. Diagrama de la red implementada 4

Figura 1.2 Esquema de encapsulación en Modbus/TCP 17

Figura 2.1 La TINI como un conversor de protocolos 31

Figura 2.2 Esquema del hardware de la TINI 32

Figura 2.3 Mapa de memoria de la TINI 34

Figura 2.4 Esquema del software de la TINI 38

Figura 2.5 Diagrama de bloques de la CPU08 42

Figura 2.6 Diagrama de bloques del PLC DL05 44

Figura 3.1 Modelo cliente / servidor 54

Figura 3.2 Estructura de clases 55

Figura 3.3 Estructura de la interface de transporte 56

Figura 3.3 Programa en Java de un servidor Modbus/TCP 60

Figura 3.4 Ejemplo de código para un servidor Web 64

Figura 3.5 Archivo HTML que carga la applet en un navegador Web 65

Figura 3.6 Código en Java para un cliente Modbus/TCP 69

Figura 3.7 Interfaz del Sistema de Acceso 71

Figura 3.8 Vista del panel de control 72

Figura 3.9 Algoritmo para el programa de la CPU08 75

Figura 3.10 Lectura de bits en la UART implementada 80

Figura 3.11 Configuración del puerto 2 en DirectSOFT 85


UNIVERSIDAD DEL VALLE

FACULTAD DE INGENIERÍA

Programa académico de pregrado de

INGENIERÍA ELECTRÓNICA

Título: Implementación de una red Modbus/TCP

Autor: Andrés Felipe Ruíz Olaya

Directores: Ing. Fabio Germán Guerrero, M. Sc.

Ing. Asfur Barandica López

Grupo de investigación: Percepción y Sistemas Inteligentes.

Area de investigación: Comunicaciones Industriales.

Descriptores: Modbus, Modbus/TCP, Ethernet, TCP/IP, Java, Interfaz Web,

Instrumentación, comunicaciones.
1

0. INTRODUCCION

En el área de las comunicaciones en entornos industriales, la estandarización de

protocolos es un tema en permanente discusión, donde intervienen problemas

técnicos y comerciales. Cada protocolo está optimizado para diferentes niveles de

automatización y en consecuencia responden al interés de diferentes proveedores.

Por ejemplo Fieldbus Foundation, Profibus y HART, están diseñados para

instrumentación de control de procesos. En cambio DeviceNet y SDC están

optimizados para los mercados de los dispositivos discretos (on-off) de detectores,

actuadores e interruptores, donde el tiempo de respuesta y repetibilidad son

factores críticos1.

Cada protocolo tiene un rango de aplicación; fuera del mismo disminuye el

rendimiento y aumenta la relación costo/prestación.

1
Tomado de “Comunicaciones en entornos industriales”, por Mario Distéfano. Visitar la dirección
http://fing.uncu.edu.ar/investigacion/institutos/IAEI/Cursos2.htm
2

Debido a la no aceptación de un protocolo estándar único en las comunicaciones

industriales, los múltiples buses de campo han perdido terreno ante la incursión de

tecnologías de comunicación emergentes como Ethernet en este área.

La aceptación mundial de Ethernet en los entornos administrativos y de oficina ha

generado el deseo de expandir su aplicación a la planta. Ethernet se está

moviendo rápidamente hacia el mercado de los sistemas de control de procesos y

la automatización, para la interconexión a nivel de campo de sensores y

actuadores, de esta forma reemplazando a los buses de campo en las industrias.

Es posible que con los avances de Ethernet y la tecnología emergente Fast

Ethernet se pueda aplicar también al manejo de aplicaciones críticas de control2.

Los buses de campo son una forma especial de LAN dedicada a aplicaciones de

adquisición de datos y comando de elementos finales de control sobre la planta.

Los buses de campo típicamente operan sobre cables de par trenzado de bajo

costo. A diferencia de Ethernet, donde no se puede garantizar determinismo sobre

la llegada de paquetes, los diseñadores optimizan los buses de campo para el

intercambio de mensajes cortos de comando y de control con altísima seguridad y

temporización estricta.

2
Tomado de “Moving Ethernet to plant floors”, por Sam Malizia. Visitar la dirección
http://www.isa.org/journals/ic/feature/1,1162,541,00.html
3

En las aplicaciones industriales, Ethernet es usado en conjunto con la pila de

protocolos TCP/IP universalmente aceptada. TCP/IP es el conjunto de protocolos

usado en Internet, suministrando un mecanismo de transporte de datos confiable

entre máquinas y permitiendo interoperabilidad entre diversas plataformas. Usar

TCP/IP sobre Ethernet a nivel de campo en la industria permite tener una

verdadera integración con la Intranet corporativa, y de esta forma se ejerce un

estricto control sobre la producción3.

En este proyecto se pretende utilizar un estándar de instrumentación sobre

Ethernet, Modbus/TCP4, para realizar la implementación de una red de control

industrial capaz de ser accedida a través de lnternet ó la Intranet local, usando los

protocolos TCP/IP. El protocolo Modbus/TCP es muy difundido por ser abierto, lo

cual le permite la comunicación con gran diversidad de elementos industriales; es

por eso que es de gran importancia trabajar sobre él, y además debido a que en

nuestro medio no se encuentran desarrollos concernientes a este tema.

Arquitectura de la solución

El siguiente diagrama ilustra la red Modbus/TCP implementada, al igual que los

enlaces y la interacción que debe existir entre los diversos elementos que

componen el sistema :

3
Tomado de http://www.modbus.org/modbus_tcp_new.htm
4
El protocolo Modbus/TCP fue introducido por Schneider Automation. La especificación se
encuentra disponible en http://www.modicon.com/openmbus.
4

Figura 1.1 Diagrama de la red implementada


5

El sistema planteado se centra en torno a la tarjeta TINI5 (Tiny InterNet Interface)

la cual provee el acceso Ethernet. Esta tarjeta es programable en Java y posee un

sistema operativo propio, el cual contiene la pila de protocolos TCP/IP para el

desarrollo de aplicaciones de red.

Objetivo general

Recopilar información y adquirir el conocimiento necesario para implementar,

configurar, mantener y evaluar una red Modbus/TCP.

Objetivos específicos

• Implementar en la tarjeta TINI un servidor Modbus/TCP, el cual permita a

través de este protocolo supervisar y comandar elementos finales de control.

• Implementar en la tarjeta TINI un servidor Web, el cual permita controlar y

monitorear los elementos que conforman la red.

6
• Programar la tarjeta CPU08 , para que pueda comportarse como un esclavo

MODBUS, y a la vez como un maestro de una red RS-485 de controladores.

5
Para más información de esta tarjeta, consultar la sección 2.1.
6
Para más información de esta tarjeta, consultar la sección 2.2.
6

• Implementar un esclavo MODBUS en la tarjeta TINI.

• Desarrollar una interfaz de usuario gráfica vía Web, desde la cual sea posible

realizar operaciones remotamente de supervisión y control sobre los distintos

elementos de la red Modbus/TCP.

• Integrar y colocar en funcionamiento los distintos elementos que conforman la

red a implementar. Además debe demostrarse la interoperabilidad de la red

probándola con software de diferentes vendedores.

El presente trabajo se encuentra dividido en diversas partes que abarcan las

etapas en las cuales se desarrolló el proyecto.

En la primera parte “El protocolo Modbus/TCP”, se expone en profundidad dicho

estándar y se detalla la manera en que se lleva a cabo su implementación. Aquí

también se presentan las ventajas del protocolo y las características que

proporciona para ser usado en comunicaciones industriales sobre Ethernet.

En la segunda parte “Descripción del hardware”, se presenta en detalle las

características de cada uno de los elementos que conforman la red Modbus/TCP

implementada y el papel que desempeñan en el sistema completo. Se realiza una


7

exposición exhaustiva de la tarjeta TINI, ya que en ella reside gran parte de la

funcionalidad que proporciona la red Modbus/TCP.

En la tercera parte “Descripción del software”, se describe la forma en que se

desarrollaron los programas y aplicaciones que corren sobre los diversos

elementos de la red, además se explica la funcionalidad que brindan y la

interacción entre los diversos componentes de software.

Finalmente, en la ultima parte se exponen los resultados y conclusiones del

proyecto y el trabajo futuro para con la red implementada.


8

1. EL PROTOCOLO MODBUS/TCP7

1.1 DESCRIPCION

Modbus/TCP es un protocolo de comunicación diseñado para permitir a equipo

industrial tal como Controladores Lógicos Programables (PLCs), computadores,

motores, sensores, y otros tipos de dispositivos físicos de entrada/salida

comunicarse sobre una red. Modbus/TCP fue introducido por Schneider

Automation como una variante de la familia MODBUS ampliamente usada, los

protocolos de comunicación simples y abiertos, destinados para la supervisión y el

control de equipo de automatización. Específicamente, el protocolo cubre el uso

de mensajes MODBUS en un entorno “Intranet” o “Internet” usando los protocolos

TCP/IP8.

7
Parte de esta sección es tomado de la especificación en http://www.modicon.com/openmbus
8
Tomado de http://www.modbus.org
9

La especificación Modbus/TCP define un estándar interoperable en el campo de la

automatización industrial, el cual es simple de implementar para cualquier

dispositivo que soporta sockets9 TCP/IP.

1.1.1 Orientado a conexión.

MODBUS es un protocolo de comunicación “sin estado”, es decir, cada solicitud

del maestro es tratada independientemente por el esclavo y es considerada una

nueva solicitud no relacionada a las anteriores, de esta forma haciendo a las

transacciones de datos altamente resistentes a rupturas debido a ruido y además

requiriendo mínima información de recuperación para ser mantenida la transacción

en cualquiera de los dos terminales .

Las operaciones de programación de otro lado, esperan una comunicación

orientada a la conexión, es decir, las máquinas de origen y de destino establecen

un canal de comunicaciones antes de transferir datos. Este tipo de operaciones

son implementadas de diferentes maneras por las diversas variantes de MODBUS

(Modbus RTU, Modbus ASCII, Modbus PLUS).

9
Un socket es una abstracción proporcionada por el sistema operativo que permite a un programa
de aplicación accesar los protocolos TCP/IP.
10

Modbus/TCP maneja ambas situaciones. Una conexión es inicialmente

establecida en esta capa de protocolo (nivel de aplicación), y esa conexión única

puede llevar múltiples transacciones independientes.

En adición, TCP permite establecer un gran número de conexiones concurrentes,

de este modo el cliente (maestro) puede ya sea re-usar una conexión

previamente establecida ó crear una nueva, en el momento de realizar una

transacción de datos.

Es interesante analizar porqué el protocolo TCP orientado a la conexión es usado

en lugar del protocolo UDP10 orientado a datagramas. La principal razón es

mantener control de una transacción individual encerrándola en una conexión la

cual pueda ser identificada, supervisada, y cancelada sin requerir acción

específica de parte de las aplicaciones cliente y servidor. Esto da al mecanismo

una amplia tolerancia a cambios del desempeño de la red, y permite que

herramientas de seguridad tal como firewalls11 y proxies puedan ser fácilmente

añadidos.

10
El UDP (User Datagram Protocol) proporciona un servicio de entrega sin conexión, utilizando el
IP para transportar mensajes entre máquinas. Emplea el IP para llevar mensajes, pero agrega la
capacidad para distinguir entre varios destinos dentro de una máquina host.
11
Un firewall (muro de seguridad) se le dice a una configuración de ruteadores y redes colocados
entre la organización interna de una red y su conexión con redes externas a fin de dar seguridad.
11

1.1.2 Codificación de datos.

MODBUS usa una representación “big-endian12” para direcciones y datos. Esto

significa que cuando una cantidad numérica más grande que un byte es

transmitido, el byte más significante es enviado primero. Así, por ejemplo:

0x1234 será 0x12 0x34

1.1.3 Interpretación del modelo de datos.

MODBUS basa su modelo de datos sobre una serie de tablas las cuales tienen

características distintivas. Las cuatro principales son:

• Entradas discretas. Bit simple, suministrado por un sistema I/O, de solo lectura.

• Salidas discretas. Bit simple, alterable por un programa de aplicación, de

lectura-escritura.

• Registros de entrada. Cantidad de 16 bits, suministrado por un sistema I/O, de

solo lectura.

• Registros de salida. Cantidad de 16 bits, alterable por un programa de

aplicación, de lectura-escritura.

12
Big-endian es un formato en el cual el byte más significativo se encuentra primero.
12

La distinción entre entradas y salidas, y entre datos direccionables al bit y

direccionables a la palabra, no implica algún comportamiento de la aplicación. Es

aceptable y común, considerar las cuatro tablas sobrelapando una con otra, si esta

es la interpretación más natural sobre la máquina (esclavo MODBUS) en cuestión.

1.1.4 Filosofía de longitud implicada.

Todas las solicitudes y respuestas MODBUS están diseñadas en tal forma que el

receptor puede verificar que un mensaje está completo. Para códigos de función

donde la solicitud y respuesta son una longitud fija, el código de función solo es

suficiente. Para códigos de función llevando una cantidad variable de datos en la

solicitud ó respuesta, la porción de datos estará precedida por un campo que

representa el número de bytes que siguen.

Cuando MODBUS es llevado sobre TCP información de longitud se adiciona en el

prefijo (o encabezado) para permitir al receptor reconocer los límites del mensaje,

igual si el mensaje ha sido dividido en múltiples paquetes para la transmisión. La

existencia de reglas de longitud implícitas o explícitas, y el uso de un código de

chequeo de error CRC-3213 (sobre Ethernet) resulta en una probabilidad muy

pequeña de corrupción no detectada sobre un mensaje de solicitud o respuesta.

13
CRC (Cyclic Redundancy Code), verificación por redundancia cíclica.
13

1.2 VENTAJAS DEL PROTOCOLO MODBUS/TCP

• Es escalable en complejidad. Un dispositivo el cual tiene solo un propósito

simple necesita solo implementar uno ó dos tipos de mensaje.

• Es simple para administrar y expandir. No se requiere usar herramientas de

configuración complejas cuando se añade una nueva estación a una red

Modbus/TCP.

• No es necesario equipo o software propietario de algún vendedor. Cualquier

sistema computador ó microprocesador con una pila de protocolos TCP/IP

puede usar Modbus/TCP.

• Puede ser usado para comunicar con una gran base instalada de dispositivos

MODBUS, usando productos de conversión los cuales no requieren

configuración.

• Es de muy alto desempeño, limitado típicamente por la capacidad del sistema

operativo del computador para comunicarse. Altas ratas de transmisión son

fáciles de lograr sobre una estación única, y cualquier red puede ser construida

para lograr tiempos de respuesta garantizados en el rango de milisegundos.


14

1.3 ESTRUCTURA DEL PROTOCOLO

A continuación se describe la forma general de encapsulación de una solicitud o

respuesta MODBUS cuando es llevada sobre una red Modbus/TCP. Es importante

anotar que la estructura del cuerpo de la solicitud y respuesta, desde el código de

función hasta el fin de la porción de datos, tiene exactamente la misma disposición

y significado como en las otras variantes MODBUS, tal como:

MODBUS serial – codificación ASCII

MODBUS serial – codificación RTU

MODBUS PLUS

Las únicas diferencias en esos otros casos son la especificación de los

delimitadores inicial y final del mensaje14, el patrón de chequeo de error y la

interpretación de la dirección.

Todas las solicitudes son enviadas vía TCP sobre el puerto registrado 502. Las

solicitudes normalmente son enviadas en forma half-duplex15 sobre una conexión

dada. Es decir, no hay beneficio en enviar solicitudes adicionales sobre una única

conexión mientras una respuesta está pendiente. Sin embargo, los dispositivos

14
En MODBUS esto se denomina “Framing”.
15
En half-duplex los datos pueden viajar en cualquier dirección, pero no en forma simultánea.
15

que desean obtener altas ratas de transferencia pueden establecer múltiples

conexiones TCP al mismo destino.

El campo “dirección esclavo” de MODBUS es reemplazado por un byte

“identificador de unidad” el cual puede ser usado para comunicar a través de

dispositivos tales como puentes y gateways, los cuales usan una dirección IP

única para soportar múltiples unidades terminales independientes.

Los mensajes de solicitud y respuesta en Modbus/TCP poseen un prefijo ó

encabezado compuesto por seis bytes como se aprecia en la tabla 1.1.

Tabla 1.1 Estructura del prefijo de Modbus/TCP

ref ref 00 00 00 len

El “ref ref” anterior son los dos bytes del campo “referencia de transacción”, un

número que no tiene valor en el servidor pero son copiados literalmente desde la

solicitud a la respuesta a conveniencia del cliente. Este campo se utiliza para que

un cliente Modbus/TCP pueda establecer simultáneamente múltiples conexiones

con diferentes servidores y pueda identificar cada una de las transacciones.

El tercer y cuarto campo del prefijo representan el “identificador de protocolo”, un

número el cual debe ser establecido a cero.


16

El “len” especifica el número de bytes que siguen. La longitud es una cantidad de

dos bytes, pero el byte alto se establece a cero ya que los mensajes son más

pequeños que 256.

De esta forma, un mensaje Modbus/TCP completo posee una estructura como se

muestra en la tabla 1.2.

Tabla 1.2 Estructura de mensajes en Modbus/TCP

Posición del Byte Significado

Byte 0 Identificador de transacción. Copiado


por el servidor – normalmente 0.

Byte 1 Identificador de transacción. Copiado


por el servidor – normalmente 0.

Byte 2 Identificador de protocolo = 0.

Byte 3 Identificador de protocolo = 0.

Byte 4 Campo de longitud (byte alto) = 0.Ya


que los mensajes son menores a 256.

Byte 5 Campo de longitud (byte bajo). Número


de bytes siguientes.

Byte 6 Identificador de unidad (previamente


“dirección esclavo”).

Byte 7 Código de función MODBUS.

Byte 8 y más Los datos necesarios.


17

1.4 ESQUEMA DE ENCAPSULACION

Modbus/TCP básicamente embebe un marco MODBUS dentro de un marco TCP

en una manera simple como es mostrado en la Figura 1.2.

Figura 1.2 Esquema de encapsulación en Modbus/TCP

1.5 CONFORMACION DE CLASES

MODBUS por su naturaleza es ya implementada en muchísimos lugares, por tanto

una ruptura de las implementaciones existentes debe ser evitada.

De esta forma el conjunto de los tipos de transacción MODBUS existente ha sido

clasificado en clases, donde el nivel 0 representa funciones las cuales son

universalmente implementadas y totalmente consistentes, y el nivel 2 representa

funciones útiles pero algo dependientes del esclavo. Esas funciones del conjunto,

las cuales no son convenientes por interoperabilidad son también identificadas.


18

Debe anotarse que futuras extensiones al estándar pueden definir códigos de

función adicionales para manejar situaciones donde el estándar existente es

deficiente.

1.5.1 Comandos Clase 0.

Este es el mínimo conjunto útil de funciones, tanto para el maestro como para el

esclavo.

Tabla 1.3 Comandos de la Clase 0

Código Función

03 Leer múltiples registros holding16.

16 Escribir múltiples registros holding.

1.5.2 Comandos Clase 1.

Este es el conjunto adicional de funciones, el cual es comúnmente implementado

e interoperable. Como fue explicado antes, muchos esclavos deciden tratar

entradas, salidas, registros, y valores discretos como equivalentes.

16
En el protocolo MODBUS , “holding register” representa una cantidad de 16 bits, la cual
representa una posición interna de la memoria.
19

Tabla 1.4 Comandos de la Clase 1


Código Función
01 Leer estado de salidas discretas.
02 Leer estado de entradas discretas.
04 Leer registros de entrada.
05 Forzar una salida discreta.
06 Prefijar un registro holding único.
07 Leer estados de excepción*.
* Esta función típicamente tiene un significado diferente para cada familia de esclavos.

1.5.3 Comandos Clase 2.

Estas son las funciones de transferencia de datos necesarias para operaciones de

rutina tal como supervisión y HMI17.

Tabla 1.5 Comandos Clase 2


Código Función
15 Fijar múltiples salidas discretas.
20 Leer referencia general*.
21 Escribir referencia general*.
22 Enmascarar registro de escritura.
23 Leer/escribir registros**.
24 Leer cola FIFO***.
* Esta función será la más apropiada para manejar grandes espacios de registros y
datos, los cuales carecen de números de referencia.
** Esta función permite la entrada y salida de un rango de registros como una
transacción única. Es la forma más eficiente usando MODBUS para desempeñar un
intercambio regular de datos tal como con un módulo I/O.
*** Una función algo especializada, destinada a permitir la transferencia de datos desde
una tabla estructurada como una FIFO a un computador.

17
HMI : Human Machine Interface.
20

1.5.4 Comandos específicos de la máquina/red/vendedor

Todas de las siguientes funciones, aunque mencionadas en los manuales del

protocolo MODBUS, no son apropiadas para propósitos de interoperabilidad

porque ellas son dependientes de la máquina.

Tabla 1.6 Funciones dependientes de la máquina

Código Función
08 Pruebas de diagnóstico.
09 Programación*.
10 Completar la programación*.
11 Leer la palabra de estado del contador de eventos.
12 Leer el registro de eventos de comunicación.
13 Programación**.
14 Completar la programación**.
17 Reportar ID del esclavo.
18 Programación***.
19 Reinicializar enlace de comunicaciones***.
125 Sustitución de firmware.
126 Programación**.
127 Reportar dirección local.
* Soportada solo por controladores 484 de Modicon.
** Soportada solo por controladores 584/984 de Modicon.
*** Soportada solo por controladores 884 y Micro84de Modicon.
21

1.6 DESEMPEÑO REQUERIDO Y ESPERADO

No existe una especificación precisa acerca del tiempo de respuesta requerida

para una transacción sobre MODBUS ó Modbus/TCP.

Esto es debido a que se espera que Modbus/TCP sea usado en la más amplia

variedad posible de situaciones de comunicación, desde sistemas I/O esperando

temporización en milisegundos, a enlaces de radio de larga distancia con retardos

de varios segundos.

En general, los dispositivos tales como PLC´s responderán a solicitudes

ingresantes en un tiempo “scan18”, el cual típicamente varía entre 20 y 200 msg.

Desde la perspectiva del cliente, ese tiempo de respuesta debe ser extendido por

los retardos de transporte través de la red, a un tiempo de respuesta razonable.

Tales retardos pueden ser de milisegundos para un Ethernet conmutado, a cientos

de milisegundos para una conexión de red de área amplia (WAN).

Cualquier tiempo “timeout19” usado en un cliente debe ser más grande que el

máximo tiempo de respuesta razonable, para así evitar una excesiva congestión

en el dispositivo servidor ó en la red, lo cual puede causar errores.

18
Un tiempo scan, es el tiempo requerido para que el PLC complete sus instrucciones programadas.
19
Un timeout es un tiempo que se establece antes de que se reporte un fallo.
22

Así en la práctica, los timeouts usados en aplicaciones cliente de alto desempeño

serán probablemente algo dependientes sobre la topología de la red y el

desempeño esperado del servidor. Aplicaciones cliente las cuales no son críticas

en tiempo pueden con frecuencia dejar los valores timeout al establecido por

defecto en TCP, el cual reportará fallo en la comunicación después de varios

segundos.

Los clientes pueden cerrar y re-establecer conexiones Modbus/TCP cuando el

timeout ha expirado. Sin embargo al retransmitir una solicitud, es aconsejable

establecer el timeout un poco más grande que el anterior, para así permitir a un

servidor recuperarse de un posible error.

1.7 GUIA DE IMPLEMENTACION DEL CLIENTE Y SERVIDOR

El contenido de esta sección no será considerado obligatorio para la

implementación particular de un cliente ó servidor. Sin embargo, si son seguidas,

estas políticas facilitarán la integración cuando se implementen sistemas multi-

vendedor y gateways a equipo MODBUS ya instalado.

1.7.1 Diseño del Cliente.

Modbus/TCP está diseñado para permitir que el diseño de un cliente sea tan

simple como sea posible. El proceso básico de manejo de una transacción es

como sigue:
23

• Establecer una conexión TCP al puerto 50220 en el destino (servidor) deseado.

• Preparar una solicitud MODBUS, codificada como fue descrito antes.

• Enviar la solicitud MODBUS, incluyendo su prefijo Modbus/TCP de 6 bytes,

como un único buffer transmitido.

• Esperar que una respuesta aparezca sobre la misma conexión TCP.

Opcionalmente correr un timeout, si se desea ser avisado de problemas de

comunicación más rápido de lo que TCP normalmente reporta.

• Leer los primeros 6 bytes de la respuesta, el cual indicará la longitud real del

mensaje recibido.

• Leer los bytes restantes de la respuesta.

• Si no se espera una comunicación adicional al destino particular en el futuro

inmediato, cerrar la conexión TCP así que los recursos en el servidor puedan

ser usados, si es requerido, para servir a otros clientes. Un tiempo de un

segundo es sugerido como el período máximo para dejar una conexión abierta

en el cliente.

20
Un puerto de protocolo es una abstracción que los protocolos de transporte del TCP/IP utilizan para
distinguir entre varios destinos en una computadora host específica.
24

En el evento que expire el timeout para una respuesta, realizar un cierre unilateral

de la conexión, abrir una nueva, y re-enviar la solicitud. Esta técnica permite al

cliente control sobre la temporización de re-intentos, el cual es superior al

suministrado por defecto por TCP. También permite el uso de estrategias alternas,

tal como enviar la solicitud a una dirección IP alterna, usando una red de

comunicación totalmente independiente, en caso de fallo de un componente de la

infraestructura de la red.

1.7.1 Diseño del Servidor.

Un servidor Modbus/TCP siempre será diseñado para soportar múltiples clientes

concurrentes, sin importar que en su uso previsto solo un único cliente parezca

tener sentido. Esto permite al cliente cerrar y reabrir la conexión a fin de responder

rápidamente a la no entrega de una respuesta.

Si una pila de protocolos TCP/IP convencional es usada, considerables recursos

de memoria pueden ser ahorrados reduciendo el tamaño de los buffers de

transmisión y recepción. Un servicio TCP normal usualmente asignará 8K bytes ó

más como un buffer de recepción por conexión. Tal espacio de buffer no tiene

valor en Modbus/TCP, ya que el tamaño máximo de una solicitud ó respuesta es

menor que 300 bytes. De esta forma se liberan recursos para conexiones

adicionales.
25

Los sistemas operativos ó lenguajes que fomentan el uso de múltiples threads

(hilos de control), tal como Java, pueden usar la estrategia multithreaded, descrita

a continuación :

1. Esperar conexiones entrantes sobre el puerto 502 de TCP.

2. Cuando una nueva solicitud de conexión sea recibida, aceptarla y crear un

nuevo thread para manejar la conexión.

3. Dentro del nuevo thread, hacer lo siguiente en un lazo infinito :

• Leer el encabezado de 6 bytes de la solicitud Modbus/TCP. No colocar un

timeout aquí, pero en cambio esperar hasta ya sea que llegue la solicitud ó la

conexión sea cerrada. Ambas situaciones despertarán al thread

automáticamente.

• Analizar el encabezado. Si aparece corrupto, por ejemplo si el campo de

protocolo no es cero ó la longitud del mensaje es más grande que 256,

entonces cerrar unilateralmente la conexión. Esta es la respuesta correcta de

un servidor a una situación donde la codificación TCP es incorrecta.

• Leer los bytes restantes del mensaje, cuya longitud es ahora conocida.
26

• Procesar el mensaje MODBUS que ingresó, si es necesario suspendiendo el

thread corriente hasta que la respuesta correcta pueda ser calculada.

Eventualmente se tendrá ya sea un mensaje MODBUS válido ó un mensaje de

excepción para usar como una respuesta.

• Generar el prefijo Modbus/TCP para la respuesta, copiando el campo

“identificador de transacción” desde la solicitud, y recalculando el campo de

longitud.

• Enviar la respuesta, incluyendo el prefijo Modbus/TCP como un buffer único

para transmisión sobre la conexión establecida.

• De nuevo volver a esperar el próximo prefijo de 6 bytes, y repetir el

procedimiento.

Eventualmente, cuando el cliente elija cerrar la conexión, la recepción del prefijo

de 6 bytes fallará. En este caso se cierra la conexión y se cancela el thread

corriente.
27

2. DESCRIPCION DEL HARDWARE

La red Modbus/TCP que se implementa en este proyecto, ver Figura 1.1, se

encuentra conformada por diversos elementos hardware, incluyendo los

elementos finales de control. A continuación se enumeran los componentes que

integran la red:

1. Tarjeta TINI.

2. Tarjeta CPU08.

3. PLC DL05 de Koyo.

4. Controladores 452 PLUS.

2.1 LA TARJETA TINI21

La tarjeta TINI es un sistema embebido para la cual se desarrollarán las siguientes

aplicaciones: un servidor Modbus/TCP, un servidor Web y el software para actuar

como gateway de otros esclavos, como el PLC DL05 y la tarjeta CPU08.

21
Tomado de “The TINI Specification and Developer`s Guide”, por Don Loomis. Addison – Wesley, 2001.
28

2.1.1 Descripción.

La Tiny InterNet Interface (TINI) es una plataforma desarrollada por Dallas

Semiconductor que suministra un medio simple, flexible y económico para diseñar

una extensa variedad de dispositivos hardware capaces de conectarse

directamente a redes corporativas y locales. Las características de la plataforma

son expuestas al desarrollador de software a través de un set de interfaces de

programación de aplicaciones (APIs) en Java, brindando un poderoso entorno de

programación orientado a objetos y facultando al programador en la creación de

aplicaciones utilizando la potencia y bondades que ofrece el lenguaje Java.

La plataforma TINI permite a dispositivos como sensores y actuadores ser

monitoreados, controlados y manejados remotamente. Esta capacidad de

interconectividad de red de la TINI permite a cualquier dispositivo conectado a ella,

una interacción con sistemas remotos y usuarios a través de aplicaciones de red

estándar, tal como browsers Web.

2.1.2 Características.

La TINI es una tarjeta SIMM (31.8mm x 102.9mm) de 72 pines. Es una

implementación hardware con Ethernet y soporta toda la funcionalidad

suministrada por cualquier sistema embebido. La tarjeta incluye las siguientes

características:
29

• 512 Kilobytes de memoria flash para código del sistema crítico.

• 512 Kilobytes de memoria SRAM no-volátil, expandible a 1 Megabyte.

• Controlador Ethernet 10Base-T.

• Reloj de tiempo real.

• Doble puerto serial (uno con niveles RS-232 y otro con niveles TTL).

• Doble controlador CAN.

• Doble interfaz de red 1-Wire.

• Expone los buses de datos y direcciones del microcontrolador para expansión

paralela.

• Requiere una fuente de alimentación única de 5V DC.

• El sistema operativo es actualizado constantemente y puede ser cargado

directamente a la memoria flash.

2.1.3 Aplicaciones.

La TINI está diseñada para satisfacer los requerimientos de las aplicaciones de

red embebidas tanto industriales como comerciales. Sin embargo, a causa de su

bajo costo y la disponibilidad de herramientas de desarrollo de software gratuito,

también está incursionando en el hogar y en entornos educativos. La TINI puede

ser usada para tareas embebidas tradicionales stand-alone, pero la mayoría de

aplicaciones utilizan las capacidades de interconectividad de la tarjeta. Unas

pocas aplicaciones de la tecnología TINI incluyen las siguientes:


30

• Monitoreo y control de equipo basado en Web. La TINI puede ser usada para

establecer comunicación con equipos específicos, para proveer recolección de

datos y diagnóstico remoto para propósitos tales como el monitoreo sobre la

utilización de un dispositivo particular.

• Conversión de protocolos. Los sistemas basados en la TINI pueden ser usados

para conectar dispositivos a redes Ethernet. Esto puede ser hecho con un PC,

sin embargo la TINI hace el trabajo en una fracción del costo y del tamaño.

• Sistemas de medición remota. Es posible construir aplicaciones para medición

distribuidas en una red. La TINI estaría equipada con dispositivos de medición

como servidor que se controla desde un cliente remoto.

• Control industrial. Utilizando el soporte integrado de la TINI, como el bus CAN

(Controller Area Network) para llevar a cabo la automatización de equipo.

• Monitores ambientales. Usando el soporte construido en la TINI de

interconexión 1-Wire, una aplicación puede interrogar a sensores y reportar los

resultados a hosts remotos.

La Figura 2.1 muestra un modelo de uso en el cual la TINI es empleada como un

conversor de protocolos (ó enlaces) entre un dispositivo embebido y una red

Ethernet.
31

Figura 2.1 La TINI como un conversor de protocolos

El dispositivo embebido puede comunicar con el mundo exterior usando un puerto

serial RS-232, un puerto CAN, ó quizás algún tipo de interfaz paralela.

La aplicación Java corriendo sobre la TINI desempeña la tarea de comunicación

con el dispositivo en su lenguaje nativo (usando un protocolo de comunicación

específico del dispositivo) y presenta los resultados a sistemas remotos

alcanzables a través de una red TCP/IP. El enlace suministrado por la TINI es

bidireccional, permitiendo a un sistema remoto controlar el dispositivo.

2.1.4 Hardware de la TINI.

La TINI esta desarrollada con diversos chips LSI. Un esquema del hardware que

compone la TINI es presentado en la Figura 2.2.


32

Figura 2.2 Esquema del hardware de la TINI

La TINI está compuesta principalmente de los siguientes elementos:

• Microcontrolador.

• Memoria flash.

• Memoria RAM estática.

El corazón de la TINI es el microcontrolador DS80C390 de Dallas Semiconductor.

El DS80C390 integra soporte para diversas formas de I/O incluyendo puertos

seriales, enlace 1-Wire y bus CAN. El microcontrolador también provee distintos

pines de propósito general que pueden ser usados para desempeñar tareas de

control simples tales como manejar relés y LEDs de estatus.


33

La memoria flash almacena el entorno runtime22 de la TINI y satisface los

siguientes dos requerimientos importantes:

1. El contenido de memoria es mantenido, igual en ausencia de potencia al

sistema.

2. La memoria es reprogramable, y por tanto el entorno runtime puede ser

actualizado cuando sea requerido.

La memoria RAM estática contiene el área de datos, la pila (heap), al igual que los

archivos de datos del sistema. La SRAM es no-volátil, ya que posee una circuitería

con batería de respaldo de forma que el contenido de la memoria persiste en

ausencia de alimentación. La batería es una muy pequeña celda de litio.

Otros dispositivos periféricos, aparte de la memoria, pueden también ser

interfazados directamente a los buses de datos y direcciones del microcontrolador

(denominada “expansión I/O paralela” en la Figura 2.2). Dos de tales periféricos

usados en el sistema TINI son un controlador Ethernet y un reloj en tiempo real.

Esta configuración extiende el alcance de los dispositivos embebidos a redes

Ethernet y provee una referencia exacta de tiempo para propósitos específicos.

La batería de respaldo también mantiene corriendo el reloj en ausencia de

potencia, asegurando que un tiempo exacto es siempre leído desde el reloj.

22
El entorno runtime esta compuesto por el sistema operativo y la Máquina Virtual Java (JVM).
34

2.1.5 Mapa de memoria del sistema.

Un mapa de memoria especifica dónde la memoria y otros dispositivos periféricos

son decodificados en el espacio de direcciones del microcontrolador. El mapa de

memoria utilizado por la TINI, mostrado en la Figura 2.3, consiste de los siguientes

tres segmentos:

• Segmento de código.

• Segmento de datos.

• Segmento de periféricos.

Figura 2.3 Mapa de memoria de la TINI


35

La figura ilustra los máximos tamaños de segmento soportados por la TINI. La

dirección de inicio del segmento es siempre constante, mientras la dirección final

puede variar de acuerdo al tamaño de memoria.

La TINI consume los siguientes rangos de direcciones:

1. TINI OS y Java API: [ 0x000000 – 0x07FFFF ]

2. Heap y almacenaje del sistema de archivos: [ 0x180000 – 0x280000 ]

3. Controlador Ethernet: [ 0x300000 – 0x37FFFF ]

4. Reloj de tiempo real: [ 0x310000 ]

Los diseñadores deben evitar los rangos del controlador Ethernet y el reloj, cuando

se adicionen otros dispositivos periféricos.

Existe también un área periférica separada, de 4 Megabytes, conocida como

espacio PCE (Peripheral Chip Enable), que puede ser usada para interfazar

grandes chips de memoria externa ú otros dispositivos directamente a los buses

de datos y direcciones del microcontrolador.

Sin embargo, la mayoría de hardware es mapeado en el segmento periférico

porque el microcontrolador puede accesarlo más eficientemente.


36

2.1.6 Sistema I/O integrado.

Un amplio rango de dispositivos no soportan la interfaz a un bus periférico.

Frecuentemente esos dispositivos tienen alguna forma de interfaz serial. Un

soporte para los siguientes protocolos de comunicación serial han sido integrados

dentro del microcontrolador.

• Comunicación serial. Son soportados protocolos seriales síncronos, utilizando

una interfaz de 2 alambres, y comunicación serial asíncrona, basada en el

estándar RS-232. El microcontrolador de la TINI provee dos circuitos UART

(Universal Asynchronous Receiver Transmitter) integrados, que facilitan la

comunicación.

• Bus CAN. Originalmente desarrollado en Bosch-Siemens, CAN está ahora

descrito en dos estándares ISO. CAN suministra un bus de comunicaciones

serial confiable que es comúnmente usado en aplicaciones de control industrial

y automotriz. El microcontrolador de la TINI provee dos controladores CAN

integrados.

• Red 1-Wire. Desarrollado por Dallas Semiconductor, el enlace 1-Wire es una

red de pequeños sensores, actuadores, y elementos de memoria en que todos

comparten el mismo conductor tanto para comunicación como para potencia.


37

• I/O TTL. Los pines de propósito general del puerto del microcontrolador pueden

ser usados para diversas tareas de control y no están necesariamente atados a

algún tipo de dispositivo serial.

La utilización de las capacidades I/O integradas en el microcontrolador en lugar de

I/O mapeada en memoria, reduce el costo de la comunicación con un dispositivo

externo porque se libera a la CPU de operaciones de lectura y escritura de datos

a un dispositivo periférico.

2.1.7 Software de la TINI.

Aparte del hardware esencial para el desarrollo de aplicaciones de red embebidas,

una gran cantidad de software es también suministrado con la TINI para liberar a

los desarrolladores de aplicación de tener que preocuparse acerca de los detalles

de la creación de capas de infraestructura que den soporte para la ejecución de

tareas múltiples, pilas de protocolos de red e interfaces de programación de

aplicaciones. Un entorno bien definido que suministre todas de esas

características permite al desarrollador enfocarse principalmente sobre los detalles

de la aplicación. De esta forma, un entorno runtime fue desarrollado como parte

integral de la plataforma TINI. Una representación gráfica del entorno runtime es

mostrada en la Figura 2.4.


38

Figura 2.4 Esquema del software de la TINI

El software que comprende el entorno runtime de la TINI puede ser dividido en dos

categorías: un sistema operativo el cual es ejecutado directamente por el

microcontrolador y un API interpretado como bytecodes por la Máquina Virtual de

Java (JVM).

El código de las aplicaciones corriendo sobre la tarjeta TINI son escritos en Java y

utilizan el API, siendo esto uno de los principales atractivos de la tarjeta.


39

Java es un lenguaje de programación simple, poderoso, concurrente, orientado a

objetos, con capacidades cliente/servidor, con el cual se pueden crear programas

interactivos, seguros, portables, robustos y para cualquier tipo de arquitectura.

Es posible escribir también librerías nativas que pueden ser cargadas desde una

aplicación para lograr requerimientos estrictos de tiempo real.

2.1.8 Sistema operativo de la TINI.

El sistema operativo de la TINI es la capa más baja del entorno runtime. Es

responsable de la administración de todos los recursos del sistema incluyendo el

acceso a la memoria, planificación de procesos múltiples y threads de ejecución, y

la interacción con componentes hardware internos y externos. A excepción del

recolector de basura23, todas las tareas manejadas por el sistema operativo son

aplicaciones Java.

Los tres componentes principales que conforman el sistema operativo son:

• Planificador de procesos y threads.

• Subsistema de manejo de memoria.

• Subsistema de manejo de I/O.

23
El recolector de basura (Garbage Collector) es un hilo que Java provee, el cual automáticamente
recupera la memoria dinámicamente repartida que ya no se necesita, liberando a los programadores
de incluir enunciados en los programas para ejecutar esta acción.
40

Tanto la pila TCP/IP como el manejador de I/O son implementados como procesos

del kernel independientes. La pila de protocolo de red TCP/IP provee mucha de la

misma capacidad de interconectividad encontrada sobre plataformas más grandes

y es suficientemente rica en funcionalidad para soportar una implementación

completa del paquete java.net. La pila de protocolo soporta múltiples interfaces de

red, incluyendo Ethernet, para interconexión de alta velocidad en área local, y PPP

(Point-to-Point Protocol) sobre un enlace serial para interconexión remota usando

modem.

2.1.9 El Socket E10.

El Socket E10 es una tarjeta de 160mm x 120mm, cuya función principal es

proveer los conectores físicos para interfazar la TINI a Ethernet, dispositivos

seriales, alimentación. La tarjeta Socket E10 está destinada a ayudar en el

proceso de desarrollo de aplicaciones y suministra los siguientes conectores

físicos:

• Conector SIMM de 72 pines. El conector SIMM acepta la tarjeta TINI.

• Conector DB9 hembra. Este conector provee un puerto serial tipo DCE (Data

Communications Equipment) que da conexión a un puerto serial DTE (Data

Terminal Equipment) estándar. Este puerto es típicamente usado sólo para

cargar el software a la memoria flash de la TINI.


41

• Conector DB9 macho. Este conector provee un puerto serial DTE para

conexión a dispositivos DCE tal como modems. Muchas aplicaciones TINI que

controlan dispositivos seriales usan el puerto DTE.

• Conector RJ45. El conector RJ45 acepta un cable Ethernet estándar 10Base-T

suministrando conectividad a una red Ethernet.

• Conector RJ11. El conector RJ11 provee acceso a la red 1-Wire usando cable

telefónico estándar.

• Jack de potencia. El Socket E10 acepta una fuente de alimentación de 5V DC.

El Socket E10 también suministra el espacio respectivo para circuitos integrados y

componentes discretos para soportar opciones adicionales de I/O tales como

expansión paralela, y otros puertos seriales y CAN.

2.2 LA TARJETA CPU08

La tarjeta CPU08 es un sistema embebido desarrollado en la Universidad del Valle

basado en el microcontrolador AT89C52 de Atmel. Según el diagrama de la

Figura 1.1, en esta tarjeta se debe implementar algunas funciones MODBUS

apropiadas para comportarse como un esclavo, y además debe manejar una red

RS-485 de controladores a través de un protocolo codificado en ASCII.


42

2.2.1 Diagrama de bloques.

El diagrama de bloques para la tarjeta CPU08 es presentado en la Figura 2.5.

Figura 2.5 Diagrama de bloques de la CPU08

2.2.2 Características.

• 8k bytes de memoria de programa interna.

• 256 bytes de memoria RAM interna.

• 8k bytes de memoria RAM externa.

• 3 contadores / temporizadores de 16 bits.

• 4 entradas digitales aisladas (a través de optoacopladores).

• Puerto serial RS-232 / RS-485.


43

• Puerto síncrono SPI.

• 2 interrupciones externas.

• Voltaje de alimentación regulado de +5V.

• Presenta conectores para expandir las funciones del sistema.

Además, se proporciona un programa bootloader residente en la memoria flash

que carga el programa de aplicación en la RAM externa para propósitos de

desarrollo y depuración, de forma que la aplicación pueda ser fácilmente

modificada.

2.2.3 Programación de la CPU08.

La tarjeta CPU08 se programa directamente en el lenguaje propio del

microcontrolador AT89C52. Opcionalmente, es posible realizar la programación en

lenguaje C y utilizar un compilador cruzado que traslade el código fuente C al

lenguaje del microcontrolador. La utilización del lenguaje C para realizar la

programación depende de los requerimientos de desempeño y tamaño de código

que se necesiten satisfacer.

En este proyecto, la programación de la tarjeta CPU08 se realizó en lenguaje C

usando el compilador proporcionado por el paquete Franklin, un entorno de

desarrollo para aplicaciones basadas en microcontroladores de la familia 8051.


44

2.3 EL PLC DL05 DE KOYO

Este dispositivo PLC ofrece características convenientes para integrarlo en la red

mostrada en la Figura 1.1, ya que proporciona un puerto serial que permite al PLC

ser configurado como un maestro ó un esclavo MODBUS. En la figura el PLC se

comporta como un dispositivo esclavo MODBUS.

2.3.1 Diagrama de bloques.

El diagrama de bloques para el dispositivo PLC Direct DL05 de Koyo es mostrado

en la Figura 2.6.

Figura 2.6 Diagrama de bloques del PLC DL05


45

La función HSIO (High-Speed I/O) que proporciona este PLC, consiste de

hardware dedicado pero configurable en el DL05. Para más información sobre su

operación consultar el manual del PLC.

2.3.2 Características.

• 8 entradas DC de alta velocidad.

• 6 salidas relé.

• Conjunto de 129 instrucciones para programación.

• Memoria de programa de 2K bytes.

• Memoria de datos de 4K bytes.

• 2 puertos de comunicación RS-232.

• Soporta los protocolos DeviceNet y MODBUS.

• Algoritmos PID integrados, con lazo auto-tunning.

• Módulos opcionales de entrada / salida análogos.

2.3.3 Modos de operación.

El PLC DL05 posee tres modos de operación: modo TERM, modo RUN y modo

STOP. En la Tabla 2.1 se describen los tres modos de operación del PLC.
46

Tabla 2.1 Modos de operación del PLC DL05

Modo Descripción

(Terminal). Están disponibles los modos de depuración,

programación y ejecución. Los diferentes modos y los


TERM
cambios en la programación pueden ser conmutados a

través del software de programación.

(Ejecución del Programa). La CPU es forzada dentro


RUN
del modo de ejecución si no existen errores.

STOP La CPU es forzada a parar.

2.3.4 Mapa de memoria.

Los tipos de memoria del PLC se dividen en dos categorías :

• Discretos: X, SP, Y, CR, S, T, C.

• Palabras de memoria: valor actual del timer, valor actual del contador, datos
de usuario.

La Tabla 2.2 muestra los distintos tipos de memoria del PLC DL05, con sus
respectivas direcciones en octal y su correspondiente valor en decimal para ser
procesadas por una aplicación MODBUS.
47

Tabla 2.2 Tipos de memoria del PLC DL05

Rango en
Tipo de memoria Cantidad Rango PLC Tipo de dato
Modbus
del PLC (decimal) (octal) Modbus
(decimal)

Datos discretos

Entradas (X) 256 X0 – X377 2048 - 2303 Entrada

Relés especiales 512 SP0 – SP777 3072 – 3583 Entrada

Salidas (Y) 256 Y0 – Y377 2048 – 2303 Salida

Relés de control (CR) 512 C0 – C777 3072 – 3583 Salida

Timers (T) 128 T0 –T177 6144 – 6271 Salida

Contadores (CT) 128 CT0 – CT177 6400 – 6527 Salida

Bits de status 256 S0 – S377 5120 – 5375 Salida

Palabras de memoria

Valor actual del timer 128 V0 – V177 0 – 127 Registro de


(V) entrada

Valor actual del 128 V1000 – V1177 512 - 639 Registro de


contador (V) entrada

Memoria V, dato de 3168 V1200 – V7377 640 – 3809 Registro de


usuario (V) retención

Memoria V, no volátil 128 V7600 – V7777 3968 - 4095 Registro de


(V) retención

2.3.5 Comunicación.

El PLC DL05 posee dos puertos de comunicación RS-232. Las características de

los puertos 1 y 2 se muestran en las Tablas 2.3 y 2.4 respectivamente.


48

Tabla 2.3 Características del puerto 1 del PLC DL05

Paquete de programación DirectSOFT.


Rata de baudios 9600 bps (fijos).
Bits de inicio 1
Bits de datos 8
Paridad Impar (por defecto), par, ninguna
Bits de parada 1
Comunicación Asíncrona, half duplex con el DTE.
K-sequence, DirectNET y MODBUS
Protocolos soportados
RTU, todos como esclavos.
Dirección del dispositivo 1 (fija)

Tabla 2.4 Características del puerto 2 del PLC DL05

Paquete de programación DirectSOFT.


300, 600, 1200, 2400, 4800, 9600,
Rata de baudios
19200 y 38400.
Bits de inicio 1
Bits de datos 8
Paridad Impar (por defecto), par, ninguna.
Bits de parada 1
Comunicación Asíncrona, half duplex con el DTE.
K-sequence, DirectNET, MODBUS RTU
Protocolos soportados (maestro o esclavo) y Non-sequence
(para impresión).
Dirección del dispositivo 1 a 247.
49

2.3.6 Programación.

El PLC DL05 posee dos métodos de programación: RLL (Relay Ladder Logic) y

RLL PLUS (PLUS PROGRAMMING). El PLC puede ser programado con un

paquete de programación avanzado, DirectSOFT, un software basado en

Windows que soporta las características más familiares para este sistema

operativo.

2.4 CONTROLADORES 452 PLUS

Los controladores 452 Plus son dispositivos que permiten realizar lectura de

variables, manejo de setpoint, establecer estrategias de control, tal como

algoritmos PID, para llevar a cabo automatización de procesos. La configuración

de los parámetros del controlador (setpoint, cte. Proporcional, cte. Derivativa, etc.)

pueden ser establecidos localmente a través del panel frontal, ó remotamente a

través de una interfaz serial RS-232, RS-423A, RS-422A, ó RS-485.

La comunicación remota con el controlador se desarrolla serialmente usando un

protocolo asíncrono codificado en ASCII de 7 bits con paridad par, un bit de

parada y un bit de inicio, a 9600, 4800, 1200 ó 300 bps.


50

2.4.1 Definición de caracteres especiales.

Los controladores 452 Plus establecen para la comunicación un conjunto de

caracteres especiales ASCII no imprimibles, mostrado en la Tabla 2.5.

Tabla 2.5 Caracteres especiales ASCII del controlador

Carácter Código
Descripción
especial hexadecimal
< STX > 02 Caracter de inicio de trama.
< ETX> 03 Caracter de fin de trama.
< EOT> 04 Caracter de fin de transmisión.
< ACK > 06 Caracter de reconocimiento.
< LF > 0A Caracter de nueva línea.
< CR > 0D Caracter de retorno.
< NAK > 15 Caracter de no reconocimiento.
< SYN > 16 Caracter de sincronización.
< ESC > 1B Caracter de borrado de línea.
< DEL > 7F Caracter de borrado de carácter.

2.4.2 Protocolo de Comunicación.

El protocolo de comunicación está definido en dos “capas” ó niveles; la primera

define el “wrapping” del mensaje (la delimitación de su inicio y su fin), mientras la

segunda describe el contenido del mensaje.


51

2.4.2.1 Nivel 1 – El “Wrapping”.

Este depende de la complejidad de la comunicación que se desea establecer. Dos

modos de comunicación son ofrecidos: el modo VDU (Visual Display Unit) y el

modo CRL (Control).

El modo VDU está definido para comunicación simple entre un terminal y un

controlador. Aquí un mensaje no necesita caracteres de inicio, y es terminado con

un caracter de retorno <CR>.

Con el modo CRL se define una comunicación entre un computador y múltiples

controladores. Este modo es más complejo, ya que primero se debe especificar

cual controlador se desea direccionar. La dirección es precedida por un caracter

especial <SYN> que indica al dispositivo receptor que el próximo caracter es

interpretado como la dirección.

En modo CRL los mensajes individuales están delimitados por <STX> para indicar

el inicio y <ETX> para indicar el final.

2.4.2.2 Nivel 2 – Contenido del mensaje.

Existen seis tipos de mensajes: establecer una variable análoga, establecer una

variable lógica, leer un valor análogo, leer un valor lógico, al igual que lectura de

un bloque de valores análogos ó lógicos.


52

Tabla 2.6 Tipos de mensaje del controlador 452 Plus

Tipo de mensaje Descripción


RA Leer variable análoga.
RL Leer variable lógica.
SA Escribir en localización análoga.
SL Escribir en localización lógica.
DA Leer 10 posiciones análogas desde la posición de inicio.
DL Leer 10 posiciones lógicas desde la posición de inicio.

2.4.3 Contenido de posiciones análogas del controlador 452 Plus.

En la Tabla 2.7 se relacionan algunas de las posiciones análogas propias de los

controladores 452 Plus.

Tabla 2.7 Posiciones de memoria del controlador 452 Plus

Posición análoga Descripción


0 Tipo de instrumento (sólo lectura).
1 Valor medido (sólo lectura).
2 Setpoint.
3 Potencia de salida (0 – 100 %).
7 Banda proporcional (%)(0 - 500.0).
8 Término integral (minutos)(0 – 200.0).
9 Término derivativo (segundos)(0 – 4000).
53

3. DESCRIPCIÓN DEL SOFTWARE

Sobre los elementos que componen la red Modbus/TCP (Figura 1.1) se ejecutan

diversos programas que son los que proporcionan la funcionalidad al sistema. El

desarrollo del software se dividió en las siguientes etapas:

1. Desarrollo de un servidor Modbus/TCP en la tarjeta TINI.

2. Desarrollo de un servidor Web en la tarjeta TINI.

3. Desarrollo de una interfaz gráfica para acceso vía Web.

4. Implementación de un esclavo MODBUS en la tarjeta CPU08.

5. Programación de la tarjeta CPU08 como maestro de una red RS-485 de

controladores.

6. Configuración del PLC DL05 como un esclavo MODBUS.

7. Configuración de los controladores 452 Plus.

En las siguientes secciones se describe detalladamente cada uno de los

componentes software y la interacción que existe entre los mismos; además se

presenta código fuente para determinados programas.


54

3.1 DESARROLLO DE UN SERVIDOR MODBUS/TCP

El protocolo Modbus/TCP está basado en el paradigma cliente / servidor: el

proceso servidor acepta una petición desde la red, ejecuta una acción basado en

la petición y devuelve el resultado al solicitante; un programa se convierte en

cliente cuando envía una petición al servidor y espera una respuesta. Este modelo

es ilustrado en la Figura 3.1.

Figura 3.1 Modelo cliente / servidor

El programa servidor para Modbus/TCP reside en la tarjeta TINI y por tanto se

desarrolló en Java, basándose en las indicaciones establecidas en la guía de

implementación descrita en la sección 1.7.1.

La implementación del servidor hace uso de la programación orientada a objetos y

el multithread para aceptar solicitudes concurrentes. La estructura de clases y

parte de la implementación está basada en el proyecto “jmodbus”.24

24
Disponible en Internet en http://jmodbus.sourceforge.net
55

El objetivo del proyecto “jmodbus” es proveer librerías Java para permitir a

dispositivos basados en este lenguaje comunicarse como maestros ó esclavos a

través de ModbusRTU, ModbusASCII ó ModbusTCP. El código es abierto y está

diseñado para correr sobre dispositivos con poca memoria, tales como la TINI de

Dallas Semiconductor.

3.1.1 Estructura de Clases.

Un diagrama de la estructura de clases está en la Figura 3.2, donde se observa la

clase base Modbus al igual que las implementaciones maestro y esclavo, y como

éstas se relacionan con implementaciones específicas de transporte.

Figura 3.2 Estructura de clases


56

En la Figura 3.3 se ilustra la estructura de ModbusTransport, la cual es una

interface que es implementada por las clases que definen los diferentes

mecanismos de transporte para la familia MODBUS (RTU, ASCII y TCP).

Figura 3.3 Estructura de la interface de transporte

3.1.2 Descripción de las Clases.

La aplicación desarrollada que corre en la TINI se encuentra conformada por las

siguientes clases:

• Clase Modbus. Clase para representar un dispositivo MODBUS. Esta es la

clase base que será extendida por las clases representando tanto un maestro

como un esclavo MODBUS.


57

• Clase ModbusMaster. Clase para representar un dispositivo maestro

MODBUS. Esta es la clase base que será extendida por las clases

representando un maestro para los diferentes transportes (RTU, ASCII y TCP).

Esta clase contiene el código requerido para generar una solicitud MODBUS y

analizar la respuesta.

• Clase ModbusRTUMaster. Clase para implementar un dispositivo maestro

MODBUS RTU. Esta clase define qué tipo de transporte es usado; todo el

trabajo en generar y enviar solicitudes es desempeñado por los métodos en la

clase ModbusMaster.

• Clase ModbusRTUTransport. Clase para implementar un mecanismo de

transporte RTU para comunicación MODBUS. Esta clase permite a un

dispositivo comunicarse serialmente, usando codificación RTU para los datos.

• Clase ModbusSlave. Clase para representar un dispositivo esclavo MODBUS.

Esta es la clase base que será extendida por las clases representando un

esclavo para los diferentes transportes (RTU, ASCII, y TCP). Esta clase

contiene el código que es requerido para la recepción y el procesamiento de

solicitudes. Esta clase también implementa la interfaz Runnable25, así que

cualquier instancia de esta clase puede correr como un thread independiente.

25
La interfaz Runnable permite manejar multihilos sin necesidad de extender la clase Thread.
58

• Clase ModbusTCPSlave. Clase para implementar un dispositivo esclavo

Modbus/TCP. Esta clase corre como un thread independiente. La clase solo

define que tipo de transporte es usado; el trabajo en la recepción y el

procesamiento de solicitudes es desempeñado por los métodos de la clase

ModbusSlave.

• Clase ModbusTCPTransport. Clase para implementar un mecanismo de

transporte TCP para la comunicación MODBUS. Esta clase permite a cualquier

dispositivo comunicarse vía Modbus/TCP. Esta clase debe implementar los

métodos definidos en la interface ModbusTransport.

• Clase ModbusMessage. Clase para representar un mensaje MODBUS. Esta

clase encapsula todos los elementos de un mensaje que son considerados

comunes a todas las implementaciones de MODBUS.

• Clase ServidorModbusTCP. Esta es la aplicación principal que se mantiene

esperando por solicitudes de conexión al puerto 502 de TCP, el puerto

registrado de Modbus/TCP, y cuando arriva una petición crea un nuevo hilo

que procesa la transacción, mientras la aplicación continúa escuchando por

nuevas solicitudes.
59

• Interface ModbusTransport. Interface para los mecanismos de transporte

MODBUS. Esta interface es implementada por las clases que representan el

transporte para los diferentes tipos de MODBUS. Las clases que implementan

esta interface son responsables por el enmarcado, delimitación y codificación

de tramas MODBUS desde el medio de transporte y el envío y recepción real

de los datos.

La aplicación desarrollada se comporta como un servidor (ó esclavo)

Modbus/TCP, pero también actúa como un gateway de forma que es capaz de

direccionar solicitudes MODBUS destinados a otros esclavos a través de

MODBUS RTU.

3.1.3 Ejemplo de código fuente.

En esta sección se describen algunos apartes importantes del código fuente de la

aplicación que ejecuta la tarjeta TINI.

Java ofrece comunicaciones basadas en sockets que permite las aplicaciones

manejar el trabajo en redes como si fuera entrada / salida de archivos; por tanto el

servidor que corre en la TINI está fundamentado en este concepto. En la Figura

3.3 se lista una porción del código de la clase ServidorModbusTCP, la cual fue

explicada en la sección anterior.


60

1 import java.net.* ;
2
3 public class ServidorModbusTCP
4 {
5 private final int DIRECCION = 1;
6 private final int PUERTO = 502;
7 private final int NUMERO_DE_CONEXIONES = 2;
8 .
9 .
10 .
11 public static void main (String args[ ])
12 {
13 ServerSocket svrSocket = null;
14 Socket socket = null;
15 Thread hiloModbus;
16 ModbusTCPSlave modbus;
17 .
18 .
19 .
20 try {
21 svrSocket = new serverSocket( PUERTO );
22 }
23 catch( IOException ex ) {
24 System.out.println( ex.getMessage( ) );
25 ex.printStackTrace( );
26 return;
27 }
28
29 while( true )
30 {
31 try {
32 socket = svrSocket.accept( );
33 modbus = new ModbusTCPSlave( DIRECCION, socket );
34 hiloModbus = new Thread ( modbus );
35 hiloModbus.start( );
36 }
37 catch ( IOException ex ) {
38 System.out.println( ex.getMessage( ) );
39 ex.printStackTrace( );
40 }
41 }
42
43 }
44 }

Figura 3.3 Programa en Java de un servidor Modbus/TCP


61

La creación de una conexión socket TCP/IP se realiza directamente con el

paquete java.net. De ahí que con el enunciado de la línea 1 se cargan las clases

del paquete de trabajo con redes de Java (Java Networking Package).

Las líneas 5, 6 y 7 definen constantes requeridas en la clase ServidorModbusTCP

como el número de puerto y el identificador de unidad.

Para establecer un servidor en Java, se utilizan instancias de las clases

ServerSocket y Socket.

En la línea 13 se declara un objeto de la clase ServerSocket. Este es el objeto

utilizado en la aplicación servidor para escuchar las peticiones que realicen los

clientes. Este objeto no realiza el servicio, sino que crea un objeto Socket en

función del cliente para realizar toda la comunicación a través de él.

En la línea 14 se declara un objeto de la clase Socket. Este es el objeto básico en

toda comunicación a través de Internet, bajo el protocolo TCP. Esta clase

proporciona métodos para la entrada/salida a través de streams.

En la línea 15 se declara un objeto de la clase Thread. Esta es la clase que Java

proporciona para dar soporte al multihilado y a las capacidades de la

programación concurrente.
62

Una instancia de la clase ModbusTCPSlave se declara en la línea 16. Esta clase

fue explicada anteriormente y se ejecuta como un nuevo hilo por cada solicitud de

conexión que recibe el servidor. Por tanto esta clase debe implementar el método

run (ejecutar) de la clase Thread. El código que “realiza el verdadero trabajo” de

un hilo se coloca en su método run.

Con el enunciado de la línea 20 se establece al objeto ServerSocket el puerto en

el que el servidor esperará las conexiones de los clientes. El argumento

NUMERO_DE_CONEXIONES especifica el número de clientes que pueden

esperar una conexión y ser procesados por el servidor. Si la cola está llena, las

conexiones de los clientes se rechazarán automáticamente.

En la línea 29 se establece un ciclo while, el cual contiene el bloque de código que

el servidor permanecerá ejecutando siempre, que consiste básicamente en

esperar por solicitudes de conexión y la creación de hilos concurrentes para cada

conexión.

Una vez establecido el ServerSocket, el servidor escucha indefinidamente (ó se

bloquea) para detectar un intento de un cliente por conectarse. Esto se logra con

la llamada de método accept( ) de la clase ServerSocket, la cual devuelve un

objeto Socket cuando se establece una conexión. En la línea 32 se ejecuta esta

acción.
63

En la línea 34 se crea un hilo para manejar la conexión, y el programa inicia la

ejecución del hilo invocando el método start (arrancar) de ese hilo (línea 35); a su

vez, start invoca el método run. Una vez que start echa a andar el hilo, regresa de

inmediato al invocador. De ahí en adelante, el invocador ( el servidor ) se ejecutará

en paralelo con el hilo iniciado.

3.2 DESARROLLO DE UN SERVIDOR WEB

El protocolo HTTP (HyperText Transfer Protocol, protocolo de transferencia de

hipertexto) que constituye la base de la World Wide Web, está basado en el

modelo cliente / servidor y posee el puerto registrado 80 de TCP.

El servidor Web que corre en la tarjeta TINI se desarrolló en Java y la aplicación

básicamente implementa la función GET que se define en la especificación del

protocolo HTTP.

El servidor permite manejar múltiples conexiones concurrentemente; el programa

se mantiene escuchando en el puerto de HTTP y cuando llega una petición GET,

se crea un proceso hijo que maneja esa transacción particular y éste devuelve una

página HTML (HyperText Markup Language) al cliente.

En la Figura 3.4 se lista parte del código que define al servidor Web.
64

1 import com.dalsemi.tininet.http.HTTPServer;
2 import com.dalsemi.tininet.http.HTTPServerException;
3
4 class WebServer {
5 public static void main(String[] args) {
6
7 // Construir una instancia of HTTPServer que escuche al puerto 80
8 HTTPServer httpd = new HTTPServer(80);
9
10 // Establecer el nombre del directorio donde reside la página Web y
11 // el nombre del archivo html principal.
12 httpd.setHTTPRoot("/html");
13 httpd.setIndexPage("Index.html");
14
15 // Especificar un nombre para el archivo de “logging” y habilitarlo
16 httpd.setLogFilename("/log/web.log");
17 httpd.setLogging(true);
18
19 // Procesar las solicitudes ingresantes
20 for ( ; ; ) {
21 try {
22 httpd.serviceRequests();
23 }
24 catch (HTTPServerException e) {
25 System.out.println(e.getMessage());
26 }
27 }
28
29 }
27 }

Figura 3.4 Ejemplo de código para un servidor Web

La página HTML devuelta por el servidor Web al cliente contiene una applet, la

cual es la que verdaderamente representa la interfaz gráfica de usuario que

permite acceso remoto desde Internet. El desarrollo de esta applet se presenta en

la sección 3.3.
65

Las applets son un tipo de aplicaciones que Java permite crear, que se mantienen

(ó residen) en el servidor Web, son transportadas a través de Internet, instaladas

automáticamente en la máquina cliente y que se ejecutan localmente como parte

de una página Web.

En la Figura 3.5 se lista el contenido del archivo HTML que define la página Web,

y que tiene embebida a la applet.

1 <HTML>
2 <HEAD>
3 <TITLE> RED MODBUS/TCP</TITLE>
4 </HEAD>
5 <BODY BGCOLOR=FFFFFF>
6 <CENTER>
7 < APPLET ARCHIVE = Programa.jar CODE = "Programa.class”
8 WIDTH = 750 HEIGHT = 420 VSPACE = 80>
9 </APPLET>
10 </CENTER>
11 </BODY>
12 </HTML>

Figura 3.5 Archivo HTML que carga la applet en un navegador Web

Para mejorar el desempeño, en el archivo HTML se hace uso de una herramienta

del JDK: el programa JAR para la creación de archivos de tipo JAR (Java Archive).

Los beneficios que se obtienen con este programa tiene que ver con el tiempo de

respuesta en la carga de la applet. Cuando se ejecuta una applet, el browser o

navegador hace tantas conexiones al servidor como clases componen la applet. Si

por el contrario se crea un archivo JAR que contenga todas las clases que son

cargadas por la applet, el navegador solo realizará una conexión adicional al

servidor. Esto hará que la applet se cargue más rápidamente.


66

3.3 DESARROLLO DE UNA INTERFAZ PARA ACCESO WEB

En esta sección se describe la herramienta con la cual un usuario puede

remotamente leer y escribir registros ó posiciones discretas sobre los diversos

elementos que componen la red Modbus/TCP implementada (Figura 1.1), a través

de una red TCP/IP como por ejemplo Internet.

La herramienta se ha desarrollado como una applet de Java de forma que un

usuario puede acceder la red Modbus/TCP desde cualquier parte en Internet,

utilizando solamente un browser ó navegador independientemente de la

plataforma en que se encuentre el usuario.

El applet desarrollado posee las siguientes características:

• Control de acceso de usuarios; sólo personas autorizadas pueden acceder la

red Modbus/TCP.

• Monitoreo de variables ( valor medido, entradas discretas, etc. ) .

• Control de variables ( setpoint, salidas discretas, etc. ).

• Todas las operaciones de supervisión y control de variables se realizan

utilizando el protocolo Modbus/TCP, por tanto la applet debe codificar las

solicitudes según este estándar.


67

3.3.1 El applet como un cliente Modbus/TCP.

Además de proveer la interfaz gráfica para interacción con el usuario, el applet

también debe comunicarse con un servidor Modbus/TCP. Por tanto, como parte

integral del applet se ha implementado un cliente Modbus/TCP, según las

indicaciones establecidas en la sección 1.7.2.

En Java para establecer la comunicación como cliente se utiliza un objeto de tipo

Socket para conectarse con el servidor, un objeto InputStream para recibir

información del servidor y un objeto OutputStream para enviar información al

servidor.

InputStream (una subclase de Object) y OutputStream (una subclase de Object)

son clases abstractas que definen métodos para realizar operaciones de entrada y

salida respectivamente.

El código en Java que se ilustra en la Figura 3.6 establece comunicación con un

servidor Modbus/TCP remoto, construye una solicitud según el protocolo, envía la

solicitud y la respuesta recibida del servidor es verificada. La solicitud

Modbus/TCP que se implementa en el código de la figura es “Leer múltiples

registros”.
68

1 import java.io.* ;
2 import java.net.* ;
3
4 class ClienteModbusTCP
5 {
6
7 private final int PUERTO = 502 ;
8 private Socket socket = null;
9 private OutputStream output = null;
10 private BufferedInputStream input = null;
11 private int buffer[ ] = new int [261];
12
13 // Rutina para función de MODBUS. Código de función 03.
14 void Leer_Multiples_Registros (
15 String dns, // Dirección IP del servidor
16 int unidad, // Identificador de unidad
17 int referencia, // Número de referencia (posición)
18 int cantidad, // Cantidad de registros a leer
19 int registros[ ] ) // Buffer para colocar los valores leídos
20 {
21 int c, i;
22
23 try {
24
25 // Crear el socket y establecer las conexiones de flujo respectivas
26 socket = new Socket ( dns, PUERTO );
27 output = socket.getOutputStream( );
28 input = new BufferedInputStream( socket.getInputStream( ) );
29
30 // Construir la trama Modbus/TCP “leer registros”
31 for ( i=0; i<5; i++ )
32 buffer[ i ] = 0;
33 buffer[ 6 ] = (byte) unidad;
34 buffer[ 7 ] = 3;
35 buffer[ 8 ] = (byte) (referencia >> 8);
36 buffer[ 9 ] = (byte) (referencia & 0xFF);
37 buffer[ 10 ] = 0;
38 buffer[ 11 ] = (byte) cantidad;
39 buffer[ 5 ] = 6;
40
41 // Enviar la solicitud al servidor
42 output.write( buffer, 0, 12 );
43
44 // Esperar y leer la respuesta
45 c = input.read( buffer, 0, 261 );
69

46 // Verificar la respuesta y extraer los valores leídos


47 if ( c == ( 9+2*cantidad ) && buffer[ 7 ] == 3 )
48 {
49 for ( i = 0; i<cantidad; i++ )
50 {
51 // Construir el valor de registro de los bytes alto y bajo
52 registros[ i ] = ( ( (int) buffer[ 9+2*i ] ) << 8 ) & 0xFF00 |
53 ( (int) buffer[ 10+2*I ] & 0xFF );
54 }
55 }
56
57 else
58 System.out.println ( “Respuesta recibida erronea \n” );
59
60 // Cerrar la conexión socket
61 socket.close( );
62
63 }
64 catch (Exception e) {
65 System.out.println ( e.getMessage( ) );
66 e.printStackTrace( );
67 return;
68 }
69
70 return;
71 }
72
73 }
Figura 3.6 Código en Java para un cliente Modbus/TCP

En el programa anterior se define una función, Leer_Multiples_Registros, la cual

recibe diversos parámetros que se requieren para construir y enviar la solicitud. A

continuación se describen algunos aspectos relevantes del código.

• Es necesario importar el paquete java.io en el programa para realizar

operaciones de entrada / salida con sockets en Java. Este paquete incluye las

definiciones de las clases de flujos, como Outputstream y BufferedInputStream.


70

• Con un objeto BufferedInputStream ( una subclase de FilterInputstream ),

muchos segmentos “lógicos” de datos se leen en una sola operación de

entrada física y se colocan en un buffer de la memoria. Así, el número de

operaciones de entrada física reales es pequeño en comparación con el

número de solicitudes de lectura emitidas por el programa, mejorando el

rendimiento del sistema.

• Los métodos getInputStream y getOutputStream sirven para obtener

referencias a los InputStream y OutputStream respectivamente, asociados al

Socket.

3.3.2 Sistema de acceso.

El applet desarrollado proporciona una interfaz visual independiente de la

plataforma, la cual puede ser ejecutada por cualquier navegador en Internet.

Existe un sistema de acceso para restringir a personas no autorizadas realizar

operaciones sobre la red Modbus/TCP (Figura 1.1).

El sistema de acceso está implementado con la utilización de un nombre de

usuario ( login ) y una palabra clave ( password ), los cuales debe poseer una

persona para obtener el panel de control desde el cual acceder a la red

Modbus/TCP.
71

En la Figura 3.7 se observa la ventana que se obtiene cuando desde Internet se

ingresa la dirección del servidor Web que se encuentra en la tarjeta TINI.

Figura 3.7 Interfaz del Sistema de Acceso

Solamente si se proporciona el login y el password correctos, la ventana

desaparece y se visualiza el panel de control.

La ventana del sistema de acceso está implementada utilizando la librería AWT

(Abstract Window Toolkit) de Java, que es un kit completo con herramientas para

manejo de gráficos como paneles, ventanas, botones, menús, etc.

3.3.3 Panel de Control.

El panel de control hace parte del applet desarrollado; es la ventana que provee

elementos como botones, campos de texto, componentes gráficos, etc., la cual

visualiza el contenido o el estado de los diferentes registros y datos discretos que

poseen los esclavos que conforman la red Modbus/TCP. Además, desde el panel

es posible cambiar el contenido de determinados registros y valores discretos.


72

En la Figura 3.8 puede observarse el aspecto del panel de control que se cargaría

en un navegador Web.

Figura 3.8 Vista del panel de control

La información que se despliega en el panel de control se actualiza

constantemente; esto se realiza a través de un thread independiente que se

comunica con los elementos remotos de la red, enviándoles solicitudes

Modbus/TCP de lectura. Sin embargo, la información que se visualiza no es en

tiempo real debido a los retardos a través de la red.


73

3.4 IMPLEMENTACION DE UN ESCLAVO MODBUS EN LA CPU08

Como se expuso en la sección 2.2.5, la tarjeta CPU08 puede ser programada en

lenguaje C; la implementación del esclavo MODBUS se desarrolló en este

lenguaje y utilizando el paquete Franklin. El programa residente en la CPU08 es

capaz de procesar las funciones del protocolo MODBUS “escribir múltiples

registros” (código 16 hexadecimal) y “leer múltiples registros” (código 03

hexadecimal).

Para la aplicación a la que está destinada la tarjeta CPU08, solo se requieren

estas dos funciones ya que el programa básicamente redirecciona la solicitud (de

lectura ó escritura) a una subred RS-485 de controladores, los cuales entienden

determinados tipos de mensaje que son similares a las funciones MODBUS

previamente mencionadas; la CPU08 actúa como interfaz entre el protocolo

MODBUS y el protocolo codificado en ASCII de los controladores 452 Plus.

El programa de la CPU08 efectúa la conversión de protocolos de forma que la

solicitud MODBUS de lectura de registros se asocia con el tipo de mensaje RA

(leer variable análoga) del controlador 452 Plus; así mismo, la solicitud MODBUS

de escritura de registros se asocia con el tipo de mensaje SA (escribir en

localización análoga) del controlador 452 Plus. Para una descripción de los tipos

de mensajes del controlador revisar la tabla 2.6 y la sección 3.5.


74

De acuerdo a la sección 2.2.2, la tarjeta CPU08 posee un solo puerto de

comunicaciones RS-232 ó RS-485. La aplicación que se desarrolló para la CPU08

requiere de la existencia de dos puertos de comunicación serial, por tanto uno de

los cuales se implementó por software utilizando dos pines de propósito general,

que simulan las señales Rx y Tx de una UART.

El puerto de comunicaciones RS-485 que tiene la tarjeta se utiliza para establecer

la comunicación con los controladores 452 Plus. La UART del microcontrolador

AT89C52 de la CPU08 está configurada en modo 2, donde se transmiten 8 bits: 7

bits de datos (caracteres ASCII) y un bit de paridad par, a una rata de 9600 bps y

con un solo bit de parada.

Los datos intercambiados entre la CPU08 y los controladores 452 Plus son de tipo

decimal, por tanto en la CPU08 se debe codificar la información según el estándar

IEEE754 que define el formato para el almacenamiento y la transmisión de datos

flotantes. Cada dato flotante se debe tratar como dos registros holding según el

protocolo MODBUS.

3.4.1 Algoritmo de la aplicación para la CPU08.

El algoritmo para el programa residente en la tarjeta CPU08 puede ser apreciado

en la Figura 3.9.
75

Figura 3.9 Algoritmo para el programa de la CPU08


76

Una descripción detallada de las diferentes etapas que componen el algoritmo es

presentada a continuación.

• Inicio. Se establecen los valores para los registros de función especial del

microcontrolador de la tarjeta CPU08.

• Etapa 1. Esperar a través de la UART implementada por software, una

solicitud MODBUS a ser procesada.

• Etapa2. verificar la integridad de la trama MODBUS recibida. Básicamente

corroborar el código de chequeo de error (CRC) recibido con el calculado.

Además comprobar que el mensaje es direccionado a la tarjeta.

• Etapa 3. realizar una discriminación basándose en el campo de código de

función, para enviar el mensaje a la rutina respectiva.

• Etapa 4. Generar una respuesta de excepción indicando que el código de

función recibido no es soportado por el esclavo MODBUS.

• Etapa 5. Rutina para procesar la función de “leer múltiples registros”. Se

encuentra conformada por las etapas 7, 10 y 12.


77

• Etapa 6. Rutina para procesar la función de “escribir múltiples registros”. Se

encuentra conformada por la etapas 8, 11 y 13.

• Etapa 7 y 8. Verificar que la solicitud MODBUS se encuentra correcta. Por

ejemplo comprobar que el registro que se pretende leer ó escribir se encuentra

dentro del rango de direcciones manejado por el esclavo MODBUS.

• Etapa 9. Generar una respuesta de excepción, indicando el tipo de excepción

que se produjo.

• Etapa 10 y 11. Construir y enviar una solicitud de lectura ó escritura según el

caso al controlador respectivo, teniendo en cuenta el protocolo de

comunicación ASCII que manejan esos dispositivos. Esto se realiza a través

del puerto serial RS-485 de la CPU08.

• Etapas 12 y 13. A través del puerto RS-485 de la CPU08, recibir y verificar la

respuesta del controlador a la solicitud de lectura o escritura. A partir de los

datos obtenidos, armar según el protocolo una respuesta MODBUS a la

solicitud procesada.

• Etapa 14. Enviar la respuesta a la trama MODBUS recibida, a través de la

UART implementada por software.


78

La aplicación embebida residente en la tarjeta CPU08 se mantiene cíclicamente

esperando por tramas MODBUS y procesando las solicitudes.

En la sección 3.5 se describe detalladamente la codificación de una trama de

solicitud ó respuesta para los controladores 452 Plus, según el protocolo de

comunicación de estos dispositivos.

La Tabla 3.1 describe los pines de los puertos utilizados por el microcontrolador

que posee la tarjeta CPU08, al igual que la función que desempeñan.

Tabla 3.1 Pines utilizados por la tarjeta CPU08

Puerto Descripción
P3.5 Simula la señal de recepción de una UART.
P1.3 Simula la señal de transmisión de una UART.
P1.6 Señal de habilitación para el driver RS-485.
P3.0 Pin de recepción de la UART del microcontrolador.
P3.1 Pin de transmisión de la UART del microcontrolador.
Interrupción externa que activa la recepción en la
P3.3
UART implementada.

También son utilizados los dos pines provenientes del driver RS-485 de la CPU08,

que proporcionan las señales A y B del canal diferencial de transmisión y

recepción.
79

3.4.2 La UART implementada por software.

Los pines 3 y 5 del puerto 3 junto con el pin 3 del puerto 1 proporcionan la

funcionalidad de una UART adicional para la tarjeta CPU08, como fue requerido

para la aplicación propuesta.

Se hace uso de una interrupción externa para indicarle a la rutina de recepción la

llegada de un byte, y para iniciar el temporizador que genera la señal de reloj.

Cuando arriva el bit de inicio de un byte (nivel lógico 0) se genera la interrupción

externa 1, activa por flanco descendente, instante en el que se sincroniza el

temporizador TR0 el cual permanecerá activo hasta que termine la llegada de la

trama completa o se genere un timeout.

Según el protocolo MODBUS RTU, la separación máxima entre bytes dentro de

una misma trama de lectura o escritura es de 3.5 veces el período de reloj; en la

rutina de recepción se desarrolla esta verificación del tiempo de separación. En la

rutina de recepción también se realiza la verificación de los bits de inicio y de

parada para cada byte que llega.

La señal de reloj se establece al doble de la rata de baudios a la cual se realiza la

comunicación, para garantizar que cada uno de los bits son leídos en la mitad del

slot de tiempo y no cerca de los límites del slot donde podría generarse

inexactitudes en la lectura. Esto es bosquejado en el diagrama de la Figura 3.10.


80

Figura 3.10 Lectura de bits en la UART implementada

3.5 LA CPU08 COMO MAESTRO DE UNA RED DE CONTROLADORES

La tarjeta CPU08 debe programarse para que se comporte como maestro de una

red RS-485 de controladores 452 Plus, utilizando el protocolo de comunicación

codificado en ASCII que entienden esos dispositivos. Referirse a la sección 2.4.2

para una descripción detallada de dicho protocolo.

Para la aplicación a la que está destinada la CPU08, existen dos tipos de

mensajes distintos para comunicarse con los controladores 452 Plus, que se

presentan a continuación.
81

• Mensaje para leer una variable análoga:

<SYN>Dirección_del_controlador<STX>RA Dirección_de_la_variable<ETX>

• Mensaje para escribir en una variable análoga:

<SYN>Dirección_del_controlador<STX>SA Dirección_de_la_variable Dato<ETX>

3.5.1 Respuestas del controlador 452 Plus a solicitudes.

Los controladores 452 Plus responden a todas las tramas correctamente definidas

que reciben con un mensaje respuesta que consiste de una réplica exacta de la

solicitud seguida por ya sea el caracter <ACK> ó el caracter <NAK>; cuando se

da una respuesta de “no reconocimiento” <NAK>, la respuesta se acompaña con

un caracter de error. Los posibles caracteres de error se detallan en la tabla 3.2.

Tabla 3.2 Caracteres de error del controlador 452 Plus

Caracter Descripción Ejemplo*

1 Mensaje inválido RX 10

3 Posición inválida SA -10

* Estos son formatos de mensaje los cuales el controlador responderá con “no
reconocimiento” y el respectivo caracter de error.

Las solicitudes para establecer un valor en una posición de solo lectura son

ignorados silenciosamente.
82

Los mensajes de solicitud emitidos por la tarjeta CPU08 son respondidos por el

controlador 452 Plus de la manera siguiente:

• Respuesta a una solicitud de lectura:

<STX>RA Dirección_de_la_variable<ACK>Dato<ETX><CR><LF>

• Respuesta a una solicitud de escritura:

<STX>SA Dirección_de_la_variable Dato<ACK><ETX><CR><LF>

Hay que tener en cuenta que un valor análogo que se desee leer o escribir

consiste de un número con un punto decimal opcional, como por ejemplo 12.34 ó

3999; solamente 4 dígitos tienen significado para el controlador 452 Plus. Si el

valor es negativo, el dato es precedido del caracter de signo negativo.

La tarjeta CPU08 enviará un mensaje de solicitud y entonces esperará por la

respuesta. Sin embargo, es posible que el controlador 452 Plus no se encuentre

encendido, o no reciba el mensaje por alguna razón. Por tanto en el programa de

la CPU08 se establece un timeout cada vez que se envíe una trama al controlador,

para evitar que posiblemente se quede esperando eternamente. Si se completa en

timeout, la CPU08 armará una respuesta de excepción y la retornará al dispositivo

maestro.
83

3.5.2 Ejemplos de mensajes de lectura y escritura.

A continuación se presentan diversos ejemplos de solicitudes de lectura y escritura

para los controladores 452 Plus, al igual que las tramas reales que serán enviadas

a estos dispositivos.

• Leer la constante proporcional del controlador 452 Plus que tiene dirección 1.

En la Tabla 3.3 se observa la trama de solicitud.

Tabla 3.3 Ejemplo de trama de lectura del controlador 452 Plus

Posición del byte Caracter ASCII Valor en hexadecimal*


Byte 0 <SYN> 96
Byte 1 1 B1
Byte 2 <STX> 82
Byte 3 R D2
Byte 4 A 41
Byte 5 Espacio A0
Byte 6 7 B7
Byte 7 <ETX> 03
* Este valor además de representar al respectivo carácter ASCII, también coloca la
paridad del protocolo (paridad par).

• Establecer a 50 el setpoint del controlador 452 Plus que tiene la dirección 2. En

la Tabla 3.4 se observa la trama de solicitud.


84

Tabla 3.4 Ejemplo de trama de escritura del controlador 452 Plus

Posición de byte Caracter ASCII Valor en hexadecimal*


Byte 0 <SYN> 96
Byte 1 2 B2
Byte 2 <STX> 82
Byte 3 S 53
Byte 4 A 41
Byte 5 Espacio A0
Byte 6 2 B2
Byte 7 Espacio A0
Byte 8 5 35
Byte 9 0 30
Byte 10 <ETX> 03
* Este valor además de representar al respectivo carácter ASCII, también coloca la
paridad del protocolo (paridad par).

3.6 CONFIGURACION DEL PLC DL05 COMO ESCLAVO MODBUS

Para realizar la configuración del PLC DL05 como un esclavo MODBUS se han

utilizado las características que se aprecian en la Tabla 3.5.

Tabla 3.5 Variables de configuración del PLC DL05

Interfaz de comunicación RS-232


Puerto de comunicación Puerto 2
Dirección de esclavo 2
Rata de baudios 4800
Bits de datos 8
Paridad ninguna
85

La comunicación del PLC como dispositivo esclavo puede hacerse a través de

cualquiera de los dos puertos de comunicación, sin embargo se optó por utilizar el

puerto 2 porque es más flexible en los parámetros que se le pueden establecer.

Según la sección 2.3.5, el PLC DL05 se programa con DirectSOFT. En la Figura

3.11 se observa la ventana para la configuración del puerto 2, en DirectSOFT.

Figura 3.11 Configuración del puerto 2 en DirectSOFT

La comunicación con el PLC se establece con el protocolo MODBUS en modo

RTU. Los códigos de función MODBUS soportados por el PLC DL05,

determinan si el acceso es de lectura ó escritura, y si el acceso es a un punto

de datos simple ó a un grupo de ellos.


86

La Tabla 3.6 muestra las funciones MODBUS soportadas por el PLC DL05 al

igual que los tipos de datos que maneja.

Tabla 3.6 Funciones MODBUS soportadas por el PLC DL05

Código de función Tipo de datos en


Función
MODBUS el PLC DL05
01 Leer un grupo de salidas discretas. Y, CR, T, CT
02 Leer un grupo de entradas discretas. X, SP
05 Cambiar un dato discreto simple. Y, CR, T, CT
15 Cambiar un grupo de datos discretos. Y, CR, T, CT
03 Leer múltiples registros. V
04 Leer múltiples registros de entrada. V
06 Escribir un valor en un registro simple. V
16 Escribir en un grupo de registros. V

Para que puedan realizarse operaciones de escritura de registros ó de datos

discretos sobre el PLC a través del protocolo MODBUS RTU, el PLC debe

encontrarse en modo de operación TERM.

3.7 CONFIGURACION DE LOS CONTROLADORES 452 PLUS

Las variables de configuración de los controladores 452 Plus requeridas para

establecer la comunicación serial a través del puerto RS-485 son:


87

• Rata de baudios.

• Dirección de comunicaciones.

• Modo de comunicación ( modo CRL o VDU ).

• Nivel de protección de los datos.

Desde el panel frontal de los controladores 452 Plus se establecen los valores de

las variables de configuración, usando las funciones CS que se relacionan en la

Tabla 3.7.

Tabla 3.7 Configuración de los controladores 452 Plus

Función Valor Descripción


Dirección del controlador
CS_5 0, 1*
( 0 a 1F )
Rata de baudios
CS_6 3
( 0-300, 1-1200, 2-4800, 3-9600 )
Modo CRL/VDU y nivel de protección
CS_7** 1
( 0-VDU, 1-CRL )
* Un solo valor para cada controlador.
** Para mayor información sobre los diversos valores que puede tomar esta función,
revisar el manual del controlador.

Para la comunicación con los controladores 452 Plus se emplea el modo CRL (ver

sección 2.4), debido a que este modo facilita la comunicación con más de un

controlador, lo cual resulta apropiado para la implementación de la subred RS-485

dentro de la red Modbus/TCP.


88

3.7.1 Conexiones físicas.

La interfaz serial RS-485 de los controladores 452 Plus se presenta físicamente a

través de 4 pines que se detallan en la Tabla 3.8.

Tabla 3.8 Interfaz serial del controlador 452 Plus

Número de pin Señal


4 Tx -
3 Tx +
2 Rx +
1 Rx -

Las señales Tx- y Tx+ conforman el canal diferencial de transmisión y las señales

Rx- y Rx+ conforman el canal diferencial de recepción.

Para realizar la conexión entre la tarjeta CPU08 y la subred RS-485 de

controladores 452 Plus, se unen las señales Tx+ y Rx+ de cada uno de los

controladores con la línea A del driver RS-485 de la CPU08. Igualmente se unen

las señales Rx- y Tx- de cada uno de los controladores con la línea B del driver

RS-485 de la CPU08.
89

4. CONCLUSIONES

• Ante la incursión de la tecnología Ethernet en el área de los sistemas de

control de procesos y la automatización, para la interconexión a nivel de campo

de sensores, actuadores y controladores, han surgido diversos protocolos para

comunicación industrial sobre Ethernet. Sin embargo, una capa de aplicación

(según el modelo de referencia OSI) estándar con un modelo de objetos

común, no existe. Modbus/TCP es un estándar “de-facto” y está ampliamente

extendido y aceptado; Pero además existen otros tres protocolos para el

Ethernet industrial: EtherNet/IP (esencialmente objetos ControlNet y DeviceNet

sobre TCP/IP y UDP), ProfiNet (combina el protocolo Profibus, OLE para

control de procesos OPC y TCP/IP) y Fieldbus Foundation high-speed Ethernet

HSE (coloca el protocolo H1 de Foundation Fieldbus sobre TCP/IP y añade

OPC y el lenguaje XML).

• En una red de control distribuido, el protocolo Modbus/TCP puede ser usado

para comunicarse con una serie de controladores o PLCs distribuidos

alrededor de la planta. Esto permite a una sola persona supervisar

remotamente diversos procesos simultáneamente desde una posición única.


90

Además del monitoreo de variables (como la variable corriente del proceso),

los parámetros operativos individuales (como el setpoint) de los controladores

pueden ser cambiados para ajustar el proceso si es requerido.

• La plataforma TINI resultó conveniente y apropiada para el sistema propuesto,

ya que las aplicaciones desarrolladas en Java se ejecutaron eficientemente;

además, todo el proceso de programación y depuración de las aplicaciones se

desarrolló en un PC, para posteriormente transportar el código a la tarjeta,

agilizándose la creación de los programas.

• Con la implementación del protocolo MODBUS y Modbus/TCP en la tarjeta

CPU08 y la TINI respectivamente, se evidenció la facilidad y flexibilidad de este

protocolo y por ende la razón de su alta difusión en entornos industriales.

Además, se demostró la interoperabilidad de la red implementada, de forma

que desde clientes Modbus/TCP de diferentes fabricantes fue posible leer y

escribir registros y datos discretos sobre los diversos elementos que conforman

la red.

• En la red implementada se integraron los protocolos Modbus/TCP, MODBUS y

ASCII y los enlaces Ethernet, RS-232 y RS-485, demostrándose que sistemas

de control de procesos ya instalados pueden ser supervisados y controlados

desde una red TCP/IP (como Internet o la Intranet local) utilizando el estándar

Modbus/TCP.
91

• El monitoreo continuo de datos ó “streaming data” no es muy eficiente con el

protocolo Modbus/TCP, debido básicamente a la sobrecarga que impone el

protocolo de transporte TCP. La sobrecarga tiene que ver con el servicio de

entrega de datos confiable y el acuse de recibo para cada paquete transmitido,

incrementándose considerablemente el tráfico en la red cuando se monitorea

en todo momento un esclavo Modbus/TCP particular. La solución para la

supervisión de datos continuo sobre una red Ethernet es la utilización del

protocolo de transporte UDP.

• Como una proyección futura del presente trabajo sería interesante poder

integrarle a la tarjeta TINI el protocolo XML (eXtensible Markup Languaje), un

lenguaje de gran crecimiento que ya abarca muchos campos en servicios de

Web, y el cual ya incursionó en el área industrial para el intercambio de

información. Con la tarjeta TINI, básicamente este estándar se utilizaría para

que una base de datos con soporte XML (actualmente casi todas lo tienen) se

comunique con ella y acceda continuamente a la información proveniente de

los procesos. Esta información es almacenada en las tablas internas de la base

de datos, y de esa forma es posible llevar registros, históricos, tendencias,

gráficos, reportes, etc. del comportamiento de las variables que se requieran.

Actualmente, ya se encuentra en desarrollo un servidor de Web para la TINI

con soporte XML, y en código abierto.


92

• La interfaz gráfica de usuario para la supervisión y control de la red

Modbus/TCP desde Internet que se desarrolló como un applet de Java también

es posible enfocarla desde un punto de vista diferente: El mecanismo de

interacción entre al usuario en la Web y la plataforma TINI se puede realizar a

través de la utilización de Servlets de Java, los cuales residirían y se

ejecutarían sobre la TINI.


93

BIBLIOGRAFÍA

• COMER, Douglas E. Redes Globales de información con Internet y TCP/IP.

Prentice-Hall Hispanoamericana, S.A. México, 1997.

• DEITEL, H. M. y DEITEL, P. J.. Cómo programar en Java.

Prentice-Hall Hispanoamericana, S.A. México, 1998.

• GEARY, David M. Graphic Java 1.2: Mastering the JFC. Tercera edición.

The Sun Microsystem Press. U.S.A., 1999.

• LOOMIS, Don. “The TINI Specification and Developer`s Guide”.

Addison – Wesley, 2001.

• ESCOBAR, Angélica M. y SANCHEZ, Hugo A. Implementación de una Red

Inalámbrica usando el protocolo MODBUS.

Trabajo de grado, Universidad del Valle. Santiago de Cali, 2001.


94

Enlaces Electrónicos:

• http://www.modicon.com/openmbus

• http://www.ibutton.com/TINI

• http://www.modbus.org

• http://www.isa.org

• http://www.win-tech.com

• http://jmodbus.sourceforge.net
95

ANEXO # 1
Disposición física del montaje final

En la figura siguiente se aprecia la disposición física de tarjetas y cables del

montaje final de la red implementada.

• TARJETA # 1.

Esta tarjeta proporciona la interfaz entre las 4 señales RS-485 provenientes del

controlador 452 Plus y las dos señales RS-485 provenientes de la tarjeta

CPU08. Además en esta tarjeta se proporcionan las resistencias de acople

necesarias para el canal de transmisión y recepción RS-485. Esta tarjeta posee

un conector macho de 7 pines el cual se conecta con la CPU08 y posee dos

conectores DB25 machos.


96

• CABLE # 1. Enlace RS-485.

Este cable posee en un terminal un conector DIN de 5 pines que se conecta al

controlador 452 Plus y en el otro extremo posee un conector DB25 hembra que

se conecta a la tarjeta # 1. Todos los cables que conectan a los diferentes

controladores son de este mismo tipo. A continuación se presenta la

descripción de pines y de señales.

Conector DIN Conector DB25

Pin 1: No conectado

Pin 2: Tx- Pin 3: Señal B

Pin 3: Tx+ Pin 9: Señal A

Pin 4: Rx+ Pin 10: Señal A

Pin 5: Rx- Pin 2: Señal B

• CABLE # 2. Enlace RS-485.

Este cable posee en los dos terminales conectores de 14 pines para cable

ribbon. A continuación se presenta la descripción de pines y de señales.

Conector CPU08 Conector tarjeta #1

Pin 14: GND Pin 14: GND

Pin 12: Señal B Pin 12: Señal B

Pin 10: Señal A Pin 10: Señal A


97

• CABLE # 3. Enlace RS-232.

Este cable posee en los dos terminales conectores de 14 pines para cable

ribbon. A continuación se presenta la descripción de pines y de señales.

Conector TINI Conector CPU08

Pin 4: RxD Pin 4: TxD

Pin 10: GND Pin 10: GND

Pin 12: ------ Pin 12: Interrupción 1

Pin 13: TxD Pin 14: RxD

• CABLE # 4. Enlace RS-232.

Este cable posee en un terminal un conector RJ11 que se conecta al PLC DL05

y en el otro extremo posee un conector DB9 que se une con la tarjeta TINI. A

continuación se presenta la descripción de pines y de señales.

Conector DB9 Conector RJ11

Pin 2: RxD Pin 4: TxD

Pin 3: TxD Pin 3: RxD

Pin 5: GND Pin 1: GND

• CABLE # 5. Enlace Ethernet.

Este cable es el que nos da acceso a una red Ethernet. Posee en ambos
terminales conectores RJ45.