Modbus

IMPLEMENTACION DE UNA RED MODBUS/TCP
ANDRES FELIPE RUIZ OLAYA
UNIVERSIDAD DEL VALLE

FACULTAD DE INGENIERA
ESCUELA DE INGENIERA ELCTRICA Y ELECTRNICA
PROGRAMA DE INGENIERA ELECTRNICA
SANTIAGO DE CALI
2002
IMPLEMENTACION DE UNA RED MODBUS/TCP
ANDRES FELIPE RUIZ OLAYA
Trabajo de grado para optar por el ttulo de

INGENIERO ELECTRNICO
Directores
Ing. ASFUR BARANDICA LOPEZ
Ing. FABIO GERMAN GUERRERO, M. Sc.

ESCUELA DE INGENIERA ELCTRICA Y ELECTRNICA
PROGRAMA DE INGENIERA ELECTRNICA
SANTIAGO DE CALI
2002
RESUMEN
En este proyecto se desarrolla e implementa una red de instrumentacin y

control industrial con conectividad TCP/IP (como por ejemplo Internet), capaz
de ser supervisada y controlada remotamente a travs del protocolo
Modbus/TCP usando el sistema embebido TINI de Dallas Semiconductor.
Adems se desarrolla una interfaz de usuario grfica para acceso desde
Internet va Web .
Nota de Aprobacin
El
trabajo
de
grado
titulado
IMPLEMENTACIN
DE
UNA
RED
MODBUS/TCP, presentado por el estudiante ANDRES FELIPE RUIZ OLAYA,

para optar al ttulo de Ingeniero Electrnico 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 grandsima colaboracin en esta etapa final de la carrera y porque de ellos
aprend mucho.
A todas aquellas personas que me acompaaron a lo largo de la carrera y en la

culminacin de este trabajo de grado.
A mis compaeros, profesores y en general a la comunidad universitaria de

Univalle por la experiencia vivida en esta institucin.
CONTENIDO
Pag.
0. INTRODUCCIN
1. EL PROTOCOLO MODBUS/TCP
1.1 DESCRIPCIN
1.1.1 Orientado a conexin
1.1.2 Codificacin de datos
11
1.1.3 Interpretacin del modelo de datos
11
1.1.4 Filosofa 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
18
19
1.5.4 Comandos especficos de la mquina/red/vendedor
20
1.6 DESEMPEO REQUERIDO Y ESPERADO
21
1.7 GUIA DE IMPLEMENTACION DEL CLIENTE Y SERVIDOR
22
1.7.1 Diseo del Cliente
22
1.7.2 Diseo del Servidor
24
2. DESCRIPCION DEL HARDWARE
27
2.1 LA TARJETA TINI
27
2.1.1 Descripcin
28
2.1.2 Caractersticas
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
42
2.2.3 Programacin de la CPU08
43
2.3 EL PLC DL05 DE KOYO
44
2.3.1 Diagrama de bloques
44
45
2.3.3 Modos de operacin
45
2.3.4 Mapa de memoria
46
2.3.5 Comunicacin
47
2.3.6 Programacin
49
2.4 CONTROLADORES 452 PLUS
49
2.4.1 Definicin de caracteres especiales
50
2.4.2 Protocolo de Comunicacin
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 anlogas del controlador 452 Plus
52
3. DESCRIPCIN DEL SOFTWARE
53
3.1 DESARROLLO DE UN SERVIDOR MODBUS/TCP
54
3.1.1 Estructura de Clases
55
3.1.2 Descripcin de las Clases
56
3.1.3 Ejemplo de cdigo 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 IMPLEMENTACIN DE UN ESCLAVO MODBUS EN LA CPU08 73

3.4.1 Algoritmo de la aplicacin 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 fsicas
88
4. CONCLUSIONES
89
BIBLIOGRAFA
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
19
Tabla 1.5 Comandos Clase 2
19
Tabla 1.6 Funciones dependientes de la mquina
20
Tabla 2.1 Modos de operacin del PLC DL05
46
Tabla 2.2 Tipos de memoria del PLC DL05
47
Tabla 2.3 Caractersticas del puerto 1 del PLC DL05
48
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 configuracin del PLC DL05
84
Tabla 3.6 Funciones MODBUS soportadas por el PLC DL05
86
Tabla 3.7 Configuracin 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
Figura 1.2 Esquema de encapsulacin 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 cdigo para un servidor Web
64
Figura 3.5 Archivo HTML que carga la applet en un navegador Web
65
Figura 3.6 Cdigo 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 Configuracin del puerto 2 en DirectSOFT
85
Programa acadmico de pregrado de

INGENIERA ELECTRNICA
Ttulo: Implementacin de una red Modbus/TCP

Autor: Andrs Felipe Ruz Olaya
Directores: Ing. Fabio Germn Guerrero, M. Sc.
Ing. Asfur Barandica Lpez
Grupo de investigacin: Percepcin y Sistemas Inteligentes.
Area de investigacin: Comunicaciones Industriales.
Descriptores: Modbus, Modbus/TCP, Ethernet, TCP/IP, Java, Interfaz Web,
Instrumentacin, comunicaciones.
0. INTRODUCCION
En el rea de las comunicaciones en entornos industriales, la estandarizacin de

protocolos es un tema en permanente discusin, donde intervienen problemas
tcnicos y comerciales. Cada protocolo est optimizado para diferentes niveles de
automatizacin y en consecuencia responden al inters de diferentes proveedores.
Por ejemplo Fieldbus Foundation, Profibus y HART, estn diseados para
instrumentacin de control de procesos. En cambio DeviceNet y SDC estn
optimizados para los mercados de los dispositivos discretos (on-off) de detectores,
actuadores e interruptores, donde el tiempo de respuesta y repetibilidad
son
factores crticos1.
Cada protocolo tiene un rango de aplicacin; fuera del mismo disminuye el

rendimiento y aumenta la relacin costo/prestacin.
Tomado de Comunicaciones en entornos industriales, por Mario Distfano. Visitar la direccin

http://fing.uncu.edu.ar/investigacion/institutos/IAEI/Cursos2.htm
Debido a la no aceptacin de un protocolo estndar nico en las comunicaciones

industriales, los mltiples buses de campo han perdido terreno ante la incursin de
tecnologas de comunicacin emergentes como Ethernet en este rea.
La aceptacin mundial de Ethernet en los entornos administrativos y de oficina ha

generado el deseo de expandir su aplicacin a la planta. Ethernet se est
moviendo rpidamente hacia el mercado de los sistemas de control de procesos y
la automatizacin, para la interconexin 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 tecnologa emergente Fast
Ethernet se pueda aplicar tambin al manejo de aplicaciones crticas de control2.
Los buses de campo son una forma especial de LAN dedicada a aplicaciones de
adquisicin de datos y comando de elementos finales de control sobre la planta.
Los buses de campo tpicamente 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 diseadores optimizan los buses de campo para el
intercambio de mensajes cortos de comando y de control con altsima seguridad y
temporizacin estricta.
Tomado de Moving Ethernet to plant floors, por Sam Malizia. Visitar

http://www.isa.org/journals/ic/feature/1,1162,541,00.html
la direccin
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 mquinas y permitiendo interoperabilidad entre diversas plataformas. Usar
TCP/IP sobre Ethernet a nivel de campo en la industria permite tener una
verdadera integracin con la Intranet corporativa, y de esta forma se ejerce un
estricto control sobre la produccin3.
En este proyecto se pretende utilizar un estndar de instrumentacin sobre

Ethernet, Modbus/TCP4, para realizar la implementacin de una red de control
industrial capaz de ser accedida a travs 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 comunicacin con gran diversidad de elementos industriales; es
por eso que es de gran importancia trabajar sobre l, y adems debido a que en
nuestro medio no se encuentran desarrollos concernientes a este tema.
Arquitectura de la solucin
El siguiente diagrama ilustra la red Modbus/TCP implementada, al igual que los
enlaces y la interaccin que debe existir entre los diversos elementos que
componen el sistema :
Tomado de http://www.modbus.org/modbus_tcp_new.htm
El protocolo Modbus/TCP fue introducido por Schneider Automation. La especificacin se
encuentra disponible en http://www.modicon.com/openmbus.
Figura 1.1 Diagrama de la red implementada
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 informacin y adquirir el conocimiento necesario para implementar,

configurar, mantener y evaluar una red Modbus/TCP.
Objetivos especficos
Implementar en la tarjeta TINI un servidor Modbus/TCP,
el cual permita a
travs 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.
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
6
Para ms informacin de esta tarjeta, consultar la seccin 2.1.

Para ms informacin de esta tarjeta, consultar la seccin 2.2.
Implementar un esclavo MODBUS en la tarjeta TINI.
Desarrollar una interfaz de usuario grfica va Web, desde la cual sea posible
realizar operaciones remotamente de supervisin 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. Adems debe demostrarse la interoperabilidad de la red
probndola 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

