Modbus est un protocole de communication couramment utilisé dans les systèmes automatisés industriels, la domotique et les réseaux automatisés de petits objets (entrepôts, serres etc). Ce protocole sert également à connecter différents types d'appareils à un ordinateur de bureau. Le développement de projets tels qu'Arduino et Raspberry Pi a augmenté de manière significative l'intérêt pour les tâches liées à la robotique et à l'automatisation, assurant le gain de popularité de Modbus aussi bien auprès des particuliers que des professionnels.
Dans cet article, nous allons nous intéresser aux principales fonctionnalités des solutions logicielles et matérielles disponibles pour tester et déboguer des périphériques et des réseaux utilisant le protocole Modbus.
Si vous êtes déjà familier avec l'architecture de ce protocole, vous pouvez directement vous rendre à la rubrique description d'un logiciel Modbus. Sinon, vous trouverez ci-dessous une brève présentation de Modbus.
Modbus est un protocole couramment utilisé dans les systèmes automatisés aux niveaux inférieur et intermédiaire. Le niveau intermédiaire est celui des contrôleurs, les périphériques qui collectent les données et contrôlent le processus technologique. Le niveau inférieur est celui de l'interaction entre les capteurs et les contrôleurs ou entre les capteurs et le serveur.
La structure typique d'un système automatisé utilisant Modbus comme protocole de base est affichée ci-dessous.
L'environnement standard du protocole Modbus est le RS485/422/232. Modbus RTU ou Modbus ASCII fonctionnent avec ce type d'interfaces. Sur les réseaux TCP/IP cependant, le protocole du niveau le plus élevé est le protocole de transport TCP, et cette variante est appelée Modbus TCP. Dans cet article, nous allons nous intéresser au mode de transmission Modbus RTU.
Le protocole Modbus est implémenté grâce à une relation maître-esclave. Cela signifie que la communication est toujours initiée par un périphérique, le maître, qui envoie une requête vers un esclave (serveur) et attend une réponse. Un réseau comporte toujours un maître et de 1 à 247 esclaves.
Le maître interagit avec les périphériques esclaves avec la méthode requête-réponse. La requête contient une séquence d'octets, appelée une trame, dans laquelle le délai entre les octets est défini en fonction du débit de transfert de données et ne peut être supérieur à la durée de transmission de 1,5 octet de données. En mode RTU, les messages débutent par un intervalle silencieux d'une durée équivalente à au moins 3,5 caractères.
Une requête est envoyée sous la forme suivante :
ID - adresse du périphérique (1 octet),
FN - fonction Modbus (1 octet),
[args] - arguments de la fonction (N octets, selon la fonction),
CRC - somme de contrôle CRC-16 (2 octets).
Le format d'un message de réponse est le suivant :
Comme vous pouvez le constater, les trames de réponse et de requête présentent une structure similaire, à l'exception du champ Data, qui a un contenu différent selon la fonction exécutée.
Si la fonction requise n'est pas supportée par le périphérique esclave ou que les arguments présents dans le champ [args] sont incorrects pour ce serveur, le bit haut du champ FN de la réponse prendra pour valeur 1 et le champ Data contiendra des informations supplémentaires concernant l'erreur survenue.
Certains périphériques esclaves peuvent également avoir des registres spécifiques contenant des informations supplémentaires.
Parmi les types de registres référencés dans les périphériques Modbus, nous pouvons trouver :
| Champ | Accès | Taille | Description |
|---|---|---|---|
| Entrées distinctes | lecture seule | 1 bit | utilisées comme entrées |
| Sorties (bobines) | lecture/écriture | 1 bit | utilisées pour contrôler les entrées distinctes |
| Registres d'entrée | lecture seule | 16 bits | utilisés pour l'entrée |
| Registres de maintien | lecture/écriture | 16 bits | utilisés pour différentes choses, notamment les entrées, les sorties, les données de configuration etc. |
La description complète du protocole Modbus RTU est fournie dans son cahier des charges fonctionnel.
En mettant en place un réseau Modbus, il est important de prendre en compte le fait que le protocole permet la transmission de données depuis plusieurs périphériques qui seront reçues par un seul et même serveur ou contrôleur sur lequel un pilote Modbus est installé. Une application série peut contrôler un port de communication d'un serveur (par exemple COM1) lorsqu'il reçoit les données Modbus de plusieurs capteurs.
Malheureusement il existe une limite, car le fait d'ouvrir le port de réception dans plusieurs applications à la fois peut s'avérer relativement compliqué.
Il existe cependant une solution à ce problème. Virtual COM Port Driver d'Electronic Team permet de créer des ports RS485 virtuels et de scinder les données Modbus afin que plusieurs ports puissent les recevoir simultanément.
Vous pouvez à présent dupliquer le flux de données entrant dans un port physique vers plusieurs ports virtuels. En connectant plusieurs applications à des copies virtuelles de votre port COM1, toutes ces applications bénéficient d'un accès partagé à votre port physique.
Lors du développement et du débogage de périphériques Modbus RTU, les experts utilisent des outils logiciels et matériels spécialisés. En ce qui concerne les solutions matérielles, le plus simple consiste à utiliser un convertisseur RS485/USB. De tous les périphériques de ce type, le plus efficace est probablement le MOXA UPORT 1130/UPORT 1150. Ce périphérique simple d'utilisation ne nécessite que peu de connaissances pour être utilisé. Il existe également des solutions plus complexes telles que des convertisseurs Ethernet/RS-485 (par exemple le NPORT de MOXA).
Dans la pratique, en ce qui concerne le développement de périphériques Modbus RTU, la plupart d'entre eux utilisent la fonction esclave. Les périphériques esclaves regroupent notamment les différents capteurs, relais contrôlés, modules d'entrée/sortie etc. Il est plus rare de créer des périphériques maîtres. Dans les réseaux automatisés, la fonction maître est généralement assurée par un contrôleur, qui dispose déjà d'un module Modbus intégré, ou un système OPC Server/SCADA équipé d'un pilote Modbus.
Nous n'allons pas nous intéresser au développement du module Modbus dans cet article. La seule chose qui mérite d'être mentionnée est la bibliothèque FreeMODBUS, à partir de laquelle il est relativement simple de créer un péripérique supportant les fonctions esclaves de Modbus.
Les tests peuvent être effectués à différentes étapes du développement d'un périphérique Modbus. Les solutions logicielles et matérielles de test Modbus à utiliser sont différentes selon le niveau d'avancement du développement et le but des tests.
Durant le développement, une situation inattendue peut survenir lorsqu'un périphérique reçoit une requête et y répond (elle peut être indiquée par les LED de réception/transmission des paquets, si de tels éléments sont présents, ou détectée à l'aide d'un outil de débogage et en définissant un point de rupture) mais que les données ne sont pas affichées dans le terminal ou dans un autre programme spécialisé. Dans ce cas, vous devrez utiliser un renifleur de port série dédié.
Serial Port Tester est l'un des meilleurs logiciels de surveillance Modbus actuellement disponibles sur le marché. Cette solution Modbus peut facilement lire et enregistrer toutes les données série transitant par les ports COM du système. Les fonctionnalités avancées de l'application permettent de capturer les données en temps réel afin d'offrir la possibilité au développeur de régler tous les problèmes dès leur détection.
COM Port Tester peut fonctionner en mode terminal émulant le transfert de données d'un port COM surveillé vers le périphérique qui y est inséré. Cette option s'avère relativement pratique lorsque vous testez une communication Modbus car elle permet d'observer le comportement d'un périphérique lorsqu'il reçoit une commande et des données spécifiques.
Un logiciel dédié peut s'avérer relativement pratique lorsque vous devez non seulement vérifier si un périphérique fonctionne (s'il répond correctement aux requêtes) mais également détecter d'éventuels problèmes.
Un testeur Modbus vous permet d'enregistrer les flux de données entrant et sortant ainsi que d'afficher les données capturées en différents modes de vue (dans un tableau, en ligne, en vrac, dans un terminal) pour pouvoir les comparer et les analyser plus facilement.
Il y a bien plus de spécialistes du dépannage de systèmes automatisés et d'appareils utilisant le protocole Modbus que de personnes créant et développant ces appareils. Les fonctionnalités du logiciel Modbus seront légèrement différentes selon les spécificités de la tâche à effectuer.
S'il est nécessaire de connecter un contrôleur à un seul périphérique esclave, vous pouvez établir une communication série en utilisant un convertisseur RS-485/USB, un PC et un terminal ou un logiciel spécialisé. Dans ce cas, il est inutile de tester sur une longue durée puis d'analyser les nombreux fichiers log obtenus. La logique de fonctionnement et l'ensemble des outils utilisés seront les mêmes que ceux utilisés durant la phase de test lors du développement du périphérique esclave.
Si vous avez déjà un réseau de périphériques fonctionnel, il peut être nécessaire d'effectuer les tâches suivantes :
Pour mener ces tâches à bien, vous devrez utiliser un terminal capable de créer une liste de requêtes ou un outil spécialisé tel que Modbus Poll, un simulateur Modbus maître permettant de surveiller plusieurs esclaves Modbus et/ou plusieurs types de données à la fois.
Certains périphériques Modbus peuvent avoir des paramètres d'interface RS-485 particuliers (le nombre de bits de données, la parité, le nombre de bits d'arrêt). Les périphériques ayant des paramètres différents ne peuvent être utilisés avec le même maître sur le même réseau. L'outil le plus pratique pour tester et configurer de tels périphériques est un programme de terminal supportant le passage rapide de paramètres de port prédéfinis à d'autres ou capable de fonctionner sur plusieurs lignes à la fois.
Un autre défi consiste à établir l'échange de données avec un périphérique fonctionnant sur un protocole différent des spécifications Modbus RTU standard. Par exemple, le protocole de l'esclave peut être similaire à Modbus (mêmes délais d'expiration, structure des paquets etc.) mais utiliser certaines fonctions n'étant pas incluses dans la norme.
Dans ce cas, il peut s'avérer être une bonne idée d'utiliser Modbus Poll, qui permet de formuler des requêtes arbitraires, ou un terminal proposant des fonctionnalités similaires.
Le système SCADA standard n'est pas efficace pour utiliser de tels périphériques, et la communication avec l'équipement est établie à l'aide d'un serveur OPC spécial.
