Está en la página 1de 39

UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO UTEQ

MATERIA
SISTEMAS DE MANUFACTURA FLEXIBLE

DOCENTE
HERNANDEZ ZUÑIGA RAÚL

PRÁCTICA 6 Comunicaciones industriales e IoT

ALUMNO
RAMÍREZ RÍOS AUGUSTO HAZZIM
RAMOS HUERTA ALEJANDRO

MATRICULA
2017348177
2019148039
ITA56
14/03/22
ÍNDICE

Fundamentación Teórica 3
¿Qué es Modbus? 3
¿Para qué se utiliza Modbus? 3
Tipos de protocolo Modbus 4
MODBUS RS 485 4
Capa física 5
Capa de enlace 5
Capa de red 6
Capa de transporte 6
Cómo funciona la estructura del mensaje en Modbus 7
Características principales 8
Descripción general de MODBUS 8
La trama Modbus 9
Dirección Modbus 10
Funciones Modbus 11
Campo de datos de Modbus 11
Trama Maestro 11
Trama esclavo 12
Tamaño de la Trama 12
Cómo funciona MQTT 14
MQTT en IoT 15
Ventajas y desventajas de MQTT 16
Desarrollo 17
Resultados 33
Conclusiones 38
Referencias 39
Fundamentación Teórica

El protocolo MODBUS es un protocolo de comunicación basado en una arquitectura


maestro/esclavo o cliente/servidor. El principal objetivo del protocolo es facilitar la
comunicación fiable y rápida entre dispositivos de automatización y campo.

¿Qué es Modbus?
Modbus es un protocolo de comunicación abierto, utilizado para transmitir
información a través de redes en serie entre dispositivos electrónicos. El dispositivo
que solicita la información se llama maestro Modbus y los dispositivos que
suministran la información son los esclavos Modbus.En realidad, esto significa que
un dispositivo esclavo no puede ofrecer información; debe esperar a que se le pida.
El maestro escribirá datos en los registros de un dispositivo esclavo y leerá los datos
de los registros de un dispositivo esclavo. Por lo tanto, en una red Modbus
estándar, hay un maestro y hasta 247 esclavos, cada uno con una dirección de
esclavo única de 1 a 247. El maestro también puede escribir información a los
esclavos. Además, esta red de comunicación industrial usa los protocolos
RS232/RS485/RS422. Su simplicidad y el hecho de que los fabricantes pueden
incorporarlo en sus productos sin cargo alguno ha ayudado a que se convierta en el
método más popular de conexión de dispositivos electrónicos industriales. En
consecuencia, son estos protocolos abiertos los que muchos fabricantes adaptan
para integrar fácilmente sus productos en el mercado.

¿Para qué se utiliza Modbus?


Por su parte, Modbus se ha convertido en un protocolo bastante común, usado
frecuentemente por muchos fabricantes en muchas industrias. Así pues, este
sistema de comunicación se usa generalmente para transmitir señales de los
dispositivos de instrumentación y control a un controlador principal o a un sistema
de recolección de datos (SCADA).Entre sus aplicaciones destaca su uso en
múltiples aplicaciones maestro-esclavo para monitorear y programar dispositivos;
para comunicarse entre dispositivos inteligentes y sensores e instrumentos; para
monitorear dispositivos de campo usando PC y HMI.

También, es un protocolo ideal para aplicaciones de RTU donde se requiere una


comunicación inalámbrica.

MODBUS en acción
MODBUS permite conectar un dispositivo maestro (p. ej., un PC) y varios
dispositivos esclavos (p. ej., sistemas de medición y control). Existen dos versiones,
una para la interfaz serie (RS-232 y RS-485) y otra para ETHERNET.

Los modos operativos de transmisión de datos son los siguientes:

● MODBUS TCP: comunicación ETHERNET TCP/IP basada en un modelo


cliente/servidor
● MODBUS RTU: transmisión asincrónica en serie a través de RS-232 o RS-
485
● MODBUS ASCII: similar al protocolo RTU excepto por un formato de datos
distinto; relativamente poco usado

Tipos de protocolo Modbus


Existen varios tipos de versiones en el protocolo Modbus para el puerto serie y
Ethernet, que se utilizan para atender las necesidades específicas de los sistemas
de automatización industrial en las empresas. Por ejemplo, Modbus TCP se
utiliza para Ethernet, y Modbus RTU y Modbus ASCII para los puertos serie.

Las más comunes son:

● Modbus RTU
● Modbus TCP
● Modbus ASCII
● Modbus Plus

El protocolo Modbus RTU es un medio de comunicación que permite el intercambio


de datos entre los controladores lógicos programables (PLC) y los ordenadores
(PC). Los dispositivos electrónicos pueden intercambiar información a través de
conexiones en serie utilizando este protocolo.

MODBUS RS 485
Se le denomina Modbus RS 485 al ya estudiado Protocolo Modbus, pero la capa
física está manejada por la recomendación RS 485. Todo lo estudiado aplica,
entre las especificaciones de RS 485 se pueden resaltar:
• Rango de Voltajes -> -6V DC a 6 V DC
• Se pueden interconectar hasta 32 equipos
• Recepción de las señales de forma diferencial, es decir, el voltaje a
interpretar se obtiene luego de restar las dos señales que llegan al
amplificador operacional (entrada no inversora y entrada inversora)
• Distancia máxima 1,2 Km
Modbus es un Protocolo monomaestro, es decir que a pesar de tener 32 equipos
solo puede estar un maestro al tiempo estableciendo la comunicación con el
esclavo que él seleccione.

Modbus/TCP

Se introdujo para aprovechar las infraestructuras LAN actuales. A su vez, aumentó


el número de unidades que podían conectarse a la misma red.Este sistema engloba
los bloques de datos de solicitud y respuesta del Modbus RTU en un bloque TCP
transmitido a través de redes estándar de Ethernet.

Es una evolución natural de las comunicaciones seriales como Modus RTU y


Modbus ASCII. En Modbus sobre TCP/IP como lo nombra la Modbus Organization
toda la estructura de la trama se mantiene como lo que se ha estudiado hasta el
momento, pero se hacen algunos ajustes propios de las nuevas capas del modelo
OSI que se están incluyendo.

Los perfiles de los equipos son ahora Cliente y Servidor. Se puede trazar un paralelo
para entender el comportamiento de los equipos con el tradicional Modbus RTU, los
maestros son ahora clientes y los esclavos son servidores.

Dentro del Modelo OSI que nuevas capas se han agregado:

Capa física
En Modbus TCP en la capa física se estandariza con la norma EIA/TIA 568, que
define entre otros aspectos el código de colores del cable, se emplea un conector
RJ45 que interconecta 8 señales, en donde 4 son dedicadas exclusivamente a la
transmisión y recepción de datos (TX+, TX-, RX+, RX-).

Capa de enlace
En la capa de enlace es importante tener en cuenta que aquí es donde aparece la
dirección física del Equipo, que popularmente se le llama la dirección MAC, se
compone de 6 bytes (6 octetos), cada equipo tiene una dirección unívoca en el
mundo (no existen dos iguales).

Figura1.-Ejemplo de dirección Capa Enlace

Si observan detenidamente la fotografía se puede identificar los 6 octetos


expresados en Hexadecimal, cada dígito abarca entonces 4 bits (dos dígitos unidos
son entonces un byte).

Capa de red
Esta capa es importante pues aparece el protocolo IP, al cual le debemos la
estandarización de todo lo relacionado con las direcciones IP, por lo tanto, nuestros
equipos en Modbus TCP deben tener asignada su dirección IP. Para hacer pruebas
y redes de tamaño mediano se usan direcciones clase C, por eso es muy habitual
encontrar direcciones IP como: 192.168.X.X configuradas en los equipos.

Capa de transporte
El protocolo empleado en esta capa normalmente es TCP, y en esta parte es
importante resaltar un parámetro de configuración definido para Modbus TCP y es
el puerto que se va a emplear, por defecto es el 502.
Figura2.-Protocolos comunicación TCP/IP

Modbus ASCII es una implementación más antigua que contiene todos los
elementos de un paquete RTU, pero expresada completamente en caracteres ASCII
imprimibles. Estos son caracteres hexadecimales que contienen 4 bits de datos
cada uno.

Modbus Plus es un protocolo de red con alta velocidad entre pares. Está basado
en la comunicación a través de un token bus. En definitiva, es un sistema completo
con un medio predefinido y la aplicación de un sistema de comunicación de paso
rápido.

Cómo funciona la estructura del mensaje en Modbus


