Introducción a Modbus

Introducción a Modbus

Modbus es usado generalmente para comunicación en red tipo SCADA entre dispositivos. Por ejemplo, un servidor grande puede ser usado para manejar un controlador lógico programable (PLC) o un controlador de automatización programable (PAC), y el PLC o PAC puede a su vez manejar un sensor, válvula, motor o cualquier otro dispositivo embebido.

Para cumplir estas necesidades, Modbus fue diseñado como un protocolo de solicitud y respuesta con un modelo flexible de datos y funciones; características que son parte de la razón por la que hoy en día aún sigue en uso.

El protocolo Modbus sigue una arquitectura de maestro y esclavo, en la que un maestro transmite una solicitud a un esclavo y espera la respuesta. Esta arquitectura brinda al maestro control completo sobre el flujo de información, lo cual tiene beneficios en redes seriales multipunto más viejas. Aún en redes TCP/IP modernas, le da al maestro un alto grado de control en el comportamiento del esclavo, lo cual es útil en algunos diseños.

^{Figura 1: La Relación de Solicitud-Respuesta y Maestro-Esclavo de los Dispositivos Modbus}

En Modbus, esta solicitud es un conjunto de datos en capas. La primera capa es la unidad de datos de la aplicación (ADU), la cual es lo que la mayoría de las personas consideran que es el "tipo" de Modbus usado. Existen tres ADUs: ASCII, unidad de terminal remota (RTU) y TCP/IP.

TCP es un formato moderno que permite un manejo eficiente de las solicitudes y respuestas Modbus en software, así como un sistema de red más eficiente a través del uso de conexiones e identificadores dedicados para cada solicitud. RTU y ASCII son formatos de ADU seriales antiguos y la principal diferencia entre los dos es que RTU utiliza una representación binaria compacta, mientras que ASCII envía todas las solicitudes como cadenas de caracteres ASCII.

Para la mayoría de las aplicaciones, el ADU preferido depende de la red física deseada (Ethernet, serial o alguna otra), el número de dispositivos en la red y los ADUs soportados por los dispositivos maestros y esclavos en la red. Desde el punto de vista de la aplicación usando Modbus, los datos deben ser expuestos simplemente como si el ADU no existiera.

En cada ADU, existe 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 datos asociados. Cada código de función tiene una respuesta bien definida y usted puede pensar en este código de función como el comando que ha sido enviado al esclavo.

En algunos casos, pueden ocurrir errores. Modbus define un PDU específico para excepciones, lo cual permite al maestro saber lo que pasó. La mayoría de los controladores convierten esto en una forma que tenga sentido para el lenguaje o la aplicación en uso.

Modbus administra el acceso de los datos de manera simple y flexible. Originalmente, Modbus soporta dos tipos de datos: un valor Booleano y un entero sin signo de 16 bits.

En los sistemas SCADA, es común para los dispositivos embebidos tener ciertos valores definidos como entradas, como ganancias o parámetros PID, mientras que otros valores son salidas, como la temperatura actual o posición de la válvula. Para cumplir con esta necesidad, los valores de los datos Modbus son divididos en cuatro rangos (ver la Tabla 1). Un esclavo puede definirse como 65,536 elementos en cada rango.

^{Tabla 1: Bloques de Modelo de Datos de Modbus}

En muchos casos, los sensores y otros dispositivos generan datos en tipos diferentes a Booleanos simples y enteros sin signo. Es común para los dispositivos esclavos convertir estos tipos de datos más grandes a registros. Por ejemplo, un sensor de presión puede dividir un valor de punto flotante de 32 bits entre dos registros de 16 bits.

Modbus muestra 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 tal manera que los registros de retención 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 almacenan cada tipo de datos soportados en memoria separada y limita el número de elementos de datos a los que un maestro tiene acceso. Esta flexibilidad es una opción debido a la manera en la que los datos son expuestos a través del comportamiento bien definido de los códigos de función de Modbus.

Los códigos de función de Modbus determinan cómo el maestro tiene acceso y modifica los datos. A diferencia de los rangos de datos, los cuales son conceptuales, los códigos de función tienen un comportamiento bien definido. Cuando a un esclavo se le pide realizar un código de función, utiliza los parámetros de la función para ejecutar ese comportamiento bien definido. La figura 2 muestra este enlace entre una solicitud de función y la memoria real del dispositivo.

