MODBUS
Definición.
El lenguaje común utilizado por todos los controladores Modicon es el protocolo
Modbus. Este protocolo define una estructura de mensaje que los controladores
reconocerán y usarán, con independencia del tipo de redes sobre la que comuniquen.
Describe el proceso que usa un controlador para pedir acceso a otro dispositivo, cómo
responderá a las peticiones desde otros dispositivos y cómo se detectarán y notificarán los
errores. Establece un formato común para la disposición y contenido de los campos de
mensaje.
El protocolo MODBUS define una red digital de comunicaciones con un solo
maestro (master) y uno o más dispositivos esclavo (slave). La comunicación ModBus es un
estándar industrial utilizado por muchos productos como PLCs, sistemas SCADA,
Estaciones Centrales (Front End Stations), Servidores de Terminales, etc.
Reseña histórica.
Los autómatas programables se introducen por primera vez en la industria en 1960
aproximadamente. Bedford Associates propuso un sistema de control denominado
Controlador Digital Modular (Modicon, Modular Digital Controler) al fabricante de
automóviles General Motors.
Otras compañías propusieron a la vez esquemas basados en ordenador, uno de los cuales
estaba basado en el PDP-8. El MODICON 084 resultó ser el primer PLC del mundo en ser
producido comercialmente.
A mediados de los 70 las tecnologías dominantes de los PLC eran máquinas de estado
secuenciales y CPU’s basadas en desplazamiento de bit Los microprocesadores
convencionales incorporaron la potencia necesaria para resolver de forma rápida y
completa la lógica de los pequeños PLC's. Por cada modelo de microprocesador había un
modelo de PLC basado en el mismo.
Las funciones de comunicación comenzaron a integrarse en los autómatas a partir del
año 1973. El primer bus de comunicaciones fue el Modbus de Modicon. El PLC podía
ahora establecer comunicación e intercambiar informaciones con otros PLC's
Características Generales.
El modo de transmisión es la estructura de las unidades de información contenidas
en un mensaje. El protocolo MODBUS define dos modos de transmisión: ASCII (American
Standard Code for Information Interchange) y RTU (Remote Terminal Unit). En una red de
dispositivos conectados mediante el protocolo MODBUS NO se pueden compartir
dispositivos utilizando diferentes modos de transmisión.
El protocolo Modbus proporciona el standard interno que los controladores
Modicon usan para el análisis de los mensajes. Durante la comunicación sobre una red
Modbus, el protocolo determina cómo cada controlador conocerá su dirección de
dispositivo, reconocerá un mensaje direccionado a él, determinará el tipo de acción a tomar
y extraerá cualquier dato u otra información contenida en el mensaje. Si se requiere una
repuesta, el controlador construirá el mensaje respuesta y lo enviará utilizando el protocolo
Modbus. Sobre otras redes, los mensajes del protocolo Modbus están integrados en la trama
o estructura de paquetes utilizadas sobre la red.
La figura 1 muestra cómo se pueden interconectar los dispositivos en una jerarquía de redes
que emplean técnicas de comunicación que difieren ampliamente. En la transacción de
mensajes, el protocolo Modbus integrado en la estructura de paquetes de cada red
proporciona el lenguaje común por el cual los dispositivos pueden intercambiar datos.
Características Técnicas.
Transacciones sobre Redes Modbus
Los puertos standard Modbus en controladores Modicon utilizan un interface serie
compatible RS-232C. La norma EIA RS-232C define patillas del conector, cableado,
niveles de señal, velocidades de transmisión y control de paridad. Los controladores pueden
ser conectados en red directamente o vía modems.
Los controladores comunican usando una técnica maestro – esclavo, en la cual sólo
un dispositivo (el maestro) puede iniciar transacciones (llamadas ‘peticiones’). Los otros
dispositivos (los esclavos) responden suministrando al maestro el dato solicitado, o
realizando la acción solicitada en la petición. Entre los dispositivos maestros típicos se
incluyen los procesadores centrales y los paneles de programación. Los esclavos típicos son
los PLC’s (controladores programables).
El maestro puede direccionar esclavos individualmente o puede generar un mensaje
en modo difusión a todos los esclavos. Los esclavos devuelven un mensaje (llamado
‘respuesta’) a las peticiones que les son direccionadas individualmente. No se devuelven
respuestas a peticiones en modo difusión enviadas desde el maestro.
El protocolo Modbus establece el formato para la petición del maestro, colocando
en ella la dirección del dispositivo esclavo (0 en caso de ‘difusión’), un código de función
que define la acción solicitada, cualquier dato que haya de enviarse y un campo de
comprobación de error. El mensaje de respuesta del esclavo está también definido por el
protocolo Modbus. Contiene campos confirmando la acción tomada, cualquier dato que
haya de devolverse y un campo de comprobación de error. Si el mensaje recibido por el
esclavo es defectuoso o el esclavo es incapaz de realizar la acción solicitada, construirá un
mensaje de error y lo enviará como respuesta.
Transacciones en otros tipos de redes
Además de sus capacidades Modbus standard, algunos modelos de controladores
Modicon pueden comunicar sobre Modbus Plus, utilizando puertos incorporados al efecto o
adaptadores de red y sobre MAP, utilizando adaptadores de red. En estas redes, los
controladores comunican usando una técnica ‘todos contra todos’ (‘peer-topeer’) en la cual
cualquier controlador puede iniciar transacciones con los otros controladores. Así un
controlador puede operar como maestro o como esclavo en diferentes transacciones. Con
frecuencia se proporcionan múltiples caminos internos para permitir procesamiento
concurrente de transacciones maestro y esclavo.
A nivel de mensaje, el protocolo Modbus todavía aplica el principio maestro-
esclavo aunque el método de comunicación en red sea ‘peer-to-peer’. Si un controlador
origina un mensaje, lo hace como un dispositivo maestro y espera una respuesta desde un
dispositivo esclavo. De la misma forma, cuando un controlador recibe un mensaje,
construye una respuesta como esclavo y la envía al controlador que originó la transacción.
La Petición: El código de función en la petición 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 mantenidos (holding regs.) y
responda con sus contenidos. El campo de datos debe contener la información que indique
al esclavo en qué registro debe comenzar y cuántos ha 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.
Los Dos Modos de Transmisión Serie
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
mantenidos (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 Comprobación 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 digitos 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 digitos 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 Comprobación de error: Comprobación Cíclica Redundante (CRC).
Trama del Mensaje Modbus
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.)
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 debajo una trama de mensaje típica.
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 mas 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 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 contínuo. 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. Debajo se muestra una trama de
mensaje típica.
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, situa 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 mas alto, las difusiones
pueden no estar permitidas o pueden ser reemplazada 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.
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 mantenidos 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 mantenidos
(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.
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:
Con trama de carácter RTU, la secuencia de bit es:
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 ACSII, 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 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.
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 (El valor preestablecido es A001 hex, correspondiente al polinomio
generador CRC16‘Inverso’, que es el que se aplica al CRC Modbus). Si el LSB fuese un 0,
no se efectúa un 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 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.
Tipo de Empresas en donde se está utilizando.
* Estaciones de bombeo * Bodegas refrigeradas
* Sistemas contra incendios * Sistemas de seguridad.
* Subestaciones eléctricas * Camaroneras y criaderos de pescado
* Compresores * Mejoramiento de sitios.
* Vigilancia de pozos * Vigilancia agrícola
* Pozos petroleros. * Estaciones de desague
* Detección de fugas *Monitoreo de motores
* Sistemas de aire acondicionado. * Telemetría
* Torres Celulares y Trunking. * Criaderos de pollos
* Invernaderos * Monitoreo de tanques.
* Monitoreo de ácidos (pH) * Monitoreo de RF
* Fundidoras. * Estaciones Hidroeléctricas
* Control de aguas. * Plantas de procesamiento
* Control de nivel, de vacío, temperatura, peso, presión, fluido, aire, etc.
* Advertencia Comunitaria de Defensa Civil, Sísmicos, etc.
Dispositivos que emplean el protocolo MODBUS.
Arrancador suave de media tensión
En esta tercera generación, se ha desarrollado el arrancador suave de media tensión
con la utilización de fibra óptica para su aplicación en motores de cortocircuito asíncronos
y motores síncronos.
El arrancador suave es un altamente sofisticado arrancador digital que asegura suavidad,
aceleración y desaceleración sin escalones, eliminando sobrecargas eléctricas y mecánicas
tanto al motor como a la máquina accionada. Se puede suministrar en chasis o en tipo
cerrado con una gran gama de opciones. Este posee Transmisión RS485 con
MODBUS,PROFIBUS o MODBUS/TCP (otros bajo consulta)
SISTEMA ULTRAC SCADA Inalámbrico
ULTRAc es un sistema inalámbrico de SCADA y de Telemetría. Ofrece una manera
práctica y económica de supervisar más de 1000 sitios remotos vía radio. El sistema
ULTRAc comprende tres partes: Unidad Terminales Remotas (UTR) (RTU en inglés)
Modelos 1708 y 1716, el controlador del sistema Modelo 1700, y el programa
"ULTRAc+/Loockout" que corre en una computadora personal (PC).
CARACTERISTICAS:
* Hasta 44 conexiones de entrada y salida por cada terminal remota.
* Reporte de alarmas por excepciones.
* Interrogación programable (polling).
* Reporte de alarmas usando Voz o Paging.
* Opera en Radios Convencionales, de Trunking y de Datos.
* Transmisión exacta de datos a alta velocidad.
* Comparte canales de radio de voz existentes.
* Gabinete industrial NEMA 4.
* Cargador y batería de respaldo.
* Comunicación con PLC usando protocolo MODBUS.
* Graba y repite (Store and Forward).
* Se puede usar con Radios para Datos de Espectro Extendido(Spread Spectrum).
* Entradas para conteo y acumulación de pulsos.
* Económicos, altamente redituables.
S7810M Módulo de Comunicación ModBus
Honeywell orgullosamente presenta el nuevo Módulo ModBus S7810M. El Módulo
ModBus permite una fácil y rápida comunicación entre los controles de SERIE7800, el
Anunciador Expandido, y el nuevo Control de Razón Gas/Aire (Fuel/Air Ratio Control),
con PlantScape o con cualquier otro sistema con comunicación ModBus.
EGW1-MB
EGW1-MB es un servidor serial Modbus diseñado para aplicaciones industriales donde
todo el equipamiento involucrado utiliza comunicaciones Modbus TCP, Modbus ASCII ó
Modbus RTU. EGW1-MB puede conectar PLCs, drives, controladores de temperatura,
sistemas de visión, y cualquier otro tipo de equipamiento industrial con comunicación serial
y protocolo Modbus. Conversor Modbus TCP a Modbus ASCII / RTU con entradas y
salidas Digitales. EGW1-MB es un dispositivo utilizado para conectar cualquier
equipamiento industrial con comunicación serial MODBUS a una red Ethernet.
Milltronics EnviroRanger ERS 500
El EnviroRanger® ERS 500 es una solución completa, fiable y de bajo coste para la gestión
y control de sistemas de distribución de agua y de recolección de aguas residuales.
El sistema combina tecnología ultrasónica sin contacto, técnicas patentadas de
procesamiento del eco y software de aplicación probado para proporcionar la
monitorización de nivel precisa en aplicaciones con líquidos de hasta 15m (50 pies) y/o
flujo de líquidos en canales, vertederos y cauces abiertos.
La unidad base tiene 8 entradas digitales, 5 salidas digitales, una entrada analógica, un
punto de nivel ultrasónico, capacidad diferencial/promedio y un puerto RS-232 con
protocolo Modbus® RTU/ASCII.
Referencias Bibliográficas.
[Link]
[Link]
[Link]
[Link]
[Link]
a_serie/[Link]
[Link]
[Link]