La interfaz de comunicación de Modbus se construye alrededor de los mensajes.
El formato de estos mensajes es independiente del tipo de interfaz física utilizada.
En el viejo RS232 se utilizan los mismos mensajes que en el Modbus/TCP por
Ethernet. En consecuencia, le da a la definición de la interfaz una vida más larga.
Por lo que, se puede utilizar el mismo protocolo independientemente del tipo de
conexión. Debido a esto, se da la posibilidad de actualizar fácilmente la estructura
del hardware de una red industrial, sin necesidad de grandes cambios en el
software. También, un dispositivo puede comunicarse con varios nodos Modbus a
la vez, incluso si están conectados con diferentes tipos de interfaz, sin necesidad
de utilizar un protocolo diferente para cada conexión. En interfaces simples como
RS485 o RS232, los mensajes Modbus se envían en forma simple a través de la
red. En este caso la red está destinada a Modbus. Cuando se utilizan sistemas de
red más versátiles como TCP/IP por Ethernet, los mensajes se incorporan en
paquetes con el formato necesario para la interfaz física. En ese caso, Modbus y
otros tipos de conexiones pueden coexistir en la misma interfaz física al mismo
tiempo.

Características principales

Aunque la estructura principal de los mensajes es de par a par, Modbus puede


funcionar tanto en redes punto a punto como en redes multipunto. Cada mensaje
tiene la misma estructura: cuatro elementos básicos están presentes en cada
mensaje. Así como, la secuencia de estos elementos es la misma para todos los
mensajes, para facilitar el análisis del contenido del mensaje. En consecuencia, una
conversación siempre es iniciada por un maestro en la red Modbus. Posteriormente,
un maestro envía un mensaje y, dependiendo del contenido del mensaje, un esclavo
actúa y le responde. Además, puede haber más maestros en una red de este
protocolo de comunicación. Finalmente, el direccionamiento en el encabezamiento
del mensaje se utiliza para definir qué dispositivo debe responder a un mensaje.
Todos los demás nodos de la red Modbus ignoran el mensaje si el campo de
dirección no coincide con su propia dirección.

Descripción general de MODBUS

El consolidado protocolo MODBUS se ha convertido en la norma «de facto» y


amplía el protocolo MODBUS usado desde 1979 a los controladores lógicos
programables. La ventaja: MODBUS es un protocolo optimizado que garantiza una
transmisión de datos ETHERNET ultrarrápida. Una estructura de datos
independiente del fabricante hace posible la comunicación entre dispositivos de
distintos fabricantes.
La trama Modbus

Una trama en el sector de la comunicación, y más concretamente en los protocolos,


es una unidad de datos enviada entre dispositivos y cuyo conjunto conforma un
mensaje. Esto es, los bits de un mensaje.

Su formato es variable, influyendo en este tanto el propio protocolo con su capa


física de trabajo. Por ello, las tramas de mensajes de, por ejemplo, Modbus RTU y
Modbus TCP son diferentes, aunque sí parecidas.

Campos de una trama Modbus

Las tramas Modbus se identifican por una serie de campos, que son los siguientes:

● Device Address: Se trata de la dirección del dispositivo hacia el que el


emisor se está dirigiendo.
● Register Address: En este caso es a la que tenemos intención de acceder.
● Function Code: Es la función que el emisor habría de realizar.
● Number of Registers: Se trata del número de registros sobre los cuales se
debe realizar la función anterior.

Estos se envían siguiendo la secuencia Device/Function/Register/Number.


Además, se pueden añadir otros campos a continuación como es el Error Check,
bastante común. Este consiste en una verificación del mensaje enviado y recibido,
incluyendo un CRC que se compara para comprobar que el contenido no se ha
deformado.

Estos son los campos que nos encontramos en un Modbus cualquiera. Después,
dependiendo de si trabajamos con TCP, RTU, etc. Las tramas se pueden completar
con algunos otros.
Figura3.-Descripción grafica de Modbus

Figura4.-Mensajes Modbus

Dirección Modbus

El mensaje Modbus comienza con una dirección de destino de 8 bits. Esto puede
tomar cualquier valor de 0 a 247. Aquí 0 se usa como dirección de transmisión y el
resto se usa como direcciones de dispositivo único.
Funciones Modbus

El código de función contiene 2 caracteres (en modo ASCII) y 8 bits (en modo
RTU)/Toma cualquier valor de 1 a 255 y se selecciona según el perfil de la
aplicación.

Campo de datos de Modbus

Este campo de datos transmite información de nivel de aplicación según lo deseen


las diferentes funciones de Modbus. Si la función contiene tamaño variable de datos,
comienza con "recuento de bytes" en esta posición.

