raa2016 Este sto ufiga ae Ihermacidn Detallada sobre el Protecclo Modbus - Nationa Instruments Informacién Detallada sobre el Protocolo Modbus Visién General Modbus es un protocolo industrial que fue desarrollado en 1979 para hacer posible la comunicacién entre dispositives de automatizacién, Originalmente implementado como un prrotocolo al nivel de la aplicacién con lafinalidad de transferir datos por una capa serial, Modbus se ha expandido para incluir implementaciones a través de protocolo serial, TCP/IP yeel User Datagram Protocol (UDP). Este documento ofrece una perspectiva detallada de la implementacisn del protocol. Contenido 41, £Qué es el Protocolo Modbus? 2. Unidad de Datos de Protocolo 43. Unidad de Datos de Aplcacion 4, Nuevos Cédigos de Funcién 5. Capas de Rea 6. Modificaciones de ADU 1.cau6 Modbus es un protocola de solicitud-respuesta implementado usando una relacién maestro- ‘esclavo. En una relacién maestro-osclavo, la comunicacién siempre se produce en pares, un dispositvo debe iniciar una solicitud y luego esperar una respuesta y el dispositivo de rico (el maestro) es responsable de iniciar cada interaccién, Por lo general, el maestro es una interfaz humano-maquina (HMI) o sistema SCADA y el esclavo es un sensor, controlador gico programable (PLC) 0 controlador de automatizacién programable (PAC). El contenido de estas solicitudes y respuestas, y las capas de la red a través de las cuales '5e envian esios mensajes, son definidas por las diferentes capas del protocolo. Send Request CT E = Read Response Master Slave Figura 1. Una Relacién de Red Maestro-Esclavo Capas del Protocolo Modbus En a implementacién incial, Modbus era un solo protocolo construido en base a serial, por lo que no podia ser dividida en miiiples capas. Con el tiempo, diferentes unidades de datos de aplicacién fueron introducidas ya sea para cambiar el formato del paquete utlizado a través de seral o para permitir el uso de redes TCP/IP y UDP (User Datagram Protocol) Esto llevé a una separacién del protocoto principal, el cual define la unidad de datos de protocolo (PDU) y a capa de red, que define la unidad de datos de aplicacién (ADU), 2. Unidad de Datos de Protocolo La PU y 6! eédigo que la mangja consiste en el nucleo de la Especificacién del Protocolo de Aplicacién Modbus (hitp:twwwe.modbus.crg/docs/Modbus_Application_Protocol_V1_‘b.pdf). Esta especificacién define el formato de la POU, los diversos conceptos de datos utlizados por el protocolo, el so de los cédigos de funcién para tener acceso a esos datos y la implementacién cespecifica y restrcciones de cada cédigo de funcign. El formato de Modbus PDU esté defiido como un eédigo de funcién seguido por un Conjunto de datos asociado. El tamario y el contenido de estos datos son definidos por el Ccédigo de funcién y la PDU completa (cédigo de funcién y datos) no puede exceder de 253 bytes de tamaio, Cada cédigo de funcién tiene un comportamiento especifico que los fesclavos pueden implementar de manera flexible en base al comportamiento de la aplicacién deseada, La especificacién de la PDU define conceptos basicos para el acceso y ‘manipulacion de datos; sin emeargo, un esclavo puede manejar datos de una manera que no esté definida explicitamente en la especificacién. sae a RRR £8 Ln GGER GH YBRLR AH WEBETERGH co aroccon: vooias, enraas cera, roleo8 0. ratooion y repistos de ertaca Al gua quo con gran part dee espectcaion, ts hombres puoden verar dependionda don indtnao ola epicaicn or ojo, fos tagiivon da fatenclén pueden deromnerse come region de sala la bones pueden Ipukwwrn.comMuhite-paper82134/es! vioraa2016 Ihermacidn Detallada sobre el Protocclo Modbus - Nationa Instruments denominarse como saldas digtales o discretas. Estos bancos de datos denen el tipo y los derechos de acceso de los datos contenidos. Los disposttivos esclavos tienen acceso directo a estos datos, los cuales son alojados locaimente en los dispositivos. Los datos disponibles por medio de Modbus generalmente son un subconjunto de la memoria principal del dispositivo. En contraste, los maestros Madbus deben solcitar el acceso a estos datos a través de diversos cédigos de funcién. El comportamiento de cada bloque se describe en la Tai Bloque de Memoria [ipa de Datos [Acseno de |Botinas |Poasane [ncusctee cca | JentedasDiscretas_|Bosteeno |sootecire ——|Lacusescura_ | Regstros do [Palabra Sin Sqno | LecuavEsotura —_|LecuafEsrara Retoncon Registros do | PaabaSin Sgro |SooLecura ———_|Lacua/Escrra Entrada Tabla 1. Bloques de Modelo de Datos de Modbus Estos bloques le brindan la hablldad de restsingiro permitr el acceso a los diferentes elementos de datos y también de proporcionar mecanismos simpiiicados en la capa de aplicacién para tener acceso a diferentes lipos de datos. Los bloques son completamente conceptuales. Pueden exist como direcciones de ‘memoria separadas en un sistema determinado, pero también pueden traslaparse. Por ejemplo, la bobina uno puede existr en la misma ubicacién en memoria como el primer bit de la palabra representada por el registro de retencién uno. El esquema de direccién se define completamente por el dispositive esclavo y su interpretacién de cada bloque de ‘memoria es una parte importante del modelo de datos del dispositvo, Direccién de Modelo de Datos La especificacion define que cada blogue contiene un espacio de direccién de un maximo de 65,536 (2°°) elementos, Dentro de la definicion de la PDU, Modbus define la direccién de cada elemento de datos que va desde 0 a 65,535. Sin embargo, cada elemento de datos ‘std numerado de 1/a n, donde n tiene un valor maximo de 65,536. Es decr, la bobina 1 ‘std en el Bloque de bobina en la direccién 0, mientras que el registro de retencién 54 esta tena direccién 53 de la seccién de la memoria que el esclavo ha definido como regisiros de retencién No se requiere que los rangas completos permits por la especificacién sean implementados por un determinado dispositivo. Por ejemplo, un dispositive puede optar por no implementar bobinas, entradas discretas o registros de entrada y en su lugar solamente sar los registros de retencién 150 al 175 y 200 al 225. Esto es perfectamente acoptable y los intentos de acceso no validos pueden manejarse a través de excepciones. Rangos de Direccién de Datos ‘Aunque la especificaciin define los diferentes tipos de datos que existen en diferentes bbloques y asigna un rango de direccién local para cada tipo, esto no se traduce necesariamente en un esquema intutvo de direccién para fines de documentactén 0 para Comprender la memoria disponible através de Modbus de un dispositivo determinado. Para simplifcar la discusién de ubicaciones del bloque de memoria, se introdujo un esquema de ‘numeracién, el cual aade prefiios aa direccién de los datos en cuestisn. Por ejemplo, en lugar de referir a un elemento como registro de retencién 14 en la dreccién, 413, un manual de dispositivo se referiria a un elemento de datos en la direccién 4,014, 40,014 0 400,014. En cada caso, el primer niimero especificado es 4 para representar registros de retencién y Ia direccién es especificada usando los niimeros restantes. La diferencia entre 4XXX, 4XXXX y 4XXXXX depende del espacio de direccién usado por el dispositvo. Si todos los 65,536 registros estén en uso, la anotacién 4XXXXX debe ser sada, ya que permite un rango de 400,001 a 465,536. Si solamente algunos registros son usados, una préctica comin es usar el fango de 4,001 al 4,999, En este esquema de direccién, a cada tipo de datos se le asigna un prefiio como se muestra Este sto uf4JaQlA Bera ofrecere una mejor experiencia de busqueda, Conazca nuestra politica de arivacdad, (hitodimnv.n comlecalonvaculuntedstates/us/) Bloque de Datos Prefijo |sovins ip | Iipukwwrn comMuhite-paper82134es! 210raa2016 Ihermacidn Detallada sobre el Protocclo Modbus - Nationa Instruments [esa Diecreae 4 |Registos de Entrada 2 | |Rogistos de Rtonibn n Tabla 2. Prefijos de Rangos de Datos Existen bobinas con un prefijo 0. Esto significa que una referencia de 4001 podria referrse al registro de retencién uno 0 bobina de 4001. Por esta razén, se recomienda que todas las ‘nuevas implementaciones usen direccién de 6 digitos con ceros a la izquierda y se cespecifique esto en la documentacién, Por lo tanto, el registra de retencién uno es referenciado como 400,001 y la bobina de 4001 es referenciada como 004,001, Valores de Inicio de Direccién de Datos La diferencia entre las dtecciones de memoria y los niimeros de referencia es atin mas ‘complicada por el indice seleccionado por una aplicacién determinada. Como se mencioné anteriormente, el registro de retencién uno esté en la direccién caro. Tipicamente, los rnumeros de referencia son indexados en base a uno, lo que significa que el valor de inicio de un intervalo determinado es uno, Por lo tanto, 400,001 se traduce iteralmente al registro de retencién 00001, el cual esté en la dreccién 0. Algunas implementaciones eligen iniciar sus rangos en cero, lo que significa que 400,000 se traduce en el registra de detencién en la direceién cero, La Tabla 3 muestra este concepto. Deen rod Rito |Nimao cstnen) ieratiy jo h |szo0% {420000 | js le |scasca [sooo | iE h |soacoa |sao002 Tabla 3. Esquemas de Indice de Registro Los rangos indexados a 1 son comunes y altamente recomendados. En cualquier caso, el valor de inicio para cada rango debe ser anotado en la documentacién, El esténdar Modbus proporciona un madelo de datos relativamente simple que no incluye los tipos de datos adicionales fuera de una palabra sin signo y valor de bit, Aunque esto es suficiente para algunos sistemas, donde los valores de bits corresponden a los solenoides y relés y los valores de palabra corresponden alos valores de ADC sin escalar, no es suficiente para los sistemas mas avanzados, Como resultado, muchas implementaciones Modbus incluyen tipos de datos que cruzan los limites de registros. EI Médulo NI LabVIEW Datalogging and Supervisory Control (DSC) (http://zone.ni.comireference/an- Xihelp/371618J-01/lvmveldse_madbus_using/) y KEPServerEX (httpswworkepware.com/Support_Center/SupportDocuments/Help/modbus_ethernet.pdf) definen un ndmero de tipos de referencia, Por ejemplo, las secuencias almacenadas en un registro de retencién siguen la forma estandar (400,001) pero son seguidas de un decimal, la longitud y el orden de bytes de la secuencia (400,001.2H, una secuencia de dos caracteres en el registro de retencién donde el byte alto corresponde al primer cardcter de la Secuencia), Esto es necesario debido a que cada solicitud tiene un tamafio limitado, por lo que un maestro Modbus debe conacer ls limites exactos de la secuencia en lugar de buscar una longitud 0 delimitador como NULL. ‘Ademas de permit el acceso a los datos que cruza un limite de registro, algunos maestros Modbus soportan referencias para bits individuales dentro de un registro, Esto es benéfico, ya que permite que los dispositivos cambinen datos de cada tipo en el mismo rango de ‘memora sin tener que dividr los datos binarios en entre bobinas y rangos de entrada discretos. Esto normaimente es referenciado como un punto decimal y el indice de bits 0 indimero, dependiendo de la implementacién. Es decir, el primer bit en el primer registro ppuede ser 400,001.00 0 400,001.01. Se recomienda que toda documentacién especifique el fesquema de indice utlizado, Este stio ude dates dpznitinis cesatngocomeal valde ountaotante desresiién.einle,quadan (hitodmwvageenstercon écitmentaien Modbus al dividir los datos en dos registros. Ya que esto no- est8 definido por el esténdar, el endianness (u orden de bytes) de esta division no est definida, Aungue cada palabra no signada debe ser enviada en orden de byte dela red (big- endian) para cumplir con el esténdar, varios dispostvos invert el orden de bytes para datos de multiples bytes. La Figura muestra un ejemplo usual pero valio sobre esto. tephra pope! a0raa2016 Este sto io REO Or ASSES Ihermacidn Detallada sobre el Protocclo Modbus - National Instruments Sa ae Figura 2. Intercambio de Orden de Bytes para Datos de Miltiples Palabras Depende del maestro comprender cémo el esclavo esta almacenando informacién en la ‘memory decodifcarlo correctamente. Se racomienda que la documentacién refleje el orden de las palabras utlizadas por el sistema. El orden de bytes también puede ser affadido como una apcién de configuracién del sistema, con funciones de codificacion y decotificacién fundamentales, si se requiere flexibilidad en la implementacién, stings Los strings pueden ser faclmente almacenados en ragistros de Modbus. Para simplficar, algunas implementaciones requieren que las longitudes de los stings sean miltiplos de dos, con cualquier espacio adicional lenado con valores nulos. El orden de los bytes también es una variable en las interacciones de los strings, El formato del string puede ono inclu un NULL como el valor final. Como ejemplo de esta variablidad, algunos dispositivos pueden almacenar los datos come se muestra en la Figura 3. Figura 3, Reversién de Orden de Bytes en secuencias de Modbus ‘Comprender Codigos de Funcion En contraste con el modelo de datos que puede variar considerablemente de un dispositive a otro, los cédigos de funcién y sus datos son definidos explicitamente por el estandar. ‘Cada funcion sigue un patrén. Primero, el esclavo valida entradas como el codigo de funci6n, direccién de datos y el rango de datos. Después, ejecuta la accién solictada y cenvia una respuesta adecuada al cédigo. SI cualquier paso en este proceso fala, se regresa luna excepcién al solcitante. El transporte de datos para estas solicitudes es la PDU. La PDU consta de un cédigo de funcién de un byte seguido de hasta 252 bytes de datos de funciones especfficas. Feo. Spct aa Figura 4. La PDU de Modbus El e6digo de funcién es el primer elemento que sera validado. Si el cédigo de funcién no es reconocido por el dispositive que recibe la solictud, respande con una excepcién. Si se acepia el codigo de funcion, el dispositivo esclavo comienza a descomponer los datos de acuerdo con la defiicién de la funcién, Debido a que el tamario del paquete esté limitado a 253 bytes, los dispositivos estén limitados a la cantidad de datos que pueden ser transferidos. Los cédigos de funcién mas ‘comunes pueden transferir entre 240 y 250 bytes de datos del modelo de datos de esclavos, dependiendo del cédigo. ‘Segtin lo define el modelo de datos, diferentes funciones son definidas para tener acceso a diferentes bloques conceptuales de datos. Una Inert ‘comin es que los eédigos Seas yar le eel pot eter tec ia Tiaras baci fica er ia morro, Por el Conran el cédigo de funcion 3 (leer registros de retencion) y el 16 (escribir 2 registros de retencién) Iepukwwrn comMuhite-paper8213/es! a0raa2016 Este sto u Ihermacidn Detallada sobre el Protocolo Modbus - National Instruments tionen acceso a ubicaciones completamente diferentes en la memoria. Por lo tanto, la ejecucién de cada cédigo de funcién mejor es considerada como parte de la definicién del modelo de datos del esclavo. Independientemente del comportamiento realizado, se espera que todos los dispositivos tesclavos sigan un diagrama de estado simple para cada solicitud. La Figura 5 muestra un ejemplo de esto para el cédigo 1, que lee bobinas, Figura 5, Leer Diagrama de Estado de Bobinas desde la Especificacién del Protocolo Modbus (hitp:iww.modbus.org/docs/Modbus_ Application Protocol V1_tb.pdf) Cada esclavo debe validar el cédigo de funcién, el nimero de entradas, la direccién de rico, el rango total y la ejecucién de la funcién definida por el esclavo que realiza la lectura, ‘Aunque los rangos de direccién estatica se muestran en el diagrama de estado de arriba, las necesidades de Ios sistemas del mundo real pueden causar que estos varien un poco en log niimeros definidos. En algunos casos, los disposiivos esclavos no pueden transferir el indmero maximo de bytes definido por el protocolo. Es decir, en lugar de permitr que un ‘maestro solicte entradas 0x07D0, unicamente puede responder con 0x0400. De forma similar, un modelo de datos esclavo puede definir el rango de valores aceptables de bobina ‘como las direcciones de 0 a 600, Si un maestro hace una solictud para 125 iniciando en la direccién 0, esto estd bien, pero si un maestro hace la misma solictud iniciando en la direccién 400, la bobina final estara en la direccién 525, la cual esta fuera del rango para este dispositivo y resuitaria en la excepcién 02 como lo define el diagrama de estado. La definicén de cada cédigo de funcién estandar esta en la especificacion. Incluso para los Ccédigos de funcién mas comunes, existen discrepancias inavitables entre las funciones habiltadas en el maestro y lo que el esclavo puede manejar. Para solucionar esto, las versiones anteriores de la especificacién Modbus TCP definen tres clases de conformidad {htipsiwwsustaautomation.com/modbustepifles/Open_ModbusTCP_Standard.pdf), La Especificacién de Pruebas de Compatibildad Modbus (htto:iwinw.modbus.org/docs/MBConformanceTestSpec._v3.0.pdi) oficial no hace referencia a estas clases y en su lugar define la compatiilidad en cada funcién; sin embargo, puede ser conveniente para comprenderlo. Se recomienda que cualquier documento siga la ‘especiicacién de pruebas y determine su compatiilidad con los cédigos que soportan, en lugar de con las clasificaciones de legado. Cédigos Clase 0 Los cédigos Clase 0 generalmente son considerados el minimo para un dispositive Modbus il, ya que dan a un maestro Ia habilidad de leer o escribir en el modelo de datos. Cédigo Des [s | Lowrie Reistos a acts Mines Regs IS cosespare acon SS RES ROY ESF a, coor ena soln te otc (hitomi. comlecalonvacsluntedTaba'd;Compatibilidad con Cédigos Clase 0 Cédigos Clase 1 Iepukwwrn comMuhite-paper8213/es! 510raa2016 (rata) Ihermacidn Detallada sobre el Protocolo Modbus - National Instruments Los cédigos de funcién Clase 1 consisten en los otros cédigos necesarios para tener acceso 2 todos los tipos del modelo de datos. En la definicién original, esta lista incluye el cédigo de funcion 7 (leer excepcién), Sin embargo, este cédigo es definido porla especificacion actual ‘como un eédigo para serial inicamente. Codigo Deseripeién 1 Leer Bobinas 2 Lear Entradas Diseretas 4 Looe Rogistros de Entrada 5 Escribi a Bobina Individual 5 Escrbie a Registro Individual 7 Lear Estado de Excepcién(inicamente serial Tabla 5. Compatibidad con Cédigos Clase 1 Cédigos Clase 2 Los cédigos de funcién Clase 2 son funciones mas especializadas que son implementadas ‘con menos frecuencia. Por ejemplo, Leer/Escribir Maltiples Registros puede ayudar a reducir el nimero total de ciclos de solictud-respuesta, pero el comportamiento atin puede ser implementado con cédigos Clase 0. Deseripeién | de Codigo 18 Escribi a Mitiles Bobinas 20 Lear Registro de Archivo a1 Escrbiea Registro de Archivo 2 Escribiea Registro con Mascara 23 LeerfEscriir Maltiples Regisros 26 Leer FIFO Tabla 6. Compatibidad con Cédigos Clase 2 Interfaz Modbus Encapsulada El cédigo de Interfaz Modbus Encapsulada (MEI), funcién 43, ¢s usado para encapsular ‘tras datos en un paquate Modbus. En la actualidad, dos nimeros MEI estan disponibles, 13 (CANopen) y 14 (identiicacion de dispositivos) La Funcién 43/14 (identificacién de dispostves) es dtl, ya que permite la transferencia de hhasta 256 objetos Unicos, Algunos de estos objetos son predefinidos y reservados, como el nomare del proveedor y el digo de producto, pero las aplicaciones pueden definir otros objetos a transferir como conjuntos de datos genéricos. Este eéaigo no es implementado cominmente, Excopciones Los esclavos ulilizan excepciones para indicar un niimero de condiciones de error, desde na solicitud matformada hasta entradas incorrectas, Sin embargo, las excepciones también se pueden generar como una respuesta a nivel de la aplicacién para una solictud valida, Los esclavos no responden a las solicitudes emitidas con una excepcién. En cambio, el esclavo ignora solicitudes incompletas o alteradas y comienza a esperar un nuevo mensaje entrante Las excepciones son reportadas en un formato de paquete defnido. Primero, un cédigo de funcién se regresa al maestro que solicita igual al cédigo de funcién original, excepto con su Conjunto de bits més significativo. Esto es equivalente a afiadir 0x80 al valor del cédigo de funcién original. En lugar de los datos normales asociados con una respuesta de funcién determinada, las respuestas de excepcién incluyen un solo cédigo de excepcién, Dentro del estandar, los cuatro cédigos de excepcién mas comunes son 01, 02, 03 y 04, este sito uit Se cDyssieN 218 TAP AL a astanse MOodigode! o! Sigmitebas Excepelén Iepukwwrn comMuhite-paper8213/es! a0raa2016 Ihlermacidn Detallada sobre el Protocclo Modbus - National Instruments El cédigo de funcién recibido no esta soportado, Para confrmar el cédigo de funcién original, restar 0x80 del valor devuelto, La solictud intents tener acceso a una direccién no valida. En el ‘standar, esto puede ocurrir inicament si la direccién de inicio y o! numero solctado de valores excede 2'®, Sin embargo, algunos dispositivos pueden imitar este espacio de direccién en su modelo de datos. 03 La solicitud tenia datos inoorrectos. En algunos casos, esto significa que habla una discrepancia de pardmetros, por ejemplo entre el numero de registros enviados y el campo “cantidad de bytes", Normalmente, maestro solcité mas datos de lo que permite ya sea el esciavo o el protocolo. Por ejemplo, un maestro puede leer solamente 125 registros de detencion a la vez y los dispositivos con recursos limitados pueden | dolimitar este valor a incluso menos ragistros. 04 ‘Se ha producido un error irrecuperable al intentar procesar la soicitud. Este es un cédigo de excepcién general que indica que la solictud era valida, pero el esclavo no podia ejecutarla. Tabla 7, Cédigos de Excepolén de Modbus Comunes El diagrama de estado para cada cédigo de funcién debe cubrir al menos el cédigo de cexcepcisn 01 y por lo general incluye los cédigos de excepcién 04, 02, 03, cualquier otro Ccédigo de excepcién definido es opcional 1. Unidad de Datos de Aplicacion ‘Ademas de la funcionalidad definida en la PDU principal del protocolo Modbus, usted puede Usar varios protocolos de red. Los protocolos mas comunes son serial y TCPIP, pero usted puedo usar otras como UDP también, Para transmit los datos necesarios para Modbus a través de estas capas, Modbus incluye un conjunto de variantes ADU que son disefiadas para cada protocolo de red. Caracteristicas Comunes, Modbus requiere ciertas caracteristicas para proporcionar una comunicacién confiable. El No. de Unidad 0 de Direccién es usado en cada formato de ADU para proporcionar informacién de enfutado a la capa de la aplicacién. Cada ADU se vende con una PDU completa, la cual incluye el cédigo de funcion y los datos asociadios para una soliitud determinada. Para mayor fiabilidad, cada mensaje incluye la informacién de comprobacién de errores, Finalmente, todas las ADUs proporcionan un mecanismo para determinar el ccomienzo y el final de un marco de solicitud, pero los implementa de manera diferente. Formatos Estandares Los tres formatos ADU esténdares son TCP, unidad terminal remota (RTU), y ASCII. RTU y ASCII ADUs normalmente son usados a través de una linea serial, mientras que el TCP es usado a través de redes TCP/IP o UDPIIP madernas. TePnP Las ADUs de TCP consisten en el Encabezado de Protocolo de Aplicacién Modbus (MBAP) ‘combinado con la PDU de Modbus. EI MBAP es un encabezado de uso general que depende de una capa de red confiable, El formato de esta ADU, incluyendo el encabezado, se muestra en la Figura 6. fraser] rues | warn | UO ona Pou Figura 6. La ADU de TCP/IP Los campos de datos del encabezado indican su uso. Primero, incluye un identifcador de transaccién, Esto es valioso en una red en la que se pueden soportar maltiples solicitudes simulténeamente. Es decir, un maestro puede enviar solicitudes 1, 2, y 3. En algun punto, lun esclavo puede responder en el orden 2,1, 3, y el maestro puede igualar las solicitudes con las respuestas y analizar los dalos con precision. Esto es tl para redes Ethemet Elidentifcador de protocolo es normalmente coro, pero usted puede utlzarlo para ampliar {el comportamiento del protocolo. El campo de longitud es usado por el protocola para Este sto udebrieaKa/pnairkdahsesto del peqpate ta ubisanidadocesie-clomente tambidadndicataad, (hita.imwdependensioriacesiedermnata’egeabezado en una capa de red confiable. Debido a que los ‘paquetes TCP tienen veriicacion de errores integrada y garantizan la coherencia de los datos y la entrega, la longitud del paquete puede ser ubicado en cualquier parte del tencabezado, En una red inherentementa menos confiable como una red serial, un paquete podria perderse, tenlendo el etecto de que incluso sila escritura de datos lelda por la Ipukwwrn.comMuhite-papen82134es!raa2016 hermacidn Detallada sobre el Protecclo Modbus - National nstrumenis aplicacién inclu informacién valida de traneaccién y del protocolo, la informacién de longitud alterada volveriainvalido al encabezado. TCP proporciona una cantidad razonable de proteccién contra esta situacion EI ID de Unidad goneraimente no es usado por los dispositivos TCP/IP. Sin embargo, Modbus es un protocolo comtin en el que se implementan muchos gateways, lo cual ‘convierte al protocolo Modbus en otro protacolo, En el caso original de uso, un gateway Modbus TCP/IP a serial podria ser usado para permit la conexién entre las nuevas redes TCPIIP y redes seriales anteriores. En dicho entomo, eID de Unidad es usado para determinar Ia direccién del dispositivo esclavo para la que la POU esté destinada. Finalmente, la ADU incluye una PDU. La longitud de esta PDU esta alin Imitada a 253, bytes para el protocolo estandar. RTU La ADU de RTU parece ser mucho mas simple, como se muestra en la Figura 7. fe nso Pu one (ene Sees] Figura 7. La ADU de RTU AA diferencia de la ADU de TCP/IP més compleja, esta ADU incluye solamente dos piezas de informaci6n, ademas de la PDU principal. Primero, una direccién es sada para definr para qué esclavo esta disefiada una PDU. En la mayoria de las redes, una direccién O define la direccién de "broadcast". Es decir, un maestro puede enviar un comando de salida a la direccién 0 y todos los esclavos deben procesar la solictud pero ningin esclavo debe responder. Ademas de esta direccién, un CRC es usada para asegurar la integridad de los datos. ‘Sin embargo, la realidad es que la situacién en las implementaciones mas modemas esté lejos de ser simple. Encapsulando el paquete hay un par de tiempos en silencio, es decir, pperiodos en los que no hay comunicacién en el bus. Para una velocidad de transferencia de 9,600, este tiempo es alrededor de 4 ms. El estandar define una longitud minima de silencio, Independientemente de la velocidad de transferencia, de un poco menos de 2 ms, Primero, esto tiene un inconveniente de rendimiento ya que el dispositvo debe esperar a ue el tiempo muerto se cumpla antes de que el paquete pueda ser procesado. Mas peligrosa atin, sin embargo, es laintroduccién de diferentes tecnologias usadas para transferencia serial y velocidades de transferencia mucho més répidas que cuando se introdujo el estandar. Con un cable convertidor de USB a serial, por ejemplo, usted no tiene ringin control sobre el paquete y la transferencia de datos. Las pruebas muestran que usar un cable de USB a serial con el controlador NI-VISA introduce grandes intervalos de tamanio variable en el flujo de datos y estas intervalos, periados de silencio, engafan al cédigo ‘compatible con la especificacién al creer que un mensaje se ha completado, Debido a que cel mensaje no es completado, esto por lo general conduce a un CRC no valido y al dispositivo que interpreta la ADU como alterada. ‘Ademas de los problemas con la transmisién, las tecnologias modernas de controlador abstraen comunicacin serial signficativa y generalmente requieren un mecanismo de ‘consulta desde el eédigo de la aplicacién. Por ejemplo, ni el NET Framework 4.5 SerialPort Class (nttpimsdn. microsoft. com/en-us/ibrary/system io. ports. serialpor{v=vs. 110).aspx) ni el controlador NI-VISA proporcionan un mecanismo para detectar silencio sobre una linea Serial excepto al consultar los bytes en el puerto, Esto resulta en una escala de bajo rendimiento (sila consulta es realizada demasiada lento) o alto uso del CPU (sila consulta @s realzada demasiado rapido). Un método comtin (http:/tvwen dig comvsupportkbase/kbaseresultdet!?id=773) para resolver ‘estos problemas es romper la capa de abstraccién entre la PDU de Modbus y la capa de red. Es decir, el cédigo serial interroga el paquete de la PDU de Modbus para determinar el Ccédigo de funcién, Combinado con otras datos en el paquete, la longjtud del paquete restante puede ser descubierta y usada para determinar el final del paquete. Con esta informacién, puede usarse un descanso mucho mas largo, lo que permite silencios de transmisién y puede ocurrir consulta a nivel de la aplicacién mucho mas lentamente. Se recomienda utilizar este mecanismo para un nuevo desarrollo. El cédigo que no emples esto puede experimentar un ndmero mayor de paquetes "alterados" de lo esperado. Este sto uhBiCdbokies para ofrecere una mejor experiencia de busqueda, Conazca nuestra polilca de arivacdad, (hitaimwuni cenlaa/MeeR WelAEEAEMHRba que la de RTU como &@ muestra an la Figura 8, también evita muchos de los problemas del paquete RTU. Sin embargo, tiene algunas de sus propias desventajas. Iepukwwrn comMuhite-paper8213/es! aroraa2016 bhermacidn Detallada sobre el Protecclo Modbus - National Instruments ‘Address ‘Modbus PDU Rc [0x00] oa (asc (asc (asc | cr | LF Figura 8. La ADU de ASCIL [Al resolver el problema de determinar el tamafio del paquete, a ADU de ASCII tiene un inicio y final bien definido y dnico para cada paquete, Es decir, cada paquele comienza con ¥ termina con un regreso de carra (CR) y almentacién de linea (LF). Ademas, los APIs seriales como NI-VISA y el NET Framework SerialPort Class pueden leer datos facimente fen un bifer hasta que un cardcter especifco, como CRILF, es recibido. Estas caracteristicas, hhacen que sea facil procesar la escritura de datos en la linea serial de manera eficiente en el cédigo de la aplicacién moderno. La desventaja del ADU de ASCII es que todos los datos son transferidos como caracteres hexadecimales codificados en ASCII, Es deci, en lugar de enviar un solo byte para el ‘eédigo de funcién 3, 0x03, envia los caracteres ASCII "0" y "3" 0 0x30 / 0x33. Esto hace que al pratocole sea mas legible, poro también significa que el doble de datos deben sor transferidos a través de la red en serie y que las aplicaciones que envian y reciben deben sser capaces de analizarlos valores ASCII Extender Modbus Modbus, un estandarrelativamente simple y abierto, puede ser mocificado para cumplir con las necesidades de una aplicacién determinada. Esto es mas comin para la comunicacién entre la HMly PLC PAC, ya que esta es una stuacién en la que una sola organizacién tiene el control sobre ambos extremos del protocolo. Los desarrolladores de sensores, por ejemplo, es mas probable que se apeguen al estandar escrito, ya que normalmente solo controlan la implementacién de su esclavo y es deseable la interoperabilidad. En general, no se recomienda modificar el protocolo. Esta seccién se proporciona simplemente como un reconocimianto de los mecanismos que otros han utiizado para ajustar el comportamiento del protocolo. ‘Algunos cédigos de funcién son definidos, pero el esténdar Modbus le permite desarrollar ‘cédigos de funcién adicionales. En conereto, los cédigos de funcién 1 al 64, 73 al 99 y 111 al 4127 son las cécigas piblicas que son reservados y garantizados para ser tnicos. Los ‘codigos restantes, 65 al 72 y 100 al 110, son para uso definido por el usuario. Con estos Ccédigos definidos por el usuario, usted puede usar cualquier estructura de datos. Los datos pueden incluso exceder el limite de 253 bytes estdndar para el Modbus PDU, pero toda la aplicac’on debe ser validada para asogurarse de que otras capas funcionan como se ‘esperaba cuando el PDU exceder el limite esténdar. Los cédigos de funcién por encima de 127 son reservados para respuestas de excepcion Modbus se puede ejecutar en muchas capas de la red, ademas de serial y TCP. Una implementacién (http:/jamod,sourceforge.net) potencial es UDP, ya que es ideal para el estilo de comunicacién Modbus. Modbus es un protocolo basado en mensajes en su nucleo, poor lo que la habilidad de UDP para enviar un paquele bien definido de la informacién sin ‘ninguna de informacién adicional a nivel de aplicacién, como un cardcter de inicio o longitu, hhace a Modbus extremadamente facil de implementar. En lugar de requerir una ADU adicional o reutlizar una ADU existente, los paquetes de la PDU de Modbus se pueden tenviar usando un API de UDP estandar y ser recibidos completamente formadas en el otro ‘exiremo. Aunque TCP es ventajoso para algunos protocolos por el sistema de confirmacién integrado, Modbus realiza confirmacién en la capa de aplicacién. Sin embargo, utlizando UDP de esta manera elimina el campo de identifcador de transaccién en | ADU de TCP. que libera la posibilidad de miiiples transacciones pendientes simulténeas, Por lo tanto, el ‘maestro debe ser un maestro sincrénico o el paquete UDP debe tener un identificador para ayudar al maestro a organizar las solicitudes y respuestas. Una implementacién sugerida sera usar la ADU de TCPIIP en una capa de red UDP. Por titimo, una aplicacién podria optar por modificar una ADU o usar porciones no utlizadas dde una ADU existente como TCP. Por ejemplo, TCP define un campo de 16 bits de longitua, un protocolo de 16 bits y un No. de Unidad de 8 bits. Dado que la POU de Modbus mayor es de 253 bytes, el byte alto del campo de longitud es siempre cero. Para Modbus/TCP, Este sitio uf PRA PEBtATAIGLL A Répedes sins ae et SHO “a gece ‘mite que a0 508 Serj af sar os dos bytes no utlizados (No. de Unidad el byte ato dol campo de longitud) para enviar las longitudes de dos PDUs adicionales (ver la Figura 9). Iepukwwrn comMuhite-paper8213/es! a0raa2016 hermacidn Detallada sobre el Protocolo Modbus - Nationa Instruments ee ee ee ee ove w | a [els] Boies Soe ies Figura 8. Modificacién de Ejomplo de la ADU de TCP Especifcacién del Protocolo de Aplicacién Modbus {httpswwwumodbus.crg/docs/Modbus,_ Application_Protocol_V1_1b3.paf) ¢Por qué es importante OPC UA? (http:ni.comwhite-paper!13843/en!) ‘Sobre OPC (htip:/waw-opcfoundation.org/Defaull aspx/01_abouVUA.asp2MID=AboulOPC) EtherNetvIP—CIP en Tecnologia Ethernet (hitpswinw.odva.org/Portalsi0/Library/Publicaions_ Numbered/PUBO0138R3_CIP_Adv_Tech_Series_EtherNetIP.paf) ‘Soporte Digital (http:/iwww-digi.com/supportikbaselkbaseresuitdet?id=773) Biblioteca Modbus Java (hitp:/jamod.sourceforge.net) PRODUCTOS: ‘SOPORTE ‘COMPARIA, upstnnnct cameo bites canvem poy SeneeReciettsimiconcenoaryesa) Comprar par ram de pate ants (pte comimaruasess) ape nconsopsAain sta? Sinai or {rh comidoulonsrwertes) (pire m.corimyprostslapmansil? tance Parner ingen trina convaresiesa) (hm commoners) ‘eto tacctana .coevoanpai Everest sim comioven) caro hin.canleaaes) Lega | tpsoenncmaglyPevacisad (tpn. comiepallprvacyluntadetteat) | ©2016 Natoralnstunars Coporton. Tao ls eachosresevate. | Mapa de Silo (ht: combats) Este sito uliiza cookies para ofrecere una mejor experiencia de busqueda, Conazca nuestra polilca de rivacdad, (hitodimw.ni comlecalonvaculuntedstates/us/) Iepukwwrn comMuhite-paper8213/es! AVANZANDO JUNTOS (rt:tantonk con NL (rap rattecconmtga (titond ncenitneweet) (reghamn yan. conieinosmene (tam ned comieopany 3! beta) (hep comicontactan) 1010