estndar y se detalla la manera en que se lleva a cabo su implementacin. Aqu
tambin se presentan las ventajas del protocolo y las caractersticas que
proporciona para ser usado en comunicaciones industriales sobre Ethernet.
En la segunda parte Descripcin del hardware, se presenta en detalle las

caractersticas de cada uno de los elementos que conforman la red Modbus/TCP
implementada y el papel que desempean en el sistema completo. Se realiza una
exposicin 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 Descripcin del software, se describe la forma en que se

desarrollaron los programas y aplicaciones que corren sobre los diversos
elementos de la red, adems se explica la funcionalidad que brindan y la
interaccin 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.
1. EL PROTOCOLO MODBUS/TCP7
1.1 DESCRIPCION
Modbus/TCP es un protocolo de comunicacin diseado para permitir a equipo

industrial tal como Controladores Lgicos Programables (PLCs), computadores,
motores, sensores, y otros tipos de dispositivos fsicos 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 comunicacin simples y abiertos, destinados para la supervisin y el
control de equipo de automatizacin. Especficamente, el protocolo cubre el uso
de mensajes MODBUS en un entorno Intranet o Internet usando los protocolos
TCP/IP8.
7
8
Parte de esta seccin es tomado de la especificacin en http://www.modicon.com/openmbus

Tomado de http://www.modbus.org
La especificacin Modbus/TCP define un estndar interoperable en el campo de la

automatizacin industrial, el cual es simple de implementar para cualquier
dispositivo que soporta sockets9 TCP/IP.
1.1.1 Orientado a conexin.
MODBUS es un protocolo de comunicacin 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 adems
requiriendo mnima informacin de recuperacin para ser mantenida la transaccin
en cualquiera de los dos terminales .
Las operaciones de programacin de otro lado, esperan una comunicacin

orientada a la conexin, es decir, las mquinas 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).
Un socket es una abstraccin proporcionada por el sistema operativo que permite a un programa
de aplicacin accesar los protocolos TCP/IP.
10
Modbus/TCP
maneja
ambas
situaciones.
Una
conexin
es
inicialmente
establecida en esta capa de protocolo (nivel de aplicacin), y esa conexin nica

puede llevar mltiples transacciones independientes.
En adicin, TCP permite establecer un gran nmero de conexiones concurrentes,

de este modo el cliente (maestro) puede
ya sea re-usar una conexin
previamente establecida crear una nueva, en el momento de realizar una

transaccin de datos.
Es interesante analizar porqu el protocolo TCP orientado a la conexin es usado

en lugar del protocolo UDP10 orientado a datagramas. La principal razn es
mantener control de una transaccin individual encerrndola en una conexin la
cual pueda ser identificada, supervisada, y cancelada sin requerir accin
especfica de parte de las aplicaciones cliente y servidor. Esto da al mecanismo
una amplia tolerancia a cambios del desempeo de la red, y permite que
herramientas de seguridad tal como firewalls11 y proxies puedan ser fcilmente
aadidos.
10
El UDP (User Datagram Protocol) proporciona un servicio de entrega sin conexin, utilizando el
IP para transportar mensajes entre mquinas. Emplea el IP para llevar mensajes, pero agrega la
capacidad para distinguir entre varios destinos dentro de una mquina host.
11
Un firewall (muro de seguridad) se le dice a una configuracin de ruteadores y redes colocados
entre la organizacin interna de una red y su conexin con redes externas a fin de dar seguridad.
11
1.1.2 Codificacin de datos.
MODBUS usa una representacin big-endian12 para direcciones y datos. Esto

significa que cuando una cantidad numrica ms grande que un byte es
transmitido, el byte ms significante es enviado primero. As, por ejemplo:
0x1234
ser
0x12 0x34
1.1.3 Interpretacin del modelo de datos.
MODBUS basa su modelo de datos sobre una serie de tablas las cuales tienen
caractersticas 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 aplicacin, 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

aplicacin, de lectura-escritura.
12
Big-endian es un formato en el cual el byte ms significativo se encuentra primero.
12
La distincin entre entradas y salidas, y entre datos direccionables al bit y

direccionables a la palabra, no implica algn comportamiento de la aplicacin. Es
aceptable y comn, considerar las cuatro tablas sobrelapando una con otra, si esta
es la interpretacin ms natural sobre la mquina (esclavo MODBUS) en cuestin.
1.1.4 Filosofa de longitud implicada.
Todas las solicitudes y respuestas MODBUS estn diseadas en tal forma que el
receptor puede verificar que un mensaje est completo. Para cdigos de funcin
donde la solicitud y respuesta son una longitud fija, el cdigo de funcin solo es
suficiente. Para cdigos de funcin llevando una cantidad variable de datos en la
solicitud respuesta, la porcin de datos estar precedida por un campo que
representa el nmero de bytes que siguen.
Cuando MODBUS es llevado sobre TCP informacin de longitud se adiciona en el

prefijo (o encabezado) para permitir al receptor reconocer los lmites del mensaje,
igual si el mensaje ha sido dividido en mltiples paquetes para la transmisin. La
existencia de reglas de longitud implcitas o explcitas, y el uso de un cdigo de
chequeo de error CRC-3213 (sobre Ethernet) resulta en una probabilidad muy
pequea de corrupcin no detectada sobre un mensaje de solicitud o respuesta.
13
CRC (Cyclic Redundancy Code), verificacin por redundancia cclica.
13
1.2 VENTAJAS DEL PROTOCOLO MODBUS/TCP
Es escalable en complejidad. Un dispositivo el cual tiene solo un propsito

simple necesita solo implementar uno dos tipos de mensaje.
Es simple para administrar y expandir. No se requiere usar herramientas de

configuracin complejas cuando se aade una nueva estacin a una red
Modbus/TCP.
No es necesario equipo o software propietario de algn 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 conversin los cuales no requieren
configuracin.
Es de muy alto desempeo, limitado tpicamente por la capacidad del sistema

operativo del computador para comunicarse. Altas ratas de transmisin son
fciles de lograr sobre una estacin 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 continuacin se describe la forma general de encapsulacin 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 cdigo de
funcin hasta el fin de la porcin de datos, tiene exactamente la misma disposicin
y significado como en las otras variantes MODBUS, tal como:
MODBUS serial codificacin ASCII

MODBUS serial codificacin RTU
MODBUS PLUS
Las nicas diferencias en esos otros casos son la especificacin de los
delimitadores inicial y final del mensaje14, el patrn de chequeo de error y la
interpretacin de la direccin.
Todas las solicitudes son enviadas va TCP sobre el puerto registrado 502. Las
solicitudes normalmente son enviadas en forma half-duplex15 sobre una conexin
dada. Es decir, no hay beneficio en enviar solicitudes adicionales sobre una nica
conexin mientras una respuesta est pendiente. Sin embargo, los dispositivos
14
15
En MODBUS esto se denomina Framing.

En half-duplex los datos pueden viajar en cualquier direccin, pero no en forma simultnea.
15
que desean obtener altas ratas de transferencia pueden establecer mltiples

conexiones TCP al mismo destino.
El campo direccin esclavo de MODBUS es reemplazado por un byte

identificador de unidad el cual puede ser usado para comunicar a travs de
dispositivos tales como puentes y gateways, los cuales usan una direccin IP
nica para soportar mltiples 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 transaccin, un
nmero 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 simultneamente mltiples 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

nmero el cual debe ser establecido a cero.
16
El len especifica el nmero 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 ms
pequeos 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

Posicin del Byte
Significado
Byte 0
Identificador de transaccin. Copiado

por el servidor normalmente 0.
Byte 1
Identificador de transaccin. 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). Nmero

de bytes siguientes.
Byte 6
Identificador de unidad (previamente

direccin esclavo).
Byte 7
Byte 8 y ms
Cdigo de funcin MODBUS.

Los datos necesarios.
17
1.4 ESQUEMA DE ENCAPSULACION
Modbus/TCP bsicamente 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 encapsulacin en Modbus/TCP
1.5 CONFORMACION DE CLASES
MODBUS por su naturaleza es ya implementada en muchsimos lugares, por tanto

una ruptura de las implementaciones existentes debe ser evitada.
De esta forma el conjunto de los tipos de transaccin 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 tambin identificadas.
18
Debe anotarse que futuras extensiones al estndar pueden definir cdigos de

funcin adicionales para manejar situaciones donde el estndar existente es
deficiente.
1.5.1 Comandos Clase 0.
Este es el mnimo conjunto til de funciones, tanto para el maestro como para el
esclavo.

Cdigo
Funcin
03
Leer mltiples registros holding16.
16
Escribir mltiples registros holding.
Este es el conjunto adicional de funciones, el cual es comnmente 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 posicin interna de la memoria.
19
Cdigo

Funcin
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 excepcin*.
* Esta funcin tpicamente tiene un significado diferente para cada familia de esclavos.
Estas son las funciones de transferencia de datos necesarias para operaciones de

rutina tal como supervisin y HMI17.
Cdigo
Tabla 1.5 Comandos Clase 2

