Voir la source de Modbus et IPX800 V5

{{sommaire|niveau=4|flottant=left}}


<small>''<sub>changes à faire : traitement des valeurs négatives par complément ????</sub>''</small>

==Introduction==

{{Infobox IPX800
 | titre        = Modbus
 | image        = modbus-dall-e.jpg
 | famille      = IPX800 V5
 | date-create  = 11/09/2024
 | date-update  = 11/09/2024
 | auteur = fgtoul<br>
}}

Nous allons explorer un sujet technique qui pourrait sembler intimidant pour certains. Hier encore, j'étais dans le même bateau, jusqu'à ce qu'un véritable chevalier blanc vienne chez moi pour me donner quelques leçons et m'aider à y voir plus clair. Un grand merci à @Jweb pour son aide précieuse !

Aujourd'hui, je ne prétends pas être un expert en la matière, mais je souhaite partager ce que j'ai appris pour vous aider à dans l'intégration de ces appareils dans votre installation sans vous laisser décourager par le protocole Modbus.

Ce qui va suivre n'est pas un guide exhaustif sur le protocole Modbus, mais plutôt une explication simplifiée adaptée à nos configurations utilisant les IPX800 V5. 

==Historique==
Modicon, une entreprise américaine, a introduit le protocole Modbus il y a 45 ans pour permettre aux automates programmables et aux dispositifs industriels de communiquer entre eux. En 1996, Schneider Electric a racheté Modicon. Sous la marque Modicon, l’entreprise française a considérablement développé et commercialisé une large gamme de contrôleurs et de solutions utilisant Modbus. 
En 2004, Schneider Electric a transféré les droits à l’organisation [Modbus.org]. Depuis lors, les spécifications sont disponibles gratuitement et il n’y a pas de frais de licence pour l’utilisation des protocoles Modbus et Modbus TCP.

À l’origine, Modbus permettait les communications sur un bus filaire série. Cependant, les contraintes de ce mode de communication ont conduit à des évolutions telles que Modbus TCP, qui permet des communications sur des distances beaucoup plus longues et avec un nombre de périphériques théoriquement illimité.

==RTU vs TCP==
===Modbus RTU===
Modbus RTU (Remote Terminal Unit) : Utilise une communication série (RS232, RS485) avec une transmission binaire compacte. C’est le mode le plus couramment utilisé dans les environnements industriels

La communication Modbus sur notre IPX800 utilise l'interface RS-485 en mode maître/esclave, avec 1 seul maître sur le réseau (dans notre cas l'IPX étant le maître).

Dans ce système, le maître prend l'initiative et interroge les esclaves, qui attendent les requêtes du maître pour fournir des informations. Les dispositifs esclaves ne peuvent pas envoyer de données de manière autonome.

Le maître a la possibilité d'écrire ou de lire des données dans les registres des périphériques esclaves.

Modbus RTU sur RS485 fonctionne généralement en mode half-duplex, ce qui signifie que les données peuvent être envoyées dans les deux sens, mais pas simultanément. Dans ce cas, le bus utilise 2 fils. 



<big><u>Avantages :</u></big>

'''Simplicité :''' Facile à implémenter et à configurer.

'''Coût ''': Moins coûteux en termes de matériel et de mise en œuvre.

'''Fiabilité ''': Utilise une communication série (RS485), qui est robuste et fiable pour les environnements industriels.

'''Efficacité ''': Optimise l’utilisation de la bande passante grâce à une transmission binaire compacte.


<big><u>Inconvénients :</u></big>

'''Distance limitée ''': La distance maximale sans répéteur est d’environ 1200 mètres.

'''Nombre limité d’appareils''' : Peut connecter jusqu’à 32 appareils sur une seule ligne sans répéteur (247 avec répéteurs).

'''Débit de données''' : Plus lent par rapport à Modbus TCP, avec des taux de transfert de données limités par la vitesse de la communication série (9600 ou 115200 Bauds)

'''1 seul maître''' sur le réseau, ce qui interdit la communication avec certains appareils comme des onduleurs photovoltaïques souvent maîtres eux-mêmes.




===Modbus TCP/IP === 
Modbus TCP/IP fonctionne sur des réseaux Ethernet, permettant une communication plus rapide et une intégration facile avec les réseaux informatiques existants.

Cette architecture  Maître/Esclaves fonctionne en mode full-duplex, permettant l’envoi et la réception de données simultanément dans les deux sens. Cela améliore la vitesse et l’efficacité de la communication.

   
<big><u>Avantages :</u></big>

