J'ai un soucis avec les fonctions du port série (ou émulation via USB)
de Windev (version 20 mais je pense que c'est pareil avec toutes les
version).
Je dois récupérer un fichier binaire d'environ 80~100 ko à 115200 bps
sans contrôle de flux ni matériel ni logiciel (pas le choix).
Une première commande permet d'avoir la taille exacte du fichier, on
envoie une seconde commande pour initier la demande de transfert.
Un écho à la commande est reçu et après une petite tempo le flux arrive
en lecture.
La fin est détectée avec un timeout et/ou en vérifiant la taille du
fichier et un CRC est lu et recalculé pour vérification.
- Tout ça marche bien avec mes fonctions de lecture/écriture que
j'utilise depuis 10 ans, jusqu'à une vitesse de 19200 bps.
- Avec une vitesse supérieure (57600 ou 115200 bps, j'ai beau essayer
tous les paramètres possibles (buffer, branchement d'un évenement avec
uniquement la lecture ou utilisation d'une boucle sans fin, paramètre
"temporisation"), il manque toujours 200 à 300 octets dans le fichier
(bizarement toujours situés à peu prêt au même endroit sans que j'ai pu
déterminer une raison, vers l'octet 4300.)
- Je peux exclure un problème matériel car si j'utilise un terminal
(hyperterminal, teraterm) tout se passe correctement.
- J'ai déjà testé avec succès une solution alternative en utilisant une
DLL payante facile à utiliser et performante
(http://www.marshallsoft.com/wsc4vb.htm) mais je voudrais avoir votre
avis :
- Une expérience similaire ? Une solution possible sans un composant
tiers ?
- Une autre référence de DLL ? (une solution opensource sans activeX à
enregistrer serait l'idéal).
Merci
A+
--
Romain PETIT
contact : rompetit chez free fr
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
J'ai un soucis avec les fonctions du port série (ou émulation via USB) de Windev (version 20 mais je pense que c'est pareil avec toutes les version).
Je dois récupérer un fichier binaire d'environ 80~100 ko à 115200 bps sans contrôle de flux ni matériel ni logiciel (pas le choix). Une première commande permet d'avoir la taille exacte du fichier, on envoie une seconde commande pour initier la demande de transfert. Un écho à la commande est reçu et après une petite tempo le flux arrive en lecture. La fin est détectée avec un timeout et/ou en vérifiant la taille du fichier et un CRC est lu et recalculé pour vérification.
- Tout ça marche bien avec mes fonctions de lecture/écriture que j'utilise depuis 10 ans, jusqu'à une vitesse de 19200 bps.
- Avec une vitesse supérieure (57600 ou 115200 bps, j'ai beau essayer tous les paramètres possibles (buffer, branchement d'un évenement avec uniquement la lecture ou utilisation d'une boucle sans fin, paramètre "temporisation"), il manque toujours 200 à 300 octets dans le fichier (bizarement toujours situés à peu prêt au même endroit sans que j'ai pu déterminer une raison, vers l'octet 4300.)
- Je peux exclure un problème matériel car si j'utilise un terminal (hyperterminal, teraterm) tout se passe correctement.
- J'ai déjà testé avec succès une solution alternative en utilisant une DLL payante facile à utiliser et performante (http://www.marshallsoft.com/wsc4vb.htm) mais je voudrais avoir votre avis :
- Une expérience similaire ? Une solution possible sans un composant tiers ? - Une autre référence de DLL ? (une solution opensource sans activeX à enregistrer serait l'idéal).
Merci A+
idée / suggestion en vrac
faire le test avec un sniffeur de port com pour voir ce qui passe comme données
plus la vitesse augmente plus le cable doit être court Débit (bit/s) Longueur (m) 2 400 60 4 800 30 9 600 15 19 200 7,6 38 400 3,7 56 000 2,6
-- Cordialement JeAn-PhI
Romain PETIT vient de nous annoncer :
Bonjour,
J'ai un soucis avec les fonctions du port série (ou émulation via USB) de
Windev (version 20 mais je pense que c'est pareil avec toutes les version).
Je dois récupérer un fichier binaire d'environ 80~100 ko à 115200 bps sans
contrôle de flux ni matériel ni logiciel (pas le choix).
Une première commande permet d'avoir la taille exacte du fichier, on envoie
une seconde commande pour initier la demande de transfert.
Un écho à la commande est reçu et après une petite tempo le flux arrive en
lecture.
La fin est détectée avec un timeout et/ou en vérifiant la taille du fichier
et un CRC est lu et recalculé pour vérification.
- Tout ça marche bien avec mes fonctions de lecture/écriture que j'utilise
depuis 10 ans, jusqu'à une vitesse de 19200 bps.
- Avec une vitesse supérieure (57600 ou 115200 bps, j'ai beau essayer tous
les paramètres possibles (buffer, branchement d'un évenement avec uniquement
la lecture ou utilisation d'une boucle sans fin, paramètre "temporisation"),
il manque toujours 200 à 300 octets dans le fichier (bizarement toujours
situés à peu prêt au même endroit sans que j'ai pu déterminer une raison,
vers l'octet 4300.)
- Je peux exclure un problème matériel car si j'utilise un terminal
(hyperterminal, teraterm) tout se passe correctement.
- J'ai déjà testé avec succès une solution alternative en utilisant une DLL
payante facile à utiliser et performante
(http://www.marshallsoft.com/wsc4vb.htm) mais je voudrais avoir votre avis :
- Une expérience similaire ? Une solution possible sans un composant tiers ?
- Une autre référence de DLL ? (une solution opensource sans activeX à
enregistrer serait l'idéal).
Merci
A+
idée / suggestion en vrac
faire le test avec un sniffeur de port com pour voir ce qui passe comme
données
plus la vitesse augmente plus le cable doit être court
Débit (bit/s) Longueur (m)
2 400 60
4 800 30
9 600 15
19 200 7,6
38 400 3,7
56 000 2,6
J'ai un soucis avec les fonctions du port série (ou émulation via USB) de Windev (version 20 mais je pense que c'est pareil avec toutes les version).
Je dois récupérer un fichier binaire d'environ 80~100 ko à 115200 bps sans contrôle de flux ni matériel ni logiciel (pas le choix). Une première commande permet d'avoir la taille exacte du fichier, on envoie une seconde commande pour initier la demande de transfert. Un écho à la commande est reçu et après une petite tempo le flux arrive en lecture. La fin est détectée avec un timeout et/ou en vérifiant la taille du fichier et un CRC est lu et recalculé pour vérification.
- Tout ça marche bien avec mes fonctions de lecture/écriture que j'utilise depuis 10 ans, jusqu'à une vitesse de 19200 bps.
- Avec une vitesse supérieure (57600 ou 115200 bps, j'ai beau essayer tous les paramètres possibles (buffer, branchement d'un évenement avec uniquement la lecture ou utilisation d'une boucle sans fin, paramètre "temporisation"), il manque toujours 200 à 300 octets dans le fichier (bizarement toujours situés à peu prêt au même endroit sans que j'ai pu déterminer une raison, vers l'octet 4300.)
- Je peux exclure un problème matériel car si j'utilise un terminal (hyperterminal, teraterm) tout se passe correctement.
- J'ai déjà testé avec succès une solution alternative en utilisant une DLL payante facile à utiliser et performante (http://www.marshallsoft.com/wsc4vb.htm) mais je voudrais avoir votre avis :
- Une expérience similaire ? Une solution possible sans un composant tiers ? - Une autre référence de DLL ? (une solution opensource sans activeX à enregistrer serait l'idéal).
Merci A+
idée / suggestion en vrac
faire le test avec un sniffeur de port com pour voir ce qui passe comme données
plus la vitesse augmente plus le cable doit être court Débit (bit/s) Longueur (m) 2 400 60 4 800 30 9 600 15 19 200 7,6 38 400 3,7 56 000 2,6
-- Cordialement JeAn-PhI
Romain PETIT
Il se trouve que JeAn-PhI a formulé :
faire le test avec un sniffeur de port com pour voir ce qui passe comme données
Merci de t'interesser à mon problème.
Je sais exatctement quelles données sont transmises (j'arrive à récupérer le fichier avec Windev avec une vitesse <200.
plus la vitesse augmente plus le cable doit être court Débit (bit/s) Longueur (m)
Ce n'est pas un problème matériel, avec la DLL appellée depuis windev ou avec Hyperterminal, tout est Ok, même avec une vitesse >57600.
Je pense que Windev est trop lent pour gérer ces vitesses sans contrôle de flux, ou bien ils ont "oublié" d'implémenter d'autres paramètres pour leurs appels API windows de gestion des ports com...
A+
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Il se trouve que JeAn-PhI a formulé :
faire le test avec un sniffeur de port com pour voir ce qui passe comme
données
Merci de t'interesser à mon problème.
Je sais exatctement quelles données sont transmises (j'arrive à
récupérer le fichier avec Windev avec une vitesse <200.
plus la vitesse augmente plus le cable doit être court
Débit (bit/s) Longueur (m)
Ce n'est pas un problème matériel, avec la DLL appellée depuis windev
ou avec Hyperterminal, tout est Ok, même avec une vitesse >57600.
Je pense que Windev est trop lent pour gérer ces vitesses sans contrôle
de flux, ou bien ils ont "oublié" d'implémenter d'autres paramètres
pour leurs appels API windows de gestion des ports com...
A+
--
Romain PETIT
contact : rompetit chez free fr
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
faire le test avec un sniffeur de port com pour voir ce qui passe comme données
Merci de t'interesser à mon problème.
Je sais exatctement quelles données sont transmises (j'arrive à récupérer le fichier avec Windev avec une vitesse <200.
plus la vitesse augmente plus le cable doit être court Débit (bit/s) Longueur (m)
Ce n'est pas un problème matériel, avec la DLL appellée depuis windev ou avec Hyperterminal, tout est Ok, même avec une vitesse >57600.
Je pense que Windev est trop lent pour gérer ces vitesses sans contrôle de flux, ou bien ils ont "oublié" d'implémenter d'autres paramètres pour leurs appels API windows de gestion des ports com...
A+
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Daniel
Bonjour, Le 11/03/2015 10:59, Romain PETIT a écrit :
Bonjour,
J'ai un soucis avec les fonctions du port série (ou émulation via USB) de Windev (version 20 mais je pense que c'est pareil avec toutes les version).
Je dois récupérer un fichier binaire d'environ 80~100 ko à 115200 bps sans contrôle de flux ni matériel ni logiciel (pas le choix). Une première commande permet d'avoir la taille exacte du fichier, on envoie une seconde commande pour initier la demande de transfert. Un écho à la commande est reçu et après une petite tempo le flux arrive en lecture. La fin est détectée avec un timeout et/ou en vérifiant la taille du fichier et un CRC est lu et recalculé pour vérification.
- Tout ça marche bien avec mes fonctions de lecture/écriture que j'utilise depuis 10 ans, jusqu'à une vitesse de 19200 bps.
- Avec une vitesse supérieure (57600 ou 115200 bps, j'ai beau essayer tous les paramètres possibles (buffer, branchement d'un évenement avec uniquement la lecture ou utilisation d'une boucle sans fin, paramètre "temporisation"), il manque toujours 200 à 300 octets dans le fichier (bizarement toujours situés à peu prêt au même endroit sans que j'ai pu déterminer une raison, vers l'octet 4300.)
Typiquement un problème de lenteur de windev. J'avais le même problème avec 4D. J'ai l'impression que ces outils ont tellement de couche dans la gestion des évènements qu'ils en loupent.
- Je peux exclure un problème matériel car si j'utilise un terminal (hyperterminal, teraterm) tout se passe correctement.
AS tu essayé de changer la priorité du programme en passant par le gestionnaire de tâche, virer la prévention de l'exécution des données?
- J'ai déjà testé avec succès une solution alternative en utilisant une DLL payante facile à utiliser et performante (http://www.marshallsoft.com/wsc4vb.htm) mais je voudrais avoir votre avis :
- Une expérience similaire ? Une solution possible sans un composant tiers ?
Nous avions fait une petite carte électronique que nous mettions entre l'automate et le pc (elle tenait dans le boitier du connecteur). Elle permettait de travailler en asynchrone. C'était le seul moyen de ne pas être dépendant du PC.
- Une autre référence de DLL ? (une solution opensource sans activeX à enregistrer serait l'idéal).
Tu dois pouvoir trouver cela sur des forums borland...
Désolé de ne pas pouvoir t'aider plus, mais j'ai arrêté le dev.
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
--- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com
Bonjour,
Le 11/03/2015 10:59, Romain PETIT a écrit :
Bonjour,
J'ai un soucis avec les fonctions du port série (ou émulation via USB)
de Windev (version 20 mais je pense que c'est pareil avec toutes les
version).
Je dois récupérer un fichier binaire d'environ 80~100 ko à 115200 bps
sans contrôle de flux ni matériel ni logiciel (pas le choix).
Une première commande permet d'avoir la taille exacte du fichier, on
envoie une seconde commande pour initier la demande de transfert.
Un écho à la commande est reçu et après une petite tempo le flux arrive
en lecture.
La fin est détectée avec un timeout et/ou en vérifiant la taille du
fichier et un CRC est lu et recalculé pour vérification.
- Tout ça marche bien avec mes fonctions de lecture/écriture que
j'utilise depuis 10 ans, jusqu'à une vitesse de 19200 bps.
- Avec une vitesse supérieure (57600 ou 115200 bps, j'ai beau essayer
tous les paramètres possibles (buffer, branchement d'un évenement avec
uniquement la lecture ou utilisation d'une boucle sans fin, paramètre
"temporisation"), il manque toujours 200 à 300 octets dans le fichier
(bizarement toujours situés à peu prêt au même endroit sans que j'ai pu
déterminer une raison, vers l'octet 4300.)
Typiquement un problème de lenteur de windev. J'avais le même problème
avec 4D. J'ai l'impression que ces outils ont tellement de couche dans
la gestion des évènements qu'ils en loupent.
- Je peux exclure un problème matériel car si j'utilise un terminal
(hyperterminal, teraterm) tout se passe correctement.
AS tu essayé de changer la priorité du programme en passant par le
gestionnaire de tâche, virer la prévention de l'exécution des données?
- J'ai déjà testé avec succès une solution alternative en utilisant une
DLL payante facile à utiliser et performante
(http://www.marshallsoft.com/wsc4vb.htm) mais je voudrais avoir votre
avis :
- Une expérience similaire ? Une solution possible sans un composant
tiers ?
Nous avions fait une petite carte électronique que nous mettions entre
l'automate et le pc (elle tenait dans le boitier du connecteur). Elle
permettait de travailler en asynchrone.
C'était le seul moyen de ne pas être dépendant du PC.
- Une autre référence de DLL ? (une solution opensource sans activeX à
enregistrer serait l'idéal).
Tu dois pouvoir trouver cela sur des forums borland...
Désolé de ne pas pouvoir t'aider plus, mais j'ai arrêté le dev.
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
http://www.avast.com
Bonjour, Le 11/03/2015 10:59, Romain PETIT a écrit :
Bonjour,
J'ai un soucis avec les fonctions du port série (ou émulation via USB) de Windev (version 20 mais je pense que c'est pareil avec toutes les version).
Je dois récupérer un fichier binaire d'environ 80~100 ko à 115200 bps sans contrôle de flux ni matériel ni logiciel (pas le choix). Une première commande permet d'avoir la taille exacte du fichier, on envoie une seconde commande pour initier la demande de transfert. Un écho à la commande est reçu et après une petite tempo le flux arrive en lecture. La fin est détectée avec un timeout et/ou en vérifiant la taille du fichier et un CRC est lu et recalculé pour vérification.
- Tout ça marche bien avec mes fonctions de lecture/écriture que j'utilise depuis 10 ans, jusqu'à une vitesse de 19200 bps.
- Avec une vitesse supérieure (57600 ou 115200 bps, j'ai beau essayer tous les paramètres possibles (buffer, branchement d'un évenement avec uniquement la lecture ou utilisation d'une boucle sans fin, paramètre "temporisation"), il manque toujours 200 à 300 octets dans le fichier (bizarement toujours situés à peu prêt au même endroit sans que j'ai pu déterminer une raison, vers l'octet 4300.)
Typiquement un problème de lenteur de windev. J'avais le même problème avec 4D. J'ai l'impression que ces outils ont tellement de couche dans la gestion des évènements qu'ils en loupent.
- Je peux exclure un problème matériel car si j'utilise un terminal (hyperterminal, teraterm) tout se passe correctement.
AS tu essayé de changer la priorité du programme en passant par le gestionnaire de tâche, virer la prévention de l'exécution des données?
- J'ai déjà testé avec succès une solution alternative en utilisant une DLL payante facile à utiliser et performante (http://www.marshallsoft.com/wsc4vb.htm) mais je voudrais avoir votre avis :
- Une expérience similaire ? Une solution possible sans un composant tiers ?
Nous avions fait une petite carte électronique que nous mettions entre l'automate et le pc (elle tenait dans le boitier du connecteur). Elle permettait de travailler en asynchrone. C'était le seul moyen de ne pas être dépendant du PC.
- Une autre référence de DLL ? (une solution opensource sans activeX à enregistrer serait l'idéal).
Tu dois pouvoir trouver cela sur des forums borland...
Désolé de ne pas pouvoir t'aider plus, mais j'ai arrêté le dev.
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
--- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com
Daniel
Bonjour, Le 11/03/2015 10:59, Romain PETIT a écrit :
Bonjour,
J'ai un soucis avec les fonctions du port série (ou émulation via USB) de Windev (version 20 mais je pense que c'est pareil avec toutes les version).
Je dois récupérer un fichier binaire d'environ 80~100 ko à 115200 bps sans contrôle de flux ni matériel ni logiciel (pas le choix). Une première commande permet d'avoir la taille exacte du fichier, on envoie une seconde commande pour initier la demande de transfert. Un écho à la commande est reçu et après une petite tempo le flux arrive en lecture. La fin est détectée avec un timeout et/ou en vérifiant la taille du fichier et un CRC est lu et recalculé pour vérification.
- Tout ça marche bien avec mes fonctions de lecture/écriture que j'utilise depuis 10 ans, jusqu'à une vitesse de 19200 bps.
- Avec une vitesse supérieure (57600 ou 115200 bps, j'ai beau essayer tous les paramètres possibles (buffer, branchement d'un évenement avec uniquement la lecture ou utilisation d'une boucle sans fin, paramètre "temporisation"), il manque toujours 200 à 300 octets dans le fichier (bizarement toujours situés à peu prêt au même endroit sans que j'ai pu déterminer une raison, vers l'octet 4300.)
Typiquement un problème de lenteur de windev. J'avais le même problème avec 4D. J'ai l'impression que ces outils ont tellement de couche dans la gestion des évènements qu'ils en loupent.
- Je peux exclure un problème matériel car si j'utilise un terminal (hyperterminal, teraterm) tout se passe correctement.
AS tu essayé de changer la priorité du programme en passant par le gestionnaire de tâche, virer la prévention de l'exécution des données?
- J'ai déjà testé avec succès une solution alternative en utilisant une DLL payante facile à utiliser et performante (http://www.marshallsoft.com/wsc4vb.htm) mais je voudrais avoir votre avis :
- Une expérience similaire ? Une solution possible sans un composant tiers ?
Nous avions fait une petite carte électronique que nous mettions entre l'automate et le pc (elle tenait dans le boitier du connecteur). Elle permettait de travailler en asynchrone. C'était le seul moyen de ne pas être dépendant du PC.
- Une autre référence de DLL ? (une solution opensource sans activeX à enregistrer serait l'idéal).
Tu dois pouvoir trouver cela sur des forums borland...
Désolé de ne pas pouvoir t'aider plus, mais j'ai arrêté le dev.
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
--- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com
Bonjour,
Le 11/03/2015 10:59, Romain PETIT a écrit :
Bonjour,
J'ai un soucis avec les fonctions du port série (ou émulation via USB)
de Windev (version 20 mais je pense que c'est pareil avec toutes les
version).
Je dois récupérer un fichier binaire d'environ 80~100 ko à 115200 bps
sans contrôle de flux ni matériel ni logiciel (pas le choix).
Une première commande permet d'avoir la taille exacte du fichier, on
envoie une seconde commande pour initier la demande de transfert.
Un écho à la commande est reçu et après une petite tempo le flux arrive
en lecture.
La fin est détectée avec un timeout et/ou en vérifiant la taille du
fichier et un CRC est lu et recalculé pour vérification.
- Tout ça marche bien avec mes fonctions de lecture/écriture que
j'utilise depuis 10 ans, jusqu'à une vitesse de 19200 bps.
- Avec une vitesse supérieure (57600 ou 115200 bps, j'ai beau essayer
tous les paramètres possibles (buffer, branchement d'un évenement avec
uniquement la lecture ou utilisation d'une boucle sans fin, paramètre
"temporisation"), il manque toujours 200 à 300 octets dans le fichier
(bizarement toujours situés à peu prêt au même endroit sans que j'ai pu
déterminer une raison, vers l'octet 4300.)
Typiquement un problème de lenteur de windev. J'avais le même problème
avec 4D. J'ai l'impression que ces outils ont tellement de couche dans
la gestion des évènements qu'ils en loupent.
- Je peux exclure un problème matériel car si j'utilise un terminal
(hyperterminal, teraterm) tout se passe correctement.
AS tu essayé de changer la priorité du programme en passant par le
gestionnaire de tâche, virer la prévention de l'exécution des données?
- J'ai déjà testé avec succès une solution alternative en utilisant une
DLL payante facile à utiliser et performante
(http://www.marshallsoft.com/wsc4vb.htm) mais je voudrais avoir votre
avis :
- Une expérience similaire ? Une solution possible sans un composant
tiers ?
Nous avions fait une petite carte électronique que nous mettions entre
l'automate et le pc (elle tenait dans le boitier du connecteur). Elle
permettait de travailler en asynchrone.
C'était le seul moyen de ne pas être dépendant du PC.
- Une autre référence de DLL ? (une solution opensource sans activeX à
enregistrer serait l'idéal).
Tu dois pouvoir trouver cela sur des forums borland...
Désolé de ne pas pouvoir t'aider plus, mais j'ai arrêté le dev.
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
http://www.avast.com
Bonjour, Le 11/03/2015 10:59, Romain PETIT a écrit :
Bonjour,
J'ai un soucis avec les fonctions du port série (ou émulation via USB) de Windev (version 20 mais je pense que c'est pareil avec toutes les version).
Je dois récupérer un fichier binaire d'environ 80~100 ko à 115200 bps sans contrôle de flux ni matériel ni logiciel (pas le choix). Une première commande permet d'avoir la taille exacte du fichier, on envoie une seconde commande pour initier la demande de transfert. Un écho à la commande est reçu et après une petite tempo le flux arrive en lecture. La fin est détectée avec un timeout et/ou en vérifiant la taille du fichier et un CRC est lu et recalculé pour vérification.
- Tout ça marche bien avec mes fonctions de lecture/écriture que j'utilise depuis 10 ans, jusqu'à une vitesse de 19200 bps.
- Avec une vitesse supérieure (57600 ou 115200 bps, j'ai beau essayer tous les paramètres possibles (buffer, branchement d'un évenement avec uniquement la lecture ou utilisation d'une boucle sans fin, paramètre "temporisation"), il manque toujours 200 à 300 octets dans le fichier (bizarement toujours situés à peu prêt au même endroit sans que j'ai pu déterminer une raison, vers l'octet 4300.)
Typiquement un problème de lenteur de windev. J'avais le même problème avec 4D. J'ai l'impression que ces outils ont tellement de couche dans la gestion des évènements qu'ils en loupent.
- Je peux exclure un problème matériel car si j'utilise un terminal (hyperterminal, teraterm) tout se passe correctement.
AS tu essayé de changer la priorité du programme en passant par le gestionnaire de tâche, virer la prévention de l'exécution des données?
- J'ai déjà testé avec succès une solution alternative en utilisant une DLL payante facile à utiliser et performante (http://www.marshallsoft.com/wsc4vb.htm) mais je voudrais avoir votre avis :
- Une expérience similaire ? Une solution possible sans un composant tiers ?
Nous avions fait une petite carte électronique que nous mettions entre l'automate et le pc (elle tenait dans le boitier du connecteur). Elle permettait de travailler en asynchrone. C'était le seul moyen de ne pas être dépendant du PC.
- Une autre référence de DLL ? (une solution opensource sans activeX à enregistrer serait l'idéal).
Tu dois pouvoir trouver cela sur des forums borland...
Désolé de ne pas pouvoir t'aider plus, mais j'ai arrêté le dev.
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
--- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com
Eric Laurent
Salut Romain, J'utilise aussi des liaisons à 115200 sans controle de flux mais pour cela je n'utilise SURTOUT PAS la gestion d'événements de Windev Je fais la lecture de la RS dans une boucle en continu et je mets les données lues dans un buffer pour les exploiter ensuite.
Eric
Salut Romain,
J'utilise aussi des liaisons à 115200 sans controle de flux mais pour
cela je n'utilise SURTOUT PAS la gestion d'événements de Windev
Je fais la lecture de la RS dans une boucle en continu et je mets les
données lues dans un buffer pour les exploiter ensuite.
Salut Romain, J'utilise aussi des liaisons à 115200 sans controle de flux mais pour cela je n'utilise SURTOUT PAS la gestion d'événements de Windev Je fais la lecture de la RS dans une boucle en continu et je mets les données lues dans un buffer pour les exploiter ensuite.
Eric
Romain PETIT
Eric Laurent a utilisé son clavier pour écrire :
Salut Romain, J'utilise aussi des liaisons à 115200 sans controle de flux mais pour cela je n'utilise SURTOUT PAS la gestion d'événements de Windev Je fais la lecture de la RS dans une boucle en continu et je mets les données lues dans un buffer pour les exploiter ensuite.
Eric
Merci pour vos réponses, ça fait plaisir de voir que ce forum vit encore... Jusqu'à présent moi non plus je n'utilisais jamais la gestion des évenements et pratique comme toi. J'ai juste voulu tester mais je constate que j'ai le même problème évenement ou pas. Jusq'à présent, je n'ai eu à gérer que des commandes et des réponses qui ne dépassaient pas quelques centaines d'octets, et en général avec un protocole haut niveau mais là c'est un flux continu de milliers d'octets, je pense (Daniel me le confirme) que Windev est trop lent.
Je suis entrain de regarder directement les appels API, ça n'a pas l'air trop complexe et je vais m'inspirer fortement de ce code VB : https://strokescribe.com/en/serial-port-vb-winapi.html
(j'arrive déjà à ouvre et à paramétrer le port com...)
A+
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Eric Laurent a utilisé son clavier pour écrire :
Salut Romain,
J'utilise aussi des liaisons à 115200 sans controle de flux mais pour cela je
n'utilise SURTOUT PAS la gestion d'événements de Windev
Je fais la lecture de la RS dans une boucle en continu et je mets les données
lues dans un buffer pour les exploiter ensuite.
Eric
Merci pour vos réponses, ça fait plaisir de voir que ce forum vit
encore...
Jusqu'à présent moi non plus je n'utilisais jamais la gestion des
évenements et pratique comme toi.
J'ai juste voulu tester mais je constate que j'ai le même problème
évenement ou pas.
Jusq'à présent, je n'ai eu à gérer que des commandes et des réponses
qui ne dépassaient pas quelques centaines d'octets, et en général avec
un protocole haut niveau mais là c'est un flux continu de milliers
d'octets, je pense (Daniel me le confirme) que Windev est trop lent.
Je suis entrain de regarder directement les appels API, ça n'a pas
l'air trop complexe et je vais m'inspirer fortement de ce code VB :
https://strokescribe.com/en/serial-port-vb-winapi.html
(j'arrive déjà à ouvre et à paramétrer le port com...)
A+
--
Romain PETIT
contact : rompetit chez free fr
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
Salut Romain, J'utilise aussi des liaisons à 115200 sans controle de flux mais pour cela je n'utilise SURTOUT PAS la gestion d'événements de Windev Je fais la lecture de la RS dans une boucle en continu et je mets les données lues dans un buffer pour les exploiter ensuite.
Eric
Merci pour vos réponses, ça fait plaisir de voir que ce forum vit encore... Jusqu'à présent moi non plus je n'utilisais jamais la gestion des évenements et pratique comme toi. J'ai juste voulu tester mais je constate que j'ai le même problème évenement ou pas. Jusq'à présent, je n'ai eu à gérer que des commandes et des réponses qui ne dépassaient pas quelques centaines d'octets, et en général avec un protocole haut niveau mais là c'est un flux continu de milliers d'octets, je pense (Daniel me le confirme) que Windev est trop lent.
Je suis entrain de regarder directement les appels API, ça n'a pas l'air trop complexe et je vais m'inspirer fortement de ce code VB : https://strokescribe.com/en/serial-port-vb-winapi.html
(j'arrive déjà à ouvre et à paramétrer le port com...)
A+
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Daniel
Le 11/03/2015 15:14, Romain PETIT a écrit :
Eric Laurent a utilisé son clavier pour écrire :
Salut Romain, J'utilise aussi des liaisons à 115200 sans controle de flux mais pour cela je n'utilise SURTOUT PAS la gestion d'événements de Windev Je fais la lecture de la RS dans une boucle en continu et je mets les données lues dans un buffer pour les exploiter ensuite.
Eric
Merci pour vos réponses, ça fait plaisir de voir que ce forum vit encore... Jusqu'à présent moi non plus je n'utilisais jamais la gestion des évenements et pratique comme toi. J'ai juste voulu tester mais je constate que j'ai le même problème évenement ou pas. Jusq'à présent, je n'ai eu à gérer que des commandes et des réponses qui ne dépassaient pas quelques centaines d'octets, et en général avec un protocole haut niveau mais là c'est un flux continu de milliers d'octets, je pense (Daniel me le confirme) que Windev est trop lent.
Je suis entrain de regarder directement les appels API, ça n'a pas l'air trop complexe et je vais m'inspirer fortement de ce code VB : https://strokescribe.com/en/serial-port-vb-winapi.html
(j'arrive déjà à ouvre et à paramétrer le port com...)
Sinon tu as cela en c++ http://cpp.developpez.com/faq/vc?page=Reseau-et-Communications#Comment-travailler-avec-le-port-serie
Ce n'est pas difficile, c'est histoire de s'y remettre.
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
--- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com
Le 11/03/2015 15:14, Romain PETIT a écrit :
Eric Laurent a utilisé son clavier pour écrire :
Salut Romain,
J'utilise aussi des liaisons à 115200 sans controle de flux mais pour
cela je n'utilise SURTOUT PAS la gestion d'événements de Windev
Je fais la lecture de la RS dans une boucle en continu et je mets les
données lues dans un buffer pour les exploiter ensuite.
Eric
Merci pour vos réponses, ça fait plaisir de voir que ce forum vit encore...
Jusqu'à présent moi non plus je n'utilisais jamais la gestion des
évenements et pratique comme toi.
J'ai juste voulu tester mais je constate que j'ai le même problème
évenement ou pas.
Jusq'à présent, je n'ai eu à gérer que des commandes et des réponses qui
ne dépassaient pas quelques centaines d'octets, et en général avec un
protocole haut niveau mais là c'est un flux continu de milliers
d'octets, je pense (Daniel me le confirme) que Windev est trop lent.
Je suis entrain de regarder directement les appels API, ça n'a pas l'air
trop complexe et je vais m'inspirer fortement de ce code VB :
https://strokescribe.com/en/serial-port-vb-winapi.html
(j'arrive déjà à ouvre et à paramétrer le port com...)
Sinon tu as cela en c++
http://cpp.developpez.com/faq/vc?page=Reseau-et-Communications#Comment-travailler-avec-le-port-serie
Ce n'est pas difficile, c'est histoire de s'y remettre.
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
http://www.avast.com
Salut Romain, J'utilise aussi des liaisons à 115200 sans controle de flux mais pour cela je n'utilise SURTOUT PAS la gestion d'événements de Windev Je fais la lecture de la RS dans une boucle en continu et je mets les données lues dans un buffer pour les exploiter ensuite.
Eric
Merci pour vos réponses, ça fait plaisir de voir que ce forum vit encore... Jusqu'à présent moi non plus je n'utilisais jamais la gestion des évenements et pratique comme toi. J'ai juste voulu tester mais je constate que j'ai le même problème évenement ou pas. Jusq'à présent, je n'ai eu à gérer que des commandes et des réponses qui ne dépassaient pas quelques centaines d'octets, et en général avec un protocole haut niveau mais là c'est un flux continu de milliers d'octets, je pense (Daniel me le confirme) que Windev est trop lent.
Je suis entrain de regarder directement les appels API, ça n'a pas l'air trop complexe et je vais m'inspirer fortement de ce code VB : https://strokescribe.com/en/serial-port-vb-winapi.html
(j'arrive déjà à ouvre et à paramétrer le port com...)
Sinon tu as cela en c++ http://cpp.developpez.com/faq/vc?page=Reseau-et-Communications#Comment-travailler-avec-le-port-serie
Ce n'est pas difficile, c'est histoire de s'y remettre.
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
--- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com
Romain PETIT
Daniel a exposé le 11/03/2015 :
Ce n'est pas difficile, c'est histoire de s'y remettre.
Bingo, ça marche du tonnerre avec les API... Récupération de mon fichier à fond les ballons sans perdre un octet!
Merci pour vos pistes.
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Daniel a exposé le 11/03/2015 :
Ce n'est pas difficile, c'est histoire de s'y remettre.
Bingo, ça marche du tonnerre avec les API...
Récupération de mon fichier à fond les ballons sans perdre un octet!
Merci pour vos pistes.
--
Romain PETIT
contact : rompetit chez free fr
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
Ce n'est pas difficile, c'est histoire de s'y remettre.
Bingo, ça marche du tonnerre avec les API... Récupération de mon fichier à fond les ballons sans perdre un octet!
Merci pour vos pistes.
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Daniel
Le 11/03/2015 17:30, Romain PETIT a écrit :
Daniel a exposé le 11/03/2015 :
Ce n'est pas difficile, c'est histoire de s'y remettre.
Bingo, ça marche du tonnerre avec les API... Récupération de mon fichier à fond les ballons sans perdre un octet!
Merci pour vos pistes.
Tu as fait en c ou en VB ?
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
--- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com
Le 11/03/2015 17:30, Romain PETIT a écrit :
Daniel a exposé le 11/03/2015 :
Ce n'est pas difficile, c'est histoire de s'y remettre.
Bingo, ça marche du tonnerre avec les API...
Récupération de mon fichier à fond les ballons sans perdre un octet!
Merci pour vos pistes.
Tu as fait en c ou en VB ?
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
http://www.avast.com
Ce n'est pas difficile, c'est histoire de s'y remettre.
Bingo, ça marche du tonnerre avec les API... Récupération de mon fichier à fond les ballons sans perdre un octet!
Merci pour vos pistes.
Tu as fait en c ou en VB ?
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
--- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com
Romain PETIT
Daniel avait soumis l'idée :
Tu as fait en c ou en VB ?
En W-Langage :-) avec AppelDLL32 et en m'inspirant surtout du code VB... Je posterai la solution après avoir écrit un truc plus propre. Si ça interesse quelqu'un ?
A+
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Daniel avait soumis l'idée :
Tu as fait en c ou en VB ?
En W-Langage :-) avec AppelDLL32 et en m'inspirant surtout du code
VB...
Je posterai la solution après avoir écrit un truc plus propre.
Si ça interesse quelqu'un ?
A+
--
Romain PETIT
contact : rompetit chez free fr
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
En W-Langage :-) avec AppelDLL32 et en m'inspirant surtout du code VB... Je posterai la solution après avoir écrit un truc plus propre. Si ça interesse quelqu'un ?
A+
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
