Problème reception données TCP

Forum traitant des automates industriels de marque Siemens.
Avatar de l’utilisateur
Damall
Codeur fou
Codeur fou
Messages : 220
Inscription : 13 janv. 2016, 09:22
Localisation : Luxembourg

Problème reception données TCP

Message par Damall »

Bonjour,

j'ai un soucis de réception de données avec une CP443-1EX20.

J'ai mon automate qui est sur un réseau avec un PC (niveau 3). Ce PC envoi et reçoit des données de production. Pour s'assurer de la liaison, l'automate lui envoi toutes les minutes un message de 32 octets avec l'horodatage de l'automate. Le PC fait de même, il envoi toutes les minutes un message vers l'automate avec l'horodatage du PC, et toutes les 15 minutes, les données de production pour l'automate.
J'utilise les fonctions AG_LSEND et AG_LRECV.

Côté PC, il reçoit bien tous les messages qu'envoi l'automate.

Par contre côté automate, je reçois des données aléatoirement. J'ai mis un DB de réception de 2000 octets. Quand je reçois des données, elle ne commence pas à l'octet 0, c'est comme si la carte CP mettais tout dans un buffer, et envoyer tout d'un seul coup, car quand je reçois quelques choses, c'est plusieurs messages en même temps, et c'est comme s'il les mettais à la suite de la dernière réception. Le statut du bloc AG_LRECV est correct (16#8181 et 16#8180), pas d'erreur, ni de perte de la liaison.

J'ai mis un analyser de trame (Wiresharks) sur le réseau, et on vois bien que le PC envoi toutes les minutes un message de 32 octets.

Est-ce qu'il y a un paramétrage particulier à faire sur la CP?
Avatar de l’utilisateur
Damall
Codeur fou
Codeur fou
Messages : 220
Inscription : 13 janv. 2016, 09:22
Localisation : Luxembourg

Re: Problème reception données TCP

Message par Damall »

Bonjour,

J'ai un peu plus d'info.

Donc apparemment tout se joue avec la taille de réception du bloc AG_RECV qui est paramètre. Car si je mets la taille de ce DB de réception (qui doit correspondre à la taille du buffer de la carte CP) à 32 octets, Je reçois bien toutes les minutes le message de 32 octets.
Hors quand arrive le message de 648 octets, et bien il écrit dans la table de 32, et une fois à la fin des 32 il recommence à remplir la table depuis le début, jusqu'à finir ces 648 octets.
Donc si je change la taille du buffer, et que je mets 648 octets, et bien je reçois les messages une fois que le buffer de 648 octets est rempli (648/32=20) donc si tous les 15 minutes je reçois la trame de 648 octets, ce qui je veux dire que toutes les 15 minutes, je reçois un message de 648 octets + 15*32 octets et je ne sais pas dans quel ordre.
Donc en gros, il faudrait que je puisse mettre une taille fixe de buffer. Que je puisse depuis l'API lire le buffer de la carte CP, puis le vider, mais je ne sais pas comment faire, ou même si ça peux se faire.
Il faudrait presque un buffer à taille variable en fonction des données que je reçois.
Bref, je ne sais pas comment faire. :?: :?: :?: :?: :?:
Avatar de l’utilisateur
djé
Dieu du process
Dieu du process
Messages : 776
Inscription : 20 oct. 2015, 09:55
Localisation : Bretagne, Pays de la Loire, Nantes

Re: Problème reception données TCP

Message par djé »

Salut,

La liaison que tu utilises est de quel type? Il faudrait que tu paramètres une liaison ISO-on-TCP plutôt que TCP.
Liaison TCP: Pendant la transmission de données, aucune information sur la longueur, le début ou la fin d'un message n'est transmise. [...] Le récepteur n'a cependant aucun moyen de savoir où se termine un message dans le flux de données et où commence le message suivant
Liaison ISO on TCP:
Pendant la transmission de données, des informations sur la longueur et la fin d'un message sont transmises.
Cas particulier
Lorsque l'échange de données a lieu via une liaison TCP, le paramètre de sortie "NDR" n'est alors mis à un que lorsque le tampon de réception a été entièrement rempli ! La valeur du paramètre de sortie "LEN" indique ainsi toujours la longueur totale du tampon de réception !
Dans le cas d'une liaison ISO-on-TCP le signal NDR devrait théoriquement passer à un à chaque fin de réception de trame.
Le monde se divise en 10 catégories:les personnes qui comprennent le binaire,et les autres.

