Estructura de la trama Modbus

Como en cualquier protocolo de campo destinado al intercambio de información entre un servidor y los dispositivos esclavo, el protocolo Modbus RTU sigue una estructura de trama bien definida por campos. Como veréis la estructura de trama Modbus es muy sencilla, siendo uno de los motivos de su éxito junto a ser un protocolo abierto y a no estar orientado a conexión (como comentaba en el post anterior).

Así pues la estructura básica de una trama Modbus RTU, tanto de lectura como escritura, es la que se muestra a continuación:

Dirección Esclavo Función Modbus Bytes de Datos Comprobación de Errores
1 Byte 1 Byte N Bytes 2 Bytes

Dirección Esclavo

Este es el campo al que había hecho referencia en el post anterior y que de manera directa limita el número de esclavos que podemos tener conectados de forma correcta al bus serie Modbus. Dado que existen direcciones reservadas para propósitos especiales como el broadcast el valor que puede ir de 1 a 247.

  • Valor comprendido entre 1-247.
  • No se vé afectado por si se trata de una trama de escritura o lectura.
  • Cuando el master pregunta al slave este campo contiene la dirección del slave al que va dirigido. Cuando se trata de una trama de respuesta de un slave al master este campo contiene también la dirección del esclavo indicando quién es el que responde.

Función Modbus

Con este campo se especifica que acción requiere el master del slave al que va dirigida la trama. Con el paso de los años se han ido añadiendo más funciones especificas. En cualquier caso, os explico las mas utilizadas y/o genéricas.

En este caso, el valor contenido en este campo si que puede variar si se trata de una trama Master->Slave o si por el contrario es Slave->Master. El valor de este byte se verá modificado en la trama de respuesta sólo cuando exista algún error en el campo de datos de la trama Modbus enviada por el Master, no cuando el código de comprobación de errores de esta sea erróneo. Reiterando lo dicho, si la trama del Master es correcta, la trama de respuesta tiene este byte con el mismo valor. En el caso de existir error el Slave responderá con la misma función que en la trama enviada por el Master pero con la máscara 0x80 aplicada. Por ejemplo: si el máster envía una trama con función 0x03 correcta el Slave responderá con el mismo campo y el mismo valor, 0x03; si por el contrario contiene algún error, el Master aplicará la máscara 0x80 y responderá con una trama con el valor 0x83. Poco a poco, mas adelante explicaré con mas detalle la trama de error de respuesta para que quede mas claro. Ahora centrémonos en los casos no excepcionales y sin error. Pues primero se gatea y después se camina.

Funciones de lectura de datos:

  • Función 01 (01 hex): Lectura de señales discretas de salida (Discrete Output Coils)
  • Función 02 (02 hex): Lectura de señales discretas de entradas (Discrete Input Contacts)
  • Función 03 (03 hex): Lectura de registros analógicos (Analog Output Holding Registers)
  • Función 04 (04 hex): Lectura de registros analógicos de entrada (Analog Input Registers)

Funciones de escritura de datos:

  • Función 05 (05 hex): Escritura de una señal discreta de salida (Simple Discrete Output Coil)
  • Función 15 (0F hex): Escritura de múltiples señales discretas de salida (Múltiple Discrete Output Coils)
  • Función 06 (06 hex): Escritura de un Simple Analog Output Holding Register
  • Función 16 (10 hex): Escritura Múltiple Analog Output Holding Registers

Byte de datos

Este campo dependerá tanto en contenido como en longitud de la función que se indique en el campo anterior (Función) así como de si se trata de una trama Master-Slave o de respuesta Slave-Master.

En este post podéis ver como son cada una de las funciones. He preferido dedicarle un post por su variabilidad.

CRC – Campo de comprobación de errores

Este campo consta de dos bytes y como en cualquier otro protocolo en el caso de Modbus sirve para la detección de errores en la trama. El CRC (Cyclic Redundancy Check o comprobación de redundancia cíclica) es un código más que frecuente en la detección de errores en redes digitales, sistemas de almacenamiento para la detección de modificación accidental de los datos o en este caso para comprobar la integridad de los datos en su transmisión por buses de campo.

Para el cálculo del CRC se utilizan cada uno de los bytes que conforman la trama. El procedimiento es el siguiente:

  • Se envía la trama Modbus con el CRC calculado.
  • El receptor del mensaje recibe la trama completa e internamente calcula el CRC con los datos recibidos. Y lo compara con el CRC que le ha llegado.
    • Si el código coincide, la trama Modbus es correcta y se prosigue con el funcionamiento normal generando la respuesta pertinente.
    • Si el código es erróneo, es decir que no coincide el CRC recibido con el CRC no se responderá a la petición de datos por parte del Slave, de manera que ocurrirá un Timeout en recepción del Master y este deberá entender que el Slave no ha recibido la trama correctamente y procederá a un reintento.

Si necesitáis más información acerca de como calcular este CRC16 encontraréis algo de código C en este post: CRC 16 Modbus RTU

Tagged with: , , , , , , ,
Posted in Blog Técnico, Hardware Firmware, ModBUS

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

*


*

enlaces patrocinados