Adam 5000 tcp código de función 10 modbus. Todo sobre Modbus RTU con descripciones detalladas y ejemplos.

) para su uso en sus controladores lógicos programables. La especificación del protocolo se publicó por primera vez en 1979.

Era un estándar abierto que describía el formato de los mensajes y cómo se transmitían a través de una red formada por varios dispositivos electrónicos.

Originalmente, los controladores MODICON utilizaban la interfaz serie RS-232.

Posteriormente se empezó a utilizar la interfaz RS-485, ya que proporciona mayor confiabilidad, permite el uso de líneas de comunicación más largas y la conexión de varios dispositivos en una sola línea.

Muchos fabricantes de equipos electrónicos han apoyado el estándar y han aparecido en el mercado cientos de productos que lo utilizan. Actualmente, el desarrollo de Modbus lo lleva a cabo la organización sin fines de lucro Modbus-IDA, creada por fabricantes y usuarios de dispositivos electrónicos.

Introducción Modbus se refiere a los protocolos de capa de aplicación del modelo de red OSI. Los controladores en el bus Modbus se comunican mediante un modelo cliente-servidor basado en transacciones de solicitud y respuesta. Normalmente sólo hay un cliente en la red, el llamado cliente "principal". maestro

) dispositivo y varios servidores - "esclavos" (

esclavos

) dispositivos. El dispositivo maestro inicia transacciones (transmite solicitudes). Los dispositivos esclavos transmiten datos solicitados por el dispositivo maestro o realizan acciones solicitadas. El maestro puede dirigirse al esclavo individualmente o iniciar un mensaje de difusión a todos los esclavos. El dispositivo esclavo genera un mensaje y lo devuelve en respuesta a una solicitud dirigida específicamente a él. Cuando se recibe una solicitud de transmisión, no se genera ningún mensaje de respuesta.

La especificación Modbus describe la estructura de solicitudes y respuestas. Su base es un paquete de protocolo elemental, la llamada PDU (Unidad de datos de protocolo). La estructura de la PDU es independiente del tipo de enlace e incluye un código de función y un campo de datos. El código de función está codificado como un campo de un byte y puede tomar valores en el rango de 1...127. El rango de valores 128...255 está reservado para códigos de error. El campo de datos puede tener una longitud variable. El tamaño del paquete de la PDU está limitado a 253 bytes.

PDU Modbus

número de función< 253 (байт)

Para transmitir un paquete a través de enlaces físicos, la PDU se coloca dentro de otro paquete que contiene campos adicionales. Este paquete se llama ADU (Unidad de datos de aplicación). El formato ADU depende del tipo de línea de comunicación.

Existen tres implementaciones principales del protocolo Modbus, dos para transmitir datos a través de líneas de comunicación serie, ambas de cobre EIA/TIA-232-E (RS-232), EIA-422, EIA/TIA-485-A (RS-485) , y ópticas y radio:

• Modbus ASCII,

y para transmisión de datos a través de redes Ethernet a través de TCP/IP:

• Modbus TCP.

La estructura general de una ADU es la siguiente (dependiendo de la implementación, pueden faltar algunos de los campos):

• dirección esclava- dirección del dispositivo esclavo al que se dirige la solicitud. Los dispositivos esclavos responden sólo a las solicitudes que se les envían. La respuesta también comienza con la dirección del dispositivo esclavo que responde, que puede variar de 1 a 247. La dirección 0 se utiliza para la transmisión de difusión, cada dispositivo la reconoce, las direcciones en el rango 248...255 están reservadas;
• ) dispositivos. El dispositivo maestro inicia transacciones (transmite solicitudes). Los dispositivos esclavos transmiten datos solicitados por el dispositivo maestro o realizan acciones solicitadas. El maestro puede dirigirse al esclavo individualmente o iniciar un mensaje de difusión a todos los esclavos. El dispositivo esclavo genera un mensaje y lo devuelve en respuesta a una solicitud dirigida específicamente a él. Cuando se recibe una solicitud de transmisión, no se genera ningún mensaje de respuesta. es el siguiente campo de un byte del marco. Le dice al esclavo qué datos o acciones el maestro quiere que realice;
• La especificación Modbus describe la estructura de solicitudes y respuestas. Su base es un paquete de protocolo elemental, la llamada PDU (Unidad de datos de protocolo). La estructura de la PDU es independiente del tipo de enlace e incluye un código de función y un campo de datos. El código de función está codificado como un campo de un byte y puede tomar valores en el rango de 1...127. El rango de valores 128...255 está reservado para códigos de error. El campo de datos puede tener una longitud variable. El tamaño del paquete de la PDU está limitado a 253 bytes.- el campo contiene la información necesaria para que el dispositivo esclavo realice la función especificada por el maestro o contiene datos transmitidos por el dispositivo esclavo en respuesta a una solicitud del maestro. La longitud y el formato del campo dependen del número de función;
• bloque de detección de errores- suma de comprobación para comprobar la ausencia de errores en el marco.

El tamaño máximo de ADU para redes serie RS232/RS485 es de 256 bytes, para redes TCP: 260 bytes.

Para Modbus TCP ADU se ve así:

• ID de transacción- dos bytes, normalmente ceros
• identificación del protocolo- dos bytes, ceros
• longitud del paquete- dos bytes, alto y luego bajo, la longitud de la siguiente parte del paquete después de este campo
• dirección esclava- dirección del dispositivo esclavo al que se dirige la solicitud. Normalmente se ignora si la conexión es a un dispositivo específico. Se puede utilizar si la conexión se establece con un puente que nos lleve, por ejemplo, a una red RS485.

No hay ningún campo de suma de comprobación en Modbus TCP.

Categorías de códigos de función

La especificación del protocolo actual define tres categorías de códigos de función:

Comandos estándar Su descripción debe ser publicada y aprobada por Modbus-IDA. Esta categoría incluye códigos ya definidos y actualmente gratuitos. Comandos personalizados Dos rangos de códigos (65 a 72 y 100 a 110) para los cuales el usuario puede implementar una función personalizada. Sin embargo, no hay garantía de que algún otro dispositivo no utilice el mismo código para realizar una función diferente. Reservado Esta categoría incluye códigos de función que no son estándar, pero que ya se utilizan en dispositivos fabricados por varias empresas. Se trata de los códigos 9, 10, 13, 14, 41, 42, 90, 91, 125, 126 y 127.

modelo de datos

Uno de los usos típicos del protocolo es leer y escribir datos en los registros del controlador. La especificación del protocolo define cuatro tablas de datos:

Se accede a los elementos de cada tabla mediante una dirección de 16 bits, correspondiendo la primera celda a la dirección 0. Así, cada tabla puede contener hasta 65536 elementos. La especificación no define qué elementos de la tabla deben representar físicamente y en qué direcciones de dispositivos internos deben ser accesibles. Por ejemplo, es posible organizar tablas superpuestas. En este caso, las instrucciones que trabajan con datos discretos y con registros de 16 bits accederán a los mismos datos.

Cabe señalar que existe cierta confusión asociada con el método de tratamiento de los datos. Modbus se desarrolló originalmente para controladores Modicon. En estos controladores se utilizó una numeración especial para cada una de las tablas. Por ejemplo, el primer registro de entrada correspondía al número de celda 30001 y el primer registro de retención correspondía al 40001. Así, el registro de retención con dirección 107 en el comando Modbus correspondía al registro número 40108 del controlador. Aunque dicha coincidencia de direcciones ya no forma parte del estándar, algunos paquetes de software pueden "corregir" automáticamente las direcciones ingresadas por el usuario, por ejemplo restando 40001 de la dirección del registro de tenencia.

Funciones del protocolo Modbus estándar

PDU de solicitud y respuesta para funciones estándar

número funciones	solicitud/respuesta
1 (0x01)	un 1	Un 0	Pregunta 1	P 0
	norte	D (N bytes)
2 (0x02)	un 1	Un 0	Pregunta 1	P 0
	norte	D (N bytes)
3 (0x03)	un 1	Un 0	Pregunta 1	P 0
	norte	D (N bytes)
4 (0x04)	un 1	Un 0	Pregunta 1	P 0
	norte	D (N bytes)
5 (0x05)	un 1	Un 0	re 1	D0
	un 1	Un 0	re 1	D0
6 (0x06)	un 1	Un 0	re 1	D0
	un 1	Un 0	re 1	D0
15 (0x0F)	un 1	Un 0	Pregunta 1	P 0	norte	D (N bytes)
	un 1	Un 0	Pregunta 1	P 0
16 (0x10)	un 1	Un 0	Pregunta 1	P 0	norte	D (N bytes)
	un 1	Un 0	Pregunta 1	P 0

• un 1 Y Un 0- dirección del elemento,
• Pregunta 1 Y P 0- número de elementos,
• norte- número de bytes de datos
• D- datos

Leyendo datos

Para leer valores de las tablas de datos enumeradas anteriormente, use funciones con códigos 1-4 (valores hexadecimales 0x01-0x04):

• 1 (0x01)- leer valores de varios registros de banderas (Leer estado de la bobina)
• 2 (0x02)- leer valores de varios registros discretos (Leer entradas discretas)
• 3 (0x03)- leer valores de múltiples registros de almacenamiento (Leer registros de tenencia)
• 4 (0x04)- leer valores de múltiples registros de entrada (Leer registros de entrada)

