Información Detallada sobre el Protocolo Modbus

Fecha de Publicación: oct 16, 2014 | 7 Calificaciones | 3.14 fuera de 5 | 

Read in English
  | Imprimir

Visión General
Modbus es un protocolo industrial que fue desarrollado en 1979 para hacer posible la comunicación entre
dispositivos de automatización. Originalmente implementado como un protocolo al nivel de la aplicación
con la finalidad de transferir datos por una capa serial, Modbus se ha expandido para incluir
implementaciones a través de protocolo serial, TCP/IP y el User Datagram Protocol (UDP). Este
documento ofrece una perspectiva detallada de la implementación del protocolo.

Contenido
1. ¿Qué es el Protocolo Modbus?
2. Unidad de Datos de Protocolo

3. Unidad de Datos de Aplicación

4. Nuevos Códigos de Función

5. Capas de Red
6. Modificaciones de ADU
1. ¿Qué es el Protocolo Modbus?
Modbus es un protocolo de solicitud-respuesta implementado usando una relación maestro-esclavo. En
una relación maestro-esclavo, la comunicación 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 interacción. Por lo general, el maestro es una interfaz humano-máquina (HMI) o sistema SCADA y el
esclavo es un sensor, controlador lógico programable (PLC) o controlador de automatización programable
(PAC). El contenido de estas solicitudes y respuestas, y las capas de la red a través de las cuales se
envían estos mensajes, son definidas por las diferentes capas del protocolo.

Figura 1. Una Relación de Red Maestro-Esclavo

Capas del Protocolo Modbus

En la implementación inicial, Modbus era un solo protocolo construido en base a serial, por lo que no
podía ser dividida en múltiples capas. Con el tiempo, diferentes unidades de datos de aplicación fueron
introducidas ya sea para cambiar el formato del paquete utilizado a través de serial o para permitir el uso
de redes TCP/IP y UDP (User Datagram Protocol). Esto llevó a una separación 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
aplicación (ADU).
Regresar al Inicio
2. Unidad de Datos de Protocolo
La PDU y el código que la maneja consiste en el núcleo de la Especificación del Protocolo de Aplicación
Modbus. Esta especificación define el formato de la PDU, los diversos conceptos de datos utilizados por
el protocolo, el uso de los códigos de función para tener acceso a esos datos y la implementación
específica y restricciones de cada código de función.
El formato de Modbus PDU está definido como un código de función seguido por un conjunto de datos
asociado. El tamaño y el contenido de estos datos son definidos por el código de función y la PDU
completa (código de función y datos) no puede exceder de 253 bytes de tamaño. Cada código de función
tiene un comportamiento específico que los esclavos pueden implementar de manera flexible en base al
comportamiento de la aplicación deseada. La especificación de la PDU define conceptos básicos para el
acceso y manipulación de datos; sin embargo, un esclavo puede manejar datos de una manera que no
esté definida explícitamente en la especificación.
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 dirección: bobinas, entradas discretas, registros de retención y registros de entrada.
Al igual que con gran parte de la especificación, los nombres pueden variar dependiendo de la industria o
de la aplicación. Por ejemplo, los registros de retención 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 través de diversos códigos de función. El
comportamiento de cada bloque se describe en la Tabla 1.
 

Bloque de Memoria Tipo de Datos Acceso de Maestro Acceso de Esclav

Bobinas Booleano Lectura/Escritura Lectura/Escritura

Entradas Discretas Booleano Solo Lectura Lectura/Escritura