'''Vitesse :''' Offre des taux de transfert de données plus rapides grâce à l’utilisation des réseaux Ethernet.

'''Scalabilité :''' Peut gérer un nombre théoriquement illimité d’appareils sur un réseau IP.

'''Flexibilité''' : Permet des connexions filaires et sans fil, facilitant l’intégration avec les infrastructures réseau existantes.

'''Installation facile''' : Utilise du matériel Ethernet standard, ce qui simplifie l’installation et la configuration.


<big><u>Inconvénients :</u></big>

'''Coût''' : Plus coûteux en termes de matériel et de mise en œuvre par rapport à Modbus RTU.

'''Latence''' : Peut avoir une latence plus élevée en raison de la surcharge du protocole TCP/IP4.

'''Complexité''' : Plus complexe à configurer et à maintenir, nécessitant une connaissance des réseaux IP4.

===Conclusion===
Modbus RTU est idéal pour les systèmes plus petits et moins complexes où la simplicité et le coût sont des facteurs importants.

Modbus TCP est mieux adapté aux systèmes plus grands et plus complexes nécessitant une communication rapide et une grande scalabilité.

==Modbus RTU==
===Le maître===
Notre IPX800 V5 possède tous les outils pour interroger ou piloter des dispositifs sur son réseau Modbus.

Un maître peut envoyer des requêtes de lecture ou d'écriture de données vers un dispositif particulier grâce à l'adresse unique qui identifie chaque esclave (1 à 247).

Il peut également s'adresser à tous les esclaves simultanément en envoyant un Broadcast sur l'adresse 0 ou 254. Vu que tous les esclaves ne peuvent pas répondre simultanément, le broadcast est utilisé pour l'envoi de commandes d'écriture.

===L'esclave===
Chaque esclave est identifié par son adresse réseau unique. 
L'esclave, comme nous l'avons abordé plus haut, ne peut prendre aucune initiative. Il reste en veille jusqu'à réception d'une requête émise par le maître. Si la requête lui est bien adressée (son adresse réseau unique correspond), il traite la demande et renvoie une réponse au maître. Il traitera également la demande dans le cas d'un Broadcast.
 
===Les requêtes===
En Modbus RTU, les messages sont encapsulés dans un format binaire compact et transmis via des interfaces série (RS485 pour notre IPX).

Chaque message contient une adresse d’esclave, un code de fonction, des données et un CRC (Cyclic Redundancy Check) pour la vérification des erreurs.


Chaque octet de la trame RTU est codé sur 2 caractères hexadécimaux. La trame sera composée de 256 octets maximum.
{| class="wikitable"
|+
!Silence
!Adresse
!Fonction 
!Données
!CRC
!Silence
|-
| Début
|1 octet
|1 octet
|n octets
| 2 octets
|Fin
|-
|
|0 à 247
|1 à 127
|Données à envoyer
|Contrôle
|
|}
Pour connaître les requêtes utilisables sur votre appareil esclave, vous devrez vous référer à la documentation du fabricant.

 Remarque :
 Vous remarquerez que l'esclave détermine le début et la fin d'une trame grâce à 2 silences. Ces silences doivent avoir chacun une durée équivalente à celle de la transmission de 3.5 caractères (1 caractère=11 bits).
 
 Avec une vitesse de transmission de 9600 Bauds, le silence doit donc durer 3.5 * 11 * (1/9600) secondes, soit environ 4 millièmes de secondes.
 Avec une vitesse de transmission de 115200 Bauds, le silence doit donc durer environ 3 millièmes de secondes.
 
 C'est pourquoi, lors de la programmation de l'ipx800, il faut éviter de traiter plus de 2 requêtes sur une même règle. Par défaut l'ipx800 insère des silences de 5ms permettant d'écouter le bus. Mais si vous surchargez la règle avec plus de 2 requêtes, l'IPX pourrait envoyer les trames trop rapprochées les unes des autres, il y aurait alors risque de perte d'informations. Il deviendrait alors judicieux d'ajouter des objets "Délais" entre les émissions de trames afin de permettre l'écoute du bus et le traitement des réponses.


==== les différents codes de fonction====
Il y a 19 fonctions en tout, voici les principales.

=====Requêtes de lecture=====
Lecture des bits de sortie (coils) :0x01
Description : Lire l’état des bits de sortie (coils) des esclaves.

