Presentacion de Modbus

Guía básica para el uso del

Protocolo Modbus

Primera Versión.

Versión Preliminar.

Julio de 2012

Raúl Mista

Entre Ríos – Argentina

Sujeta a revisión de dialéctica.

Los contenidos están completos para esta versión.

Introducción a Modbus

Modbus ASCII y RTU Versión Preliminar 07-2012

Conclusiones: El documento es una recopilación sobre distintas lecturas y practicas realizadas en mi incursión

de aprendizaje sobre el protocolo de comunicación en cuestión.

Esta presentación es una introducción al uso del protocolo de comunicación serial Modbus, los

lectores obtienen herramientas que le servirán de base a la hora de implementar el protocolo.

En el documento se trata de forma teórica y práctica una comunicación efectiva usando el

protocolo, la idea fundamental del trabajo reside en que los lectores verán distintas

configuraciones en forma práctica con su sustento teórico.

Se requiere un mínimo conocimiento de redes RS232, RS485, RS422 y Ethernet capa física,

numeración hexadecimal, conversión decimal a hexadecimal, códigos de numeración ASCII.

Aquellos que requieran realizar comunicaciones, se recomienda leer atentamente las

especificaciones de los IED involucrados en la comunicaciones, ya que el mapa de

direccionamiento de las variables que sirven de intercambio, varían de acuerdo a la disposición

de cada fabricante.

En una segunda presentación se profundizara en prácticas de configuraciones y códigos de diagnósticos para redes MODBUS.



________________________________________________________________________INDICE

1. Modbus 4

1.1 Historia 4

1.2 Características 4

1.3 Distintas alternativas 4

2 Introducción __ 5

3 Modos de trasmisión 7

3.1 Modbus ASCII_____ 7

3.2 Modbus RTU _____ 8

4 Estructura del mensaje Modbus __ 8

4.1 Estructura ASCII___ 8

4.2 Estructura RTU____ 9

4.3 Campo de dirección 9

4.4 Campo de función_ 10

4.5 Campos de datos_ 10

4.6 Campo de detección de errores 11

4.7 Como se trasmiten los caracteres 11

5 Métodos de chequeo de errores __ 12

5.1 Comprobación de paridad 12



6 Formato de función Modbus 13

6.1 Como se expresan los valores numéricos 13

6.2 Contenidos de los campos en los mensajes 13

6.3 Códigos de funciones 15

6.4 Direccionamiento 15

6.5 Códigos de errores 16

7 Practicas 16

8 Biografías 25



1 Modbus 1.1 Historia:

Protocolo diseñado para comunicar PLC MODICON (MOdular Digital CONtroler, de la

empresa Bedford Associates), este protocolo se empieza a integrar a dichos PLC en 1973, y en

1979 se libero como protocolo abierto. Esto hizo a modbus el protocolo de comunicación serial

más ampliamente utilizado.

1.2 Características:

Es público.

Situado en capa 7 del modelo OSI.

Fácil implementación.

Flexible.

Bloques de datos de distintos tipos (variables digitales, analógicas, entradas salidas).

La comunicación se realiza entre un Maestro y uno o varios esclavos hasta 247

Comunicación Punto a Punto o Punto a Multipunto.

Utilizable en RS232, RS485, Ethernet (no es especificada por el protocolo).

1.3 Distintas alternativas:

Existen dos alternativas libres para la implementación de este protocolo en forma serial. Modbus fue desarrollado originalmente en su versión ASCII, esta versión es legible, pero poco eficiente, la trama tiene un encabezado (:) y el control de errores es de redundancia longitudinal LRC. Luego se desarrollo la versión RTU, esta versión es binaria y optimiza los bit trasmitidos, no tiene encabezado y el control de errores es de redundancia cíclica (CRC). También existe la versión Modbus/TCP, esta es semejante a la versión RTU encapsulada en una

trama TCP, para el uso de esta versión se definió el puerto 502 (nombre: ASA-APPL-

PROTO.) Además de estas versiones existen otras alternativas que no serán tratadas en esta presentación, entre las que se distinguen: Modbus Plus.



2 Introducción El lenguaje de comunicación más común utilizado por los controladores, medidores, actuadores, válvulas a los que llamaremos IED, es el protocolo Modbus. Este protocolo define una estructura de mensaje que los controladores reconocen y utilizan independientemente del tipo de redes sobre la que se comunican. Se describe el proceder de un controlador para solicitar el acceso a otro dispositivo, cómo responderá a las peticiones de los otros dispositivos, y cómo los errores se detectan y se notifican. Se establece un formato común para la disposición y el contenido de los campos del mensaje. El protocolo Modbus establece la norma interna que los IED´s analiza el mensaje. Durante las comunicaciones en una red Modbus, el protocolo determina cómo cada IED sabrá su dirección de dispositivo, reconocer un mensaje dirigido a él, determinar el tipo de medidas que deben adoptarse, y extraer cualquier datos u otra información contenida en el mensaje. Si la respuesta es necesaria, el controlador construirá el mensaje de respuesta. La siguiente figura muestra cómo los IED pueden ser interconectados en una jerarquía de redes que emplean diferentes técnicas de comunicación. En trasmisiones de mensajes, el protocolo Modbus incrustado en la estructura del paquete que cada red ofrece, es el lenguaje común mediante el cual los dispositivos pueden intercambiar datos. Trasmisión sobre redes Modbus:

