Variantes de Modbus

Existen dos variantes, con diferentes

representaciones numricas de los datos y
detalles del protocolo ligeramente desiguales.
Modbus RTU es una representacin binaria
compacta de los datos. Modbus ASCII es una
representacin legible del protocolo pero
menos eficiente. Ambas implementaciones del
protocolo son serie.
 Formato RTU
El formato RTU finaliza la trama con un suma
de control de redundancia cclica (CRC),
mientras que el formato ASCII utiliza una
suma de control de redundancia longitudinal
(LRC). La versin Modbus/TCP es muy
semejante al formato RTU, pero estableciendo
la transmisin mediante paquetes TCP/IP
(puerto del sistema 502, identificador asa-
appl-proto)
 Caractersticas de los MODBUS

Seleccin de Protocolos y Consideraciones de

Diseo
La capa de aplicacin de Modbus es
implementada como un diseo maestro-
esclavo de solicitud-respuesta para transmitir
datos de un solo punto en varias capas en red.
Este diseo fundamental funciona bien, pero
tiene sus desventajas para algunas
aplicaciones.
 1. Patrones de Mensajes de Modbus
Modbus es un protocolo de solicitud-respuesta para interaccin
entre sistemas SCADA y dispositivos de automatizacin. Para cada
solicitud que se enva, el dispositivo final debe responder. Hay una
respuesta para cada solicitud. Adems, las solicitudes con
frecuencia proceden de una sola fuente y se dirigen a un solo
dispositivo. Estos sistemas pueden ser caracterizados como un
dispositivo cliente que genera una solicitud y espera la respuesta
junto con un dispositivo servidor que analiza las solicitudes del
cliente, se encarga de ellas y despus regresa una respuesta (ver
Figura 1). La terminologa de Modbus con frecuencia se refiere al
cliente como el maestro, ya que suele actuar como el servidor del
SCADA, y se refiere al servidor como el esclavo. El esclavo es
comnmente un sensor o controlador de automatizacin.
 2. Fiabilidad de las Interacciones de Modbus
El patrn de mensajes de Modbus es similar al definido
por el protocolo HTTP. Una ventaja de este patrn es
que no requiere un capa de red extremadamente
confiable. Si el cliente (o maestro) enva una solicitud y
no recibe respuesta, sabe que algo ha salido mal y
puede volver a enviar la solicitud. Haciendo una
analoga con HTTP, esto sera equivalente a dar clic en
el botn actualizar en un navegador de internet. Si
usted enva solicitudes repetidamente y no obtiene
una respuesta del servidor, usted puede pensar que el
servidor no est funcionando y dejar de intentar tener
acceso a l temporalmente.
 3. Comunicacin No Solicitada
La naturaleza de esta arquitectura maestro-esclavo
tambin significa que los esclavos Modbus no pueden
proporcionar datos cuando no son solicitados por un
maestro. Aunque el maestro puede implementar una
arquitectura basada en eventos para enviar datos al
esclavo, debe interactuar continuamente con los
esclavos a una frecuencia definida para obtener los
nuevos datos. Esto requiere una carga adicional
significativa si los cambios son limitados, tanto en
trminos de ancho de banda de la red como en la
utilizacin del CPU del maestro.
 4. Control en Red y Determinismo
Esta incapacidad del esclavo para enviar datos no
solicitados a un maestro significa que Modbus ofrece
un nivel de control a travs de la red que algunas
aplicaciones requieren. En una red frgil, un protocolo
de solicitud-respuesta puede asegurar que el maestro
es el nico dispositivo que puede determinar cuando
ocurre comunicacin en la red. Si es configurado
correctamente, esto significa que el maestro puede
eliminar colisiones de paquetes de red y asegurar un
nivel ms alto de determinismo.
 5. Comunicacin y Organizacin de Datos Orientadas a
Etiquetas
Los datos de Modbus estn orientados en torno al
concepto de etiquetas (tags) o variables. Estos elementos
de datos, registros de retencin, registros de entrada,
bobinas y entradas discretas, son llamados con nombres
diferentes en el protocolo, pero la idea es la misma. Estas
etiquetas son elementos de datos que pueden ser escritos
o ledos en cualquier momento, pero nicamente
proporcionan el valor actual. Esto tiene sentido para varias
aplicaciones; sin embargo, implementar conceptos como
eventos, mensajes o bfers de memoria First-In-First-Out
(FIFO) puede ser difcil.