Informacin Detallada sobre el Protocolo Modbus

Fecha de Publicacin: oct 16, 2014

Visin General

Modbus es un protocolo industrial que fue desarrollado en 1979 para hacer posible la comunicacin entre dispositivos de
automatizacin. Originalmente implementado como un protocolo al nivel de la aplicacin con la finalidad de transferir datos por
una capa serial, Modbus se ha expandido para incluir implementaciones a travs de protocolo serial, TCP/IP y el User Datagram
Protocol (UDP). Este documento ofrece una perspectiva detallada de la implementacin del protocolo.
Contenido

1.
2.
3.
4.
5.
6.

Qu es el Protocolo Modbus?
Unidad de Datos de Protocolo
Unidad de Datos de Aplicacin
Nuevos Cdigos de Funcin
Capas de Red
Modificaciones de ADU

1. Qu es el Protocolo Modbus?

Modbus es un protocolo de solicitud-respuesta implementado usando una relacin maestro-esclavo. En una relacin
maestro-esclavo, la comunicacin siempre se produce en pares, un dispositivo debe iniciar una solicitud y luego esperar una
respuesta y el dispositivo de inicio (el maestro) es responsable de iniciar cada interaccin. Por lo general, el maestro es una
interfaz humano-mquina (HMI) o sistema SCADA y el esclavo es un sensor, controlador lgico programable (PLC) o controlador
de automatizacin programable (PAC). El contenido de estas solicitudes y respuestas, y las capas de la red a travs de las cuales
se envan estos mensajes, son definidas por las diferentes capas del protocolo.

Figura 1. Una Relacin de Red Maestro-Esclavo

Capas del Protocolo Modbus

En la implementacin inicial, Modbus era un solo protocolo construido en base a serial, por lo que no poda ser dividida en
mltiples capas. Con el tiempo, diferentes unidades de datos de aplicacin fueron introducidas ya sea para cambiar el formato del
paquete utilizado a travs de serial o para permitir el uso de redes TCP/IP y UDP (User Datagram Protocol). Esto llev a una
separacin del protocolo principal, el cual define la unidad de datos de protocolo (PDU) y la capa de red, que define la unidad de
datos de aplicacin (ADU).
2. Unidad de Datos de Protocolo

La PDU y el cdigo que la maneja consiste en el ncleo de la Especificacin del Protocolo de Aplicacin Modbus. Esta
especificacin define el formato de la PDU, los diversos conceptos de datos utilizados por el protocolo, el uso de los cdigos de
funcin para tener acceso a esos datos y la implementacin especfica y restricciones de cada cdigo de funcin.
El formato de Modbus PDU est definido como un cdigo de funcin seguido por un conjunto de datos asociado. El tamao y el
contenido de estos datos son definidos por el cdigo de funcin y la PDU completa (cdigo de funcin y datos) no puede exceder
de 253 bytes de tamao. Cada cdigo de funcin tiene un comportamiento especfico que los esclavos pueden implementar de
manera flexible en base al comportamiento de la aplicacin deseada. La especificacin de la PDU define conceptos bsicos para
el acceso y manipulacin de datos; sin embargo, un esclavo puede manejar datos de una manera que no est definida
explcitamente en la especificacin.
Acceso de Datos en Modbus y el Modelo de Datos de Modbus

Los datos disponibles por medio de Modbus son almacenados, en general, en uno de los cuatro bancos de datos o rangos de
direccin: bobinas, entradas discretas, registros de retencin y registros de entrada. Al igual que con gran parte de la
especificacin, los nombres pueden variar dependiendo de la industria o de la aplicacin. Por ejemplo, los registros de retencin
pueden denominarse como registros de salida y las bobinas pueden denominarse como salidas digitales o discretas. Estos
bancos de datos definen el tipo y los derechos de acceso de los datos contenidos. Los dispositivos esclavos tienen acceso directo
a estos datos, los cuales son alojados localmente en los dispositivos. Los datos disponibles por medio de Modbus generalmente
son un subconjunto de la memoria principal del dispositivo. En contraste, los maestros Modbus deben solicitar el acceso a estos
datos a travs de diversos cdigos de funcin. El comportamiento de cada bloque se describe en la Tabla 1.
1/9

www.ni.com

Bloque de Memoria

Tipo de Datos

Acceso de Maestro

Acceso de Esclavo

Bobinas

