Niveles Jerárquicos en Sistemas de Automatización

Seminario de Titulación Protocolo de Comunicación Modbus
REDES INDUSTRIALES
PROTOCOLO MODBUS
Mayo 2004
ÍNDICE
CAPITULO 1
Introducción a las Redes Industriales 1
1.1. Automatización Industrial y Redes de Comunicación 2

1.2. Vista General de la Automatización Industrial y Redes de
Comunicación 5
1.3. Niveles Jerárquicos en Sistemas de Automatización
Industrial 8
-Nivel de campo 8
-Nivel de célula.. 10
-Nivel de área.. 11
-Nivel de planta… 11
-Medios de transmisión… 11
-Topología de red… 13
1.4. Consideraciones de diseño..14
-Costo… 15
-Servicio o función de la red… 16
-Tolerancia con respecto al medio ambiente.. 17
-Medios físicos.. 17
-Expansión .. 18
-Mantenimiento.. 18
-Requisitos de comunicación para los sistemas de
automatización… 18
CAPITULO 2
Protocolo Modbus.. 21
2.1. Introducción al Protocolo de Comunicación Modbus… 22

-Intercambio de información en una red Modbus.. 24
-Intercambio de información sobre redes diferentes a
Modbus.. 25
-Pregunta.. 26
-Respuesta.. 27
2.2. Los Dos Modos de Transmisión Serial… 27
-Modo ASCII.. 28
-Modo RTU.. 28
2.3. Tramas de Mensaje Modbus.. 30
-Trama ASCII.. 30
-Trama RTU..31
-Como es manipulado el campo de dirección… 32
-Como es manipulado el campo de función… 32

-Contenido del campo de datos.. 34
-Contenido del campo de comprobación de error.. 35
-Como son trasmitidos los caracteres en serie.. 36
2.4. Métodos de Comprobación de Error.. 37
-Control de Paridad… 37
-Comprobación LRC.. 39
-Comprobación CRC.. 39
CAPITULO 3
Datos y Funciones de Control… 42

3.1. Formato de las Funciones Modbus… 43
3.2. Código de Funciones Soportadas por Los Controladores.. 47
-01 Lectura del estatus de una bobina.. 48
-02 Lectura del estatus de una entrada.. 50
-03 Lectura de registros sostenidos.. 52
-04 Lectura de registro de entradas.. 54
-05 Forzar bobinas simples……… 56
-06 Predeterminar registros simples……. 58
-07 Lectura de estatus de excepción……. 59
-11 Sacar un contador de eventos de comunicaciones…… 61
-12 Traer el registro de eventos de comunicaciones………. 63
-15 Forzar varias bobinas….... 68
-16 Predefinir varios registros…… 70
-17 Reportar el identificador del esclavo…….. 72
-20 Lectura de referencias generales………… 81
-21 Escritura de referencias generales………. 84
-22 Escritura de registros 4X con una mascara……. 88
-23 Lectura/escritura de registros 4X………………. 90
-24 Lectura de una cola FIFO……………. 92
CAPITULO 4
Subfunciones de Diagnostico………………… 95
4.1 Función 08 Diagnósticos…………………….. 96
-Efectos del diagnostico en el esclavo……. 96
4.2 Subfuncion de Diagnostico…………………….. 99

-00 Regreso de datos de la pregunta……….. 99
-01 Opción de reinicio de la comunicación…. 99
-02 Regreso del registro de diagnostico 100
-03 Cambio del delimitador de entrada ASCII 101
-04 Forzar el modo de solo escucha 101
-10 Borrar contadores y registro de diagnostico 102
-11 Regreso del contador de mensajes del bus 102

-12 Regreso del contador de errores de
comunicación del bus.. 102
-13 Regreso del contador de errores de excepción
en el bus…. 103
-14 Regreso del contador de mensajes del esclavo 103

-15 Regreso del contador de no respuestas del esclavo 103
-16 Regreso del contador NAK del esclavo 104
-17 Regreso del contador de ocupado del esclavo .104
-18 Regreso del contador de caracteres
desbordados en el bus… 105
-19 Regreso del contador de IOP desbordados (884)…… 105
-20 Borrar banderas y contadores de desbordamiento….. 106
CAPITULO 5
Modbus TCP/IP……… 107

5.1 Modelo Cliente Servidor……… 108
5.2 Descripción del Protocolo……….. 109
-Arquitectura general de comunicación….. 109
-La unidad de datos de la aplicación sobre
Modbus TCP/IP …..110
-Descripción del encabezado MBAP……… 111
5.3 Descripción Funcional………… 113

-Agente de conexión TCP 118
-Uso de la pila TCP/IP 123
-Capa de aplicación de comunicación 124
INTRODUCCIÓN
JUSTIFICACIÓN
El tema de protocolo de comunicación Modbus fue elegido por ser uno de los protocolos más
utilizados en la industria, y el cual a sufrido modificaciones al original Modbus creado por
Modicon, llegando a ser un estándar para la industria, este tema es poco conocido afuera del
área de instrumentación y control, pero la mayoría de los equipos industriales tienen este
protocolo para la transmisor de sus datos y/o configuración del mismo equipo.
OBJETIVOS
El objetivo es tener un material claro y objetivo para comprender el modo de operación de

los dispositivos que cuentan con Modbus para la transmisión de datos, así como conocer los
alcances del mismo protocolo, tener un panorama de las variantes que se pueden encontrar
en el campo debido a los diferentes modos de transmisión que eligieron los fabricantes, y
tener clara la filosofía del funcionamiento de una red de este tipo, tanto para su transmisión
serial como para el caso de su transmisión bajo Modbus TCP/IP en el cual se busca que el
lector comprenda las diferencias contra el Modbus de transmisión serial, y mostrar las
modificaciones que sufrirían los datos.
PROBLEMAS
La falta de información acerca de este tema es el principal problema, ya que en lo referente

a redes todo mundo habla de las nuevas tecnologías y de redes empresariales, pero no
consideran las redes industriales que es un campo con grandes posibilidades, ya que se están
logrando integraciones de sistemas usando infraestructura ya creada, logrando un grado de
control y automatización que no seria posible bajo los conceptos antiguos, debido a el
excesivo uso de cables para la transmisión de las señales y con la necesidad de tener grande
cuartos de control donde integrar estas señales, con las redes industriales, el grado de
monitoreo y control permite reducción de costos y espacios.
CAPITULO 1
INTRODUCCIÓN A LAS REDES INDUSTRIALES
AUTOMATIZACIÓN INDUSTRIAL Y REDES DE COMUNICACIÓN.
VISTA GENERAL DE LA AUTOMATIZACIÓN INDUSTRIAL Y REDES DE

COMUNICACIÓN.
NIVELES JERÁRQUICOS EN SISTEMAS DE AUTOMATIZACIÓN

INDUSTRIALES
CONSIDERACIONES DE DISEÑO
Puntos básicos, sobre la arquitectura de una red industrial y las necesidades que
se tienen en una empresa a nivel proceso, así como las razones por las que los
protocolos de los diferentes fabricantes deben poder ser integrados para formar un
solo sistema.
1.1 AUTOMATIZACIÓN INDUSTRIAL Y REDES DE COMUNICACIÓN
Cuando las tecnologías de automatización digitales se pusieron disponibles en los