Scada

Controlador RTU

Válvula Actuador Medidor

Modbus Ethernet

Modbus ASCII RS232

Modbus RTU RS485

Entradas

/Salidas



Figura 1 Los puertos estándar Modbus se utilizan generalmente en RS-232C o en RS485. Las interfaces definen los pines del conector, el cableado, los niveles de señal, la transmisión en tasas de baudios y comprobación de paridad. Los IED´s se comunican utilizando una técnica maestro-esclavo, en la que sólo un dispositivo (el maestro) puede iniciar transacciones (llamadas 'consultas'). Los otros dispositivos (los esclavos) responden al pedido de datos requeridos para el maestro, o mediante la adopción de la acción solicitada por la consulta. El maestro puede dirigirse a los esclavos individuales, o puede iniciar un mensaje de difusión a todos los esclavos (Broadcast). Los esclavos responden con un mensaje (llamado «respuesta») a las preguntas que son dirigidos a ellos de forma individual. Los mensajes Broadcast no requieren respuestas. El protocolo Modbus establece el formato para la consulta del maestro con los campos dirección, un código de función que define la acción solicitada, los datos a enviar, y un campo de comprobación de errores. El mensaje de respuesta del esclavo también se construye mediante el protocolo Modbus. Contiene campos que confirman la acción tomadas, los datos a ser devuelto, y un campo de comprobación de errores. Si se produce un error en la recepción del mensaje, o si el esclavo no es capaz de realizar la acción solicitada, el esclavo va a construir un mensaje de error y enviarlo como su respuesta. 2.1 Ciclo de preguntas y respuestas:

Figura 2 *Los maestros y los esclavos son IED´s, esto es el sigla de Dispositivo Electrónico Inteligente. La Consulta: El código de función de consulta le dice al dispositivo esclavo direccionado el tipo

de acción a realizar, Los bytes de datos contienen la información adicional que el esclavo

necesita para realizar la función. Por ejemplo, el código de función 03 consulta al esclavo para

leer registros de valores análogos y responder con su contenido. El campo de datos debe

contener la información sobre la cantidad de registros y en qué posición debe comenzar el

envió. El campo de verificación de error proporciona un método con el que el esclavo validara

la integridad de los contenidos del mensaje.

1•Direccion del dispocitivo

2•Codigo de funcion

3•Datos

4

•Control de errores

Pregunta desde el maestro

Respuesta del esclavo

maestro

1•Direccion del dispocitivo

2•Codigo de funcion

3•Datos

4

•Control de errores



La respuesta: Si el esclavo hace una respuesta normal, el código de función en la respuesta es

un eco del código de función en la consulta. Los bytes de datos contienen el los datos

recogidos por el esclavo, como los valores de registro o de su estado. Si ocurre un error, el

código de función se ha modificado para indicar que la respuesta es una respuesta de error,

y los bytes de datos contienen un código que describe el error. El campo de comprobación de

errores permite que el maestro confirme la validez del contenido del mensaje.

3 Modos de trasmisión serial La comunicación Modbus serial libre tiene dos alternativas: ASCII o RTU. Los usuarios pueden

seleccionar el modo deseado, junto con los parámetros de comunicación del puerto serie

(velocidad de transmisión, el modo de paridad, etc), durante la configuración de cada IED. El

modo serie debe ser el mismo para todos los dispositivos en una red Modbus (no es

compatible Modbus RTU con ASCII)

3.1 El modo ASCII: Cuando los IED están configurados para comunicarse en una red Modbus en

modo ASCII (Código Estándar Americano para Intercambio de Información), cada byte de 8 bits

en un mensaje se envía como dos caracteres ASCII. La principal ventaja de este modo es que

permite intervalos de tiempo de hasta un segundo entre los caracteres sin causar un error.

El formato de cada byte en modo ASCII es:

Figura 3

3.2 Modo RTU: Cuando los IED están configurados para comunicarse en una red Modbus en

modo RTU (Remote Terminal Unit), cada byte de 8 bits en un mensaje contiene dos caracteres

hexadecimales 4-bit. La principal ventaja de este modo es su mayor densidad de caracteres

permite una mejor transferencia de datos que el ASCII para la misma velocidad en baudios.

Cada mensaje debe ser transmitido en forma secuencia continua.

Los caracteres hexadecimales, ASCII 0-9, A-F

Un carácter hexadecimal contenido en cada trama

ASCII

Codificación del sistema

1 bit de inicio

7 bits de datos, el bit menos significativo enviado primero

1 bit para paridad par/impar; ningún bit sin paridad

1 bit de parada si se utiliza la paridad, 2 bits si no hay paridad

Bits por byte:

Chequeo de redundancia longitudinal (LRC) Campo de chequeo de

error



El formato de cada byte en modo RTU es:

Figura 4

4 La estructuración del mensaje Modbus En cualquiera de los dos modos de transmisión serie (ASCII o RTU), un mensaje Modbus se

coloca por dispositivo de transmisión en un marco que tiene un principio conocido y en punto

final. Esto le permite a los dispositivos receptores reconocer el inicio del mensaje, leer la

