modbus

67
Universidad de Costa Rica Facultad de Ingeniería Escuela de Ingeniería Eléctrica IE 0502 Proyecto Eléctrico Desarrollo de programas de comunicaciones para un sistema inteligente de control de iluminación Por: José Leandro Gamboa Alvarado Ciudad Universitaria Rodrigo Facio Julio de 2011

Transcript of modbus

Page 1: modbus

Universidad de Costa Rica

Facultad de Ingeniería

Escuela de Ingeniería Eléctrica

IE – 0502 Proyecto Eléctrico

Desarrollo de programas de comunicaciones para un sistema inteligente de

control de iluminación

Por:

José Leandro Gamboa Alvarado

Ciudad Universitaria Rodrigo Facio

Julio de 2011

Page 2: modbus

i

Desarrollo de programas de comunicaciones para un sistema inteligente de

control de iluminación

Por:

José Leandro Gamboa Alvarado

Sometido a la Escuela de Ingeniería Eléctrica

de la Facultad de Ingeniería

de la Universidad de Costa Rica

como requisito parcial para optar por el grado de:

BACHILLER EN INGENIERÍA ELÉCTRICA

Aprobado por el Tribunal:

_________________________________________________

Ing. Geovanny Delgado C., M.Sc.E.E.

Profesor Guía

____________________________________________ ___________________________________

Ing. Marco A. Vásquez E., M.Sc.E.E. Ing. Juan R. Rodríguez S.

Profesor lector Profesor lector

Page 3: modbus

ii

DEDICATORIA

Primeramente a mis padres y también a mis otros familiares que me han ayudado de una y otra

manera en este proceso universitario.

Page 4: modbus

iii

RECONOCIMIENTOS

Primeramente a los ingenieros: Ing. Geovanny Delgado C, y al Ing. Marco A. Vásquez E, por

haberme confiado este proyecto y también porque en el proceso de desarrollo del mismo,

siempre encontré un consejo y apoyo para salir adelante. Realmente gracias por cada enseñanza

que me brindaron ya que estas me ayudaron a crecer más desde el punto de vista académico y

profesional.

Por último a los que fueron mis profesores en la escuela de Ingeniería Eléctrica de la Universidad

de Costa Rica.

Page 5: modbus

iv

ÍNDICE GENERAL

1. CAPÍTULO 1: Descripción del problema............................................................................................. 1

1.1 Objetivos ....................................................................................................................................... 4

1.1.1 Objetivo General ................................................................................................................... 4

1.1.2 Objetivos Específicos ............................................................................................................ 4

1.2 Metodología .................................................................................................................................. 5

2. CAPÍTULO 2: Desarrollo Teórico ....................................................................................................... 6

2.1 Controladores Lógicos programables ................................................................................................. 6

2.1.1 Aspectos Generales ...................................................................................................................... 6

2.1.3 Historia ......................................................................................................................................... 7

2.1.4 Ventajas y desventajas de los PLC .............................................................................................. 8

2.2 Comunicaciones ................................................................................................................................ 10

2.2.1 Clasificaciones en las comunicaciones ...................................................................................... 11

2.2.1.1 Transferencia de información serial .................................................................................... 11

2.2.1.2 Transferencia de información paralela ................................................................................ 13

2.2.2 Detección de errores en la comunicación................................................................................... 14

2.2.3 Comunicación Maestro – Esclavo .............................................................................................. 15

2.2.3.1 Parámetros en una transacción maestro-esclavo ................................................................ 16

2.2.4 Protocolos de comunicación ...................................................................................................... 17

2.2.4.1 Clasificación de los protocolos ........................................................................................... 18

2.2.4.2 Protocolo MODBUS .......................................................................................................... 19

2.2.4.2.1 Definición .................................................................................................................... 19

2.2.4.2.2 MODBUS RTU y MODBUS ASCII ........................................................................... 20

2.2.4.2.3 Descripción general del protocolo MODBUS ............................................................. 21

2.2.4.2.4 Codificación de la información .................................................................................... 23

2.2.4.2.5 MODBUS Modelo de Información .............................................................................. 24

2.2.4.2.6 MODBUS Modelo de direccionamiento ...................................................................... 25

2.2.4.2.7 Definición de la transferencia en MODBUS ............................................................... 26

2.2.4.2.7 Categoría de los códigos de Función ........................................................................... 27

2.3 Aspectos Básicos del estándar RS-485 ............................................................................................. 29

Page 6: modbus

v

2.3.1 Definición RS-485 ..................................................................................................................... 29

2.3.2 Funcionamiento del estándar RS-485 ........................................................................................ 29

2.3.3 Ventajas y desventajas entre “doble cable” y “cuatro cables” ................................................... 30

2.3.4 Para qué el estándar RS-485 hace uso del “cable tierra” ........................................................... 30

2.3.5 Características generales de RS-485 .......................................................................................... 31

3. CAPÍTULO 3: Análisis de la solución desarrollada ........................................................................... 32

3.1 Registros utilizados en la máquina de comunicaciones .................................................................... 33

3.2 Esquema de transferencia de la información .................................................................................... 35

3.2.1 Solicitud en módulo central o maestro ....................................................................................... 36

3.2.2 Solicitud en un módulo de extensión ........................................................................................ 37

3.3 Herramientas utilizadas para realizar la comunicación .................................................................... 38

3.3.1 Tablas de comunicaciones ......................................................................................................... 38

3.3.1.1 Estructura de una tabla de comunicaciones ........................................................................ 38

3.3.1.2 Tablas utilizadas en la máquina de comunicaciones ........................................................... 39

3.3.2 Control a nivel de comunicación ........................................................................................... 40

3.4 Máquina de comunicaciones ............................................................................................................. 42

3.4.1 Análisis por partes de la máquina de comunicaciones .............................................................. 44

3.4.1.1 Contador .............................................................................................................................. 44

3.4.1.2 Control y sincronización en las comunicaciones ................................................................ 45

3.4.1.3 Transferencia ante un cambio en el registro RO y ROU del módulo maestro .................... 46

3.4.1.4 Transferencia ante un cambio en el registro RO y ROU de algún módulo de extensión .... 48

3.4.1.5 Difusión de la hora del día y hora de apagado maestro automático .................................... 49

4. CAPÍTULO 4: Conclusiones y recomendaciones ............................................................................... 50

4.1 Conclusiones ..................................................................................................................................... 50

4.2 Recomendaciones ............................................................................................................................. 51

BIBLIOGRAFIA .............................................................................................................................................. 53

APÉNDICES............................................................................................................................................... 55

Apéndice 1. Tabla de comunicaciones completas................................................................................... 55

Page 7: modbus

vi

ÍNDICE DE FIGURAS

Figura 1. Arquitectura del sistema de PLC propuesto. ................................................................................. 2

Figura 2. Diagrama de bloques de un sistema de comunicación digital ..................................................... 10

Figura 3. Formato de un carácter a nivel serie-asincrónico ........................................................................ 11

Figura 4. Formato de transmisión paralela. ................................................................................................. 13

Figura 5. Aplicación de comunicación MODBUS ..................................................................................... 20

Figura 6. Trama genérica del mensaje según el código empleado .............................................................. 21

Figura 7. Trama general en MODBUS ....................................................................................................... 21

Figura 8. Transacción libre de error ............................................................................................................ 22

Figura 9. Transacción no libre de error ....................................................................................................... 23

Figura 10. Modelo de direccionamiento ..................................................................................................... 25

Figura 11. Diagrama de estado de transferencia MODBUS ....................................................................... 26

Figura 12. Esquema de comunicaciones. .................................................................................................... 35

Figura 13. Máquina de comunicaciones. .................................................................................................... 43

Figura 14. Contador de la máquina de comunicaciones ............................................................................. 45

Figura 15. Control y sincronización en la máquina de comunicaciones ..................................................... 46

Figure 16. Secuencia a seguir ante un cambio a los registros RO y ROU en el módulo central ................ 47

Figura 17. Secuencia a seguir ante un cambio en RO y ROU en un módulo de extensión. ....................... 48

Figura 18. Difusión de la hora del día y hora de apagado maestro automático. ......................................... 49

ÍNDICE DE TABLAS

Tabla 1. Modelo de información soportado por MODBUS ........................................................................ 24

Tabla 2. Códigos de funciones públicas en MODBUS ............................................................................... 28

Tabla 3. Características del RS-485 ............................................................................................................ 31

Tabla 4. Difusión de escritura de palabras operacionales de control del modulo central. .......................... 55

Tabla 5. Lectura de palabras de control de cualquier modulo de extensión. .............................................. 55

Tabla 6. Difusión de escritura por cambios en palabras de control leídas en algún módulo de extensión. 56

Tabla 7. Comando de escritura para borrar palabras de control en un módulo de extensión...................... 56

Tabla 8. Comando de difusión de los registros que contienen la hora actual del día y hora de apagado

maestro automático ..................................................................................................................................... 57

Page 8: modbus

vii

NOMENCLATURA

PLC: (Programmable Logic Controller) Controladores Lógicos Programables

MC: Módulo Central

MX: Módulos de Extensión

«: Transferencia de registro

<>: Diferente

ROMC: Registro de Operaciones en el Módulo Central

ROMX: Registro de Operaciones en el Módulo de eXtension

ROUMC: Registro de Operaciones de Unión de luces en el Módulo Central

ROUMX: Registro de Operaciones de Unión de luces en el Módulo de eXtension

RCMC: Registro de Control en el Módulo Central

RCMX: Registro de Control en el Módulo de eXtension

RCUMC: Registro de Control de Unión de luces en el Módulo Central

RCUMX: Registro de Control de Unión de luces en el Módulo de eXtension

RTU: Unidad terminal remota (del inglés “Remote Terminal Unit”).