Booleano

Lectura/Escritura

Lectura/Escritura

Entradas Discretas

Booleano

Solo Lectura

Lectura/Escritura

Registros de Retencin

Palabra Sin Signo

Lectura/Escritura

Lectura/Escritura

Registros de Entrada

Palabra Sin Signo

Solo Lectura

Lectura/Escritura

Tabla 1. Bloques de Modelo de Datos de Modbus

Estos bloques le brindan la habilidad de restringir o permitir el acceso a los diferentes elementos de datos y tambin de
proporcionar mecanismos simplificados en la capa de aplicacin para tener acceso a diferentes tipos de datos.
Los bloques son completamente conceptuales. Pueden existir como direcciones de memoria separadas en un sistema
determinado, pero tambin pueden traslaparse. Por ejemplo, la bobina uno puede existir en la misma ubicacin en memoria como
el primer bit de la palabra representada por el registro de retencin uno. El esquema de direccin se define completamente por el
dispositivo esclavo y su interpretacin de cada bloque de memoria es una parte importante del modelo de datos del dispositivo.
Direccin de Modelo de Datos
La especificacin define que cada bloque contiene un espacio de direccin de un mximo de 65,536 (2 16) elementos. Dentro de
la definicin de la PDU, Modbus define la direccin de cada elemento de datos que va desde 0 a 65,535. Sin embargo, cada
elemento de datos est numerado de 1 a n, donde n tiene un valor mximo de 65,536. Es decir, la bobina 1 est en el bloque de
bobina en la direccin 0, mientras que el registro de retencin 54 est en la direccin 53 de la seccin de la memoria que el
esclavo ha definido como registros de retencin.
No se requiere que los rangos completos permitidos por la especificacin sean implementados por un determinado dispositivo.
Por ejemplo, un dispositivo puede optar por no implementar bobinas, entradas discretas o registros de entrada y en su lugar
solamente usar los registros de retencin 150 al 175 y 200 al 225. Esto es perfectamente aceptable y los intentos de acceso no
vlidos pueden manejarse a travs de excepciones.
Rangos de Direccin de Datos
Aunque la especificacin define los diferentes tipos de datos que existen en diferentes bloques y asigna un rango de direccin
local para cada tipo, esto no se traduce necesariamente en un esquema intuitivo de direccin para fines de documentacin o para
comprender la memoria disponible a travs de Modbus de un dispositivo determinado. Para simplificar la discusin de
ubicaciones del bloque de memoria, se introdujo un esquema de numeracin, el cual aade prefijos a la direccin de los datos en
cuestin.
Por ejemplo, en lugar de referir a un elemento como registro de retencin 14 en la direccin 13, un manual de dispositivo se
referira a un elemento de datos en la direccin 4,014, 40,014 o 400,014. En cada caso, el primer nmero especificado es 4 para
representar registros de retencin y la direccin es especificada usando los nmeros restantes. La diferencia entre 4XXX, 4XXXX
y 4XXXXX depende del espacio de direccin usado por el dispositivo. Si todos los 65,536 registros estn en uso, la anotacin
4XXXXX debe ser usada, ya que permite un rango de 400,001 a 465,536. Si solamente algunos registros son usados, una
prctica comn es usar el rango de 4,001 al 4,999.
En este esquema de direccin, a cada tipo de datos se le asigna un prefijo como se muestra en la Tabla 2.

Bloque de Datos

Prefijo

Bobinas

Entradas Discretas

Registros de Entrada

Registros de Retencin

Tabla 2. Prefijos de Rangos de Datos

Existen bobinas con un prefijo 0. Esto significa que una referencia de 4001 podra referirse al registro de retencin uno o bobina
de 4001. Por esta razn, se recomienda que todas las nuevas implementaciones usen direccin de 6 dgitos con ceros a la
izquierda y se especifique esto en la documentacin. Por lo tanto, el registro de retencin uno es referenciado como 400,001 y la
bobina de 4001 es referenciada como 004,001.
Valores de Inicio de Direccin de Datos
La diferencia entre las direcciones de memoria y los nmeros de referencia es an ms complicada por el ndice seleccionado por
2/9

www.ni.com

