Aplicación Del Protocolo Modbus RTU En El Entorno De Desarrollo Isagraf

Universidad Distrital Francisco José de Caldas

Facultad Tecnológica - Ingeniería en Control
Automática DCS

Presentado por: Juan David Contreras Garzón - Daniel Andrés López Rodríguez
20151383014 20151383002

En este documento se mostrara toda la información e implementación de un sistema

de comunicación modbus RTU. El protocolo MODBUS define una estructura de
mensajes que puede ser reconocida por diferentes dispositivos independientemente
del tipo de red de comunicaciones utilizada. El protocolo describe el proceso para
acceder a información de un dispositivo, cómo debe responder éste, y como se
notifican las situaciones de error. Modbus es un protocolo de solicitud-respuesta
implementado usando una relación maestro-esclavo. En una relación maestro-esclavo,
la comunicación siempre se produce en pares, un dispositivo debe iniciar una solicitud
y luego esperar una respuesta y el dispositivo de inicio (el maestro) es responsable de
iniciar cada interacción. Por lo general, el maestro es una interfaz humano-máquina
(HMI) o sistema SCADA y el esclavo es un sensor, controlador lógico programable
(PLC) o controlador de automatización programable (PAC). El contenido de estas
solicitudes y respuestas, y las capas de la red a través de las cuales se envían estos
mensajes, son definidos por las diferentes capas del protocolo.

El modo de transmisión es la estructura de las unidades de información contenidas en

un mensaje. El protocolo MODBUS define dos modos de transmisión: ASCII (American
Satandard Code for Information Interchange) y RTU (Remote Terminal Unit). En una
red de dispositivos conectados mediante el protocolo MODBUS NO se pueden
compartir dispositivos utilizando diferentes modos de transmisión.

Los datos disponibles por medio de Modbus son almacenados, en general, en uno de
los cuatro bancos de datos o rangos de dirección: bobinas, entradas discretas,
registros de retención y registros de entrada. Al igual que con gran parte de la
especificación, los nombres pueden variar dependiendo de la industria o de la
aplicación. Por ejemplo, los registros de retención pueden denominarse como registros
de salida y las bobinas pueden denominarse como salidas digitales o discretas. Estos
bancos de datos definen el tipo y los derechos de acceso de los datos contenidos. Los
dispositivos esclavos tienen acceso directo a estos datos, los cuales son alojados
localmente en los dispositivos. Los datos disponibles por medio de Modbus
generalmente son un subconjunto de la memoria principal del dispositivo. En
contraste, los maestros Modbus deben solicitar el acceso a estos datos a través de
diversos códigos de función. El comportamiento de cada bloque se describe en la
siguiente tabla.

Estos bloques le brindan la habilidad de restringir o permitir el acceso a los diferentes

elementos de datos y también de proporcionar mecanismos simplificados en la capa
de aplicación para tener acceso a diferentes tipos de datos. Los bloques son
completamente conceptuales. Pueden existir como direcciones de memoria separadas
en un sistema determinado, pero también pueden traslaparse. Por ejemplo, la bobina
uno puede existir en la misma ubicación en memoria como el primer bit de la palabra
representada por el registro de retención uno. El esquema de dirección se define
completamente por el dispositivo esclavo y su interpretación de cada bloque de
memoria es una parte importante del modelo de datos del dispositivo.

Rangos de dirección

Aunque la especificación define los diferentes tipos de datos que existen en diferentes
bloques y asigna un rango de dirección local para cada tipo, esto no se traduce
necesariamente en un esquema intuitivo de dirección para fines de documentación o
para comprender la memoria disponible a través de Modbus de un dispositivo
determinado. Para simplificar la discusión de ubicaciones del bloque de memoria, se
introdujo un esquema de numeración, el cual añade prefijos a la dirección de los datos
en cuestión.

Por ejemplo, si el maestro consulta a un esclavo el estado de veintidós entradas a

partir de la entrada 197 estará haciendo referencia a las entradas 10197-10218 del
controlador esclavo. Se ha colocado el primer dígito en negrita para resaltar que éste
indica la referencia de este tipo de dato. Este protocolo ha sido acogido y actualizado a
tal punto que se ha convertido en un estándar de facto para la automatización de la
industria gracias a su particular estructura de mensajes, la cual opera con direcciones
de memoria y no variables concretas, haciéndolo adaptable a diferentes dispositivos
Un mensaje consiste en una secuencia de caracteres que puedan ser interpretados
por el receptor, como se muestra en la figura:

Esta secuencia de caracteres define la trama, como se muestra en la tabla. Para

sincronizar la trama, Los dispositivos receptores monitorizan el intervalo de tiempo
transcurrido entre caracteres recibidos. Si se detecta un intervalo mayor que tres
veces y medio el tiempo necesario para transmitir un carácter, el dispositivo receptor
ignora la trama y asume que el siguiente carácter que recibirá será una dirección.

Ahora se explicara cada uno de los campos que componen la trama:

Dirección. El campo dirección es el primero de la trama después del tiempo de
sincronización. Indica el dispositivo al que va dirigido el mensaje. Cada dispositivo de
la red debe tener asignada una dirección única, diferente de cero.
Igualmente, cuando un dispositivo responde a un mensaje, debe enviar en primer lugar
su dirección para que el master reconozca la procedencia del mensaje.
Dado que existen direcciones reservadas para propósitos especiales como el
broadcast el valor que puede ir de 1 a 247.
• Valor comprendido entre 1-247.
• No se ve afectado por si se trata de una trama de escritura o lectura.
• Cuando el master pregunta al slave este campo contiene la dirección del slave al que
va dirigido. Cuando se trata de una trama de respuesta de un slave al master este
campo contiene también la dirección del esclavo indicando quién es el que responde.
Función. El campo función indica al dispositivo direccionado qué tipo de función ha de
Realizar. En este caso, el valor contenido en este campo sí que puede variar si se
trata de una trama Master->Slave o si por el contrario es Slave->Master. El valor de
este byte se verá modificado en la trama de respuesta sólo cuando exista algún error
en el campo de datos de la trama Modbus enviada por el Master, no cuando el código
de comprobación de errores de esta sea erróneo. Reiterando lo dicho, si la trama del
Master es correcta, la trama de respuesta tiene este byte con el mismo valor.
Las funciones pueden ser:
Funciones de lectura de datos:
• Función 01 (01 hex): Lectura de señales discretas de salida (Discrete Output Coils)
• Función 02 (02 hex): Lectura de señales discretas de entradas (Discrete Input
Contacts)
• Función 03 (03 hex): Lectura de registros analógicos (Analog Output Holding
Registers)
• Función 04 (04 hex): Lectura de registros analógicos de entrada (Analog Input
Registers)
Funciones de escritura de datos:
• Función 05 (05 hex): Escritura de una señal discreta de salida (Simple Discrete
Output Coil)
• Función 15 (0F hex): Escritura de múltiples señales discretas de salida (Múltiple
Discrete Output Coils)
• Función 06 (06 hex): Escritura de un Simple Analog Output Holding Register
• Función 16 (10 hex): Escritura Múltiple Analog Output Holding Registers
Datos. El campo datos contiene la información necesaria para que los dispositivos
puedan ejecutar las funciones solicitadas, o la información enviada por los dispositivos
al master como respuesta a una función.
Control de Errores. El campo de control de errores es el último de la trama y permite
al master y a los dispositivos detectar errores de transmisión. Ocasionalmente, debido
a ruido eléctrico o a interferencias de otra naturaleza, se puede producir alguna
modificación en el mensaje mientras se está transmitiendo. El control de errores
asegura que los dispositivos receptores o el master no efectuarán acciones incorrectas
debido a una modificación accidental del mensaje. El formato RTU utiliza el control de
redundancia cíclica (CRC), mientras que el ASCII utiliza el control de redundancia
longitudinal (CRL) para finalizar la trama de comunicación.
Este campo también consta de dos bytes y como en cualquier otro protocolo en el
caso de Modbus sirve para la detección de errores en la trama. El CRC (Cyclic
Redundancy Check o comprobación de redundancia cíclica) es un código más que
frecuente en la detección de errores en redes digitales, sistemas de almacenamiento
para la detección de modificación accidental de los datos o en este caso para
comprobar la integridad de los datos en su transmisión por buses de campo.
Para el cálculo del CRC se utilizan cada uno de los bytes que conforman la trama. El
procedimiento es el siguiente:
• Se envía la trama Modbus con el CRC calculado.
• El receptor del mensaje recibe la trama completa e internamente calcula el CRC con
los datos recibidos. Y lo compara con el CRC que le ha llegado.
• Si el código coincide, la trama Modbus es correcta y se prosigue con el
funcionamiento normal generando la respuesta pertinente.
• Si el código es erróneo, es decir que no coincide el CRC recibido con el CRC no se
responderá a la petición de datos por parte del Slave, de manera que ocurrirá un
Timeout en recepción del Master y este deberá entender que el Slave no ha recibido la
trama correctamente y procederá a un reintento.
Comúnmente, los errores que aparecen durante las operaciones de acceso y
programación de dispositivos tienen relación con datos no válidos en la trama, tal
como se ve en la tabla 4. Cuando un dispositivo detecta un error de esta naturaleza, la
respuesta al master consiste en la dirección del dispositivo, el código de la función, el
código de error y el CRC. Para indicar que la respuesta es una notificación de error, el
bit de más peso del código de la función está activado a 1.
Modbus RTU con Isagraf

En este apartado se explicara detalladamente lo necesario para realizar una

comunicación modbus, en el programa de resologis isagraf.
La aplicación consta de dos partes. La primera es toda la configuración del dispositivo
maestro que en nuestro caso es una raspberry pi 2 modelo B, y por último la
configuración del esclavo que en este caso será un arduino debido a que
necesitaremos convertir señales análogas en digitales ya que la raspberry no contiene
un conversor análogo-digital.