60`s, fueron usadas para mejorar y agrandar los sistemas de automatización
industriales. Los conceptos de fabricado de computadoras-integradas (CIM) y los
sistemas de control de computadoras distribuidas (DCCSs) fueron introducidos en
el campo de la automatización industrial y el uso de las redes de comunicación ha
tenido un crecimiento acelerado.
Los últimos sistemas de automatización industriales usan arquitecturas muy

distribuidas donde un número de módulos digitales son interconectados por redes
de comunicación para la adquisición de los datos y funciones de control a bajo nivel.
En los sistemas de automatización industriales más modernos, la comunicación de
los datos entre la los dispositivos automatizados juega un papel importante.
La llave del éxito el integrar los sistemas de automatización grandes es poner

mutuamente de acuerdo normas que permitan que todos los tipos diferentes de
dispositivos de automatización se comuniquen entre sí. Por lo tanto, se han hecho
esfuerzos internacionales notables de regularización en el área de redes de áreas
locales. Los logros importantes en esta área incluyen el muy conocido, Modelo de
Interconexión de Sistemas abierto (OSI-Open Systems Interconnection Model),
Proyecto 802 de IEEE, y el Protocolo de Automatización Industrial (Manufacturing
Automation Protocol (MAP)) concepto para habilitar la compatibilidad de sistemas
bus y redes de áreas locales conecta a una red de computadoras de vendedores
diferentes.
El protocolo de automatización industrial (MAP) fue desarrollado para superar

problemas de comunicación entre los dispositivos de automatización de varios
fabricantes, y se aceptó ampliamente como una norma industrial para
comunicaciones de datos en fábricas. La arquitectura de mini-Map es satisfacer las
condiciones para comunicaciones en tiempo crítico y no incluye las capas 3 a 6 de

las 7 capas de arquitectura del modelo OSI.
La arquitectura del mini-Map consiste en la capa de la aplicación, la subcapa de

control de enlace lógico (logical link control (LLC)), la subcapa de control de acceso
al medio (medium access control (MAC)) y la capa física.
La especificación del mensaje industrial (manufacturing message specification

(MMS)) [2,5] fue desarrollado como la capa de la aplicación de la red MAP para
lograr un intercambio del mensaje estándar entre los dispositivos de automatización
de los diferentes vendedores.
El desempeño y la condición de fiabilidad de un sistema de automatización industrial

dependen substancialmente de su red de comunicación. En una red de
comunicación para un sistema de automatización industrial, mejora el desempeño
y fiabilidad de la red y se pide la regularización de la comunicación de acuerdo con
la extensión del tamaño de sistema y el aumento de información.
Los puntos siguientes deben ser considerados al diseñar una red de comunicación
para un sistema de automatización industrial.
 Verifique el desempeño de la red para reunir los requisitos;

 Confirme los valores instalados de los diversos parámetros han sido
adecuadamente fijados en todos los nodos.
 Verifique la fiabilidad de la red para reunir los requisitos
Una red de comunicación para un sistema de automatización industrial debe

garantizar los requisitos para el desempeño como es la utilización de la red, la
conexión de una red de computadoras y el retraso de la transmisión. Todo esto
juega un papel importante para determinar el desempeño global de un sistema de
automatización industrial. La evaluación del desempeño de una red de

comunicación puede ser hecha por simulación de los métodos analíticos.
En la mayoría de los ambientes industriales, hay mucho ruido, emitido por las
fuentes de ruido como robots soldando y grandes motores. El desempeño de una
red de comunicación puede ser degradada por la interferencia de ruido, los efectos
de ruido en el desempeño de una red de comunicación deben ser estudiados para
obtener un desempeño practico de una red de comunicación aplicada a un ambiente
ruidoso, qué es común en aplicaciones prácticas.
Muchos problemas de comunicación en una red de comunicación para un sistema

de automatización industrial son debidos a malas configuraciones en los diversos
parámetros de la red como fue. Los parámetros de la red pueden determinar el
desempeño de la misma. Además, los parámetros incorrectos pueden producir
funcionamiento incorrecto de la red. Para conseguir valores apropiados, el ambiente
local de un nodo en la red debe ser considerado, y los posibles links de
comunicación entre los nodos deben ser considerados.
Entre los componentes de un sistema de automatización industrial, la red de

comunicación es un componente importante que se encarga del intercambio de
información. Por consiguiente, la fiabilidad de un sistema de automatización
industrial depende significativamente de la fiabilidad de su red de comunicación.
Para aumentar la fiabilidad de una red de comunicación, muchos tipos de
tolerancias a errores se están desarrollado y se ha aplicado para el sistema que
requiere fiabilidad alta.
1.2 VISTA GENERAL DE LA AUTOMATIZACIÓN INDUSTRIAL Y REDES DE

COMUNICACIÓN.
A principios de los años 20, el sistema de control de proceso y el sistema industrial

fueron diseñados basados principalmente en la tecnología mecánica y con
dispositivos analógicos. Después del periodo, la tecnología de control neumático y
el poder hidráulico fue introducida. La tecnología de control neumática hizo posible
controlar sistemas remotos por un sistema de control centralizado. Estas
tecnologías todavía son muy comunes.
El uso de sistemas de control centralizados para grandes sistemas a aumentados

con el desarrollo de los controladores electrónicos en los años cincuenta debido a
la gran distancia de la transmisión. Muchos transmisores electrónicos fueron
desarrollados durante este periodo. Algunos convertidores neumáticos a
electrónicos fueron usados, y los convertidores electrónicos a neumáticos eran
necesarios para conectar las válvulas neumáticas de control. Empezando los años
cincuenta, muchos sistemas de comunicación industriales eran desarrollados para
el control de sistemas. Estas redes usaban tecnología analógica, y fueron usadas
para unir un procesador central al periférico y las terminales. El periférico era usado
en paralelo, cables de muchos alambres, e interfaces serie de 20mA de corriente a
baja frecuencia de transmisión.
Al principio de 1960, la primera vez que se uso una computadora como un

controlador digital. El término control digital directo (direct digital control (DDC)) fue
usado para dar énfasis al control del proceso directamente por la computadora. En
los años sesenta, la aplicación de una mini computadora era todavía una solución
bastante cara para muchos problemas de control. Mientras tanto, el controlador
lógico programable (programmable logic controller (PLC)) fue desarrollado y
reemplazo a los convencionales que estaban basados en relevadores, que tenían
funciones de control limitadas. Además, muchas tecnologías fueron desarrolladas
para las herramientas de las maquinas y los procesos de producción discretos. El
control numérico (numerically controlled (NC)) llego a controlar las herramientas de

las maquinas por computadoras y el robot fue desarrollado en este periodo.
Las técnicas y equipos necesarios para las comunicaciones de datos a gran

velocidad fueron desarrollados en los años sesenta. La frecuencia de codificación
cambio en los módems y eran capaces de transmitir datos sobre líneas dedicadas
a velocidades de 1200 bit/s. La introducción de mini computadoras capaces de
transferir datos a grandes velocidades llevó al desarrollo de las redes de
comunicación de datos y los quipos de transmisión de datos a alta velocidad a
fínales de los años 60 e inicio de los 70´s.
A fines de los sesenta, Mollins del Reino Unido anunció su Sistema 24. Este sistema
fue diseñado para operar varias máquinas bajo el control de una sola computadora.
Se esperaba que con esto aumentara la productividad más allá del nivel alcanzable
por el mismo número de máquinas trabajando independientemente. Este concepto
de sistema industrial flexible (flexible manufacturing system (FMS)) actualmente es
de gran interés como estructura conveniente para la creciente utilización en la
máquina, reduciendo tiempo de manufacturado y un proceso de inventario. Con la
introducción de FMS, el concepto de la fabricación integrada por computadora
(computer integrated manufacturing (CIM)) hizo que se tomara atención en el área
de automatización industrial para integrar los procesos de fabricación a
computadoras digitales en todos los aspectos. Ahora el término CIM es usado en
todos los tipos de sistemas industriales lo que significa la integración completa de
las computadoras industriales, redes de comunicación, y sistemas de control de
proceso en todas las funciones industriales.
Con el uso más extenso de computadoras digitales y las tecnologías asociadas, las
redes de comunicación industriales llegaron a ser desarrolladas con o transformar
a la transmisión digital. La red de comunicación digital para uso industrial empezó
en los años sesenta como computadoras para sistemas de automatización y fueron
las primeras en unirse.
A mediados de los setenta, el primer sistema de control de computadora distribuido

(distributed computer control system (DCCS)) fue anunciado por Honeywell como
un sistema de control jerárquico con un gran numero de microprocesadores. Desde
que su introducción a mediados de los años setenta, el concepto de DCCS se
extendió ampliamente en muchos sistemas de automatización industriales como
sistema de control de energía en las fabricas, sistemas industriales, etc. La
instalación de sistemas de control distribuidos recientemente en las fabricas planea
o reemplaza la existencia analógica o los sistemas de control centralizado en el
presente es una decisión común de la administración de la empresa.
El uso de las redes de área local para interconectar computadoras y dispositivos de

automatización dentro de un sistema de automatización industrial llego a ser
popular desde 1980. La alta capacidad y el bajo costo ofrecido en la comunicación
por redes de área locales han hecho una realidad la distribución de la informática, y
muchos servicios de automatización. Los sistemas de automatización industriales
frecuentemente se realizan como una arquitectura distribuida abierta con
comunicación en redes de comunicaciones digitales.
Es ahora común para usuarios conectados a una red de área local comunicarse con
computadoras o dispositivos de automatización en otra red de área local unidas
por una red de área ancha.
Como los sistemas de automatización industriales llegaron a ser grandes y el

número de dispositivos de automatización aumento, se ha hecho importante para la
automatización industrial proporciona normas que hacen posible interconectar
muchos dispositivos diferentes de automatización de una manera normal. Se han
hecho esfuerzos de regularización internacionales considerables en el área de
redes de áreas locales. Interconexión de Sistemas Abiertos (Open Systems
Interconnection (OSI)) las normas que permiten a cualquier par de dispositivos de
automatización comunicar fiablemente sin tener en cuenta el fabricante. El
Protocolo de Automatización Industrial (Manufacturing Automation Protocol (MAP))

el concepto se ha desarrollado para habilitar la compatibilidad de redes de
comunicación de vendedores diferentes.
Para el nivel bajo de la red de comunicación para la Industria de automatización, las

soluciones de red de área local industrial como MAP son demasiado caras y/o no
alcanzan las necesidades de respuestas en tiempo cortos y dependiendo de la
aplicación. Los fieldbuses han tenido, por consiguiente, un desarrollo para reunir
estos requisitos, y están haciéndose muchos esfuerzos ahora hacer del fieldbus un
estándar para las aplicaciones de automatización industriales.
1.3 NIVELES JERÁRQUICOS EN SISTEMAS DE AUTOMATIZACIÓN

INDUSTRIALES
Los sistemas de automatización industriales pueden ser muy complejos, y

normalmente están estructurados dentro de varios niveles jerárquicos. Cada nivel
jerárquico tiene un apropiado nivel de comunicación que coloca requisitos diferentes
en la comunicación de red. En la figura 1.1 Se muestras un ejemplo de la jerarquía
de un sistema de automatización industrial.
Nivel de campo
El nivel más bajo de la jerarquía de automatización es el nivel de campo que incluye

los dispositivos de campo como actuadores y sensores. Los dispositivos de campo
elementales a veces son clasificados como elementos de nivel. La tarea de los
dispositivos en el nivel de campo es transferir datos entre el producto fabricado y el
proceso técnico. Los datos pueden ser binarios y analógicos. Los valores
moderados pueden estar disponibles para un periodo corto de tiempo o por un
periodo largo de tiempo.
Figura 1.1 jerarquía de un sistema de automatización industrial
Para el nivel de campo la comunicación, paralelo, cables de varios alambres e

interfaces de corriente como la de 20mA han sido ampliamente usados desde el
pasado. Las normas de comunicación serie como RS232C, RS422 y RS485 son
normalmente usadas como protocolos junto con las normas de comunicación
paralela IEEE488. Estos métodos de comunicación de punto a punto han
evolucionado a la red de comunicación de bus para cubrir con el costo de cableado

y lograr una comunicación de alta calidad.
Hoy día, el fieldbus es usado a menudo para el traslado de información en el nivel

de campo. Debido a los requisitos de tiempo que tienen que ser observado
estrictamente en un proceso de automatización, las aplicaciones en el nivel de
campo requieren control cíclico de las funciones de transporte que transmiten la
información de la fuente a intervalos de regulación. La representación de los datos
debe ser tan corta como sea posible para reducir el tiempo de transferencia del
mensaje en el bus.
Nivel de célula
En el nivel de célula, el flujo de información consiste principalmente en la carga de

programas, parámetros y datos. En procesos con pequeñas maquinas los tiempos
inactivos y reajustes, esto se hace durante el proceso de la producción. En
pequeños controles puede ser necesario cargar subprogramas durante un ciclo
industrial. Esto determina los requisitos de regulación. Para el funcionamiento del
nivel de célula, la sincronización de la máquina y el manejo de evento pueden
requerir tiempos cortos de respuestas en el bus. Estos requisitos en tiempo real no
son compatibles con excesivos tiempos de transmisión de aplicación de programas,
haciendo necesaria una adaptación de segmentación del mensaje.
Para lograr los requisitos de comunicación en este nivel, se han usado redes de
área local como la red de comunicación. Después de la introducción del concepto
de CIM y el concepto de DCCS, muchas compañías desarrollaron sus propias redes
para el nivel de célula de un sistema de automatización. El Ethernet junto con
TCP/IP ((protocolo de control de la transmisión / protocolo de Internet (transmission
control protocol / internet protocol)) fue aceptado como un factor normal para este
nivel, aunque no se puede proporcionar una verdadera comunicación en tiempo
real.
Muchos esfuerzos se han hecho para la regularización de la red de comunicación

para el nivel de célula. La norma IEEE de red basada en la arquitectura de capas
OSI y la red mini-Map fue desarrolló en los años ochenta para comprender una
comunicación normal entre los varios dispositivos de vendedores diferentes.
Algunos fieldbuses también pueden usarse para este nivel.
Nivel de área
El nivel del área consiste en células combinadas dentro de grupos. Las células están
diseñadas con aplicaciones orientadas al funcionamiento. Por los controladores de
nivel de área o operadores de control, él controlando y las funciones intermedias
están hechas como objetivos de producción, el encendido de la máquina y apagado,
y actividades de emergencia.
Nivel de planta
El nivel de planta, es el nivel de cima de una planta o un sistema de automatización

industrial. El nivel de planta de controlado reúne información de administración para
los niveles de área, y maneja todo el sistema de automatización.
Medios de transmisión.
Un factor principal al elegir una red de comunicación industrial es el tipo de sistema

de cableado físico o los medios de transmisión. Los más comunes medios de
transmisión para las redes de comunicación industrial son alambres de cobre, en la
forma de coaxial o par trenzado, fibra óptica y las tecnologías inalámbricas están
también siendo usadas.
El cable coaxial se usa para la transmisión de datos a gran velocidad en distancias

a varios kilómetros.
El cable coaxial está ampliamente disponible, relativamente barato, y puede ser

instalado y mantenido fácilmente. Por estas razones se usa ampliamente en muchas
redes de comunicación industriales.
El par trenzado puede ser usado para transmitir datos en banda base a varios Mbit/s
en distancias de 1 Km o más pero cuando la velocidad se aumenta la longitud
máxima del cable es reducida. El par trenzado se ha estado usado durante muchos
años y este también se usa ampliamente en redes de comunicación industrial. Es
menos caro que el cable coaxial, pero no proporciona alta capacidad de transmisión
o buena protección de la interferencia electromagnética.
La Fibra óptica proporciona un incremento en la capacidad de transmisión arriba de

giga bits, y es libre de la interferencia electromagnética. Sin embargo, el equipo
asociado requerido es más caro, y es más difícil de derivar para las conexiones de
multidrop. También si es usado para los cables del sensor en plantas de proceso se
requeriría separar la instalación eléctrica de cobre para los instrumento de
alimentación, que podrían también usarse para transmisión de señales.
En muchas situaciones de medición móvil o temporal, lo dispositivos inalámbrico es

una buena solución y está siendo usada ampliamente.
Métodos de transmisión
La comunicación de datos puede ser analógica o digital. Los datos analógicos toman
continuamente los cambios en el valor.
En comunicación digital, los datos pueden tomar solo valores binarios de 1 o 0.
La transmisión puede ser asíncrona o síncrona, dependiendo de la manera de envió

de los datos. En modo de transmisión asíncrona, los caracteres se envían usando
el principio y el fin del código y cada carácter puede ser enviado
independientemente a una velocidad no uniforme. El modo de transmisión síncrona

es el método más eficaz. Los datos son transmitidos en bloques de caracteres, la
salida exacta y el tiempo de llegada de cada bit son predecibles porque el reloj del
remitente y el receptor están sincronizados.
Los métodos de la transmisión en redes de comunicación industriales incluyen

banda base, banda ancha, y banda portadora. En una transmisión de banda base,
la transmisión consiste en un juego de signos que se aplican al medio de transmisión
sin estar trasladada en frecuencia.
La transmisión de banda ancha usa un rango de frecuencias que puede ser dividido
en varios canales. La transmisión portadora usa sólo una frecuencia para transmitir
y recibir información.
La transmisión digital en fibra óptica es basada en representar los unos y ceros

como pulsos de luz.
Topología de red
Tres principales topologías son empleadas para las redes de comunicación

industriales: estrella, bus y anillo como se muestra en la Figura 1.2.
Una configuración estrella contiene un control central, en que todos los nodos están
conectados directamente. Esto permite una conexión fácil para las redes pequeñas,
pero los controles adicionales deben ser agregados cuando un número máximo de
nodos se alcanza. El fallo de un nodo en una configuración de estrella no afecta
otros nodos.
En la topología bus, cada nodo es directamente unido a un canal de comunicación

común. Los mensajes transmitidos en el bus son recibidos por todos los nodos. Si
un nodo falla, el resto de la red continúa en funcionamiento siempre que el nodo
fallado no afecte los medios de comunicación.
En la topología de anillo, el cable forma una vuelta y los nodos están unidos a
intervalos alrededor de la vuelta. El mensaje es transmitido alrededor del anillo que
comunica los nodos unidos a él. Si un solo nodo falla, la red entera pudiese
detenerse a menos que un mecanismo de recuperación se lleve a cabo.
Topología estrella Topología de bus
Topología de anillo
Figura 1.2 topologías de las redes industriales
1.4 CONSIDERACIONES DE DISEÑO
El diseño de una red de comunicación involucra la planificación cuidadosa y la

evaluación de diferentes opciones de diseño. El diseñador intenta lograr un máximo
desempeño de la red a un costo razonable. Para alcanzar esta meta, los requisitos
de comunicación y consideraciones para un sistema específico de automatización
deben ser investigados.
La estrategia global y la planeación son el paso más crítico en un diseño de red de

comunicación. El sistema de automatización al cual la red de comunicación podrá
aplicarse, deber ser investigado y los objetivos para la red de comunicación serán
obtenidos. Para la planeación los factores a considerar son los siguientes.
 Costo
 Desempeño
 Fiabilidad o disponibilidad
 Servicio o funcionamiento de la Red
 Tolerancia con respecto al medio ambiente
 Medios físicos
 Expansión
 Mantenimiento
 Seguridad
Costo
El costo de conectar una red de computadoras consiste en los costos iniciales y los
costos continuos. Los costes iniciales incluyen la compra de nuevo hardware y
software, el diseño, la instalación y la puesta en marcha. Los costos continuos
incluyen el mantenimiento del hardware y software, el pago a las personas que lo
operan y arreglan la red y los costos para la expansión de la red y cambios de
configuración.
Desempeño
El buen funcionamiento de la red es esencial. Sin él, incluso las actividades de

comunicaciones normales llegan a ser difíciles y el continuo control del proceso de
las aplicaciones requiere un alto funcionamiento de cómputo y ejecución de
decisiones que llegaran a ser imposibles.
La planificación eficaz debe incluir una estimación de requisitos de funcionamiento

mínimos. La velocidad y la carga de la red son los principales factores para
considerar en análisis de desempeño. Es importante definir y analizar las
aplicaciones de la red, la operación y el tráfico en general de las comunicaciones.
Las medidas típicas del funcionamiento para las redes de comunicación incluyen lo
siguiente.
 Velocidad de transmisión. La velocidad de transmisión de la red es la

proporción a la cual los bits de información están transmitidos por el cable
de la red.
 Tiempo de respuesta. el tiempo de respuesta es el tiempo que toma realizar

una acción de respuesta para ejecutar una aplicación del usuario que ha
emitido una solicitud. Esto incluye el tiempo que toma transmitir un mensaje
y la recepción, los sistemas para procesar la solicitud y la contestación del
mensajes y el retraso de transmisión de la red.
 Utilización. La utilización del ancho de banda se refiere a la capacidad de

enlace y usualmente es representada como la proporción de capacidad en
uso. Aquí no hay ninguna regla clara para la utilización máxima de las redes
de comunicación. Ethernet con más clientes degrada exponencialmente al
35% después de la utilización continua, mientras que token ring o las redes
FDDI manejan más tráfico.
Servicio o funcionamiento de la Red
El diseñador de la red debe saber qué tipo de datos maneja la red y qué
funcionalidad se requiere para encontrar la meta. La típica funcionalidad requerida
en las redes de comunicación industriales incluye:
 Transferencia de archivos
 Terminal para conexión del host

 Descargar o cargar programas
 Descargar o cargar datos fijos
 Llamar al Programa
 Enviar y recibir datos (cortos)
 Apoyo a las aplicaciones distribuidas
Tolerancia con respecto al medio ambiente
Las redes de comunicación pueden ser a menudo armadas en zonas peligrosas y

están expuestas a ambientes rudos. Las redes de comunicación para los sistemas
de automatización industriales deben ser diseñadas para resistir interferencia
electromagnética (EMI), interferencia de radio frecuencia (RFI), atmósferas
corrosivas y de fluidos, temperaturas extremas y exposiciones a la intemperie.
En un ambiente industrial, el exceso de EMI puede causar modificaciones en los

paquetes de datos, retransmisiones frecuentes, y cargas altas en la red.
Medios Físicos
La selección de los medios físicos es una importante decisión técnica y económica,

debe contar con los requisitos de las redes establecidas.
Expansión
Pocas redes permanecen estáticas ante el rápido crecimiento de las demandas

comerciales y el desarrollo de la tecnología. El diseño de la red siempre debe
incorporar un factor de flexibilidad para su crecimiento.
Mantenimiento
Todas las redes deben tener mantenimiento y servicio. El buen diseño de la red
debe permitir un mantenimiento preventivo, actualización, y llevar a cabo
reconfiguraciones con un mínimo o ninguna ruptura de funcionamiento de la red.
Seguridad
Los principales objetivos de medidas contra los ataques de seguridad son:
Para minimizar la probabilidad de intrusión los dispositivos proporcionan protección

y procedimientos.
Para descubrir cualquier intrusión tan pronto como sea posible.
Para poder identificar la información que ha estado sujetado a vinculaciones e

identificar el estado de control, es necesario información para recuperar el enlace.
Requisitos de comunicación para los Sistemas de Automatización Industrial
Los requisitos de comunicación pueden depender del nivel en la jerarquía de los

sistemas de automatización industrial.
Comunicación en el nivel de campo
En el nivel de campo en los sistemas de automatización, las comunicaciones están

para intercambiar datos de los sensores individuales y el montón de actuadores en
un mismo equipo de control local. Los requisitos de comunicación a este nivel
incluyen lo siguiente.
Respuestas cortas en tiempo. Los tiempos de respuesta de microsegundos y

milisegundos se requieren para lazos de control rápido y apagado de las alarmas
de seguridad de los sistemas.
Tolerancia para el medio ambiente rudo. Los dispositivos de campo están

frecuentemente montados en áreas peligrosas que requieren gabinetes a prueba de
explosión, o medios intrínsecamente seguros.
Distancia larga. Debe ser posible conectar dispositivos localizados a grandes

distancias hasta los racks de terminales. Esto podría ser unos cientos de metros
dentro de un área de la planta o muchos kilómetros a distancia como en una
estación de bombeo en funcionamiento.
Distribución de energía. La energía es normalmente distribuida en un alambrado

de dos cables de señal para la mayoría de los dispositivos de campo. Esta fuente
de energía está separada de otra fuente usada en la planta, y se suministra un
respaldo de energía para su funcionamiento.
Comunicación en el nivel de célula
En el nivel de célula se encuentran los dispositivos de control, las consolas de

mando de los operadores, los nodos de campo, etc. Están comunicados entre sí.
Los requisitos de comunicación para el nivel de célula son los siguientes.
Respuestas cortas en tiempo. La respuesta en tiempo en milisegundos y

segundos se requiere para controlar la comunicación de un nodo de red a otro; para
la alarma; y para las comunicaciones del operador, donde un gran número de datos
puede pedirse al mismo tiempo.
Tolerancia para el medio ambiente rudo. Cuando una red de nodos se mueve al
campo, el hardware del sistema debe ser diseñado para resistir la interferencia
electromagnética (EMI), la interferencia de radio frecuencia (RFI), atmósferas

corrosivas y de fluidos, temperaturas extremas y exposiciones a la intemperie.
Seguridad. El acceso al sistema de control debe ser diseñado para prevenir usos
accidentales o no autorizados que puedan dañar el proceso de la planta.
Respaldo de la alimentación. En los instantes en que falla la energía normalmente

se proporciona un sistema redundante de alimentación, que pueden ser bancos de
baterías o unidades generadoras.
En general podemos concluir que el proceso para el diseño de una red es el
mostrado en la siguiente figura:
Estudio de fiabilidad
Análisis
Diseño
Implementación
Mantenimiento y
Actualización
Figura 1.3 Esquema del diseño de una red industrial
CAPITULO 2
PROTOCOLO MODBUS
INTRODUCCIÓN AL PROTOCOLO DE COMUNICACIÓN MODBUS.
LOS DOS MODOS DE TRANSMISIÓN SERIAL
TRAMAS DE MENSAJE MODBUS.
MÉTODOS DE COMPROBACIÓN DE ERROR
Presentación de uno de los protocolos más usados en la industria, este protocolo al

no ser un estándar toma varias formas dependiendo del fabricante del equipo, se
da un resumen sobre las diferencias entre un tipo de Modbus y otro, cabe mencionar
que en la actualidad debido a esta diferencia en protocolos los equipos permiten
configurar el tipo de Modbus a manejar.
2.1 Introducción al protocolo de comunicación Modbus
Los controladores programables de Modbus pueden comunicarse entre si y con

otros dispositivos instalados sobre una gran variedad de redes. Algunas de las redes
soportadas son Modicon Modbus y Modbus Plus Industrial Networks, pero el
alcance es más allá, ya que es posible comunicarse con redes estándares como
son MAP y Ethernet. Estas redes son acezadas por puertos construidos por el
controlador o por adaptadores de red, módulos opcionales y puertas de enlace que
son disponibles por Modicon.
El lenguaje común usado por todos los controladores Modicon es el protocolo
Modbus, este protocolo define una estructura de mensaje que el controlador
reconocerá y usara, sin tener en cuenta sobre el tipo de red que estén montados los
dispositivos, describiremos el proceso que usa un controlador para pedir acceso a
otro dispositivo, como responderá a las peticiones de otros dispositivos y como los
errores serán detectados y reportados todo esto establecerá un formato común para
el tamaño y contenido de cada mensaje.
El protocolo de comunicación Modbus proporciona el estándar interno que usan los

controladores Modicon para transmitir mensajes. Durante la comunicación en una
red Modbus el protocolo determina como cada controlador conocerá la dirección de
los dispositivos, reconocerá un mensaje para el, determinara el tipo de acción a
tomar y la forma de extraer todo los datos o información contenida en el mensaje,
si una respuesta es requerida el controlador creara esta y la enviara bajo protocolo
Modbus.
Usando Modbus sobre otras redes, el mensaje que contiene la información en

Modbus es introducida en la trama o mensaje que es usado por esta red. Por
ejemplo el controlador de Modicon para Modbus Plus o para MAP, con aplicaciones
software como son librerías y drivers proporcionan la conversión entre el mensaje
empaquetado de Modbus y la trama o mensaje utilizado por esta red para
comunicarse entre sus diferentes nodos
Esta conversión también es ampliada para resolver direccionamiento de nodos,
direcciones de ruteo, método para la detección de error especifico para cada red,
por ejemplo el dispositivo de Modbus con una dirección especifica, contenida en el
protocolo Modbus será convertida en la dirección de nodo previo a la transmisión
del mensaje, los campos de detección de error serán aplicados también a los
paquetes de mensaje, compatible con el protocolo de esta red en el punto final del
envió, sin embargo por ejemplo un controlador, el contenido del mensaje
empaquetado. Escrito usando Protocolo Modbus define la acción que será tomada
por el dispositivo al cual se le esta atendiendo.
La figura 2.1 muestra como pueden ser conectados algunos dispositivos en una
jerarquía de redes que emplean técnicas de comunicación ampliamente diferentes.
En el intercambio de mensajes, el protocolo Modbus insertado en cada paquete de
la red específica proporciona el lenguaje común mediante el cual cada dispositivo
intercambia los datos.
Host
Procesador
MAP
984-985 Programador
(Modbus Modbus P230
Plus) y
S980 (MAP)
Modbus Plus
AT/MC-984 984 A/B y BM85

y Host/MMI S985
Modbus Modbus
Programador
P230
Cuatro dispositivos
Modbus o 4 redes.
Figura 2.1 Diagrama general de una posible aplicación con el protocolo Modbus
Intercambio de Información en Una red Modbus
Los puertos de Modbus estándar sobre controladores Modicon usan una interfase
serial compatible con RS-232 que define los pines de entrada y salida, el cableado,
los niveles de señal velocidad de transmisión en bauds y el chequeo de la paridad,
los controladores pueden ser conectados a la red directamente o vía MODEM.
La comunicación de los controladores Modbus usan una técnica de maestro-

esclavo, en donde solo un dispositivo denominado (el maestro) puede iniciar
transferencias (llamadas preguntas). Los otros dispositivos (los esclavos)

responderán proporcionando los datos solicitados por el maestro
El maestro puede direccional esclavos individuales, o puede iniciar un mensaje a
todos los dispositivos esclavos (broadcast). Los esclavos regresan un mensaje
(llamado respuesta) a preguntas que son dirigidas a ellos individualmente.
Los esclavos no regresaran respuestas cuando el maestro envía un mensaje a

todos los dispositivos (un broadcast).
El Protocolo Modbus establece el formato para las preguntas de los dispositivos

maestros realizan poniendo en la pregunta la dirección del dispositivo al cual desea
comunicarse (o pone una dirección de broadcast), un código de acciones definen la
acción de respuesta, así como cada dato a ser enviado, y un campo de chequeo de
error. Los mensajes de respuesta de los dispositivos esclavos son construidos
usando solo protocolo Modbus. Estos mensajes contienen campos confirmando la
acción tomada, cualquier dato que sea necesario regresar, y un campo de chequeo
de error. Si un error ocurre en la recepción del mensaje, o si el dispositivo esclavo
no es capaz de realizar la respuesta a la petición, el dispositivo esclavo construirá
un mensaje de error y enviara esto como una respuesta.
Intercambio de Información sobre redes diferentes a una red Modbus
En adición a sus capacidades estándares de Modbus, Algunos modelos de

controladores pueden comunicarse sobre Modbus Plus usando puertos de
expansión o adaptadores de red, y sobre MAP, usando adaptadores de red.
Sobre este tipo de redes, los controladores comunican mediante una técnica de par
a par, en donde cualquier controlador puede iniciar envíos con los otros
controladores. Así un controlador puede operar como un esclavo o como un maestro
en envíos diferentes.
Múltiples rutas internas son frecuentemente proporcionadas para permitir

concurrentes procesos de intercambio de maestro a esclavo.
En el nivel de mensajes, El protocolo Modbus aplica todavía el principio de maestro

esclavo aunque el método de comunicación de la red sea par a par si un controlador
origina un mensaje, lo hace como un dispositivo maestro y espera una respuesta de
un dispositivo configurado como esclavo. De la misma forma, cuando un dispositivo
recibe un mensaje, construye una respuesta (como dispositivo esclavo) y regresa el
mensaje al controlador original.
Mensaje de pregunta del maestro

Dirección del dispositivo Dirección del dispositivo
Código de función Código de función
8 bits 8 bits
Bytes de datos Bytes de datos
Chequeo de error Chequeo de error

Mensaje de respuesta del maestro
Figura 2.2 el ciclo de pregunta y respuesta maestro – esclavo.
La pregunta: La función de código en la pregunta le indica al dispositivo esclavo

direccionado el tipo de acción a realizar. Los bytes de datos contienen cualquier
información adicional que el esclavo necesitará para llevar a cabo la función. Por
ejemplo el código de función 03 pedirá al esclavo que lea registros sostenidos
(holding registers.) y responda con sus contenidos. El campo de datos debe
contener la información que indique al esclavo en qué registro debe comenzar y
cuántos a de leer. El campo de comprobación de error proporciona un método para

que el esclavo valide la integridad del contenido del mensaje recibido.
La Respuesta: Si el esclavo elabora una respuesta normal, el código de función

contenido en la respuesta es una réplica del código de función enviado en la
petición. Los bytes de datos contienen los datos recolectados por el esclavo, tales
como valores de registros o estados. Si ocurre un error, el código de función
contenido en la respuesta es diferente al código de función enviado en la petición,
para indicar que la respuesta es una respuesta de error y los bytes de datos
contienen un código que describe el error. El campo de comprobación de error
permite al maestro confirmar que los contenidos del mensaje son válidos.
2.2 Los dos modos de transmisión serial
Los controladores pueden ser configurados para comunicar sobre redes standard
Modbus utilizando cualquiera de los dos modos de transmisión: ASCII o RTU. Los
usuarios seleccionan el modo deseado, junto con los parámetros de comunicación
del puerto serie (velocidad, paridad, etc), durante la configuración de cada
controlador. El modo y los parámetros serie deben ser los mismos para todos los
dispositivos conectados a una red Modbus. La selección del modo ASCII o RTU
tiene que ver únicamente con redes Modbus standard. Define los bits contenidos en
los campos del mensaje transmitido en forma serie en esas redes. Determina cómo
debe ser empaquetada y decodificada, la información en los campos del mensaje.
En otras redes como MAP y Modbus Plus, los mensajes Modbus son situados en
tramas sin relación con la transmisión serie. Por ejemplo una solicitud para leer
registros sostenidos (holding reg.) puede ser manejada entre dos controladores en
Modbus Plus, con independencia de la configuración actual de los puertos serie
Modbus de ambos controladores.
Modo ASCII
Cuando los controladores se configuran para comunicar en una red Modbus según
el modo ASCII (American Standard Code for Information Interchange), cada byte –
8 bits - en un mensaje se envía como dos caracteres ASCII. La principal ventaja de
este modo es que permite intervalos de tiempo de hasta un segundo entre
caracteres sin dar lugar a error.
El formato para cada byte en modo ASCII es:
Sistema de codificación: Hexadecimal, caracteres ASCII 0-9, A-F

un carácter hexadecimal contenido en
cada carácter ASCII del mensaje.
Bits por byte: 1 bit de arranque.

7 bits de datos, el menos significativo se
envía primero.
1 bit para paridad Par o Impar; ningún bit
para No paridad.
1 bit de paro si se usa paridad; 2 bits si no
se usa paridad.
Campo de Chequeo de error: Comprobación Longitudinal

Redundante (LRC).
Modo RTU
Cuando los controladores son configurados para comunicar en una red Modbus
usando el modo RTU (Remote Terminal Unit), cada byte de 8 bits en un mensaje
contiene dos dígitos hexadecimales de 4 bits. La principal ventaja de este modo es
que su mayor densidad de carácter permite mejor rendimiento que el modo ASCII
para la misma velocidad. Cada mensaje debe ser transmitido en un flujo continuo.
El formato para cada byte en modo RTU es:
Sistema de codificación: Binario 8-bits, hexadecimal 0-9, A-F.

Dos dígitos hexadecimales contenidos en
cada campo de 8 bits del mensaje.
Bits por byte: 1 bit de arranque.

8 bits de datos, el menos significativo se
envía primero.
1 bit para paridad Par o Impar; ningún bit
para No paridad.
1 bit de paro si se usa paridad; 2 bits si no
se usa paridad.
Campo de Chequeo de error: Comprobación Cíclica Redundante (CRC).
En cualquiera de los modos de transmisión serie (ASCII o RTU), un mensaje

Modbus es situado por el dispositivo que transmite, en una trama que tiene un
comienzo y un final conocidos. Esto permite a los dispositivos receptores comenzar
en el arranque del mensaje, leer la parte de la dirección y determinar qué dispositivo
es direccionado (o todos los dispositivos si es una difusión ‘dirección = 0’) y conocer
cuándo se ha completado el mensaje. Mensajes parciales pueden ser detectados y
establecer errores como resultado.
En redes como MAP o Modbus Plus, el protocolo de red manipula la trama de los
mensajes con delimitadores de comienzo y final que son específicos de la red. Esos
protocolos también manipulan el envío al dispositivo de destino, haciendo
innecesario el campo de la dirección Modbus integrado en el mensaje para la
transmisión actual. (La dirección modbus es convertida a una dirección de nodo de
la red y enrutada por el controlador remitente o sus adaptadores de red.)
2.3 Tramas de mensaje Modbus.

Trama ASCII
En modo ASCII, los mensajes comienzan con un carácter ( : ) ‘dos puntos’ (ASCII
3A hex) y terminan con un par de caracteres (CRLF) ‘Retorno de Carro + Avance
de Línea) (ASCII 0D hex y 0A hex).
Los caracteres a transmitir permitidos para todos los demás campos son 0-A, A-F
hexadecimal. Los dispositivos conectados en red monitorizan el bus de red
continuamente para detectar un carácter ‘dos puntos’. Cuando se recibe, cada
dispositivo decodifica el próximo campo (el campo de dirección) para enterarse si
es el dispositivo direccionado.
Pueden haber intervalos de hasta un segundo entre caracteres dentro del mensaje.
Si transcurre más tiempo entre caracteres, el dispositivo receptor asume que ha
ocurrido un error.
Se muestra una trama de mensaje típica.
Figura 2.3 trama de mensaje ASCII
Excepción: Con los controladores 584 y 984A/B/X, un mensaje ASCII puede

terminar normalmente después del campo LRC sin enviar los caracteres CRLF. En
ese caso, debe tener lugar una pausa de al menos 1 segundo. Si esto sucede, el
controlador asumirá que el mensaje ha terminado normalmente.
Trama RTU
En modo RTU, los mensajes comienzan con un intervalo silencioso de al menos 3.5
tiempos de carácter. Esto es más fácilmente implementado como un múltiplo de
tiempos de carácter a la velocidad de transmisión configurada en la red (mostrado
como T1-T2-T3-T4 en la figura 2.4). El primer campo transmitido es entonces la
dirección del dispositivo destinatario.
Los caracteres a transmitir permitidos para todos los campos son 0-A, A-F
hexadecimal. Los dispositivos conectados en red monitorizan el bus de red
continuamente incluso durante los intervalos ‘silencioso’. Cuando el primer campo
(el campo de dirección) es recibido, cada dispositivo lo decodifica para enterarse si
es el dispositivo direccionado.
Siguiendo al último carácter transmitido, un intervalo de al menos 3.5 tiempos de

carácter señala el final del mensaje. Un nuevo mensaje puede comenzar después
de este intervalo.
La trama completa del mensaje debe ser transmitida como un flujo continuó. Si un
intervalo silencioso de más de 1.5 tiempos de carácter tiene lugar antes de
completar la trama, el dispositivo receptor desecha el mensaje incompleto y asume
que el próximo byte será el campo de dirección de un nuevo mensaje.
De forma similar, si un nuevo mensaje comienza antes de que transcurran 3.5

tiempos de carácter después de un mensaje previo, el dispositivo receptor lo
considerará una continuación del mensaje previo. Esto dará lugar a un error, ya que
el valor en el campo final CRC no será válido para el mensaje combinado.
Aquí se muestra una trama de mensaje típica.

Figura 2.4 trama de mensaje RTU
Cómo es Manipulado el Campo Dirección
El campo dirección de un mensaje contiene dos caracteres (ASCII) u ocho bits

(RTU). Las direcciones de esclavo válidas están en el rango de 0 – 247 decimal.
Los dispositivos esclavos individuales tienen direcciones asignadas en el rango 1 –
247. Un maestro direcciona un esclavo situando la dirección del esclavo en el campo
dirección del mensaje. Cuando el esclavo envía su respuesta, sitúa su propia
dirección en este campo dirección de la respuesta para dar a conocer al maestro
qué esclavo está respondiendo.
La dirección 0 es utilizada para dirección difusión, la cual todos los dispositivos

esclavos reconocen. Cuando el protocolo Modbus es usado en redes de nivel más
alto, las difusiones pueden no estar permitidas o pueden ser reemplazadas por otros
métodos. Por ejemplo, Modbus Plus utiliza una base de datos global compartida
que puede ser actualizada con cada rotación del testigo.
Cómo es Manipulado el Campo Función
El campo código de función de una trama de mensaje contiene dos caracteres

(ASCII) u ocho bits (RTU). Los códigos válidos están en el rango de 1 – 255 decimal.
De esos, algunos códigos son aplicables a todos los controladores Modicon,
mientras que algunos códigos se aplican sólo en algunos modelos y otros están
reservados para usos futuros. Los códigos actuales se describen en el Capítulo 2.
Cuando un mensaje es enviado desde un maestro a un dispositivo esclavo, el

campo del código de función indica al esclavo qué tipo de acción ha de ejecutar.
Por ejemplo: leer los estados ON/OFF de un grupo bobinas o entradas discretas;
leer el contenido de datos de un grupo de registros; leer el status de diagnóstico de
un esclavo; escribir en determinadas bobinas o registros; o permitir cargar, salvar o
verificar el programa dentro del esclavo.
Cuando el esclavo responde al maestro, utiliza el campo del código de función para
indicar bien una respuesta normal (libre de error) o que algún tipo de error ha tenido
lugar (denominado respuesta de excepción). Para una respuesta normal, el esclavo
simplemente replica el código de función original. Para un respuesta de excepción,
el esclavo devuelve un código que es equivalente al código de función original con
su bit más significativo puesto a valor 1. Por ejemplo, un mensaje desde un maestro
a un esclavo para leer un grupo de registros sostenidos tendría el siguiente código
de función:
0000 0011 (Hexadecimal 03)
Si el dispositivo esclavo ejecuta la acción solicitada, sin error, devuelve el mismo

código en su respuesta. Si ocurre una excepción. Devuelve:
1000 0011 (Hexadecimal 83)
Además de la modificación del código de función para una respuesta de excepción,

el esclavo sitúa un único código en el campo de datos del mensaje respuesta. Esto
indica al maestro qué tipo de error ha tenido lugar, o la razón para la excepción.
El programa de aplicación del maestro tiene la responsabilidad de manejar las

respuestas de excepción. Procedimientos típicos son: enviar subsiguientes
reintentos de mensaje, intentar mensajes de diagnóstico al esclavo y notificar
operadores.
Contenido del Campo Datos
El campo datos se construye utilizando conjuntos de 2 dígitos hexadecimales, en el

rango de 00 á FF hexadecimal. Pueden formarse a partir de un par de caracteres
ASCII o desde un carácter RTU, de acuerdo al modo de transmisión serie de la red.
El campo datos de los mensajes enviados desde un maestro a un esclavo, contiene

información adicional que el esclavo debe usar para tomar la acción definida por el
código de función. Esto puede incluir partes como direcciones discretas y de
registros, la cantidad de partes que han de ser manipuladas y el cómputo de bytes
de datos contenidos en el campo.
Por ejemplo, si el maestro solicita a un esclavo leer un grupo de registros sostenidos

(código de función 03), el campo de datos especifica el registro de comienzo y
cuántos registros han de ser leídos. Si el maestro escribe sobre un grupo de
registros en el esclavo (código de función 10 hexadecimal), el campo datos
especifica el registro de comienzo, cuántos registros escribir, el cómputo de bytes
de datos que siguen en el campo datos y los datos que se deben escribir en los
registros.
Si no ocurre error, el campo datos de una respuesta desde un esclavo al maestro

contiene los datos solicitados. Si ocurre un error, el campo contiene un código de
excepción que la aplicación del maestro puede utilizar para determinar la próxima
acción a tomar.
El campo datos puede ser inexistente (de longitud cero) en ciertos tipos de
mensajes. Por ejemplo, en una petición de un dispositivo maestro a un esclavo para
que responda con su anotación de eventos de comunicación (Código de función 0B
hexadecimal), el esclavo no requiere ninguna información adicional. El código de
función por sí solo especifica la acción.
Contenido del Campo Comprobación de Error

Dos tipos de métodos de comprobación de error son utilizados para las redes
Modbus Standard. El contenido del campo Comprobación de Error depende del
método que esté siendo utilizado.
ASCII
Cuando el modo ASCII es usado para trama de carácter, el campo Comprobación
de Error contiene dos caracteres ASCII. Los caracteres de comprobación de error
son el resultado de un cálculo Comprobación Longitudinal Redundante (LRC) que
es realizado sobre el contenido del mensaje, excluyendo los ‘dos puntos’ del
comienzo y los caracteres CRLF de finalización.
Los caracteres LRC son añadidos al mensaje como el último campo que precede a
los caracteres CRLF.
RTU
Cuando el modo RTU es usado para trama de carácter, el campo Comprobación de
Error contiene un valor de 16 bits implementado como dos bytes de 8 bits. El valor
de comprobación de error es el resultado de un cálculo Comprobación Cíclica
Redundante (CRC) realizado sobre el contenido del mensaje.
El campo CRC es añadido al mensaje como último campo del mensaje.
La forma de hacerlo es, añadir primero el byte de orden bajo del campo, seguido
del byte de orden alto. El byte de orden alto del CRC es el último byte a enviar en el
mensaje.
Hay información adicional sobre comprobación de error mas adelante en este

capítulo. Se muestran los pasos detallados para generar los campos LRC y CRC en
el Apéndice C.
Cómo son Transmitidos los Caracteres en Serie
Cuando los mensajes son transmitidos sobre redes serie standard Modbus, cada
carácter o byte es enviado en este orden (izquierda a derecha):
Bit Menos Significativo (LSB) ... Bit Mas Significativo (MSB)
Con trama de carácter ASCII, la secuencia de bit es:
Figura 2.5 Orden de bits ASCII
Con trama de carácter RTU, la secuencia de bit es:
Figura 2.6 Orden de bits RTU
2.4. Métodos de Comprobación de Error

Las redes series standard Modbus utilizan dos tipos de comprobación de error. La
comprobación de paridad (par o impar) puede ser aplicada opcionalmente a cada
carácter. La comprobación de la trama (LRC o CRC) es aplicada al mensaje
completo. Ambas comprobaciones, de carácter y de trama de mensaje son
generadas en el dispositivo maestro y aplicadas a los contenidos del mensaje antes
de la transmisión. El dispositivo esclavo comprueba cada carácter y la trama del
mensaje completo durante la recepción.
El maestro es configurado por el usuario para aguardar durante un tiempo de espera

predeterminado antes de abortar la transacción. Este intervalo es establecido para
ser lo suficientemente largo para que cualquier esclavo responda normalmente. Si
el esclavo detecta un error de transmisión, el mensaje no será tenido en cuenta. El
esclavo no construirá una respuesta para el maestro. Así el tiempo de espera
expirará y permite al programa del maestro tratar el error. Observe que un mensaje
direccionado a un dispositivo esclavo inexistente también causará un error de
tiempo excedido - time out -.
Otras redes tales como MAP y Modbus Plus utilizan comprobación de trama a un
nivel por encima del contenido Modbus del mensaje. En esas redes, el campo de
comprobación LRC o CRC del mensaje Modbus no se aplica. En caso de error de
transmisión, el protocolo de comunicación específico a esas redes notifica al
dispositivo que inició la comunicación que ha ocurrido un error y le permite reintentar
o abortar de acuerdo a cómo ha sido configurado. Si el mensaje ha sido enviado,
pero el dispositivo esclavo no puede responder, puede ocurrir un error de tiempo
excedido que puede ser detectado por el programa del maestro.
Control de Paridad
Los usuarios pueden configurar los controladores para Control de paridad Par o
Impar, o Sin Control de paridad. Esto determinará cómo será iniciado el bit de
paridad en cada carácter. Si se especifica cualquier control de paridad Par o Impar,
se contabilizará la cantidad de bits que tienen valor 1 en la porción de datos de cada
carácter (siete bits de datos para modo ASCII, u ocho para RTU). Al bit de paridad
habrá de darse valor 0 o 1, para que se obtenga finalmente un número par o impar,
respectivamente, de bits con valor 1.
Por ejemplo, estos 8 bits de dato forman parte de una trama de carácter RTU:
1100 0101
La cantidad de bits de valor 1 en el dato es cuatro. Si se utiliza Control de Paridad

Par, el bit de paridad de la trama debe establecerse a valor 0, haciendo que la
cantidad de bits de valor 1 siga siendo un número par (cuatro). Si se utiliza Control
de Paridad Impar, el bit de paridad deberá tener valor 1, resultando una cantidad de
bits de valor 1, impar (cinco).
Cuando el mensaje es transmitido, el bit de paridad es calculado y aplicado a la

trama de cada carácter. El dispositivo receptor cuenta la cantidad de bits de valor 1
y establece un error si no coincide la paridad con la configurada para ese dispositivo
(todos los dispositivos en la red Modbus deben ser configurados para usar el mismo
método de Control de paridad).
Obsérvese que la comprobación de paridad sólo detecta si un número impar de bits

se han alterado en una trama de carácter durante la transmisión. Por ejemplo, si se
utiliza control de paridad Impar y dos bits de valor 1 de un carácter que tiene en
origen 3 bits con valor 1, han quedado falseados (pasan a valor 0) durante la
transmisión, el resultado es todavía un cómputo impar de bits de valor 1 (y por lo
tanto el error no es detectado por este método).
Si se especifica control No Paridad, no se transmite bit de paridad y no se hace

comprobación de paridad. Se transmite un bit de paro adicional para rellenar la
trama de carácter.
Comprobación LRC
En modo ASCII, los mensajes incluyen un campo de comprobación de error que

está basado en un método de Comprobación Longitudinal Redundante (LRC). El
campo LRC controla el contenido del mensaje, a excepción de los ‘:’ del comienzo
y el par CRLF. Es aplicado con independencia de cualquier método de control de
paridad utilizado para los caracteres individuales del mensaje.
El campo LRC es un byte, conteniendo un valor binario de ocho bits. El valor LRC
es calculado por el dispositivo emisor, que añade el LRC al mensaje. El dispositivo
receptor calcula el LRC durante la recepción del mensaje y compara el valor
calculado con el valor recibido en el campo LRC. Si los dos valores no son iguales,
resulta un error.
El valor LRC se calcula sumando entre sí los sucesivos bytes del mensaje,
descartando cualquier acarreo y luego complementando a dos el valor resultante.
Se realiza sobre el contenido del campo de mensaje ASCII excluyendo el carácter
‘:’ de comienzo del mensaje y excluyendo el par CRLF de final de mensaje.
En la lógica de programación de controladores, la función CKSM calcula el LRC en

base al contenido del mensaje. Para aplicaciones con ordenadores, se acompaña
un ejemplo detallado sobre la generación del LRC, en el Apéndice C.
Comprobación CRC
En modo RTU, los mensajes incluyen un campo de comprobación de error que está
basado en un método Comprobación de Redundancia Cíclica (CRC). El campo CRC
controla el contenido del mensaje completo. Se aplica con independencia de

cualquier método de control de paridad utilizado para los caracteres individuales del
mensaje.
El campo CRC es de dos bytes, conteniendo un valor binario de 16 bits. El valor

CRC es calculado por el dispositivo emisor, que añade el CRC al mensaje. El
dispositivo receptor calcula el CRC durante la recepción del mensaje y compara el
valor calculado con el valor recibido en el campo CRC. Si los dos valores no son
iguales, resulta un error.
Para calcular el valor CRC Modbus se precarga un registro de 16 bits, todos ellos a
1. Luego comienza un proceso que toma los sucesivos bytes del mensaje y los
opera con el contenido del registro y actualiza éste con el resultado obtenido. Sólo
los 8 bits de dato de cada carácter son utilizados para generar el CRC. Los bits de
arranque y paro y el bit de paridad, no se tienen en cuenta para el CRC.
Durante la generación del CRC, se efectúa una operación booleana OR exclusivo

(XOR) a cada carácter de 8 bits con el contenido del registro. Entonces al resultado
se le aplica un desplazamiento de bit en la dirección de bit menos significativo (LSB),
rellenando la posición del bit más significativo (MSB) con un cero. El LSB es extraído
y examinado. Si el LSB extraído fuese un 1, se realiza un XOR entre el registro y un
valor fijo preestablecido (*). Si el LSB fuese un 0, no se efectúa la función XOR (OR
exclusiva).
Este proceso es repetido hasta haber cumplido 8 desplazamientos. Después del

último desplazamiento (el octavo), el próximo byte es operado XOR con el valor
actual del registro y el proceso se repite con ocho desplazamientos más, como se
ha descrito mas arriba y así con todos los bytes del mensaje. El contenido final del
registro, después de que todos los bytes del mensaje han sido procesados, es el
valor del CRC.
Cuando el CRC es añadido al mensaje, primero se añade el byte de orden bajo

seguido del byte de orden alto.
En la lógica de programación de controladores, la función CKSM calcula el CRC en

base al contenido del mensaje. Para aplicaciones con ordenadores, se acompaña
un ejemplo detallado sobre la generación del CRC, en el Apéndice C.
(*) El valor preestablecido es A001 hex, correspondiente al polinomio generador

CRC16
‘Inverso’, que es el que se aplica al CRC Modbus.
CAPITULO 3
DATOS Y FUNCIONES DE CONTROL
RESUMEN SOBRE LAS FUNCIONES DE CONTROL
DETALLES DE LAS FUNCIONES MODBUS
Este capitulo pretende dar un panorama de las funciones que realiza un controlador
Modbus, de cómo un maestro realiza las peticiones y como es la respuesta de un
dispositivo esclavo. Así como la explicación de cual es el propósito de cada función
y los controladores que soportan a dichas funciones.
3.1 Formato de las Funciones Modbus
Cómo son expresados los valores numéricos
A menos que se especifique otra cosa, los valores numéricos (tales como
direcciones, códigos, o datos) se expresan como valores decimales en el texto de
esta sección. Son expresados como valores hexadecimales en los campos del
mensaje de las figuras.
Direcciones en los Mensajes Modbus
Todos las direcciones en los mensajes Modbus son referenciadas a cero. La primera
unidad de cada tipo de dato es direccionada como parte número cero. Por ejemplo:
La bobina conocida como ‘bobina 1 ‘en un controlador programable es direccionada

como bobina 0000 en el campo de dirección de un mensaje Modbus.
La bobina 127 decimal es direccionada como bobina 007E hex (126 decimal).
El registro mantenido 40001 es direccionado como registro 0000 en el campo de

dirección de un mensaje Modbus. El campo código de función ya especifica una
operación sobre un ’registro mantenido’. Por lo tanto la referencia ‘4XXXX’ está
implícita.
El registro mantenido 40108 es direccionado como registro 006B hex (107 decimal).
Campos contenidos en los Mensajes Modbus
La figura 3.1 muestra un ejemplo de un mensaje de petición Modbus. La figura 3.2

es un ejemplo de una respuesta normal. Ambos ejemplos muestran los campos
contenidos en hexadecimal y también cómo estaría distribuido en la trama, un
mensaje en modo ASCII o en modo RTU.
La petición del maestro es una solicitud de Lectura de Registros sostenidos, al

dispositivo esclavo con dirección 06. El mensaje solicita datos numéricos de tres
registros sostenidos, 40108 al 40110.
Observe que el mensaje especifica la dirección de comienzo como 0107 (006B hex).
La respuesta del esclavo replica el código de función, indicando que esto es una
respuesta normal. El campo ‘Cómputo de Bytes’ especifica cuántas unidades de
datos de 8 bits se devuelven. Muestra la cantidad de bytes de datos que vienen a
continuación, bien ASCII o RTU. En el modo ASCII, este valor representa la mitad
del cómputo real de caracteres ASCII en el dato, ya que en este modo, cada dígito
hexadecimal de 4 bits requiere un carácter ASCII y por lo tanto, debe haber dos
caracteres ASCII para contener cada unidad de dato de 8 bits.
Por ejemplo, el dato: 63 hex se envía como un byte – ocho bits - en modo RTU
(0110 0011).
El mismo valor, enviado en modo ASCII requiere dos caracteres ASCII, el ASCII ‘6’
(011 0110) y el ASCII ‘3’ (011 0011). El campo ‘Cómputo de bytes’ contabiliza este
dato como una sola de dato de 8 bits , con independencia del método de trama de
carácter (ASCII o RTU).
Cómo Usar el Campo Cómputo de Bytes: Cuando se construyan respuestas en

buffer, ponga en el campo correspondiente al Cómputo de Bytes un valor igual a la
cantidad de bytes de datos contenidos en su mensaje (2 x nº de datos a enviar -
byte alto y byte bajo de cada dato - ).
La figura 11 muestra cómo se implementa el cómputo de Bytes en una respuesta
típica
Figura 3.1 pregunta típica
Figura 3.2 Respuesta típica
Campos contenidos en los mensajes sobre Modbus Plus

Los mensajes Modbus enviados sobre redes Modbus Plus están integrados en la
trama dentro del nivel Logical Link Control (LLC). Los campos del mensaje Modbus
sobre Modbus Plus consisten en bytes de 8 bits de forma similar a la utilizada con
la trama RTU.
El campo Dirección del Esclavo es convertido en un enrutamiento (‘ROUTING

PATH’) por el dispositivo emisor. El campo CRC no se envía en el mensaje Modbus,
porque sería redundante con la comprobación CRC realizada en el nivel High-level
Data Link Control (HDLC).
El resto del mensaje permanece como en el formato serie Standard. El software de

aplicación (Bloques MSTR en los controladores, o Modcom III en ordenadores)
manipula la trama del mensaje en una red de paquetes.
La figura 3.3 muestra cómo se integraría una petición Leer Registros sostenidos en
una trama para transmisión Modbus Plus.
Figura 3.3 contenido de los campos en Modbus Plus
3.2 Código de funciones soportadas por los controladores
El listado de más abajo muestra los códigos soportados por los controladores
Modicon. Los códigos se listan en decimal.
‘Y’ indica que la función está soportada. ‘N’ indica que no está soportada.
Código Nombre 384 484 584 884 M84 984

01 Leer Estados de Bobinas Y Y Y Y Y Y
02 Leer Estados de Entradas Y Y Y Y Y Y
03 Leer Registros sostenidos Y Y Y Y Y Y
04 Leer Registros de Entradas Y Y Y Y Y Y
05 Forzar una única Bobina Y Y Y Y Y Y
06 Preestablecer un único Registro Y Y Y Y Y Y
07 Leer Status de Excepción Y Y Y Y Y Y
08 Diagnosticos (ver Capítulo 3)
09 Programar 484 N Y N N N N
10 Selección 484 N Y N N N N
11 Buscar Contador de Eventos de Y N Y N N Y
Comunicación
12 Buscar Anotac de Eventos de Comunic Y N Y N N Y
13 Programar Controlador Y N Y N N Y
14 Selección Controlador Y N Y N N Y
15 Forzar Múltiples Bobinas Y Y Y Y Y Y
16 Preestablecer Múltiples Registros Y Y Y Y Y Y
17 Reportar Identificación de Esclavo Y Y Y Y Y Y
18 Programar 884/M84 N N N Y Y N
19 Resetear Enlace de Comunicaciones N N N Y Y N
20 Leer Referencia General N N Y N N Y
21 Escribir Referencia General N N Y N N Y
22 Escribir con máscara en Registros 4X N N N N N (1)
23 Leer/Escribir Registros 4X N N N N N (1)
24 Leer Cola FIFO N N N N N (1)
(1) Funciones soportadas solo en el 984-785
01 Lectura del estatus de una bobina

Lee el estatus de ON/OFF de salidas discretas en el esclavo (referencia OX,
bocinas).
El apéndice B muestra los parámetros máximos soportados por varios modelos de

controladores.
Pregunta
El mensaje de pregunta especifica la bobina de inicio y la cantidad de bobinas que

serán leídas.
Las bobinas son direccionadas iniciando en cero: bobinas del 1 -16 son
direccionadas como 0-15.
A continuación un ejemplo de una petición para leer las bobinas 20-56 del esclavo
17:
Figura 3.4 pregunta para la lectura de estatus de una bobina
Respuesta
Los estatus de las bobinas en el mensaje es empaquetado como una bobina por bit
de el campo de dato, Los estados son indicados como 1= ON; 0=OFF, el bit menos
significativo de el primer byte de datos contiene la bobina direccionada en la
pregunta, las otras bobinas siguen hacia el extremo del orden alto de este byte, y
de ‘el orden bajo al orden alto ' en los bytes subsecuentes.
Si la cantidad de bobinas regresadas no es un múltiplo de ocho, los bits sobrantes

en el final del byte de datos serán puestos en ceros (hacia el fin del byte siguiendo
el orden alto). El campo de conteo de bytes indica la cantidad de bytes de datos
completos.
Aquí el ejemplo de la respuesta a la pregunta realizada en la pagina anterior.
Figura 3.5 respuesta que entregaría un dispositivo esclavo

Los estatus de las bobinas 27-20 son mostrados como el byte con valor CD en
hexadecimal o el binario 11001102. el estatus de la bobina numero 27 es el bit mas
significativo del byte, y la bobina 20 el bit menos significativo. De izquierda a derecha
el estatus de la bobina 27 hasta la 20 son:, ON–ON–OFF–OFF–ON–ON–OFF–ON.
Por convención, el bit mas significativo del byte es puesto a la izquierda y el menos
significativo a la derecha de dicho byte. Así las bobinas en el primer byte son de la
“27 a la 20”, de izquierda a derecha. El siguiente byte tiene las bobinas “35 a la 28”
de izquierda a derecha. Como los bits son trasmitidos serialmente, estos fluyen del
bit menos significativo (LSB) a el más significativo (MSB): 20…..27, 28…..35, y así
sucesivamente.
En el ultimo byte de datos, el estatus de las bobinas son mostrados como el byte
cuyo valor es 1B en hexadecimal o 00011011 en binario. La bobina numero 56 esta
en la cuarta posición de la izquierda y la bobina numero 52 es el bit menos
significativo del byte (LSB). Los estatus de las bobinas “56 a la 52” son ON-ON-
OFF-ON-ON. Note como los 3 bit restantes bits son llenados con ceros (hacia el
extremo mas alto).
02 Lectura de estatus de entrada

Descripción
Lee los estatus de entradas discretas (referencia 1X) en el esclavo.
Para una transmisión de tipo broadcast no esta soportado este tipo de operación.
El apéndice B indica los parámetros máximos soportados por varios modelos de
controladores.
Pregunta
El mensaje de pregunta especifica el inicio de las entradas y la cantidad de entradas

a ser leídas. Entradas son direccionadas iniciando en cero: entradas de 1 a la 16
son direccionadas como 0-15.
Aquí se muestra un ejemplo de una petición para leer las estradas de 10197-10218
del dispositivo esclavo numero 17.
Figura 3.6 pregunta para la lectura del estatus de una entrada

Respuesta
Los estatus de una entradas en el mensaje de respuesta es empaquetado como

una entrada por bit del campo de datos. El estatus es indicado como: 1= ON; 0 =
OFF. El bit menos significativo del primer byte de datos contiene la entrada
direccionada en la pregunta. Las otras entradas siguen hacia el extremo mas
significativo de este byte, y de menor a mayor en los bytes subsecuentes.
Si la cantidad de status de entradas regresadas no es múltiplo de 8. los bits

sobrantes en el byte final de datos serán puestos en cero (hacia el extremo más
significativo del byte). El campo de conteo de bytes especifica la cantidad de bytes
completos de datos.
Aquí un ejemplo de la respuesta a la petición anterior.

Figura 3.7 respuesta entregada por el dispositivo
Los estatus de las entradas 10204-10197 son mostrados como el byte con valor AC
en hexadecimal, o 10101100 en binario. La entrada 10204 es el bit más significativo
de este byte, y la entrada 10197 es el bit menos significativo.
De izquierda a derecha, los estatus de las entradas 10204 hasta 10197 son: ON-
OFF-ON-OFF-ON-ON-OFF-OFF.
Los estatus de las entradas 10218-10213 son mostrados como el byte con valor 35
hexadecimal, o 00110101 binario. La entrada 10218 esta en la posición del tercer
bit de la izquierda, y la entrada 10213 es el bit menos significativo (LSB). El estatus
de las entradas 10218 hasta 10213 son ON-ON-OFF-ON-OFF-ON. Note como los
dos bits sobrantes son llenados con cero (hacia el extremo más significativo).
03 Lectura de registros sostenidos
Descripción
Lee el contenido binario de registros sostenidos (referencia 4x)
En transmisión modo broadcast esta opción no esta soportada.
controladores.
Pregunta
El mensaje de la pregunta especifica el registro de inicio y la cantidad de registros

a ser leídos. Los registros son direccionados empezando en cero: registros de 1 –
16 son direccionados como 0-15.
Aquí hay un ejemplo de una petición para leer los registros 40108 a 40110 del
dispositivo esclavo 17.
Figura 3.8 pregunta para la lectura de registros sostenidos
Respuesta
El dato del registro es empaquetado en el mensaje de respuesta como dos bytes
por registro, tonel contenido en binario correctamente justificado en cada byte. Para
cada registro, el primer byte contiene los bits de la parte alta, y el segundo contiene
los bits de la parte baja.
Los datos son revisados en el esclavo a razón de 125 registros por revisión para
controladores 984-SEX (984-685, etc), y a razón de 32 registros por revisión para el
resto de controladores. La respuesta es regresada cuando el dato es
completamente integrado.
A continuación se muestra un ejemplo de la respuesta a la pregunta anterior.

Figura 3.9 Respuesta del dispositivo.
El contenido del registro 40108 es desplegado como el valor de los dos bytes con
valor de 02 2B en hexadecimal, o 555 en decimal. El contenido de los registros
40109-40110 son 00 00 y 00 64 en hexadecimal o 0 y 100 en decimal.
04 Lectura de registro de entradas.
Descripción
Lee el contenido binario de registros de entrada en el esclavo (referencia 3X).

En el modo de transmisión broadcast no esta soportada esta función.

controladores.
Pregunta
El mensaje de petición especifica el registro de inicio y la cantidad de registros a ser

leídos, los registros son direccionados iniciando en cero: los registros de 1-16 son
direccionados como 0-15.
A continuación un ejemplo de la petición para leer el registro 30009 del dispositivo

esclavo 17.
Figura 3.10 lectura de registros de entrada
Respuesta
El dato del registro es empaquetado en el mensaje de respuesta como dos bytes

por registro, tonel contenido en binario correctamente justificado en cada byte. Para
cada registro, el primer byte contiene los bits de la parte alta, y el segundo contiene
los bits de la parte baja.
Los datos son revisados en el esclavo a razón de 125 registros por revisión para
controladores 984-SEX (984-685, etc), y a razón de 32 registros por revisión para el
resto de controladores. La respuesta es regresada cuando el dato es
completamente integrado.
A continuación se muestra un ejemplo de la respuesta a la pregunta anterior.

Figura 3.11 Respuesta a la función 04
El contenido del registro 30009 es representado con dos bytes cuyo valor es 00 0A
en hexadecimal o 10 en decimal
05 Forzar bobinas simples
Descripción
Obliga a una simple bobina a tomar alguno de sus valores ON/OFF (referencia 0X).
Cuando se usa un broadcast la función obliga a las mismas bobinas en todos los
dispositivos adjuntados al mensaje.
Nota la función sobrescribirá la memoria del controlador proteja el estado y

desactive el estado de la bobina. El estado forzado permanecerá valido hasta
que la siguiente lógica del controlador resuelva a la bobina. La bobina
permanecerá forzada si no es re-programada en la lógica del controlador.

controladores.
Pregunta
El mensaje de petición especifica la bobina a ser forzada, las bobinas son

direccionadas empezando por cero: la bobina 1 es direccionada como 0.
El estado pedido de ON ó OFF es especificado por una constante en el campo de

dato de la pregunta. Un valor de FF 00 (hexadecimal). Pide a la bobina que pase a
su estado de ON. Un valor de 00 00 pide que pase a su estado de OFF. Cualquier
otro valor es considerado ilegal y no afectara a la bobina.
A continuación un ejemplo de una petición para forzar la bobina 173 en ON en el

esclavo 17.
Figura 3.12 pregunta para forzar bobinas
Respuesta
Una respuesta normal es un eco de la pregunta, regresando después el status de

la bobina que ha sido forzado.
El siguiente ejemplo es la respuesta normal a la pregunta anterior.
Figura 3.13 Respuesta normal por parte del dispositivo.

06 Predeterminar registros simples
Descripción
Poner un valor predeterminado a un registro sostenido simple (referencia 4x).
Cuando ocurre un broadcast, la función pone la misma referencia del registro en
todos los esclavos adjuntos.
Nota la función anulara el estado de protección de memoria del controlador.

El valor fijado a este registro permanecerá valido en el registro hasta que la
lógica del controlador re defina el contenido de este.

controladores.
Pregunta
El mensaje de pregunta especifica el registro que será fijado en un valor

predeterminado. Los registros son direccionados empezando en cero: el registro 1
es el registro 0.
El valor asignado esta especificado en el campo de dato de la pregunta. Los

controladores M84 y 484 usan un valor de 10 bits con los 6 más significativos
puestos en cero. Cualquier otro controlador usa un valor de 16 bits.
A continuación un ejemplo de una petición para fijar el registro 40002 en el valor

hexadecimal 00 03 para el dispositivo esclavo 17.
Figura 3.14 pregunta para fijar registros.

Respuesta
La respuesta normal a esta solicitud es un eco de la pregunta, que es regresada

después de que el contenido del registro ha sido modificado.
Aquí se muestra la respuesta a la solicitud del ejemplo anterior.
07 Lectura de estatus de excepción
La función nos permite leer el contenido de 8 estatus de excepción en bobinas

dentro del controlador del esclavo.
Ciertas bobinas tienen asignaciones predefinidas en los diversos controladores.

Otras bobinas pueden ser programadas por el usuario para mantener información
sobre el estado de los controladores, por ejemplo, “maquina encendida/apagada”
“cabezales abiertos”, “seguridad satisfactoria”, “presencia de condiciones de error”,

o cualquier otra bandera definida por el usuario.
Por la naturaleza de la función es evidente que no es posible el broadcast.
Esta función proporciona un método simple para acceder a esta información, porque
las referencias de las bobinas de excepción son conocidas (no se necesita la
referencia de la bobina).
Las asignaciones predefinidas en las bobinas de excepción son:
Modelo del controlador Bobina Asignación

M84, 184/384, 584, 984 1-8 Definida por el usuario
484 257 Estatus de la batería.

258-264 Definido por el usuario.
884 761 Estatus de la batería.

762 Estatus de la protección a la memoria.
763 RIO estatus de salud.
764-768 Definidas por el usuario
Aquí se muestra un ejemplo de una petición para el estatus de excepción en el

Figura 3.16 pregunta para leer estatus de excepciones

Respuesta
La respuesta normal contiene el estatus de excepción de las 8 bobinas. Las bobinas
son empaquetadas en un solo byte, con un bit por bobina. El estatus de la bobina
con referencia menor es contenido en el bit menos significativo.
Aquí esta un ejemplo de la respuesta a la petición.
En este ejemplo, el dato de las bobinas es 6D que en binario corresponde a

01101101. De izquierda a derecha las bobinas son: apagado- encendido-
encendido- apagado- encendido- encendido- apagado- encendido. Los estatus son
mostrados de la bobina con la dirección más alta a la más baja.
Si el controlador es un 984, estos bits son los estatus de las bobinas 8 hasta 1.
Si el controlador es a 484, estos bits son los estatus de las bobinas 264 hasta 257.
en este ejemplo la bobina 257 esta en ON, indicando que la batería del controlador
esta en perfecto estado.
11 (0B Hexadecimal) Sacar un contador de eventos de comunicaciones
Descripción
Retorna una palabra de estatus y un contador de evento del contador de eventos

de comunicaciones del esclavo. Para traer el contador correcto antes y después de
una serie de mensajes, un dispositivo maestro puede determinar si el mensaje fue
manejado correctamente por el dispositivo esclavo.
El contador de eventos del controlador es incrementado una vez por cada mensaje
exitoso completo. Este contador no es incrementado por respuestas de excepción,
comandos de encuesta, o comandos de traída del contador de eventos de
comunicaciones.
El contador de eventos puede ser peseteado por medio de la función de diagnostico

(código 08) con una subfunción de nos da la opción de reiniciar las comunicaciones
(código 00 01) o limpiar el contador y registro de diagnostico (código 00 0A).
Pregunta
Aquí mostramos el ejemplo de una petición para traer el contador de eventos de

comunicación del dispositivo esclavo 17:
Figura 3.17 pregunta para obtener el contador de eventos en las comunicaciones.
Respuesta
La respuesta normal contiene una palabra de estatus de dos bytes y un contador de

eventos de 2 bytes. La palabra de estatus estará en unos en todos sus bits (FF FF
hexadecimal) si un comando previamente emitido aun esta siendo ejecutado por el
esclavo (una condición de ocupado existe).
Si otra condición existe la palabra contendrá solo ceros en sus bits.
Aquí se muestra la respuesta a la pregunta realizada previamente.

En este ejemplo, la palabra de ejemplo es FF FF (hexadecimal) indicando que una
función del programa esta en ejecución en el esclavo. El contador de eventos es
mostrado como 264 (01 08 hexadecimal) eventos han sido contados por el
controlador.
12 (0C Hexadecimal) Traer el registro de eventos de comunicación.
Descripción.
Regresa una palabra de estatus, contador de eventos, contador de mensajes, y un

campo de bytes de eventos del esclavo. El broadcast no esta soportado por esta
función.
La palabra de estatus y el contador de eventos son idénticos a los entregados por

la función anterior (11 0B Hexadecimal, sacar un contador de eventos de
comunicaciones).
El contador de mensajes contiene la cantidad de mensajes procesados por el

esclavo desde el ultimo reinicio, operación de limpieza de contadores, o encendido
del equipo. Este contador es idéntico al que es regresado por la función de
diagnostico (código 08), con la sub-función regresar contador de mensajes de bus
(código 11, 0B hexadecimal).
El campo de bytes de eventos contiene 0-64 bytes. En donde cada byte corresponde
al estatus de una operación Modbus enviada o recibida por el dispositivo esclavo.
Los eventos son ingresados por el esclavo dentro del campo en orden cronológico.
El byte cero es el byte con el estatus del evento más reciente. Cada nuevo byte
recorre a los demás en el campo de los 64 bytes.
Pregunta
Aquí esta un ejemplo de una petición para traer el registro de eventos de

comunicaciones para el esclavo 17:
Figura 3.19 pregunta para obtener el registro de eventos en las comunicaciones.

Respuesta
La respuesta normal contiene un campo de dos bytes con una palabra de estatus,
un campo de dos bytes con el contador de eventos, un campo de dos bytes para el
contador de mensajes, y un campo de 0-64 bytes de eventos. Un campo de contador
de bytes define la longitud de los datos en estos cuatro campos.
Aquí esta el ejemplo de la respuesta a la pregunta anterior.
En este ejemplo, la palabra de estatus es 00 00 hexadecimal, indicando que el

esclavo no esta procesando una función del programa. El contador de eventos es
mostrado como 264 (01 08 hexadecimal) eventos contados por el esclavo. El
contador de mensajes es mostrado con el número 289 (01 21 hexadecimal)
mensajes procesados por el esclavo.
El evento más reciente de comunicación es mostrado en el byte de Event 0. Este

contenido (20 hexadecimal) muestra que el dispositivo esclavo ha sido ingresado
en el modo de solo escuchar.
El evento anterior es mostrado por el campo Event 1. el contenido de este campo

(00 00) muestra que el esclavo recibió un reinicio de comunicaciones.
El esquema de los bytes de evento de la contestación se describe en la siguiente

página.
Que contienen los bytes de eventos
Un byte de evento regresado por la función de traer el registro de eventos de

comunicaciones puede ser cualquiera entre cuatro tipos. El tipo es definido por el
bit 7 (el mas significativo) en cada byte, esto puede ser definido además por el bit
6.
Eventos recibidos por el esclavo Modbus.
Este tipo de bytes de eventos son almacenados por el esclavo cuando un mensaje
de respuesta es recibido. Es almacenado antes que el esclavo procese el mensaje.
Este evento es definido por el bit 7 puesto el estado lógico de 1. Los otros bits serán
puestos con un uno lógico si las siguientes condiciones son ciertas. El esquema de
bits es:
Bit Contenido
0 No usado
1 Error de comunicación
2 No usado
3 No usado
4 Carácter desbordado
5 Actualmente en modo de solo escuchar.
6 Broadcast recibido
7 1
Eventos enviados por el esclavo Modbus

Este tipo de bytes de eventos son almacenados por el esclavo cuando este termina
de procesar un mensaje de petición. Este byte es almacenado por el esclavo si
regresa una respuesta normal o de excepción, o no responde. Este evento es
definido por el bit 7 puesto en un cero lógico, con el bit 6 puesto en uno lógico. Los
otros bits serán puestos en 1 lógico si la condición correspondiente es verdadera.
El esquema de bits es:
Bit Contenido
0 Excepción de lectura enviado (código de excepción 1-3)
1 Excepción de interrupción de esclavo (código de excepción 4)
2 Excepción de esclavo ocupado (código de excepción 5-6)
3 Excepción de programa NAK esclavo (código de excepción 4)
4 A ocurrido un error de tiempo de espera para escritura
5 Actualmente en modo de solo escuchar.
6 1
7 0
Dispositivo esclavo ingresado en modo de solo escuchar.
Este tipo de byte de evento es almacenado por el esclavo cuando entra en el modo
de solo escuchar. El evento es definido por un contenido de 04 hexadecimal. El
esquema de bits es el siguiente:
Bit Contenido
0 0
1 0
2 1
3 0
4 0
5 0
6 0
7 0
Esclavo iniciado en modo de reiniciar comunicaciones
Este tipo de bytes de eventos es almacenado por el esclavo cuando su puerto de

comunicaciones es reiniciado. El esclavo puede ser reiniciado por la función de
diagnostico (código 08), con la sub-función de reiniciar comunicación (código 00 01).
Esta función también pone al esclavo en el modo de “continuar con error” o “parar
con error”. Si el esclavo es puesto en el modo “continuar con error”, el byte de evento
es sumado al registro existente de eventos. Si el esclavo es puesto en el modo de
“parar con error”, El byte es sumado al registro y el resto del registro es borrado con
ceros.
El evento es definido por el contenido de ceros. El esquema de bits es:
Bit Contenido
0 0
1 0
2 0
3 0
4 0
5 0
6 0
7 0
15 (0F hexadecimal) forzar varias bobinas.

Descripción
Forzar cada bobina (referencia 0X) en una secuencia para ponerlas en encendido
o apagado. Esta función tiene la posibilidad de ser enviada en un broadcast lo que
ocasionara que las mismas bobinas sean forzadas en todos los esclavos de la red.
Nota la función anulara el estado de protección de memoria del controlador

y los estados de deshabilitación de las bobinas. El estado de forzamiento
permanecerá valido en el registro hasta que la lógica del controlador resuelva
los valores para cada bobina.
El apéndice B lista los parámetros máximos soportados por varios modelos de

controladores.
Pregunta
El mensaje de petición especifica la referencia de la bobina que será forzada. Las

bobinas son direccionadas comenzando en 0: es decir la bobina uno es 0.
El estado de encendido/apagado solicitado es especificado por el contenido del
campo de dato de la pregunta. Un “1” lógico en la posición de bit corresponde a un
estado de encendido de dicha bobina. Un “0” lógico indica una petición de estado
apagado.
El siguiente ejemplo muestra un ejemplo de la petición para forzar una serie de 10

bobinas iniciando en la bobina 20 (direccionada como 19 o 13 hexadecimal) en el
Los datos contenidos en la pregunta son dos bytes: CD 01 hexadecimal (1100 1101
0000 0001 binario). Los bits binarios corresponden a las bobinas en el siguiente
orden:
Bit: 1 1 0 0 1 1 0 1 0 0 0 0 0 0 0 1
Bobina 27 26 25 24 23 22 21 20 - - - - - - 29 28
El primer byte transmitido (CD hexadecimal) de las bobinas direccionadas 27-20,

con el bit menos significativo direccionando a la bobina menor (20) y que indica el
valor a ser fijado.
El siguiente byte transmitido (01 hexadecimal) de las bobinas direccionadas 29-28,

con el bit menos significativo direccionando a la bobina menor (28). Los bits no
utilizados en el último byte de datos deben ser llenados con ceros.
Figura 3.21 Pregunta para forzar varias bobinas
Respuesta
La respuesta normal regresa la dirección del esclavo, código de función, dirección

de inicio y cantidad de bobinas forzadas.
Aquí esta la respuesta a la petición anterior:

16 (10 hexadecimal) predefinir varios registros.
Descripción
Esta función pretende predefinir los valores en una secuencia de registros
sostenidos (referencia 4X). Esta función soporta ser enviada por un broadcast y
cuando esto ocurra la función fijara los mismos registros referenciados en todos los
dispositivos esclavos.
Nota la función anulara el estado de protección de memoria del controlador.

Los valores permanecerán como validos en los registros hasta que la lógica
del controlador resuelva el contenido de los registros. Los valores de los
registros se conservar si no existe una lógica en el controlador que altere
esto.
El apéndice B lista los parámetros máximos soportados por varios modelos de

controladores.
Pregunta
El mensaje de pregunta especifica las referencias de los registros que serán fijados.
Los registros son direccionados iniciando en cero: el registro “1” es diseccionado
como “0”.
Los valores solicitados para ser fijados están especificados en el campo de datos
de la pregunta. Los controladores M84 y 484 usan un valor binario de 10 bits. Con
los seis bits de más alto orden puestos a cero. Todos los demás controladores usan
un valor de 16 bits. Los datos son empaquetados como dos bytes por registro.
Aquí se muestra un ejemplo de una petición para fijar dos registros iniciando en
40002 en 00 0A y 01 02 hexadecimal respectivamente en el esclavo 17:
Figura 3.23 pregunta para fijar varios registros.
Respuesta
La respuesta normal regresa la dirección del esclavo, código de la función, dirección

de inicio, y la cantidad de registros fijados.
Aquí esta el ejemplo de la respuesta a la petición anterior:

17 (11 hexadecimal) Reportar el identificador del Esclavo.
Descripción
Regresa una descripción del tipo de controlador presente en la dirección del

esclavo, el indicador del estatus actual del controlador corriendo, y otra información
específica para el dispositivo esclavo. El broadcast no esta soportado para este tipo
de función.
Pregunta:
Aquí esta un ejemplo de una petición para reportar el identificador del dispositivo
esclavo 17:
Figura 3.25 pregunta para reportar el ID de un esclavo.
Respuesta:
El formato de una respuesta normal es mostrado en la siguiente figura. Los datos

contenidos son especificados por cada tipo de controlador. Estos datos son
mencionados en las siguientes páginas.
Resumen de los identificadores de los esclavos.
Estos son los códigos de identificadores de los esclavos regresados por los
controladores Modicon en el primer byte de los campos de datos:
identificador de esclavo Controlador

0 Micro 84
1 484
2 184/384
3 584
8 884
9 984
184/384
El controlador 184 o 384 regresa una cantidad de bytes que será 4 o 74 (4A
hexadecimal). Si el controlador esclavo de Modbus es el J346 y se encuentra
instalado apropiadamente, y la su tabla interna de PIB es normal, la cantidad de
bytes será 74. En cualquier otro caso los bytes serán 4.
Los cuatro bytes que son regresados siempre son:

Byte Contenido
1 ID del esclavo (2 para los controladores 184/384). Ver los bytes 3,4 para
más información.
2 Indicador de estatus corriendo (0= apagado, FF= encendido).
3,4 Palabra de estado:

Bit 0=0
Bit 1= estatus de protección de memoria (0= apagado, 1 = encendido)
Bit 2,3 = tipo de controlador:
Bit 2 = 0 y Bit 3 =0 indican un controlador 184.
Bit 2 = 1 y Bit 3= 0 indican un controlador 384.
Bits de 4 – 15 no usados.
Los 70 bytes adicionales regresados por un controlador J347 correctamente
instalado y tabla de PIB normal son:
Byte Contenido
5, 6 Dirección de inicio de la tabla PIB
7, 8 Numero de serie del controlador
9, 10 identificador ejecutivo
Los bytes 11 a 74 contienen a la tabla PIB. Estos datos son
validos solo si el controlador esta corriendo (ver byte 2) la tabla
contiene lo siguiente:
11,12 Numero máximo de bobinas de salida
13,14 Tabla de bobinas de salida habilitadas.
15,16 Dirección de bobina de entrada/tabla corriendo
17,18 Cantidad de bobinas de entrada.
19,20 Tabla de bobinas de entrada habilitadas.
21,22 Primer numero de picaporte (deberá ser múltiplo de 16)
23,24 Ultimo numero de picaporte (deberá ser múltiplo de 16)
25,26 Dirección de registros de entrada.

27,28 Cantidad de registros de entrada.
29,30 Cantidad de registros de salidas y registros sostenidos
31,32 Dirección de la lógica de usuario
33,34 Dirección de bobina de salida tabla RAM.
35,36 Función de inhibir mascara
37,38 Dirección de la rutina de función extendida.
39,40 Dirección de la rutina de transferencia de datos.
41,42 Dirección del vigilante de trafico
43,43 No usado
45,46 función de inhibir mascara
47,48 dirección de la tabla histórica modo A
49,50 Tabla de respuesta para impresora DX.
51,52 Cantidad de grupos de secuencia.
53,54 Dirección de las secuencias de la tabla imagen
55,56 Dirección de la secuencia RAM
57,58 Cantidad de registros 50XX
59,60 Dirección de la tabla 50XX
61,62 Dirección de bobina de salida imagen RAM
63,64 Dirección de entrada imagen RAM
65,66 Retardo de salida grupo de inicio
67,68 Retardo de salida grupo final
69,70 Línea de Watchdog
71,72 Direcciones RAM de los picaportes
73,74 Cantidad de grupos de salida retrasados
584
El controlador 584 regresa una cantidad de bytes de 9, de la siguiente manera:

Byte Contenido
1 ID del esclavo (3 para el 584)
2 Indicador de estatus corriendo (0= apagado, FF= encendido)
3 Cantidad de secciones de 4k de paginas en memoria
4 Cantidad de secciones de 1k en RAM
5 Cantidad de segmentos de lógica del usuario
6,7 Palabra de estado de maquina (configuración de palabra 101, 65
hexadecimal)
La palabra es organizada como sigue:
Byte 6:
Bit 15 (MSB del byte 6) = configuración del puerto 1
Bit 14= configuración puerto 2
Bit 13= puerto 1 dirección fija
Bit 12 = puerto 2 dirección fija.
Bit 11= no asignado
Bit 10= estatus de barrido constante (0 = barrido constante apagado, 1
= encendido)
Bit 9 = estatus de barrido simple (0 = barrido simple apagado, 1=
encendido)
Bit 8 = nodos de 16/24 bits (0= nodo de 24 bits, 1= nodo de 16 bits)
Byte 7
Bit 7 (MSB del byte 7) = Alimentación (1= encendido, nunca debe ser
0).
Bit 6= indicador de estatus corriendo (0= encendido, 1 =apagado).
Bit 5= estatus de protección a la memoria (0= encendido, 1= apagado).
Bit 4 = bateria OK (0=OK, 1= problema).
Bit 3-0= no asignado
8,9 código de paro de maquina, la palabra es organizada como sigue:

Byte 8:
Bit 15 (MSB del byte 8) = alto controlado del puerto.

Bit 14= no asignado
Bit 13= conocimiento opaco
Bit 12 = intervención perimetral ilegal
Bit 11= solución invalida de la tabla de multiniveles
Bit 10= inicio de nodo que no inicio segmento.
Bit 9 = prueba no pasada de estado de RAM
Bit 8 = No se detecto final de lógica, o cantidad errónea de segmentos.
Byte 9
Bit 7 (MSB of byte 9) = expiración del watchdog timer.
Bit 6= error del reloj de tiempo real.
Bit 5= diagnostico del CPU fallido.
Bit 4 = tipo de trafico invalido
Bit 3 = tipo de nodo invalido.
Bit 2 = error en la lógica del checksum
Bit 1 =error en el checksum de respaldo
Bit 0 =configuración ilegal.
984
El controlador 984 regresa una cantidad de 9 bytes, de la siguiente manera:

Byte Contenido
1 ID del esclavo (9 para el 984)
3 Cantidad de secciones de 4k de paginas en memoria
4 Cantidad de secciones de 1k en RAM
5 Cantidad de segmentos de lógica del usuario
6,7 Palabra de estado de maquina (configuración de palabra 101, 65
hexadecimal)
La palabra es organizada como sigue:

Byte 6:
Bit 15 (MSB del byte 6) = No asignado
Bit 14 - 11= No asignado
Bit 10= estatus de barrido constante (0 = barrido constante apagado, 1
= encendido)
Bit 9 = estatus de barrido simple (0 = barrido simple apagado, 1=
encendido)
Bit 8 = nodos de 16/24 bits (0= nodo de 24 bits, 1= nodo de 16 bits)
Byte 7
Bit 7 (MSB del byte 7) = Alimentación (1= encendido, nunca debe ser 0).
Bit 6= indicador de estatus corriendo (0= encendido, 1 =apagado).
Bit 5= estatus de protección a la memoria (0= encendido, 1= apagado).
Bit 4 = bateria OK (0=OK, 1= problema).
Bit 3-1= no asignado
Bit 0: bandera de tamaño bajo de memoria ( 0= No, 1= Tamaño bajo)
Tamaño bajo de memoria: El Bit 0 de la palabra de estado de maquina define el

uso del valor de tamaño bajo de memoria en palabras 99, 100 y 175 (63, 64 y AF
hexadecimal) de la tabla de configuración. Si el Bit 0 = 1 lógico, el tamaño de
memoria es calculado como sigue:
Tamaño de la pagina 0 (palabras de 16 bits) = (palabra 99 * 4096) – (palabra 175

byte bajo *16)
Tamaño de la tabla de estado (palabras de 16 bits) = (palabra 100 * 1024) – (palabra

175 byte alto *16)
8,9 código de paro de maquina, la palabra es organizada como sigue:

Byte 8:
Bit 15 (MSB del byte 8) = alto controlado del puerto.

Bit 14= (984A, B, X) fallo en paridad de memoria extendida
Bit 14= (otro 984) mal vigilante de entrada/salida
Bit 13 = conocimiento nublado
Bit 12 = intervención perimetral ilegal
Bit 11= tabla de segmentos errónea.
Bit 10= inicio de nodo que no inicio segmento.
Bit 9 = prueba no pasada de estado de RAM
Bit 8 = No se detecto final de lógica, o cantidad errónea de segmentos.
Byte 9
Bit 7 (MSB of byte 9) = expiración del watchdog timer.
Bit 6= error del reloj de tiempo real.
Bit 5 (984A, B, X)= diagnostico del CPU fallido.
Bit 5 (otro 984)= bobina dañada uso la tabla
Bit 4 = S908 fallo de cabeza remota de IO
Bit 3 = tipo de nodo invalido.
Bit 2 = error en la lógica del checksum
Bit 1 =error en el checksum de respaldo
Bit 0 =configuración ilegal.
MICRO 84
El controlador micro 84 regresa una cuenta de 8 bytes, de la siguiente manera:
Byte Contenido
1 identificador del esclavo (0 para el micro 84)
3 Número de puerto actual
4 Tamaño de la memoria
5-8 No usados (todos en ceros)
484
El controlador 484 regresa un total de 5 bytes, de la siguiente manera:
Byte Contenido
1 identificador del esclavo (1 para el 484)
3 Estado del sistema
4 Primer byte de configuración
5 Segundo byte de configuración
884
El controlador 884 regresa una cantidad de 8 bytes, distribuidos de la siguiente

manera:
Byte Contenido
1 identificador del esclavo (8 para el 884)
3 Número del puerto actual
4 Tamaño de la lógica del usuario mas el estado de la RAM, en
kilobytes (1 palabra = 2 bytes).
5 Reservado
6 Bits de enganche
Bit 0 – 2 = reservado
Bit 3 =desviación del trazador: 1 no usar el trazador estándar.
Bit 4 = fin de la prueba de análisis, 1= fin del análisis de los links.
Bit 5 = reservado
Bit 6 = desviación del solucionador lógico, 1= no ejecutar el

solucionador lógico estándar.
Bit 7 = reservado
7,8 Reservados
20 (14 Hexadecimal) lectura de referencias generales.
Descripción:
Esta función regresa el contenido de los registros ubicados en el archivo de
referencias de la memoria extendida (6XXX). El broadcast no esta soportado.
La función puede leer grupos múltiples de referencias. El grupo puede ser separado
(no necesariamente grupos contiguos), pero las referencias dentro de cada grupo
deberán ser secuénciales.
Pregunta
La pregunta contiene la dirección del dispositivo Modbus, el código de la función,

cantidad de bytes, y campo de chequeo de error. El resto de la pregunta especifica
el grupo grupos de referencias que serán leídas. Cada grupo es definido en un
campo separado entendiéndose como una sub. Petición que contiene 7 bytes:
 El tipo de referencia: 1 byte (será especificado como 6)
 El numero de archivo en la memoria extendida: 2 bytes (1 a 10,
hexadecimal 0001 a 000A).
 La dirección del registro dentro del archivo: 2 bytes.
 La cantidad de registros que serán leídos.
La cantidad de registros a ser leídos, combinados con todos los otros campos en la
respuesta esperada, no podrán exceder la longitud de un mensaje modbus: 256
bytes.
La cantidad de archivos de memoria extendida disponible depende del tamaño de

memoria extendida instalada en el controlador esclavo. Cada archivo excepto el
ultimo contiene 10,000 registros, direccionados como 0002-270F hexadecimal
(0000 – 9999 decimal).
El diseccionado de registros de referencia extendidos (6XXXX) difiere del

diseccionado de registros de referencia sostenidos.
El menor de los registros extendidos es diseccionado como el registro cero

(600000).
El menor de los registros sostenidos es diseccionado como uno (40001).
Para controladores diferentes a los 984 – 785 con registros extendidos, el último
registró (el mayor) en el último archivo es:
Tamaño de memoria extendida Ultimo archivo Ultimo registro (decimal)

16K 2 6383
32K 4 2767
64K 7 5535
96K 10 8303
Para los controladores 984 – 785 con registros extendidos, el último registró (el
mayor) en el ultimo archivo es mostrado en las dos tablas siguientes.
984 – 785 con cartucho de memoria AS-M785-032

Lógica del Situación de la Tamaño de la Ultimo archivo Ultimo registro
usuario RAM memoria (decimal)
extendida
32K 32K 0 0 0
16K 64K 72K 8 3727

extendida
48K 32K 24K 3 4575
32K 64K 96K 10 8303
Un ejemplo de una petición para leer dos grupos de referencias del esclavo 17 es
mostrado a continuación:
Grupo 1 consiste de dos registros del archivo 4, iniciando en el registro 1 (dirección
0001).
Grupo 2 consiste de dos registros del archivo 3, iniciando en el registro 9 (dirección
0009).
Figura 3.27 Pregunta para la lectura de referencias generales

Respuesta
La respuesta normal es una serie de “sub – respuestas”, cada una de las “sub -
peticiones”. La campo de cantidad de bytes es el total combinado de la cantidad en
todas las sub respuestas. En suma, cada “sub – respuesta” contienen un campo
que muestra su propia cantidad de bytes.
21 (15 Hexadecimal) Escritura de referencias generales.
Descripción:
Esta función escribe el contenido de los registros ubicados en el archivo de
referencias de la memoria extendida (6XXX). El broadcast no esta soportado.
La función puede escribir grupos múltiples de referencias. El grupo puede ser

separado (no necesariamente grupos contiguos), pero las referencias dentro de
cada grupo deberán ser secuénciales.
Pregunta
La pregunta contiene la dirección del dispositivo Modbus, el código de la función,

cantidad de bytes, y campo de chequeo de error. El resto de la pregunta especifica
el grupo grupos de referencias que serán escritos, y los datos a ser escritos en ellos.
Cada grupo es definido en un campo separado entendiéndose como una sub.
Petición que contiene 7 bytes más el dato:
 El tipo de referencia: 1 byte (será especificado como 6)
 El numero de archivo en la memoria extendida: 2 bytes (1 a 10,
hexadecimal 0001 a 000A).
 La dirección del registro dentro del archivo: 2 bytes.
 La cantidad de registros que serán escritos. 2 bytes por registro.
La cantidad de registros a ser escritos, combinados con todos los otros campos en
la pregunta, no podrán exceder la longitud de un mensaje modbus: 256 bytes.
La cantidad de archivos de memoria extendida disponible depende del tamaño de

memoria extendida instalada en el controlador esclavo. Cada archivo excepto el
ultimo contiene 10,000 registros, direccionados como 0002-270F hexadecimal
(0000 – 9999 decimal).
El diseccionado de registros de referencia extendidos (6XXXX) difiere del

diseccionado de registros de referencia sostenidos.
El menor de los registros extendidos es diseccionado como el registro cero

(600000).
El menor de los registros sostenidos es diseccionado como uno (40001).
Para controladores diferentes a los 984 – 785 con registros extendidos, el último
registró (el mayor) en el último archivo es:
Tamaño de memoria extendida Ultimo archivo Ultimo registro (decimal)
16K 2 6383
32K 4 2767
64K 7 5535
96K 10 8303
Para los controladores 984 – 785 con registros extendidos, el último registró (el
mayor) en el ultimo archivo es mostrado en las dos tablas siguientes.

extendida
32K 32K 0 0 0
16K 64K 72K 8 3727

extendida
48K 32K 24K 3 4575
32K 64K 96K 10 8303
Un ejemplo de una petición para escribir un grupo de referencias en el esclavo 17

es mostrado a continuación:
El grupo consiste de tres registros en el archivo 4, iniciando en el registro 7
(dirección 0007).
Figura 3.29 pregunta para escribir referencias generales.
Respuesta:
La respuesta normal es un eco de la pregunta

22 (16 Hexadecimal) Escritura de registros 4X con una mascara.
Descripción
Modifica el contenido de un registro especifico 4XXXX usando una combinación de

una mascara AND, un mascara OR, y el contenido actual de los registros. La función
puede ser usada para fijar o limpiar individualmente bits en dicho registro. Un
broadcast no es soportado para esta función.
Pregunta
La pregunta especifica la referencia 4XXXX a ser escrita, el dato a ser usado con la
mascara AND, y el dato a ser usado con la mascara OR.
El algoritmo de la función es:
Resultado = (contenido actual del registro AND mascara_AND) OR (mascara_OR

AND mascara_AND)
Por ejemplo:
Hexadecimal Binario
Contenido actual = 12 0001 0010
mascara_AND = F2 1111 0010
mascara_OR = 25 0010 0101
mascara_AND = 0D 0000 1101

resultado = 17 0001 0111
Nota: si el valor de la mascara_OR es 0, el resultado es simplemente la lógica AND

entre los valores actuales y la mascara_AND, si la mascara_AND tiene un valor de
cero el resultado es igual al valor de la mascara_OR.
El contenido del registro puede ser leído con la función de lectura de registros
sostenidos (código de función 03). Pero los registros pueden serán cambiados por
la lógica del controlador cuando este entre en esta parte de su rutina.
Un ejemplo de cómo escribir en el registro 5 en el esclavo 17 a partir de una mascara

se da a continuación:
Figura 3.31 pregunta para la escritura de registros con una mascara.

Respuesta
La respuesta normal es un eco de la pregunta, y dicha respuesta es dada después

de que se realiza la escritura de los registros.

23 (17 hexadecimal) Lectura/escritura de registros 4X
Descripción
Desempeña una combinación de operaciones, una lectura y una escritura en un

solo mensaje Modbus de transferencia. La función puede escribir un nuevo
contenido a un grupo de registros 4XXXX. Un broadcast no es soportado por esta
función. Esta función es soportada solamente en los controladores 984-785.
Pregunta
La pregunta especifica la direccion de inicio y la cantidad de registros del grupo a

ser leidos, tambien especifica la direccion inicio, cantidad de registros y datos de los
registros a ser escritos. El campo de cantidad de bytes especifica la cantidad de
bytes que seguiran en el campo de escritura de datos.
A continuación el ejemplo de una solicitud para leer seis registros comenzando en

el registro 5, y escribir tres registros comenzando en el registro 16, todo esto en el
esclavo 17.
Figura 3.33 pregunta para la lectura/escritura de registros 4X.

Respuesta
La respuesta normal contiene los datos del grupo de registros que fueron leídos. El
campo de cantidad de bytes especifica la cantidad de bytes que seguirán en el
campo de lectura de datos.
Aquí se muestra un ejemplo de la respuesta a la pregunta anterior.

24 (18 hexadecimal) lectura de una cola FIFO.
Descripción
Esta función da lectura a una cola de registros 4X del tipo primero en entrar primero
en salir. La función regresa la cantidad de registros en la cola, seguidos pos los
datos de la cola. Hasta 32 registros pueden ser leídos: el contador, mas 31 registros
almacenados en la cola. El contador de la colado es regresado primero y después
los datos.
La función da lectura a los datos que están contenidos en la cola, pero no limpia la
cola después de realizar dicha operación. Broadcast no esta soportado.
Esta función es soportada solo por los controladores 984 – 785.

Pregunta
La pregunta especifica la referencia de inicio 4XXXX a ser leída de la cola FIFO.

Esta es la dirección del registro indicador usado con los bloques de función primero
en entrar (FIN) y primero en salir (FOUT) del controlador. Contiene también la
cantidad de registros almacenados en la cola actualmente. Los registros de datos
seguirán secuencialmenté esta dirección.
Un ejemplo de una petición para leer la cola FIFO en el esclavo 17 se da a

continuación. La petición se hará para dar lectura a la cola iniciando en el registro
indicador número 41247 (04DE hexadecimal).
Figura 3.35 pregunta para la lectura de una cola FIFO.
Respuesta
En una respuesta normal, el campo de cantidad de bytes muestra la cantidad de

bytes que seguirán. Incluyendo la cantidad de bytes de la cola y los bytes de datos
de los registros (pero sin incluir el campo de chequeo de error).
El contador de la cola es la cantidad de registros de datos en la cola (sin incluirse a

si mismo).
Si el contador de la cola excede 31, una respuesta de excepción es regresada con

un código de error con el mensaje de valores de datos ilegales(03 Illegal value data).
Esta es la respuesta a la pregunta anterior:
En este ejemplo, el registro indicador FIFO (41247 en la pregunta) es regresado con

un contador de cola de 3. Los 3 registros de datos que seguirán al contador de cola
son: 41248 (contiene 440 decimal – 01B8 hexadecimal); 41249 (contiene 4740 –
1284 hexadecimal); y 41250 (contiene 4898 – 1322 hexadecimal).
CAPITULO 4
SUBFUNCIONES DE DIAGNOSTICO
FUNCIÓN MODBUS 08 DIAGNÓSTICOS
SUBFUNCIONES DE DIAGNOSTICO
Este capitulo da una explicación clara y detallada de la función de diagnostico dentro

de los controladores Modbus, así como un resumen detallado del propósito de las
sub-funciones de esta función.
4.1 Función 08 Diagnósticos
Descripción
La función Modbus 08 proporciona una serie de pruebas para comprobar el sistema

de comunicaciones entre el maestro y el esclavo, o para revisar varias condiciones
internas de error dentro del esclavo. El broadcast no esta soportado.
La función utiliza un campo de código de subfunción en la pregunta para definir el

tipo de prueba que será realizada. En una respuesta normal el esclavo realiza un
eco del código de función y del código de subfunción.
La mayoría de las preguntas de diagnostico usa un campo de datos de dos bytes

para mandar datos de diagnóstico o información de control para el esclavo. Algunos
de los diagnósticos causan que los datos sean regresados del esclavo en una
respuesta normal.
Efectos del diagnostico en el esclavo.
En general, emitir una función de diagnostico a un dispositivo esclavo no afecta el

programa del usuario que esta corriendo en el esclavo. La lógica como son variables
discretas y registros no son accesibles para diagnostico. Algunas funciones pueden
opcionalmente resetear el contador de error en el esclavo.
Un dispositivo esclavo puede, sin embargo, ser forzado en el modo de “solo

escucha” en el cual monitoreara los mensajes sobre el sistema de comunicación
pero sin responder a ellos. Esto puede afectar el resultado del programa de
aplicación. Esto depende de cualquier intercambio extenso de datos con el
dispositivo esclavo. Generalmente, el modo es forzado para remover un
malfuncionamiento del sistema de comunicaciones del dispositivo esclavo.
Un ejemplo de pregunta de diagnostico y su respuesta es mostrada en el siguiente

ejemplo, mostrando la localidad del código de función, código de subfunción, y
campo de datos dentro del mensaje.
Una lista de códigos de subfunciones soportadas por los controladores es mostrada

en las páginas después del ejemplo. Cada código de subfunción es listado con un
ejemplo del contenido del campo de datos que aplica para ese diagnostico.
Pregunta
Este ejemplo es una petición para el esclavo 17 para regresar los datos. Este
ejemplo usa una código de subfunción cero (00 00 hexadecimal en los dos bytes
del campo). El dato a ser regresado es enviado en los dos bytes del campo de datos
(A5 37 hexadecimal).
Figura 4.1 pregunta de diagnostico.
Respuesta
La respuesta normal a la pregunta es un lazo de regreso que traerá los mismos

datos que la pregunta. El código de función y código de subfunción son regresados
también.
Figura 4.2 respuesta de diagnostico
Los campos de datos en la respuesta a diferencia de otro tipo de respuestas pueden

contener contadores de error u otra información solicitada por la subfunción.
La siguiente lista muestra los códigos de subfunción soportados por los

controladores Modicon. Los códigos son mostrados en decimal.
La S indica que la subfunción es soportada, de manera similar la literal N indica que

dicho controlador no es capaz de soportar esta subfunción.
Código Nombre 384 484 584 884 M84 984

00 Regreso de datos de la pregunta S S S S S S
01 Reinicio de comunicación S S S S S S
02 Regresa registro de diagnostico S S S S S S
03 Cambia el delimitador de entras ASCII S S S N N S
04 Forzar modo de solo escucha S S S S S S
05-09 Reservado
10 Limpia registros de control y diagnostico S S (1) N N (1)
11 Regresa el contador de mensajes del bus S S S N N S
12 Regresa el contador de errores de S S S N N S
comunicación en el bus
13 Regresa el contador de errores de excepción en S S S N N S
el bus.
14 Regresa el contador de mensajes del esclavo S S S N N N
15 Regresa el contador del esclavo de no S S S N N N

respuestas.
16 Regresa el contador NAK del esclavo S S S N N S
17 Regresa el contador de ocupado del esclavo S S S N N S
18 Regreso del contador de caracteres S S S N N S
desbordados en el bus.
19 Regreso del contador de IOP desbordados N N N S N N
(884).
20 borrar banderas y contadores de N N N S N N
desbordamiento
21 Obtener/borrar estadisticas de Modbus Plus N N N N N S
22-hacia Reservado
arriba
(1) Limpieza de contadores solamente
4.2 Subfunciones de diagnostico
00 regreso de datos de la pregunta
Los datos de la pregunta tienen que ser regresados en la respuesta. El mensaje de

respuesta tendrá que ser enteramente idéntico ala pregunta.
Subfunción Campo de datos Campo de datos (pregunta)

(pregunta)
00 00 cualquiera Eco de los datos de la pregunta
01 Opción de Reinicio de la Comunicación
El puerto periférico del esclavo será inicializado y arrancado nuevamente, y todos

sus contadores de eventos serán reiniciados. Si el puerto esta puesto en el modo
de solo escucha. Ninguna respuesta será regresada. Esta función es la única que
modifica el estado de solo lectura del puerto. Si el puerto no esta en el modo de solo
lectura ocurrirá una respuesta normal. Esto ocurrirá antes de que se reinicie todo.
Cuando el esclavo recibe la pregunta. Procura llevar a cabo un reseteo y ejecutar

su prueba. Si la prueba concluye exitosamente esta función pondrá el puerto on-
line.
Un contenido de FF 00 hexadecimal en el campo de datos de la pregunta causa que

los registros de eventos de comunicaciones de los puertos sean limpiados también.
Un contenido de 00 00 dejara al histórico como estaba antes del reinicio.
Subfunción Campo de datos Campo de datos

(pregunta) (respuesta)
00 01 00 00 Eco de la pregunta
00 01 FF 00 Eco de la pregunta
02 Regreso del registro de diagnostico

El contenido del registro de diagnostico de 16 bits del esclavo es regresado en la
respuesta.
Subfunción Campo de datos Campo de datos (respuesta)

(pregunta)
00 02 00 00 Contenido del registro de
diagnostico
Nota. El contenido varia de controlador a controlador y es necesario verificar cual
es dicho contenido.
03 Cambio del delimitador de entrada ASCII
el carácter que es pasado en la pregunta dentro del campo de datos vendrá a ser el
carácter delimitador del fin de mensaje para los futuros mensajes (remplazando el
carácter por default Line Feed). Esta función es útil donde el line feed no es
esperado en el final de los mensajes ASCII.

(pregunta)
00 03 Carácter 00 Eco de la pregunta
04 Forzar el modo de solo escucha
Fija al esclavo direccionado en el modo de solo escucha para las comunicaciones

en protocolo Modbus. Esto aísla el dispositivo del resto de la red, permitiéndoles
comunicarse sin interrupción por parte del esclavo direccionado. Ninguna respuesta
es regresada.
Cuando el esclavo entra en el modo de solo escucha. Todos los controles de

comunicación activos son apagados. El watchdog timer podrá expirar. Bloqueando
los controles apagados. Mientras se este en este modo, ningún mensaje Modbus
direccionado al esclavo o broadcast será monitoreado, así como ninguna acción
será tomada y ninguna respuesta será enviada.
La única función que puede regresar a la actividad a este dispositivo es la opción

de reinicio de comunicaciones (código de función 8, subfunción 1).

(pregunta)
00 04 00 00 Ninguna respuesta es regresada
10 (0A hexadecimal) Borrar contadores y registro de diagnostico
Para controladores diferentes a los 584 o 984, es posible borrar todos los
contadores y el registro de diagnostico. Par el 584 o 984 solo es posible borrar los
contadores. Los contadores también son borrados después de una falla de

alimentación.

(pregunta)
00 0A 00 00 Eco de la pregunta
11 (0B hexadecimal) Regreso del contador de mensajes del Bus
El campo de datos de la respuesta regresa la cantidad de mensajes que el esclavo

a detectado sobre el sistema de comunicaciones desde el ultimo reinicio y borrado
de contadores o desde la ultima falla de energía.

(pregunta)
00 0B 00 00 Cantidad de mensajes
12 (0C hexadecimal) Regreso del contador de errores de comunicación del

Bus
El campo de datos de la respuesta regresa la cantidad de errores CRC encontrados

en el esclavo desde el ultimo reinicio y borrado de contadores o desde la ultima falla
de energía.

(pregunta)
00 0C 00 00 Cantidad de errores CRC
13 (0D hexadecimal) Regreso del contador de errores de excepción en el Bus
El campo de datos de la respuesta regresa la cantidad de respuestas de excepción

Modbus desde el ultimo reinicio y borrado de contadores o desde la ultima falla de
energía. Las respuestas de excepción son descritas en el apéndice A.

(pregunta)
00 0D 00 00 Cantidad de errores de excepción
14 (0E hexadecimal) Regreso del contador de mensajes del esclavo
El campo de datos de la respuesta regresa la cantidad de mensajes direccionados

al esclavo, o de broadcast que el esclavo procesó desde el ultimo reinicio y borrado
de contadores o desde la ultima falla de energía.

(pregunta)
00 0E 00 00 Cantidad de mensajes del esclavo
15 (0F hexadecimal) Regreso del contador de No respuestas del esclavo

al esclavo, a los cuales no respondió (esto incluye a respuestas normales no a
respuestas de excepción) desde el ultimo reinicio y borrado de contadores o desde
la ultima falla de energía.
Subfunción Campo de datos (pregunta) Campo de datos (respuesta)

00 0F 00 00 Cantidad de no respuestas del

esclavo
16 (10 hexadecimal) Regreso del contador NAK del esclavo

al esclavo, a los cuales respondió con una respuesta de excepción del tipo
“confirmación de recepción negativa” (Negative Acknowledge “NAK”) desde el
ultimo reinicio y borrado de contadores o desde la ultima falla de energía. Las
respuestas de excepción son descritas en el apéndice A.

(pregunta)
00 10 00 00 Contador NAK del esclavo
17 (11 hexadecimal) Regreso del contador de ocupado del esclavo

al esclavo, a los cuales respondió con una respuesta de excepción del tipo
“Dispositivo esclavo ocupado” desde el ultimo reinicio y borrado de contadores o
desde la ultima falla de energía. Las respuestas de excepción son descritas en el
apéndice A.

(pregunta)
00 11 00 00 Contador de dispositivo ocupado del
esclavo
18 (12 hexadecimal) Regreso del contador de caracteres desbordados en el

bus.

al esclavo, que no pudo manejar debido a una condición de desbordamiento de
caracteres desde el ultimo reinicio y borrado de contadores o desde la ultima falla
de energía. Un desbordamiento de caracteres es causado por caracteres llegando
al puerto a una velocidad mayor a la que pueden ser almacenados, o por la pérdida
de caracteres debido a un mal funcionamiento de hardware.

(pregunta)
00 12 00 00 Contador de caracteres desbordados del
esclavo
19 (13 hexadecimal) Regreso del contador de IOP desbordados (884).

al esclavo, que no pudo manejar debido a una condición de desbordamiento de IOP
desde el ultimo reinicio y borrado de contadores o desde la ultima falla de energía.
Un desbordamiento de IOP es causado por caracteres llegando al puerto a una
velocidad mayor a la que pueden ser almacenados, o por la pérdida de caracteres
debido a un mal funcionamiento de hardware Esta función es específica del 884.

(pregunta)
00 13 00 00 Contador de IOP desbordados del
esclavo
20 (14 hexadecimal) borrar banderas y contadores de desbordamiento

Borra el contador de errores de desbordamiento en el 884 y reinicia las banderas

de error. El estado actual de la bandera es encontrado en el bit 2 del registro de
diagnosticó del 884.
Esta función es específica para el 884.

(pregunta)
00 14 00 00 Eco de los datos en la pregunta.
CAPITULO 5
MODBUS TCP/IP
MODELO CLIENTE SERVIDOR
DESCRIPCIÓN DEL PROTOCOLO
DESCRIPCIÓN FUNCIONAL
Este capitulo comprende al protocolo Modbus TCP/IP, variante del protocolo

Modbus, describe la filosofía de funcionamiento, al mismo tiempo muestra las
posibilidades de interconexión que se tienen, surgiendo de la necesidad de integrar
equipos de tecnologías seriales a redes empresariales.
5.1 MODELO cliente servidor
Los mensajes de Modbus proporcionan una comunicación cliente / servidor entre

dispositivos conectados en una red Ethernet TCP /IP
Este modelo de cliente servidor esta basado en cuatro tipos de mensajes:
 Petición Modbus
 Confirmación Modbus
 Indicación Modbus
 Respuesta Modbus
Figura 5.1 Modelo cliente servidor

Una Petición de Modbus es el mensaje enviado sobre la red por el cliente para iniciar
una transferencia.
Una indicación de Modbus es el mensaje a la pregunta recibida del lado del servidor.
Una respuesta de Modbus es el mensaje de respuesta enviado por el servidor.
Una confirmación de Modbus es el mensaje a la pregunta recibida del lado del
cliente.
El servicio de mensajes Modbus es usado para el intercambio de información en

tiempo real:
 Entre aplicaciones de dos dispositivos

 Entre la aplicación de un dispositivo y otro dispositivo.
 Entre aplicaciones de SCADA/Sistemas de control y dispositivos.

 Entre una PC y un programa de dispositivo proporcionando servicios en línea.
5.2 Descripción del protocolo
Arquitectura general de comunicación
Un sistema de comunicación sobre MODBUS TCP/IP puede incluir diferentes tipos

de dispositivos:
 Un cliente MODBUS TCP/IP y dispositivos servidores conectados a una red

TCP/IP.
 Los dispositivos de interconexión como son puentes, routers o puertas de enlace
para la interconexión entre la red TCP/IP y un a sub red serial que permita la
conexión de clientes Modbus seriales y servidores y dispositivos.
Figura 5.2 Arquitectura de comunicaciones Modbus TCP/IP
El protocolo de comunicaciones MODBUS define un simple protocolo unidad de

datos (PDU) independiente de las capas subyacentes de red. EL trazado del
protocolo Modbus sobre redes o buses específicos puede agregar algunos campos
adicionales a la unidad de datos de la aplicación (ADU).
Figura 5.3 Trama general de Modbus.
El cliente que inicia una transferencia de Modbus construye la unidad de datos de

la aplicación. El código de la función indica al servidor que tipo de acción será
desempeñada.
La unidad de datos de la aplicación sobre MODBUS TCP/IP
Esta sección describe el encapsulamiento de una petición o respuesta de Modbus

cuando es cargada sobre una red TCP/IP.
Figura 5.4 pregunta o respuesta sobre TCP/IP
Un encabezado dedicado es usado sobre TCP/IP para definir la unidad de datos de

la aplicación. Este encabezado es llamado encabezado MBAP (encabezado de
aplicación del protocolo MODBUS).
Este encabezado proporciona algunas diferencias comparado a la unidad de datos

de la aplicación MODBUS RTU usado en líneas seriales.
 El campo de dirección Modbus del esclavo comúnmente usada en la transmisión

serial es remplazada por un solo byte “identificador de unidad” dentro del
encabezado MBAP. El identificador de unidad es usado para comunicarse a
través de los dispositivos como son puentes, routers y puertas de enlace que
usan una simple dirección IP para soportar varias unidades de Modbus
independientes.
 Todas las peticiones y respuestas son diseñadas de una manera tal que el
receptor pueda verificar que un mensaje esté acabado. Para códigos de
funciones donde el PDU (protocolo de unidad de datos) Modbus tiene una
longitud fija, el código de la función es suficiente. Para códigos de función que
cargan con una variable para contar la cantidad de datos en una petición o
respuesta, el campo de datos incluye un contador de bytes.
 Cuando MODBUS es cargado sobre TCP, la información al adicional es cargada
en el encabezado MBAP para permitirle al receptor para reconocer límites del
mensaje iguale si el mensaje ha estado dividido en múltiples paquetes para la
transmisión.
Descripción del encabezado MBAP
Campos Longitud Descripción Cliente Servidor

Identificador de 2 Bytes Identificación Iniciado por el Recopilado por
transferencia de una petición cliente el servidor de
MODBUS/trans la petición
ferencia de recibida.
respuesta
Identificador de 2 Bytes 0= protocolo Iniciado por el Recopilado por
protocolo MODBUS cliente el servidor de
la petición
recibida
Longitud 2 Bytes Numero de Iniciado por el Iniciado por el
bytes cliente servidor
siguiendo (petición) (respuesta)
Identificador de 1 Byte Identificación Iniciado por el Recopilado por
unidad de un esclavo cliente el servidor de
conectado la petición
remotamente recibida
en una línea
serial o sobre
otro bus.
El encabezado tiene una longitud de 7 bytes:
 Identificador de transferencia – es usado para la transferencia en pares, el

servidor copia en la respuesta el identificador de transferencia de la petición.
 Identificador de protocolo – es usado para multiplexar intra – sistemas, El
protocolo MODBUS es identificado por el valor de cero.
 Longitud – El campo de longitud es un contador de bytes de los siguientes
campos, incluyendo el identificador de unidad y los campos de datos.
 Identificador de unidad – este campo es usado para propósitos de enrutar intra
– sistemas. Es típicamente usado para comunicar esclavos MODBUS o
MODBUS PLUS (que son protocolos de líneas seriales) a través de una puerta
de enlace entre una RED ethernet TCP/IP y una línea serial. Este campo es
fijado por el cliente MODBUS en la petición y debe ser regresado con el mismo
valor en la respuesta por el servidor. Todas las unidades de datos de la
aplicación son enviadas vía TCP sobre el puerto 502.
5.3 Descripción funcional
La arquitectura de los componentes MODBUS presentados aquí es un modelo

general incluyendo ambos componentes el servidor y el cliente MODBUS y usado
en cualquier dispositivo.
Algunos dispositivos solo pueden proporcionar los componentes para funcionar
como servidores o como clientes.
Modelo de la arquitectura de los componentes MODBUS.

Aplicación del Usuario
Capa de Interfase Parte trasera

comunicaci Cliente de la interfase
ón de la Modbus modbus
aplicación
Cliente Modbus Servidor

Modbus
Administrad
or TCP
Pila de Administrador Control de

parametrizaci de conexión acceso
on
Pila TCP/IP
Figura 5.5 Arquitectura conceptual delservicio de mensajes MODBUS
Capa de comunicaciones de la aplicación
Un dispositivo de Modbus puede proporcionar una interfase de cliente y/o servidor.
La parte trasera de una interfase Modbus puede ser proporcionada permitiendo el

acceso indirectamente a los objetos de la aplicación del usuario.
Cuatro áreas pueden componer esta interfase: entradas discretas, salidas discretas
(bobinas), entrada de registros y salida de registros. Un trazado entre esta interfase
y la aplicación de datos del usuario tiene que ser realizada (edición local).
Tablas Tipo de tipo Comentario

principales objeto
Entradas Bit simple Solo lectura Este tipo de dato puede ser
discretas proporcionado por un sistema de
entrada/salida
Bobinas Bit simple Lectura/escrit Este tipo de dato puede ser
ura alterado por un programa de
aplicación
Registros de Palabra de 16 Solo lectura Este tipo de dato puede ser
entrada bits proporcionado por un sistema de
entrada/salida
Registros Palabra de 16 Lectura/escrit Este tipo de dato puede ser
sostenidos bits ura alterado por un programa de
aplicación
Entradas discretas Petición MODBUS

Bobinas
Registros de
entrada
Registros de salida
Memoria del dispositivo de

aplicación
Figura 5.6 Modelo de los datos Modbus con bloques separados

Memoria del dispositivo de

aplicación
Entradas discretas
Petición MODBUS
Bobinas
Registros de
entrada
Registros de salida
FiguFigura 5.7 Modelo de los datos Modbus con un solo bloque

 Cliente Modbus
El cliente Modbus permite a la aplicación del usuario tener control del intercambio
de la información con un dispositivo remoto. El cliente Modbus construye una
petición Modbus de los parámetros contenidos en una petición enviada por la
aplicación del usuario a la interfase del cliente Modbus.
 Interfase del cliente Modbus
La interfase del cliente Modbus proporciona una interfase habilitando la aplicación

del usuario para construir la petición para varios servicios Modbus incluyendo el
acceso a objetos de la aplicación Modbus. La interfase del cliente Modbus (API) no
es caracterizada en estas especificaciones, aunque un ejemplo se describe en el
modelo de implementaron.
 Servidor Modbus
Con la recepción de una petición Modbus este modulo activa una acción local para
leer, escribir o realizar alguna otra acción. El procesamiento de estas es realizado
de una manera transparente para las aplicaciones del programador. El servidor
principal de Modbus es esperar por una petición Modbus en el puerto 502 de TCP,
para tratar esta petición y entonces construir una respuesta Modbus dependiendo
del contexto del dispositivo.
 Interfase trasera Modbus
La interfase trasera es una interfase del servidor Modbus para la aplicación del
usuario en donde los objetos de la aplicación son definidos.
 Capa de administración TCP

Una de las funciones principales de los servicios de mensajes es manejar el
establecimiento de la comunicación y el fin de esta conexión y manejar el flujo de
datos en conexiones de TCP establecidas.
 Administrado de conexión.
Una comunicación entre el cliente y el servidor Modbus requiere el uso de un modulo
de administración de conexión TCP. El cual esta a cargo de manejar globalmente
los mensajes en las conexiones TCP.
Dos posibilidades son proporcionadas para el administrador de conexión. La
aplicación del usuario maneja las conexiones TCP o la administración de conexión
esta hecha en su totalidad por el modulo y sin embargo es transparente para la
aplicación del usuario. La última solución implica menos flexibilidad.
El puerto de escucha 502 esta reservado para las comunicaciones en Modbus. Esto
es obligatorio por default escuchar en este puerto. Sin embargo, algunas marcas o
aplicaciones podrían requerir que otro puerto este dedicado a Modbus sobre TCP.
En este caso cuando la interoperatividad es requerida con productos que no son
similares como suele pasar en un cuarto de control. Por esta razón es altamente
recomendado que el cliente y el servidor den la posibilidad al usuario de modificar

el parámetro del puerto a ser utilizado para Modbus sobre TCP. Es importante notar
que aun si otro puerto en el servidor es configurado para servicio de Modbus en
ciertas aplicaciones. El puerto 502 tendrá que seguir habilitado para otras
aplicaciones que lo requieran.
Modulo de control de acceso
En algunos contextos críticos, la accesibilidad a los datos internos del dispositivo es

no deseable para algunos hosts. Esto es porque se necesita un modo de seguridad
es necesario y el proceso de seguridad deberá ser implementado si se requiere.
Capa pila TCP/IP
La pila TCP/IP puede ser parametrizada para adaptar el control de flujo de datos, el
administración de direcciones y el administrador de conexión para diferentes
equipos o sistemas. Generalmente la interfase del socket BSD es usada para
administrar las conexiones TCP.
Administrador de código y control de flujo de datos.
Para equilibrar el flujo de los mensajes de entrada y salida entre el cliente Modbus
y el servidor, el mecanismo de control de flujo de datos es proporcionado en todas
las capas de pilas de mensajes Modbus.
El administrador de código y él modulo de control esta basado principalmente sobre
el control de flujo interno en TCP sumado con algún control de flujo de datos en la
capa de enlace de datos y también en el nivel de la aplicación del usuario.
Administrador de conexión TCP

Modulo administrador de conexión
Descripción general
La comunicación Modbus requiere que se establezca una conexión TCP entre un

cliente y un servidor.
El establecimiento de la conexión puede ser activado directamente por el modulo

de aplicación del usuario o automáticamente por el modulo administrador de
conexión TCP.
En el primer caso una interfase aplicación de interfase programada tendrá que ser
proporcionada en el modulo de la aplicación del usuario para administrar
completamente la conexión. Esta solución proporciona flexibilidad para el
programador de la aplicación pero requiere de una buena experiencia sobre
mecanismos TCP/IP.
N la segunda opción el administrador de conexión TCP esta completamente oculto

para la aplicación del usuario que solo envía y recibe mensajes Modbus. El modulo
administrador TCP esta a cargo de establecer una nueva conexión de TCP cuando
esto es requerido.
La definición del numero de la conexión TCP cliente y servidor no esta en el alcance
de este documento. Dependiendo sobre las capacidades el número de la conexión
de TCP puede ser diferente.
Reglas de implementación:
1) Sin requerimientos explícitos del usuario, esto es recomendado para implementar

el administrador automático de conexión
2) esto es recomendado para mantener la conexión TCP abierta con un dispositivo

remoto y no abrir y cerrar para cada trasferencia Modbus.
Nota: sin embargo el cliente Modbus debe ser capaz de aceptar una petición cerrada
del servidor y cerrar la conexión. La conexión puede ser re abierta cuando sea
requerido.
3) Esto es recomendado para un cliente Modbus abrir un mínimo de conexiones

TCP con un servidor MODBUS (con la misma dirección IP). Una conexión por
aplicación puede ser una buena elección.
4) diversas transferencias Modbus pueden ser activadas simultáneamente sobre la

misma conexión TCP.
Nota: si esto ocurre entonces el identificador de transferencia Modbus deberá ser
usado únicamente para identificar las preguntas y respuestas concordantes.
5)En el caso de una comunicación bidireccional entre dos entidades remotas (cada
una de ellos es cliente y servidor), es necesario abrir conexiones separadas para el
flujo de datos del cliente y para el flujo de datos del servidor.
6) una trama de TCP podrá transportar solo un ADU Modbus. Esto es avisado antes
de enviar múltiples peticiones o respuestas de Modbus sobre el mismo PDU TCP.
1. Administración de conexión TCP
Él moduló de la aplicación del usuario esta a cargo de manejar todas las conexiones
TCP: establecidas activamente o pasivamente, fin de conexión.......Este
administrador esta hecho para todas las comunicaciones Modbus entré un servidor
y un cliente. La interfase del socket BSD es usada en él modulo de la aplicación del
usuario para administrar la conexión TCP. Esta solución ofrece una total flexibilidad
pero implica que el programador de la aplicación tenga suficiente conocimiento
sobre TCP.
Un límite en el número de conexiones cliente servidor tiene que ser configurado

tomando los requerimientos y capacidades del dispositivo.
2. administración automática de la conexión TCP
El administrador de conexión es totalmente transparente para el modulo de

aplicaciones del usuario. El modulo administrador de la conexión puede aceptar un
número suficiente de conexiones cliente servidor.
Sin embargo un mecanismo debe ponerse en ejecución en el caso de que se
excedan el número de conexiones autorizadas. En algunos casos se recomienda
cerrar la conexión más antigua que no este en uso.
Una conexión con una pareja remota es establecida en el primer paquete recibido
de un cliente remoto o de la aplicación del usuario local. Esta conexión será cerrada
si una terminación llega de la red o se decide localmente por el dispositivo. En la
recepción de una petición de conexión, la opción de control de acceso puede ser
usado para prohibir la accesibilidad a dispositivos clientes no autorizados.
Él moduló administrador de TCP usa la interfase de pila (usualmente interfase de

socket BSD) para comunicarse con la pila TCP/IP.
Para mantener la compatibilidad entre los requerimientos del sistema y el servidor,

el administrador de TCP mantendrá poleando 2 conexiones.
 La primer conexión (conexión con prioridad en el poleo) esta hecha con

conexiones que nunca están cerradas sobre una iniciativa local. El principio a
ser implementado esta asociado a una dirección IP especifica con cada posible
conexión de este poleo. El dispositivo con tal dirección IP será marcado.
Cualquier conexión nueva solicitada por un dispositivo marcado debe ser
aceptada. Y será tomada de la prioridad de conexión. Esto también es necesario
para configurar el número máximo de conexiones permitidas para cada
dispositivo para evitar que el mismo dispositivo use todas las conexiones
posibles.
 La segunda conexión (conexión sin prioridad en el poleo) contiene conexiones
para dispositivos no marcados. Las reglas a tomar para este caso es cerrar las
conexiones más viejas cuando una nueva conexión es solicitada por un
dispositivo no marcado y cuando no existen más conexiones disponibles.
Una configuración puede ser proporcionada opcionalmente para asignar el número

de conexiones disponibles en cada poleo. Sin embargo (esto no es obligatorio) los
diseñadores pueden fijar el numero de conexiones al momento de diseñar en caso
de ser necesario.
Descripción del Administrador de conexión
El servicio de mensajes Modbus será proporcionado por un socket de escucha en

el puerto 502, que permitirá aceptar nuevas y el intercambio de datos con otros
dispositivos.
Cuando el servicio de mensajes requiere intercambiar datos con un servidor remoto,

debe de abrir un nuevo cliente de conexión con un puerto remoto para intercambiar
datos con este dispositivo. El puerto local debe de ser mayor que 1024 y diferente
para cada cliente de conexión.
Si el numero de conexiones cliente – servidor es mayor al numero de conexiones

permitidas la conexión más antigua que no este siendo usada será cerrada. El
mecanismo de control de acceso puede ser activado para checar si la dirección IP
del cliente remoto es autorizada. Si no la nueva conexión será rechazada.
Transferencia de datos Modbus

Una petición tiene que ser enviada a la conexión TCP correctamente abierta. La
dirección IP del dispositivo remoto es usada para encontrar la conexión TCP. En
caso de varias conexiones TCP abiertas con el mismo dispositivo. Se elegirá una
conexión para que el mensaje de Modbus sea enviado. Diferentes criterios de
elección son usados como son la conexión más antigua, la primera. La conexión
permanecerá abierta durante toda la comunicación Modbus. El cliente puede
establecer varias transferencias Modbus con un servidor sin que la transferencia
anterior finalice.
Terminación de comunicación
Cuando las comunicaciones Modbus son terminadas entre un cliente y servidor el

cliente debe iniciar la terminación de comunicación.
Impacto de los Modos de operación
Algunos modos de operación (paro de comunicación entre dos extremos

operacionales, deshabilitacion y reinicio de una de los extremos,…..) puede tener
impactos sobre las comunicaciones TCP. Una conexión puede ser considerada
fallida o abortada por uno de los extremos sin conocimiento del otro lado. Se dice
que la conexión es “medio-abierta”.
Modulo de control de acceso
El objetivo de este modulo es checar cada conexión nueva y usando una lista de
direcciones IP remotas autorizadas el modulo puede autorizar o prohibir una
conexión de un cliente remoto.
En contextos típicos el programador de la aplicación necesita elegir el modo de

control de acceso para dar seguridad a la red. En tal caso se necesita
autorizar/prohibir acceso a cada dirección IP remota. El usuario necesita
proporcionar una lista de direcciones IP y especificar para cada dirección IP si tiene
autorización o no. Por default, en modo de seguridad, la dirección IP no configurada
por el usuario será denegada. Sin embargo con el modo de control de acceso una
conexión proveniente de una dirección IP desconocida es cerrada.
Uso de la pila TCP/IP
Una pila de TCP/IP proporciona una interfase para administrar conexiones, para
enviar y recibir datos, y también para hacer algunas parametrizaciones para adaptar
el comportamiento de la pila para el dispositivo.
La interfase de pila generalmente esta basada en la interfase BSD (Berkeley

Software Distribution).
Uso de la interfase de socket BSD
Un socket es un punto final de comunicación. Es el bloque básico en la construcción

de una comunicación. Una comunicación Modbus es realizada al enviar y recibir
datos a través de sockets. La librería TCP/IP proporciona solo sockets stream
usando TCP y proporciona una conexión basado en el servicio de comunicación.
Capa de aplicación de comunicación
Diseño del cliente Modbus
La definición del protocolo Modbus TCP/IP permite un diseño simple de un cliente.

El proceso básico de transferencia de información se describe a continuación.
 Establecer una conexión TCP con un puerto 502 en el servidor deseado

usando una función de conexión.
 Preparar una petición Modbus como ya se describió antes.
 Poner la petición Modbus incluyendo los 6 bytes del prefijo Modbus

TCP/IP en un buffer listo para ser enviados.
 Esperar por una respuesta que aparecerá por la misma conexión TCP,
opcionalmente se puede incluir un tiempo de espera en este punto, si se
desea tener algún aviso de problemas de comunicación tan rápido como
TCP normalmente reporta.
 Leer con alguna función los 6 primeros bytes de la respuesta, que indicara
la longitud actual del mensaje de respuesta.
 Usar la misma función para leer el resto de los bytes.
Si no se va a tener comunicaciones para objetivos similares al que se realizo, cerrar

la conexión TCP para que el servidor tenga disponibilidad para otros clientes.
En los eventos donde ser incluye un tiempo de espera para una respuesta se emitirá
un aviso de cierre unilateralmente, abrirá una nueva conexión, y reenviara la
pregunta. Esta técnica permite al cliente el control de tiempos de respuesta que es
superior al proporcionado por TCP. Esto permite también alternar estrategias de
fallback, como es enviar la petición a otra IP alterna, usando una red de
comunicación totalmente independiente, en caso de una falla de la infraestructura
de la red.
Diseño del servidor
Un servidor de Modbus TCP debe ser diseñado siempre para soportar la

concurrencia de múltiples clientes, aun cuando en su uso funcional aparente que
solo requiere un cliente. Esto permite al cliente cerrar y reabrir las conexiones en
secuencias rápidas para responder rápidamente en una situación de respuestas no
entregadas.
Si una pila de TCP convencional es usada se pueden ahorrar significantes recursos

de memoria reduciendo el tamaño de los buffers de transmisión y recepción. Un
servidor normal de Unix usualmente aloja 8K bytes o más como un buffer de recibo
por conexión para alentar la transferencia en ráfagas como Por ejemplo un servidor
de archivos. Como el espacio del buffer no tiene un valor en Modbus TCP, desde el
máximo tamaño de una pregunta o respuesta es menor a 300 bytes. Es posible a
menudo cambiar el espacio de almacenamiento por recursos adicionales de
conexión.
Los modelos de multi-hilos o simple-hilo pueden ser usados para manejar las
conexiones múltiples.
Servidor Multi-hilos
Sistemas operativos o lenguajes que alientan el uso de múltiples hilos como es java
usan la estrategia de multi-hilos descrita aquí:
Usar una función de escucha para detectar conexiones en el puerto 502.
Cuando es recibida una petición de conexión, se usa una función de aceptación y

después se genera un hilo para manejar la conexión.
Dentro del hilo se realiza lo siguiente en un loop infinito.

Emitir una pregunta de los 6 bytes de la cabecera de Modbus TCP/IP. No poner una
interrupción aquí, pero en cambio estará esperando hasta que una pregunta venga
o la conexión sea cerrada. Ambas situaciones invocaran al hilo automáticamente.
Analizar el encabezado. Si este parece dañado, por ejemplo que el campo de

protocolo no son ceros o la longitud del mensaje es mayor que 256, entonces
unilateralmente se cerrara la conexión. Esta es la respuesta correcta de un servidor
para una situación que implique a la codificación de TCP.
Usar una función de recibo para los siguientes bytes del mensaje, cuya longitud ya
conocemos. Podemos notar que al usar una función de recepción con una longitud
conocida tolerara clientes que insisten en encimar peticiones.
El siguiente paso es procesar el mensaje Modbus. Si es necesario suspender el hilo

actual hasta que la respuesta adecuada sea generada, en el futuro se tendrá un
mensaje de Modbus valido o un mensaje de excepción para responder.
Generar el prefijo Modbus para la respuesta, como un solo buffer para ser
transmitido en la conexión, usando una función de envió.
Regresar y esperar por los siguientes 6 bytes de una pregunta.
En el futuro, cuando el cliente seleccione cerrar la conexión, la función de recibo

para los 6 bytes del prefijo fallara. Una orden de cierre de comunicación resultara
en que la función de recibo tenga una cantidad de 0 bytes. En este caso se cierra la
conexión y se cancela el hilo.
Servidor de un solo hilo
Algunos sistemas integrados con sistemas viejos como es UNIX o MS-DOS alientan
el manejo de múltiples conexiones usando la llamada de “select” de la interfase de
sockets. En semejante sistema, en lugar de ocuparse del proceso de demandas

coexistentes individuales en su propio hilo, usted puede ocuparse de las demandas
como una máquina de estados múltiples dentro de un manejador común. Los
idiomas como C++ hacen la estructura de software como la siguiente.
La estructura ahora debe ser como sigue:
Inicialización de la maquina multi estados fijando su estado en inactivo.
Usar una función de escucha para las conexiones entrantes en el puerto 502.
Ahora iniciar un loop infinito checando el puerto y la maquina de estados como

sigue:
En el puerto de escucha, si se recibe una nueva petición de conexión, se acepta y

ocasiona que la maquina de estados cambie su estado de “inactivo” a “petición
nueva” para procesar la conexión entrante.
Para cada estado de la maquina de estados tenemos:
 Si es estado es “nueva petición”

o Use una función para ver cuando llega la petición. Normalmente se fija la
interrupcion en cero, lo que indica que usted no desea suspender el proceso
debido a la inactividad de esta conexión.
o Si la funcion indica que existe un paquete use un a funcion para leer el

encabezado como en el caso de multi hilos. Si el encabezado esta dañado
cerrar la conexión y poner el estado de la maquina en “inactivo”.
o Si la lectura ocurre y se indica que hay entradas disponibles se lee el resto

de la petición.
o Si la petición esta completa cambiar el estado de la maquina por “esperar

respuesta”
o Si se detecta que la petición es muy larga se cierra la conexión y el estado

de la maquina se regresa a “inactivo”.
 Si el estado es “esperar respuesta”
o Ver si la información de respuesta esta disponible, de ser así crear el paquete

de respuesta, y enviarlo usando enviar, exactamente como en el caso de
multi hilos, fijando el estado en “nueva petición”.
Desempeño requerido y esperado
No existe una especificación para el tiempo de respuesta en Modbus o Modbus

TCP/IP. Esto es debido a que se espera que Modbus TCP sea usado las más
variadas situaciones de comunicación.
Además, la familia de Modbus esta diseñada para alentar la conversión automática

entre redes mediante puentes. Tales como los dispositivos Schneider “puente
Ethernet a Modbus Plus“, y varios dispositivos que convierten de Modbus TCP a
Modbus serial. El uso de tales dispositivos implica que el desempeño de dispositivos
Modbus existentes es consistente con el uso de Modbus TCP.
En general dispositivos como PLC´s que exhiben un comportamiento de escaneo

responderá a una pregunta entrante en un tiempo de escaneo, que típicamente varia
entre 20 mili segundos y 200 msec.
Desde la perspectiva de un cliente, el tiempo deberá ser extendido por los retardos
de transmisión a través de la red. Para determinar un tiempo se respuesta
razonable. Tales retardos de transporte pueden ser de mili segundos para redes
Ethernet o cientos de segundos para una red de área amplia.
A su vez, cualquiera tiempo de 'interrupción' usado en el cliente comenzar un

reintento de la aplicación debe ser más grande que el máximo esperado ' tiempo de
contestación razonable'. Si esto no es seguido, hay un potencial para la congestión
excesiva al dispositivo designado o en la red que puede causar los errores. Ésta es
una característica que siempre debe evitarse.
Así en la práctica, siempre es probable que las interrupciones del cliente usadas en
aplicaciones de alto desempeño son siempre dependientes a la topología de la red
y la actuación esperada del cliente.
Una interrupción de digamos 30 msec podrían ser razonables cuando examinando

10 dispositivos de entrada/salida para una red Ethernet local y cada dispositivo
normalmente responderían en 1 msec. Por otro lado, un valor de interrupción de 1
segundo podría ser más apropiado al dirigir PLC lento a través de una entrada serial
dónde la secuencia de escaneo normal es de 300 msec.
Los clientes son animados a cerrar y restablecen las conexiones de MODBUS/TCP

que son usadas sólo para acceso de datos (no programación del PLC) y donde el
tiempo esperado antes del siguiente uso es significante, por ejemplo más largo que
un segundo. Si los clientes siguen este principio, permite un servidor con recursos
limitados de conexión reparar un número más grande de clientes potenciales, así
como facilitar las estrategias de recuperación de error como la selección de una IP
objetivo diferente. Debe recordarse que la comunicación extra y carga de CPU
causaron por cerrar y abrir una conexión es comparable a eso causado por una
simple transferencia de Modbus.
CAPITULO 6
APLICACIÓN
COMUNICACIÓN DE LOS COMPUTADORES DE FLUJO SOLARTRON
MONITOREO DE DENSITOMETROS
El propósito de este capitulo es mostrar algunos ejemplos prácticos del uso de este
protocolo, donde quedara claro las ventajas y alcance de las aplicaciones, no es el
objetivo dar a detalle los pormenores del desarrollo ya que esto es información de
las empresas desarrolladoras.
6.1 COMUNICACIÓN SOLARTRON
Uno de los equipos para la medición en transferencia de custodia de productos

derivados del petróleo son las computadoras de flujo, los cuales son dispositivos
que toman las señales de campo, las cuantifican y las utilizan para hacer los
cálculos necesarios en la totalización de un volumen.
El objetivo inicial de estos equipos era simplemente la totalización del producto,

pero con el paso del tiempo y buscando un grado de automatización mayor se
requirió que estos equipos controlaran parte del proceso, dentro de estos
requerimientos se encuentra:
 Control de válvulas
 Totalización por lotes
 Totalización por estación
 Control con programas de calibración de sus medidores
 Control del proceso por presión y/o por flujo
Los equipos fueron evolucionando hasta poder manejar los puntos anteriores, pero
no existía una interfase hombre maquina, la configuración y operación del equipo
se realizaba frente a panel, siendo un trabajo cansado y que requeria amplio
conocimiento del equipo.
Inicio de computadoras con Modbus
Así pues las principales marcas en el desarrollo de los computadores de flujo tiene
la necesidad de proporcionar una interfase hombre maquina, y el protocolo Modbus
es elegido por OMNI Flor Computer, al ser OMNI el computador más vendido a nivel
mundial el resto de los fabricantes tienen que diseñar computadores de flujo con
Modbus en sus puertos, para poder ofrecer una interfase hombre maquina a través
de una PC.
OMNI baja su poder en el mercado mundial y muchas marcas empiezan a colocar
mejor sus equipos en la industria del petróleo, y nos encontramos con equipos
nuevos como es AcuLoad, y la familia de computadores 795X de Solartron Mobrey,
estos últimos con un desarrollo tremendo de tecnología, y sobre todo desarrollo en
el aspecto de comunicaciones, teniendo puertos seriales con el protocolo Modbus,
esto podrá sonar trivial ya que OMNI contaba también con protocolo Modbus, pero
Solartron implemento cosas realmente innovadoras como es la total configuración
del Modbus del computador, ya que permite elegir el modo de transmisión entre
ASCII o RTU, así como la velocidad de esta transmisión.
Características de Modbus para la familia 795X
Los computadores de Solartron además de lo ya mencionado presentaron

características nunca vistas por otros equipos como fue el High Speed List (HSLst)
que son las listas de acceso rápido, teniendo 2 listas por equipo y con la capacidad
de almacenar 150 variables cada lista divididos en bloque de 50 variables.
Es decir en total se tiene la posibilidad de almacenar hasta 300 variables en sus 6

bloques que van de la A a la F, esto tiene el objetivo de que el computador de flujo
al ser un esclavo en una red Modbus responda con mayor rapidez a las peticiones
que se le realicen ya que no requiere de una petición por variable, es decir si deseas
conocer la presión o temperatura no es necesario realizar una petición por variable,
simplemente se configuran estas variables en las listas y se pregunta por la lista
que se desee.
El acceso a estas listas se logra a partir de la dirección base de esclavo Modbus

que se le configure al equipo, ya que estas listas se comportan como esclavos
virtuales, es decir que se simula que cada una de estas listas es un equipo
conectado a la red Modbus.
El acceso esta dado de la siguiente forma:
HSLst 1 = dirección base +1

HSLst 2 = dirección base +2
De este modo es posible realizar una configuración sin problemas y lograr

integraciones con relativa facilidad.
Pero esta característica es solo una parte del desarrollo de Solartron Mobrey, el
equipo que funciona como esclavo puede ser también un maestro, pero se debe de
tener la precaución de no intentar esto por el mismo puerto ya que eso no es posible
y causaría una colisión de datos, lo que provoca que los equipos se reinicien, con
lo que perderán su totalización y si el equipo esta controlando válvulas puede causar
problemas operativos, es por ello que se cuenta con 3 puertos seriales y con la
posibilidad de tener un puerto Ethernet por medio del cual se puede tener acceso
vía TCP/IP.
El objetivo de que el equipo funcione como un maestro es pensar en un sistema

redundante. Es decir que las señales de campo le llegan a dos equipos y si el equipo
como “Duty” sufre algún daño la computadora “Stand by” toma su lugar en el control
del proceso.
A sistema de
Supervisión
Figura 6.1 computadoras en Duty – Stand by
Ambos tienen las señales de campo para medición, pero solo una de ellas tiene el
control del proceso así que cuando la computadora Duty se apaga, es necesario
que la computadora Stand by tome el control, pero no puede tomar el control si no
tiene los valores que estaban siendo aplicados, como pueden ser el porcentaje de
apertura de una válvula reguladora, tiempo de inicio de lote, etc.
Esta es la razón por la que el computador Duty actuara como maestro y fijara estos
valores al computador Stand by, cuando ocurra el Hand over la computadora se
intercambiaran las posiciones la computadora 1 será esclavo y la computadora 2
maestro.
Teniendo esto en consideración, Solartron desarrollo en base a Modbus su

configurador que esta en dos versiones que son PC Config y FC Config; ambos con
el propósito de configurar el equipo.
Figura 6.2 Pantalla FC config

Figura 6.3 Pantalla PC Config
Con toda la información de direcciones es posible crear un sistema supervisorio que

proporciona una interfase amigable para el operador y que además permite el
acceso al computador solo para su operación, lo que ayuda a que se desconfigure
por error.
La siguiente pantalla muestra el desarrollo que se realizo para la terminal de

almacenamiento y distribución Azcapotzalco en la ciudad de México, siendo uno de
los proyectos más notables y donde se explota las capacidades del equipo Solartron
en un 90%, así como el hecho de que se integraron los PLC’s de la empresa
Yokogawa.
Figura 6.4 Sistema Azcapotzalco
Por ultimo mostramos una pantalla del sistema supervisorio que se desarrollo para
control de medición, este sistema tiene la intención de llevar el control de lote, así
como cuantificación cada 24 hrs.
El control del proceso lo realiza el equipo 7955 Solartron pero el operador tiene
acceso a través de los sistemas Yokogawa.
Figura 6.5 Supervisorio Infohawk

6.2 Monitoreo de Densitometros
Otra aplicación se desarrollo para una empresa de refrescos donde utilizando

densitometros de la marca Solartron y usando el software Adview desarrollado por
Solartron se tienen conectados 5 densitometros cuyo propósito es medir la densidad
del jarabe utilizado para la bebida, pero adicionalmente el equipo calcula la
concentración en ºBrix aquí se tiene la desventaja de que el software Adview es
para configurar el densitometro no para monitoreo, pero al poder configurar la
dirección del esclavo es posible cambiar de un densitometro a otro cuando se desee
ver otro equipo, la desventaja es que no es posible hacerlo para los 5 equipos a la
vez, la densidad el equipo la entrega por una salida de 4 – 20mA al igual que la
función especial (en este caso ºBrix), que están conectados a alarmas para cuando
el jarabe sale de los parámetros.
Figura 6.6 Software Adview para el monitoreo y configuración

El CIATEQ esta trabajando en el desarrollo del software para

monitoreo/configuración de los 5 densitometros al mismo tiempo, cosa que no se
había hecho antes.
Con estas dos aplicaciones podemos dar un panorama de la importancia de un

protocolo como lo es Modbus y de que las posibilidades de integración son infinitas,
gracias a la transparencia.
GLOSARIO DE TÉRMINOS
CIM Computadoras Integradas

DCCS Sistemas de control de computadoras distribuidas
OSI Sistema abierto de interconexión
MAP Protocolo de automatización de manufactura
LLC Control lógico de enlace
MAC Control de acceso al medio
MMS Especificación del mensaje de manufactura
DDC Control digital directo
PLC Controlador lógico programable
NC Controlador numérico
FMS Sistema flexible de manufactura
Multi Drop Conexión en cascada en un par de hilos
EMI Interferencia electromagnética
Actuador Dispositivo que controla a un elemento de campo,
Racks Panel para montar dispositivos
RFI Interferencia de radiofrecuencia
RS-232 Transmisión serial punto a punto
RS-485 Transmisión serial con opción multi drop
Broadcast Mandar señal a todo los elementos
ASCII Código estándar americano para el intercambio de
información
RTU Unidad terminal remota
LRC Comprobación longitudinal redundante
CRC Comprobación de renuncia cíclica
LSB Bit menos significativo
MSB Bit más significativo
HDLC Control de enlace de datos en el nivel alto.
FIFO Primero en entrar primero en salir
NAK Conocimiento negativo
ADU Unidad de aplicación de datos

IP Protocolo de Internet
MBAP Protocolo de aplicación Modbus
PDU Unidad de dato del protocolo
TCP Protocolo del control de transporte
BSD Distribución de software Berkeley
BIBLIOGRAFÍA
“Modbus Protocol Reference Guide”.

(PI-MBUS-300 Rev. B). Modicon Inc..
“TCP/IP: Principios Básicos, Protocolos y Arquitectura”

Comer, Douglas .E.;,
Vol. I, 3ª Edición
Ed. Prentice-Hall; 1996.
“Transmisión de Datos y Redes de Computadores”

García-Teodoro, P.; Díaz-Verdejo, J.E.; López-soler, J.M.
Ed. Prentice-Hall; 2003.
“Redes locales en la industria “

Justo Carracedo Gallardo.
Ed. Marcombo, 1988. - 119 p
“Ingeniería de la automatización industrial”

Piedrafita Moreno, Ramón
2ª Edición
Ed. ra-ma
"Instrumentación Industrial".
CREUS A.
5ª Edición.
Ed. Marcombo. (1993).
7955 Flow Computer Operating Manual

Solartron Mobrey HB552540
APÉNDICE A
RESPUESTAS DE EXCEPCIÓN
RESPUESTAS DE EXCEPCIÓN
CÓDIGOS DE EXCEPCIÓN
A.1 RESPUESTAS DE EXCEPCIÓN
Excepto para mensajes tipo difusión, cuando un dispositivo maestro envía una
petición a un dispositivo esclavo, espera una respuesta normal.
Uno de cuatro posibles eventos pueden ocurrir desde la petición del maestro:
 Si el dispositivo esclavo recibe la petición sin error de comunicación y

puede manejar la petición normalmente, devuelve una respuesta normal.
 Si el esclavo no recibe la petición debido a un error de comunicación, no

hay devolución de respuesta. El programa del maestro eventualmente
procesará una condición de tiempo excedido - timeout -, para la petición.
 Si el esclavo recibe la petición, pero detecta un error de comunicación

(paridad, LRC, o CRC), no hay devolución de respuesta. El programa del
maestro eventualmente procesará una condición de tiempo excedido –
timeout -, para la petición.
 Si el esclavo recibe la petición sin error de comunicación, pero no puede

manejarla (por ejemplo, si la solicitud es leer un una bobina o registro
inexistente), el esclavo devolverá una respuesta de excepción informando
al maestro de la naturaleza del error.
El mensaje de respuesta de excepción tiene dos campos que lo diferencian de una

respuesta normal:
Campo de Código de Función: En una respuesta normal el esclavo replica el

código de función de la petición original en el campo del código de función de la
respuesta. Todos los códigos de función tienen el bit más significativo (MSB) a 0
(sus valores están por debajo de 80 hexadecimal). En una respuesta de excepción,
el esclavo establece el MSB del código de función a 1.Esto hace que el código de
función en una respuesta de excepción resulte 80 hexadecimal mas alto de lo que

sería para una respuesta normal.
Con el MSB del código de función activado, el programa de aplicación del maestro
puede reconocer la respuesta de excepción y puede examinar en el campo de datos
el código de excepción.
Campo de Datos: En una respuesta normal, el esclavo puede devolver datos o

estadísticas en el campo de datos (cualquier información que fuera solicitada en la
petición). En una respuesta de excepción, el esclavo devuelve un código excepción
en el campo de datos. Esto define la condición del esclavo que causó la excepción.
La figura A.1 muestra un ejemplo de una petición del maestro y una respuesta de
excepción de un esclavo. Los campos del ejemplo se muestran en hexadecimal.
Figura A.1 Petición del maestro y respuesta de excepción del esclavo.

En este ejemplo, el maestro direcciona una petición al dispositivo esclavo 10 (0A

hex).El código de función (01) es corresponde a una operación Leer el Estado de
una Bobina. Se devuelve el estado de la bobina en la dirección 1245 (04 A1 hex).
Observe que sólo se lee una bobina, como se ha especificado en el campo del
número de bobinas (0001).
Si la dirección de la bobina es inexistente en el dispositivo esclavo, el esclavo

devolverá la respuesta de excepción con el código de excepción mostrado (02). Eso
especifica un dato de dirección ilegal para el esclavo. Por ejemplo, si el esclavo es
un 984-385 con 512 bobinas, podría devolver este código.
A.2 CÓDIGOS DE EXCEPCIÓN
Código Nombre Significada

01 Función Ilegal El código de función recibido en la petición no es
una acción permitida para el esclavo. Si un
comando Completar Selección de Programa fue
notificado, este código indica que no le precedió
función programa.
02 Dato de dirección El dato de dirección recibido en la petición no es

Ilegal una dirección permitida para el esclavo
03 Dato de Valor Un valor contenido en el campo de datos de la

Ilegal petición no es un valor admisible para el esclavo.
04 Fallo dispositivo Ha ocurrido un error no recuperable mientras el

esclavo esclavo estaba intentando ejecutar la acción
solicitada.
05 Reconocimiento El esclavo ha aceptado la petición y está

procesándola, pero requerirá un tiempo largo para
hacerlo. Esta respuesta se devuelve para prevenir
que ocurra un error de tiempo excedido en el
maestro. El maestro puede notificar a continuación
un mensaje Completar Selección de programa
para determinar si se ha completado el
procesamiento.
06 Dispositivo El esclavo ha aceptado la petición y está

esclavo Ocupado procesándola, pero requerirá un tiempo largo para
hacerlo. Esta respuesta se devuelve para prevenir
que ocurra un error de tiempo excedido en el
maestro. El maestro puede notificar a continuación
un mensaje Completar Selección de programa para
determinar si se ha completado el procesamiento.
07 Reconocimiento El esclavo no puede efectuar la función de

negativo programa recibida en la petición. Este código es
devuelto por una petición de programación fallida,
utilizando código de función 13 ó 14 decimal. El
maestro debería pedir al esclavo diagnóstico o
información de error.
08 Error de paridad El esclavo ha intentado leer memoria extendida,

en memoria pero ha detectado un error de paridad en la
memoria.. El maestro puede reintentar la petición,
pero el servicio debe ser requerido al dispositivo

esclavo.
APÉNDICE C
GENERACIÓN DEL LRC
GENERACIÓN DEL CRC

B.1 GENERACIÓN DEL LRC
El campo Comprobación de Redundancia Longitudinal (LRC) es un byte, que

contiene un valor binario de 8 bits. El valor LRC es calculado por el dispositivo
emisor, que añade el LRC al mensaje. El dispositivo receptor recalcula un LRC
durante la recepción del mensaje y compara el valor calculado con el valor
verdadero recibido en el campo LRC. Si los dos valores no son iguales, resulta un
error.
El LRC se calcula sumando entre sí los sucesivos bytes del mensaje, descartando
cualquier acarreo y luego complementando a dos el valor resultante. El LRC es un
campo de 8 bits, por lo tanto cada nueva suma de un carácter que resultara ser
mayor de 255 simplemente ‘hace pasar el valor del campo por cero. Dado que no
hay un noveno bit, el acarreo se descarta automáticamente.
Un procedimiento para generar un LRC es:
1.- Sumar todos los bytes del mensaje, excluyendo los ‘dos puntos’ de comienzo y
el par CRLF del final. Sumarlos en un campo de 8 bits, así serán descartados los
acarreos.
2.- Restar el resultado del paso anterior de FF hex (todos los bit a 1), para producir
el complemento a uno.
3.- Sumar 1 al resultado del paso anterior para producir el complemento a 2.
Situando el LRC en el Mensaje
Cuando los 8 bits del LRC (2 caracteres ASCII) son transmitidos en el mensaje, el
carácter de orden alto será transmitido en primer lugar, seguido por el carácter de
orden bajo.
Por ejemplo, si el valor del LRC es 61 hex (0110 0001):
Figura B.1 secuencia de caracteres LRC
Ejemplo
Se muestra mas abajo un ejemplo de función en lenguaje C que genera el LRC.
La función toma dos argumentos:
Unsigned char *auchMsg ; Un puntero al primer byte después del

‘dos puntos’ en el buffer de mensaje
que contiene los datos binarios sobre
los que efectuar el LRC.
Unsigned short usDataLen ; La cantidad de bytes en el buffer de

mensaje sobre los que se haya de
realizar el LRC.
La función devuelve el LRC como un tipo unsigned char.
Función para Generación del LRC

static unsigned char LRC (auchMsg, usDataLen)
unsigned char *auchMsg ; /* apunta a la parte del mensaje a calcularle el LRC */

unsigned short usDataLen; /*cantidad de bytes a tratar, dentro del mensaje */
{
unsigned char uchLRC = 0; /* LRC inicializado */
while (usDataLen--) /* a lo largo de todo el buffer de mensaje */
uchLRC += *auchMsg++; /* suma un byte del buffer, sin acarreo */
return ( (unsigned char) (- ((char) uchLRC))); /* devuelve el complemento a dos */
}
B.2 GENERACIÓN DEL CRC
El campo de Comprobación de Redundancia Cíclica es de dos bytes, conteniendo

un valor binario de 16 bits. El valor del CRC es calculado por el dispositivo emisor,
el cual añade el CRC al mensaje. El dispositivo receptor recalcula un CRC durante
la recepción del mensaje y compara el valor calculado con el valor actual recibido
en el campo de CRC. Si los dos valores no son iguales, resulta un error.
Para calcular el valor CRC Modbus se precarga un registro de 16 bits, con todos
ellos a 1. Luego comienza un proceso que toma los sucesivos bytes del mensaje y
los opera con el contenido del registro y actualiza éste con el resultado obtenido.
Sólo los 8 bits de dato de cada carácter son utilizados para generar el CRC. Los bits
de arranque y paro y el bit de paridad , no afectan al CRC.
Durante la generación del CRC, se efectúa una operación booleana OR eclusivo

(XOR) a cada carácter de 8 bits con el contenido del registro. Entonces al resultado
se le aplica un desplazamiento de bit en la dirección de bit menos significativo (LSB),
rellenando la posición del bit más significativo (MSB) con un cero. El LSB es extraído
y examinado. Si el LSB extraído fuese un 1, se realiza un XOR entre el registro y un
valor fijo preestablecido. Si el LSB fuese un 0, no se efectúa el XOR.
Este proceso es repetido hasta haber cumplido 8 desplazamientos. Después del

último desplazamiento (el octavo), el próximo byte es operado XOR con el valor
actual del registro y el proceso se repite con ocho desplazamientos más, como se
ha descrito mas arriba y así con todos los bytes del mensaje.. El contenido final del
registro, después que todos los bytes del mensaje han sido procesados, es el valor
del CRC.
Un procedimiento para generar un CRC es:
1. Cargar un registro de 16 bits que denominaremos registro CRC, con FFFF (todos
1).
2. XOR del primer byte - 8 bits - del mensaje con el byte de orden bajo del registro
CRC de 16 bits, colocando el resultado en el registro CRC.
3. Desplazar el registro CRC un bit a la derecha (hacia el LSB - bit menos

significativo -, rellenando con un cero el MSB – bit mas significativo -. Extraer y
examinar el LSB.
4. (Si el LSB era 0): Repetir paso 3 (otro desplazamiento).

(Si el LSB era 1): Hacer XOR entre el registro CRC y el valor
polinómico A001 hex (1010 0000 0000 0001).
5. Repetir los pasos 3 y 4 hasta que se hayan efectuado 8 desplazamientos. Una

vez hecho esto, se habrá procesado un byte completo – 8 bits -.
6. Repetir los pasos 2 al 5 para el próximo byte – 8 bits – del mensaje. Continuar
haciendo ésto hasta que todos los bytes hayan sido procesados.
7. El contenido final del registro CRC es el valor CRC.
8. Cuando el CRC es situado en el mensaje, sus bytes de orden alto y bajo han de
ser permutados como se describe mas abajo.
Situando el CRC en el Mensaje
Cuando el CRC de 16 bits (2 bytes) es transmitido en el mensaje, el byte de orden

bajo se transmitirá primero, seguido por el byte de orden alto.
Por ejemplo, si el valor del CRC es 1241 hex (0001 0010 0100 0001):
Figura B.2 Secuencia byte CRC

Ejemplo
Un ejemplo de una función C que genera CRC se muestra en las siguientes páginas.
Todos los valores CRC posibles son cargados previamente en dos matrices fila, que
son simplemente indexadas a medida que la función va procesando los bytes del
buffer de mensaje. Una de las matrices contiene los 256 valores posibles de CRC
del byte de orden alto del campo CRC de 16 bits y la otra matriz contiene todos los
valores de byte de orden bajo.
Indexar el CRC de esta manera proporciona una ejecución más rápida, que la que
pudiera alcanzarse calculando un nuevo valor CRC con cada nuevo carácter del
buffer del mensaje.
Nota Esta función realiza internamente el intercambio de los bytes alto/bajo

del CRC. Los bytes han sido ya permutados en el valor CRC que es devuelto
desde la función.
Por lo tanto el valor CRC devuelto desde la función puede ser colocado
directamente en el mensaje para la transmisión.
La función toma dos argumentos:
Unsigned char *puchMsg ; Un puntero al primer byte en el buffer

de mensaje que contiene los datos
binarios sobre los que efectuar el CRC.
Unsigned short usDataLen ; La cantidad de bytes en el buffer de

mensaje sobre los que se haya de
realizar el CRC.
La función devuelve el CRC como un tipo unsigned short.
Función para Generación del CRC
unsigned short CRC16 (puchMsg, usDataLen)
unsigned char *puchMsg ; /* apunta al mensaje a calcularle el CRC */

unsigned short usDataLen; /*cantidad de bytes a tratar, dentro del mensaje */
{
unsigned char uchCRCHi = 0xFF; /* byte alto del CRC inicializado */
unsigned char uchCRCLo = 0xFF; /* byte bajo del CRC inicializado */
unsigned uIndex; /* indexará a la tabla de valores CRC */
while (usDataLen--) /* a lo largo de todo el buffer de mensaje */
{
uIndex = uchCRCHi ^ *puchMsg++ ; / *calcula el CRC */
uchCRCHi = uchCRCLo ^ auchCRCHi [uIndex] ;
uchCRCLo = auchCRCLo [uIndex] ;

}
return ( uchCRCHi << 8 | uchCRCLo);
}

Niveles Jerárquicos en Sistemas de Automatización

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Niveles Jerárquicos en Sistemas de Automatización

Transféré par

Droits d'auteur :

Formats disponibles

Seminario de Titulación Protocolo de Comunicación Modbus

Introducción a las Redes Industriales 1

1.1. Automatización Industrial y Redes de Comunicación 2

2.1. Introducción al Protocolo de Comunicación Modbus… 22

-Como es manipulado el campo de función… 32

Datos y Funciones de Control… 42

4.2 Subfuncion de Diagnostico…………………….. 99

-11 Regreso del contador de mensajes del bus 102

-14 Regreso del contador de mensajes del esclavo 103

Modbus TCP/IP……… 107

5.3 Descripción Funcional………… 113

El objetivo es tener un material claro y objetivo para comprender el modo de operación de

La falta de información acerca de este tema es el principal problema, ya que en lo referente

INTRODUCCIÓN A LAS REDES INDUSTRIALES

AUTOMATIZACIÓN INDUSTRIAL Y REDES DE COMUNICACIÓN.

VISTA GENERAL DE LA AUTOMATIZACIÓN INDUSTRIAL Y REDES DE

NIVELES JERÁRQUICOS EN SISTEMAS DE AUTOMATIZACIÓN

1.1 AUTOMATIZACIÓN INDUSTRIAL Y REDES DE COMUNICACIÓN

Cuando las tecnologías de automatización digitales se pusieron disponibles en los

Los últimos sistemas de automatización industriales usan arquitecturas muy

La llave del éxito el integrar los sistemas de automatización grandes es poner

El protocolo de automatización industrial (MAP) fue desarrollado para superar

condiciones para comunicaciones en tiempo crítico y no incluye las capas 3 a 6 de

La arquitectura del mini-Map consiste en la capa de la aplicación, la subcapa de

La especificación del mensaje industrial (manufacturing message specification

El desempeño y la condición de fiabilidad de un sistema de automatización industrial

 Verifique el desempeño de la red para reunir los requisitos;

Una red de comunicación para un sistema de automatización industrial debe

automatización industrial. La evaluación del desempeño de una red de

Muchos problemas de comunicación en una red de comunicación para un sistema

Entre los componentes de un sistema de automatización industrial, la red de

1.2 VISTA GENERAL DE LA AUTOMATIZACIÓN INDUSTRIAL Y REDES DE

A principios de los años 20, el sistema de control de proceso y el sistema industrial

El uso de sistemas de control centralizados para grandes sistemas a aumentados

Al principio de 1960, la primera vez que se uso una computadora como un

control numérico (numerically controlled (NC)) llego a controlar las herramientas de

Las técnicas y equipos necesarios para las comunicaciones de datos a gran

A mediados de los setenta, el primer sistema de control de computadora distribuido

El uso de las redes de área local para interconectar computadoras y dispositivos de

Como los sistemas de automatización industriales llegaron a ser grandes y el

Protocolo de Automatización Industrial (Manufacturing Automation Protocol (MAP))

Para el nivel bajo de la red de comunicación para la Industria de automatización, las

1.3 NIVELES JERÁRQUICOS EN SISTEMAS DE AUTOMATIZACIÓN

Los sistemas de automatización industriales pueden ser muy complejos, y

El nivel más bajo de la jerarquía de automatización es el nivel de campo que incluye

Figura 1.1 jerarquía de un sistema de automatización industrial

Para el nivel de campo la comunicación, paralelo, cables de varios alambres e

evolucionado a la red de comunicación de bus para cubrir con el costo de cableado

Hoy día, el fieldbus es usado a menudo para el traslado de información en el nivel

En el nivel de célula, el flujo de información consiste principalmente en la carga de

Muchos esfuerzos se han hecho para la regularización de la red de comunicación

El nivel de planta, es el nivel de cima de una planta o un sistema de automatización

Un factor principal al elegir una red de comunicación industrial es el tipo de sistema

El cable coaxial se usa para la transmisión de datos a gran velocidad en distancias

El cable coaxial está ampliamente disponible, relativamente barato, y puede ser

La Fibra óptica proporciona un incremento en la capacidad de transmisión arriba de

En muchas situaciones de medición móvil o temporal, lo dispositivos inalámbrico es

En comunicación digital, los datos pueden tomar solo valores binarios de 1 o 0.

La transmisión puede ser asíncrona o síncrona, dependiendo de la manera de envió

independientemente a una velocidad no uniforme. El modo de transmisión síncrona

Los métodos de la transmisión en redes de comunicación industriales incluyen

La transmisión digital en fibra óptica es basada en representar los unos y ceros

Tres principales topologías son empleadas para las redes de comunicación

En la topología bus, cada nodo es directamente unido a un canal de comunicación