Funcin
15
Fijar mltiples salidas discretas.
20
Leer referencia general*.
21
Escribir referencia general*.
22
Enmascarar registro de escritura.
23
Leer/escribir registros**.
24
Leer cola FIFO***.
* Esta funcin ser la ms apropiada para manejar grandes espacios de registros y

datos, los cuales carecen de nmeros de referencia.
** Esta funcin permite la entrada y salida de un rango de registros como una
transaccin nica. Es la forma ms eficiente usando MODBUS para
desempear un
intercambio regular de datos tal como con un mdulo I/O.
*** Una funcin 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 especficos de la mquina/red/vendedor
Todas de las siguientes funciones, aunque mencionadas en los manuales del

protocolo MODBUS, no son apropiadas para propsitos de interoperabilidad
porque ellas son dependientes de la mquina.
Tabla 1.6 Funciones dependientes de la mquina

Cdigo
Funcin
08
Pruebas de diagnstico.
09
Programacin*.
10
Completar la programacin*.
11
Leer la palabra de estado del contador de eventos.
12
Leer el registro de eventos de comunicacin.
13
Programacin**.
14
Completar la programacin**.
17
Reportar ID del esclavo.
18
Programacin***.
19
Reinicializar enlace de comunicaciones***.
125
Sustitucin de firmware.
126
Programacin**.
127
Reportar direccin 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 DESEMPEO REQUERIDO Y ESPERADO
No existe una especificacin precisa acerca del tiempo de respuesta requerida

para una transaccin sobre MODBUS Modbus/TCP.
Esto es debido a que se espera que Modbus/TCP sea usado en la ms amplia

variedad posible de situaciones de comunicacin, desde sistemas I/O esperando
temporizacin en milisegundos, a enlaces de radio de larga distancia con retardos
de varios segundos.
En general, los dispositivos tales como PLCs respondern a solicitudes

ingresantes en un tiempo scan18, el cual tpicamente vara entre 20 y 200 msg.
Desde la perspectiva del cliente, ese tiempo de respuesta debe ser extendido por
los retardos de transporte travs 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 conexin de red de rea amplia (WAN).
Cualquier tiempo timeout19 usado en un cliente debe ser ms grande que el

mximo tiempo de respuesta razonable, para as evitar una excesiva congestin
en el dispositivo servidor en la red, lo cual puede causar errores.
18
19
Un tiempo scan, es el tiempo requerido para que el PLC complete sus instrucciones programadas.
Un timeout es un tiempo que se establece antes de que se reporte un fallo.
22
As en la prctica, los timeouts usados en aplicaciones cliente de alto desempeo

sern probablemente algo dependientes sobre la topologa de la red y el
desempeo esperado del servidor. Aplicaciones cliente las cuales no son crticas
en tiempo pueden con frecuencia dejar los valores timeout al establecido por
defecto en TCP, el cual reportar fallo en la comunicacin despus 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 ms 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 seccin no ser considerado obligatorio para la

implementacin particular de un cliente servidor. Sin embargo, si son seguidas,
estas polticas facilitarn la integracin cuando se implementen sistemas multivendedor y gateways a equipo MODBUS ya instalado.
1.7.1 Diseo del Cliente.
Modbus/TCP est diseado para permitir que el diseo de un cliente sea tan
simple como sea posible. El proceso bsico de manejo de una transaccin es
como sigue:
23
Establecer una conexin 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 conexin TCP.

Opcionalmente correr un timeout, si se desea ser avisado de problemas de
comunicacin ms rpido 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 comunicacin adicional al destino particular en el futuro

inmediato, cerrar la conexin 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 perodo mximo para dejar una conexin abierta
en el cliente.
20
Un puerto de protocolo es una abstraccin que los protocolos de transporte del TCP/IP utilizan para
distinguir entre varios destinos en una computadora host especfica.
24
En el evento que expire el timeout para una respuesta, realizar un cierre unilateral
de la conexin, abrir una nueva, y re-enviar la solicitud. Esta tcnica permite al
cliente control sobre la temporizacin de re-intentos, el cual es superior al
suministrado por defecto por TCP. Tambin permite el uso de estrategias alternas,
tal como enviar la solicitud a una direccin IP alterna, usando una red de
comunicacin totalmente independiente, en caso de fallo de un componente de la
infraestructura de la red.
1.7.1 Diseo del Servidor.
Un servidor Modbus/TCP siempre ser diseado para soportar mltiples clientes

concurrentes, sin importar que en su uso previsto solo un nico cliente parezca
tener sentido. Esto permite al cliente cerrar y reabrir la conexin a fin de responder
rpidamente 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 tamao de los buffers de
transmisin y recepcin. Un servicio TCP normal usualmente asignar 8K bytes
ms como un buffer de recepcin por conexin. Tal espacio de buffer no tiene
valor en Modbus/TCP, ya que el tamao mximo 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 mltiples threads

(hilos de control), tal como Java, pueden usar la estrategia multithreaded, descrita
a continuacin :
1. Esperar conexiones entrantes sobre el puerto 502 de TCP.
2. Cuando una nueva solicitud de conexin sea recibida, aceptarla y crear un

nuevo thread para manejar la conexin.
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
conexin
sea
cerrada.
Ambas
situaciones
despertarn
al
thread
automticamente.
Analizar el encabezado. Si aparece corrupto, por ejemplo si el campo de

protocolo no es cero la longitud del mensaje es ms grande que 256,
entonces cerrar unilateralmente la conexin. Esta es la respuesta correcta de
un servidor a una situacin donde la codificacin 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 vlido un mensaje de
excepcin para usar como una respuesta.
Generar el prefijo Modbus/TCP para la respuesta, copiando el campo

identificador de transaccin desde la solicitud, y recalculando el campo de
longitud.
Enviar la respuesta, incluyendo el prefijo Modbus/TCP como un buffer nico

para transmisin sobre la conexin establecida.
De nuevo volver a esperar el prximo prefijo de 6 bytes, y repetir el

procedimiento.
Eventualmente, cuando el cliente elija cerrar la conexin, la recepcin del prefijo

de 6 bytes fallar. En este caso se cierra la conexin 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 continuacin 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 desarrollarn 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 Descripcin.
La Tiny InterNet Interface (TINI) es una plataforma desarrollada por Dallas

Semiconductor que suministra un medio simple, flexible y econmico para disear
una extensa variedad de dispositivos hardware capaces de conectarse
directamente a redes corporativas y locales. Las caractersticas de la plataforma
son expuestas al desarrollador de software a travs de un set de interfaces de
programacin de aplicaciones (APIs) en Java, brindando un poderoso entorno de
programacin orientado a objetos y facultando al programador en la creacin 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 interaccin con sistemas remotos y usuarios a travs de aplicaciones de red
estndar, tal como browsers Web.
2.1.2 Caractersticas.
La TINI es una tarjeta SIMM (31.8mm x 102.9mm) de 72 pines. Es una

implementacin hardware con Ethernet y soporta toda la funcionalidad
suministrada por cualquier sistema embebido. La tarjeta incluye las siguientes
caractersticas:
29
512 Kilobytes de memoria flash para cdigo del sistema crtico.
512 Kilobytes de memoria SRAM no-voltil, 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 expansin

paralela.
Requiere una fuente de alimentacin 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 diseada 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,
tambin est incursionando en el hogar y en entornos educativos. La TINI puede
ser usada para tareas embebidas tradicionales stand-alone, pero la mayora de
aplicaciones utilizan las capacidades de interconectividad de la tarjeta. Unas
pocas aplicaciones de la tecnologa TINI incluyen las siguientes:
30
Monitoreo y control de equipo basado en Web. La TINI puede ser usada para
establecer comunicacin con equipos especficos, para proveer recoleccin de
datos y diagnstico remoto para propsitos tales como el monitoreo sobre la
utilizacin de un dispositivo particular.
Conversin 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 fraccin del costo y del tamao.
Sistemas de medicin remota. Es posible construir aplicaciones para medicin

distribuidas en una red. La TINI estara equipada con dispositivos de medicin
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 automatizacin de equipo.
Monitores ambientales. Usando el soporte construido en la TINI de

interconexin 1-Wire, una aplicacin 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, quizs algn tipo de interfaz paralela.
La aplicacin Java corriendo sobre la TINI desempea la tarea de comunicacin

con el dispositivo en su lenguaje nativo (usando un protocolo de comunicacin
especfico del dispositivo) y presenta los resultados a sistemas remotos
alcanzables a travs 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 esttica.
El corazn 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 tambin provee distintos
pines de propsito general que pueden ser usados para desempear tareas de
control simples tales como manejar rels 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 esttica contiene el rea de datos, la pila (heap), al igual que los
archivos de datos del sistema. La SRAM es no-voltil, ya que posee una circuitera
con batera de respaldo de forma que el contenido de la memoria persiste en
ausencia de alimentacin. La batera es una muy pequea celda de litio.
Otros dispositivos perifricos, aparte de la memoria, pueden tambin ser

