Stratégie de dialogue Modbus TCP entre PC et API
Stratégie de dialogue Modbus TCP entre PC et API
Bonjour à tous,
Je développe une application qui tourne sur un pc et récupère des données côté automate via modbus tcp. Je récupère ces données toutes les 500ms.
Je dialogue avec deux types d'api :
Schneider M300
Siemens S7-1500
Aujourd'hui, toutes les 500ms :
- Je me connecte à l'api
- je fais un Read Holding Register
- Je me déconnecte
- Je traite
Que pensez-vous de cette approche ?
Est il préférable de maintenir la connexion en permanence à la place de se déco/reco aussi souvent ? si oui pourquoi ?
Merci.
Je développe une application qui tourne sur un pc et récupère des données côté automate via modbus tcp. Je récupère ces données toutes les 500ms.
Je dialogue avec deux types d'api :
Schneider M300
Siemens S7-1500
Aujourd'hui, toutes les 500ms :
- Je me connecte à l'api
- je fais un Read Holding Register
- Je me déconnecte
- Je traite
Que pensez-vous de cette approche ?
Est il préférable de maintenir la connexion en permanence à la place de se déco/reco aussi souvent ? si oui pourquoi ?
Merci.
-
- Dieu du process
- Messages : 981
- Inscription : 12 nov. 2015, 21:02
- Localisation : 45 - Loiret
- Contact :
Re: Stratégie de dialogue Modbus TCP entre PC et API
Bonjour.
A l'époque lointaine ou les processeurs étaient lents et le débit des réseau était faibles, économiser quelques trames d'ouverture de de fermeture des connexions ça permettait de faire un peu moins ramer le serveur.
Aujourd'hui bon... Tu gaspille un peu de temps d'exécution et de transfert des données, mais avec une requête toute les 500 ms tu va pas mettre tes automates a genoux. Il devrait leur rester assez de temps pour exécuter tout ça sans faire 'péter le chien de garde'
Si tu faisait une requête toute les 1ms, la question se poserai sérieusement.
A l'époque lointaine ou les processeurs étaient lents et le débit des réseau était faibles, économiser quelques trames d'ouverture de de fermeture des connexions ça permettait de faire un peu moins ramer le serveur.
Aujourd'hui bon... Tu gaspille un peu de temps d'exécution et de transfert des données, mais avec une requête toute les 500 ms tu va pas mettre tes automates a genoux. Il devrait leur rester assez de temps pour exécuter tout ça sans faire 'péter le chien de garde'
Si tu faisait une requête toute les 1ms, la question se poserai sérieusement.
Re: Stratégie de dialogue Modbus TCP entre PC et API
Ok merci. Les api de ma boîte sont généralement très chargés. Aujourd'hui, mon app fonctionne correctement. Pour moi l’intérêt de faire de la sorte était de ne pas devoir vérifier l'état de la connexion en permanence.MiGaNuTs a écrit : ↑16 oct. 2020, 14:19 Bonjour.
A l'époque lointaine ou les processeurs étaient lents et le débit des réseau était faibles, économiser quelques trames d'ouverture de de fermeture des connexions ça permettait de faire un peu moins ramer le serveur.
Aujourd'hui bon... Tu gaspille un peu de temps d'exécution et de transfert des données, mais avec une requête toute les 500 ms tu va pas mettre tes automates a genoux. Il devrait leur rester assez de temps pour exécuter tout ça sans faire 'péter le chien de garde'
Si tu faisait une requête toute les 1ms, la question se poserai sérieusement.
Par contre, il semblerait que généralement, on laisse une connexion modbus tcp ouverte en permanence, d'où mon interrogation.
Re: Stratégie de dialogue Modbus TCP entre PC et API
Salut
Moi je laisse la connexion ouverte en permanence.
De mémoire je suis a environ 50ms en chaque requete.
L'appli tourne sur un Windows Serveur 2003 et interroge un PFC100 de chez Wago. (VB.NET + Lib Easymodbus de rossmann)
Moi je laisse la connexion ouverte en permanence.
De mémoire je suis a environ 50ms en chaque requete.
L'appli tourne sur un Windows Serveur 2003 et interroge un PFC100 de chez Wago. (VB.NET + Lib Easymodbus de rossmann)
Re: Stratégie de dialogue Modbus TCP entre PC et API
Salut, Merci de ton retour.filou59 a écrit : ↑19 oct. 2020, 21:20 Salut
Moi je laisse la connexion ouverte en permanence.
De mémoire je suis a environ 50ms en chaque requete.
L'appli tourne sur un Windows Serveur 2003 et interroge un PFC100 de chez Wago. (VB.NET + Lib Easymodbus de rossmann)
J'utilise aussi cette lib. Dans easymodbus, La propiété connected (indique que le client est connecté au serveur) est toujours vrai (bug). Comment tu t'assures que le serveur modbus est toujours dispo (un ping ? sachant que si le serveur est un pc, un ping indique que le pc est sur le réseau, mais pas que le serveur modbus est opérationnel).
- itasoft
- Mi homme - Mi automate
- Messages : 7037
- Inscription : 20 oct. 2015, 10:15
- Localisation : Lyon
- Contact :
Re: Stratégie de dialogue Modbus TCP entre PC et API
J'utilise aussi cette lib. Dans easymodbus, La propiété connected (indique que le client est connecté au serveur) est toujours vrai (bug). Comment tu t'assures que le serveur modbus est toujours dispo (un ping ? sachant que si le serveur est un pc, un ping indique que le pc est sur le réseau, mais pas que le serveur modbus est opérationnel).
----------
Disons que moi je fais ce contrôle avec un "mot de vie"
----------
Disons que moi je fais ce contrôle avec un "mot de vie"
Automaticien privé (de tout)
itasoft@free.fr
itasoft@free.fr
Re: Stratégie de dialogue Modbus TCP entre PC et API
Il faut que je regarde comment j'ai fait
Déjà je me met en place un petit chien de garde, un compteur qui s'incremente des 2 cotés, comme ca que ce soit coté Automate ou Coté Soft l'un et l'autre sont au courant si tout est ok ou pas.
Déjà je me met en place un petit chien de garde, un compteur qui s'incremente des 2 cotés, comme ca que ce soit coté Automate ou Coté Soft l'un et l'autre sont au courant si tout est ok ou pas.
Re: Stratégie de dialogue Modbus TCP entre PC et API
De mon côté j'incrémente un mot de vie pc côté API, pour que l'automate sache quand mon appli est déco.
Par contre, l'inverse ne me semble pas nécessaire. Si la com est out, l'application ne peut de toute façon pas lire le registre (donc que ce soit à l'adresse d'un mot de vie ou à l'adresse de l'infos que j'ai besoin ne change rien).
Le problème est que je n'ai pas l’info factuel que je suis déconnecté.
Ce que je fais :
Je fais un readHoldingRegister toutes les 500ms. Si je lève une exception à ce moment, je force une déconnexion et je me reconnecte. Ça n'arrive jamais, mais si ça doit arriver, je me reconnecte de toute façon. Mais c'est vrai que ne pas connaître précisément l'état de la connexion donne lieu à des contournements pas très "élégants".
Par contre, l'inverse ne me semble pas nécessaire. Si la com est out, l'application ne peut de toute façon pas lire le registre (donc que ce soit à l'adresse d'un mot de vie ou à l'adresse de l'infos que j'ai besoin ne change rien).
Le problème est que je n'ai pas l’info factuel que je suis déconnecté.
Ce que je fais :
Je fais un readHoldingRegister toutes les 500ms. Si je lève une exception à ce moment, je force une déconnexion et je me reconnecte. Ça n'arrive jamais, mais si ça doit arriver, je me reconnecte de toute façon. Mais c'est vrai que ne pas connaître précisément l'état de la connexion donne lieu à des contournements pas très "élégants".