Page 2 sur 4
Re: Perte de liaison TCP sur AG_LSEND
Posté : 12 sept. 2019, 15:19
par bipcoyote
Bonjour,
Peux tu nous mettre l'image de ta configuration NetPro avec la déclaration de ta liaison avec les propriétés de ta liaison ?
Merci.
+
Re: Perte de liaison TCP sur AG_LSEND
Posté : 12 sept. 2019, 15:41
par Damall
Re: Perte de liaison TCP sur AG_LSEND
Posté : 12 sept. 2019, 16:18
par djé
Il y a une possibilité aussi que cela vienne du PC qui ne garde pas le port ouvert en permanence.
Que fais-tu lorsque cela arrive pour relancer la com?
Re: Perte de liaison TCP sur AG_LSEND
Posté : 12 sept. 2019, 16:20
par bipcoyote
Bonjour,
En reprenant une de tes anciennes réponse
Damall a écrit : ↑12 sept. 2019, 08:39
Salut,
quand je dis que ça fonctionne à l'arrêt, c'est pour dire que l'automate envoi que le chien de garde.
Pour faire des essais machine à l'arrêt, j'ai forcé l'envoi de requête des données de production et de marche/arrêt de la machine.
Et là, ça plante aussi.
Il n'y a pas de problème de CEM, car tous les switchs sont au même endroit et on part en fibre optique vers l'informatique.
++
Donc cela ne fonctionne pas du tout.
1-le firewall bloque t il le port 502 ?
2-en mp privé, envoi moi ton archive si tu veux et je regarderai si je vois un truc qui me chiffonne.
+
Re: Perte de liaison TCP sur AG_LSEND
Posté : 12 sept. 2019, 16:22
par bipcoyote
Re,
P.S. pour voir ton réseau si autre chose est dessus, utilise Proneta de Siemens, tu verra au moins le matériel siemens.
+
Re: Perte de liaison TCP sur AG_LSEND
Posté : 13 sept. 2019, 07:15
par Damall
Je n'ai pas la main sur le routeur et le switch, faut que je passe par le service informatique.
Lorsque je perd la liaison, j'attends une seconde avec de réactiver le bloc AG_LRECV.
J'ai fait un essai en diminuant le nombre de message émis. J'ai laissé les deux messages en réception.
Et moins j'ai de message a émettre et moins j'ai de défaut.
Comme je vais avoir de plus en plus de message à émettre, ce week-end je vais changer la carte et mettre une carte 1Gbit/s (6GK7 443-1GX30-0XE0)
Et je forcerais l'échange en FULL_DUPLEX.
On verra bien, mais je doute que cela change quelques choses.
Re: Perte de liaison TCP sur AG_LSEND
Posté : 13 sept. 2019, 09:21
par bipcoyote
Bonjour,
Demande au service informatique, un compte rendu sur l'activité des ports connectés que tu utilises.
Dis nous ce qu'il en est.
+
Re: Perte de liaison TCP sur AG_LSEND
Posté : 13 sept. 2019, 09:42
par Damall
J'ai fait une demande à l'informatique, on verra bien ce qu'il en remonte.
Par ailleurs est-ce que vous avais comment synchroniser l'heure des CP avec celle de l'automate car le tampon de diagnostique de la CP me mets l'année 1984. Ce qui est pas très pratique pour le diagnostique.
Re: Perte de liaison TCP sur AG_LSEND
Posté : 13 sept. 2019, 10:09
par bipcoyote
Bonjour,
Regarde
https://support.industry.siemens.com/cs ... 0&lc=fr-WW
Sinon regarde clic droit sur ta CP, tu as synchronisme de l'horloge.
+
Re: Perte de liaison TCP sur AG_LSEND
Posté : 13 sept. 2019, 12:18
par djé
Bonjour,
Est-ce que dans l'onglet "Options" du CP tu as une valeur non nulle pour l'émission de Keep Alive des liaisons.
Ce qui serait vraiment intéressant à tester c'est une connexion directe avec le PC MES via un switch classique sans Routeur/Firewall.
Je pense qu'il n'y a pas de problème côte Siemens mais plutôt côte PC (le PC ferme le socket de liaison pour une raison x/y) ou matériel de liaison (config switch/firewall sur des ports je ne connais pas l'architecture exacte)
KeepAlive
2.4. Éviter une déconnexion due à une inactivité réseau.
L'autre objectif utile de keepalive est d'éviter que l'inactivité ne provoque une déconnexion. C'est un cas fréquent d'être déconnecté sans raison lorsque vous vous trouvez derrière un proxy NAT ou un pare-feu. Ce comportement est dû aux procédures de surveillance des connexions des proxies et pare-feu, qui tiennent un inventaire des connexions qui les traverse.
En raison des limites physiques de leurs ressources, ces machines ne peuvent conserver en mémoire qu'un nombre déterminé de connexions. La règle la plus courante et la plus logique est de maintenir les connexions les plus récentes et de mettre d'abord fin aux connexions les plus anciennes ou inactives.
Pour revenir à nos hôtes A et B, reconnectons les. Une fois le lien établi, attendons qu'un évènement se produise pour le transmettre à l'hôte distant. Qu'en est-il si cet évènement se produit après un long moment ? Notre connexion a sa propre durée, qui est inconnue du proxy. Lorsque nous finissons par transmettre des données, le proxy n'est plus capable de les traiter correctement, et la connexion est rompue.
Puisque le fonctionnement normal est de mettre en tête de liste la connexion par laquelle transitent des paquets, et de choisir la dernière connexion de la file quand il faut en supprimer une, le fait d'envoyer périodiquement des paquets sur le réseau est un bon moyen pour toujours rester en phase avec un risque minime de suppression.