Trama Maestro
[ID][FUNCIÓN][DATO][CRC]
Para el maestro el campo dato está integrado por dos subcampos, la dirección y la
longitud. En la dirección se indica al esclavo en que dirección debe buscar lo que
se ha solicitado a través de la función y la longitud indica a partir de esa dirección
cuantos elementos se deben tomar.

Figura5.-Trama Maestro
Trama esclavo

[ID][FUNCIÓN][DATO][CRC]

La estructura se mantiene para el esclavo, pero nuevamente el cambio está en el


campo de Dato, pues aparecen dos subcampos que son: Número de bytes para dar
la respuesta y la respuesta en sí.

Figura6.-Trama Esclavo

Tamaño de la Trama
Es necesario analizar cada campo cuantos bits, Bytes o Words ocupan, para el caso
del Protocolo Modbus se organizan bloques de tamaño mínimo de Bytes como lo
muestra la siguiente estructura.
[1 Byte][1 Byte][nxByte][1 Byte][1 Byte]
El primer corchete es la dirección del esclavo (slave), con un Byte se pueden tener
valores entre 0 y 255 para colocar la dirección (ID) del equipo. El segundo corchete
es la función y con un Byte se tiene también la posibilidad de colocar valores entre
0 y 255 pero se debe tener en cuenta que no existen 256 funciones en el protocolo,
son menos ya lo veremos más adelante. El tercer corchete es el campo de dato y
es flexible dependiendo de si es un maestro o un esclavo. Y finalmente los últimos
dos corchetes son dedicados al CRC (Chequeo de Redundancia Cíclica).
Figura7.-Tamaño de la trama

MQTT
MQTT es un protocolo de mensajería ligero de publicación/suscripción diseñada
para telemetría M2M (máquina a máquina) en entornos de bajo ancho de banda.
Fue diseñado por Andy Stanford-Clark (IBM) y Arlen Nipper en 1999 para conectar
sistemas de telemetría de oleoductos por satélite. Aunque comenzó como un
protocolo propietario, fue liberado libre de regalías en 2010 y se convirtió en un
estándar OASIS en 2014.

MQTT significa MQ Telemetry Transport, pero anteriormente se conocía como


Message Queuing Telemetry Transport. MQTT se está convirtiendo rápidamente
en uno de los principales protocolos para despliegues de IOT (Internet de las cosas).

Es un interesante protocolo que se puede usar con nuestros Arduino o Raspberry


Pi para comunicarse con distintos sensores, uno de los campos donde mejores
resultados se pueden dar es en el de la domótica.

Figura8.-Descipción grafica MQTT


Cómo funciona MQTT

Una sesión MQTT se divide en cuatro etapas: conexión, autenticación,


comunicación y terminación. Un cliente comienza creando una conexión de
Protocolo de Control de Transmisión/Protocolo de Internet (TCP/IP) con el broker
utilizando un puerto estándar o un puerto personalizado definido por los operadores
del broker. Al crear la conexión, es importante reconocer que el servidor puede
continuar una sesión antigua si se le proporciona una identidad de cliente
reutilizada.

Los puertos estándar son 1883 para la comunicación no cifrada y 8883 para la
comunicación cifrada – usando Secure Sockets Layer (SSL)/Transport Layer
Security (TLS). Durante la conexión SSL/TLS, el cliente valida el certificado del
servidor y autentica el servidor. El cliente también puede proporcionar un certificado
de cliente al agente durante el apretón de manos. El agente puede utilizarlo para
autenticar al cliente. Aunque no es específicamente parte de la especificación
MQTT, se ha convertido en una costumbre que los agentes soporten la
autenticación de clientes con certificados SSL/TLS del lado del cliente.

Debido a que el protocolo MQTT tiene como objetivo ser un protocolo para
dispositivos con recursos limitados y dispositivos de IO, SSL/TLS puede no ser
siempre una opción y, en algunos casos, puede no ser deseado. En tales ocasiones,
la autenticación se presenta como un nombre de usuario y una contraseña en texto
claro, que son enviados por el cliente al servidor — esto, como parte de la secuencia
de paquetes CONNECT/CONNNACK. Además, algunos brokers, especialmente los
brokers abiertos publicados en Internet, aceptarán clientes anónimos. En estos
casos, el nombre de usuario y la contraseña simplemente se dejan en blanco.