La diferencia entre las direcciones de memoria y los nmeros de referencia es an ms complicada por el ndice seleccionado por
una aplicacin determinada. Como se mencion anteriormente, el registro de retencin uno est en la direccin cero.
Tpicamente, los nmeros de referencia son indexados en base a uno, lo que significa que el valor de inicio de un intervalo
determinado es uno. Por lo tanto, 400,001 se traduce literalmente al registro de retencin 00001, el cual est en la direccin 0.
Algunas implementaciones eligen iniciar sus rangos en cero, lo que significa que 400,000 se traduce en el registro de detencin
en la direccin cero. La Tabla 3 muestra este concepto.
Direccin

Nmero de Registro

Nmero (ndice 1, estndar)

Nmero (ndice 0, alternativo)

400001

400000

400002

400001

400003

400002

Tabla 3. Esquemas de ndice de Registro

Los rangos indexados a 1 son comunes y altamente recomendados. En cualquier caso, el valor de inicio para cada rango debe
ser anotado en la documentacin.
Tipos de Datos Grandes

El estndar Modbus proporciona un modelo de datos relativamente simple que no incluye los tipos de datos adicionales fuera de
una palabra sin signo y valor de bit. Aunque esto es suficiente para algunos sistemas, donde los valores de bits corresponden a
los solenoides y rels y los valores de palabra corresponden a los valores de ADC sin escalar, no es suficiente para los sistemas
ms avanzados. Como resultado, muchas implementaciones Modbus incluyen tipos de datos que cruzan los lmites de registros.
El Mdulo NI LabVIEW Datalogging and Supervisory Control (DSC) y KEPServerEX definen un nmero de tipos de referencia.
Por ejemplo, las secuencias almacenadas en un registro de retencin siguen la forma estndar (400,001) pero son seguidas de
un decimal, la longitud y el orden de bytes de la secuencia (400,001.2H, una secuencia de dos caracteres en el registro de
retencin donde el byte alto corresponde al primer carcter de la secuencia). Esto es necesario debido a que cada solicitud tiene
un tamao limitado, por lo que un maestro Modbus debe conocer los lmites exactos de la secuencia en lugar de buscar una
longitud o delimitador como NULL.
Acceso a Bits

Adems de permitir el acceso a los datos que cruza un lmite de registro, algunos maestros Modbus soportan referencias para
bits individuales dentro de un registro. Esto es benfico ya que permite que los dispositivos combinen datos de cada tipo en el
mismo rango de memoria sin tener que dividir los datos binarios en entre bobinas y rangos de entrada discretos. Esto
normalmente es referenciado como un punto decimal y el ndice de bits o nmero, dependiendo de la implementacin. Es decir, el
primer bit en el primer registro puede ser 400,001.00 o 400,001.01. Se recomienda que toda documentacin especifique el
esquema de ndice utilizado.
Endianness de Datos

Los datos de mltiples registros, como el valor de punto flotante de precisin simple, pueden ser transferidos fcilmente en
Modbus al dividir los datos en dos registros. Ya que esto no est definido por el estndar, el endianness (u orden de bytes) de
esta divisin no est definida. Aunque cada palabra no signada debe ser enviada en orden de byte de la red (big-endian) para
cumplir con el estndar, varios dispositivos invierten el orden de bytes para datos de mltiples bytes. La Figura 2 muestra un
ejemplo inusual pero vlido sobre esto.

Figura 2. Intercambio de Orden de Bytes para Datos de Mltiples Palabras

Depende del maestro comprender cmo el esclavo est almacenando informacin en la memoria y decodificarlo correctamente.
Se recomienda que la documentacin refleje el orden de las palabras utilizadas por el sistema. El orden de bytes tambin puede
ser aadido como una opcin de configuracin del sistema, con funciones de codificacin y decodificacin fundamentales, si se
requiere flexibilidad en la implementacin.
Strings

Los strings pueden ser fcilmente almacenados en registros de Modbus. Para simplificar, algunas implementaciones requieren
que las longitudes de los strings sean mltiplos de dos, con cualquier espacio adicional llenado con valores nulos. El orden de los
bytes tambin es una variable en las interacciones de los strings. El formato del string puede o no incluir un NULL como el valor
final. Como ejemplo de esta variabilidad, algunos dispositivos pueden almacenar los datos como se muestra en la Figura 3.
3/9

www.ni.com

Figura 3. Reversin de Orden de Bytes en secuencias de Modbus

Comprender Cdigos de Funcin