Lecture des entrées discrètes :0x02
Description : Lire l’état des entrées discrètes (discrete inputs) des esclaves.

Lecture des registres d’entrée : 0x04
Description : Lire les valeurs des registres d’entrée (input registers) des esclaves.

Lecture des registres de maintien : 0x03
Description : Lire les valeurs des registres de maintien (holding registers) des esclaves.

=====Requêtes d’écriture=====
Écriture d’un bit de sortie unique : 0x05
Description : Écrire une valeur dans un bit de sortie (coil) unique.

Écriture d’un registre de maintien unique : 0x06
Description : Écrire une valeur dans un registre de maintien (holding register) unique.

Écriture de plusieurs bits de sortie : 0x0F
Description : Écrire des valeurs dans plusieurs bits de sortie (coils).

Écriture de plusieurs registres de maintien : 0x10
Description : Écrire des valeurs dans plusieurs registres de maintien (holding registers).

===== Requêtes de diagnostic=====
Diagnostic : 0x08
Description : Effectuer des tests de diagnostic sur les esclaves.
====Logiciel Modbus====
Pour lire les trames sur le bus RTU, vous pouvez utiliser divers logiciels gratuits disponibles sur le Web.

Ces logiciels vous permettront de dialoguer avec votre dispositif esclave et de comprendre son mode de communication.

Cela vous sera très utile pour programmer l’IPX800 V5 par la suite.

De plus, vous aurez besoin d’un adaptateur USB pour interfacer votre PC. Vous pouvez en trouver pour moins de 20 €.

[[Fichier:USB rs485.png|sans_cadre]]

Consultez la documentation de votre adaptateur pour son installation et son branchement. En général, seules deux bornes (A et B) seront utilisées pour la communication, tandis que la borne GND servira à mettre en commun les masses entre l’alimentation du port USB et celle de l’esclave.

Cet adaptateur crée un port série virtuel qu’il faudra configurer avec les paramètres requis par l’esclave.

voici un exemple de configuration :

* Vitesse : 9600 ou 115200 Bauds

* Nombre de Bits : 8

* Bit de parité : N
* Bit de STOP : 1

En ce qui concerne le logiciel, j'utilise Modbus Doctor.

Voilà, vous êtes prêt à communiquer en Modbus RTU entre votre PC (maître) et l'esclave.
=== Exemples d'utilisation===
====Capteur de conductivité Modbus RTU====
J'ai acquis un capteur de conductivité (EC) qui me permettra de mesurer et réguler le taux de nutriments dans la solution qui nourrira le jardin hydroponique. Cette installation fera sans doute l'objet d'un autre article, mais je ne rentrerai pas dans les détails ici.

La conductivité d'un liquide varie avec sa température,  ce capteur mesure donc les 2 grandeurs afin de permettre le calcul du facteur de correction.

Chaque grandeur pourra alors être demandée par le maître.

==== Branchement sur l'adaptateur USB====
[[Fichier:Capteur EC RS485 en USB.png|sans_cadre|1001x1001px]]

====Les premiers tests de communication ====
Voici la documentation du produit (je vous épargne les pages en mandarin. Heureusement, Google Lens permet des traductions instantanées à partir de documents au format image).

=====Configuration du port=====
Pour communiquer avec le produit, il faut d'abord configurer le port COM via le logiciel que vous aurez choisi.

Voici ce que dit la documentation :
{| class="wikitable"
|+ Port de communication
! Vitesse en Bauds
!Bit de parité
!Bits de données 
!Bit d'arrêt
|-
|9600
|N
|8
|1
|}
Ce sont donc les paramètres de la configuration du port série virtuel créé par l'adaptateur. Ces paramètres doivent être appliqués dans le logiciel Modbus.

Voilà ce que cela donne dans Modbus Doctor :

[[Fichier:Modbus doctor config.png|sans_cadre|661x661px]]

=====Liste des registres accessibles=====
La documentation doit impérativement lister les adresses et formats des données pour que vous puissiez exploiter votre appareil.
{| class="wikitable"
|+Adresse des registres
! Adresse
!Valeur
!Plage
!Lecture/Ecriture
!Fonction supportées
|-
|0x 00 00
|Température en °C
|0 à 80.0
|Lecture seule
|03
|-
|0x 00 01
|Conductivité en µS/cm 
|0 à 4000
|Lecture seule
|03
|-
|0x 00 03
|ID Esclave
|1 à 247
|Lecture/Ecriture
|03/06
|}
Ce sont donc les adresses des registres qu'il sera possible de lire ou écrire, ainsi que leur description. Comme nous l'avons vu plus haut, cette partie de documentation est indispensable pour l'interprétation des données du fabricant contenues dans les réponses du capteur.