La solicitud consta de la dirección del primer elemento de la tabla cuyo valor se va a leer y el número de elementos que se van a leer. La dirección y la cantidad de datos se especifican como números de 16 bits; el byte más significativo de cada uno se transmite primero.

La respuesta contiene los datos solicitados. La cantidad de bytes de datos depende de la cantidad de elementos solicitados. Antes de los datos, se transmite un byte, cuyo valor es igual al número de bytes de datos.

Los valores de los registros de retención y de los registros de entrada se transfieren a partir de la dirección especificada, dos bytes por registro, el byte más significativo de cada registro se transfiere primero:

byte 1	byte 2	byte 3	byte 4	...	byte N-1	byte norte
RA,1	RA,0	R A+1,1	RA+1.0	...	R A+Q-1,1	R A+Q-1.0

Los valores de banderas y entradas discretas se transmiten en forma empaquetada: un bit por bandera. Uno significa encendido, cero significa apagado. Los valores de las banderas solicitadas llenan primero el primer byte, comenzando por el bit menos significativo, luego los siguientes bytes, también desde el bit menos significativo hasta el más significativo. El bit menos significativo del primer byte de datos contiene el valor del indicador especificado en el campo "dirección". Si el número de banderas solicitadas no es múltiplo de ocho, entonces los valores de los bits adicionales se completan con ceros:

byte 1								...	byte norte
F A+7	F A+6	F A+5	F A+4	F A+3	F un+2	F un+1	F.A.	...	0	...	0	F A+Q-1	F A+Q-2	...

Grabar un solo valor

• 5 (0x05)- registrar el valor de una bandera (Fuerza de bobina simple)
• 6 (0x06)- escribir un valor en un registro de almacenamiento (Registro único preestablecido)

El comando consta de la dirección del elemento (2 bytes) y el valor a establecer (2 bytes).

Para un registro de retención, el valor es simplemente una palabra de 16 bits.

Para las banderas, el valor 0xFF00 significa habilitado, 0x0000 significa deshabilitado, otros valores no son válidos.

Si el comando tiene éxito, el esclavo devuelve una copia de la solicitud.

Grabar múltiples valores

• 15 (0x0F)- escribir valores en varios registros de banderas (Forzar múltiples bobinas)
• 16 (0x10)- escribir valores en varios registros de almacenamiento (Registros múltiples preestablecidos)

El comando consta de la dirección del elemento, el número de elementos que se van a cambiar, el número de bytes de los valores establecidos transmitidos y los valores establecidos en sí. Los datos se empaquetan de la misma manera que en los comandos de lectura de datos.

La respuesta consta de la dirección inicial y el número de elementos modificados.

A continuación se muestra un ejemplo de un comando maestro y una respuesta de esclavo (para Modbus RTU).

Monitoreo de errores en el protocolo Modbus RTU

Pueden ocurrir dos tipos de errores durante el intercambio de datos:

• errores asociados con distorsiones durante la transmisión de datos;
• errores lógicos.

Los errores de tipo 1 se detectan mediante tramas de caracteres, paridad y la suma de comprobación cíclica CRC-16-IBM (utilizando el número polinómico = 0xA001).

marco RTU

En el modo RTU, el mensaje debe comenzar y terminar con un intervalo de silencio: un tiempo de transmisión de al menos 3,5 caracteres a una velocidad de red determinada. El primer campo transmite entonces la dirección del dispositivo.

Al último carácter transmitido le sigue también un intervalo de silencio de al menos 3,5 caracteres. Después de este intervalo puede comenzar un nuevo mensaje.

El telegrama se transmite continuamente. Si se produce un intervalo de silencio de 1,5 de duración durante la transmisión de una trama, el dispositivo receptor DEBE ignorar la trama como incompleta.

Por lo tanto, un nuevo mensaje no debe comenzar antes de intervalos de 3,5, porque en este caso se establece un error.

Un poco de intervalos (estamos hablando de Serial Modbus RTU): a una velocidad de 9600 y 11 bits por cuadro (bit de inicio + 8 bits de datos + bit de paridad + bit de parada): 3,5 * 11 / 9600 = 0,00401041(6), aquellos. más de 4 ms; 1,5 * 11 / 9600 = 0,00171875, es decir más de 1ms. Para velocidades superiores a 19200 baudios, se permite utilizar intervalos de 1,75 y 0,75 ms, respectivamente.

Errores lógicos

Para el segundo tipo de mensajes de error, el protocolo Modbus RTU prevé que los dispositivos puedan enviar respuestas indicando una situación de error. Una indicación de que la respuesta contiene un mensaje de error es que el bit más significativo del código de comando está configurado. En la (Tabla 2-1) se proporciona un cuadro de ejemplo cuando un dispositivo esclavo detecta un error en respuesta a una solicitud.

1. Si Slave recibe una solicitud válida y puede procesarla normalmente, devuelve una respuesta normal.

2. Si el Esclavo no acepta ningún valor, no se envía ninguna respuesta. El maestro diagnostica el error por tiempo de espera.

3. Si el esclavo acepta la solicitud pero encuentra un error (paridad, LRC o CRC), no se envía ninguna respuesta. El maestro diagnostica el error por tiempo de espera.

4. Si el Esclavo acepta una solicitud, pero no puede procesarla (accediendo a un registro inexistente, etc.), se envía una respuesta que contiene datos de error.

Tabla 2-1. Trama de respuesta (Esclavo→Maestro) cuando ocurre un error modbus RTU

Dirección de transmisión	dirección esclava	) dispositivos. El dispositivo maestro inicia transacciones (transmite solicitudes). Los dispositivos esclavos transmiten datos solicitados por el dispositivo maestro o realizan acciones solicitadas. El maestro puede dirigirse al esclavo individualmente o iniciar un mensaje de difusión a todos los esclavos. El dispositivo esclavo genera un mensaje y lo devuelve en respuesta a una solicitud dirigida específicamente a él. Cuando se recibe una solicitud de transmisión, no se genera ningún mensaje de respuesta.	datos (o código de error)	CDN

En la Lección 48, mostré un ejemplo de un protocolo de intercambio de datos no estándar a través de la interfaz UART. Como siempre, todo lo no estándar permite optimizar la ejecución de una tarea, y todo lo universal simplifica el desarrollo de una tarea.

Existe un protocolo de comunicación ModBus sencillo y universal en el que la redundancia de datos y funciones se mantiene al mínimo. Este es probablemente el protocolo más común para organizar pequeños sistemas distribuidos. En lecciones posteriores implementaré el intercambio de datos entre dispositivos que utilicen este protocolo.

Descripción general del protocolo.

ModBus es un protocolo abierto para el intercambio de datos en pequeñas redes locales. Normalmente se utiliza para transmitir datos a través de interfaces RS-232, RS-485, RS-422, en redes TCP/IP, UDP. Debido a su simplicidad y versatilidad, ModBus se ha generalizado y se ha convertido en el estándar de facto en pequeños sistemas informáticos distribuidos. Casi todos los controladores modernos admiten redes ModBus.

En una red ModBus, los controladores generalmente se conectan mediante una topología de "Bus común". La interacción de los controladores se produce de acuerdo con el modelo maestro-esclavo (maestro-esclavo).

Hay un dispositivo principal en la red: el maestro. Y también varios dispositivos esclavos: esclavos. El intercambio sólo puede ser iniciado por el dispositivo maestro.

Una transacción (una secuencia de operaciones durante el intercambio de datos) consta de una solicitud y una respuesta.

El dispositivo maestro puede dirigir la solicitud a cualquier controlador esclavo o iniciar un mensaje de transmisión a todos los dispositivos esclavos simultáneamente.

El dispositivo esclavo, habiendo determinado su dirección en la solicitud, genera una respuesta.

La solicitud del dispositivo maestro debe contener un código de función, es decir lo que hay que hacer. Además, dependiendo de la función, la solicitud puede contener datos.

Hay 3 variantes del protocolo ModBus.

• ModBus ASCII – protocolo de texto. Utiliza sólo caracteres ASCII. Cada byte se transmite como dos caracteres hexadecimales.
• ModBus RTU es un protocolo numérico. Los datos se transmiten en forma binaria. El byte transmitido a través de la red es el número de protocolo.
• ModBus TCP es un protocolo para la transmisión de datos en redes TCP/IP.

Comparé los protocolos numéricos y de texto en . En términos de rendimiento y velocidad de intercambio, los protocolos numéricos ciertamente tienen una ventaja. En las próximas lecciones usaremos ModBus RTU. La siguiente información en esta lección está dedicada a esta opción.

Protocolo ModBus RTU.

Los dispositivos (controladores) se conectan a la red mediante la topología de "Bus común". El estándar ModBus permite que hasta 247 controladores funcionen juntos.

De hecho, cada controlador contiene datos que los dispositivos intercambian.

El estándar ModBus define 4 tipos de datos.

tipo de datos	Tamaño	Operaciones válidas
Registro de bandera (Bobinas)	1 poco	escribir y leer
Entradas discretas	1 poco	Lectura
Registros de tenencia	16 bits	escribir y leer
Registros de entrada	16 bits	Lectura