En contraste con el modelo de datos que puede variar considerablemente de un dispositivo a otro, los cdigos de funcin y sus
datos son definidos explcitamente por el estndar. Cada funcin sigue un patrn. Primero, el esclavo valida entradas como el
cdigo de funcin, direccin de datos y el rango de datos. Despus, ejecuta la accin solicitada y enva una respuesta adecuada
al cdigo. Si cualquier paso en este proceso falla, se regresa una excepcin al solicitante. El transporte de datos para estas
solicitudes es la PDU.
La PDU de Modbus

La PDU consta de un cdigo de funcin de un byte seguido de hasta 252 bytes de datos de funciones especficas.

Figura 4. La PDU de Modbus

El cdigo de funcin es el primer elemento que ser validado. Si el cdigo de funcin no es reconocido por el dispositivo que
recibe la solicitud, responde con una excepcin. Si se acepta el cdigo de funcin, el dispositivo esclavo comienza a
descomponer los datos de acuerdo con la definicin de la funcin.
Debido a que el tamao del paquete est limitado a 253 bytes, los dispositivos estn limitados a la cantidad de datos que pueden
ser transferidos. Los cdigos de funcin ms comunes pueden transferir entre 240 y 250 bytes de datos del modelo de datos de
esclavos, dependiendo del cdigo.
Ejecucin de Funciones del Esclavo

Segn lo define el modelo de datos, diferentes funciones son definidas para tener acceso a diferentes bloques conceptuales de
datos. Una implementacin comn es que los cdigos tengan acceso a las ubicaciones estticas de la memoria, pero otros
comportamientos estn disponibles. Por ejemplo, el cdigo de funcin 1 (leer bobinas) y el 3 (leer registros de retencin) pueden
tener acceso a la misma ubicacin fsica en la memoria. Por el contrario, el cdigo de funcin 3 (leer registros de retencin) y el
16 (escribir a registros de retencin) tienen acceso a ubicaciones completamente diferentes en la memoria. Por lo tanto, la
ejecucin de cada cdigo de funcin mejor es considerada como parte de la definicin del modelo de datos del esclavo.
Independientemente del comportamiento realizado, se espera que todos los dispositivos esclavos sigan un diagrama de estado
simple para cada solicitud. La Figura 5 muestra un ejemplo de esto para el cdigo 1, que lee bobinas.

4/9

www.ni.com

Figura 5. Leer Diagrama de Estado de Bobinas desde la Especificacin del Protocolo Modbus
Cada esclavo debe validar el cdigo de funcin, el nmero de entradas, la direccin de inicio, el rango total y la ejecucin de la
funcin definida por el esclavo que realiza la lectura.
Aunque los rangos de direccin esttica se muestran en el diagrama de estado de arriba, las necesidades de los sistemas del
mundo real pueden causar que estos varen un poco en los nmeros definidos. En algunos casos, los dispositivos esclavos no
pueden transferir el nmero mximo de bytes definido por el protocolo. Es decir, en lugar de permitir que un maestro solicite
entradas 0x07D0, nicamente puede responder con 0x0400. De forma similar, un modelo de datos esclavo puede definir el rango
de valores aceptables de bobina como las direcciones de 0 a 500. Si un maestro hace una solicitud para 125 iniciando en la
direccin 0, esto est bien, pero si un maestro hace la misma solicitud iniciando en la direccin 400, la bobina final estar en la
direccin 525, la cual est fuera del rango para este dispositivo y resultara en la excepcin 02 como lo define el diagrama de
estado.
Cdigos de Funcin Estndares

La definicin de cada cdigo de funcin estndar est en la especificacin. Incluso para los cdigos de funcin ms comunes,
existen discrepancias inevitables entre las funciones habilitadas en el maestro y lo que el esclavo puede manejar. Para solucionar
esto, las versiones anteriores de la especificacin Modbus TCP definen tres clases de conformidad. La Especificacin de Pruebas
de Compatibilidad Modbus oficial no hace referencia a estas clases y en su lugar define la compatibilidad en cada funcin; sin
embargo, puede ser conveniente para comprenderlo. Se recomienda que cualquier documento siga la especificacin de pruebas
y determine su compatibilidad con los cdigos que soportan, en lugar de con las clasificaciones de legado.
Cdigos Clase 0
Los cdigos Clase 0 generalmente son considerados el mnimo para un dispositivo Modbus til, ya que dan a un maestro la
habilidad de leer o escribir en el modelo de datos.
Cdigo