TCP/IP: Protocolo de control terminal/ protocolo internet (de inglés “Terminal

Control Protocol / Internet Protocol”).

Page 9: modbus

viii

B-S: Bit menos significativo.

B+S: Bit más significativo

MODBUS: Protocolo de comunicaciones.

RS-485: Estándar de transmisión serial asincrónico

ISO: Norma estándar.

Page 10: modbus

ix

RESUMEN

El presente trabajo muestra la solución de comunicaciones que se desarrolló para un

sistema de control de iluminación. El sistema en general está bajo una arquitectura jerárquica

maestro-esclavo.

Para la solución propuesta, se utilizó el protocolo MODBUS RTU y el estándar RS-485,

todo sobre el autómata Twido Suite de la marca Schneider.

La metodología utilizada para la solución, fue basada en el uso de una máquina de

estados, luego de tener la descripción esta máquina se procedió a escribir el código de programa

en lenguaje Ladder que posteriormente se puso a prueba en conjunto con todo el sistema de

iluminación, con el fin de depurarlo y dejar la máquina funcionando al correctamente.

Los resultados obtenidos fueron positivos ya que se logró cumplir con la totalidad de los

objetivos. La máquina funciona correctamente y representa una solución robusta para dicho

problema, pero además de esto, también sirve de paradigma para otras aplicaciones similares a

esta.

En general, el presente proyecto integra diferentes áreas de la ingeniería eléctrica

importantes, como lo son comunicaciones, sistema de iluminación y control automático por

medio de PLC.

Page 11: modbus

1

1. CAPÍTULO 1: Descripción del problema

Hoy en día la aplicación de la tecnología en el campo de la automatización está llegando

a niveles que quizás en un inicio no fueron considerados, tal es el caso de la iluminación.

Actualmente el potencial de los “controladores lógicos programados” (PLC por sus siglas en

inglés) está siendo aprovechado en diversas áreas donde la automatización así lo permite. Estos

autómatas por sus características, han servido de un gran aporte debido a su bajo costo y

versatilidad para adaptarse a diversos sistemas o proyectos.

En el presente trabajo, se muestra una aplicación de control inteligente de iluminación

por medio del PLC Twido Suite de Schneider.

Los sistemas de iluminación, en general tienen involucrados una alta cantidad de

elementos, entiéndase por elementos todos aquellos “puntos” dedicados para adaptar un

dispositivo de iluminación. Por ejemplo si se tiene una casa habitación, se sabe que muy

probablemente tiene 20 o más puntos dedicados para la iluminación, ahora si se considera un

edificio, se tiene por seguro que existirá una cantidad grande de puntos de iluminación.

El autómata Twido Suite, con el que se lleva a cabo el control, tiene 24 entradas y 16

salidas, ahora bien, si se considera que cada salida está destinada a controlar un punto de

iluminación específico, se hace evidente que controlar un sistema de iluminación completo con

un solo autómata no es posible. Entonces la pregunta es: ¿Cómo controlar un sistema que tenga

más de 16 puntos de iluminación?.

La solución a esta pregunta es muy sencilla, ya que el problema se soluciona utilizando la

cantidad necesaria de autómatas, por ejemplo si se utilizan 2 autómatas, la capacidad del sistema

Page 12: modbus

2

sería de controlar hasta 32 puntos de iluminación, por tanto para esto tendríamos una arquitectura

del sistema como se muestra en la figura 1.

Figura 1. Arquitectura del sistema de PLC propuesto.

El hecho de utilizar más de un autómata no quiere decir que cada autómata trabajará

independientemente uno del otro, más bien lo que se pretende hacer, es un sistema integrado que

involucre a cada autómata, esto es, que si una acción se da en un autómata, esta acción debe

afectar directa o indirectamente a todos los otros módulos del sistema de iluminación. Por tanto

en este punto la pregunta sería: ¿Cómo hacer para que los autómatas del sistema de iluminación

trabajen de forma conjunta?.

La respuesta a esta pregunta es: estableciendo un sistema de comunicación entre los

autómatas del sistema de iluminación que les permita intercambiar información, esto puede ser

Page 13: modbus

3

observado en la figura 1. Por lo tanto lo queda por hacer, es diseñar este sistema de

comunicación.

Todo el diseño integral de dicho sistema, es desarrollado en el presente proyecto y

expuesto en este informe.

De forma general se tiene que el diseño del sistema comprende del desarrollo de

programas de comunicaciones entre un Módulo Central (MC) de control y diferentes Módulos de

Extensión (MX), así como también la integración de los fundamentos de las máquinas

secuenciales, con el fin de representar adecuadamente el proceso de automatismo llevado a cabo

por el PLC.

El desarrollo de estos programas es basado en el lenguaje de programación en escalera y

además de esto, es importante señalar que antes de la ejecución de este trabajo ya se contaba con

los programas para el control de iluminación completos para el MC y el MX, pero se hicieron

pequeñas modificaciones cuando fue necesario con el fin de que los programas de

comunicaciones pudiesen dar el desempeño esperado en conjunto con todo el sistema de

iluminación.

La información que es necesaria transmitir entre los módulos proviene de dos maneras

diferentes, ya sea que un módulo por lógica interna necesite transmitir una información a los

demás módulos, o que se dé una solicitud en un módulo específico que afecta a todo el sistema

de iluminación y por ende esa petición debe ser comunicada a todos los autómatas del sistema.

Page 14: modbus

4

Por último para la solución planteada se utilizó el protocolo MODBUS RTU y el estándar

RS-485 en donde ambos por sus características logran que la solución planteada por medio de

una máquina secuencial funcione de manera adecuada.

1.1 Objetivos

1.1.1 Objetivo General

Desarrollar los programas de comunicaciones entre el Módulo Central y los Módulos de

Extensión, de un control inteligente de iluminación basado en PLCs, para que operen de manera

integrada y sincronizada transmitiéndose información entre módulos.

1.1.2 Objetivos Específicos

Estudiar los conceptos, componentes y procedimientos requeridos para realizar

automatismos con PLCs.

Aprender a aplicar los conocimientos de síntesis de máquinas secuenciales en PLCs.

Aprender a programar en lenguaje de programación en escalera.

Realizar todos los programas de comunicaciones requeridos para integrar los módulos

de control del sistema inteligente de control de iluminación en una familia específica

de PLCs.

Page 15: modbus

5

1.2 Metodología

Para la realización de este proyecto primeramente se realizó una revisión bibliográfica

sobre los aspectos teóricos relacionados con los temas de: Controladores lógicos programables,

Comunicaciones, protocolo MODBUS y el estándar RS-485.

Luego se planteó formalmente el problema a solucionar, después de esto se procedió a

solucionarlo mediante el uso de una máquina de estados.

Una vez descrita la máquina de estados por medio de un diagrama ASM se continuó la

programación de la misma por medio del lenguaje de escalera, siempre respetando la estructura

de programación del controlador lógico programable Twido Suite de la marca Schneider.

Luego de tener el programa el mismo se puso a prueba, mediante un protocolo de

evaluación previamente establecido, poco a poco se fue depurando hasta dejar la máquina

funcionando de acuerdo a los requerimientos establecidos.

Page 16: modbus

6

2. CAPÍTULO 2: Desarrollo Teórico

2.1 Controladores Lógicos programables

2.1.1 Aspectos Generales

Los controladores lógicos programables (PLC, en inglés Programmable Logic Controller)

son dispositivos con la capacidad de controlar funciones mediante una lógica brindada por un

programador [1]. Estos dispositivos son el resultado de la búsqueda de construir un controlador

de bajo costo, versátil y de fácil aplicación [2] que permitiera remplazar los controles industriales

clásicos que usualmente estaban basados en el uso de relés electromecánicos o por medio de

bloques lógicos cableados [1].

Los PLC’s operan mediante la continua revisión de las señales de entrada, que mediante

la lógica interna programada, generan señales de salida que permiten que un proceso o sistema

complejo pueda ejecutarse de manera eficiente y eficaz. A nivel interno estos dispositivos

contienen funciones tales como contadores, cambiadores (shift) de registro y temporizadores [2],

secuenciación y operaciones aritméticas.

La capacidad de los PLC’s para controlar sistemas es amplia, debido a que tiene la

capacidad de manipular dispositivos en donde las salidas o entradas se definan dentro los estados

de encendido y apagado, lo cual es conocido también como señales discretas o digitales, además

de este tipo de señales también tienen la capacidad de procesar variables analógicas [3], por lo

tanto por esta características es que son considerados como sistemas híbridos.

Page 17: modbus

7

2.1.3 Historia

Los PLC fueron primeramente concebidos por un grupo de ingenieros de General Motors

en el año 1968. Originalmente los PLC’s fueron representados por el acrónimo PC, pero debido a

confusiones con el término personal computer es que se decidió cambiar el nombre a PLC [3].

Los criterios que se utilizaron en la creación de estos equipos fueron varios. los cuales

corresponden a:

Elaborar una máquina que fuese fácil de programar. En donde esta tuviese

secuencias de operaciones con capacidad de ser alteradas fácilmente y preferiblemente a

nivel de planta.

Máquina de fácil mantenimiento y de reparación bajo el formato de plug-in.

Tiene que tener la capacidad de operación más fácil a nivel de planta que a nivel

de “relay control panel”.

Físicamente deben ser más pequeños que “relay control panel”, esto con el fin de

ahorrar espacio.

Capacidad de compartir información en una colección de sistemas.

Tiene que ser competitiva a nivel de costo en comparación con el sistema de relés

y tecnología de estado sólido.

El estándar de los controladores programables es la NEMA Standard ICS3-1978.

Actualmente existe una vasta cantidad de fabricantes de PLC que es difícil de describir cada una

por separada, pero lo que sí es bueno de resaltar es que todas las máquinas de PLC son basados

Page 18: modbus

8

