Modbus RTU, ASCII et TCP avec SerialTool

Dernière mise à jour le 9 mars 2026 par Oliver Reed

Qu’est-ce que Modbus

Le protocole Modbus est un protocole de communication série créé en 1979 par Modicon® (société aujourd’hui intégrée au groupe Schneider Electric) afin de permettre la communication entre ses automates programmables (PLC). Il est devenu un standard de facto dans les communications industrielles et figure aujourd’hui parmi les protocoles de connexion les plus utilisés au monde pour les équipements électroniques industriels. Modbus est un protocole libre de droits dont les spécifications sont publiées sur le site de The Modbus Organization.

En termes simples, il s’agit d’une méthode utilisée pour transmettre des informations sur des lignes série entre des appareils électroniques. L’appareil qui demande les informations est appelé Client Modbus, tandis que les appareils qui les fournissent sont appelés Serveurs Modbus. Dans un réseau Modbus standard, il existe un client et jusqu’à 247 serveurs, chacun avec une adresse serveur unique de 1 à 247. Le client peut également écrire des informations sur les serveurs.

---

Initialement destiné à un usage industriel, ce protocole a ensuite été adopté dans d’autres secteurs et est devenu l’un des plus répandus. Aujourd’hui encore, malgré plus de 40 ans d’existence, on le retrouve dans de nombreux équipements comme les panneaux opérateur, les PLC, la domotique et même des dispositifs simples comme Arduino.

Transmission Modbus RTU et ASCII via liaison série

Lors de la création du protocole, la communication était conçue pour fonctionner via un port série, et c’est pour cette raison qu’elle a été implémentée dans SerialTool. Modbus est souvent utilisé pour relier un ordinateur de supervision à une unité terminale distante (RTU) dans les systèmes SCADA (Supervisory Control and Data Acquisition). Selon le format utilisé pour transmettre les données, le protocole se divise en :

• MODBUS RTU - les données sont transmises au format hexadécimal.
• MODBUS ASCII - les données sont transmises au format ASCII.

Le contrôle d’erreur diffère dans les deux cas : en MODBUS RTU, on utilise un CRC (Cyclic Redundancy Check) ajouté aux commandes, tandis qu’en MODBUS ASCII on utilise un LRC (Longitudinal Redundancy Check), également envoyé après les commandes.

Transmission Modbus TCP

En 1999, « Modbus TCP » a été développé, un standard destiné aux réseaux utilisant la suite de protocoles TCP/IP : en pratique, il s’agit d’une version série RTU de Modbus construite sur TCP/IP, ce qui permet les communications sur des réseaux Internet/intranet. Ces dernières années, la version TCP/IP est de plus en plus utilisée car elle est Open Source, simple à implémenter, peu coûteuse à développer et nécessite très peu de support matériel.

Le contrôle d’erreur diffère dans les deux cas : en MODBUS RTU, on utilise un CRC (Cyclic Redundancy Check) ajouté aux commandes, tandis qu’en MODBUS ASCII on utilise un LRC (Longitudinal Redundancy Check), également envoyé après les commandes.

Le protocole Modbus TCP/IP utilise un codage binaire des données et le mécanisme de détection d’erreurs TCP/IP. Contrairement au Modbus série, la version TCP/IP est orientée connexion et permet des connexions simultanées vers le même esclave ou vers plusieurs équipements. Modbus TCP/IP utilise lui aussi le paradigme maître-esclave ; cette communication s’appuie en outre sur quatre types de messages.

Modbus se situe au niveau 7 de la pile ISO/OSI (couche application), en définissant le formatage des messages, appelé framing, ainsi que le mode de transmission des données et des fonctions de contrôle. La communication s’effectue selon le paradigme client-serveur. Le protocole définit une Protocol Data Unit (PDU) indépendante de la couche de communication sous-jacente. L’Application Data Unit (ADU) ajoute des champs supplémentaires pour l’adressage et le contrôle d’erreur.

Client Modbus SerialTool (Master / Polling)

SerialTool est un client Modbus RTU, ASCII et TCP avec polling, scan des registres, surveillance du trafic et graphiques en temps réel pour les tests et le débogage des équipements industriels.

