Bonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
Bonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
Bonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
Certains automates ne me supportent pas.
Certains automates ne me supportent pas.
Certains automates ne me supportent pas.
Re,Certains automates ne me supportent pas.
C'est pas faux! Mais dans ce cas précis il fallait lire
"ne LE supportent pas" ;-)
Re,
Certains automates ne me supportent pas.
C'est pas faux! Mais dans ce cas précis il fallait lire
"ne LE supportent pas" ;-)
Re,Certains automates ne me supportent pas.
C'est pas faux! Mais dans ce cas précis il fallait lire
"ne LE supportent pas" ;-)
Bonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
Bonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
Bonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
Le 01/08/2014 10:23, Fredo a écrit :
Bonjour,
Quand je communique avec des automates (via modus TCP)
J'ouvre le socket de cette façon
SI SocketExiste(socket_name) = Faux ALORS
SI SocketConnect(socket_name,port,host,time_out) = Faux ALORS
status = "";
ExceptionDéclenche(err_connection,ErreurInfo(errMessage))
ELSE
status = "Connecté"+RC;
SocketChangeModeTransmission(socket_name,SocketSansMarqueurFin)
FIN
connected = True
RENVOYER Vrai
FIN
Cordialement,
PYTBonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
Le 01/08/2014 10:23, Fredo a écrit :
Bonjour,
Quand je communique avec des automates (via modus TCP)
J'ouvre le socket de cette façon
SI SocketExiste(socket_name) = Faux ALORS
SI SocketConnect(socket_name,port,host,time_out) = Faux ALORS
status = "";
ExceptionDéclenche(err_connection,ErreurInfo(errMessage))
ELSE
status = "Connecté"+RC;
SocketChangeModeTransmission(socket_name,SocketSansMarqueurFin)
FIN
connected = True
RENVOYER Vrai
FIN
Cordialement,
PYT
Bonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
Le 01/08/2014 10:23, Fredo a écrit :
Bonjour,
Quand je communique avec des automates (via modus TCP)
J'ouvre le socket de cette façon
SI SocketExiste(socket_name) = Faux ALORS
SI SocketConnect(socket_name,port,host,time_out) = Faux ALORS
status = "";
ExceptionDéclenche(err_connection,ErreurInfo(errMessage))
ELSE
status = "Connecté"+RC;
SocketChangeModeTransmission(socket_name,SocketSansMarqueurFin)
FIN
connected = True
RENVOYER Vrai
FIN
Cordialement,
PYTBonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
PYT a formulé ce lundi :Le 01/08/2014 10:23, Fredo a écrit :
Bonjour,
Quand je communique avec des automates (via modus TCP)
J'ouvre le socket de cette façon
SI SocketExiste(socket_name) = Faux ALORS
SI SocketConnect(socket_name,port,host,time_out) = Faux ALORS
status = "";
ExceptionDéclenche(err_connection,ErreurInfo(errMessage))
ELSE
status = "Connecté"+RC;
SocketChangeModeTransmission(socket_name,SocketSansMarqueurFin)
FIN
connected = True
RENVOYER Vrai
FIN
Cordialement,
PYTBonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
Bonjour,
Effectivement ce problème peut arriver quand il y a coupure de liaison,
Windev ne le détecte pas vraiment lorsque l'on fait un SocketExiste() ou
un SocketLit()
J'ai pu constater que quand la connexion était coupée, le temps de
lecture dans la fonction SocketLit() est largement inférieur à celui
demandé, par exemple on demande la lecteure pendant 1s et la fonction ne
met que quelque dixième, j'ai donc créée une fonction :
ChronoDebut(NumChrono)
Buff=SocketLit(ConvoyeurSocket:NomSocket,Faux,ConvoyeurSocket:TpsAttenteSocket)
Tps=ChronoValeur(NumChrono,Faux,-1)
// Erreur de connexion
SI PAS SocketControle(Tps,ConvoyeurSocket:TpsAttenteSocket)
####ERREUR###
FIN
PROCEDURE SocketControle(TempsReel est numérique (7,3), TempsAttenteSocket)
// Controle le temps de réaction sur la lecture d'une socket
// permet de savoir si la socket a été fermée par l'autre partie
// contrôle du temps par rapport à un temps de référence
// TempsAttenteSocket est en milisecondes : ex 1000
// Temps reel fourni par une fonction chrono ex : 1.000
// Renvoyer vrai = OK
SI 10 * TempsReel < TempsAttenteSocket/1000 ALORS
RENVOYER Faux
SINON
RENVOYER Vrai
FIN
PYT a formulé ce lundi :
Le 01/08/2014 10:23, Fredo a écrit :
Bonjour,
Quand je communique avec des automates (via modus TCP)
J'ouvre le socket de cette façon
SI SocketExiste(socket_name) = Faux ALORS
SI SocketConnect(socket_name,port,host,time_out) = Faux ALORS
status = "";
ExceptionDéclenche(err_connection,ErreurInfo(errMessage))
ELSE
status = "Connecté"+RC;
SocketChangeModeTransmission(socket_name,SocketSansMarqueurFin)
FIN
connected = True
RENVOYER Vrai
FIN
Cordialement,
PYT
Bonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
Bonjour,
Effectivement ce problème peut arriver quand il y a coupure de liaison,
Windev ne le détecte pas vraiment lorsque l'on fait un SocketExiste() ou
un SocketLit()
J'ai pu constater que quand la connexion était coupée, le temps de
lecture dans la fonction SocketLit() est largement inférieur à celui
demandé, par exemple on demande la lecteure pendant 1s et la fonction ne
met que quelque dixième, j'ai donc créée une fonction :
ChronoDebut(NumChrono)
Buff=SocketLit(ConvoyeurSocket:NomSocket,Faux,ConvoyeurSocket:TpsAttenteSocket)
Tps=ChronoValeur(NumChrono,Faux,-1)
// Erreur de connexion
SI PAS SocketControle(Tps,ConvoyeurSocket:TpsAttenteSocket)
####ERREUR###
FIN
PROCEDURE SocketControle(TempsReel est numérique (7,3), TempsAttenteSocket)
// Controle le temps de réaction sur la lecture d'une socket
// permet de savoir si la socket a été fermée par l'autre partie
// contrôle du temps par rapport à un temps de référence
// TempsAttenteSocket est en milisecondes : ex 1000
// Temps reel fourni par une fonction chrono ex : 1.000
// Renvoyer vrai = OK
SI 10 * TempsReel < TempsAttenteSocket/1000 ALORS
RENVOYER Faux
SINON
RENVOYER Vrai
FIN
PYT a formulé ce lundi :Le 01/08/2014 10:23, Fredo a écrit :
Bonjour,
Quand je communique avec des automates (via modus TCP)
J'ouvre le socket de cette façon
SI SocketExiste(socket_name) = Faux ALORS
SI SocketConnect(socket_name,port,host,time_out) = Faux ALORS
status = "";
ExceptionDéclenche(err_connection,ErreurInfo(errMessage))
ELSE
status = "Connecté"+RC;
SocketChangeModeTransmission(socket_name,SocketSansMarqueurFin)
FIN
connected = True
RENVOYER Vrai
FIN
Cordialement,
PYTBonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
Bonjour,
Effectivement ce problème peut arriver quand il y a coupure de liaison,
Windev ne le détecte pas vraiment lorsque l'on fait un SocketExiste() ou
un SocketLit()
J'ai pu constater que quand la connexion était coupée, le temps de
lecture dans la fonction SocketLit() est largement inférieur à celui
demandé, par exemple on demande la lecteure pendant 1s et la fonction ne
met que quelque dixième, j'ai donc créée une fonction :
ChronoDebut(NumChrono)
Buff=SocketLit(ConvoyeurSocket:NomSocket,Faux,ConvoyeurSocket:TpsAttenteSocket)
Tps=ChronoValeur(NumChrono,Faux,-1)
// Erreur de connexion
SI PAS SocketControle(Tps,ConvoyeurSocket:TpsAttenteSocket)
####ERREUR###
FIN
PROCEDURE SocketControle(TempsReel est numérique (7,3), TempsAttenteSocket)
// Controle le temps de réaction sur la lecture d'une socket
// permet de savoir si la socket a été fermée par l'autre partie
// contrôle du temps par rapport à un temps de référence
// TempsAttenteSocket est en milisecondes : ex 1000
// Temps reel fourni par une fonction chrono ex : 1.000
// Renvoyer vrai = OK
SI 10 * TempsReel < TempsAttenteSocket/1000 ALORS
RENVOYER Faux
SINON
RENVOYER Vrai
FIN
Le 22/01/2015 11:24, Pierre BOUSQUET a écrit :PYT a formulé ce lundi :Le 01/08/2014 10:23, Fredo a écrit :
Bonjour,
Quand je communique avec des automates (via modus TCP)
J'ouvre le socket de cette façon
SI SocketExiste(socket_name) = Faux ALORS
SI SocketConnect(socket_name,port,host,time_out) = Faux ALORS
status = "";
ExceptionDéclenche(err_connection,ErreurInfo(errMessage))
ELSE
status = "Connecté"+RC;
SocketChangeModeTransmission(socket_name,SocketSansMarqueurFin)
FIN
connected = True
RENVOYER Vrai
FIN
Cordialement,
PYTBonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
Bonjour,
Effectivement ce problème peut arriver quand il y a coupure de liaison,
Windev ne le détecte pas vraiment lorsque l'on fait un SocketExiste() ou
un SocketLit()
J'ai pu constater que quand la connexion était coupée, le temps de
lecture dans la fonction SocketLit() est largement inférieur à celui
demandé, par exemple on demande la lecteure pendant 1s et la fonction ne
met que quelque dixième, j'ai donc créée une fonction :
ChronoDebut(NumChrono)
Buff=SocketLit(ConvoyeurSocket:NomSocket,Faux,ConvoyeurSocket:TpsAttenteSocket)
Tps=ChronoValeur(NumChrono,Faux,-1)
// Erreur de connexion
SI PAS SocketControle(Tps,ConvoyeurSocket:TpsAttenteSocket)
####ERREUR###
FIN
PROCEDURE SocketControle(TempsReel est numérique (7,3), TempsAttenteSocket)
// Controle le temps de réaction sur la lecture d'une socket
// permet de savoir si la socket a été fermée par l'autre partie
// contrôle du temps par rapport à un temps de référence
// TempsAttenteSocket est en milisecondes : ex 1000
// Temps reel fourni par une fonction chrono ex : 1.000
// Renvoyer vrai = OK
SI 10 * TempsReel < TempsAttenteSocket/1000 ALORS
RENVOYER Faux
SINON
RENVOYER Vrai
FIN
Un post qui date un peu ... mais merci pour cette réponse, je vais mettre ton
code en test immédiatement !!!
Merci merci merci !!
Fred.
Le 22/01/2015 11:24, Pierre BOUSQUET a écrit :
PYT a formulé ce lundi :
Le 01/08/2014 10:23, Fredo a écrit :
Bonjour,
Quand je communique avec des automates (via modus TCP)
J'ouvre le socket de cette façon
SI SocketExiste(socket_name) = Faux ALORS
SI SocketConnect(socket_name,port,host,time_out) = Faux ALORS
status = "";
ExceptionDéclenche(err_connection,ErreurInfo(errMessage))
ELSE
status = "Connecté"+RC;
SocketChangeModeTransmission(socket_name,SocketSansMarqueurFin)
FIN
connected = True
RENVOYER Vrai
FIN
Cordialement,
PYT
Bonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
Bonjour,
Effectivement ce problème peut arriver quand il y a coupure de liaison,
Windev ne le détecte pas vraiment lorsque l'on fait un SocketExiste() ou
un SocketLit()
J'ai pu constater que quand la connexion était coupée, le temps de
lecture dans la fonction SocketLit() est largement inférieur à celui
demandé, par exemple on demande la lecteure pendant 1s et la fonction ne
met que quelque dixième, j'ai donc créée une fonction :
ChronoDebut(NumChrono)
Buff=SocketLit(ConvoyeurSocket:NomSocket,Faux,ConvoyeurSocket:TpsAttenteSocket)
Tps=ChronoValeur(NumChrono,Faux,-1)
// Erreur de connexion
SI PAS SocketControle(Tps,ConvoyeurSocket:TpsAttenteSocket)
####ERREUR###
FIN
PROCEDURE SocketControle(TempsReel est numérique (7,3), TempsAttenteSocket)
// Controle le temps de réaction sur la lecture d'une socket
// permet de savoir si la socket a été fermée par l'autre partie
// contrôle du temps par rapport à un temps de référence
// TempsAttenteSocket est en milisecondes : ex 1000
// Temps reel fourni par une fonction chrono ex : 1.000
// Renvoyer vrai = OK
SI 10 * TempsReel < TempsAttenteSocket/1000 ALORS
RENVOYER Faux
SINON
RENVOYER Vrai
FIN
Un post qui date un peu ... mais merci pour cette réponse, je vais mettre ton
code en test immédiatement !!!
Merci merci merci !!
Fred.
Le 22/01/2015 11:24, Pierre BOUSQUET a écrit :PYT a formulé ce lundi :Le 01/08/2014 10:23, Fredo a écrit :
Bonjour,
Quand je communique avec des automates (via modus TCP)
J'ouvre le socket de cette façon
SI SocketExiste(socket_name) = Faux ALORS
SI SocketConnect(socket_name,port,host,time_out) = Faux ALORS
status = "";
ExceptionDéclenche(err_connection,ErreurInfo(errMessage))
ELSE
status = "Connecté"+RC;
SocketChangeModeTransmission(socket_name,SocketSansMarqueurFin)
FIN
connected = True
RENVOYER Vrai
FIN
Cordialement,
PYTBonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les trames
à l'aide d'un appareil de capture de trames (physique, pas wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
Bonjour,
Effectivement ce problème peut arriver quand il y a coupure de liaison,
Windev ne le détecte pas vraiment lorsque l'on fait un SocketExiste() ou
un SocketLit()
J'ai pu constater que quand la connexion était coupée, le temps de
lecture dans la fonction SocketLit() est largement inférieur à celui
demandé, par exemple on demande la lecteure pendant 1s et la fonction ne
met que quelque dixième, j'ai donc créée une fonction :
ChronoDebut(NumChrono)
Buff=SocketLit(ConvoyeurSocket:NomSocket,Faux,ConvoyeurSocket:TpsAttenteSocket)
Tps=ChronoValeur(NumChrono,Faux,-1)
// Erreur de connexion
SI PAS SocketControle(Tps,ConvoyeurSocket:TpsAttenteSocket)
####ERREUR###
FIN
PROCEDURE SocketControle(TempsReel est numérique (7,3), TempsAttenteSocket)
// Controle le temps de réaction sur la lecture d'une socket
// permet de savoir si la socket a été fermée par l'autre partie
// contrôle du temps par rapport à un temps de référence
// TempsAttenteSocket est en milisecondes : ex 1000
// Temps reel fourni par une fonction chrono ex : 1.000
// Renvoyer vrai = OK
SI 10 * TempsReel < TempsAttenteSocket/1000 ALORS
RENVOYER Faux
SINON
RENVOYER Vrai
FIN
Un post qui date un peu ... mais merci pour cette réponse, je vais mettre ton
code en test immédiatement !!!
Merci merci merci !!
Fred.
Fredo avait écrit le 22/01/2015 :Le 22/01/2015 11:24, Pierre BOUSQUET a écrit :PYT a formulé ce lundi :Le 01/08/2014 10:23, Fredo a écrit :
Bonjour,
Quand je communique avec des automates (via modus TCP)
J'ouvre le socket de cette façon
SI SocketExiste(socket_name) = Faux ALORS
SI SocketConnect(socket_name,port,host,time_out) = Faux ALORS
status = "";
ExceptionDéclenche(err_connection,ErreurInfo(errMessage))
ELSE
status = "Connecté"+RC;
SocketChangeModeTransmission(socket_name,SocketSansMarqueurFin)
FIN
connected = True
RENVOYER Vrai
FIN
Cordialement,
PYTBonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les
trames
à l'aide d'un appareil de capture de trames (physique, pas
wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en
place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un
bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
Bonjour,
Effectivement ce problème peut arriver quand il y a coupure de liaison,
Windev ne le détecte pas vraiment lorsque l'on fait un SocketExiste() ou
un SocketLit()
J'ai pu constater que quand la connexion était coupée, le temps de
lecture dans la fonction SocketLit() est largement inférieur à celui
demandé, par exemple on demande la lecteure pendant 1s et la fonction ne
met que quelque dixième, j'ai donc créée une fonction :
ChronoDebut(NumChrono)
Buff=SocketLit(ConvoyeurSocket:NomSocket,Faux,ConvoyeurSocket:TpsAttenteSocket)
Tps=ChronoValeur(NumChrono,Faux,-1)
// Erreur de connexion
SI PAS SocketControle(Tps,ConvoyeurSocket:TpsAttenteSocket)
####ERREUR###
FIN
PROCEDURE SocketControle(TempsReel est numérique (7,3),
TempsAttenteSocket)
// Controle le temps de réaction sur la lecture d'une socket
// permet de savoir si la socket a été fermée par l'autre partie
// contrôle du temps par rapport à un temps de référence
// TempsAttenteSocket est en milisecondes : ex 1000
// Temps reel fourni par une fonction chrono ex : 1.000
// Renvoyer vrai = OK
SI 10 * TempsReel < TempsAttenteSocket/1000 ALORS
RENVOYER Faux
SINON
RENVOYER Vrai
FIN
Un post qui date un peu ... mais merci pour cette réponse, je vais
mettre ton code en test immédiatement !!!
Merci merci merci !!
Fred.
Bonjour Fred ,
J'ai rencontré les mêmes problèmes avec un périphérique qui communique
par socket.
Pourrais tu me dire si la solution proposée par Pierre fonctionne ?
Merci
JYB
---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
http://www.avast.com
Fredo avait écrit le 22/01/2015 :
Le 22/01/2015 11:24, Pierre BOUSQUET a écrit :
PYT a formulé ce lundi :
Le 01/08/2014 10:23, Fredo a écrit :
Bonjour,
Quand je communique avec des automates (via modus TCP)
J'ouvre le socket de cette façon
SI SocketExiste(socket_name) = Faux ALORS
SI SocketConnect(socket_name,port,host,time_out) = Faux ALORS
status = "";
ExceptionDéclenche(err_connection,ErreurInfo(errMessage))
ELSE
status = "Connecté"+RC;
SocketChangeModeTransmission(socket_name,SocketSansMarqueurFin)
FIN
connected = True
RENVOYER Vrai
FIN
Cordialement,
PYT
Bonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les
trames
à l'aide d'un appareil de capture de trames (physique, pas
wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en
place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un
bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
Bonjour,
Effectivement ce problème peut arriver quand il y a coupure de liaison,
Windev ne le détecte pas vraiment lorsque l'on fait un SocketExiste() ou
un SocketLit()
J'ai pu constater que quand la connexion était coupée, le temps de
lecture dans la fonction SocketLit() est largement inférieur à celui
demandé, par exemple on demande la lecteure pendant 1s et la fonction ne
met que quelque dixième, j'ai donc créée une fonction :
ChronoDebut(NumChrono)
Buff=SocketLit(ConvoyeurSocket:NomSocket,Faux,ConvoyeurSocket:TpsAttenteSocket)
Tps=ChronoValeur(NumChrono,Faux,-1)
// Erreur de connexion
SI PAS SocketControle(Tps,ConvoyeurSocket:TpsAttenteSocket)
####ERREUR###
FIN
PROCEDURE SocketControle(TempsReel est numérique (7,3),
TempsAttenteSocket)
// Controle le temps de réaction sur la lecture d'une socket
// permet de savoir si la socket a été fermée par l'autre partie
// contrôle du temps par rapport à un temps de référence
// TempsAttenteSocket est en milisecondes : ex 1000
// Temps reel fourni par une fonction chrono ex : 1.000
// Renvoyer vrai = OK
SI 10 * TempsReel < TempsAttenteSocket/1000 ALORS
RENVOYER Faux
SINON
RENVOYER Vrai
FIN
Un post qui date un peu ... mais merci pour cette réponse, je vais
mettre ton code en test immédiatement !!!
Merci merci merci !!
Fred.
Bonjour Fred ,
J'ai rencontré les mêmes problèmes avec un périphérique qui communique
par socket.
Pourrais tu me dire si la solution proposée par Pierre fonctionne ?
Merci
JYB
---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
http://www.avast.com
Fredo avait écrit le 22/01/2015 :Le 22/01/2015 11:24, Pierre BOUSQUET a écrit :PYT a formulé ce lundi :Le 01/08/2014 10:23, Fredo a écrit :
Bonjour,
Quand je communique avec des automates (via modus TCP)
J'ouvre le socket de cette façon
SI SocketExiste(socket_name) = Faux ALORS
SI SocketConnect(socket_name,port,host,time_out) = Faux ALORS
status = "";
ExceptionDéclenche(err_connection,ErreurInfo(errMessage))
ELSE
status = "Connecté"+RC;
SocketChangeModeTransmission(socket_name,SocketSansMarqueurFin)
FIN
connected = True
RENVOYER Vrai
FIN
Cordialement,
PYTBonjour à tous,
Je communique avec un périphérique par sockets en utilisant les
fonctions sockets standard de Windev (version 16)
Chez quelques clients, je rencontre un problème bizarre. Ma boucle de
lecture ne lit plus rien (sans erreurs) alors qu'en capturant les
trames
à l'aide d'un appareil de capture de trames (physique, pas
wireshark) je
vois bien que le périphérique émets correctement les trames.
Le fabricant m'indique qu'il n'a pas ce problème avec ses autres
partenaires (qui n'utilisent pas windev)
J'ai donc besoin afin de cibler l'origine du problème de mettre en
place
un système de lecture socket alternatif, .net et/ou winsock, opération
que je n'ai jamais faite.
Afin de ne pas ré-inventer la poudre, si une âme généreuse avait un
bout
de code ou un lien à me communiquer afin de dégrossir le boulot :)
Merci d'avance,
Fred.
Bonjour,
Effectivement ce problème peut arriver quand il y a coupure de liaison,
Windev ne le détecte pas vraiment lorsque l'on fait un SocketExiste() ou
un SocketLit()
J'ai pu constater que quand la connexion était coupée, le temps de
lecture dans la fonction SocketLit() est largement inférieur à celui
demandé, par exemple on demande la lecteure pendant 1s et la fonction ne
met que quelque dixième, j'ai donc créée une fonction :
ChronoDebut(NumChrono)
Buff=SocketLit(ConvoyeurSocket:NomSocket,Faux,ConvoyeurSocket:TpsAttenteSocket)
Tps=ChronoValeur(NumChrono,Faux,-1)
// Erreur de connexion
SI PAS SocketControle(Tps,ConvoyeurSocket:TpsAttenteSocket)
####ERREUR###
FIN
PROCEDURE SocketControle(TempsReel est numérique (7,3),
TempsAttenteSocket)
// Controle le temps de réaction sur la lecture d'une socket
// permet de savoir si la socket a été fermée par l'autre partie
// contrôle du temps par rapport à un temps de référence
// TempsAttenteSocket est en milisecondes : ex 1000
// Temps reel fourni par une fonction chrono ex : 1.000
// Renvoyer vrai = OK
SI 10 * TempsReel < TempsAttenteSocket/1000 ALORS
RENVOYER Faux
SINON
RENVOYER Vrai
FIN
Un post qui date un peu ... mais merci pour cette réponse, je vais
mettre ton code en test immédiatement !!!
Merci merci merci !!
Fred.
Bonjour Fred ,
J'ai rencontré les mêmes problèmes avec un périphérique qui communique
par socket.
Pourrais tu me dire si la solution proposée par Pierre fonctionne ?
Merci
JYB
---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
http://www.avast.com
