Introduccin a Modbus

Fecha de Publicacin: oct 15, 2014

Visin General
El protocolo industrial Modbus fue desarrollado en 1979 para permitir la comunicacin entre dispositivos de automatizacin. Originalmente implementado como un protocolo a nivel de la
aplicacin para transferir datos en una capa serial, el protocolo se ha expandido para incluir implementaciones a travs de protocolo serial, TCP/IP y UDP (User Datagram Protocol). Hoy en da,
es un protocolo comn usado por innumerables dispositivos para comunicacin simple, confiable y eficiente en una variedad de redes modernas.

Contenido
1. El Ciclo de Solicitud-Respuesta
2. El Modelo de Datos de Modbus
3. Cdigos de Funcin de Modbus
4. API de LabVIEW Modbus
5. Servidores de E/S Modbus
6. NI OPC Servers con Servidores de E/S OPC u OPC UA

Introduccin a Modbus
Modbus es usado generalmente para comunicacin en red tipo SCADA entre dispositivos. Por ejemplo, un servidor grande puede ser usado para manejar un controlador lgico programable
(PLC) o un controlador de automatizacin programable (PAC), y el PLC o PAC puede a su vez manejar un sensor, vlvula, motor o cualquier otro dispositivo embebido.
Para cumplir estas necesidades, Modbus fue diseado como un protocolo de solicitud y respuesta con un modelo flexible de datos y funciones; caractersticas que son parte de la razn por la
que hoy en da an sigue en uso.

1. El Ciclo de Solicitud-Respuesta
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 informacin, lo cual tiene beneficios en redes seriales multipunto ms viejas. An 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 diseos.

Figura 1. La Relacin 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 aplicacin (ADU), la cual es lo que la mayora 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 ms eficiente a travs 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 representacin binaria compacta,
mientras que ASCII enva todas las solicitudes como cadenas de caracteres ASCII.
Para la mayora de las aplicaciones, el ADU preferido depende de la red fsica deseada (Ethernet, serial o alguna otra), el nmero 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 aplicacin 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 ncleo del protocolo Modbus. Cada PDU contiene un cdigo de funcin y datos asociados. Cada cdigo de funcin tiene
una respuesta bien definida y usted puede pensar en este cdigo de funcin como el comando que ha sido enviado al esclavo.
En algunos casos, pueden ocurrir errores. Modbus define un PDU especfico para excepciones, lo cual permite al maestro saber lo que pas. La mayora de los controladores convierten esto en
una forma que tenga sentido para el lenguaje o la aplicacin en uso.

2. El Modelo de Datos de Modbus

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 comn para los dispositivos embebidos tener ciertos valores definidos como entradas, como ganancias o parmetros PID, mientras que otros valores son salidas,
como la temperatura actual o posicin de la vlvula. 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.
Bloque de Memoria

Tipo de Datos

Acceso de Maestro

Acceso de Esclavo

Bobinas

Booleano

Lectura/Escritura

Lectura/Escritura

Entradas Discretas

Booleano

Solo Lectura

Lectura/Escritura

Registros de Retencin

Palabra Sin Signo

Lectura/Escritura

Lectura/Escritura

Registros de Entrada

Palabra Sin Signo

Solo Lectura

Lectura/Escritura

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 comn para los dispositivos esclavos convertir estos tipos de
datos ms grandes a registros. Por ejemplo, un sensor de presin 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 retencin y los registros de entrada de hecho comparten la misma memoria si ese comportamiento tiene sentido para el esclavo. En la mayora de los casos, los
esclavos almacenan cada tipo de datos soportados en memoria separada y limita el nmero de elementos de datos a los que un maestro tiene acceso. Esta flexibilidad es una opcin debido a la
manera en la que los datos son expuestos a travs del comportamiento bien definido de los cdigos de funcin de Modbus.

3. Cdigos de Funcin de Modbus

Los cdigos de funcin de Modbus determinan cmo el maestro tiene acceso y modifica los datos. A diferencia de los rangos de datos, los cuales son conceptuales, los cdigos de funcin tienen
un comportamiento bien definido. Cuando a un esclavo se le pide realizar un cdigo de funcin, utiliza los parmetros de la funcin para ejecutar ese comportamiento bien definido. La figura 2
muestra este enlace entre una solicitud de funcin y la memoria real del dispositivo.

1/6

www.ni.com

Figura 2. El Mapeo entre un Cdigo de Funcin, Rangos de Datos y la Memoria Real de un Dispositivo Esclavo
Los cdigos de funcin ms comunes llevan el nombre del rango de datos conceptual que modifican o al que tienen acceso. Por ejemplo, "read holding registers" realiza la accin de extraer
datos de la memoria definida como registros de retencin y regresarlos al maestro. La Tabla 2 identifica los cdigos de funcin ms comunes.

Tabla 2. Cdigos de Funcin Ms 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 travs de los mdulos LabVIEW Real-Time o LabVIEW Datalogging and Supervisory Control (DSC).

4. API de LabVIEW Modbus

