TSX 57 Premium Communication à l'automate échoue.

[Nikolo]

Bonjour à tous,

Je vous sollicite aujourd'hui car j'ai un soucis sur l'un de mes automates TSX 57 (Premium). Il est raccordé au réseau Ethernet de l'usine via un coupleur ETY 4103 et je cherche à m'y connecter à distance depuis un PC.

L'automate parvient à établir la connexion au PC, seulement lors du transfert de l'automate, seuls quelques kB sont transférés, après quoi la communication échoue subitement. La connexion PC - Automate ne se maintient que quelques secondes. Ce n'est pas tout le temps au même moment lors du transfert des données.

Le message indiqué par PL7 Pro 4.5 est un message du genre : "La communication avec l'automate a échoué".

J'ai quelques automates TSX 57 avec une configuration similaire ailleurs dans l'usine. Ceux-ci ne me posent aucun problème et peuvent être connectés à mon PC indéfiniment. Ce n'est pas le cas de celui-ci et je ne comprends pas pourquoi.

A noter que :
1) j'ai une supervision qui interroge mon automate et récupère un certain nombre de données. J'ai réduit ce nombre de données à une cinquantaine de mots, mais le problème persiste.
2) J'ai un autre automate qui lance des requêtes en IO-scanning sur mon coupleur, avec 50 mots en lecture/écriture pour échanger avec d'autres process dans l'usine. Je n'ai pas encore eu l'occasion de couper la requête d'io-scanning et de voir si ça résout le problème.
3) Le coupleur est en derniere position sur le rack (position n°10), je ne sais pas si ça peut être à l'origine du problème ?


J'ai essayé de suivre les trames de communication en mirroring avec Wireshark mais cela dépasse mes compétences, pour le moment, étant novice en communication réseau. Je peux seulement remarquer que lors du transfert de données, je fais remonter tout un tas de trames [PSH,ACK] donc je déduis que ce sont les trames contenant le programme automate qui est transféré.
Cependant à un moment ça bloque et j'ai une trame [FIN, ACK] donc une demande d'interruption de la communication qui doit provenir du PC, ou bien du coupleur ETY.

Auriez-vous une idée de l'origine du problème ?

Bien à vous,
Nikolo

[Laurent]

Salut,

quelle est la référence du processeur ?
Selon le modèle, le serveur MODBUS géré par le processeur est limité en nombre de connexions, s'il y en a trop, il coupe certaines connexions ou le processeur plante.

Avec Wireshark, tu peux regarder le nombre de connexions MODBUS/TCP que le module ETY4103 gère en ouvrant la fenêtre des conversations pendant la capture (menu Statistiques > Conversations, l'onglet TCP liste les sessions TCP observées pendant la capture).
Toutes les connexions se faisant sur l'adresse IP de ton API, port 502 sont des sessions MODBUS/TCP s'adressant au serveur MODBUS de ton API.

Attention à bien utiliser un hub, ou un switch avec le mirroring activé.

[MiGaNuTs]

Bonjour.
Ton coupleur ne peut répondre qu'a un certain nombre de requetes/secondes. A un moment quand on lui demande trop de trucs, il ne sait plus répondre a tout le monde.
Ca m'est déja arrivé. les symptomes ressemblent beaucoup a ce que tu décrit.
Dans un monde idéal tu devait avoir un coupleur dédié a la supervision, et un autre coupleur dédié a l'automate "maitre" qui viens interroger ta cpu, ca c'est pour le coté "performances de l'instalation"
Du point de vue cybersécurité tes coupleurs devraient etre chacun dans des sous réseaux isolés et indépendants (ca deviendra une obligation légale et un prérequis pour les assurances dans quelques temps du reste. La dissolution de l'an dernier nous a donné un surcis, mais ca reviendra forcement a l'ordre du jour a un moment)