Descripcin

Leer Mltiples Registros

16

Escribir a Mltiples Registros

Tabla 4. Compatibilidad con Cdigos Clase 0

Cdigos Clase 1
Los cdigos de funcin Clase 1 consisten en los otros cdigos necesarios para tener acceso a todos los tipos del modelo de
datos. En la definicin original, esta lista incluye el cdigo de funcin 7 (leer excepcin). Sin embargo, este cdigo es definido por
la especificacin actual como un cdigo para serial nicamente.
Cdigo

Descripcin

Leer Bobinas

Leer Entradas Discretas

Leer Registros de Entrada

Escribir a Bobina Individual

Escribir a Registro Individual

Leer Estado de Excepcin (nicamente serial)

Tabla 5. Compatibilidad con Cdigos Clase 1

Cdigos Clase 2
Los cdigos de funcin Clase 2 son funciones ms especializadas que son implementadas con menos frecuencia. Por ejemplo,
Leer/Escribir Mltiples Registros puede ayudar a reducir el nmero total de ciclos de solicitud-respuesta, pero el comportamiento
an puede ser implementado con cdigos Clase 0.
Descripcin

de Cdigo

15

Escribir a Mltiples Bobinas

20

Leer Registro de Archivo

21

Escribir a Registro de Archivo

5/9

www.ni.com

22

Escribir a Registro con Mscara

23

Leer/Escribir Mltiples Registros

24

Leer FIFO
Tabla 6. Compatibilidad con Cdigos Clase 2

Interfaz Modbus Encapsulada

El cdigo de Interfaz Modbus Encapsulada (MEI), funcin 43, es usado para encapsular otros datos en un paquete Modbus. En la
actualidad, dos nmeros MEI estn disponibles, 13 (CANopen) y 14 (identificacin de dispositivos).
La Funcin 43/14 (identificacin de dispositivos) es til, ya que permite la transferencia de hasta 256 objetos nicos. Algunos de
estos objetos son predefinidos y reservados, como el nombre del proveedor y el cdigo de producto, pero las aplicaciones
pueden definir otros objetos a transferir como conjuntos de datos genricos.
Este cdigo no es implementado comnmente.
Excepciones

Los esclavos utilizan excepciones para indicar un nmero de condiciones de error, desde una solicitud malformada hasta
entradas incorrectas. Sin embargo, las excepciones tambin se pueden generar como una respuesta a nivel de la aplicacin para
una solicitud vlida. Los esclavos no responden a las solicitudes emitidas con una excepcin. En cambio, el esclavo ignora
solicitudes incompletas o alteradas y comienza a esperar un nuevo mensaje entrante.
Las excepciones son reportadas en un formato de paquete definido. Primero, un cdigo de funcin se regresa al maestro que
solicita igual al cdigo de funcin original, excepto con su conjunto de bits ms significativo. Esto es equivalente a aadir 0x80 al
valor del cdigo de funcin original. En lugar de los datos normales asociados con una respuesta de funcin determinada, las
respuestas de excepcin incluyen un solo cdigo de excepcin.
Dentro del estndar, los cuatro cdigos de excepcin ms comunes son 01, 02, 03 y 04. Estos se muestran en la Tabla 7 con
significados estndares para cada funcin.
Cdigo de
Excepcin

Significado

01

El cdigo de funcin recibido no est soportado. Para confirmar el cdigo de funcin original, restar 0x80 del
valor devuelto.

02

La solicitud intent tener acceso a una direccin no vlida. En el estndar, esto puede ocurrir nicamente si la
direccin de inicio y el nmero solicitado de valores excede 2 16. Sin embargo, algunos dispositivos pueden
limitar este espacio de direccin en su modelo de datos.

03

La solicitud tena datos incorrectos. En algunos casos, esto significa que haba una discrepancia de
parmetros, por ejemplo entre el nmero de registros enviados y el campo "cantidad de bytes". Normalmente,
el maestro solicit ms datos de lo que permite ya sea el esclavo o el protocolo. Por ejemplo, un maestro
puede leer solamente 125 registros de detencin a la vez y los dispositivos con recursos limitados pueden
delimitar este valor a incluso menos registros.

04

Se ha producido un error irrecuperable al intentar procesar la solicitud. Este es un cdigo de excepcin

