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
Introducción a 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
5.2 Comprobación de paridad
12
5.3 Comprobación de paridad
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
Modbus ASCII y RTU Versión Preliminar 07-2012
Introducción a Modbus
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.
Modbus ASCII y RTU Versión Preliminar 07-2012
Introducción a Modbus
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
Modbus ASCII y RTU Versión Preliminar 07-2012
Introducción a Modbus
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.
Modbus ASCII y RTU Versión Preliminar 07-2012
Introducción a Modbus
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.
Modbus ASCII y RTU Versión Preliminar 07-2012
Introducción a Modbus
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.
Modbus ASCII y RTU Versión Preliminar 07-2012
Introducción a Modbus
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.
Modbus ASCII y RTU Versión Preliminar 07-2012
Introducción a Modbus
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
Introducción a 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 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
Introducción a Modbus
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
Introducción a Modbus
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
Introducción a Modbus
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
Modbus ASCII y RTU Versión Preliminar 07-2012
Introducción a Modbus
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
Modbus ASCII y RTU Versión Preliminar 07-2012
Introducción a Modbus
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
Respuesta del esclavo
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 )
Modbus ASCII y RTU Versión Preliminar 07-2012
Introducción a Modbus
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
Respuesta del esclavo
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
Respuesta del esclavo
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”.
Modbus ASCII y RTU Versión Preliminar 07-2012
Introducción a Modbus
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
Modbus ASCII y RTU Versión Preliminar 07-2012
Introducción a Modbus
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
Modbus ASCII y RTU Versión Preliminar 07-2012
Introducción a Modbus
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
Vista de los software en comunicación
Modbus ASCII y RTU Versión Preliminar 07-2012
Introducción a Modbus
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
Vista de los software en comunicación
Modbus ASCII y RTU Versión Preliminar 07-2012
Introducción a Modbus
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
Modbus ASCII y RTU Versión Preliminar 07-2012