'''Attention :''' '''un esclave ne peut pas avoir un ID 0.'''

La documentation du capteur indique que l’ID peut être 0, bien que cette valeur soit strictement réservée aux messages de diffusion (Broadcasts).

Si par erreur vous configurez votre appareil avec un ID à 0, il deviendra alors injoignable. Cette mésaventure m'est arrivée pendant mon apprentissage du logiciel Modbus Doctor. Une écriture malencontreuse de la valeur 0 dans le registre 3, et hop, matériel à la poubelle.

'''(à retenter :  modifier l'ID avec un broadcast sur adresse 0 ou 254 (FE)) si un seul esclave est connecté car doublon impossible.'''

Autre souci dans la documentation : il est mentionné que l'ID par défaut du matériel est 0 alors qu'il est de 1.

Le matériel Made in China est donc d'un rapport qualité/prix excellent, mais il faut très souvent s'attendre à galérer un peu pour la mise en œuvre.

=====Requête "Lecture" de registre=====

======Extrait de la documentation======
Le format de la requête émise par le maître est standardisé, la trame  est donc toujours construite de la même façon.

{| class="wikitable"
|+Requête d'interrogation de l'esclave (03)
! Adresse de l'esclave
!code fonction
!adresse registre
(bit fort)
! adresse registre
(bits faibles )
!Nombre de registres à lire 
(bits forts)
! nombre de registres à lire 
(bits faibles)
!CRC
(bits forts)
!CRC 
(bits faibles)
|-
| 1 octet
|03 
|1 octet
|1 octet
|1 octet
|1 octet 
| 1 octet 
|1 octet
|}
La réponse émise par l'esclave lors de la réception de cette requête est également formatée, mais en partie seulement. En effet, le champ "Données" n'a pas de format imposé. Le fabricant peut alors adapter le message à son produit. 

Le fabricant doit alors documenter la construction de trame adoptée, le format de chaque registre et son adresse, afin que l'utilisateur final puisse lire et convertir ces variables en grandeurs réelles.
{| class="wikitable"
|+Réponse de l'esclave à une requête 03
!Adresse de l'esclave
!code fonction
! Nombre de registres lus
!Données
!CRC (bits forts)
!CRC (Bits faibles)
|-
| 1 octet
|03
|1 octet
| N * 2 octets de données
|1 octet
|1 octet
|}
Nous pouvons constater que les données du capteur sont constituées de paires d'octets, dont le nombre dépend de la requête d'interrogation reçue.

======Lecture de la valeur de conductivité======

* '''émission de la requête du maître vers l'esclave :'''  Selon la documentations ci-dessus, construisons la requête de type 03 à destination de l'esclave #1 pour récupérer la valeur de la conductivité avec notre logiciel.  Réglez le logiciel pour un affichage en hexadécimal.

{|
!<big>01</big>
!<big>03</big>
!<big>00</big>
!<big>01</big>
!<big>00</big> 
!<big>01</big>
!xx
!yy
|}


Cette trame émise par le maître est donc construite comme suit :

01 (1 octet) : ID unique de l'esclave destinataire

03 (1 octet) : Fonction lecture de registres

00 01 (2 octets) : Adresse de début de lecture, ici : 1 qui correspond bien à la conductivité

00 01 (2 octets) : Nombre de registres à lire, ici 1. Nous demandons donc seulement la valeur de la conductivité.

xx yy (2 octets) : CRC. Je remplace la valeur hexadécimale par XX dans chaque octet car le code de vérification est calculé automatiquement par le logiciel et n'est pas utile à la compréhension.

Emettons la trame avec notre logiciel Modbus (en général il calcule automatiquement les octets du code de vérification -CRC-)

* '''Réponse de L'esclave ID 1 :'''

{|
!<big>01</big>
! <big>03</big>
!<big>02</big>
!<big>06</big>
! <big>FA</big>
!3B
!A7
|}Cette réponse émise par l'esclave se décompose comme ceci:

01 (1 octet) : ID de l'esclave

03 (1 octet) : la commande reçue

