[M580] Performances Modbus TCP

[dpo]

Bonjour
en attendant une réponse du support, je pose la question ici :
j'ai une application avec un M580 qui communique avec une quarantaine d"équipements en modbus/TCP et Ethernet/IP via le navigateur de DTM. Le programme est un peu costaud mais pas monstrueux.
il y a 3 écrans KEP qui tapent dans le M580 en modbus TCP et une supervision pcvue en modbus/TCP avec presque 17000 variables sur ce seul automate.
Malgré quelques optimisations sur les trames côté pcvue, j'ai un peu de latence sur la supervision.
Si je monte un banc de test avec pcvue qui tape dans un M340 qui n'a pas de de programme ni esclavee, il me semble que c'est plus réactif.
Donc je me dis que le réseau côté M580 doit être ralenti par tous ses esclaves et son programme et qu'il répond "quand il peut" à la supervision.
La question est de savoir si l'ajout d'une carte NOC sur le M580 dédiée à la supervision permettrait d'améliorer les performances ?

[itasoft]

slts,
A savoir les IHM ou supervision échange avec l'automate toutes les variables externes déclarées, ça veut dire qu'il est chaudement recommandé que toutes ces variables soient consécutives pour limiter le nombre de requêtes ModBus.
Si via un Script périodique si on écris dans des variables automate il est préférable de ne le faire que sur changement d'état de la variable sinon c'est prioritaire et ça monopolise la COM, disons que c'est ce que j'ai remarqué chez moi mais il se peut que je me trompe et que c'est une impression.

[philou77]

salut !

Pourquoi, avec la supervision, ne pas taper dans les keps.. qui eux tapent dans l'automate ?
c'est peut être pas possible mais si oui, cela libèrerait de la com Automate...

[dpo]

Les keps ont beaucoup moins de variables et des fonctions volontairement limitées.
Malgré tout, ils peuvent servir de secours si la supervision est plantée et réciproquement.
La problématique existait avant de mettre le KEP
les infos sont bien regroupées par trames avec des adresses consécutives.
il y a 3 ou 4 écritures cycliques à 5 secondes, en effet je pourrais améliorer en n’écrivant que si la valeur n'est pas déjà bonne, mais la problématique existait aussi avant.
Ce qui est intéressant c'est cette différence entre taper dans le M580 sur la carte (CPU) qui fait le prog, les E/S et la supervision
ou taper dans un simple M340 qui ne fait rien.
j'ai déjà fait des applis en siemens ou schneider où réseaux E/S et réseaux supervision étaient séparés pour être plus propre, dans la cas ci-dessus je me demande si ça ne pourrait pas améliorer les performances de la com supervision.

[djé]

Salut,
Il y a de fortes chances que taper dans un coupleur décharge la cpu de la gestion de la communication et améliore les temps de réaction.

[RG2i]

Bonjour,

Je vais peut être dire une bêtise, mais pourquoi ne pas utiliser de l'OPC-UA plutôt, qui ne génère pas de trafic inutile ?

[dpo]

Bonjour,

Je vais peut être dire une bêtise, mais pourquoi ne pas utiliser de l'OPC-UA plutôt, qui ne génère pas de trafic inutile ?

je ne me suis pas posé la question à la base du Modbus TCP entre un schneider et Pcvue c'est une valeur sûre.
en effet schneider a sorti un coupleur OPC-UA mais je méfie des supers nouveaux trucs de schneider (et autres) ça pue le patch, le correctif...
Je fais parti des vieux ronchons qui en ont marre de faire bêta-testeur pour les fabricants.
D'autant plus que le Modbus TCP est natif sur la cpu.
C'est la première fois que je tape autant de variables dans un seul automate avec cette architecture, comme pcvue fonctionne bien en tapant dans une CPU sans programme et sans E/S, je me dis qu'il y a moyen de faire mieux côté M580
Les performances restent correctes mais j'aimerai faire mieux,

[MiGaNuTs]

Bonjour.

Simple question, est tu sur que c'est bien ton automate qui "rame" ?
Peut être que tu arrive a saturer ta connexion Ethernet. Tu a une idée de la charge de ton switch ?

D'une manière générale c'est plutôt une bonne idée de séparer le réseau de com' avec les Entrées/Sorties de celui avec les IHM et la supervision.

En général j'utilise la NOC en I-O scanning pour mes E/S déportées et les drives, et le port "natif" de ma CPU pour les IHM.
J'ai déjà fait des config avec une NOC supplémentaire pour la supervision. Du coup avec un 3eme réseau.

[dpo]

bonne remarque pour le switch, je ferais un essai en mettant mon banc de test sur le réseau de l'usine pour comparer
tant que je mettais des M340 je tapais dans la CPU pour la supervision et une NOC pour les E/S
sur ce projet comme le M580 fait aussi i/o scan nous sommes partis sans NOC

Retour du support allant dans le bon sens :
une noc pour la com avec la supervision ne fera pas de mal (même si on privilégie plutôt la supervision sur la cpu et la noc pour les E/S)
séparer les réseaux E/S et supervision physiquement et/ou via le switch manageable