Dans tout ce que vous apprenez, seuls 10% vont vous servir,mais vous ne savez pas lesquels ...
philou77
Mi homme - Mi automate
Mi homme - Mi automate
Messages : 2076
Inscription : 21 oct. 2015, 10:00
Localisation : Ile de France

Re: Problème reception données TCP

Message par philou77 »

Salut !
un poil insoluble amha..

tu met l'automate en 'écoute' pour un message de 32 octets ET un message de 648 octets

tu peux paramétrer plusieurs blocs AG_LRECV en parallèle..
et si tu tentais d'en faire un de 32 octets et un de 648 octets ?

se remplissent-ils tout les deux pareils ? si oui, il va en plus falloir remettre dans le bon sens le buffer de 648 octets une fois reçu !
Si vous avez compris tout ce que je viens d'écrire, c'est que j'ai dû faire une erreur quelque part ! :D
Avatar de l’utilisateur
Damall
Codeur fou
Codeur fou
Messages : 220
Inscription : 13 janv. 2016, 09:22
Localisation : Luxembourg

Re: Problème reception données TCP

Message par Damall »

philou77 a écrit : 19 mars 2019, 11:27
tu peux paramétrer plusieurs blocs AG_LRECV en parallèle..
et si tu tentais d'en faire un de 32 octets et un de 648 octets ?
Déjà tester, ça ne fonctionne pas.
Avatar de l’utilisateur
Damall
Codeur fou
Codeur fou
Messages : 220
Inscription : 13 janv. 2016, 09:22
Localisation : Luxembourg

Re: Problème reception données TCP

Message par Damall »

Dès que je peux, j'essaie la liaison ISO-ON-TCP, mais j'ai vu aussi que l'on peux créer une liaison UDP et dans la configuration de la CP, on peux désactiver la mise en tampon UDP.

Je vais essayer de faire ça dès que la machine est dispo.

Merci pour les infos.
philou77
Mi homme - Mi automate
Mi homme - Mi automate
Messages : 2076
Inscription : 21 oct. 2015, 10:00
Localisation : Ile de France

Re: Problème reception données TCP

Message par philou77 »

Quand tu dis que ça fonctionne pas ?

Pas du tout ou tes données sont erronées ?
Si vous avez compris tout ce que je viens d'écrire, c'est que j'ai dû faire une erreur quelque part ! :D
Avatar de l’utilisateur
Damall
Codeur fou
Codeur fou
Messages : 220
Inscription : 13 janv. 2016, 09:22
Localisation : Luxembourg

Re: Problème reception données TCP

Message par Damall »

Alors, je pense qu'un seule bloc est actif, mais si on en déclare plusieurs, car toutes les trames arrive dans le même DB de réception.

C'est comme si le dernier AG_RECV était le seul actif.
Avatar de l’utilisateur
itasoft
Mi homme - Mi automate
Mi homme - Mi automate
Messages : 7037
Inscription : 20 oct. 2015, 10:15
Localisation : Lyon
Contact :

Re: Problème reception données TCP

Message par itasoft »

Slts,
J’entrave que couic en « teutons » mais d’après ce que j’ai compris, je dirais que si ya plusieurs requêtes à faire sur la même voie , le plus sur c’est avec un chenillard d’en faire une seule à chaque tour de cycle
Automaticien privé (de tout)
itasoft@free.fr
philou77
Mi homme - Mi automate
Mi homme - Mi automate
Messages : 2076
Inscription : 21 oct. 2015, 10:00
Localisation : Ile de France

Re: Problème reception données TCP

Message par philou77 »

Etrange, d'après la doc, on peut en faire plusieurs en parallèle..(d'après la doc du coupleur)
mais bon, jamais testé... alors il faudrait un 'pro' en com siemens..

https://support.industry.siemens.com/cs ... 0&lc=fr-WW
A priori,
l'appel se fait sur front, je suppose que tu déclares des db différents pour les deux appels ?
cela devrait fonctionner.. en théorie il y a rien qui gène...
tu as bien créé 2 liaisons dans netpro ou une seule ?

sauf peut être :
Cas particulier
Lorsque l'échange de données a lieu via une liaison TCP, le paramètre de sortie "NDR" n'est alors mis à un que lorsque le tampon de réception a été entièrement rempli ! La valeur du paramètre de sortie "LEN" indique ainsi toujours la longueur totale du tampon de réception !
Dernière modification par philou77 le 19 mars 2019, 15:11, modifié 1 fois.
Si vous avez compris tout ce que je viens d'écrire, c'est que j'ai dû faire une erreur quelque part ! :D
Répondre