interfazados directamente a los buses de datos y direcciones del microcontrolador
(denominada expansin I/O paralela en la Figura 2.2). Dos de tales perifricos
usados en el sistema TINI son un controlador Ethernet y un reloj en tiempo real.
Esta configuracin extiende el alcance de los dispositivos embebidos a redes
Ethernet y provee una referencia exacta de tiempo para propsitos especficos.
La batera de respaldo tambin mantiene corriendo el reloj en ausencia de

potencia, asegurando que un tiempo exacto es siempre ledo desde el reloj.
22
El entorno runtime esta compuesto por el sistema operativo y la Mquina Virtual Java (JVM).
34
2.1.5 Mapa de memoria del sistema.
Un mapa de memoria especifica dnde la memoria y otros dispositivos perifricos

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 cdigo.
Segmento de datos.
Segmento de perifricos.
Figura 2.3 Mapa de memoria de la TINI
35
La figura ilustra los mximos tamaos de segmento soportados por la TINI. La

direccin de inicio del segmento es siempre constante, mientras la direccin final
puede variar de acuerdo al tamao 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 diseadores deben evitar los rangos del controlador Ethernet y el reloj, cuando
se adicionen otros dispositivos perifricos.
Existe tambin un rea perifrica 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 mayora de hardware es mapeado en el segmento perifrico

porque el microcontrolador puede accesarlo ms eficientemente.
36
2.1.6 Sistema I/O integrado.
Un amplio rango de dispositivos no soportan la interfaz a un bus perifrico.

Frecuentemente esos dispositivos tienen alguna forma de interfaz serial. Un
soporte para los siguientes protocolos de comunicacin serial han sido integrados
dentro del microcontrolador.
Comunicacin serial. Son soportados protocolos seriales sncronos, utilizando

una interfaz de 2 alambres, y comunicacin serial asncrona, basada en el
estndar RS-232. El microcontrolador de la TINI provee dos circuitos UART
(Universal Asynchronous Receiver Transmitter) integrados, que facilitan la
comunicacin.
Bus CAN. Originalmente desarrollado en Bosch-Siemens, CAN est ahora

descrito en dos estndares ISO. CAN suministra un bus de comunicaciones
serial confiable que es comnmente 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 pequeos sensores, actuadores, y elementos de memoria en que todos
comparten el mismo conductor tanto para comunicacin como para potencia.
37
I/O TTL. Los pines de propsito general del puerto del microcontrolador pueden
ser usados para diversas tareas de control y no estn necesariamente atados a
algn tipo de dispositivo serial.
La utilizacin de las capacidades I/O integradas en el microcontrolador en lugar de

I/O mapeada en memoria, reduce el costo de la comunicacin con un dispositivo
externo porque se libera a la CPU de operaciones de lectura y escritura de datos
a un dispositivo perifrico.
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 tambin suministrado con la TINI para liberar a
los desarrolladores de aplicacin de tener que preocuparse acerca de los detalles
de la creacin de capas de infraestructura que den soporte para la ejecucin de
tareas mltiples, pilas de protocolos de red e interfaces de programacin de
aplicaciones.
Un
entorno
bien
definido que
suministre
todas
de
esas
caractersticas permite al desarrollador enfocarse principalmente sobre los detalles

de la aplicacin. De esta forma, un entorno runtime fue desarrollado como parte
integral de la plataforma TINI. Una representacin grfica 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
categoras: un sistema operativo el cual es ejecutado directamente por el
microcontrolador y un API interpretado como bytecodes por la Mquina Virtual de
Java (JVM).
El cdigo 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 programacin 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 tambin libreras nativas que pueden ser cargadas desde una
aplicacin para lograr requerimientos estrictos de tiempo real.
2.1.8 Sistema operativo de la TINI.
El sistema operativo de la TINI es la capa ms baja del entorno runtime. Es

responsable de la administracin de todos los recursos del sistema incluyendo el
acceso a la memoria, planificacin de procesos mltiples y threads de ejecucin, y
la interaccin con componentes hardware internos y externos. A excepcin 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 automticamente
recupera la memoria dinmicamente repartida que ya no se necesita, liberando a los programadores
de incluir enunciados en los programas para ejecutar esta accin.
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 ms grandes
y es suficientemente rica en funcionalidad para soportar una implementacin
completa del paquete java.net. La pila de protocolo soporta mltiples interfaces de
red, incluyendo Ethernet, para interconexin de alta velocidad en rea local, y PPP
(Point-to-Point Protocol) sobre un enlace serial para interconexin remota usando
modem.
2.1.9 El Socket E10.
El Socket E10 es una tarjeta de 160mm x 120mm, cuya funcin principal es

proveer los conectores fsicos para interfazar la TINI a Ethernet, dispositivos
seriales, alimentacin. La tarjeta Socket E10 est destinada a ayudar en el
proceso de desarrollo de aplicaciones y suministra los siguientes conectores
fsicos:
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 conexin a un puerto serial DTE (Data
Terminal Equipment) estndar. Este puerto es tpicamente usado slo para
cargar el software a la memoria flash de la TINI.
41
Conector DB9 macho. Este conector provee un puerto serial DTE para
conexin 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 estndar 10Base-T

suministrando conectividad a una red Ethernet.
Conector RJ11. El conector RJ11 provee acceso a la red 1-Wire usando cable
telefnico estndar.
Jack de potencia. El Socket E10 acepta una fuente de alimentacin de 5V DC.
El Socket E10 tambin suministra el espacio respectivo para circuitos integrados y

componentes discretos para soportar opciones adicionales de I/O tales como
expansin 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.
Segn el diagrama de la
Figura 1.1, en esta tarjeta se debe implementar algunas funciones MODBUS

apropiadas para comportarse como un esclavo, y adems debe manejar una red
RS-485 de controladores a travs 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
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 travs de optoacopladores).
Puerto serial RS-232 / RS-485.
43
Puerto sncrono SPI.
2 interrupciones externas.
Voltaje de alimentacin regulado de +5V.
Presenta conectores para expandir las funciones del sistema.
Adems, se proporciona un programa bootloader residente en la memoria flash

que carga el programa de aplicacin en la RAM externa para propsitos de
desarrollo y depuracin, de forma que la aplicacin pueda ser fcilmente
modificada.
2.2.3 Programacin de la CPU08.
La tarjeta CPU08 se programa directamente en el lenguaje propio del

microcontrolador AT89C52. Opcionalmente, es posible realizar la programacin en
lenguaje C y utilizar un compilador cruzado que traslade el cdigo fuente C al
lenguaje del microcontrolador. La utilizacin del lenguaje C para realizar la
programacin depende de los requerimientos de desempeo y tamao de cdigo
que se necesiten satisfacer.
En este proyecto, la programacin 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 caractersticas 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 funcin HSIO (High-Speed I/O) que proporciona este PLC, consiste de

hardware dedicado pero configurable en el DL05. Para ms informacin sobre su
operacin consultar el manual del PLC.
8 entradas DC de alta velocidad.
6 salidas rel.
Conjunto de 129 instrucciones para programacin.
Memoria de programa de 2K bytes.
Memoria de datos de 4K bytes.
2 puertos de comunicacin RS-232.
Soporta los protocolos DeviceNet y MODBUS.
Algoritmos PID integrados, con lazo auto-tunning.
Mdulos opcionales de entrada / salida anlogos.
2.3.3 Modos de operacin.
El PLC DL05 posee tres modos de operacin: modo TERM, modo RUN y modo
STOP. En la Tabla 2.1 se describen los tres modos de operacin del PLC.
46
Tabla 2.1 Modos de operacin del PLC DL05

Modo
Descripcin
(Terminal). Estn disponibles los modos de depuracin,
programacin y ejecucin. Los diferentes modos y los
TERM
cambios en la programacin pueden ser conmutados a
travs del software de programacin.
(Ejecucin del Programa). La CPU es forzada dentro
RUN
del modo de ejecucin 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 categoras :
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 aplicacin MODBUS.
47
Tabla 2.2 Tipos de memoria del PLC DL05

Tipo de memoria
Cantidad
Rango PLC
del PLC
(decimal)
(octal)
Rango en
Modbus
Tipo de dato
Modbus
(decimal)
Datos discretos
Entradas (X)
256
X0 X377
2048 - 2303
Entrada
Rels especiales
512
SP0 SP777
3072 3583
Entrada
Salidas (Y)
256
Y0 Y377
2048 2303
Salida
Rels 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
Valor actual del timer 128
V0 V177
0 127
Registro
Palabras de memoria
(V)
Valor
de
entrada
actual
del 128
V1000 V1177
512 - 639
contador (V)
Memoria V, dato de 3168
(V)
de
entrada
V1200 V7377
640 3809
usuario (V)
Memoria V, no voltil 128
Registro
Registro
de
retencin
V7600 V7777
3968 - 4095
Registro
de
retencin
2.3.5 Comunicacin.
El PLC DL05 posee dos puertos de comunicacin RS-232. Las caractersticas de

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