en los mismos principios lo cual permite que la compresión de cada máquina sea de manera

sistemática.

2.1.4 Ventajas y desventajas de los PLC

A continuación se definen las principales ventajas de los PLC.

1. Flexibilidad: son capaces de controlar diferentes máquinas al mismo tiempo con

un solo PLC, a diferencia con el pasado esta aplicación era imposible.

2. Implementación de cambios y corrección de errores: en el pasado realizar un

cambio implicaba realizar alteraciones a nivel del panel de control de los dispositivos lo

cual implicaba mucho tiempo en ciertos casos. Ahora con los PLC se pueden hacer

cambios y corrección de errores a partir de una interfaz simple y que implica mínima

cantidad de tiempo.

3. Gran Cantidad de Contactos: Los PLC tiene una gran cantidad de contactos por

bobina disponibles en su programación.

4. Bajo Costo: A pesar de ser una tecnología revolucionaria que incluye relés,

temporizadores, contadores y secuenciadores el costo a nivel de mercado es bajo.

5. Observación visual: los sistemas de PLC presentan la capacidad de ser

monitoreados en tiempo de ejecución, lo cual representa una gran ventaja ya que permite

visualizar opciones de para depurar una aplicación.

6. Evaluación piloto (running pilot): presentan la disponibilidad de realizar

pruebas de verificación antes de ser probado en un sistema a escala real, lo cual permite

protección de equipos y alta eficiencia.

Page 19: modbus

9

7. Velocidad de Operación: los sistemas de relés en el pasado necesitan una

cantidad de tiempo inaceptable para trabajar eficientemente. Ahora con los PLC se

alcanzan velocidades rápidas de acción.

8. Métodos de programación Ladder o Booleano: es flexible a nivel de los

métodos de programación.

9. Mantenimiento: a nivel de costos, si se comparan con los gastos que se tenían

con los paneles de relés con respecto a los PLC, la diferencia es grande, además de que

los tiempos de mantenimiento es mínima.

10. Documentación: Los PLC presentan la capacidad de representar información a

tiempo real de las operaciones que realizan, y también a nivel técnico se encuentra

fácilmente las especificaciones de las operaciones.

11. Seguridad: Las secuencias programadas en los PLC son solamente configurables

por una persona que tenga acceso al sistema, de lo contrario el sistema siempre actuará de

la manera indicada como correcta.

También los PLC presentas desventajas a nivel de preparación de personal, ya que por ser

tecnológicamente innovador en comparación con lo que se tenía en el pasado, es necesario el

entrenamiento en la tecnología de cada fabricante. Además en ciertas ocasiones invertir en PLC

no es una opción viable si se considera para operaciones simples que pueden ser realizadas por

otros métodos. Muchas veces también la implementación de soluciones con PLC’s se ve limitada

por las condiciones es que esta trabajaría, como por ejemplo la temperatura, exposición a

vibraciones y también de interferencia magnéticas.

Page 20: modbus

10

2.2 Comunicaciones

La Comunicación [8] es la transferencia de información con sentido desde un lugar

(remitente, fuente, originador, transmisor) a otro lugar (destino, receptor). Por otra

parte Información es un patrón físico al cual se le ha asignado un significado comúnmente

acordado. El patrón debe ser único (separado y distinto), capaz de ser enviado por el transmisor,

y capaz de ser detectado y entendido por el receptor.

Para llevar a cabo la comunicación de la información en sistemas tecnológicos se

implementan diversas técnicas, protocolos, medios, etc. Pero a pesar de esto, siempre se cumple

con un esquema básico y fundamental para llevar a cabo con eficiencia la comunicación. En la

figura 2 se muestra el diagrama de bloques de un sistema de comunicación digital genérico. Cada

uno de los bloques mostrados son modelados matemáticamente con el fin de analizar, diseñar y

comparar sistemas entre sí. La modelación matemática se lleva a cabo por medio del uso de la

teoría de la información, la cual tiene sus inicios con C.E. Shannon en 1948.

Figura 2. Diagrama de bloques de un sistema de comunicación digital [11]

Transductor de entrada

Transmisor

Canal

Receptor

Transductor de Salida

Mensaje de entrada

Mensaje de Salida

Señal eléctrica

de entrada

Señal eléctrica de

salida

Señal trasmitida

Señal recibida

Page 21: modbus

11

2.2.1 Clasificaciones en las comunicaciones

Los bits en la información binaria son comúnmente transferidos entre dispositivos

electrónicos por cambios en corriente o en voltaje. La información puede ser transferida de

manera “serial” sobre una única línea, o puede ser en “paralelo” sobre varias líneas. La

transferencia puede ser “síncrona” en la cual la llegada o salida de información de cada bit en el

plano del tiempo puede ser predecible, o también la transferencia puede ser “asíncrona”, en

donde la transferencia de la información se hace de manera no uniforme [4].

2.2.1.1 Transferencia de información serial

Síncrona

En la comunicación serial sincronía, además de una línea sobre la cual se transmitirán los

datos, se necesita de una línea la cual contendrá los pulsos de reloj que indicaran cuando un dato

es válido [6].

Asíncrona

En la comunicación serial asíncrona, no son necesarios los pulsos de reloj. La duración de

cada bit está determinada por la velocidad con la cual se realiza la transferencia de datos. En la

figura 3 muestra la estructura de un caracter que se trasmite en forma serial asíncrona [6].

Figura 3. Formato de un carácter a nivel serie-asincrónico

REPOSO

B-S

B+S

Page 22: modbus

12

Normalmente cuando no se realiza ninguna transferencia de datos, la línea del transmisor

se encuentra en estado de reposo, es decir en estado alto.

Para iniciar la transmisión de datos, el transmisor coloca esta línea en bajo durante

determinado tiempo, lo cual se le conoce como bit de arranque y a continuación, empieza a

transmitir durante un intervalo de tiempo los bits correspondientes al dato, empezando siempre

por el bit menos significativo (B-S), y terminando con el bit más significativo (B+S).

Si el receptor no está sincronizado con el transmisor, este desconoce cuándo se van a

recibir los datos.

En general, para la comunicación en serie se tiene que:

Es mucho menos costoso (número reducido de líneas)

Se tiene menor disposición a errores

Los datos necesitan ser serializados/deserializados

Se requiere un protocolo de transmisión.

También para la comunicación en serie se tiene la siguiente clasificación

Simplex: Transmisión en un solo sentido.

Semi dúplex: Transmisión en ambos sentidos pero no simultáneamente.

Dúplex completo: transmisión en ambos sentidos simultáneamente (Requiere dos líneas

de datos)

Page 23: modbus

13

2.2.1.2 Transferencia de información paralela

En la figura 4 se muestra el formato de transmisión paralela de la información, en donde

se logra denotar que por cada bit, hay una línea exclusiva.

+3V ________”1”________ +3V

+3V ________”1”________ +3V

0V ________”0”________ 0V

0V ________”0”________ 0V

0V ________”0”________ 0V

0V ________”0”________ 0V

0V ________”0”________ 0V

+3V ________”1”________ +3V

Figura 4. Formato de transmisión paralela.

Para la comunicación en paralelo se tiene que:

Es aparentemente más rápida.

En cortas distancias resulta más efectiva.

Los datos a transmitir no necesitan pretratamiento

A largas distancias, resulta más costoso por la mayor disposición a generar errores.

Transmisor Receptor

Page 24: modbus

14

2.2.2 Detección de errores en la comunicación

Debido a los numerosos problemas a la hora de realizar la transmisión, es necesario

utilizar técnicas que permitan detectar y corregir los errores que se hayan producido. Estas

técnicas se basan siempre en la idea de añadir cierta información redundante a la información

que desee enviarse. A partir de ella, el receptor puede determinar, de forma bastante fiable, si los

bits recibidos corresponden realmente a los enviados. Algunos métodos son:

Bit de paridad

Con este bit, se pueden descubrir errores en la transmisión. Se puede dar paridad par o

impar. En la paridad par, por ejemplo, la palabra de datos a transmitir se completa con el bit de

paridad de manera que el número de bits 1 enviados es par.

Códigos de redundancia cíclica

Los códigos de redundancia cíclica, también conocidos como códigos polinomiales,

constituyen el método de detección de errores más empleado en comunicaciones. Se utiliza con

esquemas de transmisión orientados a tramas (o bloques). Permiten sustanciales mejoras en

fiabilidad respecto al método anterior mencionado, siendo a la vez, una técnica de fácil

implementación. Imponiendo condiciones bastante simples sobre los polinomios divisores, es

posible detectar un gran número de errores. Existen tres polinomios G(x) que se han convertido

en estándares internacionales.

CRC-12: X12

+ x11

+ x3 + x

2 + x +1

CRC-16: X16

+ x15

+ x2 + 1

CRC-CCITT: X16

+ x12

+ x5 + 1

Page 25: modbus

15

Con secuencias de control de 16 bits, utilizando los polinomios CRC-16 y CRC-CCITT

es posible detectar todos los errores simples y los dobles, todos los que afectan a un número

impar de bits, todos los errores tipo ráfaga de 16 bits o menores, el 99,997% de errores ráfaga de

17 bits y el 99.998% de los de 18 bits y mayores.

LRC, chequeo de redundancia longitudinal, utilizados en protocolos de robustez media,

consiste en el complemento a dos de la suma binaria de los bytes de la trama,

generalmente tomados en dos bytes. Posee una distancia de Hamming de 4 con una

eficiencia del 97 % [10].

BCC, chequeo de código de bloques, utilizado en protocolos de robustez media.

2.2.3 Comunicación Maestro – Esclavo

El sistema de comunicación maestro-esclavo consta esencialmente de un equipo que se le

denomina maestro y uno o varios equipos denominados esclavos; el maestro es quien gobierna

los ciclos de comunicación, toda iniciativa de comunicación es llevada a cabo por este equipo

