Protocolos de comunicación: MODBUS TCP/IP

MODBUS TCP/IP es una variante de la familia MODBUS de protocolos de comunicación simples y neutrales para la supervisión y el control de equipos de automatización. Específicamente, cubre el uso de la mensajería MODBUS en un entorno ‘Intranet’ o ‘Internet’ utilizando los protocolos TCP/IP. El uso más común de los protocolos en este momento es para la conexión Ethernet de PLC’s, módulos de E/S y “puertas de enlace” a otros buses de campo o redes de E/S simples.

El protocolo MODBUS TCP/IP se está publicando como un estándar de automatización (‘de facto’). Dado que MODBUS ya es ampliamente conocido, debe haber poca información en este documento que no pueda obtenerse en otro lugar. Sin embargo, se ha intentado aclarar qué funciones dentro de MODBUS tienen valor para la interoperabilidad de los equipos de automatización generales y qué partes son “equipaje” del uso alternativo de MODBUS como protocolo de programación para PLC.

Esto se hace a continuación agrupando los tipos de mensajes admitidos en “clases de conformidad” que diferencian entre los mensajes que se implementan universalmente y los opcionales, en particular los específicos de dispositivos como los PLC.

Orientado a la conexión

En MODBUS, las transacciones de datos son tradicionalmente sin estado, lo que las hace altamente resistentes a las interrupciones del ruido y, sin embargo, requieren que se mantenga una mínima información de recuperación en cada extremo.

Las operaciones de programación, por otro lado, esperan un enfoque orientado a la conexión. Esto se logró en las variantes más simples mediante un token exclusivo de “inicio de sesión”, y en la variante MODBUS Plus por las capacidades explícitas de “Ruta del programa” que mantuvieron una asociación dúplex hasta que se desglosaron explícitamente.

MODBUS TCP/IP maneja ambas situaciones. Una conexión es fácilmente reconocible a nivel de protocolo, y una sola conexión puede llevar múltiples transacciones independientes. Además, TCP/IP permite un gran número de conexiones simultáneas, por lo que en la mayoría de los casos es la elección del iniciador si se vuelve a conectar según sea necesario o se reutiliza una conexión de larga duración.

Los desarrolladores familiarizados con MODBUS pueden preguntarse por qué se usa el protocolo TCP/IP orientado a la conexión en lugar del UDP orientado a datagramas. La razón principal es mantener el control de una ‘transacción’ individual encerrándola en una conexión que pueda ser identificada, supervisada y cancelada sin requerir una acción específica por parte de las aplicaciones del cliente y del servidor. Esto le da al mecanismo una amplia tolerancia a los cambios en el rendimiento de la red, y permite que se agreguen fácilmente características de seguridad como cortafuegos y servidores proxy. Los desarrolladores originales de la World Wide Web utilizaron un razonamiento similar cuando optaron por implementar una consulta web mínima como una sola transacción utilizando TCP/IP en el conocido puerto 80´s.

Codificación de datos

MODBUS utiliza una representación ‘big-endian‘ para direcciones y elementos de datos. Esto significa que cuando se transmite una cantidad numérica mayor que un solo byte, el byte MÁS significativo se envía primero. Así por ejemplo:

Interpretación de números de referencia

MODBUS basa su modelo de datos en una serie de tablas que tienen características distintivas. Las cuatro tablas primarias son

La distinción entre entradas y salidas, y entre elementos de datos direccionables por bit y direccionables por palabra, no implica ningún comportamiento de la aplicación. Es perfectamente aceptable, y muy común, considerar que las cuatro tablas se superponen entre sí, si esta es la interpretación más natural en la máquina de destino en cuestión.

Para cada una de las tablas primarias, el protocolo permite la selección individual de 65536 elementos de datos, y las operaciones de lectura o escritura de esos elementos están diseñadas para abarcar varios elementos de datos consecutivos hasta un límite de tamaño de datos que depende del código de función de transacción.

No se supone que los elementos de datos representan una verdadera matriz contigua de datos, aunque esa es la interpretación utilizada por la mayoría de los PLC simples.

Los códigos de función de ‘lectura y escritura de referencia general’ están definidos para llevar un número de referencia de 32 bits, y podrían usarse para permitir el acceso directo a los elementos de datos dentro de un espacio MUY grande. Hoy en día no hay dispositivos PLC que aprovechen eso.