MQTT se llama un protocolo ligero porque todos sus mensajes tienen una pequeña
huella de código. Cada mensaje consiste en un encabezado fijo — 2 bytes — un
encabezado variable opcional, una carga útil del mensaje que está limitada a 256
megabytes (MB) de información y un nivel de calidad de servicio (QoS).

Durante la fase de comunicación, un cliente puede realizar operaciones de


publicación, suscripción, des inscripción y ping. La operación de publicación envía
un bloque binario de datos (el contenido) a un tema definido por el editor.

MQTT soporta grandes objetos binarios de mensajes (BLOBs) de hasta 256 MB de


tamaño. El formato del contenido será específico de la aplicación. Las suscripciones
a los temas se realizan utilizando un par de paquetes SUBSCRIBE/SUBACK, y la
cancelación de la suscripción se realiza de forma similar utilizando un par de
paquetes UNSUBSCRIBE/UNSUBACK.

Los strings de temas forman un árbol temático natural con el uso de un carácter
delimitador especial, la barra oblicua (/). Un cliente puede suscribirse y cancelar la
suscripción a ramas enteras del árbol de temas utilizando caracteres comodines
especiales. Existen dos caracteres comodines: un carácter comodín de un nivel, el
carácter más (+); y un carácter comodín de varios niveles, el carácter de almohadilla
(#). Un carácter de tema especial, el carácter dólar ($), excluye un tema de cualquier
suscripción de comodín de raíz. Normalmente, $ se usa para transportar mensajes
específicos del servidor o del sistema.

Otra operación que un cliente puede realizar durante la fase de comunicación es


hacer ping al servidor del agente usando una secuencia de paquetes
PINGREQ/PINGRESP. Esta secuencia de paquetes se traduce aproximadamente
en ESTÁ USTED VIVO/SÍ ESTOY VIVO. Esta operación no tiene otra función que
la de mantener una conexión viva y asegurarse de que la conexión TCP no ha sido
cerrada por un gateway o router.

Cuando un editor o suscriptor quiere terminar una sesión MQTT, envía un mensaje
de DESCONEXIÓN al broker y luego cierra la conexión. Esto se llama un cierre
elegante porque le da al cliente la capacidad de reconectarse fácilmente
proporcionando su identidad de cliente y reanudando donde lo dejó.

En caso de que la desconexión se produzca de forma repentina y sin tiempo para


que un publisher envíe un mensaje de DESCONEXIÓN, el broker puede enviar a
los suscriptores un mensaje del publisher que el broker ha almacenado previamente
en caché. El mensaje, que se denomina última voluntad y testamento, proporciona
a los suscriptores instrucciones sobre lo que deben hacer si el editor muere
inesperadamente.

MQTT en IoT

El MQTT es uno de los protocolos más utilizados en relación con la Internet de las
Cosas. El MQTT permite que los dispositivos de IoT con recursos limitados envíen
o publiquen información sobre un tema determinado a un servidor que funciona
como un agente de mensajes MQTT. El servidor envía la información a los clientes
que se han suscrito previamente al tema. Para un humano, un tema tiene el
aspecto de una ruta de archivo jerárquica. Los clientes pueden suscribirse a un
nivel específico de la jerarquía de un tema o utilizar un carácter comodín para
suscribirse a varios niveles.
Figura9.-MQTT en IoT

Ventajas y desventajas de MQTT

MQTT tiene algunas ventajas y desventajas claras cuando se compara con los
protocolos de la competencia. Las ventajas incluyen lo siguiente:

1. transmisión de datos eficiente y rápida de implementar debido a que es


un protocolo ligero;
2. bajo uso de la red, debido a la minimización de los paquetes de datos;
3. distribución eficiente de los datos;
4. implementación exitosa de la teledetección y el control;
5. entrega de mensajes rápida y eficiente;
6. uso de pequeñas cantidades de energía, lo que es bueno para los
dispositivos conectados; y
7. reducción del ancho de banda de la red

Las desventajas de MQTT incluyen lo siguiente:

● MQTT tiene ciclos de transmisión más lentos en comparación con


CoAP.
● El descubrimiento de recursos de MQTT funciona con una suscripción
de temas flexible, mientras que CoAP utiliza un sistema estable de
descubrimiento de recursos.
● MQTT no está encriptado. En su lugar, utiliza TLS/SSL para el cifrado
de seguridad.
● Es difícil crear una red MQTT globalmente escalable.

Desarrollo
Inicialmente para el desarrollo de la presente práctica, es necesario tener un
fundamento básico en el manejo e inclusión de aquellos componentes necesarios
para establecer una comunicación MQTT y a su vez incluir una comunicación
MODBUS, entre dispositivos. Con base a lo mencionado, fue de vital ayuda la
inclusión y guía de videos que dieron lugar a esto. Desde la inclusión de la librería
MQTT de CODESYS, hasta lo que fue la correcta explicación de cada paso a
realizar en el mismo programa. En primera instancia, se procedió por el que mi
compañero y yo, instalamos y añadimos la librería “MQTT” en el software. Posterior
a esto, se es posible incluir un bloque de comunicación referente a este. El cual se
muestra de la siguiente manera:

Figura10.-MQTT Client
Inicial
En este mismo bloque se descartaron algunas terminales que no fueron necesarias
para esta práctica, las cuales fueron “i_sUsername”, “i_sPassword” y
“i_sWillRetain”. Por la tanto el bloque quedó configurado de la siguiente manera,
para ambos casos de nuestra programación:
Figura11.-MQTT Client RRAH

En la imagen anterior, se puede apreciar que en la terminal de “i_sBrokerAddress”,


se escribió la siguiente dirección: ‘broker.hivemq.com’. En la terminal siguiente
correspondiente a i_uiPort, fue necesario especificar el puerto 1883 y
correspondiente a las demás terminales se especificaron los caracteres necesarios
para lograr recibir y enviar datos. De entre esas terminales se destaca el
correspondiente a “i_sTopicPublish” y “isTopicSubscribe”, puesto que esas
terminales establecen caracteres relevantes para establecer la comunicacion
MQTT, por poner un ejemplo, en la imagen anterior se tiene primero el carácter “A”
y en Subscribe se tiene el carácter “B”, por su parte el otro bloque que tendrá el
compañero es necesario que estos caracteres están invertidos, es decir, que en
lugar de la letra “B” el tenga la letra “A” y en donde esta la letra “A” el tenga la letra
“B”, como lo es el siguiente caso:
Figura12.-MQTT 2 ARH

Una vez realizado lo anterior se facilitó el poder enviar mensajes con el tipo de dato
“STRING”, esto con el fin de comprobar la comunicación.
Una vez realizado lo anterior, se comenzó por establecer el código y las
configuraciones necesarias en este para poder ser comunicado con el mismo
software de CODESYS. Para este paso, se hizo uso de la tarjeta ESP8266, que
incluye un módulo capaz de conectarse vía Wi-Fi. En este mismo apartado fue
necesario la instalación de librerías, tales como, la librería correspondiente a la
tarjeta, la librería que corresponde a aquellas definiciones necesarias para la
comunicación MODBUS
Figura13.- Librerías Arduino

En el mismo código se procedió a declarar aquellos pines o terminales que


corresponden para nuestras entradas y salidas (2 indicadores y 2 pulsadores). En
este paso fue necesario recurrir a las especificaciones de cada PIN, la cual se tomó
de referencia la siguiente imagen:

Figura14.- Mapeo terminales


ESP8266

Como resultado se obtuvo la siguiente conexión:


Figura15.- Conexión Física 1

Figura16.- Conexión Física 2


Posteriormente, a esto, se comenzó por cargar el programa arduino previamente
configurado, en donde se concretaban aquellos registros necesarios para poder
establecer el registro de datos que se llegaran a manipular durante el proceso de
esta comunicación (MQTT y MODBUS).

Figura17.- Registros

Otro punto que no se debe descartar en la configuración del mismo código, es el


declarar nuestra conexión Wi-Fi, en donde se incluye la contraseña tal cual, es
punto de suma importancia si se desea ejecutar de buena manera la
comunicación.

Figura18.- Wi-Fi Password

Una vez realizada la carga de programa, es necesario verificar que nuestra tarjeta
se encuentra conectada correctamente al Wi-Fi. Así que para corroborar este paso,
es necesario desglosar o abrir la pestaña correspondiente a la terminal serial y así
mismo comprobar dicho punto.

Figura19.- Obtención IP Serial

Como siguiente paso, es necesario comenzar con agregar los dipositivos


correspondientes a la comunicación MODBUS, por lo que es necesario incluir, el
dispositivo ethernet en el que por consiguiente se agregara el dispositivo de
“Modbus TCP Master”, en el mismo agregar el dispositivo de esclavo con el nombre
de “Modbus TCP Slave”.

Figura20.- Add Device

Figura21.- Dispositivos Maestro / Esclavo

Al haber realizado el paso anterior, se procede por configurar los mismos


dispositivos agregados.
Figura22.- Interface Wi Fi

En ethernet, se especificó que la interfaz será del modo Wi-FI.

Figura23.- Auto-reconnect

En cuanto al dispositivo Master, es necesario marcar la casilla de “Auto-reconnect”.

Figura24.- Dirección Esclavo


Respecto a la configuración del dispositivo esclavo, es necesario e importante
declarar aquella dirección IP, que anteriormente se obtuvo de la terminal serial de
arduino, la cual es para este caso: “192.168.100.39”.
En el mismo apartado del dispositivo esclavo, es necesario agregar aquellos
canales que se utilizaran como registro, por lo tanto, será uno por cada entrada o
salida que se usará o emplea en la comunicación. Por ejemplo en la elaboración de
esta práctica se incluyeron 4 canales, dos para entradas y dos para salidas.
Quedando de la siguiente manera:

Figura25.- Canales I/O

Dos puntos relevantes por cada inclusión de canal, es configurar si será


correspondiente a lectura de registro o escritura de registro, a su vez, especificar a
qué registro corresponderá a la de arduino. Al incluir un canal es necesario
especificar el tipo de acceso, aunque anteriormente se mencionaba. Se tienen los
siguientes ejemplos para que este punto quede más claro.
Figura26.- Registro de lectura Figura27.- Registro de escritura

Figura28.- Registros 2

Una vez ingresados los datos necesarios, es normal visualizar que en el offset,
aparecerán los números hexadecimales, esto es normal, puesto que aquellos
números que se agregaron como el “100” y el “101”, el mismo software los cambio
a una dirección y a formato hexadecimal.
Finalmente se procede a declarar aquellas variables que serán asignadas para el
registro de escritura y lectura. Para la elaboración de esta práctica, los botones
corresponden a Read, dado que son entradas y los indicadores serán Write puesto
que serán salidas. Ambas variables se especificaron en tipo WORD.

Figura29.- Declaración de variables


I/O
Hasta ese punto ya se realizó la configuración para cada dispositivo de manera
correcta, lo siguiente es generar un arreglo, es decir, una programación que se
encarga de convertir variables y especificar ciertas condiciones para poder mandar
un dato que logre encender un indicador del compañero y viceversa. Por ello en la
rutina de MODBUS, se realizaron las siguientes condiciones:

Figura30.- Variables y Código

En la rutina anterior, se tienen aquellas variables que se utilizaron en el bloque


MQTT, tal como establecer la llegada del indicador y poder interpretarlo con base a
las configuraciones previamente realizadas. Por lo que inicialmente es necesario
realizar una conversión de string a word, tal y como se tiene en el apartado de la
rutina MQTT.

Figura31.- Conversión String to Word

Es aquí donde entra en juego la interpretación de datos que se reciben y envían,


por ejemplo al presionar un botón asignado por arduino, en el que al presionar se
enviará un “2” o un “4”, dependiendo cual de los dos botones se presionan esta
habilitará la comunicación y será enviado a CODESYS, dado que en esto consiste
esa transmisión de datos vía Wi-Fi, por el módulo que incluye la ESP8266.

Figura32.- Conversión Word to String


Figura33.- Condicionamiento de Indicadores y pulsadores

Así que al enviar un dos o un cuatro al presionar el boton correspondiente, éste será
enviado a la terminal siguiente, del bloque MQTT:

Figura34.- DatoConvert

Razones por las que se llama DatoConvert, es porque antes de ser enviado el dato
pasa de ser de tipo WORD a STRING, siendo el tipo de variable admitida por el
bloque.
Adicionalmente se incluyó una condición en la que se estableciera si el indicador 1
era igual a 2, habilitará una señal booleana, esta condición fue aplicada igualmente
para el indicador 2 con respecto al número cuatro, tal y como se muestra de la
siguiente manera:

Figura35.- Condición Booleana

Eso se debe a que aquella señal booleana resultante de dichas condiciones llegaría
habilitar una bobina que tiene como variable asignada de tipo BYTE, puesto que en
la misma práctica se procedió por comprobar la comunicación incluyendo el OPC
Server para Fluid SIM, por lo que fue necesario incluir una serie de pasos necesarios
para buildear dicha variable y que está fuera reconocida por Fluid Sim.
Figura36.- Variables OPC

Figura37.- Diagrama Neumatico


Para mayor comodidad al momento de enviar y recibir los datos, se diseñó una
interfaz virtual en el que sea habilitaran aquellos contactos correspondientes al
bloque MQTT. Tal y como se tiene a continuación

Figura38.- HMI
Resultados
Finalmente, se procedió por comprobar aquellos resultados finales, para este caso
uno sería el encargado de recibir datos y el otro se encargaría de recibirlos, así
que en primera instancia se cargó el software en CODESYS, estableciendo el
modo online y en ejecución, posteriormente se habilitó y se ejecutó FluidSIM. Lo
que se esperaba de este punto es el conseguir la activación de los leds
correspondientes y de la habilitación de las solenoides, dependiendo que dato se
recibiera, fuera un “2” o un “4”.

Figura39.- Estado ONLINE

En las siguientes imágenes se muestra el cómo se envía un dato, cabe mencionar


que es necesario presionar el PB físico y mientras se encuentra presionada habilitar
la señal de envío en el MQTT.
Figura40.- Envió de carácter

Figura41.- Envió de carácter 2


El encargado de enviar el dato para este caso tiene deshabilitado el de recibir.
Figura42.- Indicador Activo
Por otra parte al habilitar recibir, se tendrá el valor enviado por el otro programa, al
realizarlo de manera correcta comenzarán las condiciones establecidas de
conversión para que este interprete el dato recibido y a su vez sea registrado.
Se anexan las siguientes imágenes como evidencia de dicha comunicación
realizada:

Figura43.- Resultado FluidSIM


Figura44.- Resultado Recepción de dato

Figura45.- Cambio de movimiento


Figura46.- Indicador activo 2

Figura47.- Cambio de Indicador


Conclusiones

Previo a la elaboración de esta práctica se desconocía la comunicación MQTT, por


lo que al elaborarla tenía mis dudas si de completamente funcionaria, aunque lo que
respalda la información de la misma, es decir la explicación de su funcionamiento,
describe que se necesita como tal el elemento broker que será el destinado o el
encargado de la transmisión de mensajes una vez se especifiquen los puertos de
manera adecuada, dentro del software CODESYS. Al efectuarlo se corroboró que
realmente este tipo de comunicación está totalmente ligado al internet de las cosas,
siendo el medio para el que nosotros enviamos datos de un programa a otro, sin
tener que establecer una dirección IP o algo más en concreto. Por otro lado, en
cuanto a la comunicación MODBUS, se tenía previamente experiencia con este,
puesto fue una de las estadías, en el centro de investigación y desarrollo CIDESI,
se emplean muchos productos en los que se logre la comunicación de los
dispositivos por medio de direcciones IP esta comunicación logre estar supervisada
en distintos ámbitos, dado su funcionamiento y la información que es necesaria para
estar al tanto del control del mismo proceso o proyecto. Con MODBUS se entiende
el concepto básico en el que el maestro pide información y el esclavo es quien se
encarga de obtener o de mandar dicha información, para el caso de esta práctica el
esclavo era la tarjeta ESP8266, el maestro como tal era el mismo programa
desarrollado en CODESYS.
Referencias

Avila, E. R. (25 de 02 de 2018). UTB.EDU. Obtenido de


https://biblioteca.utb.edu.co/notas/tesis/0063148.pdf
Standard, A. N. (2012). Obtenido de
http://webdelprofesor.ula.ve/ingenieria/oscaror/CursosDictados/Sobre%2
Andhurta. (12 de Enero de 2022). Protocolo Modbus. Obtenido de EEYMUC:
https://www.eeymuc.co/31-protocolo-modbus/#título4
A. (2022, 4 januari). Modbus: Qué es y cómo funciona. aula21 | Formación para la

Industria. Geraadpleegd op 15 maart 2022, van

https://www.cursosaula21.com/modbus-q (Andhurta, 2022)ue-es-y-como-funciona/

R. (2020, 20 april). MQTT, Qué es, ¿cómo se puede usar? y Cómo funciona.

Descubrearduino.com. Geraadpleegd op 15 maart 2022, van

https://descubrearduino.com/mqtt-que-es-como-se-puede-usar-y-como-funciona/

F. (2018, 27 augustus). Protocolos de comunicación: tramas Modbus | TCP & RTU.

Vester training. Geraadpleegd op 15 maart 2022, van

https://vestertraining.com/blog/tramas-modbus/

También podría gustarte