[10]. Los esclavos solo responden a la petición del maestro. El proceso de pregunta/respuesta de

un equipo maestro a uno esclavo se le conoce como transacción. Existen dos tipos de

transacciones:

Consulta-Respuesta: el equipo maestro inicia una transacción con uno de sus esclavos,

todos los esclavos escuchan la pregunta, pero al ser dirigida a uno en particular, este

asume su rol de encuestado, devolviendo la consulta al maestro. Esta transacción puede

ser de lectura, escritura, consulta de estado, etc, todo lo que pueda ser comunicado entre

Page 26: modbus

16

ambos. La transacción puede concretarse en uno o varios hilos de consulta entre el

maestro y el esclavo.

Difusión sin respuesta: el equipo maestro comienza una transacción que va a tener como

destino a todos los esclavos. Los esclavos no responden tal petición y el maestro da por

supuesta la finalización de la misma. Puede darse el caso que uno o más esclavos no

hayan recibido correctamente la información, esto debe tenerse en cuenta cuando se

utiliza este tipo de transacción.

Planteado el esquema maestro-esclavo, se observa que la relación entre ellos es

jerárquica, el maestro posee mayor jerarquía que los esclavos y es quien maneja y distribuye los

tiempos, desde el punto de vista de las comunicaciones.

2.2.3.1 Parámetros en una transacción maestro-esclavo

En una transacción maestro-esclavo se definen ciertos parámetros que se utilizan para

tratar de organizar y garantizar estas transacciones:

Protocolo: para que dos equipos que están intercambiando información puedan

comprenderse, es necesario que ambos se pongan de acuerdo en el contenido de la

información intercambiada. Al conjunto de reglas y convenciones que se utiliza, se le

denomina protocolo.

Interrogación (encuesta): el equipo maestro interroga, bajo un esquema programado, la

secuencia de equipos a disposición. Más aún, cada equipo puede recibir diferentes tipos

de transacciones correspondientes a lectura/escrituras, diferentes tipos de variables. Etc.,

Page 27: modbus

17

el período de encuestamiento para cada esclavo o transacción se le define como

interrogación.

Tiempo de respuesta: cuando el maestro inicia la transacción con un determinado

esclavo dentro del esquema consulta/respuesta, puede suceder que el esclavo no pueda

responderle al maestro. Este debe manejar un tiempo de espera para la respuesta del

esclavo, en caso contrario, abortar esta transacción, ya sea para reintentarla o para

continuar con su esquema de encuesta previsto, este tiempo se le denomina tiempo de

respuesta.

Reintentos: cuando un esclavo no responde y el maestro aborta la transacción, este debe

decidir qué hacer, si continuar con el diagrama de encuesta o reintentar la transacción

abortada. A la cantidad de veces que va a reintentar llevar a cabo con éxito la transacción

es lo que se denomina Reintentos.

2.2.4 Protocolos de comunicación

En principio, un protocolo de comunicación es un conjunto de reglas que permiten la

transferencia e intercambio de datos entre los distintos dispositivos que conforman una red.

Estos han tenido un proceso de evolución gradual, a medida que la tecnología electrónica ha

avanzado y muy en especial en lo que se refiere a los microprocesadores.

Existen diversos protocolos como por ejemplo: CAH, DH+, PROFIBUS, DEVICE NET,

MODBUS, MODBUS TCP, etc.

Page 28: modbus

18

2.2.4.1 Clasificación de los protocolos

Por las características propias de cada protocolo, se ha determinado clasificar de forma

general los protocolos, en donde dicha clasificación se debe básicamente a las propiedades que

los definen, a continuación se menciona dicha categorización [10].

Protocolos sin delimitadores: los datos de la trama son transmitidos todos a la vez, se

tiene en cuenta el tiempo de retardo entre cada byte ya que la normalización de este tipo

de protocolos implica que la finalización de la trama estará dada por un determinado

tiempo sin la recepción de datos. La codificación de datos es binaria, es decir los

caracteres a transmitir pueden ser cualquiera dentro de la tabla de codificación ASCII.

Así, un dato de 16 bits es representado por 2 bytes compuestos por la parte baja y alta del

mismo. El protocolo MODBUS RTU es el más conocido representante de este tipo de

protocolos.

Protocolos de transmisión en formato ASCII, con delimitadores: este tipo de

protocolos utiliza un identificador como comienzo y final de trama, se tratan de

caracteres ASCII de control. Los datos contenidos entre estos delimitadores le dan la

flexibilidad al protocolo. En este caso estos datos van a ser caracteres ASCIIs

comprendidos entre del “0” al “9” y “A” a “F”. Puesto que el final de la trama es

identificada por “caracteres de fin” no es necesaria la transmisión continua ni acotada de

bytes, se permiten demoras entre la transmisión de cada byte y esto es manejable por cada

equipo. En detrimento de esta característica se tiene que cada dato de 16 bits debe ser

transmitido en 4 bytes, llevando así el doble de tiempo en la transmisión de la trama que

Page 29: modbus

19

un protocolo con transmisión sin delimitadores. El protocolo MODBUS ASCII es el más

conocido representante de este tipo de protocolos.

Protocolos con delimitadores e inserción de carácter: este método de encapsulado de

la información, es una conjunción de los dos anteriores, por un lado presenta caracteres

de inicio y final de trama y por otro envía los datos en forma binaria.

2.2.4.2 Protocolo MODBUS

2.2.4.2.1 Definición

MODBUS es un protocolo de capa de aplicaciones de mensajería, situado en el nivel 7del

modelo OSI, que proporciona la comunicación cliente/servidor entre dispositivos conectados en

diferentes tipos de buses o redes [9].

Fue desarrollado por Modicon para comunicación entre PLC’s. Debido a su simplicidad y

especificación abierta, actualmente es ampliamente utilizado por diferentes fabricantes.

Entre los dispositivos que lo utilizan, se puede mencionar: PLC, HMI (interfaz humano-

máquina), sensores y actuadores remotos. A grandes rasgos, el protocolo establece cómo los

mensajes se intercambian en forma ordenada, así como también, la detección de errores.

Entre las principales características del protocolo se tienen:

Control de acceso al medio tipo Maestro/Esclavo.

El protocolo especifica: formato de trama, secuencias y control de errores.

Existen dos variantes en el formato: ASCII y RTU

Solo especifica la capa de enlace del modelo ISO/OSI.

Page 30: modbus

20

A cada esclavo se le asigna una dirección fija y única en el rango de 1 a 247.

La dirección 0 está reservada para mensajes de difusión sin respuesta.

En la figura 5 se presenta un esquema sobre la aplicación de MODBUS.

Figura 5. Aplicación de comunicación MODBUS

2.2.4.2.2 MODBUS RTU y MODBUS ASCII

La codificación de datos dentro de la trama, puede hacerse en modo ASCII o puramente

binario, según el estándar RTU (Remote Transmission Unit). En cualquiera de los dos casos,

cada mensaje obedece a una trama que contiene cuatro campos principales, según se muestra en

la figura 6. La única diferencia estriba en que la trama ASCII incluye un carácter de

encabezamiento («:»=3AH) y los caracteres CR y LF al final del mensaje (ver figura 6)

Page 31: modbus

21

Pueden existir también diferencias en la forma de calcular el CRC (se explica más

adelante), puesto que el formato RTU emplea una fórmula polinómica en vez de la simple suma

en módulo 16. Con independencia de estos pequeños detalles, a continuación se da una breve

descripción de cada uno de los campos del mensaje:

Figura 6. Trama genérica del mensaje según el código empleado

Por último es necesario señalar que MODBUS ASCII es un protocolo “peer to peer” a

diferencia del protocolo MODBUS RTU en donde se tiene una organización jerárquica entre los

autómatas involucrados en un sistema.

2.2.4.2.3 Descripción general del protocolo MODBUS

MODBUS define un protocolo simple de información única de datos (PDU, sigla en

inglés) independiente de la las capas subyacentes de la comunicación. El mapeo del protocolo

MODBUS en redes y buses específicos, puede introducir algunos campos adicionales en la

unidad de datos de aplicación (ADU, siglas en ingles), figura 7.

Lo anterior se puede visualizar de la siguiente manera

Figura 7. Trama general en MODBUS

Page 32: modbus

22

El ADU en MODBUS, es construido por el cliente que inicia la transacción MODBUS.

La función le indica al servidor, que tipo de función debe llevar a cabo. La aplicación del

protocolo MODBUS, establece el formato de la aplicación iniciada por el cliente.

El código de función es codificado por medio de una palabra (byte). Los códigos

permitidos se encuentran en el ámbito de 1-255 (decimal). Cuando un mensaje es enviado desde

el cliente hasta el servidor, el código de función le indica al mismo qué tipo de actividad debe

desempeñar. Es importante destacar que el código “0” no es permitido.

El mensaje enviado por el cliente contiene información adicional que el servidor utiliza

para poder llevar a cabo lo solicitado, lo cual incluye direcciones de registros, cantidad de

información procesada, etc.

Si no se produce ningún error relacionado durante la ejecución de la petición por parte

del cliente, el sistema continua con su ejecución normal, pero en caso contrario MODBUS crea

una alerta con un código de excepción (ver figura 8).

Figura 8. Transacción libre de error

Page 33: modbus

23

Ahora cuando la transacción de la información no se da libre de errores se tiene el

siguiente comportamiento (ver figura 9).

Figura 9. Transacción no libre de error

Es importante notar, a partir de lo anterior, que es elemental asegurar que el maestro

tenga el tiempo necesario de recibir correctamente la respuesta, ya que si no, esto también

significaría un error.

El tamaño de PDU recibido es definido básicamente por el primer PDU enviado por parte

del cliente. El tamaño máximo que se tiene con el estándar RS485 ADU es de 256 bytes

