Redes Industriales Mod Bus

Seminario de Titulación Protocolo de Comunicación Modbus

REDES INDUSTRIALES

PROTOCOLO MODBUS

Mayo 2004


ÍNDICE

CAPITULO 1

Introducción a las Redes Industriales 1

1.1. Automatización Industrial y Redes de Comunicación 21.2. Vista General de la Automatización Industrial y Redes de

Comunicación 51.3. Niveles Jerárquicos en Sistemas de Automatización

Industrial 8-Nivel de campo 8-Nivel de célula.. 10-Nivel de área.. 11-Nivel de planta… 11-Medios de transmisión… 11-Topología de red… 13

1.4. Consideraciones de diseño..14-Costo… 15-Servicio o función de la red… 16-Tolerancia con respecto al medio ambiente.. 17-Medios físicos.. 17-Expansión .. 18-Mantenimiento.. 18-Requisitos de comunicación para los sistemas de automatización… 18

CAPITULO 2

Protocolo Modbus.. 21

2.1. Introducción al Protocolo de Comunicación Modbus… 22-Intercambio de información en una red Modbus.. 24-Intercambio de información sobre redes diferentes a Modbus.. 25-Pregunta.. 26-Respuesta.. 27

2.2. Los Dos Modos de Transmisión Serial… 27-Modo ASCII.. 28-Modo RTU.. 28

2.3. Tramas de Mensaje Modbus.. 30-Trama ASCII.. 30-Trama RTU..31-Como es manipulado el campo de dirección… 32


-Como es manipulado el campo de función… 32-Contenido del campo de datos.. 34-Contenido del campo de comprobación de error.. 35-Como son trasmitidos los caracteres en serie.. 36

2.4. Métodos de Comprobación de Error.. 37-Control de Paridad… 37-Comprobación LRC.. 39-Comprobación CRC.. 39

CAPITULO 3

Datos y Funciones de Control… 42

3.1. Formato de las Funciones Modbus… 433.2. Código de Funciones Soportadas por Los Controladores.. 47

-01 Lectura del estatus de una bobina.. 48-02 Lectura del estatus de una entrada.. 50-03 Lectura de registros sostenidos.. 52-04 Lectura de registro de entradas.. 54-05 Forzar bobinas simples……… 56-06 Predeterminar registros simples……. 58-07 Lectura de estatus de excepción……. 59-11 Sacar un contador de eventos de comunicaciones…… 61-12 Traer el registro de eventos de comunicaciones………. 63-15 Forzar varias bobinas….... 68-16 Predefinir varios registros…… 70-17 Reportar el identificador del esclavo…….. 72-20 Lectura de referencias generales………… 81-21 Escritura de referencias generales………. 84-22 Escritura de registros 4X con una mascara……. 88-23 Lectura/escritura de registros 4X………………. 90-24 Lectura de una cola FIFO……………. 92

CAPITULO 4

Subfunciones de Diagnostico………………… 95

4.1 Función 08 Diagnósticos…………………….. 96-Efectos del diagnostico en el esclavo……. 96

4.2 Subfuncion de Diagnostico…………………….. 99-00 Regreso de datos de la pregunta……….. 99-01 Opción de reinicio de la comunicación…. 99-02 Regreso del registro de diagnostico 100-03 Cambio del delimitador de entrada ASCII 101-04 Forzar el modo de solo escucha 101-10 Borrar contadores y registro de diagnostico 102


-11 Regreso del contador de mensajes del bus 102-12 Regreso del contador de errores de comunicación del bus.. 102-13 Regreso del contador de errores de excepción en el bus…. 103

-14 Regreso del contador de mensajes del esclavo 103-15 Regreso del contador de no respuestas del esclavo 103-16 Regreso del contador NAK del esclavo 104-17 Regreso del contador de ocupado del esclavo .104-18 Regreso del contador de caracteres desbordados en el bus… 105-19 Regreso del contador de IOP desbordados (884)…… 105-20 Borrar banderas y contadores de desbordamiento….. 106

CAPITULO 5

Modbus TCP/IP……… 107

5.1 Modelo Cliente Servidor……… 1085.2 Descripción del Protocolo……….. 109

-Arquitectura general de comunicación….. 109-La unidad de datos de la aplicación sobre Modbus TCP/IP …..110-Descripción del encabezado MBAP……… 111