Esta separación funcional de datos se ha borrado y prácticamente no se utiliza. En última instancia, todos los datos se leen de la memoria del controlador y no es tan importante dónde llegaron desde las entradas o desde los registros de entrada.

En la práctica, sólo se utilizan estos Registros de Tenencia. Se accede a los datos a través de una dirección de 16 bits. Como resultado:

• los datos de cada controlador son una tabla de registros de 16 bits;
• la tabla de datos puede tener hasta 65536 elementos;
• La numeración de elementos comienza desde 0.

El dispositivo maestro inicia una transacción: intercambio de datos. La transacción puede ser individual (solicitud-respuesta) o de difusión (todos los dispositivos esclavos se abordan simultáneamente). Una transacción consta de un marco de solicitud y un marco de respuesta. En una transacción de difusión, sólo se utiliza el marco de solicitud.

Los datos del cuadro se transmiten como un flujo continuo. La pausa entre la transmisión de datos no debe exceder el tiempo de transmisión de 1,5 caracteres. Un signo de una nueva trama es la ausencia de intercambio en la red (silencio) durante el tiempo necesario para la transmisión de 3,5 caracteres. Si durante este tiempo la línea de red estuvo en estado inactivo, los dispositivos esclavos perciben los primeros datos recibidos como el comienzo de la trama.

En general, un marco de solicitud tiene el siguiente formato.

Dirección (8 bits).

La trama comienza con un campo de dirección que consta de 8 bits. Contiene la dirección del dispositivo esclavo al que está destinado el mensaje del maestro. Cada dispositivo esclavo debe tener una dirección única del 1 al 247. Y solo el dispositivo esclavo direccionable debe responder a la solicitud del maestro. La respuesta le dice al maestro qué esclavo se está comunicando.

La dirección 0 se utiliza en modo de transmisión. Todos los esclavos realizan la función especificada en la solicitud, pero no envían un acuse de recibo.

Función (8 bits).

El campo de función le dice al esclavo direccionado qué operación realizar.

El bit más significativo del byte de función se establece en 1 en la respuesta del esclavo para informar al maestro que la operación se completó por error. Si la operación tiene éxito, el bit más significativo es 0.

• Comandos estándar. Códigos definidos por el estándar del protocolo ModBus.
• Comandos personalizados. Para los códigos 65...72 y 100...110, el usuario puede asignar una función arbitraria.
• Equipos reservados. Se trata de códigos que originalmente no estaban definidos por la norma, pero que ya se utilizan en dispositivos de diferentes fabricantes.

La gran mayoría de controladores ModBus utilizan sólo 3 funciones.

El formato de respuesta depende de la función. En muchos casos, una respuesta normal repite la solicitud total o parcialmente.

Datos (N * 8 bits).

El campo de datos contiene la información necesaria para que el controlador esclavo realice una función determinada, o el campo contiene datos transmitidos por el dispositivo esclavo a solicitud del maestro. La longitud y el formato del campo de datos dependen del código de función. Es posible que a algunos mensajes les falten datos.

Cada dato tiene 16 bits (2 bytes). Los datos se transmiten primero en el byte más significativo. Por ejemplo, la transferencia secuencial de registros con direcciones 0 y 1 debería ocurrir de la siguiente manera:

• byte alto del registro 0 ->
• byte bajo del registro 0 ->
• byte alto del registro 1 ->
• byte bajo del registro 1 ->.

Al transmitir un número de 4 bytes, por ejemplo en coma flotante, la secuencia es la misma. El número se divide en dos registros de 16 bits y en cada uno de ellos se transmite primero el byte más significativo (1->0->3->2->).

Suma de comprobación (16 bits).

Campo de control de integridad de datos del mensaje. Le permite comprobar los fotogramas en busca de errores. Estamos hablando de errores que aparecen durante la transferencia de datos.

Intentaré dar una descripción general del código de control. Es mejor saltarse este párrafo. Podría romperse la cabeza. Cuando toco este tema siempre me duele la cabeza. En el próximo tutorial presentaré una implementación práctica del cálculo del código de control ModBus.

El código de redundancia cíclica (CRC) se utiliza como suma de comprobación. Todos los bits de una trama de transmisión se agrupan en un enorme número binario. Se divide por el código del polinomio generador. El resto de la división es el código de control.

Se utiliza aritmética polinomial módulo 2. Esto significa que todas las acciones al calcular CRC son operaciones aritméticas sin acarreo. La resta y la suma ocurren bit a bit, sin tener en cuenta el acarreo, por lo que estas operaciones dan el mismo resultado y pueden ser reemplazadas por la operación "exclusiva o". Al dividir, en lugar de restar el divisor al dividendo, también se utiliza la operación “o exclusivo”. Este es el principio general para calcular el CRC. En la práctica, los cálculos se realizan utilizando algoritmos más eficientes.

La suma de control finaliza la trama de transmisión. Una vez recibida la trama, el dispositivo esclavo, utilizando el mismo algoritmo, calcula la suma de verificación de los datos recibidos y la compara con el código de verificación transmitido al final de la trama. Como resultado, se confirma la integridad de los datos del marco.

El estándar ModBus RTU utiliza el código cíclico estándar CRC-16 con un polinomio generador X 16 +X 15 +X 2 +1. Este es un código de 16 bits, los coeficientes binarios son 1 1000 0000 0000 0101 (8005h en hexadecimal).

El mensaje se trata como un número binario secuencial en el que el bit más significativo se transmite primero. Este número se multiplica por X 16 (desplazado a la izquierda 16 lugares) y se divide por X 16 +X 15 +X 2 +1 (1 1000 0000 0000 0101). El resto de 16 bits (preinicializado con todos unos) es el código de control del mensaje.

Manejo de errores lógicos.

Además de los errores asociados con la corrupción de datos durante la transmisión, pueden ocurrir errores lógicos cuando una solicitud se recibe sin errores, pero no se puede ejecutar. Normalmente, estos errores están asociados con direcciones, datos, códigos, etc. no válidos. La mayoría de los controladores ModBus admiten los siguientes tipos de errores.

código de error	Nombre	Descripción
01	FUNCIÓN ILEGAL	Código de función no compatible con el controlador
02	DIRECCIÓN DE DATOS ILEGALES	Dirección de datos no válida
03	VALOR DE DATOS ILEGAL	Valores de datos no válidos
04	FALLO DEL DISPOSITIVO ESCLAVO	Se produjo un error al realizar la operación.

Si se produce un error en la respuesta, el bit más significativo se establece en el campo del código de función y luego se transmite el código de error en lugar de los datos habituales.

Examen detallado de funciones.

Función 03: leer registros de retención.

Se utiliza para leer los valores de múltiples registros de tenencia. La solicitud transmite la dirección del primer elemento de la tabla de registros, cuyo valor debe leerse y el número de registros que deben leerse. Se utilizan números de 16 bits para la dirección y la cantidad. El byte más significativo se transmite primero.

Los datos solicitados están contenidos en la respuesta. Antes del bloque de datos se transmite un byte que contiene el número de datos leídos en bytes.

Formato de solicitud para la función de lectura de registros de almacenamiento.

número de byte	Número de byte en el parámetro	Parámetro
0	0	Dirección del controlador	01	01
1	0	Función	03	03
2	1	Dirección inicial de registros	0008	00
3	0			08
4	1	Número de registros	0002	00
5	0			02
6	1	Suma de comprobación	45C9	45
7	0			C9

Respuesta (dirección del esclavo, código de función, número de bytes leídos, valores de registro).

número de byte	Número de byte en el parámetro	Parámetro	Ejemplo de lectura de registros con direcciones 8 y 9
0	0	Dirección del controlador	01	01
1	0	Función	03	03
2	0	Número de bytes leídos	04	04
3	1	Valor de registro 8	12A5	12
4	0			A5
5	1	Valor de registro 9	E020	E0
6	0			20
7	1	Suma de comprobación	A770	A7
8	0			70

Función 06: escribir en un registro de retención.

Se utiliza para escribir en un solo registro. La solicitud pasa la dirección del registro y su valor. Si tiene éxito, el controlador esclavo responde con una copia de la solicitud.

Formato de solicitud de función de escritura de registro de retención único.

número de byte	Número de byte en el parámetro	Parámetro
0	0	Dirección del controlador	01	01
1	0	Función	06	06
2	1	Dirección de registro	0009	00
3	0			09
4	1	Valor de registro	12A5	12
5	0			A5
6	1	Suma de comprobación	9513	95
7	0			13

Responder (repite la solicitud).

número de byte	Número de byte en el parámetro	Parámetro	Un ejemplo de cómo escribir el valor 12A5 en el registro 9
0	0	Dirección del controlador	01	01
1	0	Función	06	06
2	1	Dirección de registro	0009	00
3	0			09
4	1	Valor de registro	12A5	12
5	0			A5
6	1	Suma de comprobación	9513	95
7	0			13

Función 16: escribir valores en registros de almacenamiento.

Se utiliza para escribir en varios registros ubicados secuencialmente en una tabla.

La solicitud transmite la dirección del primer registro, el número de registros y los valores de los mismos.

La respuesta devuelve la dirección inicial y el número de registros modificados.

Formato de solicitud para la función de escritura del registro de almacenamiento.