Registros de Retención 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 también de proporcionar mecanismos simplificados en la capa de aplicación 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 también pueden traslaparse. Por ejemplo, la bobina uno puede existir en
la misma ubicación en memoria como el primer bit de la palabra representada por el registro de retención
uno. El esquema de dirección se define completamente por el dispositivo esclavo y su interpretación de
cada bloque de memoria es una parte importante del modelo de datos del dispositivo.
Dirección de Modelo de Datos
La especificación define que cada bloque contiene un espacio de dirección de un máximo de 65,536 (216)
elementos. Dentro de la definición de la PDU, Modbus define la dirección 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 máximo de 65,536. Es decir, la bobina 1 está en el bloque de bobina en la dirección 0, mientras que
el registro de retención 54 está en la dirección 53 de la sección de la memoria que el esclavo ha definido
como registros de retención.
No se requiere que los rangos completos permitidos por la especificación 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 retención 150 al 175 y 200
al 225. Esto es perfectamente aceptable y los intentos de acceso no válidos pueden manejarse a través
de excepciones.
Rangos de Dirección de Datos
Aunque la especificación define los diferentes tipos de datos que existen en diferentes bloques y asigna
un rango de dirección local para cada tipo, esto no se traduce necesariamente en un esquema intuitivo de
dirección para fines de documentación o para comprender la memoria disponible a través de Modbus de
un dispositivo determinado. Para simplificar la discusión de ubicaciones del bloque de memoria, se
introdujo un esquema de numeración, el cual añade prefijos a la dirección de los datos en cuestión.
Por ejemplo, en lugar de referir a un elemento como registro de retención 14 en la dirección 13, un
manual de dispositivo se referiría a un elemento de datos en la dirección 4,014, 40,014 o 400,014. En
cada caso, el primer número especificado es 4 para representar registros de retención y la dirección es
especificada usando los números restantes. La diferencia entre 4XXX, 4XXXX y 4XXXXX depende del
espacio de dirección usado por el dispositivo. Si todos los 65,536 registros están en uso, la anotación
 4XXXXX debe ser usada, ya que permite un rango de 400,001 a 465,536. Si solamente algunos registros
son usados, una práctica común es usar el rango de 4,001 al 4,999.
En este esquema de dirección, a cada tipo de datos se le asigna un prefijo como se muestra en la Tabla
2.
 

Bloque de Datos Prefijo

Bobinas 0

Entradas Discretas 1

Registros de Entrada 3

Registros de Retención 4
Tabla 2. Prefijos de Rangos de Datos
Existen bobinas con un prefijo 0. Esto significa que una referencia de 4001 podría referirse al registro de
retención uno o bobina de 4001. Por esta razón, se recomienda que todas las nuevas implementaciones
usen dirección de 6 dígitos con ceros a la izquierda y se especifique esto en la documentación. Por lo
tanto, el registro de retención uno es referenciado como 400,001 y la bobina de 4001 es referenciada
como 004,001.
Valores de Inicio de Dirección de Datos
La diferencia entre las direcciones de memoria y los números de referencia es aún más complicada por el
índice seleccionado por una aplicación determinada. Como se mencionó anteriormente, el registro de
retención uno está en la dirección cero. Típicamente, los números 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 retención 00001, el cual está en la dirección 0. Algunas
implementaciones eligen iniciar sus rangos en cero, lo que significa que 400,000 se traduce en el registro
de detención en la dirección cero. La Tabla 3 muestra este concepto.

Dirección Número de Registro Número (índice 1, Número (índice 0,

estándar) alternativo)

0 1 400001 400000

1 2 400002 400001

2 3 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 documentación.
Tipos de Datos Grandes
El estándar 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 relés y los valores de palabra
corresponden a los valores de ADC sin escalar, no es suficiente para los sistemas más avanzados. Como
resultado, muchas implementaciones Modbus incluyen tipos de datos que cruzan los límites de registros.
El Módulo NI LabVIEW Datalogging and Supervisory Control (DSC) y KEPServerEX definen un número
de tipos de referencia. Por ejemplo, las secuencias almacenadas en un registro de retención siguen la
forma estándar (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 retención donde el byte alto
corresponde al primer carácter de la secuencia). Esto es necesario debido a que cada solicitud tiene un
tamaño limitado, por lo que un maestro Modbus debe conocer los límites exactos de la secuencia en lugar
de buscar una longitud o delimitador como NULL.
Acceso a Bits
Además de permitir el acceso a los datos que cruza un límite de registro, algunos maestros Modbus
soportan referencias para bits individuales dentro de un registro. Esto es benéfico 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 número, dependiendo de la implementación. Es decir, el primer bit en el
primer registro puede ser 400,001.00 o 400,001.01. Se recomienda que toda documentación especifique
el esquema de índice utilizado.
Endianness de Datos
Los datos de múltiples registros, como el valor de punto flotante de precisión simple, pueden ser
transferidos fácilmente en Modbus al dividir los datos en dos registros. Ya que esto no está definido por el
estándar, el endianness (u orden de bytes) de esta división no está definida. Aunque cada palabra no
signada debe ser enviada en orden de byte de la red (big-endian) para cumplir con el estándar, varios
dispositivos invierten el orden de bytes para datos de múltiples bytes. La Figura 2 muestra un ejemplo
inusual pero válido sobre esto.