Comencemos por abrir el programa isagraf:

Una vez abierto vamos a crear un proyecto nuevo, para esto vamos a archivo, nuevo,
proyecto y aparecerá lo siguiente:
Seleccionamos el dispositivo que tenemos, en este caso el dispositivo es un RPI2B y
damos un nombre al proyecto y damos clic a aceptar. En el entorno de trabajo
aparecerá un archivo llamado Desployment.isadpl en el cual configuramos la dirección
ip del dispositivo, para configurar la ip damos doble clic sobre la línea verde oscura
como muestra la figura.

Al costado derecho de la pantalla en el recuadro de propiedades, buscamos el

apartado de IPAdress y damos doble clic y cambiamos la IP a la que nosotros
tenemos. Una vez realizada la configuración, en el explorador de solución que está
ubicada en la parte derecha de la pantalla desplegamos la carpeta que se encuentra
en este cuadro que ente caso se llama Modbus_RTU, desplegamos el ítem CPU1, y
también desplegamos el ítem IOTask, después de a ver hecho esto no queda lo
siguiente:
Una vez aplicado lo anterior vamos a configurar el dispositivo, habilitar la
comunicación modbus que nos da isagraf, para esto damos clic secundario sobre
IOTask, Vamos a Dispositivos E/S damos clic y aparecerá una ventana con lo
siguiente:

Vamos a configurar la comunicación modbus. A continuación vamos a agregar todas

las funciones de modbus maestro serial, y agregaremos
modbusmaster_serial_gateway, que hará todo lo relacionado a la conexión con el
esclavo.
Una vez agregados vamos a configurar el Gateway que es el que configura el puerto y
el tipo de comunicación si rtu o ASCII, damos clic sobre el + de serial_gateway y
tendremos los siguiente:

Ahora tenemos que saber que puerto vamos a usar hay varias formas de saber
conectando una pantalla a la RPI, y por medio de comando saber que puerto serial
usar, (Recordando que se pueden usar 2 puertos el /dev/ACM0 y el /dev/AMA0)
vamos a usar /dev/ACM0 debido a que el otro puerto genera errores al momento de la
transmisión de datos. Por ultimo terminamos todos los ítems según la aplicación que
necesitemos en nuestro caso se dejaron así:
Vamos a la ventana de explorador de solución y damos clic sobre programas, añadir y
seleccionamos el tipo de lenguaje que queramos en nuestro caso ST (Lenguaje
estructurado).

Una vez creado generamos el siguiente código en ST: (*Codigo Maestro MODBUS
RTU*):

analoga1:= _IO_IU1_0.Value;
digital1:=_IO_IU2_0.Value;
digital2:=_IO_IU3_0.value;
analoga2:=_IO_IU4_0.value;

Estas variables se crean en el item de variables locales como se muestra a

continuación:
El texto estructurado queda de la siguinete manera:

Compilamos y si todo va bien debería salir correcta la compilación:

Ahora vamos con la configuración del esclavo. Vamos a buscar la librería de esclavo
modbus en google, la descargamos y la instalamos de la siguiente manera:
Vamos a programa, incluir librería, añadir librería .zip y buscamos la librería en nuestro
caso usamos la de esta página web:
http://www.electronhacks.com/2014/04/arduino-modbus-plc-rtu/
El programa que se implementara en el arduino sera el siguinte:

#include <modbus.h>
#include <modbusDevice.h>
#include <modbusRegBank.h>
#include <modbusSlave.h>

modbusDevice regBank;
modbusSlave slave;

int AI0,AI1;

void setup()
{
regBank.setId(1);

regBank.add(10001); //Digital_Inpunt
regBank.add(1); //Coil
regBank.add(30001); //Inpunt_register
regBank.add(40001); //Holding_register

slave._device = &regBank;
slave.setBaud(9600);

pinMode(2,INPUT);
pinMode(3,INPUT);
}
void loop(){

while(1){
byte DI1 = digitalRead(2); //Pin digital #2
if (DI1 >= 1)regBank.set(10001,1);
if (DI1 <= 0)regBank.set(10001,0);
bool DI2 = digitalRead(3); //Pin digital #3
if (DI2 >= 1)regBank.set(1,1);
if (DI2 <= 0)regBank.set(1,0);

AI0 = analogRead(0); //Pin análogo #0

delay(10);
AI0 = analogRead(0);
regBank.set(30001, (word) AI0);
delay(10);

AI1 = analogRead(1); //Pin análogo #1

delay(10);
AI1 = analogRead(1);
regBank.set(40001, (word) AI1);
delay(10);

slave.run();
}
}
Después de haber compilado el programa vamos al paso final. La conexión se realiza
por USB, conectamos un extremo en los puertos USB disponibles en la RPI y el puerto
disponible en el arduino como la figura:

Para finalizar se realiza la prueba de conexíon desde Isagraf. Se obserbará la

comunicación de las 4 variables (dos digitales y dos análogas) dando click en los items
Depurar->Iniciar Depuración.