Commencer

Cette page est la section de référence pour le protocole Modbus dans SHIP.

Si vous débutez, vous pouvez commencer par la note d’application AN0500 – Utilisation de Modbus dans SHIP : un tutoriel étape par étape.

Qu’est-ce que Modbus ?

Modbus est un protocole de communication maître/slave très simple, fonctionnant traditionnellement sur des réseaux RS232 point à point ou RS485 multipoints.

Il est conçu pour fonctionner en mode semi-duplex, avec un seul appareil, désigné comme le maître responsable de l’interrogation et de la direction de tous les slaves. Les slaves ne peuvent pas initier spontanément des messages de données : ils doivent être interrogés par le maître. De même, les slaves ne peuvent pas parler de pair à pair à un autre slave. Le maître doit interroger un slave, collecter des données et les renvoyer à un autre.

Chaque slave sur un réseau donné doit avoir un numéro d’identification unique (ID d’slave). Les slaves peuvent répondre à plus d’un identifiant d’slave (agissant comme plusieurs slaves dans un seul appareil physique), mais aucun identifiant d’slave ne peut se chevaucher. Les slaves peuvent être de simples appareils, comme des capteurs ou des actionneurs, souvent dotés d’un minuscule commutateur DIP permettant de sélectionner manuellement parmi une gamme d’identifiants d’slaves. Les slaves plus sophistiqués peuvent mettre en œuvre des identifiants d’slave sélectionnables sur le panneau avant.

Le maître n’a pas d’identifiant (bien que dans certains réseaux, 0 soit réservé au maître). C’est parce que les slaves n’ont pas besoin de s’adresser explicitement au maître, ils répondent toujours simplement aux demandes du maître.

Modes de protocole

Modbus est un ensemble très simple de protocole de paquets. Lorsque le paquet est décodé, quel que soit le « mode » de transmission du protocole, il contient exactement le même contenu de message. Les décodeurs logiciels peuvent être écrits avec différentes interfaces de décodeur/encodeur pour les différents modes de transmission et le reste du logiciel peut être unifié.

Lorsque Modbus est transmis sur des réseaux série de type RS232, RS422 et RS485, il existe deux modes de transmission standard : ASCII ou RTU (binaire). Le réseau série doit être désigné ASCII ou RTU. Vous ne pouvez pas mélanger les modes sur le même réseau. Il n’y a pas de processus de négociation et les capacités d’auto-bauds n’existent pas. Le type doit être défini une fois par le concepteur de réseau/système et tous les périphériques du réseau doivent être réglés manuellement à la vitesse correcte.

Lorsque Modbus est transmis via TCP/IP, le mode Modbus TCP est utilisé.

Pour plus d’informations sur le protocole, consultez la liste des Références Modbus.

ASCII

MODBUS_SLAVE_ASCII s’agit d’un format de transmission ASCII lisible par l’homme et facile à déboguer sur un terminal renifleur (un appareil qui écoute uniquement mais ne pilote pas le câble RS232 ou RS485) puisqu’un programme de terminal afficherait les paquets. Il est très facile à analyser dans un logiciel, avec des caractères uniques de début (‘ :’) et de paquet de fin (CR-LF), mais parce que chaque octet est envoyé comme une valeur hexadécimale-ascii (par exemple, un ‘a’ est envoyé comme deux octets ‘2’ et ‘1’, représentant un 0x21 hexadécimal qui est un ‘a’), c’est la moitié de la vitesse d’un protocole de transmission binaire.

Chaque paquet initié par le maître ressemble à ceci :

Chaque slave répond avec une version modifiée du paquet :

Le mode Modbus ASCII présente plusieurs avantages :