El API de Modbus de bajo nivel es la opcin preferida cuando su aplicacin necesita un alto nivel de control en las secuencias y temporizacin de las solicitudes de Modbus. El API de bajo nivel
tambin es generalmente la eleccin preferida cuando la flexibilidad es lo ms importante. Sin embargo, la flexibilidad y la potencia ofrecida por el API de LabVIEW Modbus tambin significa que
su cdigo de aplicacin debe ser ms 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 informacin bsica de la funcionalidad del API. Tambin muestra las diferencias entre una implementacin en una PC y dispositivo en tiempo
real. La Figura 3 muestra el cdigo involucrado en el ejemplo de Maestro Modbus en Tiempo Real.

2/6

www.ni.com

Figura 3. Master on RT Target.vi

Este ejemplo muestra los requerimientos principales de una aplicacin 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 polimrfico.

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 cdigo de funcin Read Input Registers. Todos los cdigos de
funcin de Modbus soportados por el API son mostrados en la paleta adecuada. Debido a la implementacin 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 cdigos de funcin.

Figura 5. Las Paletas de Maestro y Esclavo de Modbus Muestran los Cdigos de Funcin
Finalmente, se cierra la instancia de Modbus, liberando la memoria asociada con la instancia. Esto tambin cierra cualquier referencia, incluyendo la conexin 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 patrn bsico que es familiar a la mayora 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 rpidamente.

Ejemplo de Maestro Redundante

El ejemplo bsico 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 aplicacin de ejemplo muestra cmo usar dos maestros para comunicarse con un esclavo determinado. Si uno de los maestros falla y pierde conexin ya sea con
el esclavo o con la interfaz humano-mquina (HMI), el otro maestro se har cargo.

3/6

www.ni.com

Figura 6. Diseo del Ejemplo de Maestro Redundante

Si este diseo cumple con las necesidades de su aplicacin o si usted est interesado en un ejemplo ms complejo de comunicacin por Modbus, vea Redundant Modbus Masters.lvproj en el
Example Finder.

5. Servidores de E/S Modbus

Los servidores de E/S Modbus, los cuales estn en los mdulos LabVIEW DSC y LabVIEW Real-Time, ofrecen un motor de alto nivel para comunicarse por Modbus. En lugar de especificar un
cdigo de funcin que usted desea enviar, registre el conjunto de datos al que quiere tener acceso y el servidor de E/S programa automticamente las solicitudes en el rango especificado.
Para usar los servidores de E/S, aada 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 dirigirn a parmetros adicionales. Por ejemplo, un maestro tiene un rango de consulta definidola velocidad a la que cada solicitud es enviada al esclavo, mientras que los esclavos
deben esperar estas solicitudes y no tienen tiempos pre-definidos.
Despus 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 retencin en la
direccin 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 precisin simple que est almacenado en los
registros 0 y 1 al seleccionar F400001.
Despus 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 Aplicacin Sencilla de Servidor de E/S

El esfuerzo de programacin involucrado con una aplicacin de servidor de E/S es mnimo y es ms fcil 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 aadir o eliminar datos solicitados en tiempo de ejecucin. Si estas limitaciones son aceptables para su aplicacin, los
servidores de E/S son la opcin recomendada para las diferentes plataformas.
Para ms informacin y una gua paso a paso, vea Cmo Conectar LabVIEW a Cualquier PLC con Modbus .

6. NI OPC Servers con Servidores de E/S OPC u OPC UA

Para aplicaciones complicadas que involucran varios dispositivos esclavos que se comunican a travs de diferentes protocolos, las E/S Modbus estndares podran no ser suficientes. Una
solucin comn es usar un servidor OPC, el cual acta como un compilador de datos para todos sus sistemas y despus usar los servidores de E/S OPC incluidos en el Mdulo 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.
Despus de que los datos son agregados en NI OPC Servers, un servidor de E/S OPC puede recuperar datos y compartirlos con la aplicacin de LabVIEW.

4/6

www.ni.com

Figura 8. Una Aplicacin SCADA Usando Modbus, NI OPC Servers y Servidores de E/S OPC
Usted tambin puede desarrollar una arquitectura similar que utilice el controlador OPC UA incluido en el Mdulo 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 aplicacin como esta, usted primero debe generar una configuracin vlida para NI OPC Servers para comunicarse con sus dispositivos esclavo. Esto se logra al generar
canales, los cuales definen una configuracin 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 Configuracin 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.

5/6

www.ni.com

Figura 10. Configurar los Servidores de E/S OPC

Este proceso de unin genera variables que usted puede usar en su aplicacin.

Figura 11. Una Aplicacin Sencilla Usando Servidores de E/S OPC

Encuentre un explicacin completa de este proceso en Cmo Conectar LabVIEW a Cualquier PLC Usando OPC .

Cumpliendo con las Necesidades de su Aplicacin

Modbus es un protocolo simple que usted puede usar de varias maneras para implementar aplicaciones potentes.
Para comunicacin por Modbus, NI ofrece estas tres opciones principales que brindan un amplio rango de funcionalidad para cumplir con las necesidades de su aplicacin. 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
ms simples, los servidores de E/S Modbus ofrecen un API ms sencillo y ms fcil 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. Despus, simplemente use una herramienta como un controlador LabVIEW OPC UA o servidores de E/S OPC para que su
aplicacin tenga acceso a estos datos.

6/6

www.ni.com