porción de dirección y determinar a qué dispositivo se dirige (o ah todos los dispositivos, si es

un mensaje broadcast), y para saber cuando el mensaje se ha completado. Mensajes parciales

se pueden detectar.

4.1 Estructura ASCII

En el modo ASCII, los mensajes comienzan con un 'dos puntos' (:) de caracteres (ASCII

hexadecimal 3A), y terminan con un "retorno de carro - avance de línea" (CRLF) par (ASCII

hexadecimal 0D 0A).

Los caracteres permitidos de transmisión para todos los otros campos son hexadecimales 0-9,

A-F.

Dispositivos monitorean la red en la espera del carácter 'dos puntos'.

Cuando se recibe, cada dispositivo decodifica el campo próximo (el campo de dirección) para

averiguar si es el dispositivo direccionado.

Intervalos de hasta un segundo puede transcurrir entre caracteres en el mensaje.

Si se produce un intervalo mayor, el dispositivo receptor asume que se ha producido un error.

8-bit binario, hexadecimal 0-9, A-F

Dos caracteres hexadecimales contenidos en cada campo de

mensaje 8-bits

Codificación del sistema

1 bit de inicio

8 bits de datos, el bit menos significativo enviado primero

1 bit para paridad par/impar; ningún bit sin paridad

1 bit de parada si se utiliza la paridad, 2 bits si no hay paridad

Bits por byte:

Chequeo de redundancia cíclica (CRC) Campo de chequeo de

error



Una estructura típica se muestra a continuación.

Figura 5

4.2 Estructura RTU

En el modo RTU, los mensajes comienzan con un intervalo de silencio de al menos 3,5

características de tiempos. Esto es más fácil de implementar como un múltiplo de veces de

características de la velocidad de transmisión que se utiliza en la red (se muestra como T1-T2-

T3-T4 en la siguiente figura). El primer campo transmitido es la dirección del dispositivo.

Los caracteres permitidos de transmisión para todos los campos son hexadecimales 0-9, A-F.

Los IED monitorean la red de de forma continua, durante los intervalos de 'Silencios'. Cuando

el primer campo (el campo de dirección) se recibe, cada dispositivo lo decodifica para saber si

es el dispositivo direccionado.

Tras el último carácter transmitido, un intervalo similar de al menos 3,5 veces de característica

de tiempo marca el final del mensaje. Un nuevo mensaje puede comenzar después de este

intervalo.

Todo el mensaje debe ser transmitido como un flujo continuo. Si se produce un intervalo de

silencio de por más de 1,5 veces la características de tiempo antes de la terminación de la

trama, la recepción IED desplaza el mensaje incompleto y asume que el próximo byte será el

campo de la dirección de un nuevo mensaje.

Del mismo modo, si un nuevo mensaje comienza antes de 3,5 veces después de un carácter de

mensaje anterior, el dispositivo receptor lo considerará una continuación del mensaje anterior.

Esto establecerá un error, como el valor en el último campo CRC no será un mensaje válido.

Una estructura típica se muestra a continuación.

Figura 6

4.3 Cómo funciona el campo de dirección:

El campo de dirección de un mensaje contiene dos caracteres (ASCII) u ocho bits (RTU). Las

direcciones validas de los IED esclavos están en el intervalo desde 1 a 247 en decimal. Cuando

el esclavo envía su respuesta, coloca su propia dirección en este campo para permitirle al

maestro saber que esclavo está respondiendo.

La dirección 0 se utiliza para el envío de mensaje broadcast, que reconocen todos los IED´s

esclavos.

Inicio

•1 caract.

•:

Direccion

•2 caract.

Funcion

•2 caract.

Datos

•n caract.

Check error

•2 caract

Fin

•2 cacact

•CR LF

Inicio

•T1-T2-T3-T4

Direccion

•8 bits

Funcion

•8 bits

Datos

•n x 8 bits

Check error

•16 bits

Fin

• T1-T2-T3-T4



4.4 Cómo funciona el campo de función:

El campo de código de función de un mensaje contiene dos caracteres (ASCII) o ocho bits

(RTU). Los códigos válidos están en el intervalo de 1 a 255 en decimal. No todos los códigos son

implementados por Modbus, y podemos encontrar muchas variantes dependiendo de la

aplicación o IED´s.

Cuando un maestro envía un mensaje a un esclavo el campo de código de función le dice al

esclavo qué tipo de acción debe realizar. Por ejemplo para leer el estado ON / OFF, estados de

un grupo de salidas discretas o entradas; para leer el contenido de datos de un grupo de

registros, para leer el estado de diagnóstico del esclavo, escribir en salidas o registros, o para

permitir la carga, grabación, o verificar el programa en el esclavo.

Cuando el esclavo responde al maestro, utiliza el campo de código de función para indicar ya

sea respuesta normal (sin errores) o algún tipo de error (llamado una respuesta de excepción).

Para una respuesta normal, el esclavo simplemente se hace eco del código de la función

original. Para una respuesta de excepción, el esclavo devuelve un código que es equivalente al

código de función original con su bit más significativo a un 1 lógico.

Por ejemplo, un mensaje de maestro a esclavo a leer a un grupo de registros análogos tendría

el siguiente código de función:

0000 0011 (hexadecimal 03)