Figura 2. Intercambio de Orden de Bytes para Datos de Múltiples Palabras

Depende del maestro comprender cómo el esclavo está almacenando información en la memoria y
decodificarlo correctamente. Se recomienda que la documentación refleje el orden de las palabras
utilizadas por el sistema. El orden de bytes también puede ser añadido como una opción de configuración
del sistema, con funciones de codificación y decodificación fundamentales, si se requiere flexibilidad en la
implementación.
Strings
Los strings pueden ser fácilmente almacenados en registros de Modbus. Para simplificar, algunas
implementaciones requieren que las longitudes de los strings sean múltiplos de dos, con cualquier
espacio adicional llenado con valores nulos. El orden de los bytes también 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.

Figura 3. Reversión de Orden de Bytes en secuencias de Modbus

Comprender Códigos de Función
En contraste con el modelo de datos que puede variar considerablemente de un dispositivo a otro, los
códigos de función y sus datos son definidos explícitamente por el estándar. Cada función sigue un
patrón. Primero, el esclavo valida entradas como el código de función, dirección de datos y el rango de
datos. Después, ejecuta la acción solicitada y envía una respuesta adecuada al código. Si cualquier paso
en este proceso falla, se regresa una excepción al solicitante. El transporte de datos para estas
solicitudes es la PDU.
La PDU de Modbus
La PDU consta de un código de función de un byte seguido de hasta 252 bytes de datos de funciones
específicas.

Figura 4. La PDU de Modbus

El código de función es el primer elemento que será validado. Si el código de función no es reconocido
por el dispositivo que recibe la solicitud, responde con una excepción. Si se acepta el código de función,
el dispositivo esclavo comienza a descomponer los datos de acuerdo con la definición de la función.
 
Debido a que el tamaño del paquete está limitado a 253 bytes, los dispositivos están limitados a la
cantidad de datos que pueden ser transferidos. Los códigos de función más comunes pueden transferir
entre 240 y 250 bytes de datos del modelo de datos de esclavos, dependiendo del código.
Ejecución de Funciones del Esclavo
Según lo define el modelo de datos, diferentes funciones son definidas para tener acceso a diferentes
bloques conceptuales de datos. Una implementación común es que los códigos tengan acceso a las
ubicaciones estáticas de la memoria, pero otros comportamientos están disponibles. Por ejemplo, el
código de función 1 (leer bobinas) y el 3 (leer registros de retención) pueden tener acceso a la misma
ubicación física en la memoria. Por el contrario, el código de función 3 (leer registros de retención) y el 16
(escribir a registros de retención) tienen acceso a ubicaciones completamente diferentes en la memoria.
Por lo tanto, la ejecución de cada código de función mejor es considerada como parte de la definición 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 código
1, que lee bobinas.
 Figura 5. Leer Diagrama de Estado de Bobinas desde la Especificación del Protocolo Modbus
Cada esclavo debe validar el código de función, el número de entradas, la dirección de inicio, el rango
total y la ejecución de la función definida por el esclavo que realiza la lectura.
Aunque los rangos de dirección estática se muestran en el diagrama de estado de arriba, las necesidades
de los sistemas del mundo real pueden causar que estos varíen un poco en los números definidos. En
algunos casos, los dispositivos esclavos no pueden transferir el número máximo 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 dirección 0, esto está bien, pero si un maestro hace la misma solicitud iniciando en la
dirección 400, la bobina final estará en la dirección 525, la cual está fuera del rango para este dispositivo y
resultaría en la excepción 02 como lo define el diagrama de estado.
Códigos de Función Estándares
La definición de cada código de función estándar está en la especificación. Incluso para los códigos de
función más 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 especificación Modbus
TCP definen tres clases de conformidad. La Especificación de Pruebas de Compatibilidad Modbus oficial
no hace referencia a estas clases y en su lugar define la compatibilidad en cada función; sin embargo,
puede ser conveniente para comprenderlo. Se recomienda que cualquier documento siga la
especificación de pruebas y determine su compatibilidad con los códigos que soportan, en lugar de con
las clasificaciones de legado.
Códigos Clase 0
Los códigos Clase 0 generalmente son considerados el mínimo para un dispositivo Modbus útil, ya que
dan a un maestro la habilidad de leer o escribir en el modelo de datos.

