Modbus TCP Slave : DLL ou JAR

[Aurélien]

Bonjour à tous !

J'essaie de faire mon propre serveur Modbus TCP esclave afin de récupérer des trames d'écriture envoyées par des API Unitronics en Modbus TCP.

Les mots sont ensuite analysés par le serveur et sauvegardés dans une base de donnée MySQL.

Je voulais savoir si certains d'entre-vous aviez déjà réalsié cela et, donc, une DLL ou une librairie JAR qui fonctionne, pour la partie Modbus ?

Merci par avance

[filou59]

Salut

Juste pour etre sur :
-Tu veux faire un Esclave qui répond au question d'un Maitre ?
C'est ton maitre (API) qui va envoyer des valeur a stocker ds ta base de donnée ?

-Ou tu veux Faire un Maitre qui envoi des question a un ou des esclave (API Unitronics) pour ensuite stocker les réponses dans ta base de donnée ?
Car en général c'est le serveur qui est maitre

Car en général c'est plutot le 2nd cas que l'on cherche a faire

J'ai pas de dll, mais tu peux trouver des truc interessant sur GITHub ou sur des plateforme de code source, voici un ou 2 truc que j'avais déjà repéré :
https://github.com/graham22/ModbusTool
http://www.codeproject.com/Tips/16260/Modbus-TCP-class
voir aussi sur sourceforge....

[Aurélien]

Pour avoir quelque chose de réactif qui ne surcharge pa le réseau, j'ai pensé à la configuration suivante :

API Modbus Master ---- envoi une requête d'écriture de mots ---> Serveur Modbus Slave ---- envoi une requête d'ajout ---> Serveur MySQL <---- Client Web

Le serveur est passif. Il attend que les automates envoient les informations.

Les automates stockent les données dans une table tampon en cas de non-réponse du serveur.

Les données sont horodatées dans l'automate (le serveur ne réalise pas d'horodatage).


Merci pour les informations, j'ai effectivement trouvé des éléments. Je voulais savoir s'il y en a qui en utilisait (et qui avait donc un retour d'expérience sur la fiabilité )

[filou59]

ok

De mon coté j'utilise du modbus régulierement (je suis en industrie), on a pas mal de système que l'on supervise.
Dans 100% des cas c'est un serveur informatique (une supervision) qui initie la demande de communication, c'est pour ca que j'etais surpris par ta demande.

La fiabilité du modbus n'est plus a démontré, je n'ai jamais cherché a mesuré la charge sur le réseau, mais les packet qui transitent ne représente pas grand chose par rapport a des transfert de fichier.

Je peux comprendre ton besoin dans le cas ou le serveur ne serait pas allumé 24/24, et si tu utilise une table tampon, mais dans ce cas cela implique de transferer valeur + horadatage. Sinon a quoi bon si tu ne les transfere pas sur le serveur ?

Après une autre raison pour laquelle on choisi le serveur en maitre, c'est que si tu as 100 automate, tu vas les interroger 1 a la foi en général.
Mais si ce sont tes automates qui sont maitre, cela implique d'avoir un serveur capable d'ouvrir potentiellement 100 socket afin de répondre a tous les automate ...

[Mantysse]

Dans 100% c'est le serveur qui initie la demande de communication.

Euh va falloir m'expliquer comment ça marche...
Pour info quand même avant de diffuser une information approximative
https://fr.wikipedia.org/wiki/Modbus

[filou59]

Je comprend ca peut surprendre

En modbus un serveur c'est un esclave.
Tandis que le client est un maitre.

L'esclave est là pour répondre aux question du maitre. Il joue le role de Serveur Modbus.

Si tu as un automate ou un serveur qui va jouer le role de serveur (au sens informatique) afin de centraliser les info de plusieurs autre equipement modbus ou autre, ton automate ou ton serveur joueront le role des Modbus Master (des Clients) qui vont interroger des Modbus Slave qui joueront le role de server (Server si on se place d'un point de vue modbus).

Tu as de plus en plus d'automate équipé de port reseau (comme chez WAGO par exemple) qui integre nativement un serveur modbus. C'est a dire qu'ils sont capable de répondre a un n'importe quel client modbus.

Le terme Client/Server en modbus peut porter a confusion, il est préférable de parler de Master/Slave je pense, vue que les schémas ou doc ne parlent pas toujours des 2 termes en meme temps, si l'on ne voie que le client/server on peut facilement s’emmêler les pinceaux.

[Mantysse]

Le terme Client/Server en modbus peut porter a confusion, il est préférable de parler de Master/Slave je pense, vue que les schémas ou doc ne parlent pas toujours des 2 termes en meme temps, si l'on ne voie que le client/server on peut facilement s’emmêler les pinceaux.

Ben on peut dire que c'est préférable ou pas, c'est la norme Modbus, sur Ethernet c'est client/serveur, en série c'est Maitre/Esclave^^ désolé c'est pas moi qui choisi
Sinon on peut se faire une petite convention perso, et ne plus ce faire comprendre des autres ^^

[filou59]

Dans 100% c'est le serveur qui initie la demande de communication.

Euh va falloir m'expliquer comment ça marche...
Pour info quand même avant de diffuser une information approximative
https://fr.wikipedia.org/wiki/Modbus

J'ai pas été assez précis, je parlais bien sur d'un serveur en tant qu'ordi. Un serveur par exemple équipé d'une supervision.

C'est bien le superviseur (Modbus Master/Client) qui pose les questions a un tat de Slave (Modbus Slave/Server)

Ben on peut dire que c'est préférable ou pas, c'est la norme Modbus, sur Ethernet c'est client/serveur, en série c'est Maitre/Esclave^^ désolé c'est pas moi qui choisi
Sinon on peut se faire une petite convention perso, et ne plus ce faire comprendre des autres ^^

Regarde cette capture extrait d'une doc :

Petit Schéma extrait d'une DOC

Les 2 termes sont employé pour une communication Modbus TCP. Je n'ai rien inventé.

[Aurélien]

Oui, je suis conscient que les termes portent à confusion avec le Modbus TCP.

Dans mon cas, je ne vois pas l'intérêt d'intéroger régulièrment les automates car les données changeront que toutes les heures, au pire toutes les quelques minutes.

Je suis ouvert à toute autre idée de solution, facilement compatible avec différentes marques

Sachant que le but est de récupérer des événements dans un automate (ID machine, ID événement, date début, date fin, commentaire) et l'enregistrer dans une base de donnée MySQL.

[Aurélien]

Dans 100% des cas c'est un serveur informatique (une supervision) qui initie la demande de communication, c'est pour ca que j'etais surpris par ta demande.

Cela vient aussi que dans la majorité des cas, on cherche à superviser une installation et à récupérer un certain nombre d'informations via un superviseur.

Là ce n'est pas le même cas. On veut juste analyser les temps de marche/arrêt.

Peut-être qu'un jour on me demandera d'ajouter un superviseur pour connaître en direct l'état des machines. Dans ce cas nous pourrions installer un superviseur qui se chargera de scruter comme bon lui semble les données pour l'affichage. Il pourra alors récupérer la liste d'événements à transférer dans une BDD.