Paquete de programacin
DirectSOFT.
Rata de baudios
9600 bps (fijos).
Bits de inicio
Bits de datos
Paridad
Impar (por defecto), par, ninguna
Bits de parada
Comunicacin
Asncrona, half duplex con el DTE.
Protocolos soportados
Direccin del dispositivo
K-sequence, DirectNET y MODBUS

RTU, todos como esclavos.
1 (fija)

Paquete de programacin
Rata de baudios
DirectSOFT.
300, 600, 1200, 2400, 4800, 9600,
19200 y 38400.
Bits de inicio
Bits de datos
Paridad
Impar (por defecto), par, ninguna.
Bits de parada
Comunicacin
Asncrona, half duplex con el DTE.

K-sequence, DirectNET, MODBUS RTU
Protocolos soportados
(maestro o esclavo) y Non-sequence

(para impresin).
Direccin del dispositivo
1 a 247.
49
2.3.6 Programacin.
El PLC DL05 posee dos mtodos de programacin: RLL (Relay Ladder Logic) y
RLL PLUS (PLUS PROGRAMMING). El PLC puede ser programado con un
paquete de programacin avanzado, DirectSOFT, un software basado en
Windows que soporta las caractersticas ms 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 automatizacin de procesos. La configuracin
de los parmetros del controlador (setpoint, cte. Proporcional, cte. Derivativa, etc.)
pueden ser establecidos localmente a travs del panel frontal, remotamente a
travs de una interfaz serial RS-232, RS-423A, RS-422A, RS-485.
La comunicacin remota con el controlador se desarrolla serialmente usando un

protocolo asncrono 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 Definicin de caracteres especiales.
Los controladores 452 Plus establecen para la comunicacin un conjunto de

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

Carcter
Cdigo
especial
hexadecimal
< STX >
02
Caracter de inicio de trama.
< ETX>
03
Caracter de fin de trama.
< EOT>
04
Caracter de fin de transmisin.
< ACK >
06
Caracter de reconocimiento.
< LF >
0A
Caracter de nueva lnea.
< CR >
0D
Caracter de retorno.
< NAK >
15
Caracter de no reconocimiento.
< SYN >
16
Caracter de sincronizacin.
< ESC >
1B
Caracter de borrado de lnea.
< DEL >
7F
Caracter de borrado de carcter.
Descripcin
2.4.2 Protocolo de Comunicacin.
El protocolo de comunicacin est definido en dos capas niveles; la primera

