Seminario de Titulación Protocolo de Comunicación Modbus REDES INDUSTRIALES PROTOCOLO MODBUS Mayo 2004 Seminario de Titulación Protocolo de Comunicación Modbus ÍNDICE CAPITULO 1 Introducción a las Redes Industriales 1 1.1. 1.2. 2 Automatización Industrial y Redes de Comunicación Vista General de la Automatización Industrial y Redes de Comunicación 1.3. Niveles Jerárquicos en Sistemas de Automatización Industrial -Nivel de campo -Nivel de célula.. -Nivel de área.. -Nivel de planta… -Medios de transmisión… -Topología de red… 1.4. Consideraciones de diseño..14 -Costo… -Servicio o función de la red… -Tolerancia con respecto al medio ambiente.. -Medios físicos.. -Expansión .. -Mantenimiento.. -Requisitos de comunicación para los sistemas de automatización… 5 8 8 10 11 11 11 13 15 16 17 17 18 18 18 CAPITULO 2 Protocolo Modbus.. 2.1. Introducción al Protocolo de Comunicación Modbus… -Intercambio de información en una red Modbus.. -Intercambio de información sobre redes diferentes a Modbus.. -Pregunta.. -Respuesta.. 2.2. Los Dos Modos de Transmisión Serial… -Modo ASCII.. -Modo RTU.. 2.3. Tramas de Mensaje Modbus.. -Trama ASCII.. -Trama RTU..31 -Como es manipulado el campo de dirección… 21 22 24 25 26 27 27 28 28 30 30 32 Seminario de Titulación Protocolo de Comunicación Modbus -Como es manipulado el campo de función… -Contenido del campo de datos.. -Contenido del campo de comprobación de error.. -Como son trasmitidos los caracteres en serie.. 2.4. Métodos de Comprobación de Error.. -Control de Paridad… -Comprobación LRC.. -Comprobación CRC.. 32 34 35 36 37 37 39 39 CAPITULO 3 Datos y Funciones de Control… 3.1. Formato de las Funciones Modbus… 3.2. Código de Funciones Soportadas por Los Controladores.. -01 Lectura del estatus de una bobina.. -02 Lectura del estatus de una entrada.. -03 Lectura de registros sostenidos.. -04 Lectura de registro de entradas.. -05 Forzar bobinas simples……… -06 Predeterminar registros simples……. -07 Lectura de estatus de excepción……. -11 Sacar un contador de eventos de comunicaciones…… -12 Traer el registro de eventos de comunicaciones………. -15 Forzar varias bobinas….... -16 Predefinir varios registros…… -17 Reportar el identificador del esclavo…….. -20 Lectura de referencias generales………… -21 Escritura de referencias generales………. -22 Escritura de registros 4X con una mascara……. -23 Lectura/escritura de registros 4X………………. -24 Lectura de una cola FIFO……………. 42 43 47 48 50 52 54 56 58 59 61 63 68 70 72 81 84 88 90 92 CAPITULO 4 Subfunciones de Diagnostico………………… 4.1 Función 08 Diagnósticos…………………….. -Efectos del diagnostico en el esclavo……. 4.2 Subfuncion de Diagnostico…………………….. -00 Regreso de datos de la pregunta……….. -01 Opción de reinicio de la comunicación…. -02 Regreso del registro de diagnostico -03 Cambio del delimitador de entrada ASCII -04 Forzar el modo de solo escucha -10 Borrar contadores y registro de diagnostico 95 96 96 99 99 99 100 101 101 102 Seminario de Titulación Protocolo de Comunicación Modbus -11 Regreso del contador de mensajes del bus -12 Regreso del contador de errores de comunicación del bus.. -13 Regreso del contador de errores de excepción en el bus…. 102 -14 Regreso del contador de mensajes del esclavo -15 Regreso del contador de no respuestas del esclavo -16 Regreso del contador NAK del esclavo -17 Regreso del contador de ocupado del esclavo -18 Regreso del contador de caracteres desbordados en el bus… -19 Regreso del contador de IOP desbordados (884)…… -20 Borrar banderas y contadores de desbordamiento….. 103 103 104 .104 102 103 105 105 106 CAPITULO 5 Modbus TCP/IP……… 5.1 Modelo Cliente Servidor……… 5.2 Descripción del Protocolo……….. -Arquitectura general de comunicación….. -La unidad de datos de la aplicación sobre Modbus TCP/IP -Descripción del encabezado MBAP……… 5.3 Descripción Funcional………… -Agente de conexión TCP -Uso de la pila TCP/IP -Capa de aplicación de comunicación 107 108 109 109 …..110 111 113 118 123 124 Seminario de Titulación Protocolo de Comunicación Modbus INTRODUCCIÓN JUSTIFICACIÓN El tema de protocolo de comunicación Modbus fue elegido por ser uno de los protocolos más utilizados en la industria, y el cual a sufrido modificaciones al original Modbus creado por Modicon, llegando a ser un estándar para la industria, este tema es poco conocido afuera del área de instrumentación y control, pero la mayoría de los equipos industriales tienen este protocolo para la transmisor de sus datos y/o configuración del mismo equipo. OBJETIVOS El objetivo es tener un material claro y objetivo para comprender el modo de operación de los dispositivos que cuentan con Modbus para la transmisión de datos, así como conocer los alcances del mismo protocolo, tener un panorama de las variantes que se pueden encontrar en el campo debido a los diferentes modos de transmisión que eligieron los fabricantes, y tener clara la filosofía del funcionamiento de una red de este tipo, tanto para su transmisión serial como para el caso de su transmisión bajo Modbus TCP/IP en el cual se busca que el lector comprenda las diferencias contra el Modbus de transmisión serial, y mostrar las modificaciones que sufrirían los datos. PROBLEMAS La falta de información acerca de este tema es el principal problema, ya que en lo referente a redes todo mundo habla de las nuevas tecnologías y de redes empresariales, pero no consideran las redes industriales que es un campo con grandes posibilidades, ya que se están logrando integraciones de sistemas usando infraestructura ya creada, logrando un grado de control y automatización que no seria posible bajo los conceptos antiguos, debido a el excesivo uso de cables para la transmisión de las señales y con la necesidad de tener grande cuartos de control donde integrar estas señales, con las redes industriales, el grado de monitoreo y control permite reducción de costos y espacios. Seminario de Titulación Protocolo de Comunicación Modbus CAPITULO 1 INTRODUCCIÓN A LAS REDES INDUSTRIALES AUTOMATIZACIÓN INDUSTRIAL Y REDES DE COMUNICACIÓN. VISTA GENERAL DE LA AUTOMATIZACIÓN INDUSTRIAL Y REDES DE COMUNICACIÓN. NIVELES JERÁRQUICOS EN SISTEMAS DE AUTOMATIZACIÓN INDUSTRIALES CONSIDERACIONES DE DISEÑO Puntos básicos, sobre la arquitectura de una red industrial y las necesidades que se tienen en una empresa a nivel proceso, así como las razones por las que los protocolos de los diferentes fabricantes deben poder ser integrados para formar un solo sistema. Seminario de Titulación Protocolo de Comunicación Modbus 1.1 AUTOMATIZACIÓN INDUSTRIAL Y REDES DE COMUNICACIÓN Cuando las tecnologías de automatización digitales se pusieron disponibles en los 60`s, fueron usadas para mejorar y agrandar los sistemas de automatización industriales. Los conceptos de fabricado de computadoras-integradas (CIM) y los sistemas de control de computadoras distribuidas (DCCSs) fueron introducidos en el campo de la automatización industrial y el uso de las redes de comunicación ha tenido un crecimiento acelerado. Los últimos sistemas de automatización industriales usan arquitecturas muy distribuidas donde un número de módulos digitales son interconectados por redes de comunicación para la adquisición de los datos y funciones de control a bajo nivel. En los sistemas de automatización industriales más modernos, la comunicación de los datos entre la los dispositivos automatizados juega un papel importante. La llave del éxito el integrar los sistemas de automatización grandes es poner mutuamente de acuerdo normas que permitan que todos los tipos diferentes de dispositivos de automatización se comuniquen entre sí. Por lo tanto, se han hecho esfuerzos internacionales notables de regularización en el área de redes de áreas locales. Los logros importantes en esta área incluyen el muy conocido, Modelo de Interconexión de Sistemas abierto (OSI-Open Systems Interconnection Model), Proyecto 802 de IEEE, y el Protocolo de Automatización Industrial (Manufacturing Automation Protocol (MAP)) concepto para habilitar la compatibilidad de sistemas bus y redes de áreas locales conecta a una red de computadoras de vendedores diferentes. El protocolo de automatización industrial (MAP) fue desarrollado para superar problemas de comunicación entre los dispositivos de automatización de varios fabricantes, y se aceptó ampliamente como una norma industrial para comunicaciones de datos en fábricas. La arquitectura de mini-Map es satisfacer Seminario de Titulación Protocolo de Comunicación Modbus las condiciones para comunicaciones en tiempo crítico y no incluye las capas 3 a 6 de las 7 capas de arquitectura del modelo OSI. La arquitectura del mini-Map consiste en la capa de la aplicación, la subcapa de control de enlace lógico (logical link control (LLC)), la subcapa de control de acceso al medio (medium access control (MAC)) y la capa física. La especificación del mensaje industrial (manufacturing message specification (MMS)) [2,5] fue desarrollado como la capa de la aplicación de la red MAP para lograr un intercambio del mensaje estándar entre los dispositivos de automatización de los diferentes vendedores. El desempeño y la condición de fiabilidad de un sistema de automatización industrial dependen substancialmente de su red de comunicación. En una red de comunicación para un sistema de automatización industrial, mejora el desempeño y fiabilidad de la red y se pide la regularización de la comunicación de acuerdo con la extensión del tamaño de sistema y el aumento de información. Los puntos siguientes deben ser considerados al diseñar una red de comunicación para un sistema de automatización industrial. Verifique el desempeño de la red para reunir los requisitos; Confirme los valores instalados de los diversos parámetros han sido adecuadamente fijados en todos los nodos. Verifique la fiabilidad de la red para reunir los requisitos Una red de comunicación para un sistema de automatización industrial debe garantizar los requisitos para el desempeño como es la utilización de la red, la conexión de una red de computadoras y el retraso de la transmisión. Todo esto juega un papel importante para determinar el desempeño global de un sistema de Seminario de Titulación Protocolo de Comunicación Modbus automatización industrial. La evaluación del desempeño de una red de comunicación puede ser hecha por simulación de los métodos analíticos. En la mayoría de los ambientes industriales, hay mucho ruido, emitido por las fuentes de ruido como robots soldando y grandes motores. El desempeño de una red de comunicación puede ser degradada por la interferencia de ruido, los efectos de ruido en el desempeño de una red de comunicación deben ser estudiados para obtener un desempeño practico de una red de comunicación aplicada a un ambiente ruidoso, qué es común en aplicaciones prácticas. Muchos problemas de comunicación en una red de comunicación para un sistema de automatización industrial son debidos a malas configuraciones en los diversos parámetros de la red como fue. Los parámetros de la red pueden determinar el desempeño de la misma. Además, los parámetros incorrectos pueden producir funcionamiento incorrecto de la red. Para conseguir valores apropiados, el ambiente local de un nodo en la red debe ser considerado, y los posibles links de comunicación entre los nodos deben ser considerados. Entre los componentes de un sistema de automatización industrial, la red de comunicación es un componente importante que se encarga del intercambio de información. Por consiguiente, la fiabilidad de un sistema de automatización industrial depende significativamente de la fiabilidad de su red de comunicación. Para aumentar la fiabilidad de una red de comunicación, muchos tipos de tolerancias a errores se están desarrollado y se ha aplicado para el sistema que requiere fiabilidad alta. Seminario de Titulación Protocolo de Comunicación Modbus 1.2 VISTA GENERAL DE LA AUTOMATIZACIÓN INDUSTRIAL Y REDES DE COMUNICACIÓN. A principios de los años 20, el sistema de control de proceso y el sistema industrial fueron diseñados basados principalmente en la tecnología mecánica y con dispositivos analógicos. Después del periodo, la tecnología de control neumático y el poder hidráulico fue introducida. La tecnología de control neumática hizo posible controlar sistemas remotos por un sistema de control centralizado. Estas tecnologías todavía son muy comunes. El uso de sistemas de control centralizados para grandes sistemas a aumentados con el desarrollo de los controladores electrónicos en los años cincuenta debido a la gran distancia de la transmisión. Muchos transmisores electrónicos fueron desarrollados durante este periodo. Algunos convertidores neumáticos a electrónicos fueron usados, y los convertidores electrónicos a neumáticos eran necesarios para conectar las válvulas neumáticas de control. Empezando los años cincuenta, muchos sistemas de comunicación industriales eran desarrollados para el control de sistemas. Estas redes usaban tecnología analógica, y fueron usadas para unir un procesador central al periférico y las terminales. El periférico era usado en paralelo, cables de muchos alambres, e interfaces serie de 20mA de corriente a baja frecuencia de transmisión. Al principio de 1960, la primera vez que se uso una computadora como un controlador digital. El término control digital directo (direct digital control (DDC)) fue usado para dar énfasis al control del proceso directamente por la computadora. En los años sesenta, la aplicación de una mini computadora era todavía una solución bastante cara para muchos problemas de control. Mientras tanto, el controlador lógico programable (programmable logic controller (PLC)) fue desarrollado y reemplazo a los convencionales que estaban basados en relevadores, que tenían funciones de control limitadas. Además, muchas tecnologías fueron desarrolladas para las herramientas de las maquinas y los procesos de producción discretos. El Seminario de Titulación Protocolo de Comunicación Modbus control numérico (numerically controlled (NC)) llego a controlar las herramientas de las maquinas por computadoras y el robot fue desarrollado en este periodo. Las técnicas y equipos necesarios para las comunicaciones de datos a gran velocidad fueron desarrollados en los años sesenta. La frecuencia de codificación cambio en los módems y eran capaces de transmitir datos sobre líneas dedicadas a velocidades de 1200 bit/s. La introducción de mini computadoras capaces de transferir datos a grandes velocidades llevó al desarrollo de las redes de comunicación de datos y los quipos de transmisión de datos a alta velocidad a fínales de los años 60 e inicio de los 70´s. A fines de los sesenta, Mollins del Reino Unido anunció su Sistema 24. Este sistema fue diseñado para operar varias máquinas bajo el control de una sola computadora. Se esperaba que con esto aumentara la productividad más allá del nivel alcanzable por el mismo número de máquinas trabajando independientemente. Este concepto de sistema industrial flexible (flexible manufacturing system (FMS)) actualmente es de gran interés como estructura conveniente para la creciente utilización en la máquina, reduciendo tiempo de manufacturado y un proceso de inventario. Con la introducción de FMS, el concepto de la fabricación integrada por computadora (computer integrated manufacturing (CIM)) hizo que se tomara atención en el área de automatización industrial para integrar los procesos de fabricación a computadoras digitales en todos los aspectos. Ahora el término CIM es usado en todos los tipos de sistemas industriales lo que significa la integración completa de las computadoras industriales, redes de comunicación, y sistemas de control de proceso en todas las funciones industriales. Con el uso más extenso de computadoras digitales y las tecnologías asociadas, las redes de comunicación industriales llegaron a ser desarrolladas con o transformar a la transmisión digital. La red de comunicación digital para uso Seminario de Titulación Protocolo de Comunicación Modbus industrial empezó en los años sesenta como computadoras para sistemas de automatización y fueron las primeras en unirse. A mediados de los setenta, el primer sistema de control de computadora distribuido (distributed computer control system (DCCS)) fue anunciado por Honeywell como un sistema de control jerárquico con un gran numero de microprocesadores. Desde que su introducción a mediados de los años setenta, el concepto de DCCS se extendió ampliamente en muchos sistemas de automatización industriales como sistema de control de energía en las fabricas, sistemas industriales, etc. La instalación de sistemas de control distribuidos recientemente en las fabricas planea o reemplaza la existencia analógica o los sistemas de control centralizado en el presente es una decisión común de la administración de la empresa. El uso de las redes de área local para interconectar computadoras y dispositivos de automatización dentro de un sistema de automatización industrial llego a ser popular desde 1980. La alta capacidad y el bajo costo ofrecido en la comunicación por redes de área locales han hecho una realidad la distribución de la informática, y muchos servicios de automatización. Los sistemas de automatización industriales frecuentemente se realizan como una arquitectura distribuida abierta con comunicación en redes de comunicaciones digitales. Es ahora común para usuarios conectados a una red de área local comunicarse con computadoras o dispositivos de automatización en otra red de área local unidas por una red de área ancha. Como los sistemas de automatización industriales llegaron a ser grandes y el número de dispositivos de automatización aumento, se ha hecho importante para la automatización industrial proporciona normas que hacen posible interconectar muchos dispositivos diferentes de automatización de una manera normal. Se han hecho esfuerzos de regularización internacionales considerables en el área de Seminario de Titulación Protocolo de Comunicación Modbus redes de áreas locales. Interconexión de Sistemas Abiertos (Open Systems Interconnection (OSI)) las normas que permiten a cualquier par de dispositivos de automatización comunicar fiablemente sin tener en cuenta el fabricante. El Protocolo de Automatización Industrial (Manufacturing Automation Protocol (MAP)) el concepto se ha desarrollado para habilitar la compatibilidad de redes de comunicación de vendedores diferentes. Para el nivel bajo de la red de comunicación para la Industria de automatización, las soluciones de red de área local industrial como MAP son demasiado caras y/o no alcanzan las necesidades de respuestas en tiempo cortos y dependiendo de la aplicación. Los fieldbuses han tenido, por consiguiente, un desarrollo para reunir estos requisitos, y están haciéndose muchos esfuerzos ahora hacer del fieldbus un estándar para las aplicaciones de automatización industriales. 1.3 NIVELES JERÁRQUICOS EN SISTEMAS DE AUTOMATIZACIÓN INDUSTRIALES Los sistemas de automatización industriales pueden ser muy complejos, y normalmente están estructurados dentro de varios niveles jerárquicos. Cada nivel jerárquico tiene un apropiado nivel de comunicación que coloca requisitos diferentes en la comunicación de red. En la figura 1.1 Se muestras un ejemplo de la jerarquía de un sistema de automatización industrial. Nivel de campo El nivel más bajo de la jerarquía de automatización es el nivel de campo que incluye los dispositivos de campo como actuadores y sensores. Los dispositivos de campo elementales a veces son clasificados como elementos de nivel. La tarea de los dispositivos en el nivel de campo es transferir datos entre el producto fabricado y el proceso técnico. Los datos pueden ser binarios y analógicos. Los Seminario de Titulación Protocolo de Comunicación Modbus valores moderados pueden estar disponibles para un periodo corto de tiempo o por un periodo largo de tiempo. Figura 1.1 jerarquía de un sistema de automatización industrial Para el nivel de campo la comunicación, paralelo, cables de varios alambres e interfaces de corriente como la de 20mA han sido ampliamente usados desde el pasado. Las normas de comunicación serie como RS232C, RS422 y RS485 son Seminario de Titulación Protocolo de Comunicación Modbus normalmente usadas como protocolos junto con las normas de comunicación paralela IEEE488. Estos métodos de comunicación de punto a punto han evolucionado a la red de comunicación de bus para cubrir con el costo de cableado y lograr una comunicación de alta calidad. Hoy día, el fieldbus es usado a menudo para el traslado de información en el nivel de campo. Debido a los requisitos de tiempo que tienen que ser observado estrictamente en un proceso de automatización, las aplicaciones en el nivel de campo requieren control cíclico de las funciones de transporte que transmiten la información de la fuente a intervalos de regulación. La representación de los datos debe ser tan corta como sea posible para reducir el tiempo de transferencia del mensaje en el bus. Nivel de célula En el nivel de célula, el flujo de información consiste principalmente en la carga de programas, parámetros y datos. En procesos con pequeñas maquinas los tiempos inactivos y reajustes, esto se hace durante el proceso de la producción. En pequeños controles puede ser necesario cargar subprogramas durante un ciclo industrial. Esto determina los requisitos de regulación. Para el funcionamiento del nivel de célula, la sincronización de la máquina y el manejo de evento pueden requerir tiempos cortos de respuestas en el bus. Estos requisitos en tiempo real no son compatibles con excesivos tiempos de transmisión de aplicación de programas, haciendo necesaria una adaptación de segmentación del mensaje. Para lograr los requisitos de comunicación en este nivel, se han usado redes de área local como la red de comunicación. Después de la introducción del concepto de CIM y el concepto de DCCS, muchas compañías desarrollaron sus propias redes para el nivel de célula de un sistema de automatización. El Ethernet junto con TCP/IP ((protocolo de control de la transmisión / protocolo de Internet (transmission control protocol / internet protocol)) fue aceptado como un factor Seminario de Titulación Protocolo de Comunicación Modbus normal para este nivel, aunque no se puede proporcionar una verdadera comunicación en tiempo real. Muchos esfuerzos se han hecho para la regularización de la red de comunicación para el nivel de célula. La norma IEEE de red basada en la arquitectura de capas OSI y la red mini-Map fue desarrolló en los años ochenta para comprender una comunicación normal entre los varios dispositivos de vendedores diferentes. Algunos fieldbuses también pueden usarse para este nivel. Nivel de área El nivel del área consiste en células combinadas dentro de grupos. Las células están diseñadas con aplicaciones orientadas al funcionamiento. Por los controladores de nivel de área o operadores de control, él controlando y las funciones intermedias están hechas como objetivos de producción, el encendido de la máquina y apagado, y actividades de emergencia. Nivel de planta El nivel de planta, es el nivel de cima de una planta o un sistema de automatización industrial. El nivel de planta de controlado reúne información de administración para los niveles de área, y maneja todo el sistema de automatización. Medios de transmisión. Un factor principal al elegir una red de comunicación industrial es el tipo de sistema de cableado físico o los medios de transmisión. Los más comunes medios de transmisión para las redes de comunicación industrial son alambres de cobre, Seminario de Titulación Protocolo de Comunicación Modbus en la forma de coaxial o par trenzado, fibra óptica y las tecnologías inalámbricas están también siendo usadas. El cable coaxial se usa para la transmisión de datos a gran velocidad en distancias a varios kilómetros. El cable coaxial está ampliamente disponible, relativamente barato, y puede ser instalado y mantenido fácilmente. Por estas razones se usa ampliamente en muchas redes de comunicación industriales. El par trenzado puede ser usado para transmitir datos en banda base a varios Mbit/s en distancias de 1 Km o más pero cuando la velocidad se aumenta la longitud máxima del cable es reducida. El par trenzado se ha estado usado durante muchos años y este también se usa ampliamente en redes de comunicación industrial. Es menos caro que el cable coaxial, pero no proporciona alta capacidad de transmisión o buena protección de la interferencia electromagnética. La Fibra óptica proporciona un incremento en la capacidad de transmisión arriba de giga bits, y es libre de la interferencia electromagnética. Sin embargo, el equipo asociado requerido es más caro, y es más difícil de derivar para las conexiones de multidrop. También si es usado para los cables del sensor en plantas de proceso se requeriría separar la instalación eléctrica de cobre para los instrumento de alimentación, que podrían también usarse para transmisión de señales. En muchas situaciones de medición móvil o temporal, lo dispositivos inalámbrico es una buena solución y está siendo usada ampliamente. Métodos de transmisión La comunicación de datos puede ser analógica o digital. Los datos analógicos toman continuamente los cambios en el valor. Seminario de Titulación Protocolo de Comunicación Modbus En comunicación digital, los datos pueden tomar solo valores binarios de 1 o 0. La transmisión puede ser asíncrona o síncrona, dependiendo de la manera de envió de los datos. En modo de transmisión asíncrona, los caracteres se envían usando el principio y el fin del código y cada carácter puede ser enviado independientemente a una velocidad no uniforme. El modo de transmisión síncrona es el método más eficaz. Los datos son transmitidos en bloques de caracteres, la salida exacta y el tiempo de llegada de cada bit son predecibles porque el reloj del remitente y el receptor están sincronizados. Los métodos de la transmisión en redes de comunicación industriales incluyen banda base, banda ancha, y banda portadora. En una transmisión de banda base, la transmisión consiste en un juego de signos que se aplican al medio de transmisión sin estar trasladada en frecuencia. La transmisión de banda ancha usa un rango de frecuencias que puede ser dividido en varios canales. La transmisión portadora usa sólo una frecuencia para transmitir y recibir información. La transmisión digital en fibra óptica es basada en representar los unos y ceros como pulsos de luz. Topología de red Tres principales topologías son empleadas para las redes de comunicación industriales: estrella, bus y anillo como se muestra en la Figura 1.2. Una configuración estrella contiene un control central, en que todos los nodos están conectados directamente. Esto permite una conexión fácil para las redes pequeñas, pero los controles adicionales deben ser agregados cuando un número Seminario de Titulación Protocolo de Comunicación Modbus máximo de nodos se alcanza. El fallo de un nodo en una configuración de estrella no afecta otros nodos. En la topología bus, cada nodo es directamente unido a un canal de comunicación común. Los mensajes transmitidos en el bus son recibidos por todos los nodos. Si un nodo falla, el resto de la red continúa en funcionamiento siempre que el nodo fallado no afecte los medios de comunicación. En la topología de anillo, el cable forma una vuelta y los nodos están unidos a intervalos alrededor de la vuelta. El mensaje es transmitido alrededor del anillo que comunica los nodos unidos a él. Si un solo nodo falla, la red entera pudiese detenerse a menos que un mecanismo de recuperación se lleve a cabo. Topología estrella Topología de bus Topología de anillo Figura 1.2 topologías de las redes industriales Seminario de Titulación Protocolo de Comunicación Modbus 1.4 CONSIDERACIONES DE DISEÑO El diseño de una red de comunicación involucra la planificación cuidadosa y la evaluación de diferentes opciones de diseño. El diseñador intenta lograr un máximo desempeño de la red a un costo razonable. Para alcanzar esta meta, los requisitos de comunicación y consideraciones para un sistema específico de automatización deben ser investigados. La estrategia global y la planeación son el paso más crítico en un diseño de red de comunicación. El sistema de automatización al cual la red de comunicación podrá aplicarse, deber ser investigado y los objetivos para la red de comunicación serán obtenidos. Para la planeación los factores a considerar son los siguientes. Costo Desempeño Fiabilidad o disponibilidad Servicio o funcionamiento de la Red Tolerancia con respecto al medio ambiente Medios físicos Expansión Mantenimiento Seguridad Costo El costo de conectar una red de computadoras consiste en los costos iniciales y los costos continuos. Los costes iniciales incluyen la compra de nuevo hardware y software, el diseño, la instalación y la puesta en marcha. Los costos continuos incluyen el mantenimiento del hardware y software, el pago a las personas que lo operan y arreglan la red y los costos para la expansión de la red y cambios de configuración. Seminario de Titulación Protocolo de Comunicación Modbus Desempeño El buen funcionamiento de la red es esencial. Sin él, incluso las actividades de comunicaciones normales llegan a ser difíciles y el continuo control del proceso de las aplicaciones requiere un alto funcionamiento de cómputo y ejecución de decisiones que llegaran a ser imposibles. La planificación eficaz debe incluir una estimación de requisitos de funcionamiento mínimos. La velocidad y la carga de la red son los principales factores para considerar en análisis de desempeño. Es importante definir y analizar las aplicaciones de la red, la operación y el tráfico en general de las comunicaciones. Las medidas típicas del funcionamiento para las redes de comunicación incluyen lo siguiente. Velocidad de transmisión. La velocidad de transmisión de la red es la proporción a la cual los bits de información están transmitidos por el cable de la red. Tiempo de respuesta. el tiempo de respuesta es el tiempo que toma realizar una acción de respuesta para ejecutar una aplicación del usuario que ha emitido una solicitud. Esto incluye el tiempo que toma transmitir un mensaje y la recepción, los sistemas para procesar la solicitud y la contestación del mensajes y el retraso de transmisión de la red. Utilización. La utilización del ancho de banda se refiere a la capacidad de enlace y usualmente es representada como la proporción de capacidad en uso. Aquí no hay ninguna regla clara para la utilización máxima de las redes de comunicación. Ethernet con más clientes degrada exponencialmente al 35% después de la utilización continua, mientras que token ring o las redes FDDI manejan más tráfico. Seminario de Titulación Protocolo de Comunicación Modbus Servicio o funcionamiento de la Red El diseñador de la red debe saber qué tipo de datos maneja la red y qué funcionalidad se requiere para encontrar la meta. La típica funcionalidad requerida en las redes de comunicación industriales incluye: Transferencia de archivos Terminal para conexión del host Descargar o cargar programas Descargar o cargar datos fijos Llamar al Programa Enviar y recibir datos (cortos) Apoyo a las aplicaciones distribuidas Tolerancia con respecto al medio ambiente Las redes de comunicación pueden ser a menudo armadas en zonas peligrosas y están expuestas a ambientes rudos. Las redes de comunicación para los sistemas de automatización industriales deben ser diseñadas para resistir interferencia electromagnética (EMI), interferencia de radio frecuencia (RFI), atmósferas corrosivas y de fluidos, temperaturas extremas y exposiciones a la intemperie. En un ambiente industrial, el exceso de EMI puede causar modificaciones en los paquetes de datos, retransmisiones frecuentes, y cargas altas en la red. Medios Físicos La selección de los medios físicos es una importante decisión técnica y económica, debe contar con los requisitos de las redes establecidas. Seminario de Titulación Protocolo de Comunicación Modbus Expansión Pocas redes permanecen estáticas ante el rápido crecimiento de las demandas comerciales y el desarrollo de la tecnología. El diseño de la red siempre debe incorporar un factor de flexibilidad para su crecimiento. Mantenimiento Todas las redes deben tener mantenimiento y servicio. El buen diseño de la red debe permitir un mantenimiento preventivo, actualización, y llevar a cabo reconfiguraciones con un mínimo o ninguna ruptura de funcionamiento de la red. Seguridad Los principales objetivos de medidas contra los ataques de seguridad son: Para minimizar la probabilidad de intrusión los dispositivos proporcionan protección y procedimientos. Para descubrir cualquier intrusión tan pronto como sea posible. Para poder identificar la información que ha estado sujetado a vinculaciones e identificar el estado de control, es necesario información para recuperar el enlace. Requisitos de comunicación para los Sistemas de Automatización Industrial Los requisitos de comunicación pueden depender del nivel en la jerarquía de los sistemas de automatización industrial. Seminario de Titulación Protocolo de Comunicación Modbus Comunicación en el nivel de campo En el nivel de campo en los sistemas de automatización, las comunicaciones están para intercambiar datos de los sensores individuales y el montón de actuadores en un mismo equipo de control local. Los requisitos de comunicación a este nivel incluyen lo siguiente. Respuestas cortas en tiempo. Los tiempos de respuesta de microsegundos y milisegundos se requieren para lazos de control rápido y apagado de las alarmas de seguridad de los sistemas. Tolerancia para el medio ambiente rudo. Los dispositivos de campo están frecuentemente montados en áreas peligrosas que requieren gabinetes a prueba de explosión, o medios intrínsecamente seguros. Distancia larga. Debe ser posible conectar dispositivos localizados a grandes distancias hasta los racks de terminales. Esto podría ser unos cientos de metros dentro de un área de la planta o muchos kilómetros a distancia como en una estación de bombeo en funcionamiento. Distribución de energía. La energía es normalmente distribuida en un alambrado de dos cables de señal para la mayoría de los dispositivos de campo. Esta fuente de energía está separada de otra fuente usada en la planta, y se suministra un respaldo de energía para su funcionamiento. Comunicación en el nivel de célula En el nivel de célula se encuentran los dispositivos de control, las consolas de mando de los operadores, los nodos de campo, etc. Están comunicados entre sí. Los requisitos de comunicación para el nivel de célula son los siguientes. Seminario de Titulación Protocolo de Comunicación Modbus Respuestas cortas en tiempo. La respuesta en tiempo en milisegundos y segundos se requiere para controlar la comunicación de un nodo de red a otro; para la alarma; y para las comunicaciones del operador, donde un gran número de datos puede pedirse al mismo tiempo. Tolerancia para el medio ambiente rudo. Cuando una red de nodos se mueve al campo, el hardware del sistema debe ser diseñado para resistir la interferencia electromagnética (EMI), la interferencia de radio frecuencia (RFI), atmósferas corrosivas y de fluidos, temperaturas extremas y exposiciones a la intemperie. Seguridad. El acceso al sistema de control debe ser diseñado para prevenir usos accidentales o no autorizados que puedan dañar el proceso de la planta. Respaldo de la alimentación. En los instantes en que falla la energía normalmente se proporciona un sistema redundante de alimentación, que pueden ser bancos de baterías o unidades generadoras. En general podemos concluir que el proceso para el diseño de una red es el mostrado en la siguiente figura: Estudio de fiabilidad Análisis Diseño Implementación Mantenimiento y Actualización Figura 1.3 Esquema del diseño de una red industrial Seminario de Titulación Protocolo de Comunicación Modbus CAPITULO 2 PROTOCOLO MODBUS INTRODUCCIÓN AL PROTOCOLO DE COMUNICACIÓN MODBUS. LOS DOS MODOS DE TRANSMISIÓN SERIAL TRAMAS DE MENSAJE MODBUS. MÉTODOS DE COMPROBACIÓN DE ERROR Presentación de uno de los protocolos más usados en la industria, este protocolo al no ser un estándar toma varias formas dependiendo del fabricante del equipo, se da un resumen sobre las diferencias entre un tipo de Modbus y otro, cabe mencionar que en la actualidad debido a esta diferencia en protocolos los equipos permiten configurar el tipo de Modbus a manejar. Seminario de Titulación Protocolo de Comunicación Modbus 2.1 Introducción al protocolo de comunicación Modbus Los controladores programables de Modbus pueden comunicarse entre si y con otros dispositivos instalados sobre una gran variedad de redes. Algunas de las redes soportadas son Modicon Modbus y Modbus Plus Industrial Networks, pero el alcance es más allá, ya que es posible comunicarse con redes estándares como son MAP y Ethernet. Estas redes son acezadas por puertos construidos por el controlador o por adaptadores de red, módulos opcionales y puertas de enlace que son disponibles por Modicon. El lenguaje común usado por todos los controladores Modicon es el protocolo Modbus, este protocolo define una estructura de mensaje que el controlador reconocerá y usara, sin tener en cuenta sobre el tipo de red que estén montados los dispositivos, describiremos el proceso que usa un controlador para pedir acceso a otro dispositivo, como responderá a las peticiones de otros dispositivos y como los errores serán detectados y reportados todo esto establecerá un formato común para el tamaño y contenido de cada mensaje. El protocolo de comunicación Modbus proporciona el estándar interno que usan los controladores Modicon para transmitir mensajes. Durante la comunicación en una red Modbus el protocolo determina como cada controlador conocerá la dirección de los dispositivos, reconocerá un mensaje para el, determinara el tipo de acción a tomar y la forma de extraer todo los datos o información contenida en el mensaje, si una respuesta es requerida el controlador creara esta y la enviara bajo protocolo Modbus. Usando Modbus sobre otras redes, el mensaje que contiene la información en Modbus es introducida en la trama o mensaje que es usado por esta red. Por ejemplo el controlador de Modicon para Modbus Plus o para MAP, con aplicaciones software como son librerías y drivers proporcionan la conversión Seminario de Titulación Protocolo de Comunicación Modbus entre el mensaje empaquetado de Modbus y la trama o mensaje utilizado por esta red para comunicarse entre sus diferentes nodos Esta conversión también es ampliada para resolver direccionamiento de nodos, direcciones de ruteo, método para la detección de error especifico para cada red, por ejemplo el dispositivo de Modbus con una dirección especifica, contenida en el protocolo Modbus será convertida en la dirección de nodo previo a la transmisión del mensaje, los campos de detección de error serán aplicados también a los paquetes de mensaje, compatible con el protocolo de esta red en el punto final del envió, sin embargo por ejemplo un controlador, el contenido del mensaje empaquetado. Escrito usando Protocolo Modbus define la acción que será tomada por el dispositivo al cual se le esta atendiendo. La figura 2.1 muestra como pueden ser conectados algunos dispositivos en una jerarquía de redes que emplean técnicas de comunicación ampliamente diferentes. En el intercambio de mensajes, el protocolo Modbus insertado en cada paquete de la red específica proporciona el lenguaje común mediante el cual cada dispositivo intercambia los datos. Seminario de Titulación Protocolo de Comunicación Modbus Host Procesador MAP 984-985 (Modbus Plus) y S980 (MAP) Modbus Programador P230 Modbus Plus AT/MC-984 y Host/MMI 984 A/B y S985 Modbus BM85 Modbus Programador P230 Cuatro dispositivos Modbus o 4 redes. Figura 2.1 Diagrama general de una posible aplicación con el protocolo Modbus Intercambio de Información en Una red Modbus Los puertos de Modbus estándar sobre controladores Modicon usan una interfase serial compatible con RS-232 que define los pines de entrada y salida, el cableado, los niveles de señal velocidad de transmisión en bauds y el chequeo de la paridad, los controladores pueden ser conectados a la red directamente o vía MODEM. La comunicación de los controladores Modbus usan una técnica de maestroesclavo, en donde solo un dispositivo denominado (el maestro) puede iniciar Seminario de Titulación Protocolo de Comunicación Modbus transferencias (llamadas preguntas). Los otros dispositivos (los esclavos) responderán proporcionando los datos solicitados por el maestro El maestro puede direccional esclavos individuales, o puede iniciar un mensaje a todos los dispositivos esclavos (broadcast). Los esclavos regresan un mensaje (llamado respuesta) a preguntas que son dirigidas a ellos individualmente. Los esclavos no regresaran respuestas cuando el maestro envía un mensaje a todos los dispositivos (un broadcast). El Protocolo Modbus establece el formato para las preguntas de los dispositivos maestros realizan poniendo en la pregunta la dirección del dispositivo al cual desea comunicarse (o pone una dirección de broadcast), un código de acciones definen la acción de respuesta, así como cada dato a ser enviado, y un campo de chequeo de error. Los mensajes de respuesta de los dispositivos esclavos son construidos usando solo protocolo Modbus. Estos mensajes contienen campos confirmando la acción tomada, cualquier dato que sea necesario regresar, y un campo de chequeo de error. Si un error ocurre en la recepción del mensaje, o si el dispositivo esclavo no es capaz de realizar la respuesta a la petición, el dispositivo esclavo construirá un mensaje de error y enviara esto como una respuesta. Intercambio de Información sobre redes diferentes a una red Modbus En adición a sus capacidades estándares de Modbus, Algunos modelos de controladores pueden comunicarse sobre Modbus Plus usando puertos de expansión o adaptadores de red, y sobre MAP, usando adaptadores de red. Sobre este tipo de redes, los controladores comunican mediante una técnica de par a par, en donde cualquier controlador puede iniciar envíos con los otros controladores. Así un controlador puede operar como un esclavo o como un maestro en envíos diferentes. Seminario de Titulación Protocolo de Comunicación Modbus Múltiples rutas internas son frecuentemente proporcionadas para permitir concurrentes procesos de intercambio de maestro a esclavo. En el nivel de mensajes, El protocolo Modbus aplica todavía el principio de maestro esclavo aunque el método de comunicación de la red sea par a par si un controlador origina un mensaje, lo hace como un dispositivo maestro y espera una respuesta de un dispositivo configurado como esclavo. De la misma forma, cuando un dispositivo recibe un mensaje, construye una respuesta (como dispositivo esclavo) y regresa el mensaje al controlador original. Mensaje de pregunta del maestro Dirección del dispositivo Dirección del dispositivo Código de función Código de función 8 bits Bytes de datos 8 bits Bytes de datos Chequeo de error Chequeo de error Mensaje de respuesta del maestro Figura 2.2 el ciclo de pregunta y respuesta maestro – esclavo. La pregunta: La función de código en la pregunta le indica al dispositivo esclavo direccionado el tipo de acción a realizar. Los bytes de datos contienen cualquier información adicional que el esclavo necesitará para llevar a cabo la función. Por ejemplo el código de función 03 pedirá al esclavo que lea registros sostenidos (holding registers.) y responda con sus contenidos. El campo de datos debe contener la información que indique al esclavo en qué registro debe comenzar y Seminario de Titulación Protocolo de Comunicación Modbus cuántos a de leer. El campo de comprobación de error proporciona un método para que el esclavo valide la integridad del contenido del mensaje recibido. La Respuesta: Si el esclavo elabora una respuesta normal, el código de función contenido en la respuesta es una réplica del código de función enviado en la petición. Los bytes de datos contienen los datos recolectados por el esclavo, tales como valores de registros o estados. Si ocurre un error, el código de función contenido en la respuesta es diferente al código de función enviado en la petición, para indicar que la respuesta es una respuesta de error y los bytes de datos contienen un código que describe el error. El campo de comprobación de error permite al maestro confirmar que los contenidos del mensaje son válidos. 2.2 Los dos modos de transmisión serial Los controladores pueden ser configurados para comunicar sobre redes standard Modbus utilizando cualquiera de los dos modos de transmisión: ASCII o RTU. Los usuarios seleccionan el modo deseado, junto con los parámetros de comunicación del puerto serie (velocidad, paridad, etc), durante la configuración de cada controlador. El modo y los parámetros serie deben ser los mismos para todos los dispositivos conectados a una red Modbus. La selección del modo ASCII o RTU tiene que ver únicamente con redes Modbus standard. Define los bits contenidos en los campos del mensaje transmitido en forma serie en esas redes. Determina cómo debe ser empaquetada y decodificada, la información en los campos del mensaje. En otras redes como MAP y Modbus Plus, los mensajes Modbus son situados en tramas sin relación con la transmisión serie. Por ejemplo una solicitud para leer registros sostenidos (holding reg.) puede ser manejada entre dos controladores en Modbus Plus, con independencia de la configuración actual de los puertos serie Modbus de ambos controladores. Seminario de Titulación Protocolo de Comunicación Modbus Modo ASCII Cuando los controladores se configuran para comunicar en una red Modbus según el modo ASCII (American Standard Code for Information Interchange), cada byte – 8 bits - en un mensaje se envía como dos caracteres ASCII. La principal ventaja de este modo es que permite intervalos de tiempo de hasta un segundo entre caracteres sin dar lugar a error. El formato para cada byte en modo ASCII es: Sistema de codificación: Hexadecimal, caracteres ASCII 0-9, A-F un carácter hexadecimal contenido en cada carácter ASCII del mensaje. Bits por byte: 1 bit de arranque. 7 bits de datos, el menos significativo se envía primero. 1 bit para paridad Par o Impar; ningún bit para No paridad. 1 bit de paro si se usa paridad; 2 bits si no se usa paridad. Campo de Chequeo de error: Comprobación Longitudinal Redundante (LRC). Modo RTU Cuando los controladores son configurados para comunicar en una red Modbus usando el modo RTU (Remote Terminal Unit), cada byte de 8 bits en un mensaje contiene dos dígitos hexadecimales de 4 bits. La principal ventaja de este modo es que su mayor densidad de carácter permite mejor rendimiento que el modo ASCII para la misma velocidad. Cada mensaje debe ser transmitido en un flujo continuo. Seminario de Titulación Protocolo de Comunicación Modbus El formato para cada byte en modo RTU es: Sistema de codificación: Binario 8-bits, hexadecimal 0-9, A-F. Dos dígitos hexadecimales contenidos en cada campo de 8 bits del mensaje. Bits por byte: 1 bit de arranque. 8 bits de datos, el menos significativo se envía primero. 1 bit para paridad Par o Impar; ningún bit para No paridad. 1 bit de paro si se usa paridad; 2 bits si no se usa paridad. Campo de Chequeo de error: Comprobación Cíclica Redundante (CRC). En cualquiera de los modos de transmisión serie (ASCII o RTU), un mensaje Modbus es situado por el dispositivo que transmite, en una trama que tiene un comienzo y un final conocidos. Esto permite a los dispositivos receptores comenzar en el arranque del mensaje, leer la parte de la dirección y determinar qué dispositivo es direccionado (o todos los dispositivos si es una difusión ‘dirección = 0’) y conocer cuándo se ha completado el mensaje. Mensajes parciales pueden ser detectados y establecer errores como resultado. En redes como MAP o Modbus Plus, el protocolo de red manipula la trama de los mensajes con delimitadores de comienzo y final que son específicos de la red. Esos protocolos también manipulan el envío al dispositivo de destino, haciendo innecesario el campo de la dirección Modbus integrado en el mensaje para la transmisión actual. (La dirección modbus es convertida a una dirección de nodo de la red y enrutada por el controlador remitente o sus adaptadores de red.) Seminario de Titulación Protocolo de Comunicación Modbus 2.3 Tramas de mensaje Modbus. Trama ASCII En modo ASCII, los mensajes comienzan con un carácter ( : ) ‘dos puntos’ (ASCII 3A hex) y terminan con un par de caracteres (CRLF) ‘Retorno de Carro + Avance de Línea) (ASCII 0D hex y 0A hex). Los caracteres a transmitir permitidos para todos los demás campos son 0-A, A-F hexadecimal. Los dispositivos conectados en red monitorizan el bus de red continuamente para detectar un carácter ‘dos puntos’. Cuando se recibe, cada dispositivo decodifica el próximo campo (el campo de dirección) para enterarse si es el dispositivo direccionado. Pueden haber intervalos de hasta un segundo entre caracteres dentro del mensaje. Si transcurre más tiempo entre caracteres, el dispositivo receptor asume que ha ocurrido un error. Se muestra una trama de mensaje típica. Figura 2.3 trama de mensaje ASCII Excepción: Con los controladores 584 y 984A/B/X, un mensaje ASCII puede terminar normalmente después del campo LRC sin enviar los caracteres CRLF. En ese caso, debe tener lugar una pausa de al menos 1 segundo. Si esto sucede, el controlador asumirá que el mensaje ha terminado normalmente. Seminario de Titulación Protocolo de Comunicación Modbus Trama RTU En modo RTU, los mensajes comienzan con un intervalo silencioso de al menos 3.5 tiempos de carácter. Esto es más fácilmente implementado como un múltiplo de tiempos de carácter a la velocidad de transmisión configurada en la red (mostrado como T1-T2-T3-T4 en la figura 2.4). El primer campo transmitido es entonces la dirección del dispositivo destinatario. Los caracteres a transmitir permitidos para todos los campos son 0-A, A-F hexadecimal. Los dispositivos conectados en red monitorizan el bus de red continuamente incluso durante los intervalos ‘silencioso’. Cuando el primer campo (el campo de dirección) es recibido, cada dispositivo lo decodifica para enterarse si es el dispositivo direccionado. Siguiendo al último carácter transmitido, un intervalo de al menos 3.5 tiempos de carácter señala el final del mensaje. Un nuevo mensaje puede comenzar después de este intervalo. La trama completa del mensaje debe ser transmitida como un flujo continuó. Si un intervalo silencioso de más de 1.5 tiempos de carácter tiene lugar antes de completar la trama, el dispositivo receptor desecha el mensaje incompleto y asume que el próximo byte será el campo de dirección de un nuevo mensaje. De forma similar, si un nuevo mensaje comienza antes de que transcurran 3.5 tiempos de carácter después de un mensaje previo, el dispositivo receptor lo considerará una continuación del mensaje previo. Esto dará lugar a un error, ya que el valor en el campo final CRC no será válido para el mensaje combinado. Aquí se muestra una trama de mensaje típica. Seminario de Titulación Protocolo de Comunicación Modbus Figura 2.4 trama de mensaje RTU Cómo es Manipulado el Campo Dirección El campo dirección de un mensaje contiene dos caracteres (ASCII) u ocho bits (RTU). Las direcciones de esclavo válidas están en el rango de 0 – 247 decimal. Los dispositivos esclavos individuales tienen direcciones asignadas en el rango 1 – 247. Un maestro direcciona un esclavo situando la dirección del esclavo en el campo dirección del mensaje. Cuando el esclavo envía su respuesta, sitúa su propia dirección en este campo dirección de la respuesta para dar a conocer al maestro qué esclavo está respondiendo. La dirección 0 es utilizada para dirección difusión, la cual todos los dispositivos esclavos reconocen. Cuando el protocolo Modbus es usado en redes de nivel más alto, las difusiones pueden no estar permitidas o pueden ser reemplazadas por otros métodos. Por ejemplo, Modbus Plus utiliza una base de datos global compartida que puede ser actualizada con cada rotación del testigo. Cómo es Manipulado el Campo Función El campo código de función de una trama de mensaje contiene dos caracteres (ASCII) u ocho bits (RTU). Los códigos válidos están en el rango de 1 – 255 decimal. De esos, algunos códigos son aplicables a todos los controladores Modicon, mientras que algunos códigos se aplican sólo en algunos modelos y otros están reservados para usos futuros. Los códigos actuales se describen en el Capítulo 2. Seminario de Titulación Protocolo de Comunicación Modbus Cuando un mensaje es enviado desde un maestro a un dispositivo esclavo, el campo del código de función indica al esclavo qué tipo de acción ha de ejecutar. Por ejemplo: leer los estados ON/OFF de un grupo bobinas o entradas discretas; leer el contenido de datos de un grupo de registros; leer el status de diagnóstico de un esclavo; escribir en determinadas bobinas o registros; o permitir cargar, salvar o verificar el programa dentro del esclavo. Cuando el esclavo responde al maestro, utiliza el campo del código de función para indicar bien una respuesta normal (libre de error) o que algún tipo de error ha tenido lugar (denominado respuesta de excepción). Para una respuesta normal, el esclavo simplemente replica el código de función original. Para un respuesta de excepción, el esclavo devuelve un código que es equivalente al código de función original con su bit más significativo puesto a valor 1. Por ejemplo, un mensaje desde un maestro a un esclavo para leer un grupo de registros sostenidos tendría el siguiente código de función: 0000 0011 (Hexadecimal 03) Si el dispositivo esclavo ejecuta la acción solicitada, sin error, devuelve el mismo código en su respuesta. Si ocurre una excepción. Devuelve: 1000 0011 (Hexadecimal 83) Además de la modificación del código de función para una respuesta de excepción, el esclavo sitúa un único código en el campo de datos del mensaje respuesta. Esto indica al maestro qué tipo de error ha tenido lugar, o la razón para la excepción. El programa de aplicación del maestro tiene la responsabilidad de manejar las respuestas de excepción. Procedimientos típicos son: enviar subsiguientes reintentos de mensaje, intentar mensajes de diagnóstico al esclavo y notificar operadores. Seminario de Titulación Protocolo de Comunicación Modbus Contenido del Campo Datos El campo datos se construye utilizando conjuntos de 2 dígitos hexadecimales, en el rango de 00 á FF hexadecimal. Pueden formarse a partir de un par de caracteres ASCII o desde un carácter RTU, de acuerdo al modo de transmisión serie de la red. El campo datos de los mensajes enviados desde un maestro a un esclavo, contiene información adicional que el esclavo debe usar para tomar la acción definida por el código de función. Esto puede incluir partes como direcciones discretas y de registros, la cantidad de partes que han de ser manipuladas y el cómputo de bytes de datos contenidos en el campo. Por ejemplo, si el maestro solicita a un esclavo leer un grupo de registros sostenidos (código de función 03), el campo de datos especifica el registro de comienzo y cuántos registros han de ser leídos. Si el maestro escribe sobre un grupo de registros en el esclavo (código de función 10 hexadecimal), el campo datos especifica el registro de comienzo, cuántos registros escribir, el cómputo de bytes de datos que siguen en el campo datos y los datos que se deben escribir en los registros. Si no ocurre error, el campo datos de una respuesta desde un esclavo al maestro contiene los datos solicitados. Si ocurre un error, el campo contiene un código de excepción que la aplicación del maestro puede utilizar para determinar la próxima acción a tomar. El campo datos puede ser inexistente (de longitud cero) en ciertos tipos de mensajes. Por ejemplo, en una petición de un dispositivo maestro a un esclavo para que responda con su anotación de eventos de comunicación (Código de función 0B hexadecimal), el esclavo no requiere ninguna información adicional. El código de función por sí solo especifica la acción. Seminario de Titulación Protocolo de Comunicación Modbus Contenido del Campo Comprobación de Error Dos tipos de métodos de comprobación de error son utilizados para las redes Modbus Standard. El contenido del campo Comprobación de Error depende del método que esté siendo utilizado. ASCII Cuando el modo ASCII es usado para trama de carácter, el campo Comprobación de Error contiene dos caracteres ASCII. Los caracteres de comprobación de error son el resultado de un cálculo Comprobación Longitudinal Redundante (LRC) que es realizado sobre el contenido del mensaje, excluyendo los ‘dos puntos’ del comienzo y los caracteres CRLF de finalización. Los caracteres LRC son añadidos al mensaje como el último campo que precede a los caracteres CRLF. RTU Cuando el modo RTU es usado para trama de carácter, el campo Comprobación de Error contiene un valor de 16 bits implementado como dos bytes de 8 bits. El valor de comprobación de error es el resultado de un cálculo Comprobación Cíclica Redundante (CRC) realizado sobre el contenido del mensaje. El campo CRC es añadido al mensaje como último campo del mensaje. La forma de hacerlo es, añadir primero el byte de orden bajo del campo, seguido del byte de orden alto. El byte de orden alto del CRC es el último byte a enviar en el mensaje. Hay información adicional sobre comprobación de error mas adelante en este capítulo. Se muestran los pasos detallados para generar los campos LRC y CRC en el Apéndice C. Seminario de Titulación Protocolo de Comunicación Modbus Cómo son Transmitidos los Caracteres en Serie Cuando los mensajes son transmitidos sobre redes serie standard Modbus, cada carácter o byte es enviado en este orden (izquierda a derecha): Bit Menos Significativo (LSB) ... Bit Mas Significativo (MSB) Con trama de carácter ASCII, la secuencia de bit es: Figura 2.5 Orden de bits ASCII Con trama de carácter RTU, la secuencia de bit es: Figura 2.6 Orden de bits RTU Seminario de Titulación Protocolo de Comunicación Modbus 2.4. Métodos de Comprobación de Error Las redes series standard Modbus utilizan dos tipos de comprobación de error. La comprobación de paridad (par o impar) puede ser aplicada opcionalmente a cada carácter. La comprobación de la trama (LRC o CRC) es aplicada al mensaje completo. Ambas comprobaciones, de carácter y de trama de mensaje son generadas en el dispositivo maestro y aplicadas a los contenidos del mensaje antes de la transmisión. El dispositivo esclavo comprueba cada carácter y la trama del mensaje completo durante la recepción. El maestro es configurado por el usuario para aguardar durante un tiempo de espera predeterminado antes de abortar la transacción. Este intervalo es establecido para ser lo suficientemente largo para que cualquier esclavo responda normalmente. Si el esclavo detecta un error de transmisión, el mensaje no será tenido en cuenta. El esclavo no construirá una respuesta para el maestro. Así el tiempo de espera expirará y permite al programa del maestro tratar el error. Observe que un mensaje direccionado a un dispositivo esclavo inexistente también causará un error de tiempo excedido - time out -. Otras redes tales como MAP y Modbus Plus utilizan comprobación de trama a un nivel por encima del contenido Modbus del mensaje. En esas redes, el campo de comprobación LRC o CRC del mensaje Modbus no se aplica. En caso de error de transmisión, el protocolo de comunicación específico a esas redes notifica al dispositivo que inició la comunicación que ha ocurrido un error y le permite reintentar o abortar de acuerdo a cómo ha sido configurado. Si el mensaje ha sido enviado, pero el dispositivo esclavo no puede responder, puede ocurrir un error de tiempo excedido que puede ser detectado por el programa del maestro. Seminario de Titulación Protocolo de Comunicación Modbus Control de Paridad Los usuarios pueden configurar los controladores para Control de paridad Par o Impar, o Sin Control de paridad. Esto determinará cómo será iniciado el bit de paridad en cada carácter. Si se especifica cualquier control de paridad Par o Impar, se contabilizará la cantidad de bits que tienen valor 1 en la porción de datos de cada carácter (siete bits de datos para modo ASCII, u ocho para RTU). Al bit de paridad habrá de darse valor 0 o 1, para que se obtenga finalmente un número par o impar, respectivamente, de bits con valor 1. Por ejemplo, estos 8 bits de dato forman parte de una trama de carácter RTU: 1100 0101 La cantidad de bits de valor 1 en el dato es cuatro. Si se utiliza Control de Paridad Par, el bit de paridad de la trama debe establecerse a valor 0, haciendo que la cantidad de bits de valor 1 siga siendo un número par (cuatro). Si se utiliza Control de Paridad Impar, el bit de paridad deberá tener valor 1, resultando una cantidad de bits de valor 1, impar (cinco). Cuando el mensaje es transmitido, el bit de paridad es calculado y aplicado a la trama de cada carácter. El dispositivo receptor cuenta la cantidad de bits de valor 1 y establece un error si no coincide la paridad con la configurada para ese dispositivo (todos los dispositivos en la red Modbus deben ser configurados para usar el mismo método de Control de paridad). Obsérvese que la comprobación de paridad sólo detecta si un número impar de bits se han alterado en una trama de carácter durante la transmisión. Por ejemplo, si se utiliza control de paridad Impar y dos bits de valor 1 de un carácter que tiene en origen 3 bits con valor 1, han quedado falseados (pasan a valor 0) durante la transmisión, el resultado es todavía un cómputo impar de bits de valor 1 (y por lo tanto el error no es detectado por este método). Seminario de Titulación Protocolo de Comunicación Modbus Si se especifica control No Paridad, no se transmite bit de paridad y no se hace comprobación de paridad. Se transmite un bit de paro adicional para rellenar la trama de carácter. Comprobación LRC En modo ASCII, los mensajes incluyen un campo de comprobación de error que está basado en un método de Comprobación Longitudinal Redundante (LRC). El campo LRC controla el contenido del mensaje, a excepción de los ‘:’ del comienzo y el par CRLF. Es aplicado con independencia de cualquier método de control de paridad utilizado para los caracteres individuales del mensaje. El campo LRC es un byte, conteniendo un valor binario de ocho bits. El valor LRC es calculado por el dispositivo emisor, que añade el LRC al mensaje. El dispositivo receptor calcula el LRC durante la recepción del mensaje y compara el valor calculado con el valor recibido en el campo LRC. Si los dos valores no son iguales, resulta un error. El valor LRC se calcula sumando entre sí los sucesivos bytes del mensaje, descartando cualquier acarreo y luego complementando a dos el valor resultante. Se realiza sobre el contenido del campo de mensaje ASCII excluyendo el carácter ‘:’ de comienzo del mensaje y excluyendo el par CRLF de final de mensaje. En la lógica de programación de controladores, la función CKSM calcula el LRC en base al contenido del mensaje. Para aplicaciones con ordenadores, se acompaña un ejemplo detallado sobre la generación del LRC, en el Apéndice C. Comprobación CRC En modo RTU, los mensajes incluyen un campo de comprobación de error que está basado en un método Comprobación de Redundancia Cíclica (CRC). El Seminario de Titulación Protocolo de Comunicación Modbus campo CRC controla el contenido del mensaje completo. Se aplica con independencia de cualquier método de control de paridad utilizado para los caracteres individuales del mensaje. El campo CRC es de dos bytes, conteniendo un valor binario de 16 bits. El valor CRC es calculado por el dispositivo emisor, que añade el CRC al mensaje. El dispositivo receptor calcula el CRC durante la recepción del mensaje y compara el valor calculado con el valor recibido en el campo CRC. Si los dos valores no son iguales, resulta un error. Para calcular el valor CRC Modbus se precarga un registro de 16 bits, todos ellos a 1. Luego comienza un proceso que toma los sucesivos bytes del mensaje y los opera con el contenido del registro y actualiza éste con el resultado obtenido. Sólo los 8 bits de dato de cada carácter son utilizados para generar el CRC. Los bits de arranque y paro y el bit de paridad, no se tienen en cuenta para el CRC. Durante la generación del CRC, se efectúa una operación booleana OR exclusivo (XOR) a cada carácter de 8 bits con el contenido del registro. Entonces al resultado se le aplica un desplazamiento de bit en la dirección de bit menos significativo (LSB), rellenando la posición del bit más significativo (MSB) con un cero. El LSB es extraído y examinado. Si el LSB extraído fuese un 1, se realiza un XOR entre el registro y un valor fijo preestablecido (*). Si el LSB fuese un 0, no se efectúa la función XOR (OR exclusiva). Este proceso es repetido hasta haber cumplido 8 desplazamientos. Después del último desplazamiento (el octavo), el próximo byte es operado XOR con el valor actual del registro y el proceso se repite con ocho desplazamientos más, como se ha descrito mas arriba y así con todos los bytes del mensaje. El contenido final del registro, después de que todos los bytes del mensaje han sido procesados, es el valor del CRC. Seminario de Titulación Protocolo de Comunicación Modbus Cuando el CRC es añadido al mensaje, primero se añade el byte de orden bajo seguido del byte de orden alto. En la lógica de programación de controladores, la función CKSM calcula el CRC en base al contenido del mensaje. Para aplicaciones con ordenadores, se acompaña un ejemplo detallado sobre la generación del CRC, en el Apéndice C. (*) El valor preestablecido es A001 hex, correspondiente al polinomio generador CRC16 ‘Inverso’, que es el que se aplica al CRC Modbus. Seminario de Titulación Protocolo de Comunicación Modbus CAPITULO 3 DATOS Y FUNCIONES DE CONTROL RESUMEN SOBRE LAS FUNCIONES DE CONTROL DETALLES DE LAS FUNCIONES MODBUS Este capitulo pretende dar un panorama de las funciones que realiza un controlador Modbus, de cómo un maestro realiza las peticiones y como es la respuesta de un dispositivo esclavo. Así como la explicación de cual es el propósito de cada función y los controladores que soportan a dichas funciones. Seminario de Titulación Protocolo de Comunicación Modbus 3.1 Formato de las Funciones Modbus Cómo son expresados los valores numéricos A menos que se especifique otra cosa, los valores numéricos (tales como direcciones, códigos, o datos) se expresan como valores decimales en el texto de esta sección. Son expresados como valores hexadecimales en los campos del mensaje de las figuras. Direcciones en los Mensajes Modbus Todos las direcciones en los mensajes Modbus son referenciadas a cero. La primera unidad de cada tipo de dato es direccionada como parte número cero. Por ejemplo: La bobina conocida como ‘bobina 1 ‘en un controlador programable es direccionada como bobina 0000 en el campo de dirección de un mensaje Modbus. La bobina 127 decimal es direccionada como bobina 007E hex (126 decimal). El registro mantenido 40001 es direccionado como registro 0000 en el campo de dirección de un mensaje Modbus. El campo código de función ya especifica una operación sobre un ’registro mantenido’. Por lo tanto la referencia ‘4XXXX’ está implícita. El registro mantenido 40108 es direccionado como registro 006B hex (107 decimal). Campos contenidos en los Mensajes Modbus La figura 3.1 muestra un ejemplo de un mensaje de petición Modbus. La figura 3.2 es un ejemplo de una respuesta normal. Ambos ejemplos muestran los campos Seminario de Titulación Protocolo de Comunicación Modbus contenidos en hexadecimal y también cómo estaría distribuido en la trama, un mensaje en modo ASCII o en modo RTU. La petición del maestro es una solicitud de Lectura de Registros sostenidos, al dispositivo esclavo con dirección 06. El mensaje solicita datos numéricos de tres registros sostenidos, 40108 al 40110. Observe que el mensaje especifica la dirección de comienzo como 0107 (006B hex). La respuesta del esclavo replica el código de función, indicando que esto es una respuesta normal. El campo ‘Cómputo de Bytes’ especifica cuántas unidades de datos de 8 bits se devuelven. Muestra la cantidad de bytes de datos que vienen a continuación, bien ASCII o RTU. En el modo ASCII, este valor representa la mitad del cómputo real de caracteres ASCII en el dato, ya que en este modo, cada dígito hexadecimal de 4 bits requiere un carácter ASCII y por lo tanto, debe haber dos caracteres ASCII para contener cada unidad de dato de 8 bits. Por ejemplo, el dato: 63 hex se envía como un byte – ocho bits - en modo RTU (0110 0011). El mismo valor, enviado en modo ASCII requiere dos caracteres ASCII, el ASCII ‘6’ (011 0110) y el ASCII ‘3’ (011 0011). El campo ‘Cómputo de bytes’ contabiliza este dato como una sola de dato de 8 bits , con independencia del método de trama de carácter (ASCII o RTU). Cómo Usar el Campo Cómputo de Bytes: Cuando se construyan respuestas en buffer, ponga en el campo correspondiente al Cómputo de Bytes un valor igual a la cantidad de bytes de datos contenidos en su mensaje (2 x nº de datos a enviar byte alto y byte bajo de cada dato - ). La figura 11 muestra cómo se implementa el cómputo de Bytes en una respuesta típica Seminario de Titulación Protocolo de Comunicación Modbus Figura 3.1 pregunta típica Figura 3.2 Respuesta típica Campos contenidos en los mensajes sobre Modbus Plus Seminario de Titulación Protocolo de Comunicación Modbus Los mensajes Modbus enviados sobre redes Modbus Plus están integrados en la trama dentro del nivel Logical Link Control (LLC). Los campos del mensaje Modbus sobre Modbus Plus consisten en bytes de 8 bits de forma similar a la utilizada con la trama RTU. El campo Dirección del Esclavo es convertido en un enrutamiento (‘ROUTING PATH’) por el dispositivo emisor. El campo CRC no se envía en el mensaje Modbus, porque sería redundante con la comprobación CRC realizada en el nivel High-level Data Link Control (HDLC). El resto del mensaje permanece como en el formato serie Standard. El software de aplicación (Bloques MSTR en los controladores, o Modcom III en ordenadores) manipula la trama del mensaje en una red de paquetes. La figura 3.3 muestra cómo se integraría una petición Leer Registros sostenidos en una trama para transmisión Modbus Plus. Seminario de Titulación Protocolo de Comunicación Modbus Figura 3.3 contenido de los campos en Modbus Plus 3.2 Código de funciones soportadas por los controladores El listado de más abajo muestra los códigos soportados por los controladores Modicon. Los códigos se listan en decimal. ‘Y’ indica que la función está soportada. ‘N’ indica que no está soportada. Código 01 02 03 04 05 06 07 08 Nombre Leer Estados de Bobinas Leer Estados de Entradas Leer Registros sostenidos Leer Registros de Entradas Forzar una única Bobina Preestablecer un único Registro Leer Status de Excepción Diagnosticos (ver Capítulo 3) 384 Y Y Y Y Y Y Y 484 Y Y Y Y Y Y Y 584 Y Y Y Y Y Y Y 884 Y Y Y Y Y Y Y M84 Y Y Y Y Y Y Y 984 Y Y Y Y Y Y Y Seminario de Titulación 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Programar 484 Selección 484 Buscar Contador de Eventos de Comunicación Buscar Anotac de Eventos de Comunic Programar Controlador Selección Controlador Forzar Múltiples Bobinas Preestablecer Múltiples Registros Reportar Identificación de Esclavo Programar 884/M84 Resetear Enlace de Comunicaciones Leer Referencia General Escribir Referencia General Escribir con máscara en Registros 4X Leer/Escribir Registros 4X Leer Cola FIFO Protocolo de Comunicación Modbus N N Y Y Y N N N Y N N N N N N N N Y Y Y Y Y Y Y N N N N N N N N N N Y Y Y N N N N N N N Y Y Y Y Y Y N N Y Y N N N N N N Y Y Y Y Y N N N N N N N N Y Y Y Y Y N N N N N Y Y Y Y Y Y N N Y Y (1) (1) (1) (1) Funciones soportadas solo en el 984-785 01 Lectura del estatus de una bobina Lee el estatus de ON/OFF de salidas discretas en el esclavo (referencia OX, bocinas). El apéndice B muestra los parámetros máximos soportados por varios modelos de controladores. Pregunta El mensaje de pregunta especifica la bobina de inicio y la cantidad de bobinas que serán leídas. Las bobinas son direccionadas iniciando en cero: bobinas del 1 -16 son direccionadas como 0-15. A continuación un ejemplo de una petición para leer las bobinas 20-56 del esclavo 17: Seminario de Titulación Protocolo de Comunicación Modbus Figura 3.4 pregunta para la lectura de estatus de una bobina Respuesta Los estatus de las bobinas en el mensaje es empaquetado como una bobina por bit de el campo de dato, Los estados son indicados como 1= ON; 0=OFF, el bit menos significativo de el primer byte de datos contiene la bobina direccionada en la pregunta, las otras bobinas siguen hacia el extremo del orden alto de este byte, y de ‘el orden bajo al orden alto ' en los bytes subsecuentes. Si la cantidad de bobinas regresadas no es un múltiplo de ocho, los bits sobrantes en el final del byte de datos serán puestos en ceros (hacia el fin del byte siguiendo el orden alto). El campo de conteo de bytes indica la cantidad de bytes de datos completos. Aquí el ejemplo de la respuesta a la pregunta realizada en la pagina anterior. Figura 3.5 respuesta que entregaría un dispositivo esclavo Seminario de Titulación Protocolo de Comunicación Modbus Los estatus de las bobinas 27-20 son mostrados como el byte con valor CD en hexadecimal o el binario 11001102. el estatus de la bobina numero 27 es el bit mas significativo del byte, y la bobina 20 el bit menos significativo. De izquierda a derecha el estatus de la bobina 27 hasta la 20 son:, ON–ON–OFF–OFF–ON–ON– OFF–ON. Por convención, el bit mas significativo del byte es puesto a la izquierda y el menos significativo a la derecha de dicho byte. Así las bobinas en el primer byte son de la “27 a la 20”, de izquierda a derecha. El siguiente byte tiene las bobinas “35 a la 28” de izquierda a derecha. Como los bits son trasmitidos serialmente, estos fluyen del bit menos significativo (LSB) a el más significativo (MSB): 20…..27, 28…..35, y así sucesivamente. En el ultimo byte de datos, el estatus de las bobinas son mostrados como el byte cuyo valor es 1B en hexadecimal o 00011011 en binario. La bobina numero 56 esta en la cuarta posición de la izquierda y la bobina numero 52 es el bit menos significativo del byte (LSB). Los estatus de las bobinas “56 a la 52” son ON-ONOFF-ON-ON. Note como los 3 bit restantes bits son llenados con ceros (hacia el extremo mas alto). 02 Lectura de estatus de entrada Descripción Lee los estatus de entradas discretas (referencia 1X) en el esclavo. Para una transmisión de tipo broadcast no esta soportado este tipo de operación. El apéndice B indica los parámetros máximos soportados por varios modelos de controladores. Seminario de Titulación Protocolo de Comunicación Modbus Pregunta El mensaje de pregunta especifica el inicio de las entradas y la cantidad de entradas a ser leídas. Entradas son direccionadas iniciando en cero: entradas de 1 a la 16 son direccionadas como 0-15. Aquí se muestra un ejemplo de una petición para leer las estradas de 1019710218 del dispositivo esclavo numero 17. Figura 3.6 pregunta para la lectura del estatus de una entrada Respuesta Los estatus de una entradas en el mensaje de respuesta es empaquetado como una entrada por bit del campo de datos. El estatus es indicado como: 1= ON; 0 = OFF. El bit menos significativo del primer byte de datos contiene la entrada direccionada en la pregunta. Las otras entradas siguen hacia el extremo mas significativo de este byte, y de menor a mayor en los bytes subsecuentes. Si la cantidad de status de entradas regresadas no es múltiplo de 8. los bits sobrantes en el byte final de datos serán puestos en cero (hacia el extremo más significativo del byte). El campo de conteo de bytes especifica la cantidad de bytes completos de datos. Aquí un ejemplo de la respuesta a la petición anterior. Seminario de Titulación Protocolo de Comunicación Modbus Figura 3.7 respuesta entregada por el dispositivo Los estatus de las entradas 10204-10197 son mostrados como el byte con valor AC en hexadecimal, o 10101100 en binario. La entrada 10204 es el bit más significativo de este byte, y la entrada 10197 es el bit menos significativo. De izquierda a derecha, los estatus de las entradas 10204 hasta 10197 son: ONOFF-ON-OFF-ON-ON-OFF-OFF. Los estatus de las entradas 10218-10213 son mostrados como el byte con valor 35 hexadecimal, o 00110101 binario. La entrada 10218 esta en la posición del tercer bit de la izquierda, y la entrada 10213 es el bit menos significativo (LSB). El estatus de las entradas 10218 hasta 10213 son ON-ON-OFF-ON-OFF-ON. Note como los dos bits sobrantes son llenados con cero (hacia el extremo más significativo). 03 Lectura de registros sostenidos Descripción Lee el contenido binario de registros sostenidos (referencia 4x) En transmisión modo broadcast esta opción no esta soportada. El apéndice B muestra los parámetros máximos soportados por varios modelos de controladores. Seminario de Titulación Protocolo de Comunicación Modbus Pregunta El mensaje de la pregunta especifica el registro de inicio y la cantidad de registros a ser leídos. Los registros son direccionados empezando en cero: registros de 1 – 16 son direccionados como 0-15. Aquí hay un ejemplo de una petición para leer los registros 40108 a 40110 del dispositivo esclavo 17. Figura 3.8 pregunta para la lectura de registros sostenidos Respuesta El dato del registro es empaquetado en el mensaje de respuesta como dos bytes por registro, tonel contenido en binario correctamente justificado en cada byte. Para cada registro, el primer byte contiene los bits de la parte alta, y el segundo contiene los bits de la parte baja. Los datos son revisados en el esclavo a razón de 125 registros por revisión para controladores 984-SEX (984-685, etc), y a razón de 32 registros por revisión para el resto de controladores. La respuesta es regresada cuando el dato es completamente integrado. A continuación se muestra un ejemplo de la respuesta a la pregunta anterior. Seminario de Titulación Protocolo de Comunicación Modbus Figura 3.9 Respuesta del dispositivo. El contenido del registro 40108 es desplegado como el valor de los dos bytes con valor de 02 2B en hexadecimal, o 555 en decimal. El contenido de los registros 40109-40110 son 00 00 y 00 64 en hexadecimal o 0 y 100 en decimal. 04 Lectura de registro de entradas. Descripción Lee el contenido binario de registros de entrada en el esclavo (referencia 3X). En el modo de transmisión broadcast no esta soportada esta función. El apéndice B muestra los parámetros máximos soportados por varios modelos de controladores. Pregunta El mensaje de petición especifica el registro de inicio y la cantidad de registros a ser leídos, los registros son direccionados iniciando en cero: los registros de 1-16 son direccionados como 0-15. Seminario de Titulación Protocolo de Comunicación Modbus A continuación un ejemplo de la petición para leer el registro 30009 del dispositivo esclavo 17. Figura 3.10 lectura de registros de entrada Respuesta El dato del registro es empaquetado en el mensaje de respuesta como dos bytes por registro, tonel contenido en binario correctamente justificado en cada byte. Para cada registro, el primer byte contiene los bits de la parte alta, y el segundo contiene los bits de la parte baja. Los datos son revisados en el esclavo a razón de 125 registros por revisión para controladores 984-SEX (984-685, etc), y a razón de 32 registros por revisión para el resto de controladores. La respuesta es regresada cuando el dato es completamente integrado. A continuación se muestra un ejemplo de la respuesta a la pregunta anterior. Seminario de Titulación Protocolo de Comunicación Modbus Figura 3.11 Respuesta a la función 04 El contenido del registro 30009 es representado con dos bytes cuyo valor es 00 0A en hexadecimal o 10 en decimal 05 Forzar bobinas simples Descripción Obliga a una simple bobina a tomar alguno de sus valores ON/OFF (referencia 0X). Cuando se usa un broadcast la función obliga a las mismas bobinas en todos los dispositivos adjuntados al mensaje. Nota la función sobrescribirá la memoria del controlador proteja el estado y desactive el estado de la bobina. El estado forzado permanecerá valido hasta que la siguiente lógica del controlador resuelva a la bobina. La bobina permanecerá forzada si no es re-programada en la lógica del controlador. El apéndice B muestra los parámetros máximos soportados por varios modelos de controladores. Pregunta El mensaje de petición especifica la bobina a ser forzada, las bobinas son direccionadas empezando por cero: la bobina 1 es direccionada como 0. Seminario de Titulación Protocolo de Comunicación Modbus El estado pedido de ON ó OFF es especificado por una constante en el campo de dato de la pregunta. Un valor de FF 00 (hexadecimal). Pide a la bobina que pase a su estado de ON. Un valor de 00 00 pide que pase a su estado de OFF. Cualquier otro valor es considerado ilegal y no afectara a la bobina. A continuación un ejemplo de una petición para forzar la bobina 173 en ON en el esclavo 17. Figura 3.12 pregunta para forzar bobinas Respuesta Una respuesta normal es un eco de la pregunta, regresando después el status de la bobina que ha sido forzado. El siguiente ejemplo es la respuesta normal a la pregunta anterior. Figura 3.13 Respuesta normal por parte del dispositivo. Seminario de Titulación Protocolo de Comunicación Modbus 06 Predeterminar registros simples Descripción Poner un valor predeterminado a un registro sostenido simple (referencia 4x). Cuando ocurre un broadcast, la función pone la misma referencia del registro en todos los esclavos adjuntos. Nota la función anulara el estado de protección de memoria del controlador. El valor fijado a este registro permanecerá valido en el registro hasta que la lógica del controlador re defina el contenido de este. El apéndice B muestra los parámetros máximos soportados por varios modelos de controladores. Pregunta El mensaje de pregunta especifica el registro que será fijado en un valor predeterminado. Los registros son direccionados empezando en cero: el registro 1 es el registro 0. El valor asignado esta especificado en el campo de dato de la pregunta. Los controladores M84 y 484 usan un valor de 10 bits con los 6 más significativos puestos en cero. Cualquier otro controlador usa un valor de 16 bits. A continuación un ejemplo de una petición para fijar el registro 40002 en el valor hexadecimal 00 03 para el dispositivo esclavo 17. Seminario de Titulación Protocolo de Comunicación Modbus Figura 3.14 pregunta para fijar registros. Respuesta La respuesta normal a esta solicitud es un eco de la pregunta, que es regresada después de que el contenido del registro ha sido modificado. Aquí se muestra la respuesta a la solicitud del ejemplo anterior. Figura 3.15 Respuesta normal por parte del dispositivo. 07 Lectura de estatus de excepción La función nos permite leer el contenido de 8 estatus de excepción en bobinas dentro del controlador del esclavo. Ciertas bobinas tienen asignaciones predefinidas en los diversos controladores. Otras bobinas pueden ser programadas por el usuario para mantener información sobre el estado de los controladores, por ejemplo, “maquina encendida/apagada” Seminario de Titulación Protocolo de Comunicación Modbus “cabezales abiertos”, “seguridad satisfactoria”, “presencia de condiciones de error”, o cualquier otra bandera definida por el usuario. Por la naturaleza de la función es evidente que no es posible el broadcast. Esta función proporciona un método simple para acceder a esta información, porque las referencias de las bobinas de excepción son conocidas (no se necesita la referencia de la bobina). Las asignaciones predefinidas en las bobinas de excepción son: Modelo del controlador Bobina Asignación M84, 184/384, 584, 984 1-8 Definida por el usuario 484 257 Estatus de la batería. 258-264 Definido por el usuario. 761 Estatus de la batería. 762 Estatus de la protección a la memoria. 763 RIO estatus de salud. 764-768 Definidas por el usuario 884 Aquí se muestra un ejemplo de una petición para el estatus de excepción en el dispositivo esclavo 17. Figura 3.16 pregunta para leer estatus de excepciones Seminario de Titulación Protocolo de Comunicación Modbus Respuesta La respuesta normal contiene el estatus de excepción de las 8 bobinas. Las bobinas son empaquetadas en un solo byte, con un bit por bobina. El estatus de la bobina con referencia menor es contenido en el bit menos significativo. Aquí esta un ejemplo de la respuesta a la petición. Figura 3.17 Respuesta normal por parte del dispositivo. En este ejemplo, el dato de las bobinas es 6D que en binario corresponde a 01101101. De izquierda a derecha las bobinas son: apagado- encendidoencendido- apagado- encendido- encendido- apagado- encendido. Los estatus son mostrados de la bobina con la dirección más alta a la más baja. Si el controlador es un 984, estos bits son los estatus de las bobinas 8 hasta 1. Si el controlador es a 484, estos bits son los estatus de las bobinas 264 hasta 257. en este ejemplo la bobina 257 esta en ON, indicando que la batería del controlador esta en perfecto estado. Seminario de Titulación Protocolo de Comunicación Modbus 11 (0B Hexadecimal) Sacar un contador de eventos de comunicaciones Descripción Retorna una palabra de estatus y un contador de evento del contador de eventos de comunicaciones del esclavo. Para traer el contador correcto antes y después de una serie de mensajes, un dispositivo maestro puede determinar si el mensaje fue manejado correctamente por el dispositivo esclavo. El contador de eventos del controlador es incrementado una vez por cada mensaje exitoso completo. Este contador no es incrementado por respuestas de excepción, comandos de encuesta, o comandos de traída del contador de eventos de comunicaciones. El contador de eventos puede ser peseteado por medio de la función de diagnostico (código 08) con una subfunción de nos da la opción de reiniciar las comunicaciones (código 00 01) o limpiar el contador y registro de diagnostico (código 00 0A). Pregunta Aquí mostramos el ejemplo de una petición para traer el contador de eventos de comunicación del dispositivo esclavo 17: Figura 3.17 pregunta para obtener el contador de eventos en las comunicaciones. Seminario de Titulación Protocolo de Comunicación Modbus Respuesta La respuesta normal contiene una palabra de estatus de dos bytes y un contador de eventos de 2 bytes. La palabra de estatus estará en unos en todos sus bits (FF FF hexadecimal) si un comando previamente emitido aun esta siendo ejecutado por el esclavo (una condición de ocupado existe). Si otra condición existe la palabra contendrá solo ceros en sus bits. Aquí se muestra la respuesta a la pregunta realizada previamente. Figura 3.18 Respuesta normal por parte del dispositivo. En este ejemplo, la palabra de ejemplo es FF FF (hexadecimal) indicando que una función del programa esta en ejecución en el esclavo. El contador de eventos es mostrado como 264 (01 08 hexadecimal) eventos han sido contados por el controlador. 12 (0C Hexadecimal) Traer el registro de eventos de comunicación. Descripción. Regresa una palabra de estatus, contador de eventos, contador de mensajes, y un campo de bytes de eventos del esclavo. El broadcast no esta soportado por esta función. Seminario de Titulación Protocolo de Comunicación Modbus La palabra de estatus y el contador de eventos son idénticos a los entregados por la función anterior (11 0B Hexadecimal, sacar un contador de eventos de comunicaciones). El contador de mensajes contiene la cantidad de mensajes procesados por el esclavo desde el ultimo reinicio, operación de limpieza de contadores, o encendido del equipo. Este contador es idéntico al que es regresado por la función de diagnostico (código 08), con la sub-función regresar contador de mensajes de bus (código 11, 0B hexadecimal). El campo de bytes de eventos contiene 0-64 bytes. En donde cada byte corresponde al estatus de una operación Modbus enviada o recibida por el dispositivo esclavo. Los eventos son ingresados por el esclavo dentro del campo en orden cronológico. El byte cero es el byte con el estatus del evento más reciente. Cada nuevo byte recorre a los demás en el campo de los 64 bytes. Pregunta Aquí esta un ejemplo de una petición para traer el registro de eventos de comunicaciones para el esclavo 17: Figura 3.19 pregunta para obtener el registro de eventos en las comunicaciones. Seminario de Titulación Protocolo de Comunicación Modbus Respuesta La respuesta normal contiene un campo de dos bytes con una palabra de estatus, un campo de dos bytes con el contador de eventos, un campo de dos bytes para el contador de mensajes, y un campo de 0-64 bytes de eventos. Un campo de contador de bytes define la longitud de los datos en estos cuatro campos. Aquí esta el ejemplo de la respuesta a la pregunta anterior. Figura 3.20 Respuesta normal por parte del dispositivo. En este ejemplo, la palabra de estatus es 00 00 hexadecimal, indicando que el esclavo no esta procesando una función del programa. El contador de eventos es mostrado como 264 (01 08 hexadecimal) eventos contados por el esclavo. El contador de mensajes es mostrado con el número 289 (01 21 hexadecimal) mensajes procesados por el esclavo. El evento más reciente de comunicación es mostrado en el byte de Event 0. Este contenido (20 hexadecimal) muestra que el dispositivo esclavo ha sido ingresado en el modo de solo escuchar. Seminario de Titulación Protocolo de Comunicación Modbus El evento anterior es mostrado por el campo Event 1. el contenido de este campo (00 00) muestra que el esclavo recibió un reinicio de comunicaciones. El esquema de los bytes de evento de la contestación se describe en la siguiente página. Que contienen los bytes de eventos Un byte de evento regresado por la función de traer el registro de eventos de comunicaciones puede ser cualquiera entre cuatro tipos. El tipo es definido por el bit 7 (el mas significativo) en cada byte, esto puede ser definido además por el bit 6. Eventos recibidos por el esclavo Modbus. Este tipo de bytes de eventos son almacenados por el esclavo cuando un mensaje de respuesta es recibido. Es almacenado antes que el esclavo procese el mensaje. Este evento es definido por el bit 7 puesto el estado lógico de 1. Los otros bits serán puestos con un uno lógico si las siguientes condiciones son ciertas. El esquema de bits es: Bit 0 1 2 3 4 5 6 7 Contenido No usado Error de comunicación No usado No usado Carácter desbordado Actualmente en modo de solo escuchar. Broadcast recibido 1 Eventos enviados por el esclavo Modbus Seminario de Titulación Protocolo de Comunicación Modbus Este tipo de bytes de eventos son almacenados por el esclavo cuando este termina de procesar un mensaje de petición. Este byte es almacenado por el esclavo si regresa una respuesta normal o de excepción, o no responde. Este evento es definido por el bit 7 puesto en un cero lógico, con el bit 6 puesto en uno lógico. Los otros bits serán puestos en 1 lógico si la condición correspondiente es verdadera. El esquema de bits es: Bit 0 1 2 3 4 5 6 7 Contenido Excepción de lectura enviado (código de excepción 1-3) Excepción de interrupción de esclavo (código de excepción 4) Excepción de esclavo ocupado (código de excepción 5-6) Excepción de programa NAK esclavo (código de excepción 4) A ocurrido un error de tiempo de espera para escritura Actualmente en modo de solo escuchar. 1 0 Dispositivo esclavo ingresado en modo de solo escuchar. Este tipo de byte de evento es almacenado por el esclavo cuando entra en el modo de solo escuchar. El evento es definido por un contenido de 04 hexadecimal. El esquema de bits es el siguiente: Bit 0 1 2 3 4 5 6 7 Contenido 0 0 1 0 0 0 0 0 Esclavo iniciado en modo de reiniciar comunicaciones Este tipo de bytes de eventos es almacenado por el esclavo cuando su puerto de comunicaciones es reiniciado. El esclavo puede ser reiniciado por la función de Seminario de Titulación Protocolo de Comunicación Modbus diagnostico (código 08), con la sub-función de reiniciar comunicación (código 00 01). Esta función también pone al esclavo en el modo de “continuar con error” o “parar con error”. Si el esclavo es puesto en el modo “continuar con error”, el byte de evento es sumado al registro existente de eventos. Si el esclavo es puesto en el modo de “parar con error”, El byte es sumado al registro y el resto del registro es borrado con ceros. El evento es definido por el contenido de ceros. El esquema de bits es: Bit 0 1 2 3 4 5 6 7 Contenido 0 0 0 0 0 0 0 0 15 (0F hexadecimal) forzar varias bobinas. Descripción Forzar cada bobina (referencia 0X) en una secuencia para ponerlas en encendido o apagado. Esta función tiene la posibilidad de ser enviada en un broadcast lo que ocasionara que las mismas bobinas sean forzadas en todos los esclavos de la red. Nota la función anulara el estado de protección de memoria del controlador y los estados de deshabilitación de las bobinas. El estado de forzamiento permanecerá valido en el registro hasta que la lógica del controlador resuelva los valores para cada bobina. Seminario de Titulación Protocolo de Comunicación Modbus El apéndice B lista los parámetros máximos soportados por varios modelos de controladores. Pregunta El mensaje de petición especifica la referencia de la bobina que será forzada. Las bobinas son direccionadas comenzando en 0: es decir la bobina uno es 0. El estado de encendido/apagado solicitado es especificado por el contenido del campo de dato de la pregunta. Un “1” lógico en la posición de bit corresponde a un estado de encendido de dicha bobina. Un “0” lógico indica una petición de estado apagado. El siguiente ejemplo muestra un ejemplo de la petición para forzar una serie de 10 bobinas iniciando en la bobina 20 (direccionada como 19 o 13 hexadecimal) en el dispositivo esclavo 17. Los datos contenidos en la pregunta son dos bytes: CD 01 hexadecimal (1100 1101 0000 0001 binario). Los bits binarios corresponden a las bobinas en el siguiente orden: Bit: 1 1 0 0 1 1 0 1 Bobina 27 26 25 24 23 22 21 20 0 0 0 0 0 0 0 1 - - - - - - 29 28 El primer byte transmitido (CD hexadecimal) de las bobinas direccionadas 27-20, con el bit menos significativo direccionando a la bobina menor (20) y que indica el valor a ser fijado. El siguiente byte transmitido (01 hexadecimal) de las bobinas direccionadas 29-28, con el bit menos significativo direccionando a la bobina menor (28). Los bits no utilizados en el último byte de datos deben ser llenados con ceros. Seminario de Titulación Protocolo de Comunicación Modbus Figura 3.21 Pregunta para forzar varias bobinas Respuesta La respuesta normal regresa la dirección del esclavo, código de función, dirección de inicio y cantidad de bobinas forzadas. Aquí esta la respuesta a la petición anterior: Figura 3.22 Respuesta normal por parte del dispositivo. 16 (10 hexadecimal) predefinir varios registros. Descripción Esta función pretende predefinir los valores en una secuencia de registros sostenidos (referencia 4X). Esta función soporta ser enviada por un broadcast y Seminario de Titulación Protocolo de Comunicación Modbus cuando esto ocurra la función fijara los mismos registros referenciados en todos los dispositivos esclavos. Nota la función anulara el estado de protección de memoria del controlador. Los valores permanecerán como validos en los registros hasta que la lógica del controlador resuelva el contenido de los registros. Los valores de los registros se conservar si no existe una lógica en el controlador que altere esto. El apéndice B lista los parámetros máximos soportados por varios modelos de controladores. Pregunta El mensaje de pregunta especifica las referencias de los registros que serán fijados. Los registros son direccionados iniciando en cero: el registro “1” es diseccionado como “0”. Los valores solicitados para ser fijados están especificados en el campo de datos de la pregunta. Los controladores M84 y 484 usan un valor binario de 10 bits. Con los seis bits de más alto orden puestos a cero. Todos los demás controladores usan un valor de 16 bits. Los datos son empaquetados como dos bytes por registro. Aquí se muestra un ejemplo de una petición para fijar dos registros iniciando en 40002 en 00 0A y 01 02 hexadecimal respectivamente en el esclavo 17: Seminario de Titulación Protocolo de Comunicación Modbus Figura 3.23 pregunta para fijar varios registros. Respuesta La respuesta normal regresa la dirección del esclavo, código de la función, dirección de inicio, y la cantidad de registros fijados. Aquí esta el ejemplo de la respuesta a la petición anterior: Figura 3.24 Respuesta normal por parte del dispositivo. Seminario de Titulación Protocolo de Comunicación Modbus 17 (11 hexadecimal) Reportar el identificador del Esclavo. Descripción Regresa una descripción del tipo de controlador presente en la dirección del esclavo, el indicador del estatus actual del controlador corriendo, y otra información específica para el dispositivo esclavo. El broadcast no esta soportado para este tipo de función. Pregunta: Aquí esta un ejemplo de una petición para reportar el identificador del dispositivo esclavo 17: Figura 3.25 pregunta para reportar el ID de un esclavo. Respuesta: El formato de una respuesta normal es mostrado en la siguiente figura. Los datos contenidos son especificados por cada tipo de controlador. Estos datos son mencionados en las siguientes páginas. Seminario de Titulación Protocolo de Comunicación Modbus Figura 3.26 Respuesta normal por parte del dispositivo. Resumen de los identificadores de los esclavos. Estos son los códigos de identificadores de los esclavos regresados por los controladores Modicon en el primer byte de los campos de datos: identificador de esclavo Controlador 0 Micro 84 1 484 2 184/384 3 584 8 884 9 984 184/384 El controlador 184 o 384 regresa una cantidad de bytes que será 4 o 74 (4A hexadecimal). Si el controlador esclavo de Modbus es el J346 y se encuentra instalado apropiadamente, y la su tabla interna de PIB es normal, la cantidad de bytes será 74. En cualquier otro caso los bytes serán 4. Los cuatro bytes que son regresados siempre son: Seminario de Titulación Protocolo de Comunicación Modbus Byte Contenido 1 ID del esclavo (2 para los controladores 184/384). Ver los bytes 3,4 para más información. 2 Indicador de estatus corriendo (0= apagado, FF= encendido). 3,4 Palabra de estado: Bit 0=0 Bit 1= estatus de protección de memoria (0= apagado, 1 = encendido) Bit 2,3 = tipo de controlador: Bit 2 = 0 y Bit 3 =0 indican un controlador 184. Bit 2 = 1 y Bit 3= 0 indican un controlador 384. Bits de 4 – 15 no usados. Los 70 bytes adicionales regresados por un controlador J347 correctamente instalado y tabla de PIB normal son: Byte Contenido 5, 6 Dirección de inicio de la tabla PIB 7, 8 Numero de serie del controlador 9, 10 identificador ejecutivo Los bytes 11 a 74 contienen a la tabla PIB. Estos datos son validos solo si el controlador esta corriendo (ver byte 2) la tabla contiene lo siguiente: 11,12 Numero máximo de bobinas de salida 13,14 Tabla de bobinas de salida habilitadas. 15,16 Dirección de bobina de entrada/tabla corriendo 17,18 Cantidad de bobinas de entrada. 19,20 Tabla de bobinas de entrada habilitadas. 21,22 Primer numero de picaporte (deberá ser múltiplo de 16) 23,24 Ultimo numero de picaporte (deberá ser múltiplo de 16) Seminario de Titulación Protocolo de Comunicación Modbus 25,26 Dirección de registros de entrada. 27,28 Cantidad de registros de entrada. 29,30 Cantidad de registros de salidas y registros sostenidos 31,32 Dirección de la lógica de usuario 33,34 Dirección de bobina de salida tabla RAM. 35,36 Función de inhibir mascara 37,38 Dirección de la rutina de función extendida. 39,40 Dirección de la rutina de transferencia de datos. 41,42 Dirección del vigilante de trafico 43,43 No usado 45,46 función de inhibir mascara 47,48 dirección de la tabla histórica modo A 49,50 Tabla de respuesta para impresora DX. 51,52 Cantidad de grupos de secuencia. 53,54 Dirección de las secuencias de la tabla imagen 55,56 Dirección de la secuencia RAM 57,58 Cantidad de registros 50XX 59,60 Dirección de la tabla 50XX 61,62 Dirección de bobina de salida imagen RAM 63,64 Dirección de entrada imagen RAM 65,66 Retardo de salida grupo de inicio 67,68 Retardo de salida grupo final 69,70 Línea de Watchdog 71,72 Direcciones RAM de los picaportes 73,74 Cantidad de grupos de salida retrasados 584 El controlador 584 regresa una cantidad de bytes de 9, de la siguiente manera: Seminario de Titulación Protocolo de Comunicación Modbus Byte Contenido 1 ID del esclavo (3 para el 584) 2 Indicador de estatus corriendo (0= apagado, FF= encendido) 3 Cantidad de secciones de 4k de paginas en memoria 4 Cantidad de secciones de 1k en RAM 5 Cantidad de segmentos de lógica del usuario 6,7 Palabra de estado de maquina (configuración de palabra 101, 65 hexadecimal) La palabra es organizada como sigue: Byte 6: Bit 15 (MSB del byte 6) = configuración del puerto 1 Bit 14= configuración puerto 2 Bit 13= puerto 1 dirección fija Bit 12 = puerto 2 dirección fija. Bit 11= no asignado Bit 10= estatus de barrido constante (0 = barrido constante apagado, 1 = encendido) Bit 9 = estatus de barrido simple (0 = barrido simple apagado, 1= encendido) Bit 8 = nodos de 16/24 bits (0= nodo de 24 bits, 1= nodo de 16 bits) Byte 7 Bit 7 (MSB del byte 7) = Alimentación (1= encendido, nunca debe ser 0). Bit 6= indicador de estatus corriendo (0= encendido, 1 =apagado). Bit 5= estatus de protección a la memoria (0= encendido, 1= apagado). Bit 4 = bateria OK (0=OK, 1= problema). Bit 3-0= no asignado 8,9 código de paro de maquina, la palabra es organizada como sigue: Seminario de Titulación Protocolo de Comunicación Modbus Byte 8: Bit 15 (MSB del byte 8) = alto controlado del puerto. Bit 14= no asignado Bit 13= conocimiento opaco Bit 12 = intervención perimetral ilegal Bit 11= solución invalida de la tabla de multiniveles Bit 10= inicio de nodo que no inicio segmento. Bit 9 = prueba no pasada de estado de RAM Bit 8 = No se detecto final de lógica, o cantidad errónea de segmentos. Byte 9 Bit 7 (MSB of byte 9) = expiración del watchdog timer. Bit 6= error del reloj de tiempo real. Bit 5= diagnostico del CPU fallido. Bit 4 = tipo de trafico invalido Bit 3 = tipo de nodo invalido. Bit 2 = error en la lógica del checksum Bit 1 =error en el checksum de respaldo Bit 0 =configuración ilegal. 984 El controlador 984 regresa una cantidad de 9 bytes, de la siguiente manera: Byte Contenido 1 ID del esclavo (9 para el 984) 2 Indicador de estatus corriendo (0= apagado, FF= encendido). 3 Cantidad de secciones de 4k de paginas en memoria 4 Cantidad de secciones de 1k en RAM 5 Cantidad de segmentos de lógica del usuario Seminario de Titulación 6,7 Protocolo de Comunicación Modbus Palabra de estado de maquina (configuración de palabra 101, 65 hexadecimal) La palabra es organizada como sigue: Byte 6: Bit 15 (MSB del byte 6) = No asignado Bit 14 - 11= No asignado Bit 10= estatus de barrido constante (0 = barrido constante apagado, 1 = encendido) Bit 9 = estatus de barrido simple (0 = barrido simple apagado, 1= encendido) Bit 8 = nodos de 16/24 bits (0= nodo de 24 bits, 1= nodo de 16 bits) Byte 7 Bit 7 (MSB del byte 7) = Alimentación (1= encendido, nunca debe ser 0). Bit 6= indicador de estatus corriendo (0= encendido, 1 =apagado). Bit 5= estatus de protección a la memoria (0= encendido, 1= apagado). Bit 4 = bateria OK (0=OK, 1= problema). Bit 3-1= no asignado Bit 0: bandera de tamaño bajo de memoria ( 0= No, 1= Tamaño bajo) Tamaño bajo de memoria: El Bit 0 de la palabra de estado de maquina define el uso del valor de tamaño bajo de memoria en palabras 99, 100 y 175 (63, 64 y AF hexadecimal) de la tabla de configuración. Si el Bit 0 = 1 lógico, el tamaño de memoria es calculado como sigue: Tamaño de la pagina 0 (palabras de 16 bits) = (palabra 99 * 4096) – (palabra 175 byte bajo *16) Tamaño de la tabla de estado (palabras de 16 bits) = (palabra 100 * 1024) – (palabra 175 byte alto *16) Seminario de Titulación 8,9 Protocolo de Comunicación Modbus código de paro de maquina, la palabra es organizada como sigue: Byte 8: Bit 15 (MSB del byte 8) = alto controlado del puerto. Bit 14= (984A, B, X) fallo en paridad de memoria extendida Bit 14= (otro 984) mal vigilante de entrada/salida Bit 13 = conocimiento nublado Bit 12 = intervención perimetral ilegal Bit 11= tabla de segmentos errónea. Bit 10= inicio de nodo que no inicio segmento. Bit 9 = prueba no pasada de estado de RAM Bit 8 = No se detecto final de lógica, o cantidad errónea de segmentos. Byte 9 Bit 7 (MSB of byte 9) = expiración del watchdog timer. Bit 6= error del reloj de tiempo real. Bit 5 (984A, B, X)= diagnostico del CPU fallido. Bit 5 (otro 984)= bobina dañada uso la tabla Bit 4 = S908 fallo de cabeza remota de IO Bit 3 = tipo de nodo invalido. Bit 2 = error en la lógica del checksum Bit 1 =error en el checksum de respaldo Bit 0 =configuración ilegal. MICRO 84 El controlador micro 84 regresa una cuenta de 8 bytes, de la siguiente manera: Seminario de Titulación Protocolo de Comunicación Modbus Byte Contenido 1 identificador del esclavo (0 para el micro 84) 2 Indicador de estatus corriendo (0= apagado, FF= encendido). 3 Número de puerto actual 4 Tamaño de la memoria 5-8 No usados (todos en ceros) 484 El controlador 484 regresa un total de 5 bytes, de la siguiente manera: Byte Contenido 1 identificador del esclavo (1 para el 484) 2 Indicador de estatus corriendo (0= apagado, FF= encendido). 3 Estado del sistema 4 Primer byte de configuración 5 Segundo byte de configuración 884 El controlador 884 regresa una cantidad de 8 bytes, distribuidos de la siguiente manera: Byte Contenido 1 identificador del esclavo (8 para el 884) 2 Indicador de estatus corriendo (0= apagado, FF= encendido). 3 Número del puerto actual 4 Tamaño de la lógica del usuario mas el estado de la RAM, en kilobytes (1 palabra = 2 bytes). 5 Reservado 6 Bits de enganche Seminario de Titulación Protocolo de Comunicación Modbus Bit 0 – 2 = reservado Bit 3 =desviación del trazador: 1 no usar el trazador estándar. Bit 4 = fin de la prueba de análisis, 1= fin del análisis de los links. Bit 5 = reservado Bit 6 = desviación del solucionador lógico, 1= no ejecutar el solucionador lógico estándar. Bit 7 = reservado 7,8 Reservados 20 (14 Hexadecimal) lectura de referencias generales. Descripción: Esta función regresa el contenido de los registros ubicados en el archivo de referencias de la memoria extendida (6XXX). El broadcast no esta soportado. La función puede leer grupos múltiples de referencias. El grupo puede ser separado (no necesariamente grupos contiguos), pero las referencias dentro de cada grupo deberán ser secuénciales. Pregunta La pregunta contiene la dirección del dispositivo Modbus, el código de la función, cantidad de bytes, y campo de chequeo de error. El resto de la pregunta especifica el grupo grupos de referencias que serán leídas. Cada grupo es definido en un campo separado entendiéndose como una sub. Petición que contiene 7 bytes: El tipo de referencia: 1 byte (será especificado como 6) El numero de archivo en la memoria extendida: 2 bytes (1 a 10, hexadecimal 0001 a 000A). La dirección del registro dentro del archivo: 2 bytes. La cantidad de registros que serán leídos. Seminario de Titulación Protocolo de Comunicación Modbus La cantidad de registros a ser leídos, combinados con todos los otros campos en la respuesta esperada, no podrán exceder la longitud de un mensaje modbus: 256 bytes. La cantidad de archivos de memoria extendida disponible depende del tamaño de memoria extendida instalada en el controlador esclavo. Cada archivo excepto el ultimo contiene 10,000 registros, direccionados como 0002-270F hexadecimal (0000 – 9999 decimal). El diseccionado de registros de referencia extendidos (6XXXX) difiere del diseccionado de registros de referencia sostenidos. El menor de los registros extendidos es diseccionado como el registro cero (600000). El menor de los registros sostenidos es diseccionado como uno (40001). Para controladores diferentes a los 984 – 785 con registros extendidos, el último registró (el mayor) en el último archivo es: Tamaño de memoria extendida Ultimo archivo Ultimo registro (decimal) 16K 2 6383 32K 4 2767 64K 7 5535 96K 10 8303 Para los controladores 984 – 785 con registros extendidos, el último registró (el mayor) en el ultimo archivo es mostrado en las dos tablas siguientes. 984 – 785 con cartucho de memoria AS-M785-032 Seminario de Titulación Protocolo de Comunicación Modbus Lógica del Situación de la Tamaño de la usuario RAM memoria Ultimo archivo Ultimo registro (decimal) extendida 32K 32K 0 0 0 16K 64K 72K 8 3727 984 – 785 con cartucho de memoria AS-M785-048 Lógica del Situación de la Tamaño de la usuario RAM memoria Ultimo archivo Ultimo registro (decimal) extendida 48K 32K 24K 3 4575 32K 64K 96K 10 8303 Un ejemplo de una petición para leer dos grupos de referencias del esclavo 17 es mostrado a continuación: Grupo 1 consiste de dos registros del archivo 4, iniciando en el registro 1 (dirección 0001). Grupo 2 consiste de dos registros del archivo 3, iniciando en el registro 9 (dirección 0009). Figura 3.27 Pregunta para la lectura de referencias generales Respuesta Seminario de Titulación Protocolo de Comunicación Modbus La respuesta normal es una serie de “sub – respuestas”, cada una de las “sub peticiones”. La campo de cantidad de bytes es el total combinado de la cantidad en todas las sub respuestas. En suma, cada “sub – respuesta” contienen un campo que muestra su propia cantidad de bytes. Figura 3.28 Respuesta normal por parte del dispositivo. 21 (15 Hexadecimal) Escritura de referencias generales. Descripción: Esta función escribe el contenido de los registros ubicados en el archivo de referencias de la memoria extendida (6XXX). El broadcast no esta soportado. La función puede escribir grupos múltiples de referencias. El grupo puede ser separado (no necesariamente grupos contiguos), pero las referencias dentro de cada grupo deberán ser secuénciales. Seminario de Titulación Protocolo de Comunicación Modbus Pregunta La pregunta contiene la dirección del dispositivo Modbus, el código de la función, cantidad de bytes, y campo de chequeo de error. El resto de la pregunta especifica el grupo grupos de referencias que serán escritos, y los datos a ser escritos en ellos. Cada grupo es definido en un campo separado entendiéndose como una sub. Petición que contiene 7 bytes más el dato: El tipo de referencia: 1 byte (será especificado como 6) El numero de archivo en la memoria extendida: 2 bytes (1 a 10, hexadecimal 0001 a 000A). La dirección del registro dentro del archivo: 2 bytes. La cantidad de registros que serán escritos. 2 bytes por registro. La cantidad de registros a ser escritos, combinados con todos los otros campos en la pregunta, no podrán exceder la longitud de un mensaje modbus: 256 bytes. La cantidad de archivos de memoria extendida disponible depende del tamaño de memoria extendida instalada en el controlador esclavo. Cada archivo excepto el ultimo contiene 10,000 registros, direccionados como 0002-270F hexadecimal (0000 – 9999 decimal). El diseccionado de registros de referencia extendidos (6XXXX) difiere del diseccionado de registros de referencia sostenidos. El menor de los registros extendidos es diseccionado como el registro cero (600000). El menor de los registros sostenidos es diseccionado como uno (40001). Para controladores diferentes a los 984 – 785 con registros extendidos, el último registró (el mayor) en el último archivo es: Seminario de Titulación Protocolo de Comunicación Modbus Tamaño de memoria extendida Ultimo archivo Ultimo registro (decimal) 16K 2 6383 32K 4 2767 64K 7 5535 96K 10 8303 Para los controladores 984 – 785 con registros extendidos, el último registró (el mayor) en el ultimo archivo es mostrado en las dos tablas siguientes. 984 – 785 con cartucho de memoria AS-M785-032 Lógica del Situación de la Tamaño de la usuario RAM memoria Ultimo archivo Ultimo registro (decimal) extendida 32K 32K 0 0 0 16K 64K 72K 8 3727 984 – 785 con cartucho de memoria AS-M785-048 Lógica del Situación de la Tamaño de la usuario RAM memoria Ultimo archivo Ultimo registro (decimal) extendida 48K 32K 24K 3 4575 32K 64K 96K 10 8303 Un ejemplo de una petición para escribir un grupo de referencias en el esclavo 17 es mostrado a continuación: El grupo consiste de tres registros en el archivo 4, iniciando en el registro 7 (dirección 0007). Seminario de Titulación Protocolo de Comunicación Modbus Figura 3.29 pregunta para escribir referencias generales. Respuesta: La respuesta normal es un eco de la pregunta Figura 3.30 Respuesta normal por parte del dispositivo. Seminario de Titulación Protocolo de Comunicación Modbus 22 (16 Hexadecimal) Escritura de registros 4X con una mascara. Descripción Modifica el contenido de un registro especifico 4XXXX usando una combinación de una mascara AND, un mascara OR, y el contenido actual de los registros. La función puede ser usada para fijar o limpiar individualmente bits en dicho registro. Un broadcast no es soportado para esta función. Pregunta La pregunta especifica la referencia 4XXXX a ser escrita, el dato a ser usado con la mascara AND, y el dato a ser usado con la mascara OR. El algoritmo de la función es: Resultado = (contenido actual del registro AND mascara_AND) OR (mascara_OR AND mascara_AND) Por ejemplo: Contenido actual = Hexadecimal Binario 12 0001 0010 mascara_AND = F2 1111 0010 mascara_OR = 25 0010 0101 mascara_AND = 0D 0000 1101 resultado = 17 0001 0111 Seminario de Titulación Protocolo de Comunicación Modbus Nota: si el valor de la mascara_OR es 0, el resultado es simplemente la lógica AND entre los valores actuales y la mascara_AND, si la mascara_AND tiene un valor de cero el resultado es igual al valor de la mascara_OR. El contenido del registro puede ser leído con la función de lectura de registros sostenidos (código de función 03). Pero los registros pueden serán cambiados por la lógica del controlador cuando este entre en esta parte de su rutina. Un ejemplo de cómo escribir en el registro 5 en el esclavo 17 a partir de una mascara se da a continuación: Figura 3.31 pregunta para la escritura de registros con una mascara. Respuesta La respuesta normal es un eco de la pregunta, y dicha respuesta es dada después de que se realiza la escritura de los registros. Figura 3.32 Respuesta normal por parte del dispositivo. Seminario de Titulación Protocolo de Comunicación Modbus 23 (17 hexadecimal) Lectura/escritura de registros 4X Descripción Desempeña una combinación de operaciones, una lectura y una escritura en un solo mensaje Modbus de transferencia. La función puede escribir un nuevo contenido a un grupo de registros 4XXXX. Un broadcast no es soportado por esta función. Esta función es soportada solamente en los controladores 984-785. Pregunta La pregunta especifica la direccion de inicio y la cantidad de registros del grupo a ser leidos, tambien especifica la direccion inicio, cantidad de registros y datos de los registros a ser escritos. El campo de cantidad de bytes especifica la cantidad de bytes que seguiran en el campo de escritura de datos. A continuación el ejemplo de una solicitud para leer seis registros comenzando en el registro 5, y escribir tres registros comenzando en el registro 16, todo esto en el esclavo 17. Seminario de Titulación Protocolo de Comunicación Modbus Figura 3.33 pregunta para la lectura/escritura de registros 4X. Respuesta La respuesta normal contiene los datos del grupo de registros que fueron leídos. El campo de cantidad de bytes especifica la cantidad de bytes que seguirán en el campo de lectura de datos. Aquí se muestra un ejemplo de la respuesta a la pregunta anterior. Seminario de Titulación Protocolo de Comunicación Modbus Figura 3.34 Respuesta normal por parte del dispositivo. 24 (18 hexadecimal) lectura de una cola FIFO. Descripción Esta función da lectura a una cola de registros 4X del tipo primero en entrar primero en salir. La función regresa la cantidad de registros en la cola, seguidos pos los datos de la cola. Hasta 32 registros pueden ser leídos: el contador, mas 31 registros almacenados en la cola. El contador de la colado es regresado primero y después los datos. La función da lectura a los datos que están contenidos en la cola, pero no limpia la cola después de realizar dicha operación. Broadcast no esta soportado. Esta función es soportada solo por los controladores 984 – 785. Seminario de Titulación Protocolo de Comunicación Modbus Pregunta La pregunta especifica la referencia de inicio 4XXXX a ser leída de la cola FIFO. Esta es la dirección del registro indicador usado con los bloques de función primero en entrar (FIN) y primero en salir (FOUT) del controlador. Contiene también la cantidad de registros almacenados en la cola actualmente. Los registros de datos seguirán secuencialmenté esta dirección. Un ejemplo de una petición para leer la cola FIFO en el esclavo 17 se da a continuación. La petición se hará para dar lectura a la cola iniciando en el registro indicador número 41247 (04DE hexadecimal). Figura 3.35 pregunta para la lectura de una cola FIFO. Respuesta En una respuesta normal, el campo de cantidad de bytes muestra la cantidad de bytes que seguirán. Incluyendo la cantidad de bytes de la cola y los bytes de datos de los registros (pero sin incluir el campo de chequeo de error). El contador de la cola es la cantidad de registros de datos en la cola (sin incluirse a si mismo). Seminario de Titulación Protocolo de Comunicación Modbus Si el contador de la cola excede 31, una respuesta de excepción es regresada con un código de error con el mensaje de valores de datos ilegales(03 Illegal value data). Esta es la respuesta a la pregunta anterior: Figura 3.36 Respuesta normal por parte del dispositivo. En este ejemplo, el registro indicador FIFO (41247 en la pregunta) es regresado con un contador de cola de 3. Los 3 registros de datos que seguirán al contador de cola son: 41248 (contiene 440 decimal – 01B8 hexadecimal); 41249 (contiene 4740 – 1284 hexadecimal); y 41250 (contiene 4898 – 1322 hexadecimal). Seminario de Titulación Protocolo de Comunicación Modbus CAPITULO 4 SUBFUNCIONES DE DIAGNOSTICO FUNCIÓN MODBUS 08 DIAGNÓSTICOS SUBFUNCIONES DE DIAGNOSTICO Este capitulo da una explicación clara y detallada de la función de diagnostico dentro de los controladores Modbus, así como un resumen detallado del propósito de las sub-funciones de esta función. Seminario de Titulación Protocolo de Comunicación Modbus 4.1 Función 08 Diagnósticos Descripción La función Modbus 08 proporciona una serie de pruebas para comprobar el sistema de comunicaciones entre el maestro y el esclavo, o para revisar varias condiciones internas de error dentro del esclavo. El broadcast no esta soportado. La función utiliza un campo de código de subfunción en la pregunta para definir el tipo de prueba que será realizada. En una respuesta normal el esclavo realiza un eco del código de función y del código de subfunción. La mayoría de las preguntas de diagnostico usa un campo de datos de dos bytes para mandar datos de diagnóstico o información de control para el esclavo. Algunos de los diagnósticos causan que los datos sean regresados del esclavo en una respuesta normal. Efectos del diagnostico en el esclavo. En general, emitir una función de diagnostico a un dispositivo esclavo no afecta el programa del usuario que esta corriendo en el esclavo. La lógica como son variables discretas y registros no son accesibles para diagnostico. Algunas funciones pueden opcionalmente resetear el contador de error en el esclavo. Un dispositivo esclavo puede, sin embargo, ser forzado en el modo de “solo escucha” en el cual monitoreara los mensajes sobre el sistema de comunicación pero sin responder a ellos. Esto puede afectar el resultado del programa de aplicación. Esto depende de cualquier intercambio extenso de datos con el dispositivo esclavo. Generalmente, el modo es forzado para remover un malfuncionamiento del sistema de comunicaciones del dispositivo esclavo. Seminario de Titulación Protocolo de Comunicación Modbus Un ejemplo de pregunta de diagnostico y su respuesta es mostrada en el siguiente ejemplo, mostrando la localidad del código de función, código de subfunción, y campo de datos dentro del mensaje. Una lista de códigos de subfunciones soportadas por los controladores es mostrada en las páginas después del ejemplo. Cada código de subfunción es listado con un ejemplo del contenido del campo de datos que aplica para ese diagnostico. Pregunta Este ejemplo es una petición para el esclavo 17 para regresar los datos. Este ejemplo usa una código de subfunción cero (00 00 hexadecimal en los dos bytes del campo). El dato a ser regresado es enviado en los dos bytes del campo de datos (A5 37 hexadecimal). Figura 4.1 pregunta de diagnostico. Respuesta La respuesta normal a la pregunta es un lazo de regreso que traerá los mismos datos que la pregunta. El código de función y código de subfunción son regresados también. Seminario de Titulación Protocolo de Comunicación Modbus Figura 4.2 respuesta de diagnostico Los campos de datos en la respuesta a diferencia de otro tipo de respuestas pueden contener contadores de error u otra información solicitada por la subfunción. La siguiente lista muestra los códigos de subfunción soportados por los controladores Modicon. Los códigos son mostrados en decimal. La S indica que la subfunción es soportada, de manera similar la literal N indica que dicho controlador no es capaz de soportar esta subfunción. Código Nombre 384 484 584 884 M84 984 00 Regreso de datos de la pregunta S S S S S S 01 Reinicio de comunicación S S S S S S 02 Regresa registro de diagnostico S S S S S S 03 Cambia el delimitador de entras ASCII S S S N N S 04 Forzar modo de solo escucha S S S S S S 05-09 Reservado 10 Limpia registros de control y diagnostico S S (1) N N (1) 11 Regresa el contador de mensajes del bus S S S N N S 12 Regresa de S S S N N S Regresa el contador de errores de excepción S S S N N S S S N N N el contador de errores comunicación en el bus 13 en el bus. 14 Regresa el contador de mensajes del esclavo S Seminario de Titulación 15 Protocolo de Comunicación Modbus Regresa el contador del esclavo de no S S S N N N respuestas. 16 Regresa el contador NAK del esclavo S S S N N S 17 Regresa el contador de ocupado del esclavo S S S N N S 18 Regreso caracteres S S S N N S Regreso del contador de IOP desbordados N N N S N N de N N N S N N N N N N N S del contador de desbordados en el bus. 19 (884). 20 borrar banderas y contadores desbordamiento 21 Obtener/borrar estadisticas de Modbus Plus 22-hacia Reservado arriba (1) Limpieza de contadores solamente 4.2 Subfunciones de diagnostico 00 regreso de datos de la pregunta Los datos de la pregunta tienen que ser regresados en la respuesta. El mensaje de respuesta tendrá que ser enteramente idéntico ala pregunta. Subfunción Campo de datos Campo de datos (pregunta) (pregunta) 00 00 cualquiera Eco de los datos de la pregunta 01 Opción de Reinicio de la Comunicación El puerto periférico del esclavo será inicializado y arrancado nuevamente, y todos sus contadores de eventos serán reiniciados. Si el puerto esta puesto en el modo de solo escucha. Ninguna respuesta será regresada. Esta función es la única que modifica el estado de solo lectura del puerto. Si el puerto no esta en el modo de Seminario de Titulación Protocolo de Comunicación Modbus solo lectura ocurrirá una respuesta normal. Esto ocurrirá antes de que se reinicie todo. Cuando el esclavo recibe la pregunta. Procura llevar a cabo un reseteo y ejecutar su prueba. Si la prueba concluye exitosamente esta función pondrá el puerto online. Un contenido de FF 00 hexadecimal en el campo de datos de la pregunta causa que los registros de eventos de comunicaciones de los puertos sean limpiados también. Un contenido de 00 00 dejara al histórico como estaba antes del reinicio. Subfunción Campo de datos Campo de datos (pregunta) (respuesta) 00 01 00 00 Eco de la pregunta 00 01 FF 00 Eco de la pregunta 02 Regreso del registro de diagnostico El contenido del registro de diagnostico de 16 bits del esclavo es regresado en la respuesta. Subfunción Campo de datos Campo de datos (respuesta) (pregunta) 00 02 00 00 Contenido del registro de diagnostico Nota. El contenido varia de controlador a controlador y es necesario verificar cual es dicho contenido. 03 Cambio del delimitador de entrada ASCII el carácter que es pasado en la pregunta dentro del campo de datos vendrá a ser el carácter delimitador del fin de mensaje para los futuros mensajes (remplazando Seminario de Titulación Protocolo de Comunicación Modbus el carácter por default Line Feed). Esta función es útil donde el line feed no es esperado en el final de los mensajes ASCII. Subfunción Campo de datos Campo de datos (respuesta) (pregunta) 00 03 Carácter 00 Eco de la pregunta 04 Forzar el modo de solo escucha Fija al esclavo direccionado en el modo de solo escucha para las comunicaciones en protocolo Modbus. Esto aísla el dispositivo del resto de la red, permitiéndoles comunicarse sin interrupción por parte del esclavo direccionado. Ninguna respuesta es regresada. Cuando el esclavo entra en el modo de solo escucha. Todos los controles de comunicación activos son apagados. El watchdog timer podrá expirar. Bloqueando los controles apagados. Mientras se este en este modo, ningún mensaje Modbus direccionado al esclavo o broadcast será monitoreado, así como ninguna acción será tomada y ninguna respuesta será enviada. La única función que puede regresar a la actividad a este dispositivo es la opción de reinicio de comunicaciones (código de función 8, subfunción 1). Subfunción Campo de datos Campo de datos (respuesta) (pregunta) 00 04 00 00 Ninguna respuesta es regresada 10 (0A hexadecimal) Borrar contadores y registro de diagnostico Para controladores diferentes a los 584 o 984, es posible borrar todos los contadores y el registro de diagnostico. Par el 584 o 984 solo es posible borrar los Seminario de Titulación Protocolo de Comunicación Modbus contadores. Los contadores también son borrados después de una falla de alimentación. Subfunción Campo de datos Campo de datos (respuesta) (pregunta) 00 0A 00 00 Eco de la pregunta 11 (0B hexadecimal) Regreso del contador de mensajes del Bus El campo de datos de la respuesta regresa la cantidad de mensajes que el esclavo a detectado sobre el sistema de comunicaciones desde el ultimo reinicio y borrado de contadores o desde la ultima falla de energía. Subfunción Campo de datos Campo de datos (respuesta) (pregunta) 00 0B 00 00 Cantidad de mensajes 12 (0C hexadecimal) Regreso del contador de errores de comunicación del Bus El campo de datos de la respuesta regresa la cantidad de errores CRC encontrados en el esclavo desde el ultimo reinicio y borrado de contadores o desde la ultima falla de energía. Subfunción Campo de datos Campo de datos (respuesta) (pregunta) 00 0C 00 00 Cantidad de errores CRC Seminario de Titulación Protocolo de Comunicación Modbus 13 (0D hexadecimal) Regreso del contador de errores de excepción en el Bus El campo de datos de la respuesta regresa la cantidad de respuestas de excepción Modbus desde el ultimo reinicio y borrado de contadores o desde la ultima falla de energía. Las respuestas de excepción son descritas en el apéndice A. Subfunción Campo de datos Campo de datos (respuesta) (pregunta) 00 0D 00 00 Cantidad de errores de excepción 14 (0E hexadecimal) Regreso del contador de mensajes del esclavo El campo de datos de la respuesta regresa la cantidad de mensajes direccionados al esclavo, o de broadcast que el esclavo procesó desde el ultimo reinicio y borrado de contadores o desde la ultima falla de energía. Subfunción Campo de datos Campo de datos (respuesta) (pregunta) 00 0E 00 00 Cantidad de mensajes del esclavo 15 (0F hexadecimal) Regreso del contador de No respuestas del esclavo El campo de datos de la respuesta regresa la cantidad de mensajes direccionados al esclavo, a los cuales no respondió (esto incluye a respuestas normales no a respuestas de excepción) desde el ultimo reinicio y borrado de contadores o desde la ultima falla de energía. Subfunción Campo de datos (pregunta) Campo de datos (respuesta) Seminario de Titulación 00 0F Protocolo de Comunicación Modbus 00 00 Cantidad de no respuestas del esclavo 16 (10 hexadecimal) Regreso del contador NAK del esclavo El campo de datos de la respuesta regresa la cantidad de mensajes direccionados al esclavo, a los cuales respondió con una respuesta de excepción del tipo “confirmación de recepción negativa” (Negative Acknowledge “NAK”) desde el ultimo reinicio y borrado de contadores o desde la ultima falla de energía. Las respuestas de excepción son descritas en el apéndice A. Subfunción Campo de datos Campo de datos (respuesta) (pregunta) 00 10 00 00 Contador NAK del esclavo 17 (11 hexadecimal) Regreso del contador de ocupado del esclavo El campo de datos de la respuesta regresa la cantidad de mensajes direccionados al esclavo, a los cuales respondió con una respuesta de excepción del tipo “Dispositivo esclavo ocupado” desde el ultimo reinicio y borrado de contadores o desde la ultima falla de energía. Las respuestas de excepción son descritas en el apéndice A. Subfunción Campo de datos Campo de datos (respuesta) (pregunta) 00 11 00 00 Contador de dispositivo ocupado del esclavo 18 (12 hexadecimal) Regreso del contador de caracteres desbordados en el bus. Seminario de Titulación Protocolo de Comunicación Modbus El campo de datos de la respuesta regresa la cantidad de mensajes direccionados al esclavo, que no pudo manejar debido a una condición de desbordamiento de caracteres desde el ultimo reinicio y borrado de contadores o desde la ultima falla de energía. Un desbordamiento de caracteres es causado por caracteres llegando al puerto a una velocidad mayor a la que pueden ser almacenados, o por la pérdida de caracteres debido a un mal funcionamiento de hardware. Subfunción Campo de datos Campo de datos (respuesta) (pregunta) 00 12 00 00 Contador de caracteres desbordados del esclavo 19 (13 hexadecimal) Regreso del contador de IOP desbordados (884). El campo de datos de la respuesta regresa la cantidad de mensajes direccionados al esclavo, que no pudo manejar debido a una condición de desbordamiento de IOP desde el ultimo reinicio y borrado de contadores o desde la ultima falla de energía. Un desbordamiento de IOP es causado por caracteres llegando al puerto a una velocidad mayor a la que pueden ser almacenados, o por la pérdida de caracteres debido a un mal funcionamiento de hardware Esta función es específica del 884. Subfunción Campo de datos Campo de datos (respuesta) (pregunta) 00 13 00 00 Contador de IOP desbordados del esclavo 20 (14 hexadecimal) borrar banderas y contadores de desbordamiento Seminario de Titulación Protocolo de Comunicación Modbus Borra el contador de errores de desbordamiento en el 884 y reinicia las banderas de error. El estado actual de la bandera es encontrado en el bit 2 del registro de diagnosticó del 884. Esta función es específica para el 884. Subfunción Campo de datos Campo de datos (respuesta) (pregunta) 00 14 CAPITULO 5 00 00 Eco de los datos en la pregunta. Seminario de Titulación Protocolo de Comunicación Modbus MODBUS TCP/IP MODELO CLIENTE SERVIDOR DESCRIPCIÓN DEL PROTOCOLO DESCRIPCIÓN FUNCIONAL Este capitulo comprende al protocolo Modbus TCP/IP, variante del protocolo Modbus, describe la filosofía de funcionamiento, al mismo tiempo muestra las posibilidades de interconexión que se tienen, surgiendo de la necesidad de integrar equipos de tecnologías seriales a redes empresariales. Seminario de Titulación Protocolo de Comunicación Modbus 5.1 MODELO cliente servidor Los mensajes de Modbus proporcionan una comunicación cliente / servidor entre dispositivos conectados en una red Ethernet TCP /IP Este modelo de cliente servidor esta basado en cuatro tipos de mensajes: Petición Modbus Confirmación Modbus Indicación Modbus Respuesta Modbus Figura 5.1 Modelo cliente servidor Una Petición de Modbus es el mensaje enviado sobre la red por el cliente para iniciar una transferencia. Una indicación de Modbus es el mensaje a la pregunta recibida del lado del servidor. Una respuesta de Modbus es el mensaje de respuesta enviado por el servidor. Una confirmación de Modbus es el mensaje a la pregunta recibida del lado del cliente. El servicio de mensajes Modbus es usado para el intercambio de información en tiempo real: Entre aplicaciones de dos dispositivos Seminario de Titulación Protocolo de Comunicación Modbus Entre la aplicación de un dispositivo y otro dispositivo. Entre aplicaciones de SCADA/Sistemas de control y dispositivos. Entre una PC y un programa de dispositivo proporcionando servicios en línea. 5.2 Descripción del protocolo Arquitectura general de comunicación Un sistema de comunicación sobre MODBUS TCP/IP puede incluir diferentes tipos de dispositivos: Un cliente MODBUS TCP/IP y dispositivos servidores conectados a una red TCP/IP. Los dispositivos de interconexión como son puentes, routers o puertas de enlace para la interconexión entre la red TCP/IP y un a sub red serial que permita la conexión de clientes Modbus seriales y servidores y dispositivos. Figura 5.2 Arquitectura de comunicaciones Modbus TCP/IP Seminario de Titulación Protocolo de Comunicación Modbus El protocolo de comunicaciones MODBUS define un simple protocolo unidad de datos (PDU) independiente de las capas subyacentes de red. EL trazado del protocolo Modbus sobre redes o buses específicos puede agregar algunos campos adicionales a la unidad de datos de la aplicación (ADU). Figura 5.3 Trama general de Modbus. El cliente que inicia una transferencia de Modbus construye la unidad de datos de la aplicación. El código de la función indica al servidor que tipo de acción será desempeñada. La unidad de datos de la aplicación sobre MODBUS TCP/IP Esta sección describe el encapsulamiento de una petición o respuesta de Modbus cuando es cargada sobre una red TCP/IP. Figura 5.4 pregunta o respuesta sobre TCP/IP Un encabezado dedicado es usado sobre TCP/IP para definir la unidad de datos de la aplicación. Este encabezado es llamado encabezado MBAP (encabezado de aplicación del protocolo MODBUS). Seminario de Titulación Protocolo de Comunicación Modbus Este encabezado proporciona algunas diferencias comparado a la unidad de datos de la aplicación MODBUS RTU usado en líneas seriales. El campo de dirección Modbus del esclavo comúnmente usada en la transmisión serial es remplazada por un solo byte “identificador de unidad” dentro del encabezado MBAP. El identificador de unidad es usado para comunicarse a través de los dispositivos como son puentes, routers y puertas de enlace que usan una simple dirección IP para soportar varias unidades de Modbus independientes. Todas las peticiones y respuestas son diseñadas de una manera tal que el receptor pueda verificar que un mensaje esté acabado. Para códigos de funciones donde el PDU (protocolo de unidad de datos) Modbus tiene una longitud fija, el código de la función es suficiente. Para códigos de función que cargan con una variable para contar la cantidad de datos en una petición o respuesta, el campo de datos incluye un contador de bytes. Cuando MODBUS es cargado sobre TCP, la información al adicional es cargada en el encabezado MBAP para permitirle al receptor para reconocer límites del mensaje iguale si el mensaje ha estado dividido en múltiples paquetes para la transmisión. Descripción del encabezado MBAP Campos Longitud Descripción Cliente Servidor Identificador de 2 Bytes Identificación Iniciado por el Recopilado por transferencia de una petición cliente el servidor de MODBUS/trans la petición ferencia de recibida. respuesta Identificador de 2 Bytes 0= protocolo Iniciado por el Recopilado por protocolo MODBUS cliente el servidor de Seminario de Titulación Protocolo de Comunicación Modbus la petición recibida Longitud 2 Bytes Numero de Iniciado por el Iniciado por el bytes cliente servidor siguiendo (petición) (respuesta) Identificador de 1 Byte Identificación Iniciado por el Recopilado por unidad de un esclavo cliente el servidor de conectado la petición remotamente recibida en una línea serial o sobre otro bus. El encabezado tiene una longitud de 7 bytes: Identificador de transferencia – es usado para la transferencia en pares, el servidor copia en la respuesta el identificador de transferencia de la petición. Identificador de protocolo – es usado para multiplexar intra – sistemas, El protocolo MODBUS es identificado por el valor de cero. Longitud – El campo de longitud es un contador de bytes de los siguientes campos, incluyendo el identificador de unidad y los campos de datos. Identificador de unidad – este campo es usado para propósitos de enrutar intra – sistemas. Es típicamente usado para comunicar esclavos MODBUS o MODBUS PLUS (que son protocolos de líneas seriales) a través de una puerta de enlace entre una RED ethernet TCP/IP y una línea serial. Este campo es fijado por el cliente MODBUS en la petición y debe ser regresado con el mismo valor en la respuesta por el servidor. Todas las unidades de datos de la aplicación son enviadas vía TCP sobre el puerto 502. Seminario de Titulación Protocolo de Comunicación Modbus 5.3 Descripción funcional La arquitectura de los componentes MODBUS presentados aquí es un modelo general incluyendo ambos componentes el servidor y el cliente MODBUS y usado en cualquier dispositivo. Aplicación del Usuario Capa de comunicaci ón de la aplicación Interfase Cliente Modbus Cliente Modbus Parte trasera de la interfase modbus Servidor Modbus Administrad or TCP Pila de parametrizaci on Administrador de conexión Control de acceso Pila TCP/IP Algunos dispositivos solo pueden proporcionar los componentes para funcionar como servidores o como clientes. Modelo de la arquitectura de los componentes MODBUS. Figura 5.5 Arquitectura conceptual delservicio de mensajes MODBUS Seminario de Titulación Protocolo de Comunicación Modbus Capa de comunicaciones de la aplicación Un dispositivo de Modbus puede proporcionar una interfase de cliente y/o servidor. La parte trasera de una interfase Modbus puede ser proporcionada permitiendo el acceso indirectamente a los objetos de la aplicación del usuario. Cuatro áreas pueden componer esta interfase: entradas discretas, salidas discretas (bobinas), entrada de registros y salida de registros. Un trazado entre esta interfase y la aplicación de datos del usuario tiene que ser realizada (edición local). Tablas Tipo de principales objeto Entradas Bit simple tipo Comentario Solo lectura Este tipo de dato puede ser discretas proporcionado por un sistema de entrada/salida Bobinas Bit simple Lectura/escrit Este tipo de dato puede ser ura alterado por un programa de aplicación Registros de Palabra de 16 Solo lectura Este tipo de dato puede ser entrada bits proporcionado por un sistema de entrada/salida Registros Palabra de 16 Lectura/escrit Este tipo de dato puede ser sostenidos bits alterado por un programa de ura aplicación Seminario de Titulación Protocolo de Comunicación Modbus Entradas discretas Petición MODBUS Bobinas Registros de entrada Registros de salida Memoria del dispositivo de aplicación Dispositivo Servidor Modbus Figura 5.6 Modelo de los datos Modbus con bloques separados Memoria del dispositivo de aplicación Entradas discretas Bobinas Petición MODBUS Registros de entrada Registros de salida Dispositivo Servidor Modbus FiguFigura 5.7 Modelo de los datos Modbus con un solo bloque Cliente Modbus El cliente Modbus permite a la aplicación del usuario tener control del intercambio de la información con un dispositivo remoto. El cliente Modbus construye una petición Modbus de los parámetros contenidos en una petición enviada por la aplicación del usuario a la interfase del cliente Modbus. Seminario de Titulación Protocolo de Comunicación Modbus Interfase del cliente Modbus La interfase del cliente Modbus proporciona una interfase habilitando la aplicación del usuario para construir la petición para varios servicios Modbus incluyendo el acceso a objetos de la aplicación Modbus. La interfase del cliente Modbus (API) no es caracterizada en estas especificaciones, aunque un ejemplo se describe en el modelo de implementaron. Servidor Modbus Con la recepción de una petición Modbus este modulo activa una acción local para leer, escribir o realizar alguna otra acción. El procesamiento de estas es realizado de una manera transparente para las aplicaciones del programador. El servidor principal de Modbus es esperar por una petición Modbus en el puerto 502 de TCP, para tratar esta petición y entonces construir una respuesta Modbus dependiendo del contexto del dispositivo. Interfase trasera Modbus La interfase trasera es una interfase del servidor Modbus para la aplicación del usuario en donde los objetos de la aplicación son definidos. Capa de administración TCP Una de las funciones principales de los servicios de mensajes es manejar el establecimiento de la comunicación y el fin de esta conexión y manejar el flujo de datos en conexiones de TCP establecidas. Administrado de conexión. Una comunicación entre el cliente y el servidor Modbus requiere el uso de un modulo de administración de conexión TCP. El cual esta a cargo de manejar globalmente los mensajes en las conexiones TCP. Seminario de Titulación Protocolo de Comunicación Modbus Dos posibilidades son proporcionadas para el administrador de conexión. La aplicación del usuario maneja las conexiones TCP o la administración de conexión esta hecha en su totalidad por el modulo y sin embargo es transparente para la aplicación del usuario. La última solución implica menos flexibilidad. El puerto de escucha 502 esta reservado para las comunicaciones en Modbus. Esto es obligatorio por default escuchar en este puerto. Sin embargo, algunas marcas o aplicaciones podrían requerir que otro puerto este dedicado a Modbus sobre TCP. En este caso cuando la interoperatividad es requerida con productos que no son similares como suele pasar en un cuarto de control. Por esta razón es altamente recomendado que el cliente y el servidor den la posibilidad al usuario de modificar el parámetro del puerto a ser utilizado para Modbus sobre TCP. Es importante notar que aun si otro puerto en el servidor es configurado para servicio de Modbus en ciertas aplicaciones. El puerto 502 tendrá que seguir habilitado para otras aplicaciones que lo requieran. Modulo de control de acceso En algunos contextos críticos, la accesibilidad a los datos internos del dispositivo es no deseable para algunos hosts. Esto es porque se necesita un modo de seguridad es necesario y el proceso de seguridad deberá ser implementado si se requiere. Capa pila TCP/IP La pila TCP/IP puede ser parametrizada para adaptar el control de flujo de datos, el administración de direcciones y el administrador de conexión para diferentes equipos o sistemas. Generalmente la interfase del socket BSD es usada para administrar las conexiones TCP. Seminario de Titulación Protocolo de Comunicación Modbus Administrador de código y control de flujo de datos. Para equilibrar el flujo de los mensajes de entrada y salida entre el cliente Modbus y el servidor, el mecanismo de control de flujo de datos es proporcionado en todas las capas de pilas de mensajes Modbus. El administrador de código y él modulo de control esta basado principalmente sobre el control de flujo interno en TCP sumado con algún control de flujo de datos en la capa de enlace de datos y también en el nivel de la aplicación del usuario. Administrador de conexión TCP Modulo administrador de conexión Descripción general La comunicación Modbus requiere que se establezca una conexión TCP entre un cliente y un servidor. El establecimiento de la conexión puede ser activado directamente por el modulo de aplicación del usuario o automáticamente por el modulo administrador de conexión TCP. En el primer caso una interfase aplicación de interfase programada tendrá que ser proporcionada en el modulo de la aplicación del usuario para administrar completamente la conexión. Esta solución proporciona flexibilidad para el programador de la aplicación pero requiere de una buena experiencia sobre mecanismos TCP/IP. N la segunda opción el administrador de conexión TCP esta completamente oculto para la aplicación del usuario que solo envía y recibe mensajes Modbus. El Seminario de Titulación Protocolo de Comunicación Modbus modulo administrador TCP esta a cargo de establecer una nueva conexión de TCP cuando esto es requerido. La definición del numero de la conexión TCP cliente y servidor no esta en el alcance de este documento. Dependiendo sobre las capacidades el número de la conexión de TCP puede ser diferente. Reglas de implementación: 1) Sin requerimientos explícitos del usuario, esto es recomendado para implementar el administrador automático de conexión 2) esto es recomendado para mantener la conexión TCP abierta con un dispositivo remoto y no abrir y cerrar para cada trasferencia Modbus. Nota: sin embargo el cliente Modbus debe ser capaz de aceptar una petición cerrada del servidor y cerrar la conexión. La conexión puede ser re abierta cuando sea requerido. 3) Esto es recomendado para un cliente Modbus abrir un mínimo de conexiones TCP con un servidor MODBUS (con la misma dirección IP). Una conexión por aplicación puede ser una buena elección. 4) diversas transferencias Modbus pueden ser activadas simultáneamente sobre la misma conexión TCP. Nota: si esto ocurre entonces el identificador de transferencia Modbus deberá ser usado únicamente para identificar las preguntas y respuestas concordantes. 5)En el caso de una comunicación bidireccional entre dos entidades remotas (cada una de ellos es cliente y servidor), es necesario abrir conexiones separadas para el flujo de datos del cliente y para el flujo de datos del servidor. Seminario de Titulación Protocolo de Comunicación Modbus 6) una trama de TCP podrá transportar solo un ADU Modbus. Esto es avisado antes de enviar múltiples peticiones o respuestas de Modbus sobre el mismo PDU TCP. 1. Administración de conexión TCP Él moduló de la aplicación del usuario esta a cargo de manejar todas las conexiones TCP: establecidas activamente o pasivamente, fin de conexión.......Este administrador esta hecho para todas las comunicaciones Modbus entré un servidor y un cliente. La interfase del socket BSD es usada en él modulo de la aplicación del usuario para administrar la conexión TCP. Esta solución ofrece una total flexibilidad pero implica que el programador de la aplicación tenga suficiente conocimiento sobre TCP. Un límite en el número de conexiones cliente servidor tiene que ser configurado tomando los requerimientos y capacidades del dispositivo. 2. administración automática de la conexión TCP El administrador de conexión es totalmente transparente para el modulo de aplicaciones del usuario. El modulo administrador de la conexión puede aceptar un número suficiente de conexiones cliente servidor. Sin embargo un mecanismo debe ponerse en ejecución en el caso de que se excedan el número de conexiones autorizadas. En algunos casos se recomienda cerrar la conexión más antigua que no este en uso. Una conexión con una pareja remota es establecida en el primer paquete recibido de un cliente remoto o de la aplicación del usuario local. Esta conexión será cerrada si una terminación llega de la red o se decide localmente por el dispositivo. En la recepción de una petición de conexión, la opción de control de acceso puede ser usado para prohibir la accesibilidad a dispositivos clientes no autorizados. Seminario de Titulación Protocolo de Comunicación Modbus Él moduló administrador de TCP usa la interfase de pila (usualmente interfase de socket BSD) para comunicarse con la pila TCP/IP. Para mantener la compatibilidad entre los requerimientos del sistema y el servidor, el administrador de TCP mantendrá poleando 2 conexiones. La primer conexión (conexión con prioridad en el poleo) esta hecha con conexiones que nunca están cerradas sobre una iniciativa local. El principio a ser implementado esta asociado a una dirección IP especifica con cada posible conexión de este poleo. El dispositivo con tal dirección IP será marcado. Cualquier conexión nueva solicitada por un dispositivo marcado debe ser aceptada. Y será tomada de la prioridad de conexión. Esto también es necesario para configurar el número máximo de conexiones permitidas para cada dispositivo para evitar que el mismo dispositivo use todas las conexiones posibles. La segunda conexión (conexión sin prioridad en el poleo) contiene conexiones para dispositivos no marcados. Las reglas a tomar para este caso es cerrar las conexiones más viejas cuando una nueva conexión es solicitada por un dispositivo no marcado y cuando no existen más conexiones disponibles. Una configuración puede ser proporcionada opcionalmente para asignar el número de conexiones disponibles en cada poleo. Sin embargo (esto no es obligatorio) los diseñadores pueden fijar el numero de conexiones al momento de diseñar en caso de ser necesario. Descripción del Administrador de conexión El servicio de mensajes Modbus será proporcionado por un socket de escucha en el puerto 502, que permitirá aceptar nuevas y el intercambio de datos con otros dispositivos. Seminario de Titulación Protocolo de Comunicación Modbus Cuando el servicio de mensajes requiere intercambiar datos con un servidor remoto, debe de abrir un nuevo cliente de conexión con un puerto remoto para intercambiar datos con este dispositivo. El puerto local debe de ser mayor que 1024 y diferente para cada cliente de conexión. Si el numero de conexiones cliente – servidor es mayor al numero de conexiones permitidas la conexión más antigua que no este siendo usada será cerrada. El mecanismo de control de acceso puede ser activado para checar si la dirección IP del cliente remoto es autorizada. Si no la nueva conexión será rechazada. Transferencia de datos Modbus Una petición tiene que ser enviada a la conexión TCP correctamente abierta. La dirección IP del dispositivo remoto es usada para encontrar la conexión TCP. En caso de varias conexiones TCP abiertas con el mismo dispositivo. Se elegirá una conexión para que el mensaje de Modbus sea enviado. Diferentes criterios de elección son usados como son la conexión más antigua, la primera. La conexión permanecerá abierta durante toda la comunicación Modbus. El cliente puede establecer varias transferencias Modbus con un servidor sin que la transferencia anterior finalice. Terminación de comunicación Cuando las comunicaciones Modbus son terminadas entre un cliente y servidor el cliente debe iniciar la terminación de comunicación. Seminario de Titulación Protocolo de Comunicación Modbus Impacto de los Modos de operación Algunos modos de operación (paro de comunicación entre dos extremos operacionales, deshabilitacion y reinicio de una de los extremos,…..) puede tener impactos sobre las comunicaciones TCP. Una conexión puede ser considerada fallida o abortada por uno de los extremos sin conocimiento del otro lado. Se dice que la conexión es “medio-abierta”. Modulo de control de acceso El objetivo de este modulo es checar cada conexión nueva y usando una lista de direcciones IP remotas autorizadas el modulo puede autorizar o prohibir una conexión de un cliente remoto. En contextos típicos el programador de la aplicación necesita elegir el modo de control de acceso para dar seguridad a la red. En tal caso se necesita autorizar/prohibir acceso a cada dirección IP remota. El usuario necesita proporcionar una lista de direcciones IP y especificar para cada dirección IP si tiene autorización o no. Por default, en modo de seguridad, la dirección IP no configurada por el usuario será denegada. Sin embargo con el modo de control de acceso una conexión proveniente de una dirección IP desconocida es cerrada. Uso de la pila TCP/IP Una pila de TCP/IP proporciona una interfase para administrar conexiones, para enviar y recibir datos, y también para hacer algunas parametrizaciones para adaptar el comportamiento de la pila para el dispositivo. La interfase de pila generalmente esta basada en la interfase BSD (Berkeley Software Distribution). Seminario de Titulación Protocolo de Comunicación Modbus Uso de la interfase de socket BSD Un socket es un punto final de comunicación. Es el bloque básico en la construcción de una comunicación. Una comunicación Modbus es realizada al enviar y recibir datos a través de sockets. La librería TCP/IP proporciona solo sockets stream usando TCP y proporciona una conexión basado en el servicio de comunicación. Capa de aplicación de comunicación Diseño del cliente Modbus La definición del protocolo Modbus TCP/IP permite un diseño simple de un cliente. El proceso básico de transferencia de información se describe a continuación. Establecer una conexión TCP con un puerto 502 en el servidor deseado usando una función de conexión. Preparar una petición Modbus como ya se describió antes. Poner la petición Modbus incluyendo los 6 bytes del prefijo Modbus TCP/IP en un buffer listo para ser enviados. Esperar por una respuesta que aparecerá por la misma conexión TCP, opcionalmente se puede incluir un tiempo de espera en este punto, si se desea tener algún aviso de problemas de comunicación tan rápido como TCP normalmente reporta. Leer con alguna función los 6 primeros bytes de la respuesta, que indicara la longitud actual del mensaje de respuesta. Seminario de Titulación Protocolo de Comunicación Modbus Usar la misma función para leer el resto de los bytes. Si no se va a tener comunicaciones para objetivos similares al que se realizo, cerrar la conexión TCP para que el servidor tenga disponibilidad para otros clientes. En los eventos donde ser incluye un tiempo de espera para una respuesta se emitirá un aviso de cierre unilateralmente, abrirá una nueva conexión, y reenviara la pregunta. Esta técnica permite al cliente el control de tiempos de respuesta que es superior al proporcionado por TCP. Esto permite también alternar estrategias de fallback, como es enviar la petición a otra IP alterna, usando una red de comunicación totalmente independiente, en caso de una falla de la infraestructura de la red. Diseño del servidor Un servidor de Modbus TCP debe ser diseñado siempre para soportar la concurrencia de múltiples clientes, aun cuando en su uso funcional aparente que solo requiere un cliente. Esto permite al cliente cerrar y reabrir las conexiones en secuencias rápidas para responder rápidamente en una situación de respuestas no entregadas. Si una pila de TCP convencional es usada se pueden ahorrar significantes recursos de memoria reduciendo el tamaño de los buffers de transmisión y recepción. Un servidor normal de Unix usualmente aloja 8K bytes o más como un buffer de recibo por conexión para alentar la transferencia en ráfagas como Por ejemplo un servidor de archivos. Como el espacio del buffer no tiene un valor en Modbus TCP, desde el máximo tamaño de una pregunta o respuesta es menor a 300 bytes. Es posible a menudo cambiar el espacio de almacenamiento por recursos adicionales de conexión. Seminario de Titulación Protocolo de Comunicación Modbus Los modelos de multi-hilos o simple-hilo pueden ser usados para manejar las conexiones múltiples. Servidor Multi-hilos Sistemas operativos o lenguajes que alientan el uso de múltiples hilos como es java usan la estrategia de multi-hilos descrita aquí: Usar una función de escucha para detectar conexiones en el puerto 502. Cuando es recibida una petición de conexión, se usa una función de aceptación y después se genera un hilo para manejar la conexión. Dentro del hilo se realiza lo siguiente en un loop infinito. Emitir una pregunta de los 6 bytes de la cabecera de Modbus TCP/IP. No poner una interrupción aquí, pero en cambio estará esperando hasta que una pregunta venga o la conexión sea cerrada. Ambas situaciones invocaran al hilo automáticamente. Analizar el encabezado. Si este parece dañado, por ejemplo que el campo de protocolo no son ceros o la longitud del mensaje es mayor que 256, entonces unilateralmente se cerrara la conexión. Esta es la respuesta correcta de un servidor para una situación que implique a la codificación de TCP. Usar una función de recibo para los siguientes bytes del mensaje, cuya longitud ya conocemos. Podemos notar que al usar una función de recepción con una longitud conocida tolerara clientes que insisten en encimar peticiones. Seminario de Titulación Protocolo de Comunicación Modbus El siguiente paso es procesar el mensaje Modbus. Si es necesario suspender el hilo actual hasta que la respuesta adecuada sea generada, en el futuro se tendrá un mensaje de Modbus valido o un mensaje de excepción para responder. Generar el prefijo Modbus para la respuesta, como un solo buffer para ser transmitido en la conexión, usando una función de envió. Regresar y esperar por los siguientes 6 bytes de una pregunta. En el futuro, cuando el cliente seleccione cerrar la conexión, la función de recibo para los 6 bytes del prefijo fallara. Una orden de cierre de comunicación resultara en que la función de recibo tenga una cantidad de 0 bytes. En este caso se cierra la conexión y se cancela el hilo. Servidor de un solo hilo Algunos sistemas integrados con sistemas viejos como es UNIX o MS-DOS alientan el manejo de múltiples conexiones usando la llamada de “select” de la interfase de sockets. En semejante sistema, en lugar de ocuparse del proceso de demandas coexistentes individuales en su propio hilo, usted puede ocuparse de las demandas como una máquina de estados múltiples dentro de un manejador común. Los idiomas como C++ hacen la estructura de software como la siguiente. La estructura ahora debe ser como sigue: Inicialización de la maquina multi estados fijando su estado en inactivo. Usar una función de escucha para las conexiones entrantes en el puerto 502. Ahora iniciar un loop infinito checando el puerto y la maquina de estados como sigue: Seminario de Titulación Protocolo de Comunicación Modbus En el puerto de escucha, si se recibe una nueva petición de conexión, se acepta y ocasiona que la maquina de estados cambie su estado de “inactivo” a “petición nueva” para procesar la conexión entrante. Para cada estado de la maquina de estados tenemos: Si es estado es “nueva petición” o Use una función para ver cuando llega la petición. Normalmente se fija la interrupcion en cero, lo que indica que usted no desea suspender el proceso debido a la inactividad de esta conexión. o Si la funcion indica que existe un paquete use un a funcion para leer el encabezado como en el caso de multi hilos. Si el encabezado esta dañado cerrar la conexión y poner el estado de la maquina en “inactivo”. o Si la lectura ocurre y se indica que hay entradas disponibles se lee el resto de la petición. o Si la petición esta completa cambiar el estado de la maquina por “esperar respuesta” o Si se detecta que la petición es muy larga se cierra la conexión y el estado de la maquina se regresa a “inactivo”. Si el estado es “esperar respuesta” o Ver si la información de respuesta esta disponible, de ser así crear el paquete de respuesta, y enviarlo usando enviar, exactamente como en el caso de multi hilos, fijando el estado en “nueva petición”. Seminario de Titulación Protocolo de Comunicación Modbus Desempeño requerido y esperado No existe una especificación para el tiempo de respuesta en Modbus o Modbus TCP/IP. Esto es debido a que se espera que Modbus TCP sea usado las más variadas situaciones de comunicación. Además, la familia de Modbus esta diseñada para alentar la conversión automática entre redes mediante puentes. Tales como los dispositivos Schneider “puente Ethernet a Modbus Plus“, y varios dispositivos que convierten de Modbus TCP a Modbus serial. El uso de tales dispositivos implica que el desempeño de dispositivos Modbus existentes es consistente con el uso de Modbus TCP. En general dispositivos como PLC´s que exhiben un comportamiento de escaneo responderá a una pregunta entrante en un tiempo de escaneo, que típicamente varia entre 20 mili segundos y 200 msec. Desde la perspectiva de un cliente, el tiempo deberá ser extendido por los retardos de transmisión a través de la red. Para determinar un tiempo se respuesta razonable. Tales retardos de transporte pueden ser de mili segundos para redes Ethernet o cientos de segundos para una red de área amplia. A su vez, cualquiera tiempo de 'interrupción' usado en el cliente comenzar un reintento de la aplicación debe ser más grande que el máximo esperado ' tiempo de contestación razonable'. Si esto no es seguido, hay un potencial para la congestión excesiva al dispositivo designado o en la red que puede causar los errores. Ésta es una característica que siempre debe evitarse. Así en la práctica, siempre es probable que las interrupciones del cliente usadas en aplicaciones de alto desempeño son siempre dependientes a la topología de la red y la actuación esperada del cliente. Seminario de Titulación Protocolo de Comunicación Modbus Una interrupción de digamos 30 msec podrían ser razonables cuando examinando 10 dispositivos de entrada/salida para una red Ethernet local y cada dispositivo normalmente responderían en 1 msec. Por otro lado, un valor de interrupción de 1 segundo podría ser más apropiado al dirigir PLC lento a través de una entrada serial dónde la secuencia de escaneo normal es de 300 msec. Los clientes son animados a cerrar y restablecen las conexiones de MODBUS/TCP que son usadas sólo para acceso de datos (no programación del PLC) y donde el tiempo esperado antes del siguiente uso es significante, por ejemplo más largo que un segundo. Si los clientes siguen este principio, permite un servidor con recursos limitados de conexión reparar un número más grande de clientes potenciales, así como facilitar las estrategias de recuperación de error como la selección de una IP objetivo diferente. Debe recordarse que la comunicación extra y carga de CPU causaron por cerrar y abrir una conexión es comparable a eso causado por una simple transferencia de Modbus. Seminario de Titulación Protocolo de Comunicación Modbus CAPITULO 6 APLICACIÓN COMUNICACIÓN DE LOS COMPUTADORES DE FLUJO SOLARTRON MONITOREO DE DENSITOMETROS El propósito de este capitulo es mostrar algunos ejemplos prácticos del uso de este protocolo, donde quedara claro las ventajas y alcance de las aplicaciones, no es el objetivo dar a detalle los pormenores del desarrollo ya que esto es información de las empresas desarrolladoras. Seminario de Titulación Protocolo de Comunicación Modbus 6.1 COMUNICACIÓN SOLARTRON Uno de los equipos para la medición en transferencia de custodia de productos derivados del petróleo son las computadoras de flujo, los cuales son dispositivos que toman las señales de campo, las cuantifican y las utilizan para hacer los cálculos necesarios en la totalización de un volumen. El objetivo inicial de estos equipos era simplemente la totalización del producto, pero con el paso del tiempo y buscando un grado de automatización mayor se requirió que estos equipos controlaran parte del proceso, dentro de estos requerimientos se encuentra: Control de válvulas Totalización por lotes Totalización por estación Control con programas de calibración de sus medidores Control del proceso por presión y/o por flujo Los equipos fueron evolucionando hasta poder manejar los puntos anteriores, pero no existía una interfase hombre maquina, la configuración y operación del equipo se realizaba frente a panel, siendo un trabajo cansado y que requeria amplio conocimiento del equipo. Inicio de computadoras con Modbus Así pues las principales marcas en el desarrollo de los computadores de flujo tiene la necesidad de proporcionar una interfase hombre maquina, y el protocolo Modbus es elegido por OMNI Flor Computer, al ser OMNI el computador más vendido a nivel mundial el resto de los fabricantes tienen que diseñar computadores de flujo con Modbus en sus puertos, para poder ofrecer una interfase hombre maquina a través de una PC. Seminario de Titulación Protocolo de Comunicación Modbus OMNI baja su poder en el mercado mundial y muchas marcas empiezan a colocar mejor sus equipos en la industria del petróleo, y nos encontramos con equipos nuevos como es AcuLoad, y la familia de computadores 795X de Solartron Mobrey, estos últimos con un desarrollo tremendo de tecnología, y sobre todo desarrollo en el aspecto de comunicaciones, teniendo puertos seriales con el protocolo Modbus, esto podrá sonar trivial ya que OMNI contaba también con protocolo Modbus, pero Solartron implemento cosas realmente innovadoras como es la total configuración del Modbus del computador, ya que permite elegir el modo de transmisión entre ASCII o RTU, así como la velocidad de esta transmisión. Características de Modbus para la familia 795X Los computadores de Solartron además de lo ya mencionado presentaron características nunca vistas por otros equipos como fue el High Speed List (HSLst) que son las listas de acceso rápido, teniendo 2 listas por equipo y con la capacidad de almacenar 150 variables cada lista divididos en bloque de 50 variables. Es decir en total se tiene la posibilidad de almacenar hasta 300 variables en sus 6 bloques que van de la A a la F, esto tiene el objetivo de que el computador de flujo al ser un esclavo en una red Modbus responda con mayor rapidez a las peticiones que se le realicen ya que no requiere de una petición por variable, es decir si deseas conocer la presión o temperatura no es necesario realizar una petición por variable, simplemente se configuran estas variables en las listas y se pregunta por la lista que se desee. El acceso a estas listas se logra a partir de la dirección base de esclavo Modbus que se le configure al equipo, ya que estas listas se comportan como esclavos virtuales, es decir que se simula que cada una de estas listas es un equipo conectado a la red Modbus. Seminario de Titulación Protocolo de Comunicación Modbus El acceso esta dado de la siguiente forma: HSLst 1 = dirección base +1 HSLst 2 = dirección base +2 De este modo es posible realizar una configuración sin problemas y lograr integraciones con relativa facilidad. Pero esta característica es solo una parte del desarrollo de Solartron Mobrey, el equipo que funciona como esclavo puede ser también un maestro, pero se debe de tener la precaución de no intentar esto por el mismo puerto ya que eso no es posible y causaría una colisión de datos, lo que provoca que los equipos se reinicien, con lo que perderán su totalización y si el equipo esta controlando válvulas puede causar problemas operativos, es por ello que se cuenta con 3 puertos seriales y con la posibilidad de tener un puerto Ethernet por medio del cual se puede tener acceso vía TCP/IP. El objetivo de que el equipo funcione como un maestro es pensar en un sistema redundante. Es decir que las señales de campo le llegan a dos equipos y si el equipo como “Duty” sufre algún daño la computadora “Stand by” toma su lugar en el control del proceso. A sistema de Supervisión Figura 6.1 computadoras en Duty – Stand by Seminario de Titulación Protocolo de Comunicación Modbus Ambos tienen las señales de campo para medición, pero solo una de ellas tiene el control del proceso así que cuando la computadora Duty se apaga, es necesario que la computadora Stand by tome el control, pero no puede tomar el control si no tiene los valores que estaban siendo aplicados, como pueden ser el porcentaje de apertura de una válvula reguladora, tiempo de inicio de lote, etc. Esta es la razón por la que el computador Duty actuara como maestro y fijara estos valores al computador Stand by, cuando ocurra el Hand over la computadora se intercambiaran las posiciones la computadora 1 será esclavo y la computadora 2 maestro. Teniendo esto en consideración, Solartron desarrollo en base a Modbus su configurador que esta en dos versiones que son PC Config y FC Config; ambos con el propósito de configurar el equipo. Figura 6.2 Pantalla FC config Seminario de Titulación Protocolo de Comunicación Modbus Figura 6.3 Pantalla PC Config Con toda la información de direcciones es posible crear un sistema supervisorio que proporciona una interfase amigable para el operador y que además permite el acceso al computador solo para su operación, lo que ayuda a que se desconfigure por error. La siguiente pantalla muestra el desarrollo que se realizo para la terminal de almacenamiento y distribución Azcapotzalco en la ciudad de México, siendo uno de los proyectos más notables y donde se explota las capacidades del equipo Solartron en un 90%, así como el hecho de que se integraron los PLC’s de la empresa Yokogawa. Seminario de Titulación Protocolo de Comunicación Modbus Figura 6.4 Sistema Azcapotzalco Por ultimo mostramos una pantalla del sistema supervisorio que se desarrollo para control de medición, este sistema tiene la intención de llevar el control de lote, así como cuantificación cada 24 hrs. El control del proceso lo realiza el equipo 7955 Solartron pero el operador tiene acceso a través de los sistemas Yokogawa. Seminario de Titulación Protocolo de Comunicación Modbus Figura 6.5 Supervisorio Infohawk Seminario de Titulación Protocolo de Comunicación Modbus 6.2 Monitoreo de Densitometros Otra aplicación se desarrollo para una empresa de refrescos donde utilizando densitometros de la marca Solartron y usando el software Adview desarrollado por Solartron se tienen conectados 5 densitometros cuyo propósito es medir la densidad del jarabe utilizado para la bebida, pero adicionalmente el equipo calcula la concentración en ºBrix aquí se tiene la desventaja de que el software Adview es para configurar el densitometro no para monitoreo, pero al poder configurar la dirección del esclavo es posible cambiar de un densitometro a otro cuando se desee ver otro equipo, la desventaja es que no es posible hacerlo para los 5 equipos a la vez, la densidad el equipo la entrega por una salida de 4 – 20mA al igual que la función especial (en este caso ºBrix), que están conectados a alarmas para cuando el jarabe sale de los parámetros. Figura 6.6 Software Adview para el monitoreo y configuración Seminario de Titulación El CIATEQ esta Protocolo de Comunicación Modbus trabajando en el desarrollo del software para monitoreo/configuración de los 5 densitometros al mismo tiempo, cosa que no se había hecho antes. Con estas dos aplicaciones podemos dar un panorama de la importancia de un protocolo como lo es Modbus y de que las posibilidades de integración son infinitas, gracias a la transparencia. Seminario de Titulación Protocolo de Comunicación Modbus GLOSARIO DE TÉRMINOS CIM Computadoras Integradas DCCS Sistemas de control de computadoras distribuidas OSI Sistema abierto de interconexión MAP Protocolo de automatización de manufactura LLC Control lógico de enlace MAC Control de acceso al medio MMS Especificación del mensaje de manufactura DDC Control digital directo PLC Controlador lógico programable NC Controlador numérico FMS Sistema flexible de manufactura Multi Drop Conexión en cascada en un par de hilos EMI Interferencia electromagnética Actuador Dispositivo que controla a un elemento de campo, Racks Panel para montar dispositivos RFI Interferencia de radiofrecuencia RS-232 Transmisión serial punto a punto RS-485 Transmisión serial con opción multi drop Broadcast Mandar señal a todo los elementos ASCII Código estándar americano para el intercambio de información RTU Unidad terminal remota LRC Comprobación longitudinal redundante CRC Comprobación de renuncia cíclica LSB Bit menos significativo MSB Bit más significativo HDLC Control de enlace de datos en el nivel alto. FIFO Primero en entrar primero en salir NAK Conocimiento negativo Seminario de Titulación Protocolo de Comunicación Modbus ADU Unidad de aplicación de datos IP Protocolo de Internet MBAP Protocolo de aplicación Modbus PDU Unidad de dato del protocolo TCP Protocolo del control de transporte BSD Distribución de software Berkeley BIBLIOGRAFÍA “Modbus Protocol Reference Guide”. (PI-MBUS-300 Rev. B). Modicon Inc.. “TCP/IP: Principios Básicos, Protocolos y Arquitectura” Comer, Douglas .E.;, Vol. I, 3ª Edición Ed. Prentice-Hall; 1996. “Transmisión de Datos y Redes de Computadores” García-Teodoro, P.; Díaz-Verdejo, J.E.; López-soler, J.M. Ed. Prentice-Hall; 2003. “Redes locales en la industria “ Justo Carracedo Gallardo. Ed. Marcombo, 1988. - 119 p “Ingeniería de la automatización industrial” Piedrafita Moreno, Ramón 2ª Edición Ed. ra-ma "Instrumentación Industrial". CREUS A. 5ª Edición. Ed. Marcombo. (1993). 7955 Flow Computer Operating Manual Solartron Mobrey HB552540 Seminario de Titulación APÉNDICE A RESPUESTAS DE EXCEPCIÓN RESPUESTAS DE EXCEPCIÓN CÓDIGOS DE EXCEPCIÓN Protocolo de Comunicación Modbus Seminario de Titulación Protocolo de Comunicación Modbus A.1 RESPUESTAS DE EXCEPCIÓN Excepto para mensajes tipo difusión, cuando un dispositivo maestro envía una petición a un dispositivo esclavo, espera una respuesta normal. Uno de cuatro posibles eventos pueden ocurrir desde la petición del maestro: Si el dispositivo esclavo recibe la petición sin error de comunicación y puede manejar la petición normalmente, devuelve una respuesta normal. Si el esclavo no recibe la petición debido a un error de comunicación, no hay devolución de respuesta. El programa del maestro eventualmente procesará una condición de tiempo excedido - timeout -, para la petición. Si el esclavo recibe la petición, pero detecta un error de comunicación (paridad, LRC, o CRC), no hay devolución de respuesta. El programa del maestro eventualmente procesará una condición de tiempo excedido – timeout -, para la petición. Si el esclavo recibe la petición sin error de comunicación, pero no puede manejarla (por ejemplo, si la solicitud es leer un una bobina o registro inexistente), el esclavo devolverá una respuesta de excepción informando al maestro de la naturaleza del error. El mensaje de respuesta de excepción tiene dos campos que lo diferencian de una respuesta normal: Campo de Código de Función: En una respuesta normal el esclavo replica el código de función de la petición original en el campo del código de función de la respuesta. Todos los códigos de función tienen el bit más significativo (MSB) a 0 Seminario de Titulación Protocolo de Comunicación Modbus (sus valores están por debajo de 80 hexadecimal). En una respuesta de excepción, el esclavo establece el MSB del código de función a 1.Esto hace que el código de función en una respuesta de excepción resulte 80 hexadecimal mas alto de lo que sería para una respuesta normal. Con el MSB del código de función activado, el programa de aplicación del maestro puede reconocer la respuesta de excepción y puede examinar en el campo de datos el código de excepción. Campo de Datos: En una respuesta normal, el esclavo puede devolver datos o estadísticas en el campo de datos (cualquier información que fuera solicitada en la petición). En una respuesta de excepción, el esclavo devuelve un código excepción en el campo de datos. Esto define la condición del esclavo que causó la excepción. La figura A.1 muestra un ejemplo de una petición del maestro y una respuesta de excepción de un esclavo. Los campos del ejemplo se muestran en hexadecimal. Seminario de Titulación Protocolo de Comunicación Modbus Figura A.1 Petición del maestro y respuesta de excepción del esclavo. En este ejemplo, el maestro direcciona una petición al dispositivo esclavo 10 (0A hex).El código de función (01) es corresponde a una operación Leer el Estado de una Bobina. Se devuelve el estado de la bobina en la dirección 1245 (04 A1 hex). Observe que sólo se lee una bobina, como se ha especificado en el campo del número de bobinas (0001). Si la dirección de la bobina es inexistente en el dispositivo esclavo, el esclavo devolverá la respuesta de excepción con el código de excepción mostrado (02). Eso especifica un dato de dirección ilegal para el esclavo. Por ejemplo, si el esclavo es un 984-385 con 512 bobinas, podría devolver este código. Seminario de Titulación Protocolo de Comunicación Modbus A.2 CÓDIGOS DE EXCEPCIÓN Código Nombre Significada 01 El código de función recibido en la petición no es una Función Ilegal acción permitida para el esclavo. Si un comando Completar Selección de Programa fue notificado, este código indica que no le precedió función programa. 02 Dato de dirección El dato de dirección recibido en la petición no es una Ilegal 03 Dato dirección permitida para el esclavo de Valor Un valor contenido en el campo de datos de la Ilegal 04 Fallo petición no es un valor admisible para el esclavo. dispositivo Ha ocurrido un error no recuperable mientras el esclavo esclavo estaba intentando ejecutar la acción solicitada. 05 Reconocimiento El esclavo ha aceptado la petición y está procesándola, pero requerirá un tiempo largo para hacerlo. Esta respuesta se devuelve para prevenir que ocurra un error de tiempo excedido en el maestro. El maestro puede notificar a continuación un mensaje Completar Selección de programa para determinar si se ha completado el procesamiento. 06 Dispositivo El esclavo ha aceptado la petición y está esclavo Ocupado procesándola, pero requerirá un tiempo largo para hacerlo. Esta respuesta se devuelve para prevenir que ocurra un error de tiempo excedido en el Seminario de Titulación Protocolo de Comunicación Modbus maestro. El maestro puede notificar a continuación un mensaje Completar Selección de programa para determinar si se ha completado el procesamiento. 07 Reconocimiento El esclavo no puede efectuar la función de programa negativo recibida en la petición. Este código es devuelto por una petición de programación fallida, utilizando código de función 13 ó 14 decimal. El maestro debería pedir al esclavo diagnóstico o información de error. 08 Error de paridad El esclavo ha intentado leer memoria extendida, pero en memoria ha detectado un error de paridad en la memoria.. El maestro puede reintentar la petición, pero el servicio debe ser requerido al dispositivo esclavo. Seminario de Titulación APÉNDICE C GENERACIÓN DEL LRC GENERACIÓN DEL CRC Protocolo de Comunicación Modbus Seminario de Titulación Protocolo de Comunicación Modbus B.1 GENERACIÓN DEL LRC El campo Comprobación de Redundancia Longitudinal (LRC) es un byte, que contiene un valor binario de 8 bits. El valor LRC es calculado por el dispositivo emisor, que añade el LRC al mensaje. El dispositivo receptor recalcula un LRC durante la recepción del mensaje y compara el valor calculado con el valor verdadero recibido en el campo LRC. Si los dos valores no son iguales, resulta un error. El LRC se calcula sumando entre sí los sucesivos bytes del mensaje, descartando cualquier acarreo y luego complementando a dos el valor resultante. El LRC es un campo de 8 bits, por lo tanto cada nueva suma de un carácter que resultara ser mayor de 255 simplemente ‘hace pasar el valor del campo por cero. Dado que no hay un noveno bit, el acarreo se descarta automáticamente. Un procedimiento para generar un LRC es: 1.- Sumar todos los bytes del mensaje, excluyendo los ‘dos puntos’ de comienzo y el par CRLF del final. Sumarlos en un campo de 8 bits, así serán descartados los acarreos. 2.- Restar el resultado del paso anterior de FF hex (todos los bit a 1), para producir el complemento a uno. 3.- Sumar 1 al resultado del paso anterior para producir el complemento a 2. Situando el LRC en el Mensaje Cuando los 8 bits del LRC (2 caracteres ASCII) son transmitidos en el mensaje, el carácter de orden alto será transmitido en primer lugar, seguido por el carácter de orden bajo. Por ejemplo, si el valor del LRC es 61 hex (0110 0001): Seminario de Titulación Protocolo de Comunicación Modbus Figura B.1 secuencia de caracteres LRC Ejemplo Se muestra mas abajo un ejemplo de función en lenguaje C que genera el LRC. La función toma dos argumentos: Unsigned char *auchMsg ; Un puntero al primer byte después del ‘dos puntos’ en el buffer de mensaje que contiene los datos binarios sobre los que efectuar el LRC. Unsigned short usDataLen ; La cantidad de bytes en el buffer de mensaje sobre los que se haya de realizar el LRC. La función devuelve el LRC como un tipo unsigned char. Función para Generación del LRC static unsigned char LRC (auchMsg, usDataLen) unsigned char *auchMsg ; unsigned short usDataLen; /* apunta a la parte del mensaje a calcularle el LRC */ /*cantidad de bytes a tratar, dentro del mensaje */ { unsigned char uchLRC = 0; while (usDataLen--) uchLRC += *auchMsg++; return ( (unsigned char) (- ((char) uchLRC))); } /* LRC inicializado */ /* a lo largo de todo el buffer de mensaje */ /* suma un byte del buffer, sin acarreo */ /* devuelve el complemento a dos */ Seminario de Titulación Protocolo de Comunicación Modbus B.2 GENERACIÓN DEL CRC El campo de Comprobación de Redundancia Cíclica es de dos bytes, conteniendo un valor binario de 16 bits. El valor del CRC es calculado por el dispositivo emisor, el cual añade el CRC al mensaje. El dispositivo receptor recalcula un CRC durante la recepción del mensaje y compara el valor calculado con el valor actual recibido en el campo de CRC. Si los dos valores no son iguales, resulta un error. Para calcular el valor CRC Modbus se precarga un registro de 16 bits, con todos ellos a 1. Luego comienza un proceso que toma los sucesivos bytes del mensaje y los opera con el contenido del registro y actualiza éste con el resultado obtenido. Sólo los 8 bits de dato de cada carácter son utilizados para generar el CRC. Los bits de arranque y paro y el bit de paridad , no afectan al CRC. Durante la generación del CRC, se efectúa una operación booleana OR eclusivo (XOR) a cada carácter de 8 bits con el contenido del registro. Entonces al resultado se le aplica un desplazamiento de bit en la dirección de bit menos significativo (LSB), rellenando la posición del bit más significativo (MSB) con un cero. El LSB es extraído y examinado. Si el LSB extraído fuese un 1, se realiza un XOR entre el registro y un valor fijo preestablecido. Si el LSB fuese un 0, no se efectúa el XOR. Este proceso es repetido hasta haber cumplido 8 desplazamientos. Después del último desplazamiento (el octavo), el próximo byte es operado XOR con el valor actual del registro y el proceso se repite con ocho desplazamientos más, como se ha descrito mas arriba y así con todos los bytes del mensaje.. El contenido final del registro, después que todos los bytes del mensaje han sido procesados, es el valor del CRC. Un procedimiento para generar un CRC es: Seminario de Titulación Protocolo de Comunicación Modbus 1. Cargar un registro de 16 bits que denominaremos registro CRC, con FFFF (todos 1). 2. XOR del primer byte - 8 bits - del mensaje con el byte de orden bajo del registro CRC de 16 bits, colocando el resultado en el registro CRC. 3. Desplazar el registro CRC un bit a la derecha (hacia el LSB - bit menos significativo -, rellenando con un cero el MSB – bit mas significativo -. Extraer y examinar el LSB. 4. (Si el LSB era 0): Repetir paso 3 (otro desplazamiento). (Si el LSB era 1): Hacer XOR entre el registro CRC y el valor polinómico A001 hex (1010 0000 0000 0001). 5. Repetir los pasos 3 y 4 hasta que se hayan efectuado 8 desplazamientos. Una vez hecho esto, se habrá procesado un byte completo – 8 bits -. 6. Repetir los pasos 2 al 5 para el próximo byte – 8 bits – del mensaje. Continuar haciendo ésto hasta que todos los bytes hayan sido procesados. 7. El contenido final del registro CRC es el valor CRC. 8. Cuando el CRC es situado en el mensaje, sus bytes de orden alto y bajo han de ser permutados como se describe mas abajo. Situando el CRC en el Mensaje Cuando el CRC de 16 bits (2 bytes) es transmitido en el mensaje, el byte de orden bajo se transmitirá primero, seguido por el byte de orden alto. Seminario de Titulación Protocolo de Comunicación Modbus Por ejemplo, si el valor del CRC es 1241 hex (0001 0010 0100 0001): Figura B.2 Secuencia byte CRC Ejemplo Un ejemplo de una función C que genera CRC se muestra en las siguientes páginas. Todos los valores CRC posibles son cargados previamente en dos matrices fila, que son simplemente indexadas a medida que la función va procesando los bytes del buffer de mensaje. Una de las matrices contiene los 256 valores posibles de CRC del byte de orden alto del campo CRC de 16 bits y la otra matriz contiene todos los valores de byte de orden bajo. Indexar el CRC de esta manera proporciona una ejecución más rápida, que la que pudiera alcanzarse calculando un nuevo valor CRC con cada nuevo carácter del buffer del mensaje. Nota Esta función realiza internamente el intercambio de los bytes alto/bajo del CRC. Los bytes han sido ya permutados en el valor CRC que es devuelto desde la función. Por lo tanto el valor CRC devuelto desde la función puede ser colocado directamente en el mensaje para la transmisión. La función toma dos argumentos: Unsigned char *puchMsg ; Un puntero al primer byte en el buffer de mensaje que contiene los datos binarios sobre los que efectuar el CRC. Unsigned short usDataLen ; La cantidad de bytes en el buffer de Seminario de Titulación Protocolo de Comunicación Modbus mensaje sobre los que se haya de realizar el CRC. La función devuelve el CRC como un tipo unsigned short. Función para Generación del CRC unsigned short CRC16 (puchMsg, usDataLen) unsigned char *puchMsg ; unsigned short usDataLen; { unsigned char uchCRCHi = 0xFF; unsigned char uchCRCLo = 0xFF; unsigned uIndex; while (usDataLen--) { uIndex = uchCRCHi ^ *puchMsg++ ; uchCRCHi = uchCRCLo ^ auchCRCHi [uIndex] ; uchCRCLo = auchCRCLo [uIndex] ; } return ( uchCRCHi << 8 | uchCRCLo); } /* apunta al mensaje a calcularle el CRC */ /*cantidad de bytes a tratar, dentro del mensaje */ /* byte alto del CRC inicializado */ /* byte bajo del CRC inicializado */ /* indexará a la tabla de valores CRC */ /* a lo largo de todo el buffer de mensaje */ / *calcula el CRC */