general que indica que la solicitud era vlida, pero el esclavo no poda ejecutarla.
Tabla 7. Cdigos de Excepcin de Modbus Comunes

El diagrama de estado para cada cdigo de funcin debe cubrir al menos el cdigo de excepcin 01 y por lo general incluye los
cdigos de excepcin 04, 02, 03, cualquier otro cdigo de excepcin definido es opcional.
3. Unidad de Datos de Aplicacin

Adems de la funcionalidad definida en la PDU principal del protocolo Modbus, usted puede usar varios protocolos de red. Los
protocolos ms comunes son serial y TCP/IP, pero usted puede usar otros como UDP tambin. Para transmitir los datos
necesarios para Modbus a travs de estas capas, Modbus incluye un conjunto de variantes ADU que son diseadas para cada
protocolo de red.
Caractersticas Comunes
Modbus requiere ciertas caractersticas para proporcionar una comunicacin confiable. El No. de Unidad o de Direccin es usado
en cada formato de ADU para proporcionar informacin de enrutado a la capa de la aplicacin. Cada ADU se vende con una PDU
completa, la cual incluye el cdigo de funcin y los datos asociados para una solicitud determinada. Para mayor fiabilidad, cada
mensaje incluye la informacin de comprobacin de errores. Finalmente, todas las ADUs proporcionan un mecanismo para
6/9

www.ni.com

mensaje incluye la informacin de comprobacin de errores. Finalmente, todas las ADUs proporcionan un mecanismo para
determinar el comienzo y el final de un marco de solicitud, pero los implementa de manera diferente.
Formatos Estndares
Los tres formatos ADU estndares son TCP, unidad terminal remota (RTU), y ASCII. RTU y ASCII ADUs normalmente son
usados a travs de una lnea serial, mientras que el TCP es usado a travs de redes TCP/IP o UDP/IP modernas.
TCP/IP
Las ADUs de TCP consisten en el Encabezado de Protocolo de Aplicacin Modbus (MBAP) combinado con la PDU de Modbus.
El MBAP es un encabezado de uso general que depende de una capa de red confiable. El formato de esta ADU, incluyendo el
encabezado, se muestra en la Figura 6.

Figura 6. La ADU de TCP/IP

Los campos de datos del encabezado indican su uso. Primero, incluye un identificador de transaccin. Esto es valioso en una red
en la que se pueden soportar mltiples solicitudes simultneamente. Es decir, un maestro puede enviar solicitudes 1, 2, y 3. En
algn punto, un esclavo puede responder en el orden 2, 1, 3, y el maestro puede igualar las solicitudes con las respuestas y
analizar los datos con precisin. Esto es til para redes Ethernet.
El identificador de protocolo es normalmente cero, pero usted puede utilizarlo para ampliar el comportamiento del protocolo. El
campo de longitud es usado por el protocolo para delinear la longitud del resto del paquete. La ubicacin de este elemento
tambin indica la dependencia de este formato encabezado en una capa de red confiable. Debido a que los paquetes TCP tienen
verificacin de errores integrada y garantizan la coherencia de los datos y la entrega, la longitud del paquete puede ser ubicado
en cualquier parte del encabezado. En una red inherentemente menos confiable como una red serial, un paquete podra
perderse, teniendo el efecto de que incluso si la escritura de datos leda por la aplicacin inclua informacin vlida de transaccin
y del protocolo, la informacin de longitud alterada volvera invlido al encabezado. TCP proporciona una cantidad razonable de
proteccin contra esta situacin.
El ID de Unidad generalmente no es usado por los dispositivos TCP/IP. Sin embargo, Modbus es un protocolo comn en el que
se implementan muchos gateways, lo cual convierte al protocolo Modbus en otro protocolo. En el caso original de uso, un
gateway Modbus TCP/IP a serial podra ser usado para permitir la conexin entre las nuevas redes TCP/IP y redes seriales
anteriores. En dicho entorno, el ID de Unidad es usado para determinar la direccin del dispositivo esclavo para la que la PDU
est destinada.
Finalmente, la ADU incluye una PDU. La longitud de esta PDU est an limitada a 253 bytes para el protocolo estndar.
RTU
La ADU de RTU parece ser mucho ms simple, como se muestra en la Figura 7.

Figura 7. La ADU de RTU

