PRUEBAS CON SIMULADOR MODBUS SLAVE Y FLUJÓMETRO TUF -2000M.

Jean Carlos Villegas.

Proyecto comunitarias.

1
PRUEBA 1 MODBUS SLAVE: COMPONENTES.
El objetivo de realizar esta prueba es para validar que tanto el software como el
hardware implementado es el correcto donde se necesitó de los siguiente
elementos:

1. Protoboard.
2. Cables de conexión.
3. Convertidor RS485MAX. (RS485 - TTL).
4. Convertidor RS485 – USB (Protocolo UART).
5. Arduino Mega.
6. Software Modbus Slave.

2
PRUEBA 1 MODBUS SLAVE: CONEXIONES.
Para esta prueba fue necesario
utilizar un convertidor RS485 a USB
con el objetivo de que la información
que envía el ARDUINO MEGA la reciba
2 el software MODBUS SLAVE.

3
4

3
PRUEBA 1 MODBUS SLAVE: CÓDIGO IMPLEMENTADO.

4
PRUEBA 1 MODBUS SLAVE: RESULTADOS.

Comunicación serial sin paridad. Comunicación serial con paridad impar.

5
PRUEBA 1 MODBUS SLAVE: EVIDENCIA.

6
PRUEBA 2 FLUJÓMETRO: COMPONENTES.
Una vez verificado el correcto funcionamiento del hardware implementado y
software en la prueba anterior entonces se utilizó un programa similar pero esta
vez se consideró leer el registro 0X20 (temperatura inlet  Ver manual del
sensor) y un número de registros a leer de 2, con el objetivo de nuevamente
validar si existe un problema de comunicación con el sensor, por otro lado, los
componentes que se utilizaron fueron los siguientes:

1. Protoboard.
2. Cables de conexión.
3. Convertidor RS485MAX. (RS485 - TTL).
4. Flujómetro TUF2000M.
5. Arduino Mega 2560.
6. Fuente de 24V.

7
PRUEBA 2 FLUJÓMETRO: CONEXIONES.
1. Convertidor RS485MAX. (RS485 - TTL).
2. Flujómetro TUF2000M.
3 3. Arduino Mega 2560.
4. Fuente de 24V.

Nota: Para la comunicación con el flujómetro

fue muy importante utilizar un arduino mega
que un arduino uno ya que dispositivos que
2 1 siguen el estándar Modbus RTU no son
compatible con puertos seriales por software
mediante comunicación sin paridad, dando
como resultado error tipo E2 que más
4 adelante se indica el significado.

8
PRUEBA 2 FLUJÓMETRO: MODIFICACIONES EN EL SENSOR.
Antes de establecer comunicación con Arduino es necesario hacer modificaciones en la
comunicación del flujómetro.

Modificación al protocolo
Parámetros del puerto
MODBUS RTU en la
serial pantalla 62.
pantalla 63.

9
PRUEBA 2 FLUJÓMETRO: RESULTADO (1).

En la figura izquierda se observa que la comunicación no es

estable ya que hay datos que se intercambia pero hay
instantes que se presenta un error tipo E0 cuyo significado
se encontró en la librería de MODBUSMASTER.

10
 PRUEBA 2 FLUJÓMETRO: TIPOS DE ERRORES MODBUSMASTER.

En las pruebas se presentó un error tipo E2 el cual se asocia a que se terminó el tiempo de respuesta
para que envíe la información el slave, esto se puede deber porque está mal implementado el
conexionado o la conexión tiene falsos contactos, por otro lado, el error E0 se asocia a que no existe
una identificación ID del slave entre solicitud y respuesta, tal vez se debe por los delay() y cambios
rápido en las mediciones del sensor en el momento que se solicita su registro.
Fuente: https://4-
20ma.io/ModbusMaster/group__constant.html#ga19521b4671bdc1ded03af72e2f3b958e
11
PRUEBA 2 FLUJÓMETRO: CÓDIGO IMPLEMENTADO.
En la programación se consideró tomar lectura del flujo y las temperaturas inlet y outlet
que corresponde a los registros que se resaltan en la siguientes tablas.

Fuente: https://4-
20ma.io/ModbusMaster/group__constant.html#ga19521b4671bdc1ded03af72e2f3b958e
12
PRUEBA 2 FLUJÓMETRO: CÓDIGO IMPLEMENTADO.
Nota: En la programación se consideró configurar el puerto serial con paridad impar y delay
de 1.5 segundos ya que eran los parámetros que mejor se estabilizaba para efectuar una
adecuada comunicación entre el sensor con arduino.

13
PRUEBA 2 FLUJÓMETRO: CÓDIGO IMPLEMENTADO.

14
PRUEBA 2 FLUJÓMETRO: RESULTADOS(2).

Se evidencia que la comunicación MODBUS si se

establece entre el flujómetro con arduino pero
cabe destacar que cada lectura se presenta cada 3
segundos mientras que el offset entre la medición
de flujo y temperatura es de 1.5 segundos, sino se
respetan mínimo estos tiempo se observó que la
lectura de flujo o temperatura no se daba.

15
PRUEBA 2 FLUJÓMETRO: EVIDENCIA.

16
CONSLUSIONES Y RECOMENDACIONES.
 Una de las consideraciones que se debe tomar en cuenta en la implementación es que si
un dispositivo sigue el estándar modbus, este no se podrá comunicar vía serial sin paridad
por lo cual utilizar un puerto serial en SOFTWARE no es útil sino se requiere a nivel de
HARWARE.

 Se utilizó un ARDUINO MEGA ya que cuenta con más de un puerto serial donde no fue
necesario utilizar la librería SOFTWARESERIAL con esto se consiguió una excelente
comunicación con el simulador mientras que en el fluxómetro a veces se presentaba un
error tipo E0.

 Con base a la información extraída de la librerí MODBUSMASTER se determinó que el error

tipo E0 se debe a que la identificación ID_SLAVE no sabe coincidir entre la petición con la
respuesta, esto se puede deber a que en el instante que el flujómetro envía la respuesta
existan variaciones en la trama de datos.

17
CONSLUSIONES Y RECOMENDACIONES.
 Se evidenció que los retardos que se utilizan en la programación (delay()) son sensibles
con la lectura del flujómetro presentado el error E0 mientras que en MODBUSSLAVE no se
evideció ese problema.

 Se mejoró la comunicación con el flujómetro cambiando los parámetros del puerto serial a
una velocidad de transmisión de 9600 bps, paridad impar, 8bits datos y 1 bit de parada.

 Se presentó los resultados de ambas simulaciones donde se evidenciaron una buena

adquisición de los datos que serán útil para el envío de la información con los módulos
LORA.

18
19