número de byte	Número de byte en el parámetro	Parámetro
0	0	Dirección del controlador	01	01
1	0	Función	10	10
2	1	Dirección inicial de registros	0008	00
3	0			08
4	1	Número de registros	0002	00
5	0			02
6	0	Contador de bytes	04	04
7	1	Valor de registro 8	12A5	12
8	0			A5
9	1	Valor de registro 9	E020	E0
10	0			20
11	1	Suma de comprobación	AF4A	A. F.
12	0			4A

Respuesta (dirección del esclavo, código de función, dirección inicial y número de registros).

número de byte	Número de byte en el parámetro	Parámetro	Ejemplo de escritura de registros con direcciones 8 y 9.
0	0	Dirección del controlador	01	01
1	0	Función	10	10
2	1	Dirección inicial de registros	0008	00
3	0			08
4	1	Número de registros	0002	00
5	0			02
6	1	Suma de comprobación	C00A	C0
7	0			0A

ModBus y protocolos especializados.

Ahora puedes comparar el protocolo ModBus con un protocolo especializado de .

número de byte	Formato de número	Objetivo
0 … 3	flotar	Temperatura
4 … 7	flotar	Voltaje
8	byte	Estado del botón
9	byte	Reservar
10, 11	entero	Suma de comprobación (suma de bytes 0...9^0xa1e3)

Comparado con un protocolo dedicado:

• ModBus es más lento y tiene menor rendimiento. Para obtener la misma cantidad de información, se transmiten muchos más datos a través de la red.
• Su implementación es más difícil. Requiere más microcontroladores y recursos de red.

Pero las ventajas son en muchos casos más significativas.

• Debido a una suma de verificación más compleja y a información redundante, los errores de red se determinan de manera más confiable y la confiabilidad de los datos es mayor.
• La red se expande fácilmente. Es muy fácil agregar nuevos dispositivos.
• ModBus es un protocolo estándar. Muchos controladores de diferentes fabricantes lo admiten.

Quizás la razón principal para utilizar protocolos no estándar sean los recursos informáticos insuficientes del sistema.

Es cierto que existe otra razón para utilizar un protocolo no estándar. Incluso, gracias a lo cual nuestra empresa ganó una importante licitación. Nadie más que los desarrolladores podrá conectarse a dispositivos con un protocolo especializado y controlarlos. Aquellos. calidad completamente opuesta a los protocolos estándar. Está vigente la ley filosófica de la unidad de los opuestos.

En la próxima lección implementaremos la comunicación entre la placa Arduino y una computadora usando el protocolo ModBus.

Categoría: . Puedes marcarlo como favorito.

Una de las ventajas de Modbus es la ausencia de la necesidad de controladores de interfaz especiales (Profibus y CAN requieren chips personalizados para su implementación), la simplicidad de la implementación del software y la elegancia de los principios operativos. Todo esto reduce el costo de dominar el estándar tanto para los integradores de sistemas como para los desarrolladores de equipos de control. El alto grado de apertura del protocolo también está garantizado por textos estándar completamente gratuitos, que se pueden descargar desde el sitio web www.modbus.org.

En Rusia, Modbus compite únicamente con Profibus en términos de prevalencia. La popularidad del protocolo actualmente se debe, en primer lugar, a la compatibilidad con una gran cantidad de equipos que cuentan con el protocolo Modbus. Además, Modbus tiene una alta confiabilidad en la transmisión de datos debido al uso de un método confiable de control de errores. Modbus permite unificar comandos de intercambio estandarizando los números de registro (direcciones) y sus funciones de lectura y escritura.

La principal desventaja de Modbus es la conexión en red maestro/esclavo, que no permite que los esclavos transmitan datos a medida que están disponibles y, por lo tanto, requiere un sondeo intensivo de los esclavos por parte del maestro.

Las variedades de Modbus son los protocolos Modbus Plus [Modicon], un protocolo multimaestro con transferencia en anillo de un token y Modbus TCP[Modbus], diseñado para uso en redes Ethernet e Internet.

El protocolo Modbus tiene dos modos de transmisión: RTU (Unidad Terminal Remota) y ASCII. El estándar estipula que el modo RTU en el protocolo Modbus debe estar presente y el modo ASCII es opcional. El usuario puede seleccionar cualquiera de ellos, pero todos los módulos incluidos en la red Modbus deben tener el mismo modo de transmisión.

Consideraremos solo el protocolo Modbus RTU, ya que Modbus ASCII prácticamente no se utiliza en Rusia. Tenga en cuenta que Modbus ASCII no debe confundirse con el protocolo propietario DCON, que se utiliza en los módulos Advantech e ICP DAS y no cumple con el estándar Modbus.

El estándar Modbus prevé el uso de una interfaz física RS-485, RS-422 o RS-232. La más común para organizar una red industrial es la interfaz RS-485 de 2 hilos. Para conexiones punto a punto, se puede utilizar la interfaz RS-232 o RS-422.

El estándar Modbus incluye obligatorio requisitos, recomendado Y opcional(opcional). Hay tres grados de cumplimiento de la norma: “totalmente conforme” - cuando el protocolo cumple con todos los requisitos obligatorios y recomendados, “condicionalmente conforme” - cuando el protocolo cumple solo con los requisitos obligatorios y no cumple con los recomendados, y “no no cumplir”.

El modelo OSI del protocolo Modbus contiene tres capas: física, canal y aplicación.

De forma predeterminada, en el modo RTU, el bit de paridad se establece en 1 si el número de unos binarios en un byte es impar y en 0 si es par. Esta paridad se llama paridad par y el método de control se llama control de paridad. bit de inicio bit de paridad Arroz. 2.26. Secuencia de bits en modo RTU; LSB: dígito menos significativo. Si no hay un bit de paridad, se escribe un segundo bit de parada en su lugar. Con un número par de unos binarios en un byte bit de paridad puede ser igual a 1. En este caso, se dice que la paridad es impar (paridad impar). Es posible que no haya ningún control de paridad. En este caso, se debe utilizar un segundo bit de parada en lugar del bit de paridad. Para garantizar la máxima compatibilidad con otros productos, se recomienda utilizar la opción de reemplazar el bit de paridad con un segundo bit de parada. Los dispositivos esclavos pueden aceptar cualquiera de las opciones: incluso, paridad impar o falta del mismo. Estructura de mensajes Modbus RTU Los mensajes Modbus RTU se transmiten en forma de tramas, cada una de las cuales tiene un principio y un final conocidos. Una señal del comienzo de una trama es una pausa (silencio) que dura al menos 3,5 caracteres hexadecimales (14 bits). La trama debe transmitirse continuamente. Si se detecta una pausa de más de 1,5 caracteres hexadecimales (6 bits) durante la transmisión de la trama, se considera que la trama contiene un error y debe ser rechazada por el módulo receptor. Estos valores de pausa deben respetarse estrictamente a velocidades inferiores a 19200 bps, pero a velocidades más altas se recomienda utilizar valores de pausa fijos de 1,75 ms y 750 µs respectivamente. Control de errores En el modo RTU existen dos niveles de control de errores de mensajes: control de paridad para cada byte (opcional); control del marco en su conjunto mediante el método CRC. Los bits de inicio, parada y paridad no participan en el cálculo del CRC. 2.8.3. Capa de aplicación La capa de aplicación Modbus RTU versión 1.1a se describe en [Modbus]. Permite la comunicación entre dispositivos maestro/esclavo. La capa de aplicación es independiente del canal físico y, en particular, puede utilizar Ethernet TCP/IP (Modbus TCP/IP), Modbus Plus (red multimaestro con paso de token), RS-232, RS-422, RS. -485, fibra óptica, canales de radio y otros medios físicos para la transmisión de señales. La capa de aplicación Modbus se basa en solicitudes utilizando códigos de función. El código de función le dice al esclavo qué operación debe realizar. Cuando se utiliza un protocolo de capa de aplicación con diferentes protocolos de capa de transporte y enlace, el bloque principal del mensaje Modbus, incluidos el código de función y los datos, permanece sin cambios (este bloque se llama PDU- "Unidad de datos de protocolo" - "elemento de datos de protocolo"). Se pueden agregar campos adicionales a la PDU cuando se usa en varias redes industriales y luego se llama " ADU" - "Unidad de datos de la aplicación" - "elemento de datos de la aplicación". Códigos de función El estándar Modbus proporciona tres categorías de códigos de función: estándar, definido por el usuario y reservado. Los códigos de función son números que van del 1 al 127. Los códigos del 65 al 72 y del 100 al 110 son funciones definidas por el usuario, y los del 128 al 255 están reservados para enviar códigos de error en el mensaje de respuesta. El código "0" no se utiliza. El esclavo utiliza los códigos de error para determinar qué acción tomar para manejarlos. El significado de los códigos y su significado se describen en el estándar Modbus RTU [Modbus]. Designación de registro Dirección de registro HEX Lo que se lee o escribe Registrar código de función de lectura Registrar escribir código de función Nota Desct. salida 0 Desct. salida 1 Desct. entrada 0 Desct. entrada 1 Desct. entrada 2 Desct. entrada 3 Desct. entrada 4 Desct. entrada 5 Desct. entrada 6 Desct. entrada 7 Desct. entrada 8 Desct. entrada 9 Desct. entrada 10 Desct. entrada 11 Desct. entrada 12 Desct. entrada 13 Desct. entrada 14 Desct. entrada 15 Nombre del módulo Versión del programa Dirección del módulo 0001h-00 F7h (rango de valores permitido) velocidad UART (Rango de valores aceptable) Protocolo 0000h–ASCII, Valor de salida después de encender la fuente de alimentación del módulo Power On Value0 0000h-0003h (rango de valores)