Si el dispositivo esclavo toma la acción solicitada, sin error, devuelve el mismo código en su

respuesta.

Si se produce una excepción, devuelve: 1000 0011 (hexadecimal 83)

Además de su modificación del código de función para una respuesta de excepción, el esclavo

pone un código único en el campo de datos del mensaje de respuesta. Esto le dice al maestro

de qué tipo de error, o la razón de la excepción. El maestro resuelve las respuestas de

excepción.

4.5 Contenido del campo de datos:

El campo de datos se construye utilizando conjuntos de dos dígitos hexadecimales, en el

intervalo de 00 a FF en hexadecimal. Estos se pueden hacer de un par de caracteres ASCII, o

a partir de un carácter RTU, de acuerdo al modo que se utilice. El campo de datos de los

mensajes enviados desde un maestro a los dispositivos esclavos contiene información

adicional que el esclavo debe utilizar para tomar la acción definida por el código de la función.

Esto puede incluir elementos como direcciones discretas o registro, la cantidad de variables

que se manejan, y el recuento de bytes de datos reales de la trama.

Por ejemplo, las peticiones de un maestro a un esclavo para leer un grupo de registros holding

(código de función 03), el campo de datos especifica el registro inicial y cuántas registros son

requeridos. Si el maestro escribe un grupo de registros en el esclavo (código de función 10

hexadecimal), el campo de datos especifica el registro de inicio, cantidad de registros a

escribir, y los datos a escribir en los registros.

Si no hay ningún error, el campo de datos de una respuesta de un esclavo a un maestro

contiene los datos solicitados. Si ocurre un error, el campo contiene un código de excepción

que el maestro puede utilizar para determinar la acción a tomar.

4.6 Contenido del campo Comprobación de errores:

Hay dos tipos de métodos de comprobación de errores para redes Modbus.



La comprobación de errores contenidos en el campo dependerá del método que se utiliza.

ASCII

Cuando se utiliza el modo ASCII, el campo de la comprobación de errores contiene dos

caracteres ASCII. Los caracteres de verificación de error es el resultado de una comprobación

de redundancia longitudinal (LRC), cálculo que se realiza con el contenido del mensaje,

excluyendo los caracteres de comienzo "dos puntos" y fin CRLF. Los campo LRC se adjuntan al

mensaje como el último campo que precede a la CRLF caracteres.

RTU

Cuando se utiliza el modo RTU, el campo de la comprobación de errores contiene un

implementado de 16-bits como dos bytes de 8 bits. El valor de verificación de error es el

resultado de un cálculo de comprobación de redundancia cíclica al cabo del contenido del

mensaje.

El campo CRC se añade al mensaje como el último campo en el mensaje.

Cuando se hace esto, el byte de orden bajo del campo se añade en primer lugar, seguido por el

byte de orden superior. El byte CRC de orden superior es el último byte que se enviará en el

mensaje.

4.7 Como se transmiten los caracteres:

Cuando los mensajes se transmiten en las redes Modbus, cada carácter o byte se envía en este

orden (de izquierda a derecha):

Bit menos significativo (LSB). . . Bit más significativo (MSB)

El modo ASCII sigue la secuencia de bits

Con Control de paridad

Sin control de paridad

El modo RTU sigue la secuencia de bits

Con Control de paridad

Sin control de paridad

Figura 7

5 Métodos de chequeos de error Modbus utiliza dos tipos de comprobación de errores. Comprobación de la paridad (par o

impar) puede estar opcionalmente aplicada a cada carácter. Chequeo de trama (LRC o CRC) se

inicio 1 2 3 4 5 6 7 paridad fin

inicio 1 2 3 4 5 6 7 fin fin

inicio 1 2 3 4 5 6 7 8 paridad fin

inicio 1 2 3 4 5 6 7 8 fin fin



aplica a todo el mensaje. Tanto el carácter de verificación y la verificación del mensaje de

trama lo genera el IED maestro y aplica al mensaje antes de la transmisión. El IED esclavo

comprueba cada carácter y la trama de todo el mensaje durante la recepción.

El maestro se configura por el usuario para esperar un intervalo de tiempo predeterminado

antes de abortar la comunicación. Este intervalo se establece lo suficientemente largo para

que cualquier esclavo de responder en forma normal. Si el esclavo detecta un error de

transmisión, el mensaje no será tratado, el esclavo no va a construir la respuesta al maestro.

Por lo tanto el tiempo de espera expira y permitir que el maestro maneje el error. Un mensaje

dirigido a un dispositivo esclavo que no existe, también causará expirar el tiempo de espera.

5.1 Comprobación de la paridad:

Los usuarios pueden configurar los controladores para la comprobación de paridad par o

impar, o sin paridad. Esto va a determinar cómo el bit de paridad se establece en cada

carácter.

La paridad par o impar especifica la cantidad de bits 1 que se contarán en los caracteres (siete

bits de datos para el modo ASCII, u ocho para RTU). El bit de paridad se establecerá en 0 o 1

dependiendo si es paridad par o impar de bits 1.

Por ejemplo, los ocho bits de datos están contenidos en un trama de carácter RTU:

1100 0101

La cantidad total de bits 1 en el carácter es cuatro. Si se utiliza paridad par, el bit de paridad

