Documentos de Académico
Documentos de Profesional
Documentos de Cultura
MATERIA
SISTEMAS DE MANUFACTURA FLEXIBLE
DOCENTE
HERNANDEZ ZUÑIGA RAÚL
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
¿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.
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.
● Modbus RTU
● Modbus TCP
● Modbus ASCII
● Modbus Plus
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
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.
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).
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.
Características principales
Las tramas Modbus se identifican por una serie de campos, que son los siguientes:
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.
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]
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.
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).
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.
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ó.
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
MQTT tiene algunas ventajas y desventajas claras cuando se compara con los
protocolos de la competencia. Las ventajas incluyen lo siguiente:
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
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
Figura17.- Registros
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.
Figura23.- Auto-reconnect
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.
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:
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
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”.
R. (2020, 20 april). MQTT, Qué es, ¿cómo se puede usar? y Cómo funciona.
https://descubrearduino.com/mqtt-que-es-como-se-puede-usar-y-como-funciona/
https://vestertraining.com/blog/tramas-modbus/