5.3 Descripción Funcional………… 113-Agente de conexión TCP 118-Uso de la pila TCP/IP 123-Capa de aplicación de comunicación 124


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.


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.


1.1AUTOMATIZACIÓ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

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


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.


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


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


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


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


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


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


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,


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.


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


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


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.


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.


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.


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.


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.


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:

Figura 1.3 Esquema del diseño de una red industrial

Análisis

Diseño

Implementación

Estudio de fiabilidad

Mantenimiento y Actualización


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.


2.1Introducció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


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.


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 maestro-

esclavo, en donde solo un dispositivo denominado (el maestro) puede iniciar

Host Procesador

984-985(Modbus Plus) y

S980 (MAP)

ProgramadorP230

AT/MC-984 y Host/MMI

984 A/B y S985

BM85

ProgramadorP230

MAP

Modbus Plus

Modbus

Modbus Modbus

Cuatro dispositivos Modbus o 4 redes.


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.


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.

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

Mensaje de respuesta del maestro

Mensaje de pregunta del maestro

Dirección del dispositivo

Código de función

8 bitsBytes de datos

Chequeo de error

Dirección del dispositivo

Código de función

8 bitsBytes de datos

Chequeo de error


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.


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.


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.)


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.


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.


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.


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.


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.


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.


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

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.

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).


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


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.


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.


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.


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

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

Figura 3.1 pregunta típica

Figura 3.2 Respuesta típica


Campos contenidos en los mensajes sobre Modbus Plus

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.


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 Nombre 384 484 584 884 M84 98401 Leer Estados de Bobinas Y Y Y Y Y Y02 Leer Estados de Entradas Y Y Y Y Y Y03 Leer Registros sostenidos Y Y Y Y Y Y04 Leer Registros de Entradas Y Y Y Y Y Y05 Forzar una única Bobina Y Y Y Y Y Y06 Preestablecer un único Registro Y Y Y Y Y Y07 Leer Status de Excepción Y Y Y Y Y Y08 Diagnosticos (ver Capítulo 3)


09 Programar 484 N Y N N N N10 Selección 484 N Y N N N N11 Buscar Contador de Eventos de

ComunicaciónY N Y N N Y

12 Buscar Anotac de Eventos de Comunic Y N Y N N Y13 Programar Controlador Y N Y N N Y14 Selección Controlador Y N Y N N Y15 Forzar Múltiples Bobinas Y Y Y Y Y Y16 Preestablecer Múltiples Registros Y Y Y Y Y Y17 Reportar Identificación de Esclavo Y Y Y Y Y Y18 Programar 884/M84 N N N Y Y N19 Resetear Enlace de Comunicaciones N N N Y Y N20 Leer Referencia General N N Y N N Y21 Escribir Referencia General N N Y N N Y22 Escribir con máscara en Registros 4X N N N N N (1)23 Leer/Escribir Registros 4X N N N N N (1)24 Leer Cola FIFO N N N N N (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:


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


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-ON-

OFF-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.


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 10197-

10218 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.


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: ON-

OFF-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.


controladores.


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.


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.


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.


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.


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.


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.


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.

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.


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.


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.


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”


“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

258-264

Estatus de la batería.

Definido por el usuario.

884 761

762

763

764-768

Estatus de la batería.

Estatus de la protección a la memoria.

RIO estatus de salud.

Definidas por el usuario

Aquí se muestra un ejemplo de una petición para el estatus de excepción en el


Figura 3.16 pregunta para leer estatus de excepciones


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.


En este ejemplo, el dato de las bobinas es 6D que en binario corresponde a

01101101. De izquierda a derecha las bobinas son: apagado- encendido-

encendido- 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.


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.


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.


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.


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.


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.


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.


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 Contenido0 No usado1 Error de comunicación2 No usado3 No usado4 Carácter desbordado5 Actualmente en modo de solo escuchar.6 Broadcast recibido7 1

Eventos enviados por el esclavo 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 Contenido0 Excepción de lectura enviado (código de excepción 1-3)1 Excepción de interrupción de esclavo (código de excepción 4)2 Excepción de esclavo ocupado (código de excepción 5-6)3 Excepción de programa NAK esclavo (código de excepción 4)4 A ocurrido un error de tiempo de espera para escritura5 Actualmente en modo de solo escuchar.6 17 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 Contenido0 01 02 13 04 05 06 07 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


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 Contenido0 01 02 03 04 05 06 07 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.


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.


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


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 0 0 0 0 0 0 0 1

Bobina 27 26 25 24 23 22 21 20 - - - - - - 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.


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:


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


cuando esto ocurra la función fijara los mismos registros referenciados en todos

los dispositivos esclavos.


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:


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:


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.



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

1

2

3

8

9

Micro 84

484

184/384

584

884

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:


Byte Contenido

1

2

3,4

ID del esclavo (2 para los controladores 184/384). Ver los bytes 3,4

para más información.

Indicador de estatus corriendo (0= apagado, FF= encendido).

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)


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:


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:


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


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) = 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)


