Introducción a Modbus

Fecha de publicación: hace 01, 2014 | 59 calificaciones que | 3.93 Fuera de 5 | PDF

Información general
El protocolo industrial Modbus fue desarrollado en 1979 para hacer posible la comunicación entre los
dispositivos de automatización.Originalmente implementado como un protocolo de nivel de aplicación
prevista para transferir datos a través de una capa de serie, el protocolo se ha expandido para incluir a las
implementaciones más de serie, TCP / IP y el protocolo de datagramas de usuario (UDP). Hoy en día, es
un protocolo común utilizado por innumerables dispositivos de comunicación simple, fiable y eficiente a
través de una variedad de redes modernas.

Tabla de contenido
1. El ciclo de petición y respuesta
2. El modelo de datos Modbus
3. Códigos de función Modbus
4. LabVIEW Modbus API
5. Servidores Modbus I / O
6. NI OPC Servers Con OPC I / O Servers o OPC UA

Introducción a Modbus
Modbus se utiliza normalmente para el Control de Supervisión y Adquisición de Datos (SCADA) de
comunicación de red de estilo entre los dispositivos. Por ejemplo, un servidor grande puede ser utilizado
para dominar un controlador lógico programable (PLC) o un controlador de automatización programable
(PAC), mientras que PLC / PAC puede en el maestro a su vez un sensor, válvula, motor, o cualquier otro
dispositivo incorporado.
Para satisfacer estas necesidades, Modbus fue diseñado como un protocolo de petición-respuesta con
datos y funciones flexibles modelo-características que forman parte de la razón por la que todavía está en
uso hoy en día.
1. El ciclo de petición y respuesta
El protocolo Modbus sigue una arquitectura maestro y esclavo, donde un maestro transmite una petición a
un esclavo y espera la respuesta. Esta arquitectura proporciona el control completo dominio sobre el flujo
de información, que tiene beneficios sobre redes en serie multipunto mayores. Incluso en las redes TCP /
IP modernas, que le da al maestro un alto grado de control sobre el comportamiento de esclavos, lo cual
es útil en algunos diseños.

Figura 1. El Master-Slave, Solicitud-Respuesta a de dispositivos Modbus

En Modbus, esta solicitud es un conjunto de capas de datos. La primera capa es la unidad de datos de la
aplicación (ADU), que es lo que la mayoría de las personas consideran que es el "tipo" de Modbus
utilizado. Hay tres ADU: ASCII, unidad terminal remota (RTU), y TCP / IP.
TCP es un formato moderno que permite un manejo eficiente de peticiones Modbus y respuestas en
software, así como la creación de redes más eficiente mediante el uso de conexiones dedicadas y los
identificadores para cada solicitud. RTU y ASCII son mayores formatos de ADU en serie con la principal
diferencia entre los dos es que el RTU utiliza una representación binaria compacta mientras ASCII envía
todas las solicitudes como las corrientes de caracteres ASCII.
Para la mayoría de las aplicaciones, la ADU preferido depende de la red física deseada (Ethernet, serial,
o algo más), el número de dispositivos en la red, y la ADU soportado por los dispositivos maestros y
esclavos en la red. Desde el punto de vista de la aplicación mediante Modbus, los datos simplemente
deben ser expuestos como si no existiera la ADU.
Dentro de cada ADU, hay una unidad de datos de protocolo (PDU) que es el núcleo del protocolo
Modbus. Cada PDU contiene un código de función y los datos asociados. Cada código de función tiene
una respuesta bien definida, y se puede pensar en este código de función que el comando se envía al
esclavo.
En algunos casos, pueden producirse errores. Modbus define una PDU específico de excepciones, lo que
permite que el maestro sabe lo que pasó. La mayoría de los conductores de convertir esto en una forma
que tenga sentido para el lenguaje o la aplicación en uso.
Volver al principio
2. El modelo de datos Modbus
Modbus gestiona el acceso de datos sencilla y flexible. Nativamente, Modbus compatible con dos tipos de
datos: un valor booleano y un 16 bits entero sin signo.
En los sistemas SCADA, es común que los dispositivos embebidos tengan ciertos valores definidos como
insumos, tales como ganancias o integral derivativo (PID) ajustes proporcionales, mientras que otros
valores son salidas, como la temperatura o la posición actual de la válvula. Para satisfacer esta
necesidad, los valores de datos Modbus se dividen en cuatro rangos (ver Tabla 1).Un esclavo puede
definir un máximo de 65.536 elementos en cada rango.