Código Descripción

3 Leer Múltiples Registros

16 Escribir a Múltiples Registros

Tabla 4. Compatibilidad con Códigos Clase 0
Códigos Clase 1
Los códigos de función Clase 1 consisten en los otros códigos necesarios para tener acceso a todos los
tipos del modelo de datos. En la definición original, esta lista incluye el código de función 7 (leer
excepción). Sin embargo, este código es definido por la especificación actual como un código para serial
únicamente.

Código Descripción

1 Leer Bobinas

2 Leer Entradas Discretas

4 Leer Registros de Entrada

5 Escribir a Bobina Individual

6 Escribir a Registro Individual

7 Leer Estado de Excepción (únicamente serial)

Tabla 5. Compatibilidad con Códigos Clase 1
Códigos Clase 2
Los códigos de función Clase 2 son funciones más especializadas que son implementadas con menos
frecuencia. Por ejemplo, Leer/Escribir Múltiples Registros puede ayudar a reducir el número total de
ciclos de solicitud-respuesta, pero el comportamiento aún puede ser implementado con códigos Clase 0.
   Descripción de Código

15 Escribir a Múltiples Bobinas

20 Leer Registro de Archivo

21 Escribir a Registro de Archivo

22 Escribir a Registro con Máscara

23 Leer/Escribir Múltiples Registros

24 Leer FIFO
Tabla 6. Compatibilidad con Códigos Clase 2
 