6.3. Serie MODBUS

Las primeras redes MODBUS se basaban en líneas de comunicación serie asíncronas y se denominaban MODBUS-RTU Y MODBUS-ASCII . A nivel físico, utilizan interfaces serie estándar con modo de transmisión de caracteres (ver Fig. 6.1).

Actualmente, en MODBUS-IDA estas redes se denominan MODBUS sobre línea serie y se describen en la norma correspondiente. Especifica las reglas y recomendaciones para su uso en el enlace y en las capas físicas.

Dado que una red MODBUS RTU/ASCII puede tener una topología de bus, el método de acceso al bus se define como modelo Maestro/Esclavo. En las redes MODBUS RTU y MODBUS ASCII, el Proceso Maestro es siempre el Cliente y los Procesos Esclavos son los Servidores. Esto significa que el Maestro envía solicitudes y los Esclavos las procesan. Esta solicitud puede dirigirse tanto a un nodo individual como a todos los esclavos del bus (difusión).

La capa de enlace de datos MODBUS RTU/ASCII utiliza direccionamiento orientado al identificador de nodo.Cada Esclavo debe tener su propia dirección única (1-247), el Maestro no es direccionable. Para solicitudes individuales, el Líder (con el Proceso del cliente) forma un marco con un mensaje de solicitud y lo envía a la dirección especificada. El esclavo (con el proceso del servidor) recibe esta trama y procesa el mensaje. Después de procesarlo, el Esclavo forma una trama con un mensaje de respuesta y lo envía de vuelta al Líder. La trama con el mensaje de respuesta también funciona como trama de confirmación, que el Maestro esperará del Esclavo durante el tiempo especificado en el tiempo de espera.

Para solicitudes de transmisión, se utiliza la dirección 0. Las solicitudes de transmisión no requieren confirmación, por lo que después de enviar una trama de transmisión, el maestro no espera una trama de respuesta.

6.3.1. Capa de enlace de datos

La Figura 6.11 muestra la vista general del bastidor MODBUS Serial. Tenga en cuenta que la delimitación de trama y el tipo de suma de comprobación no se especifican aquí ya que depende del modo de transmisión ASCII o RTU. En el campo de dirección del dispositivo, el Maestro (al solicitar) indica la dirección del destinatario y el Esclavo (al responder), su dirección. Los campos de MODBUS PDU se describen arriba.

El diagrama de tiempos de la Fig. 6.12 muestra tres situaciones típicas de funcionamiento del modelo Maestro-Esclavo en MODBUS Serie. La primera situación es un intercambio típico en modo unicast, la segunda es en modo broadcast, la tercera es la reacción del Slave ante un error de comunicación.

6.3.2. MODBUS-RTU

Este modo utiliza 8 bits de datos en un símbolo de 11 bits, lo que le permite transferir un byte por símbolo. Formato de caracteres en modo RTU: 1 bit de inicio, 8 bits de datos (el bit bajo se transmite primero), 1 bit de paridad + 1 bit de parada bits o sin paridad + 2 bits de parada.

El formato de trama MODBUS RTU se muestra en la Figura 6.13. La distinción entre fotogramas se realiza mediante pausas entre personajes. Una nueva trama no debe aparecer en el bus antes de 3,5 * Тс de la anterior, donde Тс es el tiempo de transmisión de un carácter. Si la ausencia de señal en la línea (intervalo de silencio) es superior a 1,5 * Tc, el receptor identifica el final de la trama. Por otro lado, la aparición de un nuevo cuadro anterior a 3,5 * Tc también dará lugar a un error.

Los campos de dirección y código de función en modo RTU ocupan un byte cada uno, ya que cada byte se transmite como un carácter. Como suma de comprobación se utilizan dos bytes calculados mediante el algoritmo CRC16.

6.3.3. MODBUS-ASCII

En este modo, cada byte del mensaje se transmite como dos caracteres ASCII de su representación hexadecimal, es decir. el valor del byte 03 16 se transmitirá como código ASCII de los caracteres "0" y "3" (0110000 0110011) Por lo tanto, los bytes de datos, el código de función y el byte del campo de verificación se transmitirán en códigoscaracteres 0-9, A-F. Formato de caracteres en modo ASCII: 1 bit de inicio, 7 bits de datos (el bit menos significativo se transmite primero); 1 bit de paridad + 1 bit de parada o sin paridad + 2 bits de parada.

El formato del marco se muestra en la Fig. 6.14. Como puede ver, el carácter de inicio “:” y la secuencia de parada “CR LF” se utilizan para diferenciar entre fotogramas. Los receptores del bus monitorean continuamente el carácter ":", que indica de forma única el comienzo de la trama. Cuando se recibe, los receptores captan el campo de dirección, etc. Este es un método de sincronización muy simple que te permite no ser crítico con las pausas entre personajes (hasta 1 segundo). La dirección del esclavo y el código de función ocupan cada uno dos caracteres, según el valor de un byte. Luego vienen n * 2 caracteres de datos, donde n es el número de bytes de datos. En modo ASCII, el algoritmo LRC se utiliza para calcular la suma de comprobación. Además, la suma de comprobación se realiza en todos los bytes de la trama, excepto en la secuencia de caracteres de inicio y parada.

El modo ASCII impone menos exigencias al hardware al utilizar una secuencia de inicio y publicación para delimitar fotogramas y es insensible a pausas significativas entre caracteres. Pero estas ventajas se reflejan en sus desventajas. El modo RTU es más exigente con los intervalos entre fotogramas, pero es mucho más productivo queASCII.

Ejemplo 6.4. MODBUS. Cálculo del tiempo de sondeo de esclavos en MODBUS-RTU.

Tarea . Construya tramas de formatos de mensajes de solicitud y respuesta para MODBUS RTU y calcule el tiempo total de sondeo para 10 variables analógicas de 16 bits para 4 esclavos (Fig. 6.15). Velocidad de transferencia de datos de bits: 19200 bps. El Proceso Maestro Cliente (TSX Premium) y los Procesos Esclavo Servidor (TSX Micro PLC) reciben mensajes al inicio del ciclo y envían mensajes al final del ciclo. Tiempo de ciclo maestro = 10 ms, esclavo - 5 s.

Completa la tarea. Se accede a las variables analógicas internas del TSX Micro a través de la función 03 o 04, por lo que el formato de trama se verá como en la Figura 6.16.

Teniendo en cuenta que la estructura de otros fotogramas es similar, no tiene sentido presentar su formato.
De manera similar a la figura 6.12, construiremos un diagrama de tiempo del intercambio (figura 6.17).

Desde el lado de la aplicación cliente, se genera un mensaje de solicitud utilizando una función de comunicación, cuyos datos se envían a través del puerto de comunicación al final del ciclo de la tarea y se reciben desde el puerto al comienzo del ciclo. Este comportamiento del lado del cliente es consistente con muchas implementaciones para varios PLC.

En TSX Micro el servidor MODBUS está implementado a nivel del sistema operativo. La especificidad de la implementación es que el sistema recibe solicitudes MODBUS del puerto de comunicación al comienzo del ciclo y envía mensajes de respuesta al final.

Cabe señalar que la implementación del servidor MODBUS se puede soportar a nivel del módulo de comunicación, y el intercambio de datos con la memoria del propio dispositivo se realiza a través de buffers de comunicación. En este caso la respuesta del servidor MODBUS será mucho más rápida y no dependerá del ciclo del programa. Para calcular los tiempos de transacción para otros tipos de sistemas, es necesario familiarizarse con los detalles de su implementación.

La figura 6.17 muestra que la llegada de una trama llega a algún lugar dentro del bucle. Esto significa que su procesamiento y generación de respuesta tomará aproximadamente 1,5 ciclos. Debe entenderse que este es un valor promedio, para la peor estimación es mejor reservar 2 tiempos de ciclo (es decir, cuando la trama llegó inmediatamente después de sondear el puerto de comunicación). Así, el tiempo de transacción para un PLC, por ejemplo PLC1 (TT1), será igual a:

TT1=C5+T1.req+2*C1+T1.res+C5*2 (6.1)

TT1 se calcula teniendo en cuenta los 2 ciclos empleados por el Esclavo para generar una respuesta al mensaje de solicitud. Si la transacción no se realizó periódicamente, como de acuerdo con la condición de la tarea, sino cuando ocurrió un evento, entonces durante la transacción también sería necesario incluir otro ciclo Maestro. Es fácil mostrar el tiempo de sondeo para todos los esclavos:

ТТall=C5*9+C1*2+C2*2+C3*2+C4*2+T1.req+T1.res+ T2.req+T2.res+ T3.req+T3.res+ T4.req+T4.res (6.2)

Dado que los ciclos de los Esclavos son los mismos, y las tramas de solicitud y de respuesta para todos los esclavos tienen la misma estructura, la fórmula general será la siguiente:

TTall= C5*9 + C1*8 + (T1.req+T2.req)*4(6.3)

Calculemos los tiempos T1.req y T2.req.