define el wrapping del mensaje (la delimitacin 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 comunicacin que se desea establecer. Dos

modos de comunicacin son ofrecidos: el modo VDU (Visual Display Unit) y el
modo CRL (Control).
El modo VDU est definido para comunicacin 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 comunicacin entre un computador y mltiples

controladores. Este modo es ms complejo, ya que primero se debe especificar
cual controlador se desea direccionar. La direccin es precedida por un caracter
especial <SYN> que indica al dispositivo receptor que el prximo caracter es
interpretado como la direccin.
En modo CRL los mensajes individuales estn 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 anloga, establecer una
variable lgica, leer un valor anlogo, leer un valor lgico, al igual que lectura de
un bloque de valores anlogos lgicos.
52
Tabla 2.6 Tipos de mensaje del controlador 452 Plus

Tipo de mensaje
Descripcin
RA
Leer variable anloga.
RL
Leer variable lgica.
SA
Escribir en localizacin anloga.
SL
Escribir en localizacin lgica.
DA
Leer 10 posiciones anlogas desde la posicin de inicio.
DL
Leer 10 posiciones lgicas desde la posicin de inicio.
2.4.3 Contenido de posiciones anlogas del controlador 452 Plus.
En la Tabla 2.7 se relacionan algunas de las posiciones anlogas propias de los

controladores 452 Plus.
Tabla 2.7 Posiciones de memoria del controlador 452 Plus

Posicin anloga
Descripcin
Tipo de instrumento (slo lectura).
Valor medido (slo lectura).
Setpoint.
Potencia de salida (0 100 %).
Banda proporcional (%)(0 - 500.0).
Trmino integral (minutos)(0 200.0).
Trmino derivativo (segundos)(0 4000).
53
3. DESCRIPCIN 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 grfica para acceso va Web.
4. Implementacin de un esclavo MODBUS en la tarjeta CPU08.
5. Programacin de la tarjeta CPU08 como maestro de una red RS-485 de
controladores.
6. Configuracin del PLC DL05 como un esclavo MODBUS.
7. Configuracin de los controladores 452 Plus.
En las siguientes secciones se describe detalladamente cada uno de los

componentes software y la interaccin que existe entre los mismos; adems se
presenta cdigo 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 peticin desde la red, ejecuta una accin basado en
la peticin y devuelve el resultado al solicitante; un programa se convierte en
cliente cuando enva una peticin 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, basndose en las indicaciones establecidas en la gua de
implementacin descrita en la seccin 1.7.1.
La implementacin del servidor hace uso de la programacin orientada a objetos y

el multithread para aceptar solicitudes concurrentes. La estructura de clases y
parte de la implementacin est basada en el proyecto jmodbus.24
24
Disponible en Internet en http://jmodbus.sourceforge.net
55
El objetivo del proyecto jmodbus es proveer libreras Java para permitir a

dispositivos basados en este lenguaje comunicarse como maestros esclavos a
travs de ModbusRTU, ModbusASCII ModbusTCP. El cdigo es abierto y est
diseado 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 especficas 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 Descripcin de las Clases.
La aplicacin 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 cdigo 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 desempeado por los mtodos en la
clase ModbusMaster.
Clase ModbusRTUTransport. Clase para implementar un mecanismo de

transporte RTU para comunicacin MODBUS. Esta clase permite a un
dispositivo comunicarse serialmente, usando codificacin 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 cdigo que es requerido para la recepcin y el procesamiento de
solicitudes. Esta clase tambin 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 recepcin y el
procesamiento de solicitudes es desempeado por los mtodos de la clase
ModbusSlave.
Clase ModbusTCPTransport. Clase para implementar un mecanismo de

transporte TCP para la comunicacin MODBUS. Esta clase permite a cualquier
dispositivo comunicarse va Modbus/TCP. Esta clase debe implementar los
mtodos 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 aplicacin principal que se mantiene

esperando por solicitudes de conexin al puerto 502 de TCP, el puerto
registrado de Modbus/TCP, y cuando arriva una peticin crea un nuevo hilo
que procesa la transaccin, mientras la aplicacin contina 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, delimitacin y codificacin
de tramas MODBUS desde el medio de transporte y el envo y recepcin real
de los datos.
La aplicacin desarrollada se comporta como un servidor ( esclavo)

Modbus/TCP, pero tambin acta como un gateway de forma que es capaz de
direccionar solicitudes MODBUS destinados a otros esclavos a travs de
MODBUS RTU.
3.1.3 Ejemplo de cdigo fuente.
En esta seccin se describen algunos apartes importantes del cdigo fuente de la

aplicacin 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 porcin del cdigo de la clase ServidorModbusTCP, la cual fue
explicada en la seccin anterior.
60
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
import java.net.* ;
public class ServidorModbusTCP
{
private final int DIRECCION = 1;
private final int PUERTO = 502;
private final int NUMERO_DE_CONEXIONES = 2;
.
.
.
public static void main (String args[ ])
{
ServerSocket svrSocket = null;
Socket socket = null;
Thread hiloModbus;
ModbusTCPSlave modbus;
.
.
.
try {
svrSocket = new serverSocket( PUERTO );
}
catch( IOException ex ) {
System.out.println( ex.getMessage( ) );
ex.printStackTrace( );
return;
}
while( true )
{
try {
socket = svrSocket.accept( );
modbus = new ModbusTCPSlave( DIRECCION, socket );
hiloModbus = new Thread ( modbus );
hiloModbus.start( );
}
catch ( IOException ex ) {
System.out.println( ex.getMessage( ) );
ex.printStackTrace( );
}
}
}
}
Figura 3.3 Programa en Java de un servidor Modbus/TCP
61
La creacin de una conexin socket TCP/IP se realiza directamente con el

paquete java.net. De ah que con el enunciado de la lnea 1 se cargan las clases
del paquete de trabajo con redes de Java (Java Networking Package).
Las lneas 5, 6 y 7 definen constantes requeridas en la clase ServidorModbusTCP

como el nmero de puerto y el identificador de unidad.
Para establecer un servidor en Java, se utilizan instancias de las clases

ServerSocket y Socket.
En la lnea 13 se declara un objeto de la clase ServerSocket. Este es el objeto

utilizado en la aplicacin servidor para escuchar las peticiones que realicen los
clientes. Este objeto no realiza el servicio, sino que crea un objeto Socket en
funcin del cliente para realizar toda la comunicacin a travs de l.
En la lnea 14 se declara un objeto de la clase Socket. Este es el objeto bsico en

toda comunicacin a travs de Internet, bajo el protocolo TCP. Esta clase
proporciona mtodos para la entrada/salida a travs de streams.
En la lnea 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
programacin concurrente.
62
Una instancia de la clase ModbusTCPSlave se declara en la lnea 16. Esta clase

fue explicada anteriormente y se ejecuta como un nuevo hilo por cada solicitud de
conexin que recibe el servidor. Por tanto esta clase debe implementar el mtodo
run (ejecutar) de la clase Thread. El cdigo que realiza el verdadero trabajo de
un hilo se coloca en su mtodo run.
Con el enunciado de la lnea 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 nmero de clientes que pueden
esperar una conexin y ser procesados por el servidor. Si la cola est llena, las
conexiones de los clientes se rechazarn automticamente.
En la lnea 29 se establece un ciclo while, el cual contiene el bloque de cdigo que

el servidor permanecer ejecutando siempre, que consiste bsicamente en
esperar por solicitudes de conexin y la creacin de hilos concurrentes para cada
conexin.
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 mtodo accept( ) de la clase ServerSocket, la cual devuelve un
objeto Socket cuando se establece una conexin. En la lnea 32 se ejecuta esta
accin.
63
En la lnea 34 se crea un hilo para manejar la conexin, y el programa inicia la

ejecucin del hilo invocando el mtodo start (arrancar) de ese hilo (lnea 35); a su
vez, start invoca el mtodo 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 aplicacin

bsicamente implementa la funcin GET que se define en la especificacin del
protocolo HTTP.
El servidor permite manejar mltiples conexiones concurrentemente; el programa

se mantiene escuchando en el puerto de HTTP y cuando llega una peticin GET,
se crea un proceso hijo que maneja esa transaccin particular y ste devuelve una
pgina HTML (HyperText Markup Language) al cliente.
En la Figura 3.4 se lista parte del cdigo 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 pgina 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 cdigo para un servidor Web
La pgina HTML devuelta por el servidor Web al cliente contiene una applet, la
cual es la que verdaderamente representa la interfaz grfica de usuario que
permite acceso remoto desde Internet. El desarrollo de esta applet se presenta en
la seccin 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 travs de Internet, instaladas
automticamente en la mquina cliente y que se ejecutan localmente como parte
de una pgina Web.
En la Figura 3.5 se lista el contenido del archivo HTML que define la pgina 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 desempeo, en el archivo HTML se hace uso de una herramienta

del JDK: el programa JAR para la creacin 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 conexin adicional al
servidor. Esto har que la applet se cargue ms rpidamente.
66
3.3 DESARROLLO DE UNA INTERFAZ PARA ACCESO WEB
En esta seccin 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 travs
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 caractersticas:
Control de acceso de usuarios; slo 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 supervisin y control de variables se realizan

utilizando el protocolo Modbus/TCP, por tanto la applet debe codificar las
solicitudes segn este estndar.
67
3.3.1 El applet como un cliente Modbus/TCP.
Adems de proveer la interfaz grfica para interaccin con el usuario, el applet

tambin debe comunicarse con un servidor Modbus/TCP. Por tanto, como parte
integral del applet se ha implementado un cliente Modbus/TCP, segn las
indicaciones establecidas en la seccin 1.7.2.
En Java para establecer la comunicacin como cliente se utiliza un objeto de tipo

Socket para conectarse con el servidor, un objeto InputStream para recibir
informacin del servidor y un objeto OutputStream para enviar informacin al
servidor.
InputStream (una subclase de Object) y OutputStream (una subclase de Object)

son clases abstractas que definen mtodos para realizar operaciones de entrada y
salida respectivamente.
El cdigo en Java que se ilustra en la Figura 3.6 establece comunicacin con un

servidor Modbus/TCP remoto, construye una solicitud segn el protocolo, enva la
solicitud y la respuesta recibida del servidor es verificada. La solicitud
Modbus/TCP que se implementa en el cdigo de la figura es Leer mltiples
registros.
68
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
import java.io.* ;
import java.net.* ;
class ClienteModbusTCP
{
private final int PUERTO = 502 ;
private Socket socket = null;
private OutputStream output = null;
private BufferedInputStream input = null;
private int buffer[ ] = new int [261];
// Rutina para funcin de MODBUS. Cdigo de funcin 03.
void Leer_Multiples_Registros (
String dns,
// Direccin IP del servidor
int unidad,
// Identificador de unidad
int referencia,
// Nmero de referencia (posicin)
int cantidad,
// Cantidad de registros a leer
int registros[ ] )
// Buffer para colocar los valores ledos
{
int c, i;
try {
// Crear el socket y establecer las conexiones de flujo respectivas
socket = new Socket ( dns, PUERTO );
output = socket.getOutputStream( );
input = new BufferedInputStream( socket.getInputStream( ) );
// Construir la trama Modbus/TCP leer registros
for ( i=0; i<5; i++ )
buffer[ i ] = 0;
buffer[ 6 ] = (byte) unidad;
buffer[ 7 ] = 3;
buffer[ 8 ] = (byte) (referencia >> 8);
buffer[ 9 ] = (byte) (referencia & 0xFF);
buffer[ 10 ] = 0;
buffer[ 11 ] = (byte) cantidad;
buffer[ 5 ] = 6;
// Enviar la solicitud al servidor
output.write( buffer, 0, 12 );
// Esperar y leer la respuesta
c = input.read( buffer, 0, 261 );
69
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
// Verificar la respuesta y extraer los valores ledos

if ( c == ( 9+2*cantidad ) && buffer[ 7 ] == 3 )
{
for ( i = 0; i<cantidad; i++ )
{
// Construir el valor de registro de los bytes alto y bajo
registros[ i ] = ( ( (int) buffer[ 9+2*i ] ) << 8 ) & 0xFF00 |
( (int) buffer[ 10+2*I ] & 0xFF );
}
}
else
System.out.println ( Respuesta recibida erronea \n );
// Cerrar la conexin socket
socket.close( );
}
catch (Exception e) {
System.out.println ( e.getMessage( ) );
e.printStackTrace( );
return;
}
return;
}
}
Figura 3.6 Cdigo en Java para un cliente Modbus/TCP
En el programa anterior se define una funcin, Leer_Multiples_Registros, la cual

recibe diversos parmetros que se requieren para construir y enviar la solicitud. A
continuacin se describen algunos aspectos relevantes del cdigo.
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 lgicos de datos se leen en una sola operacin de
entrada fsica y se colocan en un buffer de la memoria. As, el nmero de
operaciones de entrada fsica reales es pequeo en comparacin con el
nmero de solicitudes de lectura emitidas por el programa, mejorando el
rendimiento del sistema.
Los mtodos 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 utilizacin 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 direccin 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 librera AWT

(Abstract Window Toolkit) de Java, que es un kit completo con herramientas para
manejo de grficos como paneles, ventanas, botones, mens, 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 grficos, 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. Adems, 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 cargara
en un navegador Web.
Figura 3.8 Vista del panel de control
La informacin que se despliega en el panel de control se actualiza

constantemente; esto se realiza a travs de un thread independiente que se
comunica con los elementos remotos de la red, envindoles solicitudes
Modbus/TCP de lectura. Sin embargo, la informacin que se visualiza no es en
tiempo real debido a los retardos a travs de la red.
73
3.4 IMPLEMENTACION DE UN ESCLAVO MODBUS EN LA CPU08
Como se expuso en la seccin 2.2.5, la tarjeta CPU08 puede ser programada en

lenguaje C; la implementacin 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 mltiples
registros (cdigo 16 hexadecimal) y leer mltiples registros (cdigo 03
hexadecimal).
Para la aplicacin a la que est destinada la tarjeta CPU08, solo se requieren

estas dos funciones ya que el programa bsicamente 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 acta como interfaz entre el protocolo
MODBUS y el protocolo codificado en ASCII de los controladores 452 Plus.
El programa de la CPU08 efecta la conversin de protocolos de forma que la

solicitud MODBUS de lectura de registros se asocia con el tipo de mensaje RA
(leer variable anloga) del controlador 452 Plus; as mismo, la solicitud MODBUS
de escritura de registros se asocia con el tipo de mensaje SA (escribir en
localizacin anloga) del controlador 452 Plus. Para una descripcin de los tipos
de mensajes del controlador revisar la tabla 2.6 y la seccin 3.5.
74
De acuerdo a la seccin 2.2.2, la tarjeta CPU08 posee un solo puerto de

comunicaciones RS-232 RS-485. La aplicacin que se desarroll para la CPU08
requiere de la existencia de dos puertos de comunicacin serial, por tanto uno de
los cuales se implement por software utilizando dos pines de propsito general,
que simulan las seales Rx y Tx de una UART.
El puerto de comunicaciones RS-485 que tiene la tarjeta se utiliza para establecer

la comunicacin 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 informacin segn el estndar
IEEE754 que define el formato para el almacenamiento y la transmisin de datos
flotantes. Cada dato flotante se debe tratar como dos registros holding segn el
protocolo MODBUS.
3.4.1 Algoritmo de la aplicacin 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 descripcin detallada de las diferentes etapas que componen el algoritmo es

presentada a continuacin.
Inicio. Se establecen los valores para los registros de funcin especial del
microcontrolador de la tarjeta CPU08.
Etapa 1. Esperar a travs de la UART implementada por software, una

solicitud MODBUS a ser procesada.
Etapa2. verificar la integridad de la trama MODBUS recibida. Bsicamente

corroborar el cdigo de chequeo de error (CRC) recibido con el calculado.
Adems comprobar que el mensaje es direccionado a la tarjeta.
Etapa 3. realizar una discriminacin basndose en el campo de cdigo de

funcin, para enviar el mensaje a la rutina respectiva.
Etapa 4. Generar una respuesta de excepcin indicando que el cdigo de

funcin recibido no es soportado por el esclavo MODBUS.
Etapa 5. Rutina para procesar la funcin de leer mltiples registros. Se

encuentra conformada por las etapas 7, 10 y 12.
77
Etapa 6. Rutina para procesar la funcin de escribir mltiples 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 excepcin, indicando el tipo de excepcin

que se produjo.
Etapa 10 y 11. Construir y enviar una solicitud de lectura escritura segn el

caso al controlador respectivo, teniendo en cuenta el protocolo de
comunicacin ASCII que manejan esos dispositivos. Esto se realiza a travs
del puerto serial RS-485 de la CPU08.
Etapas 12 y 13. A travs 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 segn el protocolo una respuesta MODBUS a la
solicitud procesada.
Etapa 14. Enviar la respuesta a la trama MODBUS recibida, a travs de la

UART implementada por software.
78
La aplicacin embebida residente en la tarjeta CPU08 se mantiene cclicamente

esperando por tramas MODBUS y procesando las solicitudes.
En la seccin 3.5 se describe detalladamente la codificacin de una trama de

solicitud respuesta para los controladores 452 Plus, segn el protocolo de
comunicacin 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 funcin que desempean.
Tabla 3.1 Pines utilizados por la tarjeta CPU08

Puerto
Descripcin
P3.5
Simula la seal de recepcin de una UART.
P1.3
Simula la seal de transmisin de una UART.
P1.6
Seal de habilitacin para el driver RS-485.
P3.0
Pin de recepcin de la UART del microcontrolador.
P3.1
Pin de transmisin de la UART del microcontrolador.
P3.3
Interrupcin externa que activa la recepcin en la

UART implementada.
Tambin son utilizados los dos pines provenientes del driver RS-485 de la CPU08,
que proporcionan las seales A y B del canal diferencial de transmisin y
recepcin.
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 aplicacin propuesta.
Se hace uso de una interrupcin externa para indicarle a la rutina de recepcin la

llegada de un byte, y para iniciar el temporizador que genera la seal de reloj.
Cuando arriva el bit de inicio de un byte (nivel lgico 0) se genera la interrupcin
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.
Segn el protocolo MODBUS RTU, la separacin mxima entre bytes dentro de

una misma trama de lectura o escritura es de 3.5 veces el perodo de reloj; en la
rutina de recepcin se desarrolla esta verificacin del tiempo de separacin. En la
rutina de recepcin tambin se realiza la verificacin de los bits de inicio y de
parada para cada byte que llega.
La seal de reloj se establece al doble de la rata de baudios a la cual se realiza la

comunicacin, para garantizar que cada uno de los bits son ledos en la mitad del
slot de tiempo y no cerca de los lmites del slot donde podra 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 comunicacin
codificado en ASCII que entienden esos dispositivos. Referirse a la seccin 2.4.2
para una descripcin detallada de dicho protocolo.
Para la aplicacin a la que est destinada la CPU08, existen dos tipos de

mensajes distintos para comunicarse con los controladores 452 Plus, que se
presentan a continuacin.
81
Mensaje para leer una variable anloga:
<SYN>Direccin_del_controlador<STX>RA Direccin_de_la_variable<ETX>
Mensaje para escribir en una variable anloga:
<SYN>Direccin_del_controlador<STX>SA Direccin_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 rplica 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 acompaa 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
Descripcin
Ejemplo*
Mensaje invlido
RX 10
Posicin invlida
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 posicin 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 Direccin_de_la_variable<ACK>Dato<ETX><CR><LF>
Respuesta a una solicitud de escritura:
<STX>SA Direccin_de_la_variable Dato<ACK><ETX><CR><LF>
Hay que tener en cuenta que un valor anlogo que se desee leer o escribir
consiste de un nmero con un punto decimal opcional, como por ejemplo 12.34
3999; solamente 4 dgitos 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 razn. Por tanto en el programa de
la CPU08 se establece un timeout cada vez que se enve una trama al controlador,
para evitar que posiblemente se quede esperando eternamente. Si se completa en
timeout, la CPU08 armar una respuesta de excepcin y la retornar al dispositivo
maestro.
83
3.5.2 Ejemplos de mensajes de lectura y escritura.
A continuacin se presentan diversos ejemplos de solicitudes de lectura y escritura

para los controladores 452 Plus, al igual que las tramas reales que sern enviadas
a estos dispositivos.
Leer la constante proporcional del controlador 452 Plus que tiene direccin 1.
En la Tabla 3.3 se observa la trama de solicitud.
Tabla 3.3 Ejemplo de trama de lectura del controlador 452 Plus

Posicin del byte
Caracter ASCII
Valor en hexadecimal*
Byte 0
<SYN>
96
Byte 1
B1
Byte 2
<STX>
82
Byte 3
D2
Byte 4
41
Byte 5
Espacio
A0
Byte 6
B7
Byte 7
<ETX>
03
* Este valor adems de representar al respectivo carcter ASCII, tambin coloca la

paridad del protocolo (paridad par).
Establecer a 50 el setpoint del controlador 452 Plus que tiene la direccin 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

Posicin de byte
Caracter ASCII
Valor en hexadecimal*
Byte 0
<SYN>
96
Byte 1
B2
Byte 2
<STX>
82
Byte 3
53
Byte 4
41
Byte 5
Espacio
A0
Byte 6
B2
Byte 7
Espacio
A0
Byte 8
35
Byte 9
30
Byte 10
<ETX>
03
* Este valor adems de representar al respectivo carcter ASCII, tambin coloca la

paridad del protocolo (paridad par).
3.6 CONFIGURACION DEL PLC DL05 COMO ESCLAVO MODBUS
Para realizar la configuracin del PLC DL05 como un esclavo MODBUS se han
utilizado las caractersticas que se aprecian en la Tabla 3.5.
Tabla 3.5 Variables de configuracin del PLC DL05

Interfaz de comunicacin
RS-232
Puerto de comunicacin
Puerto 2
Direccin de esclavo
Rata de baudios
Bits de datos
Paridad
2
4800
8
ninguna
85
La comunicacin del PLC como dispositivo esclavo puede hacerse a travs de

cualquiera de los dos puertos de comunicacin, sin embargo se opt por utilizar el
puerto 2 porque es ms flexible en los parmetros que se le pueden establecer.
Segn la seccin 2.3.5, el PLC DL05 se programa con DirectSOFT. En la Figura

3.11 se observa la ventana para la configuracin del puerto 2, en DirectSOFT.
Figura 3.11 Configuracin del puerto 2 en DirectSOFT
La comunicacin con el PLC se establece con el protocolo MODBUS en modo

RTU. Los cdigos de funcin 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

Cdigo de funcin
MODBUS
Funcin
Tipo de datos en
el PLC DL05
01
Leer un grupo de salidas discretas.
Y, CR, T, CT
02
Leer un grupo de entradas discretas.
05
Cambiar un dato discreto simple.
Y, CR, T, CT
15
Cambiar un grupo de datos discretos.
Y, CR, T, CT
03
Leer mltiples registros.
04
Leer mltiples registros de entrada.
06
Escribir un valor en un registro simple.
16
Escribir en un grupo de registros.
X, SP
Para que puedan realizarse operaciones de escritura de registros de datos

discretos sobre el PLC a travs del protocolo MODBUS RTU, el PLC debe
encontrarse en modo de operacin TERM.
3.7 CONFIGURACION DE LOS CONTROLADORES 452 PLUS
Las variables de configuracin de los controladores 452 Plus requeridas para

establecer la comunicacin serial a travs del puerto RS-485 son:
87
Rata de baudios.
Direccin de comunicaciones.
Modo de comunicacin ( modo CRL o VDU ).
Nivel de proteccin de los datos.
Desde el panel frontal de los controladores 452 Plus se establecen los valores de
las variables de configuracin, usando las funciones CS que se relacionan en la
Tabla 3.7.
Tabla 3.7 Configuracin de los controladores 452 Plus

Funcin
Valor
CS_5
0, 1*
CS_6
CS_7**
Descripcin
Direccin del controlador
( 0 a 1F )
Rata de baudios
( 0-300, 1-1200, 2-4800, 3-9600 )
Modo CRL/VDU y nivel de proteccin
( 0-VDU, 1-CRL )
* Un solo valor para cada controlador.

** Para mayor informacin sobre los diversos valores que puede tomar esta funcin,
revisar el manual del controlador.
Para la comunicacin con los controladores 452 Plus se emplea el modo CRL (ver
seccin 2.4), debido a que este modo facilita la comunicacin con ms de un
controlador, lo cual resulta apropiado para la implementacin de la subred RS-485
dentro de la red Modbus/TCP.
88
3.7.1 Conexiones fsicas.
La interfaz serial RS-485 de los controladores 452 Plus se presenta fsicamente a

travs de 4 pines que se detallan en la Tabla 3.8.
Tabla 3.8 Interfaz serial del controlador 452 Plus

Nmero de pin
Seal
Tx -
Tx +
Rx +
Rx -
Las seales Tx- y Tx+ conforman el canal diferencial de transmisin y las seales
Rx- y Rx+ conforman el canal diferencial de recepcin.
Para realizar la conexin entre la tarjeta CPU08 y la subred RS-485 de

controladores 452 Plus, se unen las seales Tx+ y Rx+ de cada uno de los
controladores con la lnea A del driver RS-485 de la CPU08. Igualmente se unen
las seales Rx- y Tx- de cada uno de los controladores con la lnea B del driver
RS-485 de la CPU08.
89
4. CONCLUSIONES
Ante la incursin de la tecnologa Ethernet en el rea de los sistemas de

control de procesos y la automatizacin, para la interconexin a nivel de campo
de sensores, actuadores y controladores, han surgido diversos protocolos para
comunicacin industrial sobre Ethernet. Sin embargo, una capa de aplicacin
(segn el modelo de referencia OSI) estndar con un modelo de objetos
comn, no existe. Modbus/TCP es un estndar de-facto y est ampliamente
extendido y aceptado; Pero adems 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 aade
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 simultneamente desde una posicin nica.
90
Adems del monitoreo de variables (como la variable corriente del proceso),

los parmetros 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;
adems, todo el proceso de programacin y depuracin de las aplicaciones se
desarroll en un PC, para posteriormente transportar el cdigo a la tarjeta,
agilizndose la creacin de los programas.
Con la implementacin 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 razn de su alta difusin en entornos industriales.
Adems, 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, demostrndose 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 estndar
Modbus/TCP.
91
El monitoreo continuo de datos streaming data no es muy eficiente con el

protocolo Modbus/TCP, debido bsicamente 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,
incrementndose considerablemente el trfico en la red cuando se monitorea
en todo momento un esclavo Modbus/TCP particular. La solucin para la
supervisin de datos continuo sobre una red Ethernet es la utilizacin del
protocolo de transporte UDP.
Como una proyeccin futura del presente trabajo sera 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
informacin. Con la tarjeta TINI, bsicamente este estndar se utilizara para
que una base de datos con soporte XML (actualmente casi todas lo tienen) se
comunique con ella y acceda continuamente a la informacin proveniente de
los procesos. Esta informacin es almacenada en las tablas internas de la base
de datos, y de esa forma es posible llevar registros, histricos, tendencias,
grficos, 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 cdigo abierto.
92
La interfaz grfica de usuario para la supervisin y control de la red

Modbus/TCP desde Internet que se desarroll como un applet de Java tambin
es posible enfocarla desde un punto de vista diferente: El mecanismo de
interaccin entre al usuario en la Web y la plataforma TINI se puede realizar a
travs de la utilizacin de Servlets de Java, los cuales residiran y se
ejecutaran sobre la TINI.
93
BIBLIOGRAFA
COMER, Douglas E. Redes Globales de informacin con Internet y TCP/IP.

Prentice-Hall Hispanoamericana, S.A. Mxico, 1997.
DEITEL, H. M. y DEITEL, P. J.. Cmo programar en Java.

Prentice-Hall Hispanoamericana, S.A. Mxico, 1998.
GEARY, David M. Graphic Java 1.2: Mastering the JFC. Tercera edicin.
The Sun Microsystem Press. U.S.A., 1999.
LOOMIS, Don. The TINI Specification and Developer`s Guide.

Addison Wesley, 2001.
ESCOBAR, Anglica M. y SANCHEZ, Hugo A. Implementacin de una Red

Inalmbrica usando el protocolo MODBUS.
Trabajo de grado, Universidad del Valle. Santiago de Cali, 2001.
94
Enlaces Electrnicos:
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
Disposicin fsica del montaje final
En la figura siguiente se aprecia la disposicin fsica de tarjetas y cables del

montaje final de la red implementada.
TARJETA # 1.
Esta tarjeta proporciona la interfaz entre las 4 seales RS-485 provenientes del
controlador 452 Plus y las dos seales RS-485 provenientes de la tarjeta
CPU08. Adems en esta tarjeta se proporcionan las resistencias de acople
necesarias para el canal de transmisin y recepcin 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 continuacin se presenta la
descripcin de pines y de seales.
Conector DIN
Conector DB25
Pin 1: No conectado
Pin 2: Tx-
Pin 3: Seal B
Pin 3: Tx+
Pin 9: Seal A
Pin 4: Rx+
Pin 10: Seal A
Pin 5: Rx-
Pin 2: Seal B

Este cable posee en los dos terminales conectores de 14 pines para cable
ribbon. A continuacin se presenta la descripcin de pines y de seales.
Conector CPU08
Conector tarjeta #1
Pin 14: GND
Pin 14: GND
Pin 12: Seal B
Pin 12: Seal B
Pin 10: Seal A
Pin 10: Seal A
97

Este cable posee en los dos terminales conectores de 14 pines para cable
ribbon. A continuacin se presenta la descripcin de pines y de seales.
Conector TINI
Conector CPU08
Pin 4: RxD
Pin 4: TxD
Pin 10: GND
Pin 10: GND
Pin 12: ------
Pin 12: Interrupcin 1
Pin 13: TxD
Pin 14: RxD

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
continuacin se presenta la descripcin de pines y de seales.
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.

Modbus

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modbus

Cargado por

Copyright:

Formatos disponibles

IMPLEMENTACION DE UNA RED MODBUS/TCP

ANDRES FELIPE RUIZ OLAYA

UNIVERSIDAD DEL VALLE

IMPLEMENTACION DE UNA RED MODBUS/TCP

ANDRES FELIPE RUIZ OLAYA

Trabajo de grado para optar por el ttulo de

UNIVERSIDAD DEL VALLE

En este proyecto se desarrolla e implementa una red de instrumentacin y

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

Ing. ASFUR BARANDICA LOPEZ

Ing. FABIO GERMAN GUERRERO

Ing. EDINSON FRANCO

Ing. CARLOS RAFAEL PINEDO

El autor expresa sus agradecimientos a:

A todas aquellas personas que me acompaaron a lo largo de la carrera y en la

A mis compaeros, profesores y en general a la comunidad universitaria de

1.1.1 Orientado a conexin

1.1.2 Codificacin de datos

1.1.3 Interpretacin del modelo de datos

1.1.4 Filosofa de longitud implicada

1.2 VENTAJAS DEL PROTOCOLO MODBUS/TCP

1.3 ESTRUCTURA DEL PROTOCOLO

1.4 ESQUEMA DE ENCAPSULACION

1.5 CONFORMACION DE CLASES

1.5.1 Comandos Clase 0

1.5.2 Comandos Clase 1

1.5.3 Comandos Clase 2

1.5.4 Comandos especficos de la mquina/red/vendedor

1.6 DESEMPEO REQUERIDO Y ESPERADO

1.7 GUIA DE IMPLEMENTACION DEL CLIENTE Y SERVIDOR

1.7.1 Diseo del Cliente

1.7.2 Diseo del Servidor

2. DESCRIPCION DEL HARDWARE

2.1 LA TARJETA TINI

2.1.4 Hardware de la TINI

2.1.5 Mapa de memoria del sistema

2.1.6 Sistema I/O integrado

2.1.7 Software de la TINI

2.1.8 Sistema operativo de la TINI

2.1.9 El Socket E10

2.2 LA TARJETA CPU08

2.2.1 Diagrama de bloques

2.2.3 Programacin de la CPU08

2.3 EL PLC DL05 DE KOYO

2.3.1 Diagrama de bloques

2.3.3 Modos de operacin

2.3.4 Mapa de memoria

2.4 CONTROLADORES 452 PLUS

2.4.1 Definicin de caracteres especiales

2.4.2 Protocolo de Comunicacin

2.4.2.1 Nivel 1 El Wrapping

2.4.2.2 Nivel 2 Contenido del mensaje

2.4.3 Contenido de posiciones anlogas del controlador 452 Plus

3. DESCRIPCIN DEL SOFTWARE

3.1 DESARROLLO DE UN SERVIDOR MODBUS/TCP

3.1.1 Estructura de Clases

3.1.2 Descripcin de las Clases

3.1.3 Ejemplo de cdigo fuente

3.2 DESARROLLO DE UN SERVIDOR WEB

3.3 DESARROLLO DE UNA INTERFAZ PARA ACCESO WEB

3.3.1 El applet como un cliente Modbus/TCP

3.3.2 Sistema de acceso

3.3.3 Panel de Control

3.4 IMPLEMENTACIN DE UN ESCLAVO MODBUS EN LA CPU08 73