2.2.4.2.4 Codificación de la información

MODBUS usa una representación de 'big-endian "para las direcciones y los elementos de

datos. Esto significa que cuando se transmite una cantidad numérica más grande que un solo

byte, el byte más significativo es enviado de primero.

Page 34: modbus

24

2.2.4.2.5 MODBUS Modelo de Información

En la tabla 1 se muestra el modelo de información que es soportado por el protocolo

MODBUS, en donde se hace diferencia con varios paramentaros.

Tabla 1. Modelo de información soportado por MODBUS

Tablas Primarias Tipo de Objetivo Tipo Comentarios

Entradas Discretas Bit Solo Lectura Información proviene por una

entrada/salida del sistema.

Bobinas Bit Escritura/Lectura Esta información es alterada por

una aplicación del programa.

Registros de entrada 16 bits/palabra Solo Lectura Información proviene por una

entrada/salida del sistema

Registros Internos Registros de entrada Lectura/Escritura Esta información es alterada por

una aplicación del programa.

Page 35: modbus

25

2.2.4.2.6 MODBUS Modelo de direccionamiento

El protocolo de aplicación de MODBUS define de forma precisa las normas de

direccionamiento para el PDU, lo cual se puede observar en la figura 10. En un PDU de

MODBUS cada dato/información se direcciona desde 0 a 65535. También define con claridad un

modelo de datos que es compuesto por 4 bloques que comprende varios elementos numerados

de 1 a n.

Figura 10. Modelo de direccionamiento

Page 36: modbus

26

2.2.4.2.7 Definición de la transferencia en MODBUS

En la figura 11 se presenta un diagrama que describe genéricamente el proceso de

transferencia en MODBUS.

Figura 11. Diagrama de estado de transferencia MODBUS

Si la solicitud MODBUS es concretada con éxito, la respuesta enviada es correcta y el

sistema puede proseguir con los procesos siguientes. En caso contrario el protocolo MODBUS

Page 37: modbus

27

señala un código de excepción, el cual es formado por el código de función mas el código 0x80.

Esto lo hace con el fin de indicarle al usuario el tipo de error que fue detectado, con esto se logra

que el problema sea solucionado con rapidez.

2.2.4.2.7 Categoría de los códigos de Función

En MODBUS existen tres categorías de funciones, entre las cuales se tienen:

Usuario – Códigos de función definidos

Para esta categoría existen dos rangos para de 65-70 y 100-110, en donde el usuario

puede seleccionar e implementar un código de función no soportado por la especificación. Así

como también no hay garantía de que la función seleccionada sea única.

Códigos de función reservados

Esto son códigos comúnmente usados por algunas compañías para productos legales y

que no están disponibles para el dominio público.

Códigos de función Públicos

Estos son códigos de función bien definidos, en donde para cada código se garantiza ser

único, son validados por la comunidad MODBUS-IDA.org.

También existe documentación pública para los mismos, existen pruebas de conformidad

disponibles. También se incluye una función de asignación pública de códigos, así como también

códigos reservados para aplicaciones futuras.

A continuación se presenta una tabla con la función y el código respectivo para la misma.

Page 38: modbus

28

Cabe resaltar que estos códigos son representados en hexadecimal.

Tabla 2. Códigos de funciones públicas en MODBUS

Función Código (Hexadecimal)

Lectura de bobinas 01

Lectura de entradas discretas 02

Lectura de registros internos 03

Lectura de registros de entrada 04

Escritura de bobina 05

Escritura de un registro 06

Lectura del estado de excepción 07

Diagnostico 08

Control de contador de diagnostico 0B

Control de contador log 0C

Escritura de múltiple bobinas 0F

Escritura de múltiples registro 10

Reportar ID esclavo 11

Leer archivo de registro 14

Escritura archivo de registro 15

Escribir mascara de registro 16

Lectura/Escritura de múltiple registros 17