El tiempo de transmisión de la trama (Tframe) se puede calcular aproximadamente mediante el número de símbolos (Nsymb) en la trama y el tiempo de transmisión de un símbolo (Tsymb):

Marco T=Nsímb*Tsimb (6.4)

Se calcula el tiempo de transmisión de un carácter:

tiempo de transmisión por símbolo = número de bits por símbolo/velocidad de bits;
El tiempo de transmisión de la trama será igual a (div. Fig. 6.16 y Fig. 6.17):

T1.req=8*(11/19200)=4,58 ms

T1.res=25*(11/19200)=14,33 ms

TTall=90+40+ (4,58+14,33)*4= 206 ms.

Así, para sondear 10 variables de 4 esclavos a una velocidad de 19200 bps, se necesitan aproximadamente 206 ms. Si se requiere un sondeo periódico, es aconsejable reservar un tiempo determinado, por ejemplo 100 ms adicionales.

En algunos casos, la implementación de las funciones del Cliente MODBUS recae en el sistema operativo y el acceso a ellas en el programa del PLC se produce a través de funciones de comunicación de la interfaz. En particular, esto es típico de la mayoría de los PLC de Scneider Electric (Momentum, Quantum, TSX Micro, TSX Premium, M340). En varios otros sistemas, el lado del cliente a nivel de aplicación debe estar completamente registrado en el programa PLC y la interfaz se proporciona solo para el intercambio con el puerto de comunicación. En este caso, el sistema proporciona servicios para enviar y recibir mensajes (que son generados y analizados por el propio programa de usuario) y generar y verificar una suma de verificación.Veamos un ejemplo.

Ejemplo 6.5. MODBUS. Implementación de un cliente MODBUS en TSX Twido.

Tarea . Escriba un fragmento de programa en el PLC Twido para leer 3 registros del Esclavo con la dirección 1 (Fig. 6.18).

Solución . En Twido, el lado del cliente MODBUS debe implementarse mediante una función genérica EXCHx, que envía y/o recibe datos a través del puerto de comunicación número x. Los parámetros de la función son una tabla de palabras (%MW), que contienen datos de control de la función, datos a enviar y un búfer a recibir. Si el intercambio se realiza a través del puerto de comunicación 2, entonces la llamada a la función tendrá el siguiente formato:

EXCH2 %MWy:n,

donde y es el número de la primera variable de la tabla seleccionada, n es el número de palabras de la tabla.

El formato de la tabla, es decir, los datos que se deben completar y el área de datos que se deben recibir, es el mismo para todo tipo de comunicaciones. Para las funciones 03/04 (lectura de N palabras) vía MODBUS-RTU, esta tabla tendrá la forma que se muestra en la Tabla 6.2).

La tabla de parámetros consta de 3 partes: subtablas. La tabla de control de funciones especifica los parámetros de la función misma. Entonces, en el byte alto de la palabra 0 se indica que esta función funciona en ambas direcciones, es decir Después de enviar los datos, debes esperar una respuesta. El byte bajo de la misma palabra indica la longitud de la tabla de transmisión (en este caso 6 bytes), para que el sistema sepa qué bytes deben transmitirse (de la 2da palabra a la 4ta) y dónde comienza el buffer de recepción. (de la quinta palabra). Los desplazamientos en transmisión y recepción son necesarios para alinear los datos en los buffers con las palabras.

La tabla de transferencia contiene la solicitud en sí, es decir. marco sin código CRC. La tabla de recepción es un búfer que el sistema llenará con un marco de respuesta si el resultado es positivo. Por lo tanto, antes de utilizar esta función, es necesario construir el marco de solicitud y respuesta con la excepción del campo CRC (Fig. 6.19).

Tabla 6.2

tabla de parámetros

	Índice en la tabla	byte alto	byte bajo
Mesa de control de comunicaciones función		01 (tipo de función envío+recepción)	06 (longitud de la mesa de transferencia)
		03 (sesgo en la recepción)	00 (sesgo en la transmisión)
mesa de transferencia		dirección del esclavo	03 (número de función)
		dirección de registro inicial
		número de registros
Mesa de recepción (mensaje-respuesta)		Direcciones del esclavo	03 (número de función)
		00 (byte para desplazamiento)	contador de bytes
		primer registro
		segundo registro
	…	...
	N+6	enésimo registro

Como puede ver, la solicitud contiene 6 bytes. Esta cantidad debe ingresarse en el byte bajo de la palabra 0 de la tabla. Se espera que la respuesta sea de 9 bytes. Si los bytes de la trama de respuesta se colocan en una secuencia de palabras (en el PLC Schneider Electric la memoria se direcciona en palabras), entonces el byte alto del primer registro recibido (según la condición, es %MW100) será ubicado en el byte bajo de la segunda palabra del búfer, y el byte bajo del registro recibido estará encendidobyte alto de la tercera palabra en el buffer. Por lo tanto, todas las palabras aceptadas se desplazarán y serán difíciles de leer. Para eliminar este problema, la tabla de parámetros de función tiene un campo de desplazamiento de recepción que especifica el número del byte en el búfer de recepción que desplazará toda la secuencia.

El fragmento del programa se verá como en la Fig. 6.20.
La cadena LD superior es para llenar la mesa de control de funciones y llenar la mesa de transmisión.

En la segunda cadena, la función se llama directamente. La variable %MSG2.D devuelve un "1" booleano cuando se procesa la función EXCH2 y se recibe el resultado. Su uso evita que la red se “inunde” con un número excesivo de tramas, pues hasta que no haya respuesta a la solicitud anterior o no haya pasado el tiempo de espera no se podrá enviar una nueva solicitud.

La última cadena está destinada a escribir el resultado de la lectura en las variables %MW0:3 (una tabla con 3 palabras a partir de %MW0). La variable %MSG2.E será igual a 1 cuando haya un error en la llamada a la función.

6.3.4. Implementación de la capa física para MODBUS Serial

A diferencia de la especificación original, que se limitaba a la descripción de la trama, el estándar MODBUS-IDA también describe las reglas para implementar la red en la capa física. MODBUS sobre Línea Serie se basa en el uso de interfaces serie RS-485, RS-422 y RS-232.

Se ha definido una topología para RS-485: este es un bus que proporciona tres formas de conectar dispositivos (Fig. 6.21):

- Directamente al cable troncal, sin ramales;

- A través de una caja de conexión pasiva y un cable derivado (Derivación);

- A través de una caja activa y un cable derivador específico.

Las interfaces entre cables y elementos de red tienen las siguientes designaciones (ver Fig. 6.21): ITr - interfaz al cable principal; IDv - interfaz entre el dispositivo y la caja pasiva; AUI: interfaz entre el dispositivo y la caja activa; LT - terminadores de línea.
Las velocidades de bits se definen como 9600 bps y 19200 bps (predeterminado). Otras velocidades son opcionales.Se utiliza el método de codificación NRZ.

Cuando se utiliza RS-485, el estándar define las reglas para conectar dispositivos usando un esquema de 2 y 4 hilos, así como las reglas para la compatibilidad de interfaces de 2 y 4 hilos en una sola línea. A continuación consideraremos solo una conexión de 2 cables, cuyo soporte es obligatorio.

Básicamente, una conexión de 2 cables es en realidad una conexión de 3 cables, ya que además de las líneas A-( D0 ) y B+( D1 ) la línea común C( Común ), que es obligatorio (Fig. 6.22).

El número total de dispositivos es limitado: 32 dispositivos en un segmento RS-485 sin repetidores (se permite el uso de repetidores). La longitud máxima del cable depende de la velocidad, el tipo de cable, la cantidad de cargas y la configuración de la red (2 o 4 hilos). Para una velocidad de bits de 9600 y cable AWG26, la longitud máxima está limitada a 1000 m. El cable de acometida debe tener una longitud inferior a 20 m. Si se utilizan cajas multipuerto con n puertos, cada cable de acometida está limitado a 40/n m de longitud.

El cable de señal común (Común) debe conectarse a la pantalla en un punto del bus, generalmente cerca del nodo maestro o su caja de derivación.

Para suprimir la reflexión de las olas, se instalan terminadores de línea (LT) en los extremos de la línea entre D1 y D0. Se permite instalar terminadores solo en el cable principal.Como terminadores se pueden utilizar los siguientes:

- Resistencia con un valor nominal de 150 Ohmios y una potencia de 0,5 W;

- Condensador conectado en serie (1 nF, 10 V mínimo) y resistencia de 120 ohmios (0,25 W) usando polarización de línea

El estándar MODBUS Serial define reglas para implementar polarización protectora (polarización), que prevén la conexión de una fuente de alimentación de 5 V entre D1 y D0 a través de resistencias PullUp y PullDown para mantener un "1" lógico en la línea cuando no hay transmisión.El valor de la resistencia se selecciona entre 450 ohmios y 650 ohmios según la cantidad de dispositivos (650 ohmios para un número grande). El desplazamiento defensivo se lleva a cabo sólo en un punto de la línea, normalmente en el lado líder. El número máximo de dispositivos con polarización implementada se reduce en 4 respecto a un sistema sin polarización. La polarización es opcional. Sin embargo, las comunicaciones en los dispositivos pueden fallar si no hay una señal lógica. Si este es el caso, entonces la polarización debe implementarse de forma independiente o utilizar circuitos existentes, si los dispositivos lo proporcionan.