8,9 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:


Byte Contenido

1 identificador del esclavo (0 para el micro 84)


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)


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)


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


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.


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


Lógica del

usuario

Situación de la

RAM

Tamaño de la

memoria

extendida

Ultimo archivo Ultimo registro

(decimal)

32K 32K 0 0 0

16K 64K 72K 8 3727


Lógica del

usuario

Situación de la

RAM

Tamaño de la

memoria

extendida


(decimal)

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


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.


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.


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:


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.


Lógica del

usuario

Situación de la

RAM

Tamaño de la

memoria

extendida


(decimal)

32K 32K 0 0 0

16K 64K 72K 8 3727


Lógica del

usuario

Situación de la

RAM

Tamaño de la

memoria

extendida


(decimal)

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).


Figura 3.29 pregunta para escribir referencias generales.

Respuesta:

La respuesta normal es un eco de la pregunta


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:

Hexadecimal Binario

Contenido actual = 12 0001 0010

mascara_AND = F2 1111 0010

mascara_OR = 25 0010 0101

mascara_AND = 0D 0000 1101

resultado = 17 0001 0111

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.


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.

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.


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.

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).

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:


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).


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.


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.

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.

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 el contador de errores de

comunicación en el bus

S S S N N S

13 Regresa el contador de errores de excepción

en el bus.

S S S N N S

14 Regresa el contador de mensajes del esclavo S S S N N N

15 Regresa el contador del esclavo de no

respuestas.

S S S N N N

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 del contador de caracteres

desbordados en el bus.

S S S N N S

19 Regreso del contador de IOP desbordados

(884).

N N N S N N

20 borrar banderas y contadores de

desbordamiento

N N N S N N

21 Obtener/borrar estadisticas de Modbus Plus N N N N N S

22-hacia

arriba

Reservado

