Problème reception données TCP
Problème reception données TCP
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?
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?
Re: Problème reception données TCP
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.
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.
- djé
- 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
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.
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.
Dans le cas d'une liaison ISO-on-TCP le signal NDR devrait théoriquement passer à un à chaque fin de réception de trame.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 !
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 ...
Dans tout ce que vous apprenez, seuls 10% vont vous servir,mais vous ne savez pas lesquels ...
-
- Mi homme - Mi automate
- Messages : 2076
- Inscription : 21 oct. 2015, 10:00
- Localisation : Ile de France
Re: Problème reception données TCP
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 !
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 !
Re: Problème reception données TCP
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.
Je vais essayer de faire ça dès que la machine est dispo.
Merci pour les infos.
-
- Mi homme - Mi automate
- Messages : 2076
- Inscription : 21 oct. 2015, 10:00
- Localisation : Ile de France
Re: Problème reception données TCP
Quand tu dis que ça fonctionne pas ?
Pas du tout ou tes données sont erronées ?
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 !
Re: Problème reception données TCP
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.
C'est comme si le dernier AG_RECV était le seul actif.
- itasoft
- Mi homme - Mi automate
- Messages : 7037
- Inscription : 20 oct. 2015, 10:15
- Localisation : Lyon
- Contact :
Re: Problème reception données TCP
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
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
itasoft@free.fr
-
- Mi homme - Mi automate
- Messages : 2076
- Inscription : 21 oct. 2015, 10:00
- Localisation : Ile de France
Re: Problème reception données TCP
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 !
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 !