modbus
-
Upload
erick-lima -
Category
Documents
-
view
142 -
download
3
Transcript of 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
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
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.
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.
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
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
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
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”).
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.
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.
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
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
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.
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.
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.
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.
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
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.
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.
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
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
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)
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
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
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
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.,
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.
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
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.
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)
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
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
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.
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.
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
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
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.
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
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.
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
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
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.
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
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.
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 *
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.
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.
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.
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).
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
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.
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í.
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
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”.
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
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
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
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
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
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.
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
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.
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
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
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.
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.
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