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

Conclusiones: El documento es una recopilación sobre distintas lecturas y practicas realizadas en mi incursión de aprendizaje 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. protoc olo. En el documento se trata de forma teórica y práctica una comunicación efectiva usando el protocolo, la idea fundamental del trabajo resi de en que los lectores verán distintas dis tintas configuraciones en forma práctica con s u 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 l a 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.

Modbus ASCII y RTU Versión Preliminar 07-2012


________________________________________________________________________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


12


13

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 pro tocolo en forma serial. Modbus fue desarrollado originalmente en su versión AS CII, 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-APPLPROTO. ) 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 d etectan 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

Modbus Ethernet

RTU

Modbus ASCII RS232

Controlador

Entradas /Salidas

Modbus RTU RS485

Medidor

Actuador

Válvula



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, l os 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 cam po 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: Pregunta desde el maestro

1

2

3

• Direccion del dispocitivo

• Codigo de funcion

• Datos

1

2

3

• Control de errores

4

• Direccion del dispocitivo

• Codigo de funcion

• Datos

• Control de errores

4

Respuesta del esclavo

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 p ara 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.



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 vali dez 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 p ará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:

Codificación del sistema

Los caracteres hexadecimales, ASCII 0-9, A-F Un carácter hexadecimal contenido en cada t rama ASCII

Bits por byte:

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

Campo de chequeo de

Chequeo de redundancia longitudinal (LRC)

error

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 mayo r 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.



El formato de cada byte en modo RTU es: Codificación del sistema

8-bit binario, hexadecimal 0-9, A-F Dos caracteres hexadecimales contenidos en cada campo de mensaje 8-bits

Bits por byte:

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

Campo de chequeo de

Chequeo de redundancia cíclica (CRC)

error 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.



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

Inicio •1 caract. •:

Direccion •2 caract.

Funcion •2 caract.

Datos •n caract.

Check error •2 caract

Fin •2 cacact •CR LF

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-T2T3-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ác ter 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.

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

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.



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 d atos 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 di ce 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 l a función. Esto puede incluir elementos como direcciones discretas o r egistro, la cantidad de variables que se manejan, y el recuento de bytes de da tos 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 inici al 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 a cció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. Modbus ASCII y RTU Versión Preliminar 07-2012


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 c ampo de la comprobación de errores contiene un implementado de 16-bits como dos bytes de 8 bits. El valor de verificación d e 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 d e 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

inicio

1

2

3

4

5

6

7

2

3

4

5

6

7

paridad

fin

Con Control de paridad

inicio

1

fin

fin

Sin control de paridad

El modo RTU sigue la secuencia de bits

inicio

1

2

3

4

5

6

7

8

2

3

4

5

6

7

8

paridad

fin

Con Control de paridad

inicio

1

fin

fin

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 Modbus ASCII y RTU Versión Preliminar 07-2012


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 i ntervalo 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 carac teres (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 utiliz a 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 mi smo 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 LR C comprueba el contenido del mensaje, sin c ontar 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, d escartando 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 ca mpo de comprobación de errores que se basa en una comprobación de redundancia cíclica (CRC). El campo CRC comprueba el contenido de Modbus ASCII y RTU Versión Preliminar 07-2012


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 d esplazamientos des cripta anteriormente. El contenido final del re gistro, 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 ref erencia a cero. La primera posición de memoria es cero. Modbus ASCII y RTU Versión Preliminar 07-2012


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 AS CII 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:

Nombre del campo

Ejemplo (hex)

Cabezera

Caracteres ASCII

Campo de 8 bitsRTU

:

Nada

Direccion de esclavo

10

10

0000 1010

Funcion

04

04

0000 0100

Direccion inicial HI

00

00

0000 0000

Direccion inicial LO

0B

0B

0000 1011

Nº de registros Hi

00

00

0000 0000

Nº de registros LO

03

03

0000 0011

Chequeo de error

LRC(2 caracteres)

CRC (16 bits)

Final

CR LF

Nada

17

8

Total Figura 8 Tramas de pregunta del maestro en ASCII y RTU



Nombre del campo

Ejemplo (hex)

Caracteres ASCII

Campo de 8 bitsRTU

:

Nada

Cabezera Direccion de esclavo

10

10

0000 1010

Funcion

04

04

0000 0100

Contador

06

06

0000 0110

Dato HI

02

02

0000 0010

Dato LO

0B

0B

0000 1011

Dato HI

30

30

0011 0000

Dato LO

0A

0A

0000 1010

Dato HI

00

00

0000 0000

Dato LO

65

65

0110 0101

Chequeo de error

LRC(2 caracteres)

CRC (16 bits)

Final

CR LF

Nada

23

11

Total

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



6.6 Direcciones de variables.

Tipo variables

Mapa de direcciones

Salidas digitales

0x0000 a 0x9999

Entradas digitales

1x0000 a 1x9999

Variables almacenadas

4x0000 a 4x9999

Entradas analogicas

3x0000 a 3x9999

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 d eterminada 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 byt es. Petición del máster (modo RTU): Consulta del maestro


Numero de esclavo

Numero de esclavo

Codigo 0x01 o 0x2

Codigo 0x01 o 0x2

Registro de direccion alto

Contador de byte de datos

Registro de direccion baja

Byte de datos (max 256)

Cantidad de bits altos

CRC altos

Cantidad de bits bajo

CRC bajos

CRC altos CRC bajos

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 by tes 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 )



Ejemplo 1: Pregunta 01

06

01

F1

00

02

58

04

01

F1

00

02

58

04

Respuesta 01

06

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) :

Consulta del maestro


Numero de esclavo

Numero de esclavo

Codigo 0x07

Codigo 0x07

CRC altos

Valor de excepcion

CRC bajos

CRC altos CRC bajos

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. Consulta del maestro


Numero de esclavo

Numero de esclavo

Codigo 0x0F

Codigo 0x0F

Direccion del bit alto

Direccion del bit alto

Direccion del bit baja

Direccion de bit baja

Cantidad de bit altos

Cantidad de bit altos

Cantidad de bit bajo

Cantidad de bit bajo

Cantidad de byte

CRC altos

Estado de los byte a modificar (x8)

CRC bajos

CRC altos CRC bajos

Aunque el estado de las DOs se especifica bi t 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”.



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 l as 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 l as aplicaciones Lookout y Modsim (simulador Modbus RTU maestro y esclavo respectivamente). Vista de las pantallas de los software´s mencionados




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). Vista de las pantallas de los software´s mencionados




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


Presentacion de Modbus

Recommend Documents