Modbus TCP

Des registres et des bobines Modbus sur TCP/IP, avec un adressage typé, la maîtrise de l'ordre des octets et un balayage réseau borné.

Le pilote Modbus TCP lit et écrit des registres et des bobines Modbus sur TCP/IP : automates, compteurs, passerelles et tout serveur qui parle Modbus/TCP. L'adressage est entièrement typé : vous choisissez une classe de registre et un numéro de registre à partir de 0, et l'application assemble la requête ; il n'y a aucune adresse en texte libre à rater.

Équipement

L'URI de base affichée dans l'en-tête du volet est modbus+tcp://host:port/unitID, plus ?minimumTransactionIntervalMs=n quand l'intervalle est réglé.

Les équipements qui partagent un hôte et un port partagent aussi une seule barrière de transaction : les requêtes vers le même endpoint ne se chevauchent jamais, et le plus grand intervalle minimal configuré parmi les équipements activés de cet endpoint les cadence tous. Le volet le dit quand un autre équipement élève l'intervalle effectif au-dessus de celui configuré ici. L'intervalle ne gouverne que le trafic que cette application émet : c'est une aide à la compatibilité pour un serveur ou une passerelle lents, pas une réparation des défauts de réseau.

La connexion attend 5 secondes au plus ; une réponse est attendue 10 secondes au plus ; il n'y a aucune reprise au niveau du protocole. La boucle de reprise en arrière-plan possède la reconnexion, si bien qu'un équipement éteint ne coûte rien de plus qu'une lecture de mauvaise qualité.

RTU sur TCP

Un convertisseur série-Ethernet en mode transparent ne parle pas Modbus TCP de lui-même : ce qui arrive sur son socket repart tel quel sur son bus série, et ce que le bus répond revient. Un équipement derrière lui est un équipement Modbus TCP dont le Format de trame est RTU : la station envoie la trame RTU (l'ID d'unité, la requête et son CRC) sans en-tête MBAP, et ne croit une réponse que si son CRC est juste. Le Base URI porte alors framing=rtu dans sa requête, par exemple modbus+tcp://192.168.0.20:502/1?framing=rtu ; un équipement en MBAP garde l'adresse qu'il a toujours eue. Tout le reste de cette page vaut sans changement : les classes de registre, les codes de fonction, la file des écritures, les délais et l'intervalle entre transactions.

• L'ID d'unité est l'adresse de l'équipement sur le bus série derrière le convertisseur, de 1 à 247.
• Les équipements derrière un convertisseur partagent son hôte et son port, et avec eux sa barrière de transactions : une requête à la fois, ce qui est aussi tout ce que porte un bus série. Si le convertisseur a besoin d'une pause entre les trames, augmentez l'Intervalle minimal entre transactions (ms).
• Les réglages série du convertisseur lui-même (débit en bauds, format) se font sur le convertisseur ; la station ne les voit jamais.
• Une trame RTU ne porte pas de numéro de transaction : avant chaque requête, la station écarte donc tout ce que le convertisseur a déjà envoyé, et une réponse arrivée après l'expiration de sa requête n'est jamais prise pour celle de la suivante.

Adressage des tags

La carte Source de la valeur se termine par Adresse dans le manuel, l'endroit où se trouve le tag dans la notation que le manuel de l'équipement imprime : le premier chiffre de la classe puis le registre compté à partir de 1. Le registre d'entrée 0 se lit 30001, un Float au registre de maintien 100 se lit de 40101 à 40102, et un registre au-delà de 9998 passe à six chiffres (le registre de maintien 9999 se lit 410000), si bien que le volet se lit ligne à ligne contre le manuel.

Types de valeur et quantités

Six types de valeur sont proposés, et la largeur de protocole de chacun est fixée :