02 (1 octet) : le nombre d'octets qui constituent les données incluses dans la réponse, ici il y aura 2 octets

Du coup on récupère les 2 octets suivants pour connaître la valeur de la réponse :

06 FA (2 octets) : ces 2 octets, qui constituent la valeur de conductivité, devront être interprétés conformément à la doc. 

3B A7 (2 octets) : CRC


La documentation donne la formule à appliquer pour obtenir la valeur de conductivité. 

Soit A la valeur contenue dans l'octet de poids fort, et B celle de l'octet de poids faible.

La formule est A* 256 + B


Nous obtenons après conversion hexadécimale vers décimal : 6*256 + 250 = 1786 µS/cm

======Lecture de la température======
Sur le même principe, émettons une requête de lecture du registre température.

Émettons la trame suivante pour interroger le registre à l'adresse 0 qui correspond à la température.

{|
!'''<big>01</big>'''
!<big>03</big>
!<big>00</big> 
!<big>00</big> 
!<big>00</big>
!<big>01</big>
!xx
!xx
|}


01 (1 octet) : ID unique de l'esclave destinataire

03 (1 octet) : Fonction lecture de registres

00 00 (2 octets) : Adresse de début de lecture, ici : 0 qui correspond bien à la température

00 01 (2 octets) : Nombre de registres à lire, ici 1. Nous demandons donc seulement la valeur de la température


Voici la réponse de L'esclave ID 1 :01 03 02 00 C6 38 16
{|
!'''<big>01</big>'''
! '''<big>03</big>'''
!'''<big>02</big>'''
!'''<big>00</big>'''
! '''<big>C6</big>'''
!'''<big>38</big>'''
!'''<big>16</big>'''
|}Au regard de la documentation, cette réponse émise par l'esclave se décompose comme ceci:

01 (1 octet) : ID de l'esclave

03 (1 octet) : la commande reçue

02 (1 octet) : le nombre d'octets qui constituent les données incluses dans la réponse, ici il y aura 2 octets

Du coup on récupère les 2 octets suivants pour connaître la valeur de la réponse :

00 C6 (2 octets) : ces 2 octets, qui constituent la valeur de température, devront être interprétés conformément à la doc. 

38 16 (2 octets) : CRC

Si nous appliquons la formule donnée par la documentation, la température est  ((0x00 * 256) + 0xC6 )/10 soit 19.8°C

===== Requête "Écriture" de registre=====

======Extrait de la documentation======
Comme pour les requêtes de lecture, le format de la demande d'écriture est toujours construit de la même façon.

{| class="wikitable"
|+Requête d'écriture d'un seul registre (06)
!Adresse de l'esclave
!code fonction
!Bit fort adresse registre
!Bit faible adresse registre
!valeur à écrire dans le registre
(bits forts)
!valeur à écrire dans le registre
(bits faibles)
!CRC (bits forts)
!CRC (bits faibles)
|-
|1 octet
|06H
|1 octet
|1 octet
|1 octet
|1 octet
|1 octet
|1 octet
|}

* Émission de la requête Émettons la requête suivante qui permet de modifier l'ID à 2.
{|
!<big>FE</big>
!<big>06</big>
!<big>00</big> 
!<big>03</big> 
!<big>00</big>
!<big>02</big>
!xx
!xx
|}La demande d'écriture se décompose ainsi :

FE : adresse de l'esclave. 254 correspond à un message de diffusion.

06 : Fonction Écriture

00 03 : Adresse du registre à modifier

00 02 : valeur à écrire


NB : dans cet exemple, nous modifions l'ID de l'esclave via un message de diffusion. Cela est possible uniquement parce que nous n'avons qu'un seul esclave connecté, l'ID devant être unique.


'''Vérifier si réponse de l'esclave.'''

==== Modbus RTU sur IPX800 V5 ====
L’IPX800 V5 propose des objets “Modbus Read” pour les requêtes de lecture et des objets “Modbus Write” pour les fonctions d’écriture sur les registres.

Ces objets peuvent être liés à des ressources ou à des événements, et il est également possible de créer des scénarios personnalisés.

Chaque valeur de registre lue peut être utilisée comme variable dans les automatismes, offrant ainsi une grande flexibilité dans la gestion de vos systèmes.

===== Branchement du capteur de conductivité =====


<diagramme>

===== Configuration du mode de communication =====
La configuration du mode de communication série (RTU)  se fait de manière centrale sur la page SYSTEM via la tuile MODBUS.