• facile à déboguer sur un terminal renifleur (un appareil qui n’écoute que le câble RS232 ou RS485 mais ne pilote pas celui-ci) puisqu’un programme de terminal peut afficher les paquets dans un format lisible par l’homme, 1 paquet par ligne
• facile à analyser et à synchroniser dans le logiciel, avec un caractère de début (‘ :’) et une séquence de fin (CR-LF) uniques
• logiciel plus petit/plus simple pour le calcul de la somme de contrôle 8 bits que le CRC 16 bits utilisé en mode RTU

et quelques inconvénients :

• la moitié de la vitesse de RTU : chaque octet est envoyé sous forme de valeur hexadécimale-ASCII, c’est la moitié de la vitesse d’un protocole de transmission binaire.
• moins robuste que le RTU : une somme de contrôle de 8 bits est beaucoup plus susceptible de manquer des erreurs que le CRC 16 bits du RTU

RTU

Modbus RTU est un format de transmission binaire. Chaque paquet initié par le maître ressemble à ceci :

Chaque slave répond avec une version modifiée du paquet :

Le mode Modbus RTU présente des avantages :

• plus rapide que l’ASCII Modbus : un octet par caractère au lieu de deux
• plus robuste au bruit que l’ASCII : le CRC 16 bits détecte mieux les erreurs de bits que la somme de contrôle ASCII 8 bits

et quelques inconvénients :

• Plus difficile d’écrire un logiciel pour rester synchronisé dans un environnement bruyant : pas de séquences de début/fin
• CRC nécessite plus de logiciel sur l’slave pour générer/tester
• Plus difficile à déboguer sur un terminal renifleur : nécessite généralement un programme de décodeur de paquets

TCP

Bien qu’ils ne soient actuellement pas pris en charge nativement dans SHIP, les paquets Modbus peuvent également être envoyés via des connexions TCP/IP pour permettre la connectivité serveur et cloud. Souvent, la carte SIM est configurée en tant que maître Modbus contrôlant un slave (tel qu’un moteur, une pompe ou un API). Avec l’ajout d’un pont UART vers WiFi très simple et d’une implémentation Modbus slave basée sur un serveur, la carte SIM peut désormais être « connectée au cloud » et envoyer et recevoir des informations d’un serveur. Dans ce mode, par exemple, la carte SIM peut fournir une application basée sur le cloud avec l’état du moteur ou de l’équipement, et l’interface graphique de la carte SIM et l’application cloud peuvent contrôler l’équipement.

Codes de fonction

Wikipédia a une liste complète des codes de fonction Modbus courants. Cependant, les codes de base sont les suivants :

Les codes de fonction sont souvent représentés par « FCxx », par exemple FC01. Notez que lorsqu’il est représenté de cette manière, le code est toujours représenté en décimal (base 10). Ainsi, FC16, par exemple, est le code de fonction 16 décimal ou 0x10 hexadécimal : la commande Preset Multiple Registers.

Variables slaves

Chaque slave dispose d’un ensemble (généralement fixe) d’entrées et de sorties booléennes et/ou 16 bits qu’il utilise. La documentation de l’slave publiera une table de ces « variables » et des FC autorisées.

Par exemple, un simple capteur de température compatible Modbus peut avoir une interface publiée très simple :

La direction est la direction Modbus par rapport au maître, donc une « entrée » est une entrée au maître et une « sortie » est une sortie à un slave du maître.

Il s’agit d’un ensemble de commandes très simple à implémenter dans le capteur. Les adresses pourraient même être ignorées, puisqu’il n’y a qu’une seule entrée 16 bits et une sortie booléenne – n’importe quel FC02 pourrait récupérer la température et n’importe quel FC05 pourrait forcer le recalibrage.

Les automates programmables (PLC), tels que la série peu coûteuse Automation Direct Click, publient une liste complète de toutes les adresses, types de données et codes de fonction autorisés à accéder à l’API.

Sondages

Modbus est un protocole mono-maître/multi-slave. Alors que le mécanisme de transmission physique réel (par exemple RS232, Ethernet, WiFi, RS485) peut être en semi-duplex ou en duplex intégral, le protocole est un protocole de commande-réponse.

