1.3 niveles jerárquicos en sistemas de automatización industriales

Seminario de Titulación
Protocolo de Comunicación Modbus
REDES INDUSTRIALES
PROTOCOLO MODBUS
Mayo 2004
Seminario de Titulación
Protocolo de Comunicación Modbus
ÍNDICE
CAPITULO 1
Introducción a las Redes Industriales
1
1.1.
1.2.
2
Automatización Industrial y Redes de Comunicación
Vista General de la Automatización Industrial y Redes de
Comunicación
1.3. Niveles Jerárquicos en Sistemas de Automatización
Industrial
-Nivel de campo
-Nivel de célula..
-Nivel de área..
-Nivel de planta…
-Medios de transmisión…
-Topología de red…
1.4. Consideraciones de diseño..14
-Costo…
-Servicio o función de la red…
-Tolerancia con respecto al medio ambiente..
-Medios físicos..
-Expansión ..
-Mantenimiento..
-Requisitos de comunicación para los sistemas de
automatización…
5
8
8
10
11
11
11
13
15
16
17
17
18
18
18
CAPITULO 2
Protocolo Modbus..
2.1. Introducción al Protocolo de Comunicación Modbus…
-Intercambio de información en una red Modbus..
-Intercambio de información sobre redes diferentes a
Modbus..
-Pregunta..
-Respuesta..
2.2. Los Dos Modos de Transmisión Serial…
-Modo ASCII..
-Modo RTU..
2.3. Tramas de Mensaje Modbus..
-Trama ASCII..
-Trama RTU..31
-Como es manipulado el campo de dirección…
21
22
24
25
26
27
27
28
28
30
30
32
Seminario de Titulación
Protocolo de Comunicación Modbus
-Como es manipulado el campo de función…
-Contenido del campo de datos..
-Contenido del campo de comprobación de error..
-Como son trasmitidos los caracteres en serie..
2.4. Métodos de Comprobación de Error..
-Control de Paridad…
-Comprobación LRC..
-Comprobación CRC..
32
34
35
36
37
37
39
39
CAPITULO 3
Datos y Funciones de Control…
3.1. Formato de las Funciones Modbus…
3.2. Código de Funciones Soportadas por Los Controladores..
-01 Lectura del estatus de una bobina..
-02 Lectura del estatus de una entrada..
-03 Lectura de registros sostenidos..
-04 Lectura de registro de entradas..
-05 Forzar bobinas simples………
-06 Predeterminar registros simples…….
-07 Lectura de estatus de excepción…….
-11 Sacar un contador de eventos de comunicaciones……
-12 Traer el registro de eventos de comunicaciones……….
-15 Forzar varias bobinas…....
-16 Predefinir varios registros……
-17 Reportar el identificador del esclavo……..
-20 Lectura de referencias generales…………
-21 Escritura de referencias generales……….
-22 Escritura de registros 4X con una mascara…….
-23 Lectura/escritura de registros 4X……………….
-24 Lectura de una cola FIFO…………….
42
43
47
48
50
52
54
56
58
59
61
63
68
70
72
81
84
88
90
92
CAPITULO 4
Subfunciones de Diagnostico…………………
4.1 Función 08 Diagnósticos……………………..
-Efectos del diagnostico en el esclavo…….
4.2 Subfuncion de Diagnostico……………………..
-00 Regreso de datos de la pregunta………..
-01 Opción de reinicio de la comunicación….
-02 Regreso del registro de diagnostico
-03 Cambio del delimitador de entrada ASCII
-04 Forzar el modo de solo escucha
-10 Borrar contadores y registro de diagnostico
95
96
96
99
99
99
100
101
101
102
Seminario de Titulación
Protocolo de Comunicación Modbus
-11 Regreso del contador de mensajes del bus
-12 Regreso del contador de errores de
comunicación del bus..
-13 Regreso del contador de errores de excepción
en el bus….
102
-14 Regreso del contador de mensajes del esclavo
-15 Regreso del contador de no respuestas del esclavo
-16 Regreso del contador NAK del esclavo
-17 Regreso del contador de ocupado del esclavo
-18 Regreso del contador de caracteres
desbordados en el bus…
-19 Regreso del contador de IOP desbordados (884)……
-20 Borrar banderas y contadores de desbordamiento…..
103
103
104
.104
102
103
105
105
106
CAPITULO 5
Modbus TCP/IP………
5.1 Modelo Cliente Servidor………
5.2 Descripción del Protocolo………..
-Arquitectura general de comunicación…..
-La unidad de datos de la aplicación sobre
Modbus TCP/IP
-Descripción del encabezado MBAP………
5.3 Descripción Funcional…………
-Agente de conexión TCP
-Uso de la pila TCP/IP
-Capa de aplicación de comunicación
107
108
109
109
…..110
111
113
118
123
124
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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,
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
Host
Procesador
MAP
984-985
(Modbus
Plus) y
S980 (MAP)
Modbus
Programador
P230
Modbus Plus
AT/MC-984
y Host/MMI
984 A/B y
S985
Modbus
BM85
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 maestroesclavo, en donde solo un dispositivo denominado (el maestro) puede iniciar
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Bytes de datos
8 bits
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.)
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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).
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación 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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
Figura 3.1 pregunta típica
Figura 3.2 Respuesta típica
Campos contenidos en los mensajes sobre Modbus Plus
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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
01
02
03
04
05
06
07
08
Nombre
Leer Estados de Bobinas
Leer Estados de Entradas
Leer Registros sostenidos
Leer Registros de Entradas
Forzar una única Bobina
Preestablecer un único Registro
Leer Status de Excepción
Diagnosticos (ver Capítulo 3)
384
Y
Y
Y
Y
Y
Y
Y
484
Y
Y
Y
Y
Y
Y
Y
584
Y
Y
Y
Y
Y
Y
Y
884
Y
Y
Y
Y
Y
Y
Y
M84
Y
Y
Y
Y
Y
Y
Y
984
Y
Y
Y
Y
Y
Y
Y
Seminario de Titulación
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Programar 484
Selección 484
Buscar Contador de Eventos de
Comunicación
Buscar Anotac de Eventos de Comunic
Programar Controlador
Selección Controlador
Forzar Múltiples Bobinas
Preestablecer Múltiples Registros
Reportar Identificación de Esclavo
Programar 884/M84
Resetear Enlace de Comunicaciones
Leer Referencia General
Escribir Referencia General
Escribir con máscara en Registros 4X
Leer/Escribir Registros 4X
Leer Cola FIFO
Protocolo de Comunicación Modbus
N
N
Y
Y
Y
N
N
N
Y
N
N
N
N
N
N
N
N
Y
Y
Y
Y
Y
Y
Y
N
N
N
N
N
N
N
N
N
N
Y
Y
Y
N
N
N
N
N
N
N
Y
Y
Y
Y
Y
Y
N
N
Y
Y
N
N
N
N
N
N
Y
Y
Y
Y
Y
N
N
N
N
N
N
N
N
Y
Y
Y
Y
Y
N
N
N
N
N
Y
Y
Y
Y
Y
Y
N
N
Y
Y
(1)
(1)
(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:
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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-ONOFF-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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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 1019710218 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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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: ONOFF-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.
El apéndice B muestra los parámetros máximos soportados por varios modelos de
controladores.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
El apéndice B muestra los parámetros máximos soportados por varios modelos de
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
El apéndice B muestra los parámetros máximos soportados por varios modelos de
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
El apéndice B muestra los parámetros máximos soportados por varios modelos de
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Figura 3.15 Respuesta normal por parte del dispositivo.
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”
Seminario de Titulación
Protocolo de Comunicación Modbus
“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.
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
884
Aquí se muestra un ejemplo de una petición para el estatus de excepción en el
dispositivo esclavo 17.
Figura 3.16 pregunta para leer estatus de excepciones
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Figura 3.17 Respuesta normal por parte del dispositivo.
En este ejemplo, el dato de las bobinas es 6D que en binario corresponde a
01101101. De izquierda a derecha las bobinas son: apagado- encendidoencendido- 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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Figura 3.18 Respuesta normal por parte del dispositivo.
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Figura 3.20 Respuesta normal por parte del dispositivo.
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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
0
1
2
3
4
5
6
7
Contenido
No usado
Error de comunicación
No usado
No usado
Carácter desbordado
Actualmente en modo de solo escuchar.
Broadcast recibido
1
Eventos enviados por el esclavo Modbus
Seminario de Titulación
Protocolo de Comunicación 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
0
1
2
3
4
5
6
7
Contenido
Excepción de lectura enviado (código de excepción 1-3)
Excepción de interrupción de esclavo (código de excepción 4)
Excepción de esclavo ocupado (código de excepción 5-6)
Excepción de programa NAK esclavo (código de excepción 4)
A ocurrido un error de tiempo de espera para escritura
Actualmente en modo de solo escuchar.
1
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
0
1
2
3
4
5
6
7
Contenido
0
0
1
0
0
0
0
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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
0
1
2
3
4
5
6
7
Contenido
0
0
0
0
0
0
0
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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
dispositivo esclavo 17.
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
Bobina 27 26 25 24 23 22 21 20
0
0
0
0
0
0
0
1
-
-
-
-
-
-
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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:
Figura 3.22 Respuesta normal por parte del dispositivo.
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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:
Seminario de Titulación
Protocolo de Comunicación Modbus
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:
Figura 3.24 Respuesta normal por parte del dispositivo.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
Figura 3.26 Respuesta normal por parte del dispositivo.
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:
Seminario de Titulación
Protocolo de Comunicación Modbus
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)
Seminario de Titulación
Protocolo de Comunicación Modbus
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:
Seminario de Titulación
Protocolo de Comunicación Modbus
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:
Seminario de Titulación
Protocolo de Comunicación Modbus
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)
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
Seminario de Titulación
6,7
Protocolo de Comunicación Modbus
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)
Seminario de Titulación
8,9
Protocolo de Comunicación Modbus
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:
Seminario de Titulación
Protocolo de Comunicación Modbus
Byte
Contenido
1
identificador del esclavo (0 para el micro 84)
2
Indicador de estatus corriendo (0= apagado, FF= encendido).
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)
2
Indicador de estatus corriendo (0= apagado, FF= encendido).
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)
2
Indicador de estatus corriendo (0= apagado, FF= encendido).
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
Lógica del
Situación de la
Tamaño de la
usuario
RAM
memoria
Ultimo archivo
Ultimo registro
(decimal)
extendida
32K
32K
0
0
0
16K
64K
72K
8
3727
984 – 785 con cartucho de memoria AS-M785-048
Lógica del
Situación de la
Tamaño de la
usuario
RAM
memoria
Ultimo archivo
Ultimo registro
(decimal)
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Figura 3.28 Respuesta normal por parte del dispositivo.
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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:
Seminario de Titulación
Protocolo de Comunicación Modbus
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
usuario
RAM
memoria
Ultimo archivo
Ultimo registro
(decimal)
extendida
32K
32K
0
0
0
16K
64K
72K
8
3727
984 – 785 con cartucho de memoria AS-M785-048
Lógica del
Situación de la
Tamaño de la
usuario
RAM
memoria
Ultimo archivo
Ultimo registro
(decimal)
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).
Seminario de Titulación
Protocolo de Comunicación Modbus
Figura 3.29 pregunta para escribir referencias generales.
Respuesta:
La respuesta normal es un eco de la pregunta
Figura 3.30 Respuesta normal por parte del dispositivo.
Seminario de Titulación
Protocolo de Comunicación Modbus
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:
Contenido actual =
Hexadecimal
Binario
12
0001 0010
mascara_AND
=
F2
1111 0010
mascara_OR
=
25
0010 0101
mascara_AND
=
0D
0000 1101
resultado
=
17
0001 0111
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Figura 3.32 Respuesta normal por parte del dispositivo.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
Figura 3.34 Respuesta normal por parte del dispositivo.
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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).
Seminario de Titulación
Protocolo de Comunicación Modbus
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:
Figura 3.36 Respuesta normal por parte del dispositivo.
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).
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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
de S
S
S
N
N
S
Regresa el contador de errores de excepción S
S
S
N
N
S
S
S
N
N
N
el
contador
de
errores
comunicación en el bus
13
en el bus.
14
Regresa el contador de mensajes del esclavo
S
Seminario de Titulación
15
Protocolo de Comunicación Modbus
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
caracteres S
S
S
N
N
S
Regreso del contador de IOP desbordados N
N
N
S
N
N
de N
N
N
S
N
N
N
N
N
N
N
S
del
contador
de
desbordados en el bus.
19
(884).
20
borrar
banderas
y
contadores
desbordamiento
21
Obtener/borrar estadisticas de Modbus Plus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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 online.
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Subfunción
Campo de datos
Campo de datos (respuesta)
(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).
Subfunción
Campo de datos
Campo de datos (respuesta)
(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
Seminario de Titulación
Protocolo de Comunicación Modbus
contadores. Los contadores también son borrados después de una falla de
alimentación.
Subfunción
Campo de datos
Campo de datos (respuesta)
(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.
Subfunción
Campo de datos
Campo de datos (respuesta)
(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.
Subfunción
Campo de datos
Campo de datos (respuesta)
(pregunta)
00 0C
00 00
Cantidad de errores CRC
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Subfunción
Campo de datos
Campo de datos (respuesta)
(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.
Subfunción
Campo de datos
Campo de datos (respuesta)
(pregunta)
00 0E
00 00
Cantidad de mensajes del esclavo
15 (0F hexadecimal) Regreso del contador de No respuestas del esclavo
El campo de datos de la respuesta regresa la cantidad de mensajes direccionados
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)
Seminario de Titulación
00 0F
Protocolo de Comunicación Modbus
00 00
Cantidad de no respuestas del
esclavo
16 (10 hexadecimal) Regreso del contador NAK del esclavo
El campo de datos de la respuesta regresa la cantidad de mensajes direccionados
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.
Subfunción
Campo de datos
Campo de datos (respuesta)
(pregunta)
00 10
00 00
Contador NAK del esclavo
17 (11 hexadecimal) Regreso del contador de ocupado del esclavo
El campo de datos de la respuesta regresa la cantidad de mensajes direccionados
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.
Subfunción
Campo de datos
Campo de datos (respuesta)
(pregunta)
00 11
00 00
Contador de dispositivo ocupado del
esclavo
18 (12 hexadecimal) Regreso del contador de caracteres desbordados en el
bus.
Seminario de Titulación
Protocolo de Comunicación Modbus
El campo de datos de la respuesta regresa la cantidad de mensajes direccionados
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.
Subfunción
Campo de datos
Campo de datos (respuesta)
(pregunta)
00 12
00 00
Contador de caracteres desbordados del
esclavo
19 (13 hexadecimal) Regreso del contador de IOP desbordados (884).
El campo de datos de la respuesta regresa la cantidad de mensajes direccionados
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.
Subfunción
Campo de datos
Campo de datos (respuesta)
(pregunta)
00 13
00 00
Contador de IOP desbordados del
esclavo
20 (14 hexadecimal) borrar banderas y contadores de desbordamiento
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Subfunción
Campo de datos
Campo de datos (respuesta)
(pregunta)
00 14
CAPITULO 5
00 00
Eco de los datos en la pregunta.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus

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
Seminario de Titulación
Protocolo de Comunicación Modbus
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).
Seminario de Titulación
Protocolo de Comunicación 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
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Aplicación del Usuario
Capa de
comunicaci
ón de la
aplicación
Interfase
Cliente
Modbus
Cliente Modbus
Parte trasera
de la interfase
modbus
Servidor
Modbus
Administrad
or TCP
Pila de
parametrizaci
on
Administrador
de conexión
Control de
acceso
Pila TCP/IP
Algunos dispositivos solo pueden proporcionar los componentes para funcionar
como servidores o como clientes.
Modelo de la arquitectura de los componentes MODBUS.
Figura 5.5 Arquitectura conceptual delservicio de mensajes MODBUS
Seminario de Titulación
Protocolo de Comunicación 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
principales
objeto
Entradas
Bit simple
tipo
Comentario
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
alterado por un programa de
ura
aplicación
Seminario de Titulación
Protocolo de Comunicación Modbus
Entradas discretas
Petición MODBUS
Bobinas
Registros de
entrada
Registros de salida
Memoria del dispositivo de
aplicación
Dispositivo Servidor Modbus
Figura 5.6 Modelo de los datos Modbus con bloques separados
Memoria del dispositivo de
aplicación
Entradas discretas
Bobinas
Petición MODBUS
Registros de
entrada
Registros de salida
Dispositivo Servidor Modbus
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.
Seminario de Titulación

Protocolo de Comunicación 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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
É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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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).
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación

Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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:
Seminario de Titulación
Protocolo de Comunicación Modbus
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”.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación 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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación 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
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
Figura 6.5 Supervisorio Infohawk
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
El
CIATEQ
esta
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
APÉNDICE A
RESPUESTAS DE EXCEPCIÓN
RESPUESTAS DE EXCEPCIÓN
CÓDIGOS DE EXCEPCIÓN
Protocolo de Comunicación Modbus
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
(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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
A.2 CÓDIGOS DE EXCEPCIÓN
Código Nombre
Significada
01
El código de función recibido en la petición no es una
Función Ilegal
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 una
Ilegal
03
Dato
dirección permitida para el esclavo
de
Valor Un valor contenido en el campo de datos de la
Ilegal
04
Fallo
petición no es un valor admisible para el esclavo.
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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 programa
negativo
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, pero
en memoria
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.
Seminario de Titulación
APÉNDICE C
GENERACIÓN DEL LRC
GENERACIÓN DEL CRC
Protocolo de Comunicación Modbus
Seminario de Titulación
Protocolo de Comunicación Modbus
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):
Seminario de Titulación
Protocolo de Comunicación Modbus
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 ;
unsigned short usDataLen;
/* apunta a la parte del mensaje a calcularle el LRC */
/*cantidad de bytes a tratar, dentro del mensaje */
{
unsigned char uchLRC = 0;
while (usDataLen--)
uchLRC += *auchMsg++;
return ( (unsigned char) (- ((char) uchLRC)));
}
/* LRC inicializado */
/* a lo largo de todo el buffer de mensaje */
/* suma un byte del buffer, sin acarreo */
/* devuelve el complemento a dos */
Seminario de Titulación
Protocolo de Comunicación Modbus
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:
Seminario de Titulación
Protocolo de Comunicación Modbus
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.
Seminario de Titulación
Protocolo de Comunicación Modbus
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
Seminario de Titulación
Protocolo de Comunicación Modbus
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 ;
unsigned short usDataLen;
{
unsigned char uchCRCHi = 0xFF;
unsigned char uchCRCLo = 0xFF;
unsigned uIndex;
while (usDataLen--)
{
uIndex = uchCRCHi ^ *puchMsg++ ;
uchCRCHi = uchCRCLo ^ auchCRCHi [uIndex] ;
uchCRCLo = auchCRCLo [uIndex] ;
}
return ( uchCRCHi << 8 | uchCRCLo);
}
/* apunta al mensaje a calcularle el CRC */
/*cantidad de bytes a tratar, dentro del mensaje */
/* byte alto del CRC inicializado */
/* byte bajo del CRC inicializado */
/* indexará a la tabla de valores CRC */
/* a lo largo de todo el buffer de mensaje */
/ *calcula el CRC */