será un 0, haciendo que la cantidad total de bits 1 sean en total un número par (cuatro).

Si se utiliza paridad impar, el bit de paridad será un 1, haciendo una cantidad impar (cinco).

Cuando el mensaje se transmite, el bit de paridad se calcula y se aplica a cada carácter. El

dispositivo receptor cuenta la cantidad de bits 1 y establece un error si coincide con el cálculo

(todos los dispositivos en la red Modbus debe estar configurado para utilizar el mismo método

de verificación de paridad).

Este método solo detecta errores cuando los bits afectados son números impares.

5.2 Comprobación LRC:

En el modo ASCII, los mensajes incluyen un campo de comprobación de errores de chequeo de

Redundancia Longitudinal (LRC). El campo LRC comprueba el contenido del mensaje, sin contar

los 'dos puntos' del inicio y el CRLF del final. Se aplica independientemente del método de

verificación de paridad.

El campo LRC es un byte, que contiene un valor binario de 8-bits. El valor de LRC es calculado

por el dispositivo que transmite, y añade la LRC en el mensaje. El dispositivo receptor calcula

un LRC durante la recepción del mensaje, y compara el valor calculado con el valor real

recibido en el campo LRC. Si los dos valores no son iguales, se produce un error.

El LRC se calcula sumando los sucesivos bytes de 8 bits del mensaje, descartando cualquier

acarreó, y luego se le realiza el complemento dos. Se realiza en el contenido del campo ASCII

mensajes excluyendo el 'dos puntos y el CRLF' de comienza y final respectivamente.

5.3 Comprobación CRC:

En el modo RTU, los mensajes incluyen un campo de comprobación de errores que se basa en

una comprobación de redundancia cíclica (CRC). El campo CRC comprueba el contenido de



todo el mensaje. Se aplica independientemente de cualquier método de verificación de

paridad utilizada.

El campo CRC es de dos bytes, que contiene un valor binario de 16-bit. El valor del CRC es

calculado por el dispositivo de transmisión, y añade el CRC al mensaje. El dispositivo receptor

vuelve a calcular un CRC durante la recepción del mensaje, y compara el valor calculado con el

valor recibido en el campo CRC. Si los dos valores no son iguales, se produce error.

El CRC comienza cargando un registro de 16 bits con todos 1's. Luego comienza un proceso de

aplicación de los sucesivos bytes del mensaje al contenido del registro. Solo los 8 bits de datos

son usados para generar el CRC. Los bits de inicio, parada y paridad no se utilizan para el CRC.

Durante la generación del CRC, se ejecuta una operación lógica XOR entre cada byte y el

contenido del registro. Luego el resultado es desplazado en la dirección del bit menos

significativo (LSB), ingresando un 0 en la posición del bit más significativo (MSB). El bit extraído

es examinado. Si es un 1 se ejecuta una XOR entre el contenido del registro y un valor fijo. Si el

bit extraído es 0 no se ejecuta la XOR. Este proceso se repite hasta ejecutarse ocho

desplazamientos. Después del último desplazamiento se ejecuta una XOR entre el próximo

byte y el valor del registro de 16 bits, realizando el procedimiento de desplazamientos des

cripta anteriormente. El contenido final del registro, después de aplicarse todos los bytes del

mensaje, es el valor del CRC.

El procedimiento para generar el CRC es:

1. Cargar un registro de 16 bits con FFFFH (todos 1's). Este registro toma el nombre de

registro CRC.

2. Ejecutar una XOR entre el primer byte del mensaje y el byte menos significativo del registro

CRC, dejando el resultado en el registro CRC.

3. Desplazar el registro CRC un bit a la derecha (hacia el LSB), ingresando un 0 en el MSB.

Extraer y examinar el LSB.

4. Si el LSB fue 0 repetir el paso 3 (otro desplazamiento). Si el MSB fue 1 realizar una XOR

entre el registro CRC y el valor A001H (1010 0000 0000 0001 B).

5. Repetir los pasos 3 y 4 hasta completar ocho desplazamientos, dando como procesado un

byte.

6. Repetir los pasos 2 a 5 para el próximo byte del mensaje. Continuar hasta que todos los

bytes han sido procesados.

7. El contenido final del registro CRC es el valor CRC. Cuando el CRC (dos bytes) es transmitido

en el mensaje, el byte menos significativo debe ser transmitido primero, seguido del byte más

significativo.

6 Formatos de función se control y datos 6.1 Cómo se expresan valores numéricos:

A menos que se especifique lo contrario, los valores numéricos (como direcciones, código o de

datos) se expresan como valores decimales en el texto de esta sección.

Direcciones de datos en los mensajes Modbus

Todas las direcciones de datos en mensajes Modbus hacen referencia a cero. La primera

posición de memoria es cero.



Por ejemplo: La bobina conocido como "bobina 1 'en un controlador programable se dirige

como bobina 0000 en el campo de dirección de datos de un mensaje Modbus.

Bobina de 127 decimal es tratado como la bobina 007E hexadecimal (126 decimal).

El holding registro 40001 se aborda como registro 0000 en el campo de dirección de datos de

mensaje. El campo de código de la función ya especifica un "holding registro" . Por lo tanto la

referencia del XXXX '4 'está implícita. El holding registro 40108 se dirige como registro 006B

hex (107 decimal).

6.2 Contenido de los campo en los mensajes:

La figura 8 muestra un ejemplo de un mensaje de consulta Modbus. La figura 9 es un ejemplo

de una respuesta normal. Ambos ejemplos muestran el contenido del campo en hexadecimal,

y se muestra cómo un mensaje puede ser enmarcado en ASCII o en modo RTU.

La consulta es una lectura de holding registros al IED esclavo 10. Las solicitud de tres holding

registro, desde el registro 40012 hasta el 40014. Tenga en cuenta que el mensaje especifica la

dirección del registro inicial como 0011 (000B hex).

La respuesta del esclavo hace eco del código de función, esto indica una respuesta normal. El

campo 'cantidad de bytes' especifica el número de 8 bits de datos serán contestados.

Se muestra la cantidad de bytes de 8 bits trasmitidos, ya sea ASCII o RTU .

En ASCII, cada valor hexadecimal de 4-bits requiere un carácter ASCII, por lo tanto dos

caracteres ASCII por cada campo de función.

Por ejemplo, el valor hexadecimal 63 se envía como un byte de 8-bits en modo RTU

(01100011). El mismo valor enviado en modo ASCII requiere dos bytes, ASCII '6 '(0.110.110)

y '3 '(0.110.011).

Pregunta:

Total 17 8

Figura 8

Tramas de pregunta del maestro en ASCII y RTU

Nombre del campo

Cabezera

Direccion de esclavo

Funcion

Direccion inicial HI

Direccion inicial LO

Nº de registros Hi

Nº de registros LO

Chequeo de error

Final

Ejemplo (hex)

10

04

00

0B

00

03

Caracteres ASCII

:

1 0

0 4

0 0

0 B

0 0

0 3

LRC(2 caracteres)

CR LF

Campo de 8 bits-RTU

Nada

0000 1010

0000 0100

0000 0000

0000 1011

0000 0000

0000 0011

CRC (16 bits)

Nada



Total 23 11

Figura 9

Tramas de respuesta del esclavo en ASCII y RTU

6.3 Códigos de función:

- Función 1 Read Coil Status - Función 2 Read Input Status - Función 3 Read Holding Registers - Función 4 Read Input Registers - Función 5 Force Single Coil - Función 6 Preset Single Register - Función 7 Read Exception Status - Función 8 Diagnostics - Función 9 Program 484 - Función 10 Poll 484 - Función 11 Fetch Communication Event Counter - Función 12 Fetch Communication Event Log - Función 13 Program Controller - Función 14 Poll Controller - Función 15 Force Multiple Coils - Función 16 Preset Multiple Registers - Función 17 Report Slave ID - Función 18 Program 884/M84 - Función 19 Reset Comm. Link - Función 20 Read General Reference - Función 21 Write General Reference - Función 22 Mask Write 4X Register - Función 23 Read/Write 4X Registers - Función 24 Read FIFO Queue

Nombre del campo

Cabezera

Direccion de esclavo

Funcion

Contador

Dato HI

Dato LO

Dato HI

Dato LO

Dato HI

Dato LO

Chequeo de error

Final

Ejemplo (hex)

10

04

06

02

0B

30

0A

00

65

Caracteres ASCII

:

1 0

0 4

0 6

0 2

0 B

3 0

0 A

0 0

6 5

LRC(2 caracteres)

CR LF

Campo de 8 bits-RTU

Nada

0000 1010

0000 0100

0000 0110

0000 0010

0000 1011

0011 0000

0000 1010

0000 0000

0110 0101

CRC (16 bits)

Nada

http://www.tolaemon.com/site/protocolo_modbus#fun_1_2




http://www.tolaemon.com/site/protocolo_modbus#fun_5









6.4 Códigos de funciones más utilizados

6.5 Códigos de errores(excepciones)

Codigo01

02

03

04

05

06

07

15

16

Accion

Leer Bobina (0:xxxx)

Leer Entradas (1:xxxx)

Leer Registros(4:xxxx)

Leer Registros (3:xxxx)

Escribir Bobina (0:xxxx)

Escribir Registro (4:xxxx)

Leer excepción

Escribir Bobinas (0:xxxx)

Escribir Registros (4:xxxx)

SignificadoPregunta el estado off-on de

bobinas logicas

Pregunta el estado off-on de entradas logicas

Pregunta el valos de registros almacenados

Pregunta el valos de registros de entradas

fuerza el estado de una bobina

Escribe una variable de almacenamiento

Pregunta el motivo del fallo

fuerza el estado de varias bobinas

Escribe varias variables de almacenamiento

Codigo

01

02

03

04

05

06

07

Tipo de error

Funcion ilegal

Direccion ilegal

Dato ilegal

Fallo en el dispositivo

Reconocimiento (ACK)

Ocupado

Reconocimiento Negativo (NAK)

Significadola funcion recivida no es

permitida por esclavo

La direccion esta fuera del rango

El dato contiene un valor no valido

El controlador no responde o ha ocurrido un error

Se ha aceptado la funcion y se esta procesando

El dispocitivo esta ocupado

La accion solicitada no puede procesarce en este momento



6.6 Direcciones de variables.

7 Ejemplos de códigos de funciones Función 01 o 02 ( 1 Read Coil Status - 2 Read Input Status ): Permite realizar la lectura del estado de las DI´s ( @1XXXX el comando 02-Read input status ) o DO´s ( @0XXXX el comando 01-Read Coil Status ). Para ello el maestro solicita el número de bits que desea leer a partir de una determinada dirección. Cada dirección se corresponde con un registro de 1 bit con el estado del la entrada digital. El esclavo responde indicando el número de byte que retorna y sus valores. En la trama de respuesta se aprovechan todos los bits del byte, y puede haber hasta 256 bytes. Petición del máster (modo RTU):

Función 03 o 04 ( 3 Read Holding Registers – 4 Read Input Registers ) : Permite realizar la lectura del valor analógicos almacenados ( @4XXXX el comando 3 Read Holding Registers ) o entradas analogas ( @3XXXX el comando 4 Read Input Registers ) . El máster indica la dirección base y número de registros a leer a partir de esta, mientras que el esclavo indica en la respuesta el número bytes retornados, seguido de estos valores. Aunque en realidad se está escribiendo en el rango de registros o valores numéricos, los registros son direccionados a partir de la dirección 0 ( así el registro @40001 se direcciona 0 )


Numero de esclavo

Codigo 0x01 o 0x2

Contador de byte de datos

Byte de datos (max 256)

CRC altos

CRC bajos

Consulta del maestro

Numero de esclavo

Codigo 0x01 o 0x2

Registro de direccion alto

Registro de direccion baja

Cantidad de bits altos

Cantidad de bits bajo

CRC altos

CRC bajos

Tipo variables

Salidas digitales

Entradas digitales

Variables almacenadas

Entradas analogicas

Mapa de direcciones

0x0000 a 0x9999

1x0000 a 1x9999

4x0000 a 4x9999

3x0000 a 3x9999



Ejemplo 1: Pregunta

Respuesta

Ejemplo 2: (variante con punto flotante, 32bits) Pregunta

Respuesta

01 03 01 00 00 06 C4 34

01 03 0C 20 81 00 00 00 00 00 00 00 00 1C 01 76 F1

0A Numero de esclavo

04 Codigo de funcion

00 00 Direccion de comienzo

00 0A Cantidad de registro

71 76 CRC


Numero de esclavo

Codigo 0x03 o 0x4

Contador de byte de datos

Byte de datos (max 128)

CRC altos

CRC bajos


Numero de esclavo

Codigo 0x03 o 0x4



Cantidad de bits altos

Cantidad de bits bajo

CRC altos

CRC bajos

0A 04 00 00 00 0A 71 76

0A 04 10 00 00 08 4D 00 0A 0F A0 00 00 00 90

00 00 00 60 CB 2E

0A Numero de esclavo

04 Codigo de funcion

10 Contador de byte

00 00 08 4D TENSION

00 0A OF A0 CORRIENTE

00 00 00 90 POTENCIA

00 00 00 60 FACTOR DE POTENCIA

CB 2E CRC



Función 05 (Force Single Coil): Permite modificar el estado de una DO del esclavo ( mando o relé ) . Es decir mediante este comando podemos modificar algún bit de alguna de las variables internas del esclavo u ordenar la ejecución o activación de un mando. Actúa sobre la zona de memoria de los DOs @0XXXX . El Maestro especifica la dirección del bit o mando que quiere modificar seguido de 0x00 para ponerlo a 0 o 0xFF para ponerlo a 1. El esclavo responde con una trama similar indicando la dirección que ha modificado y el valor que ha establecido en el bit o mando. Petición del máster (modo RTU): Estado para el bit: 0xXX ( 0x00 : 0 , 0xFF : 1 ) Ejemplo 1: Pregunta

Respuesta

Función 6 (Preset Single Register): Permite la escritura en las AOs del esclavo ( ya sea una señal o valor interno del equipo ), y por tanto actúa sobre la zona de memoria de las AOs ( @4XXXX ). Deberemos indicar la dirección del valor que queremos modificar y la magnitud que queremos asignarle. Luego el esclavo debería responder con la dirección del dato que ha modificado y el valor que le ha asignado, que debería coincidir con el enviado. Aunque en realidad se está escribiendo en el rango de AOs , los registros son direccionados a partir de la dirección 0 ( así el registro @40001 se direcciona 0 )

01 05 00 01 FF 00 DD FA


Numero de esclavo

Codigo 0x05



Estado para el bit altos (00)

Estado para el bit bajo (00 o FF)

CRC altos

CRC bajos


Numero de esclavo

Codigo 0x05





CRC altos

CRC bajos


Numero de esclavo

Codigo 0x06





CRC altos

CRC bajos


Numero de esclavo

Codigo 0x06





CRC altos

CRC bajos

01 05 00 01 FF 00 DD FA



Ejemplo 1: Pregunta

Respuesta

La respuesta es un eco de la pregunta para códigos 05 y 06 Función 7 ( Read Exception Status ) : Permite la lectura rápida de un byte fjo de un esclavo, que generalmente es el de excepción y que informa del estado del equipo. No tiene dirección del byte debido a que siempre se lee el mismo byte (determinado por el propio dispositivo esclavo) :

Función 15 (Force Multiple Coils): Permite la modificación simultanea de varios bits DO´s en el esclavo, pasándolos de OFF (‘0’) o a ON ( ‘1’) según convenga. Actúa sobre la zona de memoria de las salidas digitales (@0XXXX). Así en el comando se pasan la dirección inicial (dirección del primer bit o mando a modificar) y la cantidad y estado de cada uno de los sucesivos mandos (bits) a modificar.

Aunque el estado de las DOs se especifica bit a bit, las tramas se componen de bytes, y esto obliga a enviar los estados en grupos de 8. El esclavo no debería hacer caso a los bits sobrantes, es decir, no debería considerar los que queden por encima del último bit indicado en el campo “cantidad de mandos a modificar”.

01 06 01 F1 00 02 58 04

01 06 01 F1 00 02 58 04


Numero de esclavo

Codigo 0x07

CRC altos

CRC bajos


Numero de esclavo

Codigo 0x07

Valor de excepcion

CRC altos

CRC bajos


Numero de esclavo

Codigo 0x0F

Direccion del bit alto

Direccion del bit baja

Cantidad de bit altos

Cantidad de bit bajo

Cantidad de byte

Estado de los byte a modificar (x8)

CRC altos

CRC bajos


Numero de esclavo

Codigo 0x0F

Direccion del bit alto

Direccion de bit baja

Cantidad de bit altos

Cantidad de bit bajo

CRC altos

CRC bajos



El siguiente ejemplo muestra como forzar una serie de bit´s de salida comenzando desde la posición del registro de salida 20 (dirección 19 decimal o 13hexadecimal) en el esclavo 17. La consulta contiene dos byte de datos:

Hexadecimal

Binario Los bits modificaran las salidas de la siguiente forma Valor del bit

Posición

El primer byte trasmitido (CD hex) a las direcciones 27-20, el bit menos significativo corresponde a la dirección mas baja de los bits de salida (20) El siguiente byte trasmitido (01 hex) a las direcciones 29-28, el bit menos significativo corresponde a la dirección mas baja de los bits de salida (28). Los bits no usados se descartan sin importar si son 1 o 0. Función 16 ( Preset multiple registers ): Permite realizar la escritura en un grupo de AOs, y por tanto actúa sobre la zona de AOs (@4XXXX ). Se debe especificar la dirección a partir de la que queremos comenzar a actualizar valores, el número de valores que queremos actualizar, y la lista de valores que queremos asignar a estos registros. Aunque se está escribiendo en el rango de registros o valores numéricos , los registros son direccionados a partir de la dirección 0 ( es decir el registro @40001 se direcciona 0 ) Petición del máster (modo RTU):

CD 01

1100 1101 0000 0001

1 1 0 0 1 1 0 1 0 0 0 0 0 0 0 1

27 26 25 24 23 22 21 20 - - - - - - 29 28


Numero de esclavo

Codigo 0x10

Direccion de inicio alto

Direccion de inicio baja

Cantidad de registros altos

Cantidad de registros bajo

Cantidad de byte

Estado de los byte a modificar

........

CRC altos

CRC bajos


Numero de esclavo

Codigo 0x10

Direccion de inicio alto

Direccion de inicio baja

Cantidad del registros altos

Cantidad del registros bajo

CRC altos

CRC bajos



Practicas:

Prueba 1: Leer 16 salidas digitales desde la posición 100, del esclavo 55, en Modbus RTU Esta prueba la realizaremos entre dos PC, con las aplicaciones Modscan y Modsim (simulador Modbus RTU maestro y esclavo respectivamente). Los datos de los puertos seriales serán 9600-8n1 para todas las pruebas Vista de las pantallas de los software´s mencionados

Vista de software en comunicación



Prueba 2: Leer 50 entradas digitales desde la posición 65, del esclavo 155, en Modbus RTU Esta prueba la realizaremos entre dos PC, con las aplicaciones ASE2000 y Modsim (simulador Modbus RTU maestro y esclavo respectivamente).

Vista de las pantallas de los software´s mencionados

Vista de los software en comunicación



Prueba 3: Leer 5 variables almacenadas desde la posición 00, del esclavo 155, en Modbus RTU Esta prueba la realizaremos entre dos PC, con las aplicaciones Lookout y Modsim (simulador Modbus RTU maestro y esclavo respectivamente).





Prueba 4: Escribir 1 salida digital desde la posición 15, del esclavo 132, en Modbus RTU Esta prueba la realizaremos entre dos PC, con las aplicaciones ASE2000 y Modsim (simulador Modbus RTU maestro y esclavo respectivamente).





8 Biografías Manuales y libros

Modicon Modbus Protocol Reference Guide PI–MBUS–300 Rev. J Micro-motion-modbus-mapping.pdf Sistemas SCADA - Aquilino Rodríguez Penin

Páginas web

es.wikipedia.org/wiki/Modbus

www.modbus.org/

http://www.tolaemon.com/site/protocolo_modbus

http://www.ditel.es/manuales/obsoletos/reguladores/Modbus_Akros_Cas.pdf

http://www.modbus.org/

http://www.tolaemon.com/site/protocolo_modbus

http://www.ditel.es/manuales/obsoletos/reguladores/Modbus_Akros_Cas.pdf

Presentacion de Modbus

Documents

Transcript of Presentacion de Modbus