Interfaz Modbus Encapsulada
El código de Interfaz Modbus Encapsulada (MEI), función 43, es usado para encapsular otros datos en un
paquete Modbus. En la actualidad, dos números MEI están disponibles, 13 (CANopen) y 14 (identificación
de dispositivos).
La Función 43/14 (identificación 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 código de producto, pero las aplicaciones pueden definir otros objetos a transferir como conjuntos de
datos genéricos.
Este código no es implementado comúnmente.
Excepciones
Los esclavos utilizan excepciones para indicar un número de condiciones de error, desde una solicitud
malformada hasta entradas incorrectas. Sin embargo, las excepciones también se pueden generar como
una respuesta a nivel de la aplicación para una solicitud válida. Los esclavos no responden a las
solicitudes emitidas con una excepción. 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 código de función se
regresa al maestro que solicita igual al código de función original, excepto con su conjunto de bits más
significativo. Esto es equivalente a añadir 0x80 al valor del código de función original. En lugar de los
datos normales asociados con una respuesta de función determinada, las respuestas de excepción
incluyen un solo código de excepción.
Dentro del estándar, los cuatro códigos de excepción más comunes son 01, 02, 03 y 04. Estos se
muestran en la Tabla 7 con significados estándares para cada función.

Código de Significado
Excepción

01 El código de función recibido no está soportado. Para confirmar el código de función

original, restar 0x80 del valor devuelto.

02 La solicitud intentó tener acceso a una dirección no válida. En el estándar, esto puede
ocurrir únicamente si la dirección de inicio y el número solicitado de valores excede
embargo, algunos dispositivos pueden limitar este espacio de dirección en su modelo
datos.

03 La solicitud tenía datos incorrectos. En algunos casos, esto significa que había una
discrepancia de parámetros, por ejemplo entre el número de registros enviados y el ca
"cantidad de bytes". Normalmente, el maestro solicitó más datos de lo que permite ya
 el esclavo o el protocolo. Por ejemplo, un maestro puede leer solamente 125 registros
detención a la vez y los dispositivos con recursos limitados pueden delimitar este valo
incluso menos registros.

04 Se ha producido un error irrecuperable al intentar procesar la solicitud. Este es un cód

de excepción general que indica que la solicitud era válida, pero el esclavo no podía
ejecutarla.
Tabla 7. Códigos de Excepción de Modbus Comunes
 
El diagrama de estado para cada código de función debe cubrir al menos el código de excepción 01 y por
lo general incluye los códigos de excepción 04, 02, 03, cualquier otro código de excepción definido es
opcional.
Regresar al Inicio
3. Unidad de Datos de Aplicación
Además de la funcionalidad definida en la PDU principal del protocolo Modbus, usted puede usar varios
protocolos de red. Los protocolos más comunes son serial y TCP/IP, pero usted puede usar otros como
UDP también. Para transmitir los datos necesarios para Modbus a través de estas capas, Modbus incluye
un conjunto de variantes ADU que son diseñadas para cada protocolo de red.
Características Comunes
Modbus requiere ciertas características para proporcionar una comunicación confiable. El No. de Unidad o
de Dirección es usado en cada formato de ADU para proporcionar información de enrutado a la capa de la
aplicación. Cada ADU se vende con una PDU completa, la cual incluye el código de función y los datos
asociados para una solicitud determinada. Para mayor fiabilidad, cada mensaje incluye la información de
comprobación 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 Estándares
Los tres formatos ADU estándares son TCP, unidad terminal remota (RTU), y ASCII. RTU y ASCII ADUs
normalmente son usados a través de una línea serial, mientras que el TCP es usado a través de redes
TCP/IP o UDP/IP modernas.
TCP/IP
Las ADUs de TCP consisten en el Encabezado de Protocolo de Aplicación 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 transacción.
Esto es valioso en una red en la que se pueden soportar múltiples solicitudes simultáneamente. Es decir,
un maestro puede enviar solicitudes 1, 2, y 3. En algún 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 precisión. 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 ubicación de este elemento también indica la dependencia de este formato
encabezado en una capa de red confiable. Debido a que los paquetes TCP tienen verificación 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 podría perderse, teniendo el efecto de que incluso si la escritura de datos leída por la aplicación
incluía información válida de transacción y del protocolo, la información de longitud alterada volvería
inválido al encabezado. TCP proporciona una cantidad razonable de protección contra esta situación.
El ID de Unidad generalmente no es usado por los dispositivos TCP/IP. Sin embargo, Modbus es un
protocolo común 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 podría ser usado para
permitir la conexión entre las nuevas redes TCP/IP y redes seriales anteriores. En dicho entorno, el ID de
Unidad es usado para determinar la dirección del dispositivo esclavo para la que la PDU está destinada.
Finalmente, la ADU incluye una PDU. La longitud de esta PDU está aún limitada a 253 bytes para el
protocolo estándar.
RTU
La ADU de RTU parece ser mucho más simple, como se muestra en la Figura 7.

Figura 7. La ADU de RTU

A diferencia de la ADU de TCP/IP más compleja, esta ADU incluye solamente dos piezas de información,
además de la PDU principal. Primero, una dirección es usada para definir para qué esclavo está diseñada
una PDU. En la mayoría de las redes, una dirección 0 define la dirección de "broadcast". Es decir, un
maestro puede enviar un comando de salida a la dirección 0 y todos los esclavos deben procesar la
solicitud pero ningún esclavo debe responder. Además de esta dirección, un CRC es usado para asegurar
la integridad de los datos.
Sin embargo, la realidad es que la situación en las implementaciones más modernas está lejos de ser
simple. Encapsulando el paquete hay un par de tiempos en silencio, es decir, periodos en los que no hay
comunicación en el bus. Para una velocidad de transferencia de 9,600, este tiempo es alrededor de 4 ms.
El estándar define una longitud mínima 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. Más peligrosa aún, sin embargo, es la
introducción de diferentes tecnologías usadas para transferencia serial y velocidades de transferencia
mucho más rápidas que cuando se introdujo el estándar. Con un cable convertidor de USB a serial, por
ejemplo, usted no tiene ningún 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 tamaño
variable en el flujo de datos y estos intervalos, períodos de silencio, engañan al código compatible con la
especificación 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 válido y al dispositivo que interpreta la ADU como alterada.
Además de los problemas con la transmisión, las tecnologías modernas de controlador abstraen
comunicación serial significativa y generalmente requieren un mecanismo de consulta desde el código de
la aplicación. Por ejemplo, ni el .NET Framework 4.5 SerialPort Class ni el controlador NI-VISA
proporcionan un mecanismo para detectar silencio sobre una línea 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 rápido).
Un método común para resolver estos problemas es romper la capa de abstracción entre la PDU de
Modbus y la capa de red. Es decir, el código serial interroga el paquete de la PDU de Modbus para
determinar el código de función. 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 información, puede
usarse un descanso mucho más largo, lo que permite silencios de transmisión y puede ocurrir consulta a
nivel de la aplicación mucho más lentamente. Se recomienda utilizar este mecanismo para un nuevo
desarrollo. El código que no emplea esto puede experimentar un número mayor de paquetes "alterados"
de lo esperado.
ASCII
La ADU de ASCII es más compleja que la de RTU como se muestra en la Figura 8, también evita muchos
de los problemas del paquete RTU. Sin embargo, tiene algunas de sus propias desventajas.

