Modbus TCP/IP sur PIC32

[invite6f4ace37]

Bonjour,

J'ai un projet ou je dois mettre en oeuvre le protocole MobBus en... UDP.

Bon mettre en oeuvre le TCP ou UDP n'est pas le problème mais j'ai beau étudier le protocole ModBus il y a certaines choses qui m'échappe. Je ne vois pas comment m'en servir et comment il fonctionne.

La trame si j'ai bien compris ressemble à ça mais après je vois pas comment commencer.

Transaction ID | Protocol ID | Length | UnitID | Function Code | Data


Comment le mettre en oeuvre, c'est à moi de créer chaque packet et sur le serveur gérer la réponse ?
Donc si le client envoi au serveur un packet de type "discrete input" avec data=3 alors il faut que je dise côté serveur "attention data=3 donc renvoi moi l'état de telle entrée" ?


Comment choisir avec quel esclave (serveur) je souhaite communiquer ? avec Transaction ID ?

Ce qui me perturbe se sont surtout les tables de donnée (coils, input register, ...) et le traitement qu'il y a derrière.

Merci pour votre aide !
-----

[Jack]

Comment le mettre en oeuvre, c'est à moi de créer chaque packet et sur le serveur gérer la réponse ?

C'est à toi de savoir si tu veux programmer un maitre ou un esclave. Le programme sera évidemment différent.

Donc si le client envoi au serveur un packet de type "discrete input" avec data=3

???? Que veut dire "data = 3". La fonction "read discrete input" demande l'adresse de la première entrée et le nombre d'entrées à lire.

Comment choisir avec quel esclave (serveur) je souhaite communiquer ?

Avec son adresse IP.

Ce qui me perturbe se sont surtout les tables de donnée (coils, input register, ...)

Coil est une sortie, input une entrée et register une donnée de 16 bits. Qu'est-ce qui te perturbe?

[invite6f4ace37]

Je vais programmer la partie serveur (récupération de température, entrées discrètes,...).

Je connais les tables de données, mais c'est comment les utiliser que je ne comprend pas.

La fonction "read discrete input" demande l'adresse de la première entrée et le nombre d'entrées à lire.

Voilà... je vois à quoi sert la fonction "read discrete input" mais c'est ce qui suit dans le packet que je ne comprend pas. Quelle entrée ?

Je suis désolé si je m'explique mal, mais c'est encore confus pour moi :/

Je crois qu'en bref, si le client m'envoi un packet avec la fonction "read discrete input" (pour commencer avec une seule fonction), comment je traite la trame ensuite ? comment je dois le gérer côté serveur ? que peut me dire la trame "data" ? Que dois-je faire si je veux lire l'état de 2 broches de mon PIC ?

Merci encore !

[Jack]

Il faut comprendre que toutes les entrées et le sorties, ainsi que les registres sont accessibles par leur adresse définie dans une table.

Par exemple, si un esclave possède 16 entrées, celles-ci pourront se trouver aux adresses 1 à 16. S'il possède 32 sorties, elles pourront se trouver de 101 à 132. Et si cet esclave peut stocker 32 mots de 16 bits (compteurs, etc.), on pourrait les trouver de 1001 à 1032.

J'au choisi ces valeur arbitrairement. En fait, on peut prendre ce qu'on veut du moment que les adresses ne se chevauchent pas.

Si tu écris le code de l'esclave, à toi de faire correspondre RB0 de ton PIC à l'adresse correspondante, pareil pour RB1, etc.

[A voir en vidéo sur Futura]

[invite6f4ace37]

Merci pour ta réponse Jack, ça s'éclaircit un peu.

Les dites "adresses" pour le pic... c'est enfaîte une variable ? un tableau ? ou un registre du PIC ?

Donc la trame "data" de mon packet va dire que le client souhaite lire telle adresse qui contient l'état de mon entrée ?

[Jack]

Les dites "adresses" pour le pic... c'est enfaîte une variable ? un tableau ? ou un registre du PIC ?

C'est ce que tu veux: des mémoires, des registres (compteur ou autres). C'est à toi de faire correspondre l'adresse logique de la requête MODBUS en adresse physique de ton PIC.

[invite6f4ace37]

Donc du coup le ModBus se résume à faire un gros "Switch() case:" et d'agir selon l'adresse et s'il s'agit de l'adresse 0x1002 alors je renvoi RB0 par exemple ?

[Jack]

Donc du coup le ModBus se résume à faire un gros "Switch() case:" et d'agir selon l'adresse et s'il s'agit de l'adresse 0x1002 alors je renvoi RB0 par exemple ?

Oui. Enfin, il y a encore beaucoup de choses à faire: décoder la trame, vérifier si elle est cohérente, en principe il faudrait vérifier si les timings sont respectés (ça n'est pas toujours fait car c'est du boulot), constituer la trame à renvoyer, la renvoyer.

[invite6f4ace37]

Oui aussi c'est vrai, je voulais m'assurer de bien comprendre comment fonctionnait le code d'un esclave.

Merci vraiment pour ta patience et tes réponses. Je vais commencer à m'y mettre.

Je reviendrai ici si j'ai des questions ! Merci !

[Jack]

Pas de problème