La norma también define la interfaz mecánica, es decir. tipos de conectores, enchufes y correspondencia de señales en contactos. Como terminal mecánico se puede utilizar un bloque de terminales, un conector RJ-45 blindado (Fig. 6.23) o un conector SUB-D9 blindado (Fig. 6.24).

La Tabla 6.3 muestra la asignación de contactos para conectores para una conexión de 2 hilos vía RS-485 y la Tabla 6.4 para RS-232.

Tabla 6.3

Propósito de los contactos del conector cuando se conecta a través de RS-485

números de contacto		requisitos de disponibilidad	circuito IDv	cadena itr	nombre RS-485	comentario (ver sección 3)
RJ45	SUB-D9
		opcional	P.M.C.			control de modo de comunicación puerto
		Necesariamente	D1		CAMA Y DESAYUNO"	voltaje V1, V1>V0 para registro. "1"
		Necesariamente	D0		AUTOMÓVIL CLUB BRITÁNICO"	voltaje V0, V0>V1 para registro. "0"
		preferiblemente				Fuente de alimentación 5…24 VCC
		Necesariamente	Común	Común	C/C"	Tierra de potencia y señal

Tabla 6.4

Propósito de los contactos del conector cuando se conecta a través de RS-232

DCE (módem)			circuito			ETD
números de contacto		requisitos de disponibilidad	Nombre	comentario (ver sección 3)	fuente RS-232	requisitos de disponibilidad	números contactos
RJ45	SUB-D9						RJ45	SUB-D9
		Necesariamente	TxD	Datos transmitidos	<< DTE	Necesariamente
		Necesariamente	RxD	Datos recibidos	DCE >>	Necesariamente
		opcional	cts	Borrar para enviar	DCE >>	opcional
		opcional	estrategia en tiempo real	Solicitud de envío	<< DTE	opcional
		Necesariamente	Común	Señal común		Necesariamente

Como cables para un tipo de conexión de 2 hilos, la norma define un par trenzado con doble blindaje de categorías 4 (hasta 600 m) o 5 (hasta 1000 m), donde un par contiene las señales balanceadas D0 y D1, y el segundo contiene las señales comunes. señal de tierra. Colores de cable recomendados: D1 amarillo; D0 marrón; Gris común.

Ejemplo 6.6. MODBUS. Esquema de conexión de red MODBUS RTU.

Tarea . Dibuje un diagrama de conexiones de red para una implementación de 2 hilos del bus MODBUS RTU con los siguientes nodos:

- PLC1: VIPA CPU 115SER 6BL32 (Maestro) a través del puerto serie incorporado del módulo procesador;

- PLC2: TSX Twido TWDLMDA40DTK (Esclavo) mediante módulo de comunicación TWD NOZ 485T

- PLC3: TSX Twido TWDLMDA40DTK (Esclavo) mediante módulo de comunicación TWD NOZ 485T

Solución . La Figura 6.25 muestra un diagrama de conexiones de red para la tarea dada. La especificación de las instalaciones de la red se da en la Tabla 6.5.

Como se puede observar en la Fig. 6.25, el PLC1 se conecta al bus a través de una caja pasiva, o más bien a través de un bloque de terminales, que es básicamente equivalente. Esto se debe a que las conexiones al PLC se realizan mediante un conector SUB-D de 9 pines, lo que requiere el desarrollo de su propio cable, cuyo diagrama de conexión (unión) al conector y al bloque de terminales se muestra debajo del diagrama principal.

Por tanto, los hilos del cable KM2 deben soldarse al enchufe KK1.La asignación de pines del socket SER no coincide con la estándar. Los pines 8 y 3 (A (D0) y B (D1, respectivamente)) van en un par, luego se conectan a XT1:1 y XT1:2; 5 y 6 (M5V (-5V) y P5V (+5 V, respectivamente)) van a otro par trenzado del cable KM2. Se requiere un suministro de 5 V para implementar la polarización protectora (asimetría) de acuerdo con la norma. AdemásM5Ves una señal de tierra (común).

El cable KM2 se conecta a XT1 según el diagrama que se muestra en la Fig. 6.25. La pantalla del cable se conecta a la tierra de señal de acuerdo con los requisitos de la norma. Cabe recordar que el PLC VIPA en este sistema es el Maestro, por lo tanto, en este lugar se deben implementar las conexiones de protección offset y blindaje a tierra. La polarización de protección se produce utilizando alimentación de 5 V, que se toma del puerto SER y dos resistencias.

Tabla 6.5.

Especificación de instalaciones de red

№	Designación	Nombre	Referencia	kólico	Nota
	PLC1	PLC VIPA 100	VIPA CPU 115SER 6BL32	1 pieza	VIPA
	PLC2, PLC3	PLC Twido	TWDLMDA40DTK	2 uds.	Electricidad Schneider
	MK1, MK2	módulo de comunicación para implementar la interfaz RS-485, conexión por tornillo	TWD NOZ 485T	2 uds.	Electricidad Schneider
	KK1	Conector macho SUB-D de 9 pines		1 pieza
	XT1	Bloque de terminales de 4 pines		1 pieza
	TL1, TL2	terminadores de línea		2 piezas	se fabrican con pos. 7 y 8
		Resistencia 120 ohmios (0,25 W)		2 uds.	incluido en el punto 6
		Condensador 1 nF (>10 V)		2 uds.	como parte de la pos.6
	Ru, Rd	Resistencia 500 ohmios (0,25 W)		2 piezas
	KM1	AWG26		300 metros
	KM2	Cable de par trenzado con doble blindaje, categoría 5 AWG26		2 metros
	KM3	Cable de par trenzado con doble blindaje, categoría 5 AWG26		300 metros

PLC2 y PLC3 se conectan al bus mediante un módulo de comunicación con un bloque de terminales. Esto permite una conexión sin ramas. Sin embargo, el bloque no proporciona un punto de conexión para el blindaje, por lo que el cable está blindado por separado.

Los terminadores de línea se implementan conectando resistencias y condensadores en serie, ya que se aplica una polarización protectora en el bus.

Actualmente MODBUS Serial se utiliza tanto a nivel de controlador como a nivel de sensor (para periféricos distribuidos). Su uso es problemático cuando hay varios dispositivos en el autobús.SCADA/ HMI, que en una arquitectura cliente-servidor deben ser Clientes, porque en MODBUS RTU/ASCII solo el Maestro puede ser Cliente. Pero incluso en tal situación, es posible organizar la entrega de datos a todos los nodos que lo necesiten, si admiten este modo.

En base a lo anterior, se puede elegir el bus Serie MODBUS si:

- todos los dispositivos de servidor admiten MODBUS RTU/ASCII en modo esclavo;

- sólo se necesita un dispositivo Cliente, que debe iniciar intercambios en el bus, soportando MODBUS RTU/ASCII como Maestro;

- velocidad de recuperación de datos- satisface las condiciones del problema;
no hay necesidad de

El artículo está dedicado al protocolo industrial ModBus, el protocolo de transferencia de datos digitales más simple y, por tanto, más utilizado.

El estándar ModBus fue inventado en 1979 por Modicon (ahora Schneider Electric) y desde entonces no ha perdido su relevancia, sino por el contrario, se ha generalizado y es muy popular entre los desarrolladores de sistemas de control de procesos.

Ventajas y desventajas del protocolo ModBus

Ventajas:

• fácil de implementar
• no es necesario instalar chips especiales para implementar el protocolo al desarrollar controladores y dispositivos
• facilidad de diagnóstico y depuración
• Compatible con la mayoría de los dispositivos utilizados en la construcción de sistemas de control de procesos automatizados.
• alta confiabilidad y confiabilidad de la transmisión de datos

Defectos:

• La red ModBus se basa en el principio "maestro-esclavo", donde sólo puede haber un dispositivo maestro. Por lo tanto, el intercambio de datos se produce sólo por iniciativa del dispositivo maestro (sondea a todos los esclavos por turno). Si un dispositivo esclavo necesita transmitir datos con urgencia, no puede hacerlo hasta que el "maestro" lo sondee.

Información general sobre la red ModBus

La red ModBus combina un líder (maestro) y varios esclavos (esclavos). El intercambio de datos en la red se produce por iniciativa del maestro. Puede enviar una solicitud a uno de los dispositivos esclavos o un mensaje de difusión a todos los dispositivos esclavos de la red a la vez.

Después de enviar una solicitud, el maestro espera una respuesta dentro de un tiempo específico (“tiempo de espera”). Si no se recibe respuesta dentro de este tiempo, el maestro considera que no hay comunicación con el esclavo. No hay respuesta a un mensaje de difusión.

Los esclavos (dispositivos esclavos) no pueden iniciar la transferencia de datos de forma independiente. Pueden transmitir datos solo después de que el maestro los solicite (y solo los datos que el maestro solicite).

Hay tres tipos de protocolo:

• Modbus ASCII- un tipo de protocolo en el que los mensajes se codifican utilizando caracteres ASCII. Los mensajes están separados por caracteres ":" y CR/LF. No es muy conveniente; en Rusia se usa muy raramente.
• Modbus RTU- un tipo de protocolo en el que los mensajes se codifican "tal cual" (en números). Los mensajes están separados entre sí por una pausa de 3,5 caracteres a una velocidad de transmisión determinada.
• Modbus TCP- un tipo de protocolo para trabajar sobre la pila TCP/IP, necesario al conectar dispositivos a través de Ethernet.