(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

(pregunta)

Campo de datos (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

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 on-

line.

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.


(pregunta)

Campo de datos

(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.


(pregunta)

Campo de datos (respuesta)

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

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.


(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).


(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

contadores. Los contadores también son borrados después de una falla de

alimentación.


(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.


(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.



(pregunta)


00 0C 00 00 Cantidad de errores CRC

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.


(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.


(pregunta)


00 0E 00 00 Cantidad de mensajes del esclavo

15 (0F hexadecimal) Regreso del contador de No respuestas del esclavo



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)

00 0F 00 00 Cantidad de no respuestas del

esclavo

16 (10 hexadecimal) Regreso del contador NAK del esclavo


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.


(pregunta)


00 10 00 00 Contador NAK del esclavo

17 (11 hexadecimal) Regreso del contador de ocupado del esclavo


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.



(pregunta)


00 11 00 00 Contador de dispositivo ocupado del

esclavo

18 (12 hexadecimal) Regreso del contador de caracteres desbordados en el

bus.


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.


(pregunta)


00 12 00 00 Contador de caracteres desbordados del

esclavo

19 (13 hexadecimal) Regreso del contador de IOP desbordados (884).


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

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.


(pregunta)


00 14 00 00 Eco de los datos en la pregunta.


CAPITULO 5

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.


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


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


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).

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

transferencia

2 Bytes Identificación

de una petición

MODBUS/trans

ferencia de

Iniciado por el

cliente

Recopilado por

el servidor de

la petición

recibida.


respuesta

Identificador de

protocolo

2 Bytes 0= protocolo

MODBUS

Iniciado por el

cliente

Recopilado por

el servidor de

la petición

recibida

Longitud 2 Bytes Numero de

bytes

siguiendo

Iniciado por el

cliente

(petición)

Iniciado por el

servidor

(respuesta)

Identificador de

unidad

1 Byte Identificación

de un esclavo

conectado

remotamente

en una línea

serial o sobre

otro bus.

Iniciado por el

cliente

Recopilado por

el servidor de

la petición

recibida

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.


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.

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

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).

Aplicación del Usuario

Interfase Cliente Modbus

Capa de comunicación de la aplicación

Cliente Modbus Servidor Modbus

Parte trasera de la interfase modbus

Pila de parametrizacion

Administrador TCP

Administrador de conexión

Control de acceso

Pila TCP/IP


Tablas

principales

Tipo de

objeto

tipo Comentario

Entradas

discretas

Bit simple Solo lectura Este tipo de dato puede ser

proporcionado por un sistema de

entrada/salida

Bobinas Bit simple Lectura/

escritura

Este tipo de dato puede ser

alterado por un programa de

aplicación

Registros de

entrada

Palabra de 16

bits

Solo lectura Este tipo de dato puede ser

proporcionado por un sistema de

entrada/salida

Registros

sostenidos

Palabra de 16

bits

Lectura/

escritura

Este tipo de dato puede ser

alterado por un programa de

aplicación

Figura 5.6 Modelo de los datos Modbus con bloques separados

Memoria del dispositivo de aplicación

Entradas discretas

Bobinas

Registros de entradaRegistros de salida

Petición MODBUS


Figu

Figura 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.

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

Memoria del dispositivo de aplicación

Entradas discretas

Bobinas

Registros de entradaRegistros de salida

Petición 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.

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.

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

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.

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.

É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.

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.

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).

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.

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.

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.

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:

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”.

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.

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.

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.

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.

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.

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.

Figura 6.1 computadoras en Duty – Stand by

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.

A sistema de Supervisión


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


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.


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.


Figura 6.5 Supervisorio Infohawk


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


El CIATEQ esta 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.


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


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ónEd. 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

https://www.upv.es/pls/sobib/est_biblio.doc_rdoBusAsistidas?p_cad=3786&p_TipoBus=4&p_tipo_doc=

http://www.casadellibro.com/fichas/fichaautores/0,1463,PIEDRAFITA2MORENO32RAMON,00.html


APÉNDICE A

RESPUESTAS DE EXCEPCIÓN

RESPUESTAS DE EXCEPCIÓN

CÓDIGOS DE EXCEPCIÓN


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


(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.


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.


A.2 CÓDIGOS DE EXCEPCIÓN

Código Nombre Significada

01 Función Ilegal El código de función recibido en la petición no es una

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

Ilegal

El dato de dirección recibido en la petición no es una

dirección permitida para el esclavo

03 Dato de Valor

Ilegal

Un valor contenido en el campo de datos de la

petición no es un valor admisible para el esclavo.

04 Fallo dispositivo

esclavo

Ha ocurrido un error no recuperable mientras el

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

esclavo Ocupado

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.

07 Reconocimiento

negativo

El esclavo no puede efectuar la función de programa

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

en memoria

El esclavo ha intentado leer memoria extendida, pero

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.


APÉNDICE C

GENERACIÓN DEL LRC

GENERACIÓN DEL CRC


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):


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 ; /* apunta a la parte del mensaje a calcularle el LRC */unsigned short usDataLen; /*cantidad de bytes a tratar, dentro del mensaje */

{unsigned char uchLRC = 0; /* LRC inicializado */while (usDataLen--) /* a lo largo de todo el buffer de mensaje */uchLRC += *auchMsg++; /* suma un byte del buffer, sin acarreo */return ( (unsigned char) (- ((char) uchLRC))); /* devuelve el complemento a dos */}

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:


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.


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


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 ; /* apunta al mensaje a calcularle el CRC */unsigned short usDataLen; /*cantidad de bytes a tratar, dentro del mensaje */

{unsigned char uchCRCHi = 0xFF; /* byte alto del CRC inicializado */unsigned char uchCRCLo = 0xFF; /* byte bajo del CRC inicializado */unsigned uIndex; /* indexará a la tabla de valores CRC */while (usDataLen--) /* a lo largo de todo el buffer de mensaje */{uIndex = uchCRCHi ^ *puchMsg++ ; / *calcula el CRC */uchCRCHi = uchCRCLo ^ auchCRCHi [uIndex] ;uchCRCLo = auchCRCLo [uIndex] ;}return ( uchCRCHi << 8 | uchCRCLo);}

Redes Industriales Mod Bus

Documents

Transcript of Redes Industriales Mod Bus