A diferencia de la ADU de TCP/IP ms compleja, esta ADU incluye solamente dos piezas de informacin, adems de la PDU
principal. Primero, una direccin es usada para definir para qu esclavo est diseada una PDU. En la mayora de las redes, una
direccin 0 define la direccin de "broadcast". Es decir, un maestro puede enviar un comando de salida a la direccin 0 y todos
los esclavos deben procesar la solicitud pero ningn esclavo debe responder. Adems de esta direccin, un CRC es usado para
asegurar la integridad de los datos.
Sin embargo, la realidad es que la situacin en las implementaciones ms modernas est lejos de ser simple. Encapsulando el
paquete hay un par de tiempos en silencio, es decir, periodos en los que no hay comunicacin en el bus. Para una velocidad de
transferencia de 9,600, este tiempo es alrededor de 4 ms. El estndar define una longitud mnima de silencio,
independientemente de la velocidad de transferencia, de un poco menos de 2 ms.
Primero, esto tiene un inconveniente de rendimiento ya que el dispositivo debe esperar a que el tiempo muerto se cumpla antes
de que el paquete pueda ser procesado. Ms peligrosa an, sin embargo, es la introduccin de diferentes tecnologas usadas
para transferencia serial y velocidades de transferencia mucho ms rpidas que cuando se introdujo el estndar. Con un cable
convertidor de USB a serial, por ejemplo, usted no tiene ningn control sobre el paquete y la transferencia de datos. Las pruebas
muestran que usar un cable de USB a serial con el controlador NI-VISA introduce grandes intervalos de tamao variable en el
flujo de datos y estos intervalos, perodos de silencio, engaan al cdigo compatible con la especificacin al creer que un
mensaje se ha completado. Debido a que el mensaje no es completado, esto por lo general conduce a un CRC no vlido y al
dispositivo que interpreta la ADU como alterada.
Adems de los problemas con la transmisin, las tecnologas modernas de controlador abstraen comunicacin serial significativa
y generalmente requieren un mecanismo de consulta desde el cdigo de la aplicacin. Por ejemplo, ni el .NET Framework 4.5
SerialPort Class ni el controlador NI-VISA proporcionan un mecanismo para detectar silencio sobre una lnea serial excepto al
7/9

www.ni.com

SerialPort Class ni el controlador NI-VISA proporcionan un mecanismo para detectar silencio sobre una lnea serial excepto al
consultar los bytes en el puerto. Esto resulta en una escala de bajo rendimiento (si la consulta es realizada demasiada lento) o
alto uso del CPU (si la consulta es realizada demasiado rpido).
Un mtodo comn para resolver estos problemas es romper la capa de abstraccin entre la PDU de Modbus y la capa de red. Es
decir, el cdigo serial interroga el paquete de la PDU de Modbus para determinar el cdigo de funcin. Combinado con otros
datos en el paquete, la longitud del paquete restante puede ser descubierta y usada para determinar el final del paquete. Con
esta informacin, puede usarse un descanso mucho ms largo, lo que permite silencios de transmisin y puede ocurrir consulta a
nivel de la aplicacin mucho ms lentamente. Se recomienda utilizar este mecanismo para un nuevo desarrollo. El cdigo que no
emplea esto puede experimentar un nmero mayor de paquetes "alterados" de lo esperado.
ASCII
La ADU de ASCII es ms compleja que la de RTU como se muestra en la Figura 8, tambin evita muchos de los problemas del
paquete RTU. Sin embargo, tiene algunas de sus propias desventajas.

Figura 8. La ADU de ASCII

Al resolver el problema de determinar el tamao del paquete, la ADU de ASCII tiene un inicio y final bien definido y nico para
cada paquete. Es decir, cada paquete comienza con ":" y termina con un regreso de carro (CR) y alimentacin de lnea (LF).
Adems, los APIs seriales como NI-VISA y el .NET Framework SerialPort Class pueden leer datos fcilmente en un bfer hasta
que un carcter especfico, como CR/LF, es recibido. Estas caractersticas hacen que sea fcil procesar la escritura de datos en
la lnea serial de manera eficiente en el cdigo de la aplicacin moderno.
La desventaja del ADU de ASCII es que todos los datos son transferidos como caracteres hexadecimales codificados en ASCII.
Es decir, en lugar de enviar un solo byte para el cdigo de funcin 3, 0x03, enva los caracteres ASCII "0" y "3" o 0x30 / 0x33.
Esto hace que el protocolo sea ms legible, pero tambin significa que el doble de datos deben ser transferidos a travs de la red
en serie y que las aplicaciones que envan y reciben deben ser capaces de analizar los valores ASCII.