Una posible fuente de confusión es la relación entre los números de referencia utilizados en las funciones MODBUS y los ‘números de registro’ utilizados en los PLC Modicon. Por razones históricas, los números de referencia del usuario se expresaron como números decimales con un desplazamiento inicial de 1. Sin embargo, MODBUS utiliza la interpretación más natural del software de un índice entero sin signo que comienza en cero.

Por lo tanto, un mensaje MODBUS que solicite la lectura de un registro en el desplazamiento 0 devolverá el valor conocido por el programador de la aplicación tal como se encuentra en el registro 4: 00001 (tipo de memoria 4 = registro de salida, referencia 00001)

Filosofía de longitud implícita.

Todas las solicitudes y respuestas de MODBUS están diseñadas de tal manera que el destinatario pueda verificar que un mensaje esté completo. Para los códigos de función donde la solicitud y la respuesta son de longitud fija, el código de función solo es suficiente. Para los códigos de función que llevan una cantidad variable de datos en la solicitud o respuesta, la porción de datos estará precedida por un conteo de bytes.

Cuando MODBUS se transmite a través de TCP / IP, la información de longitud adicional se incluye en el prefijo para permitir que el destinatario reconozca los límites del mensaje, incluso si el mensaje tuvo que dividirse en varios paquetes para su transmisión. La existencia de reglas de longitud explícitas e implícitas, y el uso de un código de verificación de error CRC-32 (en Ethernet) da como resultado una posibilidad infinitesimal de corrupción no detectada en un mensaje de solicitud o respuesta.

2. Resumen de la clase de conformidad.

Al definir un nuevo protocolo desde cero, es posible imponer la coherencia de la numeración y la interpretación. MODBUS por su naturaleza ya se implementa en muchos lugares, y se debe evitar la interrupción de las implementaciones existentes.

Por lo tanto, el conjunto existente de tipos de transacción se ha clasificado en clases de conformidad donde el nivel 0 representa funciones que se implementan universalmente y son totalmente consistentes, y el nivel 2 representa funciones útiles pero con algunas idiosincrasias. También se identifican las funciones del presente conjunto que NO son adecuadas para la interoperabilidad.

Se debe tener en cuenta que las futuras extensiones de este estándar pueden definir códigos de función adicionales para manejar situaciones en las que el estándar de facto existente es deficiente. Sin embargo, sería engañoso que los detalles de dichas extensiones propuestas aparezcan en este documento. Siempre será posible determinar si un dispositivo de destino en particular admite un código de función en particular enviándolo de forma ‘especulativa’ y verificando el tipo de respuesta de excepción, si existe alguna, y este enfoque garantizará la interoperabilidad continua de los dispositivos MODBUS actuales con la introducción de cualquiera de tales extensiones. De hecho, esta es la filosofía que ha conducido a la clasificación actual del código de función.

2.1 Clase 0
Este es el conjunto de funciones mínimo útil, tanto para un MAESTRO como para un ESCLAVO.

leer múltiples registros (fc 3)
escribir múltiples registros (fc 16)

2.2 Clase 1

bobinas de lectura (fc 1)
lectura de entradas discretas (fc 2)
registros de entrada de lectura (fc 4)
escritura de bobina (fc 5)
registro único de escritura (fc 6)
lectura de estado de excepción (fc 7)

Esta función tiene típicamente un significado diferente para cada familia de esclavos.

2.3 Clase 2
Estas son las funciones de transferencia de datos necesarias para operaciones de rutina como HMI y supervisión

forzar bobinas múltiples (fc 15)
leer referencia general (fc 20)

Esta función tiene la capacidad de manejar múltiples solicitudes simultáneas y puede aceptar un número de referencia de 32 bits. Los PLC 584 y 984 actuales solo usan esta función para aceptar referencias de tipo 6 (archivos de registro extendido).

Esta función sería la más apropiada de extender para manejar grandes espacios de registro y elementos de datos que actualmente carecen de números de referencia, como las variables ‘no ubicadas’.

escribir referencia general (fc 21)

Esta función tiene la capacidad de manejar múltiples solicitudes simultáneas y puede aceptar un número de referencia de 32 bits. Los PLC 584 y 984 actuales solo usan esta función para aceptar referencias de tipo 6 (archivos de registro extendido).

Esta función sería la más apropiada de extender para manejar grandes espacios de registro y elementos de datos que actualmente carecen de números de referencia, como las variables ‘no ubicadas’.

registro de escritura de máscara (fc 22)
registros de lectura / escritura (fc 23)

Esta función permite la entrada de un rango de registros y la salida de un rango de registros como una sola transacción. Es la forma más eficiente, utilizando MODBUS, de realizar un intercambio regular de una imagen de estado como con un módulo de E / S.