Memoria Bloquear Tipo de datos Maestro de Acceso Acceso

Esclavo

Bobinas Boolean Leer / Escribir Leer / Escribir

Entradas discretas Boolean Sólo lectura Leer / Escribir

Registros de retención Unsigned Palabra Leer / Escribir Leer / Escribir

Registros de entrada Unsigned Palabra Sólo lectura Leer / Escribir

Tabla 1. Modbus Datos Bloques Modelo
En muchos casos, los sensores y otros dispositivos generan datos en otros tipos que simplemente
Booleanas y sin signo de números enteros. Es común que los dispositivos esclavos para convertir estos
tipos de datos más grandes en los registros. Por ejemplo, un sensor de presión puede dividir un valor de
coma flotante de 32 bits a través de dos registros de 16 bits.
Modbus expone estos valores de una manera completamente conceptual, lo que significa que pueden no
existir en realidad en la memoria. Por ejemplo, un dispositivo esclavo puede definirse de forma que los
registros y los registros de entrada de hecho comparten la misma memoria si ese comportamiento tiene
sentido para el esclavo. En la mayoría de los casos, los esclavos almacenar cada tipo de datos que
soporta en memoria independiente, y limita el número de elementos de datos que un maestro puede tener
acceso. Esta flexibilidad es una opción debido a la forma en que los datos se expone a través del
comportamiento bien definido de los códigos de función Modbus.
Volver al principio
3. los códigos de función Modbus
Códigos de función Modbus determinan cómo se accede y modificados por el maestro de datos. A
diferencia de los rangos de datos, que son conceptual, códigos de función tienen un comportamiento bien
definido. Cuando se le preguntó a un esclavo para realizar un código de función, utiliza los parámetros de
la función de ejecutar ese comportamiento bien definido. La Figura 2 muestra el enlace entre una solicitud
función y la memoria real del dispositivo.
Figura 2. La asignación entre un código de función, Rangos de datos, y la memoria real de un dispositivo
esclavo
Los códigos de función más comunes son el nombre del rango de datos conceptual que modifican o
acceso. Por ejemplo, "leer registros de retención" toma la acción de tirar de los datos de la memoria se
define como registros de retención y devolverla al maestro. Tabla 2 identifica los códigos de función más
comunes.
 Tabla 2. Códigos de Función comunes

Primeros pasos con Modbus en LabVIEW

NI ofrece tres mecanismos principales para la interconexión con los dispositivos Modbus: (1) un servidor
de alto nivel de OPC, (2) un servidor Modbus I / O, y (3) un API Modbus de bajo nivel introducidas en el
software NI LabVIEW 2014 LabVIEW a través de la Supervisory Control (DSC) módulos Real-Time o
registro de datos LabVIEW y.
Volver al principio
4. LabVIEW Modbus API
La API Modbus de bajo nivel es la opción preferida cuando la aplicación necesita un alto nivel de control
sobre el orden y el calendario de las peticiones Modbus. La API de bajo nivel suele ser también la opción
preferida donde la flexibilidad es primordial. En contraste, la flexibilidad y potencia ofrecida por la API de
LabVIEW Modbus también significa que el código de aplicación debe ser más compleja de gestionar
correctamente el API. Para ayudarle a entender esta complejidad, LabVIEW ofrece dos ejemplos.
Modbus introductoria Ejemplo
El primer ejemplo, Modbus Library.lvproj , ofrece una descripción básica de la funcionalidad de la
API. También demuestra las diferencias entre una aplicación en un PC y un objetivo en tiempo real. La
Figura 3 muestra el código implicado en el ejemplo en tiempo real Modbus Maestro.

[+] Ampliar imagen

Figura 3. principal en RT Target.vi
Este ejemplo demuestra los requisitos básicos de una aplicación Modbus utilizando el API de
LabVIEW. En primer lugar, se crea una instancia de Modbus. En este caso, un maestro TCP. Sin
embargo, puede cambiar este ejemplo para un maestro de serie al cambiar el selector ejemplo
polimórfica.

