Modbus es un protocolo de comunicación comúnmente utilizado en sistemas de automatización industrial, sistemas domésticos inteligentes, redes automatizadas de pequeños objetos (almacenes, invernaderos, etc). El protocolo también sirve para conectar equipos de varios tipos a un ordenador doméstico. El desarrollo de proyectos como Arduino y Raspberry Pi ha aumentado significativamente el interés en tareas relacionadas con la robótica y la automatización. Todo ello asegura el crecimiento de la popularidad de Modbus entre aficionados y profesionales.
En este artículo, veremos las características clave de las soluciones de software y hardware existentes para probar y depurar dispositivos y redes basadas en el protocolo Modbus.
Si está familiarizado con la arquitectura del protocolo, puede ir directamente a la descripción del software Modbus. De lo contrario, a continuación encontrará una breve introducción a Modbus.
Tabla de contenidos:
- Sobre el protocolo Modbus
- Desarrollo y prueba de dispositivos Modbus
- Depuración de sistemas de automatización basados en dispositivos Modbus
- Desafíos de la comunicación Modbus
Sobre el protocolo Modbus
Modbus es un protocolo común utilizado en los sistemas de automatización de niveles medio e inferior (campo). El nivel medio es el nivel de los controladores - dispositivos que recopilan datos y controlan el proceso tecnológico. El nivel de campo es el nivel de interacción entre sensores y controladores o sensores y el servidor.
A continuación se muestra la estructura típica de un sistema de automatización que utiliza Modbus como protocolo básico.
El 'entorno' estándar para el protocolo Modbus es RS485/422/232. Modbus RTU o Modbus ASCII funcionan sobre ellos. En las redes TCP/IP, sin embargo, el protocolo de nivel superior es el protocolo de transporte TCP y esta variante se denomina Modbus TCP. En este artículo, hablaremos sobre el modo de transmisión Modbus RTU.
El protocolo Modbus se implementa en una relación maestro-esclavo. Eso significa que la comunicación siempre la inicia un dispositivo, el maestro, que envía una solicitud a un esclavo (servidor) y espera una respuesta. Siempre hay un maestro en la red y de 1 a 247 esclavos.
El maestro interactúa con los dispositivos esclavos en el formato de solicitud-respuesta. La solicitud contiene una secuencia de bytes, denominada trama, en la que el tiempo entre los bytes está estandarizado en función de la velocidad de transferencia de datos y no supera el intervalo durante el cual se pueden transmitir 1,5 bytes de datos. En el modo RTU, los mensajes comienzan con un intervalo de silencio de al menos 3,5 tiempos de caracteres.
Se envía un mensaje de solicitud con el siguiente formato:
ID - dirección del dispositivo (1 byte),
FN - función Modbus (1 byte),
[args] - argumentos de la función (N bytes, dependiendo de la función),
CRC - una suma de control CRC-16 (2 bytes).
Formato de un mensaje de respuesta:
Como puede ver, los marcos de respuesta y solicitud tienen construcciones similares, excepto por el campo Datos, que proporciona contenido diferente según la función realizada.
Si la función solicitada no es compatible con el dispositivo esclavo o los argumentos en el campo [args] de la solicitud son incorrectos para este servidor, en el campo FN de la respuesta el bit superior debe ser establecido en 1 y el campo de datos contener información adicional sobre el error ocurrido.
Además, determinados dispositivos esclavos pueden tener registros específicos con información adicional.
Los tipos de registros a los que se hace referencia en los dispositivos Modbus incluyen los siguientes:
| Campo | Acceso | Tamaño | Descripción |
|---|---|---|---|
| Entradas Discretas | utilizado como entradas | ||
| Salidas de Bobinas | utilizado para control discreto | ||
| Registros de entrada | utilizado para entrada | ||
| Registros de retención | utilizado para muchas cosas, incluidas entradas, salidas, datos de configuración, etc. |
La descripción completa del protocolo Modbus RTU se proporciona en su especificación funcional.
Al configurar una red Modbus, un punto a considerar es que el protocolo permite la transmisión de datos desde múltiples dispositivos que serán recibidos por un solo servidor o controlador con un driver Modbus instalado. Una aplicación serie puede controlar el puerto de comunicación de un servidor (por ejemplo, COM1) cuando recibe datos Modbus de varios sensores.
Desafortunadamente, existe una limitación, ya que abrir el puerto de recepción en múltiples aplicaciones simultáneamente puede ser un verdadero desafío.
Hay una solución a este dilema. Virtual COM Port Driver de Electronic Team permite crear puertos RS485 virtuales y dividir los datos Modbus para que múltiples puertos puedan recibir los datos al mismo tiempo.