Le client Modbus permet de se connecter à un équipement Modbus Slave/server via le port série (RTU ou ASCII) ou le réseau (TCP sur IPv4 ou IPv6), de lire et d’écrire des données à l’aide des fonctions Modbus standard et de créer un équipement Modbus avec sa propre cartographie sur lequel un polling planifié peut être exécuté.
À l’intérieur du dispositif prototype, il est possible d’ajouter des structures Modbus (Discrete Output Coils, Discrete Input Contacts, Analog Input Register, Analog Output Holding Register) et d’enregistrer l’équipement afin de pouvoir le recharger lorsque cela est nécessaire. Le dispositif prototype Modbus peut également être exporté aux formats Texte, CSV ou PDF afin d’être partagé de façon simple et intuitive.
Une fois un équipement avec la cartographie correcte créé, il est possible d’afficher des graphiques en temps réel avec les valeurs lues directement depuis l’équipement Slave via un polling planifié.
SerialTool permet également de visualiser le trafic Modbus (série et TCP) dans un terminal dédié au trafic généré et reçu. Le terminal avancé prend en charge l’export des données ainsi que le filtrage en temps réel des données entrantes et sortantes.
SerialTool permet aussi de balayer l’équipement Slave distant grâce à la fonction Modbus Scanner. En définissant les filtres appropriés, il est possible de tenter de cartographier l’équipement distant (Modbus Slave) même sans connaître les registres actuellement pris en charge. La fonction Modbus Scanner est particulièrement utile lorsque l’on souhaite explorer un équipement dont les caractéristiques sont inconnues ou seulement partiellement connues.

Voici l’écran principal du module Modbus de SerialTool :

L’écran principal met en évidence les fonctions clés de SerialTool et du client Modbus (Master).

Client Modbus SerialTool (Master / Polling)

Sur la partie gauche de l’écran, vous pouvez choisir le mode de connexion série ou TCP :

Comme indiqué ci-dessus, le protocole Modbus série se divise en deux types : RTU et ASCII. Pour communiquer correctement avec l’équipement distant, dans le cas d’une connexion série, il est indispensable de connaître le type de protocole Modbus pris en charge par l’équipement Slave.

La connexion ModBus TCP, quant à elle, prend en charge IPv4 et IPv6. Pour configurer la connexion Modbus via TCP, il est nécessaire de définir l’IP de l’esclave et le port distant auquel se connecter.

Sur l’écran de connexion, deux paramètres concernent le délai de réponse que l’équipement Modbus Slave doit fournir.
Un délai de réponse générique (Response Timeout), au-delà duquel le client (Master) cesse d’attendre la réponse du slave, ainsi qu’un délai calculé à partir du dernier octet reçu du Slave.

Émulation Modbus ENRON/Daniel

Parmi les paramètres de connexion figure l’émulation ENRON/Daniel (souvent appelée simplement Enron Modbus ou Daniels Modbus), qui renvoie à une variante spécifique du protocole de communication Modbus standard.
Elle a été développée à l’origine par Enron Corporation et largement implémentée dans les flow computers de Daniel Measurement and Control. Au fil du temps, elle est devenue un standard de facto pour la mesure électronique des fluides (EFM), en particulier dans le secteur Oil & Gas.

L’activation de l’émulation ENRON/Daniel sur un équipement modifie le comportement de Modbus afin de prendre en charge les caractéristiques clés suivantes :

• 1. Gestion des données 32 bits dans un seul registre : Il s’agit de la différence technique la plus importante. En Standard Modbus, les registres font 16 bits (2 octets) et il faut lire deux registres pour obtenir une valeur 32 bits. En Enron Modbus, les valeurs 32 bits sont mappées dans un seul registre (4 octets par registre).
• 2. Cartographie d’adresses spécifique : Des plages prédéfinies sont utilisées pour les données 32 bits. La série 5000 (par exemple 45001 - 45999) est destinée aux Long Integers, tandis que la série 7000 (par exemple 47001 - 47999) est destinée aux Floating Points.
• 3. Données historiques et événements : Elle prend en charge des commandes spéciales pour extraire des historiques et des archives d’alarmes, contrairement au Modbus standard conçu presque exclusivement pour la lecture en temps réel.
• 4. Pas d’offset : L’adresse demandée correspond exactement au numéro du registre, ce qui élimine le classique « offset +1 » propre au Modbus standard.

En résumé : Cette émulation est essentielle pour éviter les erreurs de communication (désalignement des octets) lors de l’interface avec des équipements qui transmettent des données 32 bits natives dans le secteur Oil & Gas.

---

Fonctions du client Modbus

Dans la partie centrale de l’écran, on trouve les fonctions Modbus prises en charge par SerialTool.

Les fonctions du client ModBus peuvent être résumées dans le tableau suivant.

Code fonction	Action	Nom de table / Description
0x01	Lire	Discrete Output Coils
0x02	Lire	Discrete Input Contacts
0x03	Lire	Analog Output Holding Register
0x04	Lire	Analog Input Registers
0x05	Écriture simple	Discrete Output Coil
0x06	Écriture simple	Analog Output Holding Register
0x07	Lire	Exception Status
0x08	Diagnostic	Diagnostic (Serial Line only)
0x0B (dec 11)	Lire	Comm Event Counter (Serial Line only)
0x0F (dec 15)	Écriture multiple	Discrete Output Coils
0x10 (dec 16)	Écriture multiple	Analog Output Holding Registers
0x11 (dec 17)	Rapport	Server ID (Serial Line only)
0x16 (dec 22)	Écriture masquée	Holding Register
0x17 (dec 23)	Lecture/Écriture multiple	Holding Registers
0x2B / 0x0E (dec 43 / 14)	Lire	Device Identification

