Bonsoir,
La doc. de l'interface que j'utilise dans mon application, recommande une
temporisation de 200ms pour l'envoi ou la réception des blocs de données.
Ma question ; Faut-il mieux utiliser un Timer ou Sleep ?
Bonsoir, La doc. de l'interface que j'utilise dans mon application, recommande une temporisation de 200ms pour l'envoi ou la réception des blocs de données. Ma question ; Faut-il mieux utiliser un Timer ou Sleep ?
Cordialement Karl
Hello,
Sleep est le plus simple et le plus naturel dans ce cas.
Si tu ne veux pas d'API ou si pour une autre raison tu préfères garder plus de controle, tu peux faire ta propre fonction Sleep, comme ça:
Public Function MySleep(milisec As Long) Dim tStart As Double
Bonsoir,
La doc. de l'interface que j'utilise dans mon application, recommande
une temporisation de 200ms pour l'envoi ou la réception des blocs de
données.
Ma question ; Faut-il mieux utiliser un Timer ou Sleep ?
Cordialement
Karl
Hello,
Sleep est le plus simple et le plus naturel dans ce cas.
Si tu ne veux pas d'API ou si pour une autre raison tu préfères garder
plus de controle, tu peux faire ta propre fonction Sleep, comme ça:
Public Function MySleep(milisec As Long)
Dim tStart As Double
Bonsoir, La doc. de l'interface que j'utilise dans mon application, recommande une temporisation de 200ms pour l'envoi ou la réception des blocs de données. Ma question ; Faut-il mieux utiliser un Timer ou Sleep ?
Cordialement Karl
Hello,
Sleep est le plus simple et le plus naturel dans ce cas.
Si tu ne veux pas d'API ou si pour une autre raison tu préfères garder plus de controle, tu peux faire ta propre fonction Sleep, comme ça:
Public Function MySleep(milisec As Long) Dim tStart As Double
Bonsoir, La doc. de l'interface que j'utilise dans mon application, recommande une temporisation de 200ms pour l'envoi ou la réception des blocs de données. Ma question ; Faut-il mieux utiliser un Timer ou Sleep ?
Cordialement Karl
Hello,
Sleep est le plus simple et le plus naturel dans ce cas.
Hello,
J'ai un doute que je ne peux pas lever actuellement. Si les blocs sont importants, et compte tenu de la bufferisation, je me demande s'il y aura bien 200ms entre la réception du dernier octet du bloc N et du premier octet du bloc N+1. Cela se calcule ... La méthode Output ne retourne-t-elle pas immédiatement ?
Pour les envois importants, j'utilisais les événements avec le TThresold. Dans ce cas, je lancerais un timer après émission du dernier octet d'un bloc dont la procédure événementielle relancerait l'émission du bloc suivant.
-- Fred
Dans : news:eqbtbt$pfe$1@aioe.org,
Jean-marc disait :
Karl wrote:
Bonsoir,
La doc. de l'interface que j'utilise dans mon application, recommande
une temporisation de 200ms pour l'envoi ou la réception des blocs de
données.
Ma question ; Faut-il mieux utiliser un Timer ou Sleep ?
Cordialement
Karl
Hello,
Sleep est le plus simple et le plus naturel dans ce cas.
Hello,
J'ai un doute que je ne peux pas lever actuellement.
Si les blocs sont importants, et compte tenu de la bufferisation, je me
demande s'il y aura bien 200ms entre la réception du dernier octet du
bloc N et du premier octet du bloc N+1. Cela se calcule ...
La méthode Output ne retourne-t-elle pas immédiatement ?
Pour les envois importants, j'utilisais les événements avec le
TThresold.
Dans ce cas, je lancerais un timer après émission du dernier octet d'un
bloc dont la procédure événementielle relancerait l'émission du bloc
suivant.
Bonsoir, La doc. de l'interface que j'utilise dans mon application, recommande une temporisation de 200ms pour l'envoi ou la réception des blocs de données. Ma question ; Faut-il mieux utiliser un Timer ou Sleep ?
Cordialement Karl
Hello,
Sleep est le plus simple et le plus naturel dans ce cas.
Hello,
J'ai un doute que je ne peux pas lever actuellement. Si les blocs sont importants, et compte tenu de la bufferisation, je me demande s'il y aura bien 200ms entre la réception du dernier octet du bloc N et du premier octet du bloc N+1. Cela se calcule ... La méthode Output ne retourne-t-elle pas immédiatement ?
Pour les envois importants, j'utilisais les événements avec le TThresold. Dans ce cas, je lancerais un timer après émission du dernier octet d'un bloc dont la procédure événementielle relancerait l'émission du bloc suivant.
-- Fred
ab
Bonjour, Oui c'est bien 200ms entre des blocs de 5 bytes d'après la doc, cette interface commande des microswitchs, donc, les commutations sont assez longues (en informatique). Avec un Sleep de 200ms, c'est ok, les switchs ne cafouillent pas. Je veux être bien sur, que sur d'autre PC le temps soit bien respecté, d'ou ma question. Karl
"Fred" a écrit dans le message de news:
Dans : news:eqbtbt$pfe$, Jean-marc disait :
Karl wrote:
Bonsoir, La doc. de l'interface que j'utilise dans mon application, recommande une temporisation de 200ms pour l'envoi ou la réception des blocs de données. Ma question ; Faut-il mieux utiliser un Timer ou Sleep ?
Cordialement Karl
Hello,
Sleep est le plus simple et le plus naturel dans ce cas.
Hello,
J'ai un doute que je ne peux pas lever actuellement. Si les blocs sont importants, et compte tenu de la bufferisation, je me demande s'il y aura bien 200ms entre la réception du dernier octet du bloc N et du premier octet du bloc N+1. Cela se calcule ... La méthode Output ne retourne-t-elle pas immédiatement ?
Pour les envois importants, j'utilisais les événements avec le TThresold. Dans ce cas, je lancerais un timer après émission du dernier octet d'un bloc dont la procédure événementielle relancerait l'émission du bloc suivant.
-- Fred
Bonjour,
Oui c'est bien 200ms entre des blocs de 5 bytes d'après la doc, cette
interface commande des microswitchs, donc, les commutations sont assez
longues (en informatique). Avec un Sleep de 200ms, c'est ok, les switchs ne
cafouillent pas.
Je veux être bien sur, que sur d'autre PC le temps soit bien respecté, d'ou
ma question.
Karl
"Fred" <foleide@libre.france> a écrit dans le message de news:
OCNvzYqSHHA.4956@TK2MSFTNGP04.phx.gbl...
Dans : news:eqbtbt$pfe$1@aioe.org,
Jean-marc disait :
Karl wrote:
Bonsoir,
La doc. de l'interface que j'utilise dans mon application, recommande
une temporisation de 200ms pour l'envoi ou la réception des blocs de
données.
Ma question ; Faut-il mieux utiliser un Timer ou Sleep ?
Cordialement
Karl
Hello,
Sleep est le plus simple et le plus naturel dans ce cas.
Hello,
J'ai un doute que je ne peux pas lever actuellement.
Si les blocs sont importants, et compte tenu de la bufferisation, je me
demande s'il y aura bien 200ms entre la réception du dernier octet du bloc
N et du premier octet du bloc N+1. Cela se calcule ...
La méthode Output ne retourne-t-elle pas immédiatement ?
Pour les envois importants, j'utilisais les événements avec le TThresold.
Dans ce cas, je lancerais un timer après émission du dernier octet d'un
bloc dont la procédure événementielle relancerait l'émission du bloc
suivant.
Bonjour, Oui c'est bien 200ms entre des blocs de 5 bytes d'après la doc, cette interface commande des microswitchs, donc, les commutations sont assez longues (en informatique). Avec un Sleep de 200ms, c'est ok, les switchs ne cafouillent pas. Je veux être bien sur, que sur d'autre PC le temps soit bien respecté, d'ou ma question. Karl
"Fred" a écrit dans le message de news:
Dans : news:eqbtbt$pfe$, Jean-marc disait :
Karl wrote:
Bonsoir, La doc. de l'interface que j'utilise dans mon application, recommande une temporisation de 200ms pour l'envoi ou la réception des blocs de données. Ma question ; Faut-il mieux utiliser un Timer ou Sleep ?
Cordialement Karl
Hello,
Sleep est le plus simple et le plus naturel dans ce cas.
Hello,
J'ai un doute que je ne peux pas lever actuellement. Si les blocs sont importants, et compte tenu de la bufferisation, je me demande s'il y aura bien 200ms entre la réception du dernier octet du bloc N et du premier octet du bloc N+1. Cela se calcule ... La méthode Output ne retourne-t-elle pas immédiatement ?
Pour les envois importants, j'utilisais les événements avec le TThresold. Dans ce cas, je lancerais un timer après émission du dernier octet d'un bloc dont la procédure événementielle relancerait l'émission du bloc suivant.
-- Fred
Jean-marc
ab wrote:
Bonjour, Oui c'est bien 200ms entre des blocs de 5 bytes d'après la doc, cette interface commande des microswitchs, donc, les commutations sont assez longues (en informatique). Avec un Sleep de 200ms, c'est ok, les switchs ne cafouillent pas. Je veux être bien sur, que sur d'autre PC le temps soit bien respecté, d'ou ma question.
Hello,
Et bien la réponse, c'est que Sleep (de même que MySleep d'ailleurs) te garantit une tempo de la durée demandée, quelle que soit la machine utilisée, sa vitesse, etc. Tu n'auras pas une précision à la microseconde, mais à la milliseconde, ça c'est sur!
MySleep a l'avantage de faire des DoEvents, donc ton thread n'est pas réellement "bloqué", le programme est juste stoppé.
Il y a des précisions techniques ici, probablement pas très utiles pour ton cas précis: http://msdn2.microsoft.com/en-us/library/ms686298.aspx
Bonjour,
Oui c'est bien 200ms entre des blocs de 5 bytes d'après la doc, cette
interface commande des microswitchs, donc, les commutations sont assez
longues (en informatique). Avec un Sleep de 200ms, c'est ok, les
switchs ne cafouillent pas.
Je veux être bien sur, que sur d'autre PC le temps soit bien
respecté, d'ou ma question.
Hello,
Et bien la réponse, c'est que Sleep (de même que MySleep d'ailleurs)
te garantit une tempo de la durée demandée, quelle que soit la machine
utilisée, sa vitesse, etc. Tu n'auras pas une précision à la microseconde,
mais à la milliseconde, ça c'est sur!
MySleep a l'avantage de faire des DoEvents, donc ton thread n'est pas
réellement
"bloqué", le programme est juste stoppé.
Il y a des précisions techniques ici, probablement pas très utiles pour ton
cas
précis:
http://msdn2.microsoft.com/en-us/library/ms686298.aspx
Bonjour, Oui c'est bien 200ms entre des blocs de 5 bytes d'après la doc, cette interface commande des microswitchs, donc, les commutations sont assez longues (en informatique). Avec un Sleep de 200ms, c'est ok, les switchs ne cafouillent pas. Je veux être bien sur, que sur d'autre PC le temps soit bien respecté, d'ou ma question.
Hello,
Et bien la réponse, c'est que Sleep (de même que MySleep d'ailleurs) te garantit une tempo de la durée demandée, quelle que soit la machine utilisée, sa vitesse, etc. Tu n'auras pas une précision à la microseconde, mais à la milliseconde, ça c'est sur!
MySleep a l'avantage de faire des DoEvents, donc ton thread n'est pas réellement "bloqué", le programme est juste stoppé.
Il y a des précisions techniques ici, probablement pas très utiles pour ton cas précis: http://msdn2.microsoft.com/en-us/library/ms686298.aspx
"Jean-marc" a écrit dans le message de news: eqg3fr$s9j$
ab wrote:
Bonjour, Oui c'est bien 200ms entre des blocs de 5 bytes d'après la doc, cette interface commande des microswitchs, donc, les commutations sont assez longues (en informatique). Avec un Sleep de 200ms, c'est ok, les switchs ne cafouillent pas. Je veux être bien sur, que sur d'autre PC le temps soit bien respecté, d'ou ma question.
Hello,
Et bien la réponse, c'est que Sleep (de même que MySleep d'ailleurs) te garantit une tempo de la durée demandée, quelle que soit la machine utilisée, sa vitesse, etc. Tu n'auras pas une précision à la microseconde, mais à la milliseconde, ça c'est sur!
MySleep a l'avantage de faire des DoEvents, donc ton thread n'est pas réellement "bloqué", le programme est juste stoppé.
Il y a des précisions techniques ici, probablement pas très utiles pour ton cas précis: http://msdn2.microsoft.com/en-us/library/ms686298.aspx
"Jean-marc" <NO_SPAM_jean_marc_n2@yahoo.fr.invalid> a écrit dans le message
de news: eqg3fr$s9j$1@aioe.org...
ab wrote:
Bonjour,
Oui c'est bien 200ms entre des blocs de 5 bytes d'après la doc, cette
interface commande des microswitchs, donc, les commutations sont assez
longues (en informatique). Avec un Sleep de 200ms, c'est ok, les
switchs ne cafouillent pas.
Je veux être bien sur, que sur d'autre PC le temps soit bien
respecté, d'ou ma question.
Hello,
Et bien la réponse, c'est que Sleep (de même que MySleep d'ailleurs)
te garantit une tempo de la durée demandée, quelle que soit la machine
utilisée, sa vitesse, etc. Tu n'auras pas une précision à la microseconde,
mais à la milliseconde, ça c'est sur!
MySleep a l'avantage de faire des DoEvents, donc ton thread n'est pas
réellement
"bloqué", le programme est juste stoppé.
Il y a des précisions techniques ici, probablement pas très utiles pour
ton cas
précis:
http://msdn2.microsoft.com/en-us/library/ms686298.aspx
"Jean-marc" a écrit dans le message de news: eqg3fr$s9j$
ab wrote:
Bonjour, Oui c'est bien 200ms entre des blocs de 5 bytes d'après la doc, cette interface commande des microswitchs, donc, les commutations sont assez longues (en informatique). Avec un Sleep de 200ms, c'est ok, les switchs ne cafouillent pas. Je veux être bien sur, que sur d'autre PC le temps soit bien respecté, d'ou ma question.
Hello,
Et bien la réponse, c'est que Sleep (de même que MySleep d'ailleurs) te garantit une tempo de la durée demandée, quelle que soit la machine utilisée, sa vitesse, etc. Tu n'auras pas une précision à la microseconde, mais à la milliseconde, ça c'est sur!
MySleep a l'avantage de faire des DoEvents, donc ton thread n'est pas réellement "bloqué", le programme est juste stoppé.
Il y a des précisions techniques ici, probablement pas très utiles pour ton cas précis: http://msdn2.microsoft.com/en-us/library/ms686298.aspx
Et bien la réponse, c'est que Sleep (de même que MySleep d'ailleurs) te garantit une tempo de la durée demandée, quelle que soit la machine utilisée, sa vitesse, etc. Tu n'auras pas une précision à la microseconde, mais à la milliseconde, ça c'est sur!
Ce que je voulais dire, et j'aurais aimé avoir ton avis la-dessus, c'est que tu garantis ainsi la durée entre l'émission du premier octet d'un bloc et le premier octet du bloc suivant. Il me semble que Output bufferise le bloc à envoyer et retourne immédiatement. Donc mettre une tempo de cet ordre de grandeur après le output me semble un peu juste. Du moins avec des blocs de données importants, ce qui n'est pas le cas présent comme ab l'a précisé depuis. La durée d'émission de 5 octets doit être petite comparée aux 200 ms.
-- Fred http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
Dans : news:eqg3fr$s9j$1@aioe.org,
Jean-marc écrivait :
Salut Jean-Marc,
Et bien la réponse, c'est que Sleep (de même que MySleep d'ailleurs)
te garantit une tempo de la durée demandée, quelle que soit la machine
utilisée, sa vitesse, etc. Tu n'auras pas une précision à la
microseconde, mais à la milliseconde, ça c'est sur!
Ce que je voulais dire, et j'aurais aimé avoir ton avis la-dessus, c'est
que tu garantis ainsi la durée entre l'émission du premier octet d'un
bloc et le premier octet du bloc suivant. Il me semble que Output
bufferise le bloc à envoyer et retourne immédiatement.
Donc mettre une tempo de cet ordre de grandeur après le output me semble
un peu juste. Du moins avec des blocs de données importants, ce qui
n'est pas le cas présent comme ab l'a précisé depuis. La durée
d'émission de 5 octets doit être petite comparée aux 200 ms.
--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
Et bien la réponse, c'est que Sleep (de même que MySleep d'ailleurs) te garantit une tempo de la durée demandée, quelle que soit la machine utilisée, sa vitesse, etc. Tu n'auras pas une précision à la microseconde, mais à la milliseconde, ça c'est sur!
Ce que je voulais dire, et j'aurais aimé avoir ton avis la-dessus, c'est que tu garantis ainsi la durée entre l'émission du premier octet d'un bloc et le premier octet du bloc suivant. Il me semble que Output bufferise le bloc à envoyer et retourne immédiatement. Donc mettre une tempo de cet ordre de grandeur après le output me semble un peu juste. Du moins avec des blocs de données importants, ce qui n'est pas le cas présent comme ab l'a précisé depuis. La durée d'émission de 5 octets doit être petite comparée aux 200 ms.
-- Fred http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
Jean-marc
Fred wrote:
Dans : news:eqg3fr$s9j$, Jean-marc écrivait :
Salut Jean-Marc,
Ce que je voulais dire, et j'aurais aimé avoir ton avis la-dessus, c'est que tu garantis ainsi la durée entre l'émission du premier octet d'un bloc et le premier octet du bloc suivant. Il me semble que Output bufferise le bloc à envoyer et retourne immédiatement. Donc mettre une tempo de cet ordre de grandeur après le output me semble un peu juste. Du moins avec des blocs de données importants, ce qui n'est pas le cas présent comme ab l'a précisé depuis. La durée d'émission de 5 octets doit être petite comparée aux 200 ms.
Salut Fred,
ok je comprends la question. Ben en fait je ne sais pas. J'ai beaucoup travaillé avec MsComm, mais jamais été confronté à devoir vérifier ou mesurer ça. Il faut que je regarde pour apporter une vrai réponse technique.
Ce dont je suis sur (et je rejoins ton avis): le temps d'émission de 5 octets est (assez) petit devant 200 ms, ça c'est certain.
Mais à 1200 bps, dans les conditions les plus défavorables, transférer les 5 octets demendera tout de même 50 ms.
Dans des conditions favorables (9600,N,8,1), on doit être autour de 5 ms.
Donc bonne remarque, si on peut vérifier que Output bufferise et retourne, alors si on est à 1200 bps, alors il faut peut être en tenir compte et ajouter 50 ms, histoire d'être tranquille :-). Si plus rapide, on peut sans doute négliger. Il faut tester, c'est sur!
Si l'appli est bien fichue, le paramètre tempo sera lisible depuis un fichier de config, bien sur!
Dans : news:eqg3fr$s9j$1@aioe.org,
Jean-marc écrivait :
Salut Jean-Marc,
Ce que je voulais dire, et j'aurais aimé avoir ton avis la-dessus,
c'est que tu garantis ainsi la durée entre l'émission du premier
octet d'un bloc et le premier octet du bloc suivant. Il me semble que
Output bufferise le bloc à envoyer et retourne immédiatement.
Donc mettre une tempo de cet ordre de grandeur après le output me
semble un peu juste. Du moins avec des blocs de données importants,
ce qui n'est pas le cas présent comme ab l'a précisé depuis. La durée
d'émission de 5 octets doit être petite comparée aux 200 ms.
Salut Fred,
ok je comprends la question. Ben en fait je ne sais pas. J'ai beaucoup
travaillé avec MsComm, mais jamais été confronté à devoir vérifier ou
mesurer ça.
Il faut que je regarde pour apporter une vrai réponse technique.
Ce dont je suis sur (et je rejoins ton avis): le temps d'émission de
5 octets est (assez) petit devant 200 ms, ça c'est certain.
Mais à 1200 bps, dans les conditions les plus défavorables, transférer
les 5 octets demendera tout de même 50 ms.
Dans des conditions favorables (9600,N,8,1), on doit être autour de 5 ms.
Donc bonne remarque, si on peut vérifier que Output bufferise et retourne,
alors si on est à 1200 bps, alors il faut peut être en tenir compte et
ajouter 50 ms, histoire d'être tranquille :-). Si plus rapide, on peut sans
doute négliger. Il faut tester, c'est sur!
Si l'appli est bien fichue, le paramètre tempo sera lisible depuis un
fichier
de config, bien sur!
Ce que je voulais dire, et j'aurais aimé avoir ton avis la-dessus, c'est que tu garantis ainsi la durée entre l'émission du premier octet d'un bloc et le premier octet du bloc suivant. Il me semble que Output bufferise le bloc à envoyer et retourne immédiatement. Donc mettre une tempo de cet ordre de grandeur après le output me semble un peu juste. Du moins avec des blocs de données importants, ce qui n'est pas le cas présent comme ab l'a précisé depuis. La durée d'émission de 5 octets doit être petite comparée aux 200 ms.
Salut Fred,
ok je comprends la question. Ben en fait je ne sais pas. J'ai beaucoup travaillé avec MsComm, mais jamais été confronté à devoir vérifier ou mesurer ça. Il faut que je regarde pour apporter une vrai réponse technique.
Ce dont je suis sur (et je rejoins ton avis): le temps d'émission de 5 octets est (assez) petit devant 200 ms, ça c'est certain.
Mais à 1200 bps, dans les conditions les plus défavorables, transférer les 5 octets demendera tout de même 50 ms.
Dans des conditions favorables (9600,N,8,1), on doit être autour de 5 ms.
Donc bonne remarque, si on peut vérifier que Output bufferise et retourne, alors si on est à 1200 bps, alors il faut peut être en tenir compte et ajouter 50 ms, histoire d'être tranquille :-). Si plus rapide, on peut sans doute négliger. Il faut tester, c'est sur!
Si l'appli est bien fichue, le paramètre tempo sera lisible depuis un fichier de config, bien sur!
Fred wrote: ok je comprends la question. Ben en fait je ne sais pas. J'ai beaucoup travaillé avec MsComm, mais jamais été confronté à devoir vérifier ou mesurer ça.
ok ca me revient maintenant! Bien sur c'est bufferisé, mais c'est réglable avec OutputBufferSize.
Mais le plus simple dans le cas qui nous occupe, c'est de déclencher le sleep(200) uniquement APRES s'être assuré que OutputBufferCount est à 0, donc que le buffer de transmission est vide :-)
C'est tout simple! Arf, ça fait trop longtemps que je n'ai plus joué avec MsComm ....
Fred wrote:
ok je comprends la question. Ben en fait je ne sais pas. J'ai beaucoup
travaillé avec MsComm, mais jamais été confronté à devoir vérifier ou
mesurer ça.
ok ca me revient maintenant!
Bien sur c'est bufferisé, mais c'est réglable avec OutputBufferSize.
Mais le plus simple dans le cas qui nous occupe, c'est de déclencher le
sleep(200) uniquement APRES s'être assuré que OutputBufferCount est à 0,
donc que le buffer de transmission est vide :-)
C'est tout simple! Arf, ça fait trop longtemps que je n'ai plus joué
avec MsComm ....
Fred wrote: ok je comprends la question. Ben en fait je ne sais pas. J'ai beaucoup travaillé avec MsComm, mais jamais été confronté à devoir vérifier ou mesurer ça.
ok ca me revient maintenant! Bien sur c'est bufferisé, mais c'est réglable avec OutputBufferSize.
Mais le plus simple dans le cas qui nous occupe, c'est de déclencher le sleep(200) uniquement APRES s'être assuré que OutputBufferCount est à 0, donc que le buffer de transmission est vide :-)
C'est tout simple! Arf, ça fait trop longtemps que je n'ai plus joué avec MsComm ....
Fred wrote: ok je comprends la question. Ben en fait je ne sais pas. J'ai beaucoup travaillé avec MsComm, mais jamais été confronté à devoir vérifier ou mesurer ça.
ok ca me revient maintenant! Bien sur c'est bufferisé, mais c'est réglable avec OutputBufferSize.
Mais le plus simple dans le cas qui nous occupe, c'est de déclencher le sleep(200) uniquement APRES s'être assuré que OutputBufferCount est à 0, donc que le buffer de transmission est vide :-)
Oui, d'où ma suggestion d'utiliser l'évènement OnComm en le déclenchant sur un TThresold à 1. (je ne suis plus sûr du nom de la propriété !!) En fait j'utilisais surtout ce principe pour envoyer des paquets de données très importants bloc par bloc. La fin de l'émission d'un bloc provoquant l'envoi du suivant. J'essayais toutjours d'éviter les boucles avec DoEvents !
C'est tout simple! Arf, ça fait trop longtemps que je n'ai plus joué avec MsComm ....
De même :-)
-- Fred
Dans : news:eqgc0e$gv5$1@aioe.org,
Jean-marc disait :
Jean-marc wrote:
Fred wrote:
ok je comprends la question. Ben en fait je ne sais pas. J'ai
beaucoup travaillé avec MsComm, mais jamais été confronté à devoir
vérifier ou mesurer ça.
ok ca me revient maintenant!
Bien sur c'est bufferisé, mais c'est réglable avec OutputBufferSize.
Mais le plus simple dans le cas qui nous occupe, c'est de déclencher
le sleep(200) uniquement APRES s'être assuré que OutputBufferCount
est à 0, donc que le buffer de transmission est vide :-)
Oui, d'où ma suggestion d'utiliser l'évènement OnComm en le déclenchant
sur un TThresold à 1.
(je ne suis plus sûr du nom de la propriété !!)
En fait j'utilisais surtout ce principe pour envoyer des paquets de
données très importants bloc par bloc.
La fin de l'émission d'un bloc provoquant l'envoi du suivant.
J'essayais toutjours d'éviter les boucles avec DoEvents !
C'est tout simple! Arf, ça fait trop longtemps que je n'ai plus joué
avec MsComm ....
Fred wrote: ok je comprends la question. Ben en fait je ne sais pas. J'ai beaucoup travaillé avec MsComm, mais jamais été confronté à devoir vérifier ou mesurer ça.
ok ca me revient maintenant! Bien sur c'est bufferisé, mais c'est réglable avec OutputBufferSize.
Mais le plus simple dans le cas qui nous occupe, c'est de déclencher le sleep(200) uniquement APRES s'être assuré que OutputBufferCount est à 0, donc que le buffer de transmission est vide :-)
Oui, d'où ma suggestion d'utiliser l'évènement OnComm en le déclenchant sur un TThresold à 1. (je ne suis plus sûr du nom de la propriété !!) En fait j'utilisais surtout ce principe pour envoyer des paquets de données très importants bloc par bloc. La fin de l'émission d'un bloc provoquant l'envoi du suivant. J'essayais toutjours d'éviter les boucles avec DoEvents !
C'est tout simple! Arf, ça fait trop longtemps que je n'ai plus joué avec MsComm ....
De même :-)
-- Fred
ab
Bonjour, Encore une petite question sur l'évenement OnComm
Pour visualiser en temps réel, l'angle Y X de mon application, j'interroge en continue l'interface. Ne trouvant pas d'explication sur comEvSend sur le Web, j'ai tenté la fonction. A priori je peux l'utiliser, mais le problème c'est qu'il me renvoie que la première partie du code (Direction_Droite_Gauche )
Je ne peux pas concaténer les deux à cause de la temporisation de 200ms entre les ordres. De plus je suis tenu de respecter les caractères de fin vbCrLf et vbCr, sans doute un bug dans le Pic de l'appareil..
Bonjour,
Encore une petite question sur l'évenement OnComm
Pour visualiser en temps réel, l'angle Y X de mon application, j'interroge
en continue l'interface.
Ne trouvant pas d'explication sur comEvSend sur le Web, j'ai tenté la
fonction.
A priori je peux l'utiliser, mais le problème c'est qu'il me renvoie que la
première partie du code (Direction_Droite_Gauche )
Je ne peux pas concaténer les deux à cause de la temporisation de 200ms
entre les ordres.
De plus je suis tenu de respecter les caractères de fin vbCrLf et vbCr,
sans
doute un bug dans le Pic de l'appareil..
Bonjour, Encore une petite question sur l'évenement OnComm
Pour visualiser en temps réel, l'angle Y X de mon application, j'interroge en continue l'interface. Ne trouvant pas d'explication sur comEvSend sur le Web, j'ai tenté la fonction. A priori je peux l'utiliser, mais le problème c'est qu'il me renvoie que la première partie du code (Direction_Droite_Gauche )
Je ne peux pas concaténer les deux à cause de la temporisation de 200ms entre les ordres. De plus je suis tenu de respecter les caractères de fin vbCrLf et vbCr, sans doute un bug dans le Pic de l'appareil..