Un tag String est lu et écrit dans l'ordre où l'équipement porte les octets, et une écriture envoie toujours de l'UTF-8. Des octets qui ne sont pas de l'UTF-8 valide, ce à quoi ressemblent une plage que l'équipement n'a jamais initialisée ou du texte écrit dans un autre encodage, se lisent en caractère de remplacement Unicode plutôt que d'échouer : le tag montre quelque chose de visiblement faux, et tous les autres tags de cet équipement continuent de se lire.

La Quantité (registres, vide = automatique) n'est demandée que sur les tags String. Les largeurs Boolean, Int16, UInt16, Int32 et Float sont fixes, si bien que la zone n'est dessinée sur aucun de ces points, ni dans le volet du tag ni dans la grille des tags ; le remplacement existe pour dimensionner les tags String.

Ordre des octets et des mots

La case de l'ordre des octets est dessinée sur les tags numériques et sur un booléen tenu dans un registre, celle de l'ordre des mots sur ceux à deux registres seulement (Int32, Float). Ce sont deux questions indépendantes : quel octet mène à l'intérieur de chaque registre, et quel registre mène sur une paire. Modbus n'en définit aucun pour le texte, si bien qu'un tag String ne se les voit pas proposer : ses octets voyagent dans l'ordre où l'équipement les porte. Pour la valeur 0x01020304, avec A pour l'octet de poids fort, les quatre dispositions sont :

Les lectures et les écritures appliquent les deux mêmes réponses dans le même ordre, si bien qu'une écriture pose exactement les octets qu'une lecture aurait repris. Ordre des octets de la valeur, sous les cases, dit la disposition en un mot (ABCD, CDAB, BADC ou DCBA), comme un manuel la nomme.

Une valeur Int16 ou UInt16 tient dans un seul registre, si bien que seul l'ordre des octets s'y applique : pour 0x1234, l'octet de poids fort en premier envoie 12 34 et la case décochée envoie 34 12. Il n'y a pas de second registre à placer : la case de l'ordre des mots n'y est donc pas dessinée.

Codes de fonction

Une écriture ne rapporte un succès que lorsque la réponse de protocole du serveur confirme l'acceptation ; la valeur en cache n'avance qu'à ce moment-là.

Découverte

Le balayage est explicite et borné : l'application ne déduit ni ne parcourt jamais votre sous-réseau local. Le formulaire de portée prend :

La découverte envoie chaque sondage dans le Format de trame choisi. En RTU, chaque sondage est la trame RTU nue, et une réponse ne compte que si son ID d'unité correspond et que son CRC est juste ; les unités derrière un convertisseur en mode transparent sont ainsi trouvées comme les autres. Une unité trouvée garde le format de trame du balayage quand elle est ajoutée.

Un seul balayage envoie 256 sondages au plus (hôtes × ID d'unité) ; un plan plus grand est refusé avant l'ouverture de la moindre prise. La seule requête envoyée est Read Basic Device Identification (fonction 43/14) : la découverte ne lit jamais de registres et ne devine jamais de plan de registres. Une réponse d'exception Modbus entièrement valide prouve qu'une unité est présente sans prétendre à son identité ; la joignabilité TCP, les délais dépassés et les trames malformées, non. Quatre hôtes au plus sont balayés en parallèle, séquentiellement à l'intérieur de chaque hôte, avec des délais de connexion et de sondage de 750 ms.

Les résultats portent l'endpoint complet et un nom proposé, construit depuis le fabricant et le code produit quand l'équipement les rapporte. Les candidats ont zéro tag : les registres se configurent après Ajouter. Une unité déjà configurée est marquée comme telle et propose Ouvrir au lieu de créer un doublon.

Des limites à connaître

• Les autres largeurs d'entier (SByte, Byte, UInt32, Int64, UInt64) et Double ne sont pas proposés : le codec de bus fait l'aller-retour exact sur les six types ci-dessus.
• Une seule requête est en cours par endpoint à la fois ; les nombreux équipements derrière une passerelle partagent cette sérialisation par construction.
• Les écritures adressent une bobine ou une suite de registres à la fois ; il n'y a pas d'écriture multibobine.