---

Structures de données Modbus

Les informations sont stockées dans l’équipement Server dans quatre tables différentes. Deux tables stockent des valeurs discrètes on/off (coils) et deux stockent des valeurs numériques (registers). Les coils et les registers disposent chacun d’une table en lecture seule et d’une table en lecture/écriture. Chaque table contient 9999 valeurs. Chaque coil ou contact fait 1 bit et possède une adresse de données comprise entre 0000 et 270E. Chaque register vaut 1 mot = 16 bits = 2 octets et possède également une adresse de données comprise entre 0000 et 270E.

Numéros des coils/registers	Adresses de données	Type	Nom de table
1-9999	0x0000 to 0x270E	Lecture/Écriture	Discrete Output Coils
10001-19999	0x0000 to 0x270E	Lecture seule	Discrete Input Contacts
30001-39999	0x0000 to 0x270E	Lecture seule	Analog Input Register
40001-49999	0x0000 to 0x270E	Lecture/Écriture	Analog Output Holding Register

---

Équipement Modbus

SerialTool permet de créer un équipement Modbus Slave représentant la cartographie des registres de l’équipement Slave auquel vous souhaitez vous connecter. Cette cartographie est très importante car elle permet d’afficher, dans une table locale, les valeurs présentes sur l’équipement slave distant.

Fonctions du client Modbus

Depuis la barre de fonctions, il est possible de charger un équipement précédemment créé avec la fonction "Load Device", d’enregistrer l’équipement courant avec "Save Device" et d’ajouter des registres individuels avec "Add Item" ou plusieurs registres avec "Add Items" à la cartographie de l’équipement.

Une fois la cartographie de l’équipement Modbus Slave créée, SerialTool permet de l’enregistrer pour une utilisation ultérieure ou d’exporter son contenu au format CSV, Texte ou PDF pour le partager et le traiter avec des tiers. L’image suivante montre un exemple d’export de la cartographie d’un équipement Modbus Slave :

Vous pouvez télécharger le PDF via ce lien.

Polling Modbus

La création d’un équipement Modbus Slave permet d’effectuer du polling, c’est-à-dire une lecture planifiée de certains registres de l’équipement slave auquel vous êtes connecté.
Pour cela, il faut d’abord créer et cartographier le Slave, puis ajouter le ou les registres pour lesquels vous souhaitez effectuer le polling, comme illustré dans la figure suivante :

Une fois qu’un ou plusieurs éléments ont été ajoutés au polling, il est possible de démarrer le polling des éléments liés à la liste de polling.

Accès aux fonctions Modbus

Le client Modbus SerialTool (Master/Polling) est conçu pour exécuter des fonctions selon trois modes :

• "Execute from Device Table" - Exécute la fonction Modbus en se basant sur la cartographie de l’équipement.
• "Execute Function" - Exécute directement la fonction Modbus et affiche le résultat dans la fenêtre de log.
• "Send Raw Data" - Envoie une requête directe formée d’octets hexadécimaux et attend la réponse.

Execute from Device Table

Ce mode exécute la fonction Modbus sélectionnée en utilisant directement la table de l’équipement chargée ou créée localement. L’utilisateur peut sélectionner le type de référence Modbus, par exemple Coils, Discrete Inputs, Holding Registers ou Input Registers, choisir l’adresse de départ et le nombre d’éléments à lire ou à écrire, puis envoyer la commande au slave en un seul clic.
Le principal avantage de ce mode est que le résultat est reporté immédiatement dans la cartographie de l’équipement, en mettant à jour les valeurs affichées dans la table locale. Il est ainsi possible d’obtenir une représentation ordonnée et persistante de l’état de l’équipement distant, utile aussi bien pendant les tests que lors des activités de supervision et de maintenance.
Lorsque la commande concerne une fonction d’écriture, SerialTool permet de préparer facilement les données à transmettre en choisissant le type de donnée, le format d’affichage et le contenu à écrire dans les registres sélectionnés. Ce mode est donc particulièrement adapté lorsque l’on souhaite travailler directement sur la structure logique de l’équipement Modbus.

Execute Function