Il suffit de reporter les paramètres documentés par le fabricant du capteur.

Si vous avez plusieurs esclaves, il faudra veiller à les configurer pour utiliser la même vitesse de communication. Si vous ne pouvez pas, sachez qu'il existe des convertisseurs (Baud rate converters) qui vous permettront d'harmoniser les vitesses entre l'IPX800 (maître) et les esclaves.

[[Fichier:Image config COM RTU.png|sans_cadre]]

===== Création d'un objet Lecture =====
La création d'un objet "Modbus read" nécessite la connaissance du format de la trame RTU.

Si vous vous rappelez bien, nous avons vu que la réponse de l'esclave à une requête de Lecture comportait une séquence d'octets que le fabricant pouvait adapter à son produit. Il va donc falloir donner la structure de ces données afin que l'ipx800 puisse interpréter les réponses du capteur.

Pour ce faire, nous allons reconstituer la séquence à l'aide de tuiles IO ou analogiques que nous glissons dans la zone "Modbus Frame".

Pour notre exemple, nous souhaitons lire la température à l'adresse 0. 

La réponse de l'esclave contient les données sur 2 octets comme nous avons pu le tester précédemment. 

Vu que nous devons appliquer une formule sur chacun d'eux pour obtenir notre température, nous devons utiliser 2 analogiques 8 bits plutôt qu'une seule analogique 16 bits

Lorsque l'on dépose une tuile, il est immédiatement demandé d'associer une ressource (source de données).

Il est alors possible d'associer une variable existante ou en créer une nouvelle.



[[Fichier:Image modbus read.png|sans_cadre|534x534px]]

Vous pouvez tester la requête avec le bouton envoi et vérifier si les variables analogiques récupèrent les bonnes valeurs.

L'ipx800 affiche les valeurs en décimal.

===== Création d'un objet Écriture =====
Notre capteur accepte les requêtes Écriture sur le registre en adresse 3, ce qui permet l'affectation d'un ID unique.

Créons un objet "Modbus Write" qui attribue l'ID 4.

Nous avons vu précédemment que la valeur à écrire se composait de 2 octets. Notre cas permet l'utilisation d'une variable analogique 16 bits qui pourra contenir la valeur 4 à envoyer au registre.

Glissons une tuile de type A16 et nommons la.

Vous pouvez tester la requête avec le bouton d'envoi.

===== Exemple d'utilisation =====
Notre capteur ne nécessite pas l'automatisation des requêtes d'écriture. En effet, seul le changement d'ID est possible, et celui-ci ne se fait qu'une fois en théorie, à la mise en œuvre du dispositif.

Cependant il est utile de mémoriser cette requête car au moment du remplacement du capteur en cas de panne, il suffira d'envoyer la requête pour lui réaffecter le bon ID. Si vos capteurs permettaient la modification d'autres paramètres comme la vitesse, une commande de réinitialisation, mémorisez ces requêtes qui pourront vous faire gagner du temps en cas de problème.



Nous allons donc automatiser la lecture de la température à intervalle régulier à l'aide d'un objet clignotant. Nous opterons pour une fréquence raisonnable pour ne pas saturer notre bus RTU. J'ai très peu de capteurs sur mon installation, je me décide pour un refresh toutes les 6 secondes, c'est suffisant pour suivre une température en cas de régulation.


Créons un clignotant et lions le à l'entrée "Départ" de l'objet Modbus Read. Désormais, la température mesurée par le capteur remontera toutes les 3 secondes dans nos 2 variables analogiques 8 bits.

Il ne reste plus qu'à créer un objet fonction qui calculera la grandeur réelle via la formule communiquée par le fabricant.

Il suffit alors de créer une formule utilisant les variables sous la forme $id$.


<image>

Maintenant il m'est possible d'envisager mon futur projet, avec un dosage automatique des engrais liquides dans la solution nutritive d'un mini potager hydroponique.

Les valeurs lues via Modbus seront comparées à des consignes et les mini pompes péristaltiques dispenseront la nourriture lorsque les seuils seront bas.

En cas d'excès de nutriments, la conductivité deviendrait trop élevée (ce qui est tout autant nocif pour les plantes aromatiques, laitues, fraisiers).

l'IPX800 pourra alors ajouter de l'eau claire pour diluer la solution.
[[Fichier:Image potager hydroponique.png|vignette|496x496px]]