[+] Ampliar Imagen

Figura 8. La ADU de ASCII
Al resolver el problema de determinar el tamaño 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 alimentación de línea (LF). Además, los APIs seriales como NI-VISA y el .NET Framework
SerialPort Class pueden leer datos fácilmente en un búfer hasta que un carácter específico, como CR/LF,
es recibido. Estas características hacen que sea fácil procesar la escritura de datos en la línea serial de
manera eficiente en el código de la aplicación 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 código de función 3, 0x03, envía
los caracteres ASCII "0" y "3" o 0x30 / 0x33. Esto hace que el protocolo sea más legible, pero también
significa que el doble de datos deben ser transferidos a través de la red en serie y que las aplicaciones
que envían y reciben deben ser capaces de analizar los valores ASCII.

Extender Modbus
Modbus, un estándar relativamente simple y abierto, puede ser modificado para cumplir con las
necesidades de una aplicación determinada. Esto es más común para la comunicación entre la HMI y
PLC o PAC, ya que esta es una situación en la que una sola organización tiene el control sobre ambos
extremos del protocolo. Los desarrolladores de sensores, por ejemplo, es más probable que se apeguen
al estándar escrito, ya que normalmente solo controlan la implementación de su esclavo y es deseable la
interoperabilidad.
En general, no se recomienda modificar el protocolo. Esta sección se proporciona simplemente como un
reconocimiento de los mecanismos que otros han utilizado para ajustar el comportamiento del protocolo.
Regresar al Inicio
4. Nuevos Códigos de Función
Algunos códigos de función son definidos, pero el estándar Modbus le permite desarrollar códigos de
función adicionales. En concreto, los códigos de función 1 al 64, 73 al 99 y 111 al 127 son los códigos
públicos que son reservados y garantizados para ser únicos. Los códigos restantes, 65 al 72 y 100 al 110,
son para uso definido por el usuario. Con estos códigos definidos por el usuario, usted puede usar
cualquier estructura de datos. Los datos pueden incluso exceder el límite de 253 bytes estándar para el
Modbus PDU, pero toda la aplicación debe ser validada para asegurarse de que otras capas funcionan
como se esperaba cuando el PDU exceder el límite estándar. Los códigos de función por encima de 127
son reservados para respuestas de excepción.
Regresar al Inicio
5. Capas de Red
Modbus se puede ejecutar en muchas capas de la red, además de serial y TCP.
Una implementación potencial es UDP, ya que es ideal para el estilo de comunicación Modbus. Modbus
es un protocolo basado en mensajes en su núcleo, por lo que la habilidad de UDP para enviar un paquete
bien definido de la información sin ninguna de información adicional a nivel de aplicación, como un
carácter de inicio o longitud, hace a Modbus extremadamente fácil 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 estándar y ser recibidos completamente formados en el otro extremo. Aunque
TCP es ventajoso para algunos protocolos por el sistema de confirmación integrado, Modbus realiza
confirmación en la capa de aplicación. Sin embargo, utilizando UDP de esta manera elimina el campo de
identificador de transacción en l ADU de TCP, que libera la posibilidad de múltiples transacciones
pendientes simultáneas. Por lo tanto, el maestro debe ser un maestro sincrónico o el paquete UDP debe
tener un identificador para ayudar al maestro a organizar las solicitudes y respuestas. Una
implementación sugerida sería usar la ADU de TCP/IP en una capa de red UDP.
Regresar al Inicio
6. Modificaciones de ADU
Por último, una aplicación podría 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 y el ID de Unidad son siempre
cero. Una simple extensión del protocolo podría enviar tres paquetes simultáneamente al cambiar el
campo del protocolo a un número 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).
 [+] Ampliar Imagen
Figura 9. Modificación de Ejemplo de la ADU de TCP

Recursos Adicionales
Especificación del Protocolo de Aplicación Modbus
¿Por qué es importante OPC UA?
Sobre OPC
EtherNet/IP—CIP en Tecnología Ethernet
Soporte Digital
Biblioteca Modbus Java