Capa física del protocolo ModBus

Se utiliza para transmitir mensajes ModBus. secuencial interfaces asíncronas(RS232, RS485, RS422) en caso de utilizar protocolos ASCII y RTU y interfaz ethernet para protocolo ModBus TCP.

El uso de interfaces estándar hace que ModBus sea conveniente para usuarios y desarrolladores.

Tipos de datos ModBus

Cualquier nodo de la red ModBus es un dispositivo inteligente (controlador, regulador, sensor, etc.). Según la especificación, un nodo de red puede tener las siguientes estructuras de datos:

• Entradas discretas— estados de las entradas discretas del dispositivo, solo se pueden leer. Tipo de datos de un solo bit.
• Bobinas— estados de las salidas discretas del dispositivo, se pueden leer y cambiar (escribir un nuevo estado). Tipo de un solo bit.
• Registros de entrada- Registros de sólo lectura de 16 bits.
• Registros de tenencia— Registros de libre asignación de 16 bits, disponibles para lectura y escritura.

Los tipos de datos especificados son opcionales para todos los dispositivos compatibles con ModBus. Por ejemplo, las entradas y bobinas discretas son más típicas de .

El fabricante del dispositivo decide qué tipo de datos poner a disposición para lectura y escritura a través de ModBus, y esto está escrito en el manual del dispositivo. En la mayoría de los casos se utiliza el tipo Holding Registers, ya que es el más universal.

Estructura de intercambio de datos ModBus

Como ya se mencionó, el intercambio de datos ModBus consta de solicitudes y respuestas. El dispositivo maestro envía una solicitud a uno de los dispositivos esclavos, indicando su dirección en la solicitud, o a todos los dispositivos a la vez, indicando la dirección 0.

Arroz. Estructura del paquete ModBus

Una solicitud o respuesta típica consta de los siguientes bloques:

• dirección esclava
• número de función: determina el tipo de datos solicitados y qué se debe hacer con ellos (lectura/escritura)
• datos: contiene parámetros de función (“dónde”, “cuánto” y “qué” datos escribir o leer)
• bloque de control de autenticación: contiene una suma de verificación para verificar la integridad de los datos recibidos.

La composición de estos bloques es diferente para las implementaciones RTU y TCP de ModBus. A continuación veremos cada uno de ellos en detalle.

No consideraremos ModBus ASCII en detalle, ya que se usa muy raramente. La composición de un paquete en ModBus ASCII es la misma que en ModBus RTU y sólo difiere en el tipo de codificación y el método de separación de paquetes.

El número de función determina el tipo de datos solicitados y qué se debe hacer con ellos (lectura/escritura).

Hay muchas funciones ModBus y se dividen en tres categorías:

• estándar: funciones descritas en el protocolo estándar. Muchos de ellos están desactualizados y sin uso.
• personalizado: una variedad de números de función (65 a 72 y 100 a 110) que cualquier fabricante de dispositivos puede utilizar para implementar sus funciones específicas. Al mismo tiempo, es muy posible que dispositivos de diferentes fabricantes con los mismos números tengan funciones diferentes.
• reservado: funciones no descritas en el estándar básico, pero implementadas en dispositivos de varios fabricantes. Al mismo tiempo, se garantiza que estos fabricantes se han reservado estos números y otros fabricantes no pueden utilizarlos.

Sin embargo, esto es todo letra... En la práctica, en la mayoría de los casos, solo se utilizan unas pocas funciones, hablaremos de ellas en detalle en y en este veremos todo usando el ejemplo de la función Leer registros de retención. (lectura de registros de uso general).

Función de lectura de registros de retención ( 0x03)

La función número 3 es una de las funciones más utilizadas, diseñada para leer registros de propósito general del dispositivo.

La solicitud especifica el número de registros que deben leerse y la dirección del primero de ellos.

La respuesta contiene el número de bytes (el número de registros multiplicado por 2) y los valores de los registros solicitados.

Arroz. Solicitud del maestro

Arroz. La respuesta del esclavo

El número de bytes en la respuesta ayuda al maestro, a medida que se reciben los datos, a saber cuándo se han recibido todos los datos. Es decir, si el maestro recibió el tercer byte con el número 200, esto significa que le quedan otros 100 bytes para recibir + 2 bytes de control de integridad. Esto le permitirá contar el número de bytes recibidos y finalizar la recepción sin esperar el tiempo de espera asignado al esclavo para responder.

En lugar de una respuesta normal que contenga los datos solicitados, el dispositivo esclavo puede responder con un error. En este caso, el código 0x80 en sistema numérico hexadecimal se agrega al número de función en la respuesta.

Veamos el ejemplo anterior. Allí, el dispositivo esclavo respondió sin error y el segundo byte de la respuesta fue 0x03. Si la respuesta contenía un código de error, entonces el esclavo agregaría 0x80 al número de función y obtendría 0x83. Como esto:

Arroz. Respuesta del esclavo con indicación de error

En este ejemplo, el código de error 02 es uno de los códigos estándar. Esto es lo que son:

01: la función no es compatible. Esto significa que quizás la función no sea estándar o simplemente no esté implementada específicamente en este dispositivo.

02 - El área de memoria solicitada no está disponible. Cada dispositivo contiene una determinada cantidad de datos de un determinado tipo. Por ejemplo, un dispositivo tiene 100 registros de uso general disponibles. Si solicita leer 101 registros, se producirá el error 02.

03: la función no admitirá la cantidad de datos solicitada. Por ejemplo, la función No. 3 “Leer registros de retención” le permite leer de 1 a 2000 registros de uso general. Por lo tanto, incluso si hay 10.000 registros disponibles para lectura en el dispositivo esclavo, si se solicitan más de 2.000 usando la función No. 3, se producirá este error.

04 - la función se ejecutó con un error. Este código de error se devolverá si existe algún otro obstáculo para la ejecución normal del comando que no esté cubierto por los tres códigos de error anteriores. En pocas palabras, se trata de un código auxiliar "por si acaso" si algo sale mal, pero el protocolo no proporciona un código especial para dicho error.

Debemos recordar que no sólo existen funciones estándar, sino también personalizadas y reservadas. Por lo tanto, los fabricantes de dispositivos que agregaron sus propias funciones al protocolo pueden haber incluido otros códigos de error allí. Pero todo esto es muy exótico...

Modbus RTU

Como ya se mencionó, en el protocolo ModBus RTU, los datos se transmiten en forma de mensajes separados por pausas de tiempo de 3,5 caracteres a una velocidad de transmisión determinada.

El mensaje debe indicar la dirección del destinatario (o 0 si el mensaje se transmite) y el número de función. El número de función determina qué datos contiene el mensaje y cómo interpretarlo.

El número de función va seguido de datos. Los registros de datos en ModBus son de 32 bits y se transmiten en dos capas de 16 bits. Primero viene el byte alto y luego el byte bajo.

Ejemplo. Digamos que queremos leer 2 registros de un módulo de adquisición de datos remoto, comenzando por el primero. La dirección del módulo remoto en la red ModBus es “4”. Para ello utilizaremos la función nº 3 Leer registros de retención.

Arroz. Solicitud de lectura de 2 registros, empezando por el 1.

Arroz. Respuesta del esclavo a la petición.

En la respuesta, el dispositivo esclavo repite su dirección y número de función, seguido del número de bytes útiles en la respuesta. Cada registro consta de dos bytes (primero el más alto y luego el más bajo). Los valores de los registros solicitados resultaron ser 11 y 22 en decimal (0B y 16 en hexadecimal, respectivamente).

Publicaremos un artículo aparte sobre cómo utilizar otras funciones de ModBus.

Monitoreo de integridad de paquetes en ModBus RTU (CRC-16)

En el ejemplo anterior, los bytes de datos van seguidos de dos bytes de verificación de integridad del paquete. Son el resultado de calcular el código CRC-16 para todo el mensaje.

El maestro, al enviar una solicitud, calcula el código CRC y lo agrega al final del mensaje. El esclavo, una vez recibido el mensaje, comprueba la integridad del mensaje según el algoritmo CRC-16. Luego, el esclavo redacta una respuesta, calcula el CRC de la misma manera y la agrega al final del paquete.

No consideraremos el algoritmo CRC-16 en detalle, porque... intentamos estar más cerca de la práctica... Y en la práctica, un programador casi nunca tiene que escribir un bloque de cálculo CRC; en cualquier entorno de programación puede encontrar la función o bloque funcional correspondiente.

Conclusión

En este artículo analizamos la estructura general del protocolo ModBus y su versión clásica ModBus RTU. En líneas generales, ModBus RTU es el “verdadero Modbus” (si descartamos el ModBus ASCII, que ya está desactualizado).

En hablaremos de un tipo de protocolo ModBus TCP, que es un "tirón de las orejas" del ModBus clásico para su uso en redes Ethernet, lo que, por supuesto, impone ciertas restricciones. Pero más sobre eso en el próximo artículo. Estén atentos a las actualizaciones sobre PEREZOSO INTELIGENTE.