Le maître lance une requête en envoyant un paquet de commande à un slave. Le slave ciblé répond ensuite avec un paquet de réponse. Il existe une relation 1:1 entre les paquets maître et slave (sauf erreur de survenance).

Au sein de chaque paquet (requête maître ou réponse slave), lorsqu’il est utilisé sur un canal série, le paquet n’est pas interactif. Il n’existe pas de concept de trafic de type ACK/NAK octet par octet. L’ensemble de la requête est poussé dans une direction en une seule rafale et l’ensemble de la réponse est repoussée en une seule rafale.

Dans le  protocole Modbus TCP, étant donné que TCP/IP peut mélanger les paquets et les désordonner en fonction de la latence du réseau, il y a un numéro de séquence supplémentaire dans chaque paquet. Chaque extrémité est responsable (éventuellement) de la gestion des paquets dans le désordre.

Le maître est donc responsable de sonder tous ses slaves, et à l’intérieur de chaque slave toutes les variables qu’il a besoin de connaître. Il n’y a aucun moyen pour un slave d’envoyer une alarme ou une valeur de manière proactive – elle doit être interrogée par le maître à une fréquence acceptable pour l’événement. Si un slave a une entrée booléenne indiquant, par exemple, qu’il est en surchauffe, alors le maître doit interroger l’slave (et plus précisément, obtenir cette valeur booléenne) à un rythme suffisant pour que la latence d’affichage/réponse soit acceptable pour le système.

De tels algorithmes dans le master peuvent devenir assez sophistiqués. Par exemple, le maître peut avoir un mécanisme d’interrogation lente où chaque slave et chaque valeur d’entrée/sortie est interrogé sur une certaine période de temps. Lorsqu’une sortie doit être modifiée, le maître peut entrelacer une demande définie à le slave cible entre les demandes de cycle d’interrogation lent. Un maître plus simple pourrait interroger tous les slaves connectés et une seule fois par cycle d’interrogation permettre d’envoyer un « ensemble » à un slave. Il existe de nombreuses variantes possibles, y compris l’interrogation rapide d’un slave spécifique combinée à l’interrogation lente d’autres slaves. Ou, par exemple, une variable spécifique sur un slave (comme l’exemple de surchauffe ci-dessus) peut être interrogée à une fréquence tandis que le reste des slaves/variables est interrogé sur une autre.

Pour cette raison, les implémentations logicielles côté maître peuvent être plus grandes et plus compliquées que les implémentations logicielles côté slave. SHIPEngine prend en charge les modes maître et slave, y compris la prise en charge du minutage des sondages à n’importe quel niveau et même la prise en charge simultanée du maître et de l’slave sur des canaux de communication séparés.

Références

Plus d’informations

• Simplement Modbus est une excellente référence d’apprentissage
• Wikipédia a une assez bonne vue d’ensemble de Modbus
• org Si vous voulez être submergé

Outils de débogage

• Simplement Modbus dispose d’un logiciel PC peu coûteux pour simuler un maître/slave
• Front Line Test Equipment dispose d’un renifleur PC-USB (avec logiciel) pour les câbles RS232 et 485 (c’est ce que nous utilisons chez Serious)
• Modpoll Modbus® Poll Polling Tool est un simulateur de maître Modbus gratuit basé sur la ligne de commande et un utilitaire de test
• Simulateur de maître Modbus Poll est un simulateur de maître Modbus avec une excellente interface utilisateur. Prend en charge les modes RTU et ASCII.

Logiciels embarqués

• Code source C gratuit de Serious SHIPWare sur Micrium, FreeRTOS et Segger pour les modules intégrés sérieux (propriétaires de cartes SIM uniquement, inscription nécessaire)
• Source gratuite pour les microcontrôleurs Microchip PIC18 (inscription nécessaire)
• Micrum μC/Modbus Commercial, robuste et entièrement pris en charge ; nombreux ports MCU