Introduccion
Si solo tiene un martillo como herramienta, cada problema comienza a parecerse a un clavo.
Abraham Maslow
El protocolo Modbus es conocido tanto por los lectores Habr como por los lectores hicktime. Se han dedicado muchas publicaciones a su aplicación, que son difíciles de enumerar porque hay muchas de ellas, y de vez en cuando aparecen nuevos artículos aquí y allá.
La popularidad de este protocolo se debe a su apertura y simplicidad. El alcance de la aplicación es lo suficientemente amplio: desde sistemas profesionales de automatización industrial hasta proyectos aficionados de bricolaje de sistemas de control distribuido, casas "inteligentes", etc. Este protocolo también fue elegido por mí cuando mi equipo se involucró en la creación de software para el simulador de trenes. El protocolo Modbus RTU en la interfaz física RS485 se usa en este simulador para proporcionar datos a la computadora de control desde los controles montados en la consola del conductor (¡no piense que Modbus se usa en material rodante real!).
No vale la pena hablar sobre las dificultades involucradas en la configuración de software que interactúa con una red de controladores que controlan los equipos. Especialmente cuando parte de los dispositivos ya existe en el hierro, y la otra parte está en proceso de desarrollo y fabricación. En este caso, se requiere que el software de nivel superior se escriba teniendo en cuenta su interacción con este hardware. Y es aconsejable escribirlo de tal manera que cree una versión funcional del sistema de inmediato, sin el uso de "muletas" que siempre son difíciles de limpiar del código.
"Necesitamos escribir software cuando los prototipos de trabajo de todo el hierro estén listos", dices, y tendrás razón, pero ... ja, ja, esto rara vez sucede en el mundo real. Y aquí los emuladores de software vienen en nuestra ayuda.
1. Brevemente sobre Modbus RTU
No hablaré en detalle sobre el protocolo. Aquellos que estén interesados en los detalles pueden usar la búsqueda: el protocolo está abierto, su especificación oficial y mucha información está disponible en la red. Solo puedo decir que en Modbus RTU describe el formato binario de los datos transmitidos y utiliza el cable de par trenzado estándar RS485 como medio de transmisión. RS232 también se puede usar si la red tiene un transmisor y un receptor, o RS422 para la transmisión de datos unidireccional.
Nos interesará RS485, que es una interfaz semidúplex, que permite que solo un dispositivo transmita datos a la vez. El arbitraje del bus en Modbus se lleva a cabo debido a la resistencia del intervalo de silencio obligatorio de 3.5 caracteres a una velocidad de transmisión dada. Cada mensaje debe comenzar y terminar con un intervalo de silencio. Hay un dispositivo maestro en la red y varios esclavos (hasta 31 en un segmento de red, sin el uso de repetidores). Cada dispositivo esclavo tiene una identificación de identificación única (1 a 31). La transmisión de datos por esclavos se lleva a cabo solo si el maestro envió una solicitud para recibir datos de este dispositivo.
Una solicitud típica de asistente se ve así
| ID | Código de función | Dirección de datos | Cantidad de datos (2 bytes) | Datos | CRC16 |
CRC16 se utiliza para controlar la integridad de los datos transmitidos. Modus utiliza la notación de representación de datos Big Endian: para valores de 2 bytes, el byte más significativo dentro del mensaje es lo primero). El protocolo utiliza cuatro tipos de datos:
- Bobinas - salidas discretas (1 bit) lectura / escritura
- Entradas discretas: entradas discretas de solo lectura (1 bit)
- Registros de retención: registros de salida (2 bytes) disponibles para lectura / escritura
- Registros de entrada: registros de entrada (2 bytes) disponibles para leer
En respuesta a la solicitud, el esclavo envía datos en el siguiente formato
| ID | Código de función | La cantidad de datos en bytes. | Datos | CRC16 |
Un mensaje recibido del maestro ingresa al búfer de recepción de todos los dispositivos. Sin embargo, si el primer byte del búfer de recepción no coincide con la ID del dispositivo, ignora los datos recibidos, borrando el búfer de recepción. Si el mensaje está destinado a este dispositivo, forma una respuesta y, después de mantener el intervalo de silencio, lo envía al maestro.
Como dicen, simple, pero con gusto. Puede leer más sobre todo esto en la
especificación del protocolo oficial .
Lea sobre los métodos para implementar el protocolo en la interfaz en serie
aquí . No nos reunimos aquí para esto.
Al desarrollar software de nivel superior (maestro implementado sobre la base de una PC, por ejemplo) para dicha red, sería bueno tener un conjunto de herramientas de software que permitan implementar dicho concepto
El significado de este esquema es el siguiente. Supongamos que tenemos una parte de los dispositivos incluidos en la red futura. O hasta ahora no hay tales dispositivos. Pero existe un deseo ardiente de escribir software para el nivel superior de administración, para depurarlo, de modo que cuando la red todavía se implemente en hardware no tengamos que reescribir nada. Para hacer esto, tendrá que usar un medio de transmisión física, para lo cual usamos un dispositivo similar a este
Uno de los adaptadores se utiliza para conectar el software del asistente desarrollado. Otro es para conectar un emulador de una futura red de esclavos. A la rama con un conector blanco, conectamos esa parte de la red que ya está implementada en el hardware. Por lo tanto, tenemos la oportunidad de trabajar con calma con el protocolo de comunicación estándar, introduciendo gradualmente equipos reales en funcionamiento. Además, al entregar el objeto al cliente, no estamos privados de la oportunidad de modificar su software en un entorno de laboratorio cómodo sin acceso al objeto. QSlave en el diagrama es la misma parte de la red emulada por el software. Naturalmente, debe escribir el software apropiado, que fue realizado por el autor.
2. QSlave - emulación de red esclava
QSlave es un emulador de red modbus RTU multiplataforma abierto. Puede obtenerlo bajo la licencia GPL v2.0 en Github en el enlace de arriba.
La aplicación está desarrollada en C ++ usando el marco Qt. Qt, en términos generales,
tiene bibliotecas para trabajar con Modbus , pero los detalles de la tarea: simular una red de esclavos en lugar de un solo esclavo, llevaron al hecho de que las bibliotecas integradas de Qt para Modbus no se usaron aquí. Para procesar los datos recibidos del puerto serie virtual, se creó una biblioteca modbus autoescrita. El código de esta biblioteca se implementa como un proyecto separado, es completamente independiente de la interfaz de usuario y se puede usar para obtener conciencia de las simulaciones de software con una funcionalidad más avanzada. Debido al hecho de que la emulación Modbus está separada de la interfaz de usuario, la red se configura mediante archivos de configuración. Se eligió el formato XML (a menudo lo usamos en nuestros proyectos). Una configuración de muestra
está disponible en el código del proyecto . Un conjunto de configuraciones consta de un archivo principal con la extensión * .net, que se ve así
ejemplo.net<?xml version="1.0" encoding="UTF-8" ?> <Config> <Slave> <Description>Traffic light</Description> <id>1</id> <config>traffic-light</config> </Slave> </Config>
y archivos de configuración XML para cada uno de los esclavos
traffic-light.xml <?xml version="1.0" encoding="UTF-8" ?> <Config> <Coil> <address>16</address> <description>Red signal</description> <value>0</value> </Coil> <Coil> <address>17</address> <description>Yellow signal</description> <value>0</value> </Coil> <Coil> <address>18</address> <description>Green signal</description> <value>0</value> </Coil> <DiscreteInput> <address>0</address> <description>Ready</description> <value>1</value> </DiscreteInput> <HoldingRegister> <address>5</address> <description>Signal activity time</description> <value>15</value> </HoldingRegister> <InputRegister> <address>2</address> <description>Signals count</description> <value>3</value> </InputRegister> </Config>
El último archivo contiene una descripción de todos los datos disponibles en el dispositivo. Para descargar la configuración, debe abrir el archivo * .net desde el menú del programa QSlave (Archivo → Abrir configuración). Todos los archivos de configuración deben estar en el mismo directorio. La configuración de ejemplo describe una red desde un dispositivo esclavo, un semáforo virtual, cuyas salidas discretas describen las señales, una entrada digital indica un bit del dispositivo listo para funcionar (Listo), el registro de entrada informa el número de semáforos y el registro de salida establece el tiempo durante el cual está encendido Cada una de las señales.
Naturalmente, este simulador no simula la lógica interna del dispositivo. Solo le permite establecer los valores de las celdas de memoria disponibles para el maestro. Cualquiera de los valores se puede establecer a su discreción editando la celda correspondiente en la tabla.
Para toda su simplicidad, este software nos ayuda a trabajar en el software del simulador (que ya ha sido comisionado) sin salir del laboratorio.
Pero nadie dice que no se puede crear un emulador más avanzado que simule el funcionamiento de los dispositivos de red virtuales. Para crearlo, puede usar el código de la biblioteca modbus disponible en el paquete QSlave.
3. QMaster - emulación del dispositivo maestro
Para crear esclavos, depurar su firmware, necesita una simulación de asistente. Hay varios emuladores abiertos, como, por ejemplo,
QModbus . Lo usamos en nuestro trabajo, hasta que decidimos aumentar la velocidad de transferencia de datos a 250 kBit / s. QModbus no permite esto. Fue posible reconstruirlo desde las fuentes para Linux, pero nuestros ingenieros electrónicos están sentados en Windows, y donde el ensamblaje no fue por varias razones. Resultó que esta aplicación está escrita en Qt 4, utiliza una biblioteca libmodbus de terceros. Quería tener una solución multiplataforma en Qt5, especialmente porque Qt5 ya funciona con Modbus fuera de la caja. Por lo tanto, su análogo fue escrito usando la pila de la biblioteca Qt Modbus -
QMaster . También está disponible en Github en las mismas condiciones.
Conclusión
En conclusión, diré que trabajo (en el trabajo) principalmente en proyectos cerrados. Sin embargo, las herramientas descritas las desarrollé personalmente por iniciativa propia en mi tiempo libre. Además, en la versión de Windows, están estáticamente vinculados con el código Qt GPL, por lo que debo transmitirlos a la comunidad en las mismas condiciones que Qt recibió. Además, estas herramientas pueden ser útiles para el lector.
Gracias por su atencion!