Présentation
Si vous n'avez qu'un marteau comme outil, chaque problème commence à ressembler à un clou.
Abraham Maslow
Le protocole Modbus est bien connu des lecteurs Habr et des lecteurs hicktime. De nombreuses publications ont été consacrées à son application, difficiles à répertorier car elles sont nombreuses et de temps en temps de nouveaux articles apparaissent ici et là.
La popularité de ce protocole est due à son ouverture et sa simplicité. Le champ d'application est assez large: des systèmes d'automatisation industrielle professionnels aux projets de bricolage amateur de systèmes de contrôle distribués, de maisons «intelligentes», etc. Ce protocole a également été choisi par moi lorsque mon équipe s'est engagée dans la création d'un logiciel pour le simulateur de train. Le protocole Modbus RTU sur l'interface physique RS485 est utilisé sur ce simulateur pour fournir à l'ordinateur de commande des données provenant de commandes montées sur la console du conducteur (ne pensez pas que Modbus est utilisé sur du matériel roulant réel!).
Cela ne vaut pas la peine de parler des difficultés liées à la mise en place d'un logiciel qui interagit avec un réseau de contrôleurs qui contrôlent les équipements. Surtout quand une partie des appareils existe déjà dans le fer et que l'autre partie est en cours de développement et de fabrication. Dans ce cas, un logiciel de niveau supérieur doit être écrit en tenant compte de son interaction avec ces matériels. Et il est conseillé de l'écrire de manière à créer immédiatement une version de travail du système, sans utiliser de «béquilles» qui sont toujours difficiles à nettoyer du code.
«Vous devez écrire des logiciels lorsque les prototypes de travail de tout le matériel sont prêts», dites-vous, et vous aurez raison, mais ... ha ha ha, cela arrive rarement dans le monde réel. Et ici, les émulateurs de logiciels viennent à notre aide.
1. En bref sur Modbus RTU
Je ne parlerai pas en détail du protocole. Ceux qui sont intéressés par les détails peuvent utiliser la recherche - le protocole est ouvert, ses spécifications officielles et beaucoup d'informations sont disponibles sur le réseau. Je peux seulement dire que dans Modbus RTU, il décrit le format binaire des données transmises et utilise le câble à paire torsadée standard RS485 comme moyen de transmission. RS232 peut également être utilisé si le réseau possède un émetteur et un récepteur, ou RS422 pour la transmission de données unidirectionnelle.
Nous serons intéressés par RS485, qui est une interface semi-duplex, qui permet à un seul appareil de transmettre des données à la fois. L'arbitrage du bus dans Modbus est effectué en raison de l'endurance de l'intervalle de silence obligatoire de 3,5 caractères à une vitesse de transmission donnée. Chaque message doit commencer et se terminer par un intervalle de silence. Il y a un appareil maître dans le réseau et plusieurs esclaves (jusqu'à 31 dans un segment de réseau, sans utiliser de répéteurs). Chaque périphérique esclave a un identifiant unique (1 à 31). La transmission de données par les esclaves n'est effectuée que si le maître a envoyé une demande de réception de données de cet appareil.
Une demande d'assistant typique ressemble à ceci
| Identifiant | Code de fonction | Adresse de données | Quantité de données (2 octets) | Les données | CRC16 |
CRC16 est utilisé pour contrôler l'intégrité des données transmises. Modus utilise la notation de représentation des données Big Endian: pour les valeurs de 2 octets, l'octet le plus significatif à l'intérieur du message vient en premier). Le protocole utilise quatre types de données:
- Bobines - sorties discrètes (1 bit) lecture / écriture
- Entrées TOR - entrées TOR en lecture seule (1 bit)
- Registres de maintien - registres de sortie (2 octets) disponibles pour lecture / écriture
- Registres d'entrée - registres d'entrée (2 octets) disponibles pour la lecture
En réponse à la demande, l'esclave envoie des données au format suivant
| Identifiant | Code de fonction | La quantité de données en octets | Les données | CRC16 |
Un message reçu du maître entre dans le tampon de réception de tous les appareils. Cependant, si le premier octet du tampon de réception ne correspond pas à l'ID de périphérique, il ignore les données reçues, effaçant le tampon de réception. Si le message est destiné à cet appareil, il forme alors une réponse et, après avoir maintenu l'intervalle de silence, l'envoie au maître.
Comme on dit, simple mais avec goût. Vous pouvez en savoir plus sur tout cela dans la
spécification officielle du protocole .
Lisez les méthodes d'implémentation du protocole sur l'interface série
ici . Nous ne nous sommes pas réunis ici pour cela.
Lors du développement d'un logiciel de haut niveau (maître implémenté sur la base d'un PC par exemple) pour un tel réseau, il serait bien d'avoir un ensemble d'outils logiciels permettant de mettre en œuvre un tel concept
La signification de ce schéma est la suivante. Supposons que nous ayons une partie des appareils inclus dans le futur réseau. Ou jusqu'à présent, il n'y a pas de tels appareils. Mais il y a un désir ardent d'écrire des logiciels pour le plus haut niveau de gestion, de les déboguer, de sorte que lorsque le réseau est toujours implémenté en matériel, nous n'avons rien à réécrire. Pour ce faire, vous devrez utiliser un support de transmission physique, pour lequel nous utilisons un appareil similaire à celui-ci
L'un des adaptateurs est utilisé pour connecter le logiciel de l'assistant développé. Un autre est de connecter un émulateur d'un futur réseau d'esclaves. À la branche avec un connecteur blanc, nous connectons cette partie du réseau qui est déjà implémentée dans le matériel. Ainsi, nous avons l'opportunité de travailler sereinement avec le protocole de communication standard, en introduisant progressivement de vrais équipements en fonctionnement. De plus, en donnant l'objet au client, nous ne sommes pas privés de la possibilité de modifier son logiciel dans un environnement de laboratoire confortable sans accès à l'objet. QSlave dans le diagramme est exactement la même partie du réseau émulée par le logiciel. Naturellement, vous devez écrire le logiciel approprié, ce qui a été fait par l'auteur.
2. QSlave - émulation de réseau esclave
QSlave est un émulateur de réseau modbus RTU multiplateforme ouvert. Vous pouvez l'obtenir sous la licence GPL v2.0 sur Github au lien ci-dessus.
L'application est développée en C ++ en utilisant le framework Qt. Qt, de manière générale,
possède des bibliothèques pour travailler avec Modbus , mais les spécificités de la tâche - simuler un réseau d'esclaves plutôt qu'un seul esclave, ont conduit au fait que les bibliothèques Qt intégrées pour Modbus n'ont pas été utilisées ici. Pour traiter les données reçues du port série virtuel, une bibliothèque Modbus auto-écrite a été créée. Le code de cette bibliothèque est implémenté comme un projet séparé, est complètement indépendant de l'interface utilisateur et peut être utilisé pour la prise de conscience de simulations logicielles avec des fonctionnalités plus avancées. Du fait que l'émulation Modbus est détachée de l'interface utilisateur, le réseau est configuré à l'aide de fichiers de configuration. Le format XML a été choisi (nous l'utilisons souvent dans nos projets). Un exemple de configuration
est disponible dans le code du projet . Un ensemble de configurations se compose d'un fichier principal avec l'extension * .net, qui ressemble à ceci
example.net<?xml version="1.0" encoding="UTF-8" ?> <Config> <Slave> <Description>Traffic light</Description> <id>1</id> <config>traffic-light</config> </Slave> </Config>
et des fichiers de configuration XML pour chacun des esclaves
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>
Le dernier fichier contient une description de toutes les données disponibles sur l'appareil. Pour télécharger la configuration, vous devez ouvrir le fichier * .net depuis le menu du programme QSlave (Fichier → Ouvrir la configuration). Tous les fichiers de configuration doivent se trouver dans le même répertoire. L'exemple de configuration décrit un réseau à partir d'un périphérique esclave, un feu de circulation virtuel, dont les sorties discrètes décrivent les signaux, une entrée numérique indique un bit du périphérique prêt à fonctionner (prêt), le registre d'entrée indique le nombre de signaux de trafic et le registre de sortie définit la durée pendant laquelle il est allumé chacun des signaux.
Naturellement, ce simulateur ne simule pas la logique interne de l'appareil. Il vous permet uniquement de définir les valeurs des cellules de mémoire disponibles pour le maître. N'importe laquelle des valeurs peut être définie à votre discrétion en modifiant la cellule correspondante dans le tableau.
Pour toute sa simplicité, ce logiciel nous aide à travailler sur le logiciel du simulateur (qui a déjà été mis en service) sans quitter le laboratoire.
Mais personne ne dit que vous ne pouvez pas créer un émulateur plus avancé qui simule le fonctionnement des périphériques réseau virtuels. Pour le créer, vous pouvez utiliser le code de bibliothèque modbus disponible dans le package QSlave.
3. QMaster - émulation de l'appareil maître
Pour créer des esclaves, déboguer leur firmware, vous avez besoin d'une simulation d'assistant. Il existe un certain nombre d'émulateurs ouverts, tels que, par exemple,
QModbus . Nous l'avons utilisé dans notre travail, jusqu'à ce que nous décidions d'augmenter le taux de transfert de données à 250 kBit / s. QModbus ne le permet pas. Il a été possible de le reconstruire à partir des sources pour Linux, mais nos ingénieurs électroniques sont assis sur Windows, et où l'assemblage n'est pas allé pour plusieurs raisons. Il s'est avéré que cette application est écrite en Qt 4, utilise une bibliothèque libmodbus tierce. Je voulais avoir une solution multiplateforme sur Qt5, d'autant plus que Qt5 fonctionne déjà avec Modbus prêt à l'emploi. Par conséquent, son analogue a été écrit à l'aide de la pile de bibliothèques Qt Modbus -
QMaster . Il est également disponible sur Github dans les mêmes conditions.
Conclusion
En conclusion, je dirai que je travaille (au travail) principalement sur des projets clôturés. Cependant, les outils décrits ont été développés par moi personnellement de ma propre initiative pendant mon temps libre. De plus, dans la version Windows, ils sont statiquement liés au code Qt GPL, je dois donc les transmettre à la communauté dans les mêmes conditions que Qt reçues. De plus, ces outils peuvent être utiles au lecteur.
Merci de votre attention!