Leer una fila FIFO (First In-First out 18

Transporte interfaz encapsulado 2B

CANopen Referencia general 2B/0D

Lectura de identificación de dispositivos 2B/0E

Page 39: modbus

29

2.3 Aspectos Básicos del estándar RS-485

2.3.1 Definición RS-485

RS-485 permite la conexión de múltiples dispositivos (hasta un máximo de 32), mediante

una comunicación media-dúplex sobre dos cables, además de un cable de tierra, la distancia

máxima es hasta 1200 metros. Pero también presenta la posibilidad de de aumentar la distancia y

numero de nodos, por medio de la utilización de repetidores [5].

2.3.2 Funcionamiento del estándar RS-485

La información es transmitida diferencialmente por medio de dos cables entrelazados

entre sí. La propiedad de que sea transmitida diferencialmente le permite tener la característica

de ser altamente inmune al ruido, así como también de que puede ser utilizado a largas

distancias.

Una red 485 puede ser configurada por dos medios, “doble cable” o “cuatros cables”. En

la configuración de “doble cable” la transmisión y recepción de cada dispositivo está conectada

por medio de dos cables entrelazados. Para la configuración de “cuatro cables” la red tiene un

puerto “maestro” con el transmisor conectado al puerto receptor del “esclavo” por medio de dos

cables, y el puerto transmisor del “esclavo” está conectado por medio de dos cable al puerto de

de recepción del “maestro”. En cada configuración, los dispositivos son direccionados

permitiendo así la posibilidad de establecer una comunicación independiente entre módulos.

Page 40: modbus

30

Solo un dispositivo puede tener la disponibilidad de la línea en un determinado tiempo,

por lo tanto mientras sucede esto los otros dispositivos presentan alta impedancia (tri-estado). En

muchos casos esta situación se da automáticamente pero en otras ocasiones esto es manipulado

manualmente.

2.3.3 Ventajas y desventajas entre “doble cable” y “cuatro cables”

La configuración doble-cable presenta la ventaja de ser de bajo costo y para nodos que

tengan que comunicarse entre sí. Pero presenta la desventaja de que limita la comunicación

media-dúplex y requiere más atención cuando sea hace referencia a los tiempos de retraso en la

comunicación.

Para la configuración de “cuatro cables” permite la operación media-dúplex, pero limita

situaciones donde se tiene la estructura maestro-esclavo (ejemplo de esto es cuando el maestro

requiere información individual de los “esclavos”). Los módulos esclavos no se pueden

comunicar entre sí.

Un punto muy importante de hacer notar es que realmente para la configuración “doble

cable” se necesitan tres cables y para la configuración de “cuatro cables” se necesitan cinco, esto

debido al cable de tierra.

2.3.4 Para qué el estándar RS-485 hace uso del “cable tierra”

En una señal diferencial la señal de tierra no es requerida para la comunicación, pero el

cable tierra tiene un importante propósito. Sobre distancias de cientos y miles de metros puede

haber una diferencia significativa en el nivel de la tensión de tierra. La red de RS-485 puede

Page 41: modbus

31

mantener los datos correctos con una diferencia de -7 a +12 Volts. Si la “tierra” difiere más que

esa cantidad la información se perdería y también el puerto se dañaría (situación común). La

función de la señal del cable de tierra es “atar” la señal de tierra con la “tierra” común de cada

nodo. Sin embargo, si las diferencias en las señales de “tierra” son demasiado grandes, requeriría

una atención extra por parte del diseñador. En donde un aislamiento óptico seria una solución

posible.

2.3.5 Características generales de RS-485

A continuación se presenta una tabla con el resumen de los aspectos más importantes del

estándar RS-485

Tabla 3. Características del RS-485 [7]

Modo de operación Diferencial, Lleno-dúplex, Multi-punto

Numero permitidos de transmisores y receptores 32

Máxima longitud de cable 1200 metros

Máxima velocidad de información 40Mbps

Mínimo rango permitido a la salida ±2.1V

Máximo rango de permitido a salida ±5V

Máxima corriente de corto circuito soportada 250mA

Impedancia de carga en el transmisor 54Ω

Sensibilidad en la entrada del receptor ±200mV

Máxima Resistencia de entrada en el receptor 12kΩ

Rango de voltaje en la entrada del receptor -7V a +12V

"1 lógico" en el Receptor >200mV

"0 lógico" en el Receptor <200mV

Page 42: modbus

32

3. CAPÍTULO 3: Análisis de la solución desarrollada

El presente capítulo, explica cómo funciona la solución desarrollada, la cual está

fundamentada en el desarrollo de la máquina de estados llamada “Comunicaciones”.

Primeramente se expondrá cuales son los registros utilizados, en donde se logrará entender el

porqué de su uso y porqué son importantes. Luego se mencionará la dinámica bajo la cual se

basa el funcionamiento de la máquina de estados.

A continuación, se visualizará el potencial del protocolo de MODBUS, el cual fue

aplicado para poder realizar la comunicación entre los módulos de extensión y el módulo

maestro, en esta sección se podrá entender cómo se construyen las tablas de comunicaciones y

cómo estas permiten que la transferencia de información se lleve a cabo, así como también se

explicará cómo se logró a nivel de programa, la buena sincronización del programa de las

comunicaciones.

Por último, se analizará cada parte que conforma la máquina de estados, con el objetivo

de entender el funcionamiento integral del sistema de comunicaciones planteado.

Cabe aclarar también, que la máquina que se desarrolló en este proyecto forma parte de

un sistema de iluminación, y es de este sistema de donde provienen las señales que conforman

los registros que a continuación se explicarán.

Page 43: modbus

33

3.1 Registros utilizados en la máquina de comunicaciones

A nivel de comunicaciones, lo que se busca transmitir son los cambios en las señales de

control que permiten el buen funcionamiento del sistema, dichas señales pueden provenir ya sea

por entradas al sistema o por señales generadas mediante lógica interna de programación.

Las señales de control para este sistema son registradas de la siguiente manera, un “1

lógico” cuando la señal esta activa y un “0 lógico” para la condición contraria. Cada señal tiene

un espacio reservado dentro de un registro establecido.

Esta manera de tratar las señales representa una gran ventaja a nivel de comunicaciones,

ya permite tener un orden con las mismas. Cada vez que se transfiere el registro se comunican

todos los cambios registrados en un ciclo de barrido del PLC, lo cual ahorra tiempo y aumenta la

eficiencia, a diferencia de si se comunicara cada señal individualmente.

Con la idea de mantener un mayor orden y a la vez asegurar una mayor sincronización

entre los módulos (esclavo y maestro), se procedió a utilizar dos registros, donde ambos

contienen la misma información. La diferencia entre ambos, radica en la funcionalidad

conceptual que se le da a los mismos.

Existe un registro denominado “Registro Operacional (RO)”, el cual es el que recibe por

primera vez cualquier cambio en cualquier señal, pero el autómata no ejecuta ninguna acción a

partir de este registro, a pesar de ser una señal de orden para realizar la acción debidamente

Page 44: modbus

34

solicitada por el usuario o por lógica interna. La importancia de controlar el sistema de esta

manera es debido a que una señal no solo afecta a un módulo en específico, sino que afecta a

todos los módulos, por tanto si se ejecuta una acción inmediatamente que se registra no habría

una sincronización correcta y no se lograría el objetivo de hacer una comunicación eficiente.

Para solucionar este aspecto importante, surgió la necesidad de crear el “registro espejo”

a RO, el cual recibe nombre de “Registro de Control (RC)” , el cual, una vez que recibe la

información correspondiente, se encarga de transmitir la orden para que se comience a ejecutar la

acción solicitada.

Como consecuencia de lo anterior es importante hacer notar los siguientes dos puntos.

Primero se debe aclarar que los registros RO y RC están en cada módulo y en todo momento los

registros RC entre módulos son una copia fidedigna, lo cual no sucede con el registro RO. La

siguiente acotación es que el registro RO es solamente alterado por las señales de entrada o por

lógica interna, y el registro RC, recibe la información por medio de la orden de la máquina de

comunicaciones. En secciones siguientes se explicará como sucede esto.

Además de los registros RO y RC, también se tienen los registros ROU y RCU, que están

enfocadas para la función de unión de luces que tiene el sistema de iluminación, pero es

importante denotar que estos registros funcionan exactamente igual a RO y RC, es por eso que la

diferencia en nombre lo marca la letra “U” haciendo alusión a unión de luces.

Page 45: modbus

35

3.2 Esquema de transferencia de la información

Esta sección, se enfoca en explicar cómo se da la comunicación a nivel general y se

visualizará claramente la funcionalidad ya citada anteriormente para los registros RC y RO. En

la figura 12, se expone el esquema que resume claramente cómo es que se transfiere la

información.

Figura 12. Esquema de comunicaciones.

*Tabla: Tabla de comunicaciones

De la figura 12 entiéndase “Módulo central o maestro (MC)” y “Módulo de extensión o

esclavo (MX)”. También para una mejor comprensión se explicara la transferencia, en dos

situaciones diferentes pero generales al mismo tiempo.

Estas dos situaciones están previstas de la siguiente manera,

1. Cuando hay una solicitud a nivel del módulo maestro que debe comunicarse así mismo

como a todos los módulos esclavos.

1 2

3 4 *

Page 46: modbus

36

2. Cuando hay una solicitud a nivel de un módulo esclavo que debe transmitirse a todos los

módulos esclavos del sistema, al módulo central (maestro), así como también al módulo

mismo donde se dio la solicitud.

A continuación se explicarán estos casos.

3.2.1 Solicitud en módulo central o maestro

Esta situación es quizás la más fácil a nivel de comunicación, ya que la solicitud

(cambio en el registro RO y ROU de 0 a 1, en uno o varios bits de los registros) se da en el

módulo maestro y este módulo es el que se encarga de hacer la transferencia de cualquier cambio

en una señal a todos los demás autómatas del sistema, por tanto si la solicitud se da en el

maestro, la transferencia es casi inmediata a diferencia de cómo se apreciará en la sección 3.2.2.

Primeramente es registrado un cambio en algún bit de los registros RO y ROU, en este

momento el proceso de transferencia se encuentra en el sub-cuadro 1 señalado en la figura 12.

Ahora por medio de la máquina de comunicaciones los registros RO y ROU son transferidos al

correspondiente en RC y RCU. A nivel del módulo central se ejecuta, mediante una simple

transferencia (obsérvese sub-cuadro 1 de figura 12), pero la escritura del registro RO y ROU para

los registros RC y RCU de los módulos esclavos, se da mediante una difusión que escribe

directamente en el registro de control de cada módulo esclavo, esto es representado en la figura

12 mediante el sub-cuadro 2. En la sección siguiente se explica cómo es posible hacer esto.

Luego de realizar esto se escribe un cero en todos los registros (acción de borrado) esto con el fin

de poder registrar otro cambio en cualquier señal.

Page 47: modbus

37

3.2.2 Solicitud en un módulo de extensión

En este caso se tiene lo siguiente. Se inicia con una solicitud (una orden proveniente por

el usuario o por lógica interna del sistema) en cualquier módulo esclavo, que se copia en el

registro RO y ROU del módulo correspondiente en donde se dio la solicitud. En este momento,

la transferencia se encuentra en el sub-cuadro 3 de la figura 12. Luego, el módulo central hace

una consulta a todos los módulos de extensión, uno por uno, con lo que se asegura de leer

cualquier cambio que suceda en cualquier módulo de extensión. En este momento la

transferencia se encuentra en el sub-cuadro 4 de la figura 12.

Una vez realizada la lectura a un módulo esclavo por parte del módulo maestro y

registrado un cambio en RO y ROU del mismo módulo esclavo, se procede a transferir estos

registros a los registro RC y RCU de todos los autómatas. En el maestro esto sucede por medio

de una transferencia (ver la relación entre los sub-cuadros 1 y 4 de la figura 12) y para los

módulos de extensión, el maestro, por medio de la sección de comunicación se encarga de la

difusión a todos los módulos esclavos, inclusive al módulo donde el maestro detectó la solicitud

(ver la relación entre los sub-cuadros 2 y 4 de la figura 12).

Luego de esto, se mandan a borrar todo los registros, para poder registrar cualquier otra

solicitud.

Page 48: modbus

38

3.3 Herramientas utilizadas para realizar la comunicación

En esta sección, se exponen las diferentes tablas de comunicaciones que se utilizaron, así

como también, la funcionalidad correspondiente de las mismas, otro aspecto a mencionar es

cómo se logró la sincronización en las comunicaciones, esto mediante las opciones que presenta

el software de programación del autómata Twido.

3.3.1 Tablas de comunicaciones

Las tablas son un aspecto fundamental para poder realizar las comunicaciones, estas

definen cuándo y sobre quién se escribe o se lee. También controla la posibilidad de hacer una

difusión o no. Básicamente en las tablas de comunicaciones se mapean los registros que se

desean transmitir, todo siempre bajo el fundamente teórico que es expuesto gráficamente en la

figura 10.

3.3.1.1 Estructura de una tabla de comunicaciones

Las tablas están formadas por tres partes, las cuales se mencionan a continuación:

1. Control: esta parte de la tabla define si se quiere o no realizar una difusión, así como

también que tipo de acción debe ejecutar la tabla, por ejemplo puede ser una tabla de

escritura o lectura, o alguna función señalada en la tabla 2.

2. Emisión: esta sección contiene la información que se desea escribir y en que posiciones

de desea hacer, esto en el caso de escritura, para el caso de lectura señala las posiciones

de memoria a leer.

Page 49: modbus

39

3. Recepción: esta sección da información de los datos leídos o escritos, así como también

las posiciones de memoria de donde se leyó o escribió.

3.3.1.2 Tablas utilizadas en la máquina de comunicaciones

A continuación, se mencionan y explican la funcionalidad de cada una de las tablas

utilizadas en la máquina de comunicaciones diseñada.

1. Tabla comando de difusión de escritura de palabras de operaciones de control del

módulo central.

Esta tabla (ver tabla 4 en apéndice) permite que se dé la escritura de los registros RO y

ROU en todos los módulos esclavos, esta escritura se da directamente en el registro RC y/o RCU

correspondientemente.

2. Tabla comando de lectura de palabras de control de cualquier módulo de extensión

Esta tabla (ver tabla 5 en apéndice) permite leer las palabras de control de todos los

módulos esclavos, lo cual corresponde a leer los registros RO y ROU. Esto se realiza para

verificar si ha existido un cambio en alguna señal.

3. Tabla comando de difusión de escritura por cambios en palabras de control leídas

en cualquier módulo de extensión.

Esta tabla (ver tabla 6 en apéndice), permite enviar a todos los módulos de extensión, las

palabras de control leídas de un módulo de extensión específico. Esto se da cuando hay un

cambio en un módulo esclavo, específicamente en alguno de los registros de operación o ambos

a la vez (RO, ROU).

Page 50: modbus

40

4. Tabla comando de escritura para borrar palabras de control en un módulo de

extensión.

Luego de que se ha difundido la acción de control a todos los módulos esclavos. Esta

tabla (ver tabla 7 en apéndice), permite borrar en todos los módulos de extensión las palabras de

los registros de operación control. Específicamente lo que se hace es copiar un valor cero en los

registros RO y ROU de los módulos esclavos.

5. Tabla comando de difusión de los registros que contienen la hora actual del día y

hora de apagado maestro automático.

Esta tabla (ver tabla 8 en apéndice), permite difundir la hora actual que tiene el módulo

maestro, a todos los módulos esclavos. También, se encarga de difundir el registro que contiene

la hora de apagado maestro automático.

3.3.2 Control a nivel de comunicación

A nivel de las comunicaciones. Existen dos variables importantes de tomar en cuenta,

Sincronización de las comunicaciones (%MSGx)

Habilitación de la tabla respectiva que permita ejecutar una función en específico

(EXCHx).

Para la sincronización de las comunicaciones a nivel de programa, se utiliza la función

%MSGx, esto logra que una comunicación se haga efectiva si y solo si el canal de comunicación

está habilitado, este bit permite asegurar un buen funcionamiento, ya que si hay dos solicitudes al

Page 51: modbus

41

mismo tiempo o si da a una solicitud ya estando una solicitud atendiéndose, el programa da un

error y manda una excepción como se expuso en la figura 11.

Por esta razón este bit se usa como complemento para sincronizar las comunicaciones, ya

que el mismo va acompañado de lógica expuesta por parte del programador

Ahora, cuando se cumplen las condiciones para realizar una comunicación, es necesario

hacer una selección adecuada de la tabla correspondiente para realizar una acción en específico,

para esto existe la instrucción EXCHx que una vez que se activa esta, permite al autómata

Twido, enviar o recibir información dirigida o procedente de otros autómatas. La instrucción

EXCHx va acompañada de la información necesaria que indica cual tabla es la que debe

habilitar, por tanto una vez activada un EXCHx especifico, se procede a activar el canal de

comunicación y a realizar la función que especifique la tabla que en ese momento la instrucción

EXCHx está habilitando

.

Estos dos aspectos mencionados son esenciales para asegurar la eficiencia a nivel de las

comunicaciones.

Page 52: modbus

42

3.4 Máquina de comunicaciones

Esta sección explica el detalle de la máquina de comunicaciones, que resolvió el

problema de comunicar un módulo maestro con “n” módulos esclavos, para un sistema de

control de iluminación en específico, pero como se evidenciará a continuación, esta máquina

permite ser ejecutada en otras aplicaciones mediante las modificaciones necesarias.

El análisis se llevará a cabo dividiendo la máquina de comunicaciones en partes claves,

con el fin de entender mejor el funcionamiento integral de la máquina.

Primero se presentará la máquina completa, para tener una visualización completa de la

misma y luego se procederá hacer el análisis por partes.

Cabe señalar que por principio de máquina de estados, esta máquina no escapa al

fundamento de que un estado es ejecutado a la vez, y el próximo estado se ejecuta una vez que el

estado anterior fue completado correctamente.

También es importante señalar que, para poder entender el siguiente análisis, es

necesario tener claro cada una de las secciones anteriores que conforman el presente capítulo, así

como también, la parte teórica, ya que la siguiente máquina refleja una fusión integral de los

conceptos de cada sección señalada anteriormente.

En la figura 13, se presenta la máquina de comunicaciones completa, la cual resuelve la

necesidad de comunicar varios autómatas entre sí.

Page 53: modbus

43

Figura 13. Máquina de comunicaciones.

SI

NO

SI

a

b

c

d

e

f

g

i

j

k

l

m

Nota: La letra a la par de cada

“rectángulo” representa el

nombre del estado.

n

o

p

h

SI

Page 54: modbus

44

3.4.1 Análisis por partes de la máquina de comunicaciones

3.4.1.1 Contador

A nivel de Twido, es posible manejar una cantidad variable de módulos esclavos, por

tanto este punto fue muy importante de considerar, ya que cada lugar donde se instale el sistema

de iluminación tendrá un número diferente de módulos. Ahora por disposición de programación

siempre hasta que se ejecuten todos los estados de la máquina para un módulo específico se

puede pasar a un nuevo módulo y comenzar la ejecución de los estados nuevamente para ese otro

módulo en específico.

Considerando lo anterior se tiene lo siguiente. En la figura 14 se presenta la parte de la

máquina de comunicaciones que contiene al contador, donde se logra observar al mismo

mediante la letra “i” que inicia la cuenta con “1”. El contador se incrementa hasta el último

estado de la máquina de estados, asegurando esto que todos los estados anteriores fueron

revisados correctamente para un módulo.

Luego cuando se hace el incremento existen dos posibilidades, una posibilidad es que el

contador no rebase la cuenta del total de los módulos, y por tanto en esta situación la máquina

comienza nuevamente en la posición señalada con la letra “B”, en caso de rebase se comienza en

la posición “A” en donde el contador se reinicia con la cuenta en “1”.

Page 55: modbus

45

Figura 14. Contador de la máquina de comunicaciones

3.4.1.2 Control y sincronización en las comunicaciones

Este es un punto fundamental y quizás el más importante que permite el buen

funcionamiento de las comunicaciones. Como se mencionó anteriormente, no basta la función

%MSGx para asegurar el éxito en las comunicaciones, ya que este solo dice cuando el canal esta

libre para empezar una nueva comunicación, pero no asegura que no se presenten excepciones o

errores.

Esta parte de la máquina, asegura que una nueva solicitud de comunicación, ya sea de

lectura o de escritura, sea valida hasta que el canal se encuentre totalmente listo, lo cual implica

que la instrucción %MSGx se encuentre activa dando la señal de habilitación para que se

proceda con la comunicación. El cómo se controla la habilitación para que una nueva acción sea

atendida por parte de las comunicaciones se señala en la figura 15. En esta figura, se tiene un

a

b

p

Transferencias de

datos entre módulos

Page 56: modbus

46

estado y una condición. En la condición, lo que se evalúa básicamente, es el estado en que se

encuentra %MSGx, ya que cuando tiene un valor de “1 lógico” lo que indica es que la acción

anterior ya se terminó de ejecutar y el canal de comunicación se encuentra listo para comunicar

una nueva acción. En caso contrario, lo que sucede es que una vez que se evalúa la condición y

esta da como resultado negativo se queda en el mismo estado, esperando has que la condición de

cómo resulta lógico un uno.

Figura 15. Control y sincronización en la máquina de comunicaciones

Nótese que en esta parte de la máquina se repite varias veces, por tanto es que junto al

“rectángulo” se mencionan los diferentes estados posibles.

3.4.1.3 Transferencia ante un cambio en el registro RO y ROU del módulo maestro

Una vez que las comunicaciones están listas, se procede primero a realizar la lectura del

registro RO y ROU del maestro, ver figura 16, si se verifica que alguno de estos dos registros es

diferente de cero se procede al esquema de transferencia de información entre el módulo maestro

y los módulos esclavos que se expuso en la sección 3.2.1, en caso de que no exista un cambio en

alguno de los registro RO y ROU, la pasa al estado “h”. Antes bien, es importante denotar que el

hecho de que la condición no se cumpla, quiere decir que el autómata se salta los estados, lo cual

c, e, g, i, k, o

Page 57: modbus

47

implícitamente implica que las salidas correspondientes a dichos estados no se activen, lo cual

conlleva a un ahorro de tiempo considerable debido a que no se activan las comunicaciones.

Si la respuesta a la pregunta (condición) es positiva, es necesario borrar los registros una

vez terminada la transferencia, esto con el fin de poder percibir algún otro cambio en los

registros RO y ROU.

Para esta sección, se utilizan las tablas de comunicaciones 1 y 4 expuestas en la sección

3.3.1.2.

Figure 16. Secuencia a seguir ante un cambio a los registros RO y ROU en el módulo central

Nota: ROMC y ROUMC hace referencia a que estos registros pertenecen al módulo maestro.

d

e

f

g

Page 58: modbus

48

3.4.1.4 Transferencia ante un cambio en el registro RO y ROU de algún módulo de extensión

Esta parte de la máquina representada en la figura 17, cumple básicamente con las

mismas condiciones de la sección 3.4.1.3, ya que esta vez el cambio de RO y ROU es registrado

en un módulo esclavo, pero para este caso primero se hace una lectura y se cambia el esquema de

transferencia según expuesto en la sección 3.2.2.

Figura 17. Secuencia a seguir ante un cambio en RO y ROU en un módulo de extensión.

Las tablas que se utilizan para esta parte son las numeradas 1, 2, 3 y 4 y que fueron

presentadas en la sección 3.3.1.2.

h

i

j

k

l

m

Page 59: modbus

49

3.4.1.5 Difusión de la hora del día y hora de apagado maestro automático

La figura 18, representa la parte de la máquina de comunicaciones que fue diseñada con

el fin de asegurar un mayor sincronismo entre autómatas. Se decidió transmitir la hora cada

minuto a todos los módulos de extensión; el que lleva la hora estándar es el módulo maestro. Con

esto, se asegura que todos lo módulos tenga la misma hora, lo cual a nivel de sistema completo

asegura que cuando exista un evento controlado por tiempo, todos los módulos lo ejecuten al

mismo instante.

También, se decidió transmitir junto con la hora del día, el registro que tiene la Hora de

Apagado maestro Automático (RHA), con el fin de evitar que se pierda en algún módulo

esclavo, por una condición no controlada.

La tabla de comunicaciones que se utiliza para esta parte es la 5, la cual se explica en la

sección 3.3.1.2.

Figura 18. Difusión de la hora del día y hora de apagado maestro automático.

n

o

Page 60: modbus

50

4. CAPÍTULO 4: Conclusiones y recomendaciones

4.1 Conclusiones

Con el trabajo realizado, se logró comprobar la utilidad potencial de los autómatas en el

campo del control automático, que para este caso específico fue enfocado para un sistema de

control de iluminación.

También se logró evidenciar que utilizando arquitectura distribuida (varios PLC en red)

se puede controlar eficientemente sistemas en donde se necesitan utilizar más de un autómata.

Para esa intercomunicación, se verificó que el protocolo MODBUS RTU cumple con los

requisitos que aseguran la buena comunicación entre los autómatas, ya que gracias a sus

características se logró alcanzar los objetivos a nivel de comunicación planteados, los cuales

comprendieron básicamente en escribir y leer registros con información.

De la misma manera, se determinó que el estándar RS-485 cumple adecuadamente con

los requerimientos planteados en un inicio, además de que este estándar permite abaratar costos

una vez que todo el sistema trabaje en conjunto.

Además de esto, se evidenció que una comunicación efectiva, depende de varias variables

como lo son, sincronización, verificación entre la información que se manda y se recibe, no

saturación del canal por el cual se da la comunicación y sobre todo el tiempo que se dura en la

transmisión de la información.

A nivel de la comunicación también se aprovechó la utilidad de la difusión que presenta

el autómata Twido, gracias al protocolo MODBUS RTU, ya que el transmitir un mensaje a todos

los módulos de extensión a un mismo tiempo cuando se es preciso, aumenta la eficiencia del

sistema.

Page 61: modbus

51

Con la máquina de comunicaciones diseñada y probada, se logró percibir la gran

potencialidad de las máquinas de estados. Esto cuando el problema y solución están

fundamentados bajo una secuencia de sucesos/estados que son dependientes entre sí, así como

también, la visualización de la solución bajo este método permitió una programación guiada, ya

que al momento de escribir el código de programa mediante el lenguaje “Ladder” se hizo de

manera directa, debido a que las condiciones que se deben cumplir para que cierto estado

específico fueron fácilmente planteadas mediante el uso de los contactos que presenta dicho

lenguaje.

Otro aspecto que se logró evidenciar fue que la compresión de la jerarquía que existe

entre un módulo maestro y un conjunto de módulos esclavos, es fundamental para que la

comunicación se lleve a cabo adecuadamente.

Por último, se afirma que los objetivos del proyecto fueron cumplidos, y todo esto bajo el

tiempo establecido en una primera instancia antes de comenzar con el desarrollo del proyecto.

4.2 Recomendaciones

Probar la máquina de comunicaciones en un sistema donde haya más de 2 autómatas, ya

que esto permitiría ver si existen problemas en la comunicación, ya que conociendo los

resultados de esta prueba, se podrían realizar los cambios pertinentes y así llegar asegurar

la robustez del sistema en general y por ende, en la máquina de comunicaciones, esto no

se hizo durante el desarrollo del trabajo ya que solo se contaba con 2 autómatas.

Probar el sistema en condiciones límites, como por ejemplo a la distancia máxima que

permite el estándar RS-485, no con el fin de comprobar el estándar, sino más bien de

Page 62: modbus

52

visualizar como funcionaría el sistema ante las “peores” condiciones, esto no se hizo

durante el desarrollo del trabajo debido a que quedaba fuera del plazo planteado para el

desarrollo del proyecto.

Hacer la máquina de comunicaciones con MODBUS TCP/IP, con el fin de mejorar la

velocidad de comunicaciones.

El autómata Twido de Schneider con el que se trabajó, trae incorporado la opción de

realizar las comunicaciones con macro-funciones. Sería interesante entonces evaluar esta

posibilidad ya que si, presenta un comportamiento similar en eficiencia y eficacia, se

podría tomar la decisión de utilizar este método.

Si existe la posibilidad de probar la máquina de comunicaciones en autómatas de otras

marcas, sería importante llevar a cabo esta idea, ya que permitiría observar si la máquina

se comporta mejor en otros autómatas, y lo cual permitiría hacer una mejor selección del

autómata para un montaje final de un sistema completo.

Page 63: modbus

53

BIBLIOGRAFIA Libros:

1. Colin D. Simpson, “Programmable Logic Controllers”, Prentice Hall Inc., Estados

Unidos, 1994.

2. Ian G. Warnock, "Programmable Controllers: Operation and Application", Prentice

Hall Inc., 1988.

3. John W. Webb and Ronald A. Reis, "Programmable Logic Controllers: Principles and

Applications", 4th

edicion, Prentice Hall Inc., Estados Unidos, 1999.

4. McNamara, J. “Technical Aspects of Data Communication”, segunda edicion, Digital

Press, Estados Unidos, 1982.

Páginas web

5. B&B electronics manufacturing company. “Basics of the RS-485 Standard”,

http://www.bb-elec.com/bb-elec/literature/tech/b&b1.pdf

6. López Pérez, Eric. “Ingeniería en microcontroladores”,

cselectrobomba.googlecode.com/files/Serial_RS232.pdf

Page 64: modbus

54

7. Maxim, “RS-485 (EIA/TIA-485) Differential Data Transmission System Basics”,

http://pdfserv.maxim-ic.com/en/an/AN736.pdf

8. “Modelo de un sistema de comunicaciones”, http://www.eveliux.com/mx/modelo-de-

un-sistema-de-comunicaciones.php.

9. “MODBUS Application Protocol Specification V1.1b”,

http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf

10. “Protocolos”, http://www.gustato.com/eprotocolos.html

11. “Sistemas de comunicación”,

http://iie.fing.edu.uy/ense/asign/siscom/teorico/clases/clase1.pdf

Page 65: modbus

55

APÉNDICES

Apéndice 1. Tabla de comunicaciones completas.

A continuación se citarán las tablas completas que fueron explicadas en la sección 3.3.1.2

Tabla comando de difusión de escritura de palabras de operaciones de control

del módulo central.

Dirección Contenido 16# Comentarios

Control 100 000C 00=Difusión. 0C= # de bytes transmitidos.

101 0007 Offsets Rx y Tx

Tx

102 0010 00=Difusión.10h(1610)= código escribir N palabras.

103 0042 Dirección donde se escribirá 1a. Palabra.

104 0002 # de palabras a escribir en el esclavo.

105 0004

00= byte no enviado por offset. 04=2*N=# de bytes a

escribir.

106 (0070) Contenido de 0070=1a. palabra a escribir.

107 (0071) Contenido de 0071=2a. palabra a escribir.

Rx

108 0010 00=Difusión.10h(1610)= código escribir N palabras.

109 0070 0070=Dirección donde se escribió 1a. Palabra.

110 0002 0070=# de palabras escritas en el esclavo.

Tabla 4. Difusión de escritura de palabras operacionales de control del modulo central.

Tabla comando de lectura de palabras de control de cualquier módulo de extensión

Dirección `Contenido 16# Comentarios

Control

120 0106 01= Comando R/W. 06= # de bytes a trasnmitir.

121 0300 Offsets Rx y Tx.

Tx

122 aa03 aa=Dirección del esclavo. 03= Código lectura de N palabras.

123 0046 0070=Dirección donde se leerá 1a. Palabra.

124 0002 # de palabras a leer del esclavo.

Rx

125 aa03 aa=Dirección del esclavo. 03= Código lectura de N palabras.

126 00004

00= Offset de Rx. 04=bytes leídos=2*N. N=# de palabras

leídas.

127 cccc 1a. palabra leída.

128 dddd 2a. palabra leida.

Tabla 5. Lectura de palabras de control de cualquier modulo de extensión.

Page 66: modbus

56

Tabla comando de difusión de escritura por cambios en palabras de control leídas

en algún módulo de extensión.

Dirección Contenido 16# Comentarios

Control 140 000C 00=Difusión. 0C= # de bytes transmitidos.

141 0007 Offsets Rx y Tx

Tx

142 0010 00=Difusión.10h(1610)= código escribir N palabras.

143 0042 0072=Dirección donde se escribirá 1a. Palabra.

144 0002 # de palabras a escribir en el esclavo.

145 0004

00= byte no enviado por offset. 04=2*N=# de bytes a

escribir.

146 (0127) Contenido de 0127=1a. palabra a escribir.

147 (0128) Contenido de 0128=2a. palabra a escribir.

Rx

148 0010 00=Difusión.10h(1610)= código escribir N palabras.

149 0072 0072=Dirección donde se escribió 1a. Palabra.

150 0002 0002=# de palabras escritas en el esclavo.

Tabla 6. Difusión de escritura por cambios en palabras de control leídas en algún módulo de

extensión.

Tabla comando de escritura para borrar palabras de control en un módulo de

extensión.

Dirección Contenido 16# Comentarios

Control 160 000C 01= Comando R/W. 0C= # de bytes transmitidos.

161 0007 Offsets Rx y Tx

Tx

162 aa10

aa=Dirección del esclavo. 10h(1610)= código escribir N

palabras.

163 0042 0070=Dirección donde se escribirá 1a. Palabra.

164 0002 # de palabras a escribir en el esclavo.

165 0004

00= byte no enviado por offset. 04=2*N=# de bytes a

escribir.

166 0000 1a. palabra a escribir.

167 0000 2a. palabra a escribir.

Rx

168 0010 01= Comando R/W. 10h(1610)= código escribir N palabras.

169 0070 0070=Dirección donde se escribió 1a. Palabra.

170 0002 0002=# de palabras escritas en el esclavo.

Tabla 7. Comando de escritura para borrar palabras de control en un módulo de extensión.

Page 67: modbus

57

Tabla comando de difusión de los registros que contienen la hora actual del día y

hora de apagado maestro automático.

Dirección Contenido 16# Comentarios

Control 180 000C 00=Difusión. 0C= # de bytes transmitidos.

181 0007 Offsets Rx y Tx

Tx

182 0010 00=Difusión.10h(1610)= código escribir N palabras.

183 0068 Dirección donde se escribirá 1a. Palabra.

184 0002 # de palabras a escribir en el esclavo.

185 0004

00= byte no enviado por offset. 04=2*N=# de bytes a

escribir.

186 (0068) Contenido de 0068=1a. palabra a escribir.

187 (0069) Contenido de 0069=2a. palabra a escribir.

Rx

188 0010 00=Difusión.10h(1610)= código escribir N palabras.

189 0068 0068=Dirección donde se escribió 1a. Palabra.

190 0002 0002=# de palabras escritas en el esclavo.

Tabla 8. Comando de difusión de los registros que contienen la hora actual del día y hora de

apagado maestro automático