Figura 4. Cambiar el tipo de maestro Modbus

Cuando se crea la instancia, se puede iniciar el sondeo del dispositivo esclavo para los datos. El ejemplo
muestra el uso de los códigos de función Leer registros de entrada . Todos los códigos de función
Modbus soportados por la API se muestran en la paleta adecuada. Debido a la aplicación del protocolo, la
API esclavo tiene funciones adicionales que el maestro no puede poner en práctica. Por ejemplo, un
esclavo puede escribir en el registro de entrada de gama, mientras que un maestro sólo puede leer de
ese rango. La Figura 5 muestra los códigos de función.
 [+] Ampliar imagen
Figura 5. Modbus maestro y esclavo Paletas Listado de los códigos de función
Finalmente, la instancia Modbus está cerrado, de-la asignación de la memoria asociada con la
instancia. Esto también cierra cualquier referencia, incluyendo la conexión TCP o NI-VISA referencias de
serie utilizado por la instancia.
Sólo el ejemplo principal se ha discutido hasta ahora; Sin embargo, todos los ejemplos sigue el mismo
patrón básico familiar para la mayoría de los usuarios de LabVIEW: abrir, leer / escribir, y cerca.
Por último, si bien la API no tienen el mismo aspecto, es importante entender la diferencia clave. Si el
dispositivo es un maestro, debe enviar una solicitud a través de la red al satélite adecuada para adquirir
datos. El esclavo, por otro lado, tiene su propio almacenamiento de datos local y se puede acceder a ella
rápidamente.
Redundante Maestro Ejemplo
El ejemplo básico puede ser suficiente para algunas aplicaciones; sin embargo, puede no ser suficiente
para aplicaciones complicadas donde el objetivo es hablar con un sensor o puerta de enlace. Para ayudar
a cerrar esta brecha, una aplicación de ejemplo muestra cómo utilizar dos maestros para comunicarse
con un esclavo determinado. Si uno de los maestros falla y pierde la conexión, ya sea con el esclavo o de
la interfaz hombre-máquina (HMI), el otro maestro se hace cargo.

Figura 6. Diseño del Maestro Ejemplo redundante

Si este diseño se ajusta a las necesidades de su aplicación, o si usted está interesado en un ejemplo más
complejo de comunicación Modbus, ver redundante Modbus Masters.lvproj en el Finder Ejemplo.
Volver al principio
5. servidores Modbus I / O
Servidores de E / S Modbus I, que están en el DSC de LabVIEW y LabVIEW módulos Real-Time,
proporcionan un motor de alto nivel para la comunicación a través de Modbus. En lugar de especificar un
código de función que desea enviar, se registra el conjunto de datos que le gustaría tener acceso y los
horarios de servidor de E / S de las solicitudes de forma automática a la velocidad especificada.
Para utilizar los servidores de E / S, se agrega un nuevo servidor de E / S a la meta deseada en el
proyecto. Al igual que con la API de bajo nivel, se puede elegir entre un maestro o esclavo Modbus, y ello
conduce a los parámetros adicionales. Por ejemplo, un maestro tiene una tasa definida de votación-la
velocidad a la que se envía cada petición al esclavo, mientras que los esclavos deben esperar en esas
solicitudes y no tienen tiempo predefinido.
Una vez creado el servidor de E / S, puede especificar los elementos en el dispositivo que desee leer. A
diferencia de la API de bajo nivel, en el que debe generar y procesar las solicitudes de ti mismo,
servidores Modbus I / O permiten seleccionar entre una amplia variedad de formatos y tipos de datos. Por
ejemplo, se puede leer el registro de la explotación en la dirección 0 mediante la asignación de una
variable al artículo 400001, leer el primer bit de este registro mediante la selección de 400.001,1, y leer el
solo flotador de precisión que se almacena en los registros 0 y 1 mediante la selección de F400001.
Después de seleccionar las variables de acceso, se puede leer o escribir estas variables utilizando nodos
de variables compartidas en el diagrama de bloques. Usted puede incluso alias los nombres de las
variables.