Por lo tanto, un dispositivo de recopilación de datos de alto rendimiento pero versátil puede optar por implementar las funciones 3, 16 y 23 para combinar el intercambio regular rápido de datos (23) con la capacidad de realizar interrogaciones a pedido o actualizaciones de elementos de datos particulares (3 y 16)

leer cola FIFO (fc 24)

Una función un tanto especializada, destinada a permitir la transferencia de datos desde una tabla estructurada como FIFO (para usar con los bloques de funciones FIN y FOUT en el 584/984) a una computadora host. Útil en ciertos tipos de aplicaciones de registro de eventos.

2.4 Funciones específicas
de la máquina / proveedor / red Todas las siguientes funciones, aunque se mencionan en los manuales del protocolo MODBUS, no son apropiadas para fines de interoperabilidad porque dependen demasiado de la máquina.

programa de diagnóstico (fc 8)
(484) (fc 9)
poll (484) (fc 10)
contadores de eventos de comunicación (MODBUS) (fc 11) programa de
registro de eventos de comunicación (MODBUS) (fc 12)
(584/984) ( fc 13)
poll (584/984) (fc 14)
informa el programa de ID de esclavo (fc 17)
(884 / u84) (fc 18)
restablece el enlace de comunicación (884 / u84) (fc 19)
programa (ConCept) (fc 40)
programa de reemplazo de firmware (fc 125)
(584/984) (fc 126)
informe de dirección local (MODBUS) (fc 127)

3. Estructura del protocolo.

Esta sección describe la forma general de encapsulación de una solicitud o respuesta MODBUS cuando se realiza en la red MODBUS. Es importante tener en cuenta que la estructura del cuerpo de solicitud y respuesta, desde el código de función hasta el final de la parte de datos, tiene EXACTAMENTE el mismo diseño y significado que en las otras variantes de MODBUS, como

Puerto serie MODBUS – Codificación ASCII Puerto serie MODBUS – Codificación
RTU (binaria)
Red MODBUS PLUS – ruta de datos

Las únicas diferencias en estos otros casos son la forma de cualquier secuencia de “encuadre”, patrón de comprobación de errores e interpretación de direcciones.

Todas las solicitudes se envían a través de TCP / IP en el puerto registrado 502.

Las solicitudes normalmente se envían en modo semidúplex en una conexión determinada. Es decir, no hay ningún beneficio en el envío de solicitudes adicionales en una sola conexión mientras que una respuesta está pendiente. En lugar de eso, se recomienda a los dispositivos que deseen obtener altas tasas de transferencia pico que establezcan múltiples conexiones TCP / IP al mismo destino. Sin embargo, se sabe que algunos dispositivos cliente existentes intentan “canalizar” las solicitudes. Las técnicas de diseño que permiten que un servidor se adapte a este comportamiento se describen en el Apéndice A.

El campo ‘dirección de esclavo’ de MODBUS se reemplaza por un ‘Identificador de unidad’ de un solo byte que se puede usar para comunicarse a través de dispositivos como puentes y pasarelas que usan una sola dirección IP para admitir múltiples unidades finales independientes.

La solicitud y la respuesta tienen el prefijo de seis bytes de la siguiente manera

Por lo tanto, un ejemplo de transacción ‘leer 1 registro en el desplazamiento 4 de la interfaz de usuario 9’ que devuelve un valor de 5 sería

solicitud: 00 00 00 00 00 06 09 03 00 04 00 01
respuesta: 00 00 00 00 00 00 09 03 02 00 05

Consulte la sección posterior para ver ejemplos del uso de cada uno de los códigos de función en las clases de conformidad 0-2 Los diseñadores familiarizados con MODBUS deben tener en cuenta que los campos de verificación ‘CRC-16’ o ‘LRC’ NO son necesarios en MODBUS. Los mecanismos de suma de comprobación TCP / IP / IP y capa de enlace (por ejemplo, Ethernet) se utilizan para verificar la entrega precisa del paquete.

Para obtener información de nuestros productos y/o servicios puede llamarnos al +52 33 38 23 43 49.

Para obtener información sobre nuestros productos, por favor visita nuestra pagina web Logicbus

¿Desea agregar Modbus TCP/IP a su proyecto?

Ver Soluciones Modbus TCP/IP.

Contáctanos

ventas@logicbus.com | soporte@logicbus.com | 55-5431-67-18 | Iniciar conversación