Le mode Execute Function permet d’exécuter une fonction Modbus en la sélectionnant directement dans la liste des codes de fonction disponibles, comme la lecture de coils, la lecture de discrete inputs, la lecture de holding registers, la lecture de input registers, l’écriture simple ou multiple et d’autres fonctions prises en charge par le protocole.
Dans ce cas, l’opération ne se limite pas à l’affichage dans la cartographie de l’équipement, car le résultat est reporté dans la zone de log de l’application. Cette approche est particulièrement utile lorsque l’on souhaite vérifier rapidement le contenu de la réponse reçue, tester une fonction Modbus spécifique ou effectuer des tests ciblés sur des adresses et quantités variables sans nécessairement modifier la cartographie de l’équipement.
Le mode Execute Function est également très pratique pour le débogage, car il permet de voir immédiatement le résultat de la commande exécutée, les éventuelles erreurs renvoyées par le slave ainsi que les informations associées à la requête et à la réponse.

Send Raw Data

Cette fonction envoie et reçoit des commandes arbitraires envoyées au slave au format hexadécimal. Elle permet à l’utilisateur de saisir manuellement la séquence d’octets à transmettre sur la connexion active, par exemple série ou TCP/IP, sans construction automatique de la trame par le logiciel.
Cette fonction est très utile pour les tests avancés, le reverse engineering, le diagnostic ou la validation d’équipements Modbus et de protocoles compatibles. En pratique, le client transmet exactement les octets saisis par l’utilisateur, laissant un contrôle total sur le contenu du paquet. Il devient ainsi possible de simuler des requêtes personnalisées, de tester des réponses anormales ou d’envoyer des trames complètes préparées manuellement.
En activant l’option d’attente de réponse, SerialTool peut également acquérir la trame de retour reçue du slave et l’afficher dans le log de trafic, permettant ainsi une comparaison immédiate entre les données transmises et les données reçues.

Fonction scanner Modbus

SerialTool intègre une fonction de scan des adresses Modbus de l’équipement Slave connecté. Cette fonction permet d’explorer rapidement une plage d’adresses, d’une adresse initiale jusqu’à une adresse finale, en spécifiant également le code de fonction à utiliser pendant le scan.
Le scanner est particulièrement utile lorsque la cartographie complète de l’équipement distant n’est pas connue avec précision ou lorsque l’on souhaite vérifier quelles adresses sont valides et lesquelles contiennent des données significatives. Pour chaque adresse interrogée, SerialTool affiche dans la table le type de fonction utilisé, l’adresse, la valeur lue et le résultat de l’opération.
Ce mode accélère considérablement les activités de diagnostic et d’intégration avec des équipements tiers, car il permet d’identifier rapidement les zones de la mémoire Modbus effectivement utilisées par le slave et d’exporter les résultats du scan pour une analyse ultérieure ou un partage.

Graphique des registres Modbus du Slave

Les valeurs des registres Modbus peuvent être affichées dans un graphique. Cette fonction permet de relier un ou plusieurs éléments de la cartographie de l’équipement à une fenêtre graphique dédiée, dans laquelle les valeurs sont tracées au fil du temps pendant le polling ou les opérations de mise à jour.
Chaque registre relié au graphique peut être affiché avec sa propre courbe, identifiée par une couleur spécifique et des informations telles que la référence Modbus, l’adresse, la valeur actuelle et le nom attribué à l’élément. Il est ainsi possible d’observer facilement l’évolution dans le temps de variables analogiques, de consignes, de mesures ou de registres numériques qui changent pendant le fonctionnement de l’équipement.
La fonction graphique est particulièrement utile pour la supervision, les essais et l’analyse dynamique, car elle permet de voir immédiatement comment les données évoluent dans le temps sans se limiter à une simple lecture tabulaire.

Journal du trafic Modbus

Toutes les commandes envoyées et reçues sont affichées dans la fenêtre du journal de trafic Modbus en octets. Le journal de trafic est un outil fondamental de débogage de la communication, car il permet une visualisation détaillée des données transmises par le client et de celles reçues depuis l’équipement slave, en affichant les séquences d’octets sous une forme lisible.
Grâce à cette fenêtre, il est possible de vérifier le contenu réel des trames, de s’assurer que les commandes générées sont correctes et de diagnostiquer d’éventuels problèmes de timeout, des réponses anormales, des exceptions Modbus ou des données inattendues. Le trafic peut être consulté pendant l’utilisation normale du client, pendant le polling automatique ou pendant l’envoi de données brutes.
La fenêtre de trafic propose également des fonctions avancées telles que la copie des données au format ASCII ou hexadécimal, l’enregistrement dans un fichier, la recherche dans le contenu, la sélection de lignes et des options de personnalisation graphique comme les couleurs, les polices, l’espacement et les paramètres d’affichage. Cela fait du journal de trafic non seulement un simple visualiseur, mais aussi un outil opérationnel très utile pour les développeurs, techniciens et intégrateurs.