Figura 7. Un servidor de aplicaciones simple I / O

El esfuerzo de programación involucrados con una aplicación de servidor de E / S es mínimo y fácil de
entender. Recuerde que esta facilidad de uso viene con limitaciones. Actualizaciones de datos en sólo la
tasa predefinida, y no hay manera de agregar o eliminar datos solicitados en tiempo de ejecución. Si estas
limitaciones son aceptables para su aplicación, E / S de los servidores son la opción multi-plataforma
recomendada.
Para obtener más información y una guía paso a paso, ver Conecte LabVIEW a Cualquier PLC con
Modbus .
Volver al principio
6. Servidores NI OPC con servidores de E / S OPC I o OPC UA
Para aplicaciones complicadas que involucran muchos dispositivos esclavos que se comunican a través
de diferentes protocolos, el estándar Modbus I / O podría no ser suficiente. Una solución común es utilizar
un servidor OPC, que actúa como un agregador de datos para todos sus sistemas y, a continuación,
utilizar los servidores de E / S OPC I incluidas en el Módulo LabVIEW DSC para comunicarse con ese
servidor OPC.
La figura 8 muestra un ejemplo de esta arquitectura, con servidores NI OPC utilizando Modbus para
comunicarse directamente con los sensores y OPC UA para comunicarse con la NI CompactRIO
PAC. Después datos se agregan en Servidores NI OPC, un servidor OPC de E / S puede recuperar datos
y compartirlo con la aplicación de LabVIEW.
 Figura 8. Una aplicación SCADA Utilizando Modbus, Servidores NI OPC y Servidores OPC de E / S
Usted también puede desarrollar una arquitectura similar que utiliza el controlador OPC UA incluido en el
Módulo LabVIEW DSC en lugar de los servidores OPC de E / S. Sin embargo, el controlador de OPC UA
es un controlador de bajo nivel y no proporciona la facilidad de uso ofrecida por los servidores OPC de E /
S.
Para desarrollar una aplicación como esta, primero debe generar una configuración válida para servidores
NI OPC para comunicarse con los dispositivos esclavos. Esto se hace mediante la generación de canales-
que definen un controlador de configuración-y dispositivos-que definen un punto final individual para ese
controlador. Después de haber configurado un dispositivo, puede generar etiquetas.

[+] Ampliar imagen

 Figura 9. un ejemplo de configuración de servidores NI OPC para la arquitectura anterior
Y después de haber configurado Servidores NI OPC, puede configurar un servidor de E / S OPC I para
comunicarse con estas etiquetas. Mientras que los servidores Modbus I / O están configurados para
acceder a los registros, los servidores OPC de E / S se configuran para las etiquetas de acceso en el
servidor OPC.

Figura 10. Configuración de los servidores OPC de E / S

Este proceso de unión genera variables que luego puede utilizar en su aplicación.

Figura 11. Una aplicación simple uso de servidores OPC de E / S

Encuentra un tutorial completo de este proceso en Conectar LabVIEW a Cualquier PLC Utilizando OPC .

Satisfacer las necesidades de su aplicación

Modbus es un protocolo simple que se puede utilizar de varias maneras para implementar aplicaciones de
gran alcance.
Para la comunicación Modbus, NI ofrece tres opciones principales que proporcionan una amplia gama de
funciones para satisfacer las necesidades de su aplicación. En primer lugar, una API de bajo nivel
proporciona un control preciso sobre el protocolo, con alto rendimiento, a expensas de la facilidad de
uso. Todo debe hacerse de forma manual cuando se utiliza la API de bajo nivel. Para aplicaciones de
control más simples, Modbus I / O Los servidores proporcionan una API más simple y más fácil para
acceder o sirviendo de datos Modbus. A cambio de la facilidad de uso, E / S de servidores rindo el control
estricto sobre el protocolo que puede ser necesario para algunas aplicaciones. Finalmente, para los
sistemas grandes y complejos, puede ser beneficioso considerar un servidor completamente equipado
OPC para servir como un agregador de datos. A continuación, sólo tiene que utilizar una herramienta
como el conductor LabVIEW OPC UA o servidores OPC de E / S para proporcionar a su acceso a la
aplicación a estos datos.