^{Figura 2: El Mapeo 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 llevan el nombre del rango de datos conceptual que modifican o al que tienen acceso. Por ejemplo, "read holding registers" realiza la acción de extraer datos de la memoria definida como registros de retención y regresarlos al maestro. La Tabla 2 identifica los códigos de función más comunes.

^{Tabla 2: Códigos de Función Más Comunes}

Comenzar a Trabajar con Modbus en LabVIEW

NI ofrece tres mecanismos principales para conectar dispositivo Modbus: (1) un servidor OPC de alto nivel, (2) un servidor de E/S Modbus y (3) un API de Modbus introducido en NI LabVIEW 2014 a través de los módulos LabVIEW Real-Time o LabVIEW Datalogging and Supervisory Control (DSC).

El API de Modbus de bajo nivel es la opción preferida cuando su aplicación necesita un alto nivel de control en las secuencias y temporización de las solicitudes de Modbus. El API de bajo nivel también es generalmente la elección preferida cuando la flexibilidad es lo más importante. Sin embargo, la flexibilidad y la potencia ofrecida por el API de LabVIEW Modbus también significa que su código de aplicación debe ser más complejo para administrar correctamente el API. Para ayudarle a comprender esta complejidad, LabVIEW proporciona dos ejemplos.

Ejemplo Introductorio de Modbus

El primer ejemplo, Modbus Library.lvproj, ofrece información básica de la funcionalidad del API. También muestra las diferencias entre una implementación en una PC y dispositivo en tiempo real. La Figura 3 muestra el código involucrado en el ejemplo de Maestro Modbus en Tiempo Real.

^{Figura 3: Master on RT Target.vi}

Este ejemplo muestra los requerimientos principales de una aplicación Modbus usando el API de LabVIEW. Primero, se crea una instancia de Modbus. En este caso, un maestro TCP. Sin embargo, usted puede cambiar este ejemplo a un maestro serial al cambiar el selector de instancia polimórfico.

^{Figura 4: Cambiar el Tipo de Maestro Modbus}

Cuando se crea esta instancia, usted puede comenzar por consultar datos en el dispositivo esclavo. El ejemplo muestra el uso del código de función Read Input Registers. Todos los códigos de función de Modbus soportados por el API son mostrados en la paleta adecuada. Debido a la implementación del protocolo, el API esclavo tiene funciones adicionales que el maestro no puede implementar. Por ejemplo, un esclavo puede escribir en el rango de registro de entrada, mientras que un maestro solamente puede leer ese rango. La Figura 5 muestra los códigos de función.

^{Figura 5: Las Paletas de Maestro y Esclavo de Modbus Muestran los Códigos de Función}

Finalmente, se cierra la instancia de Modbus, liberando la memoria asociada con la instancia. Esto también cierra cualquier referencia, incluyendo la conexión TCP o referencias seriales NI-VISA usadas por la instancia.

Únicamente el ejemplo del maestro ha sido discutido hasta ahora; sin embargo, cada ejemplo sigue el mismo patrón básico que es familiar a la mayoría de los usuarios de LabVIEW: abrir, leer/escribir y cerrar.

Finalmente, aunque el API se ve igual, es importante comprender la diferencia clave. Si su dispositivo es un maestro, debe enviar una solicitud por la red al esclavo adecuado para adquirir datos. El esclavo, por otro lado, tiene su propio almacenamiento de datos local y puede tener acceso a ellos rápidamente.

Ejemplo de Maestro Redundante

El ejemplo básico es suficiente para algunas aplicaciones; sin embargo, puede no ser suficiente para aplicaciones complicadas donde el objetivo es hablar con un sensor o gateway. Para ayudar a disminuir esta diferencia, una aplicación de ejemplo muestra cómo usar dos maestros para comunicarse con un esclavo determinado. Si uno de los maestros falla y pierde conexión ya sea con el esclavo o con la interfaz humano-máquina (HMI), el otro maestro se hará cargo.

^{Figura 6: Diseño del Ejemplo de Maestro Redundante}

Si este diseño cumple con las necesidades de su aplicación o si usted está interesado en un ejemplo más complejo de comunicación por Modbus, vea Redundant Modbus Masters.lvproj en el Example Finder.

Los servidores de E/S Modbus, los cuales están en los módulos LabVIEW DSC y LabVIEW Real-Time, ofrecen un motor de alto nivel para comunicarse por Modbus. En lugar de especificar un código de función que usted desea enviar, registre el conjunto de datos al que quiere tener acceso y el servidor de E/S programa automáticamente las solicitudes en el rango especificado.

Para usar los servidores de E/S, añada un nuevo servidor de E/S al dispositivo deseado en su proyecto. Como con el API de bajo nivel, usted puede escoger entre un maestro o esclavo Modbus y estos lo dirigirán a parámetros adicionales. Por ejemplo, un maestro tiene un rango de consulta definido—la velocidad a la que cada solicitud es enviada al esclavo, mientras que los esclavos deben esperar estas solicitudes y no tienen tiempos pre-definidos.

Después de que se crea el servidor de E/S, usted debe especificar los elementos en el dispositivo que desea leer. A diferencia del API de bajo nivel, en el que usted debe generar y procesar las solicitudes usted mismo, los servidores de E/S de Modbus le permiten seleccionar entre una variedad de formatos y tipos de datos. Por ejemplo, usted puede leer el registro de retención en la dirección 0 al mapear una variable al elemento 400001, leer el primer bit de este registro al seleccionar 400001.1 y leer el dato de punto flotante de precisión simple que está almacenado en los registros 0 y 1 al seleccionar F400001.

Después de seleccionar las variables a acceder, usted puede leer o escribir estas variables usando nodos de variables compartidas en el diagrama de bloques. Usted incluso puede asignar un alias a los nombres de las variables.

^{Figura 7: Una Aplicación Sencilla de Servidor de E/S}

El esfuerzo de programación involucrado con una aplicación de servidor de E/S es mínimo y es más fácil de comprender. Recuerde que esta facilidad de uso tiene sus limitaciones. Los datos se actualizan únicamente a la velocidad pre-definida y no hay manera de añadir o eliminar datos solicitados en tiempo de ejecución. Si estas limitaciones son aceptables para su aplicación, los servidores de E/S son la opción recomendada para las diferentes plataformas.

Para más información y una guía paso a paso, vea Cómo Conectar LabVIEW a Cualquier PLC con Modbus.

Para aplicaciones complicadas que involucran varios dispositivos esclavos que se comunican a través de diferentes protocolos, las E/S Modbus estándares podrían no ser suficientes. Una solución común es usar un servidor OPC, el cual actúa como un compilador de datos para todos sus sistemas y después usar los servidores de E/S OPC incluidos en el Módulo LabVIEW DSC para comunicarse con ese servidor OPC.

La Figura 8 muestra un ejemplo de esta arquitectura, con NI OPC Servers usando Modbus para comunicarse directamente con sensores y UA OPC para comunicarse con un PAC CompactRIO. Después de que los datos son agregados en NI OPC Servers, un servidor de E/S OPC puede recuperar datos y compartirlos con la aplicación de LabVIEW.

^{Figura 8: Una Aplicación SCADA Usando Modbus, NI OPC Servers y Servidores de E/S OPC}

Usted también puede desarrollar una arquitectura similar que utilice el controlador OPC UA incluido en el Módulo LabVIEW DSC en lugar de los servidores de E/S OPC. Sin embargo, el controlador OPC UA es un controlador de bajo nivel y no proporciona la facilidad de uso que tienen los servidores de E/S OPC.

Para desarrollar una aplicación como esta, usted primero debe generar una configuración válida para NI OPC Servers para comunicarse con sus dispositivos esclavo. Esto se logra al generar canales, los cuales definen una configuración de controlador y dispositivos, que definen un punto final individual para ese controlador. Una vez que usted ha configurado un dispositivo, puede generar etiquetas.

^{Figura 9: Una Configuración de Muestra en NI OPC Servers para la Arquitectura de Arriba}

Y una vez que ha configurado NI OPC Servers, puede configurar un servidor de E/S OPC para comunicarse con esas etiquetas. Mientras que los servidores de E/S Modbus son configurados para tener acceso a los registros, los servidores de E/S OPC son configurados para tener acceso a las etiquetas en el servidor OPC.

^{Figura 10: Configurar los Servidores de E/S OPC}

Este proceso de unión genera variables que usted puede usar en su aplicación.

^{Figura 11: Una Aplicación Sencilla Usando Servidores de E/S OPC}

Encuentre un explicación completa de este proceso en Cómo Conectar LabVIEW a Cualquier PLC Usando OPC.

Cumpliendo con las Necesidades de su Aplicación

Modbus es un protocolo simple que usted puede usar de varias maneras para implementar aplicaciones potentes.

Para comunicación por Modbus, NI ofrece estas tres opciones principales que brindan un amplio rango de funcionalidad para cumplir con las necesidades de su aplicación. Primero, un API de bajo nivel ofrece control fino del protocolo, con alto rendimiento, a costa de la facilidad de uso. Todo debe realizarse manualmente al usar el API de bajo nivel. Para aplicaciones de monitoreo más simples, los servidores de E/S Modbus ofrecen un API más sencillo y más fácil para tener acceso o proporcionar datos Modbus. A cambio de la facilidad de uso, los servidores de E/S disminuyen el control del protocolo que puede ser necesario para algunas aplicaciones. Finalmente, para sistemas grandes y complejos, puede ser beneficioso considerar un servidor OPC con todas las funciones para servir como un compilador de datos. Después, simplemente use una herramienta como un controlador LabVIEW OPC UA o servidores de E/S OPC para que su aplicación tenga acceso a estos datos.

• Introducción a maestros y esclavos Modbus
• Desarrollo de aplicaciones con Modbus
• Información detallada sobre el protocolo Modbus
• Conecte LabVIEW a cualquier PLC con Modbus
• Descargue el LabVIEW Datalogging and Supervisory Control Module
• Descargar LabVIEW