Extender Modbus
Modbus, un estndar relativamente simple y abierto, puede ser modificado para cumplir con las necesidades de una aplicacin
determinada. Esto es ms comn para la comunicacin entre la HMI y PLC o PAC, ya que esta es una situacin en la que una
sola organizacin tiene el control sobre ambos extremos del protocolo. Los desarrolladores de sensores, por ejemplo, es ms
probable que se apeguen al estndar escrito, ya que normalmente solo controlan la implementacin de su esclavo y es deseable
la interoperabilidad.
En general, no se recomienda modificar el protocolo. Esta seccin se proporciona simplemente como un reconocimiento de los
mecanismos que otros han utilizado para ajustar el comportamiento del protocolo.
4. Nuevos Cdigos de Funcin

Algunos cdigos de funcin son definidos, pero el estndar Modbus le permite desarrollar cdigos de funcin adicionales. En
concreto, los cdigos de funcin 1 al 64, 73 al 99 y 111 al 127 son los cdigos pblicos que son reservados y garantizados para
ser nicos. Los cdigos restantes, 65 al 72 y 100 al 110, son para uso definido por el usuario. Con estos cdigos definidos por el
usuario, usted puede usar cualquier estructura de datos. Los datos pueden incluso exceder el lmite de 253 bytes estndar para el
Modbus PDU, pero toda la aplicacin debe ser validada para asegurarse de que otras capas funcionan como se esperaba
cuando el PDU exceder el lmite estndar. Los cdigos de funcin por encima de 127 son reservados para respuestas de
excepcin.
5. Capas de Red

Modbus se puede ejecutar en muchas capas de la red, adems de serial y TCP. Una implementacin potencial es UDP, ya que
es ideal para el estilo de comunicacin Modbus. Modbus es un protocolo basado en mensajes en su ncleo, por lo que la
habilidad de UDP para enviar un paquete bien definido de la informacin sin ninguna de informacin adicional a nivel de
aplicacin, como un carcter de inicio o longitud, hace a Modbus extremadamente fcil de implementar. En lugar de requerir una
ADU adicional o reutilizar una ADU existente, los paquetes de la PDU de Modbus se pueden enviar usando un API de UDP
estndar y ser recibidos completamente formados en el otro extremo. Aunque TCP es ventajoso para algunos protocolos por el
sistema de confirmacin integrado, Modbus realiza confirmacin en la capa de aplicacin. Sin embargo, utilizando UDP de esta
manera elimina el campo de identificador de transaccin en l ADU de TCP, que libera la posibilidad de mltiples transacciones
pendientes simultneas. Por lo tanto, el maestro debe ser un maestro sincrnico o el paquete UDP debe tener un identificador
para ayudar al maestro a organizar las solicitudes y respuestas. Una implementacin sugerida sera usar la ADU de TCP/IP en
una capa de red UDP.
6. Modificaciones de ADU

Por ltimo, una aplicacin podra optar por modificar una ADU o usar porciones no utilizadas de una ADU existente como TCP.
Por ejemplo, TCP define un campo de 16 bits de longitud, un protocolo de 16 bits y un No. de Unidad de 8 bits. Dado que la PDU
de Modbus mayor es de 253 bytes, el byte alto del campo de longitud es siempre cero. Para Modbus/TCP, el campo de protocolo
8/9

www.ni.com

de Modbus mayor es de 253 bytes, el byte alto del campo de longitud es siempre cero. Para Modbus/TCP, el campo de protocolo
y el ID de Unidad son siempre cero. Una simple extensin del protocolo podra enviar tres paquetes simultneamente al cambiar
el campo del protocolo a un nmero que no sea cero y al usar los dos bytes no utilizados (No. de Unidad y el byte alto del campo
de longitud) para enviar las longitudes de dos PDUs adicionales (ver la Figura 9).

Figura 9. Modificacin de Ejemplo de la ADU de TCP

Recursos Adicionales
Especificacin del Protocolo de Aplicacin Modbus
Por qu es importante OPC UA?
Sobre OPC
EtherNet/IPCIP en Tecnologa Ethernet
Soporte Digital
Biblioteca Modbus Java

9/9

www.ni.com