Lecture d'un port Serie, MSCOMM32.OCX et perte de trames (buffer ?)
7 réponses
Pierremag
Bonjour,
Une application cr=E9=E9 en VB6 pour lire le port s=E9rie tourne
correctement et remplie parfaitement son role, jusqu'au jour ou nous
l'avons control=E9 de plus pr=E9s ...
Et la, surprise, nous nous aper=E7evons que nous perdons enormement de
donn=E9es.
Chaque trame envoy=E9e et lu sur le port s=E9rie fait pr=E9cisement 114
caracteres, et se termine par un CRLF.
Or, il semblerait que la lecture puis ecriture dans un fichier text se
fasse "=E0 la vol=E9e" sans traitement d'un buffer, ce qui expliquerait
la perte des trames surnumeraires ...
Nous avons tent=E9s differentes config, mais aucune ne r=E9cupere toute
les trames ...
Aujourd'hui nous tournons comme suit, =E0 l'exception de tout autre
parametres :
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred
Dans : news:, Pierremag disait :
Bonjour,
Bonjour,
Une application créé en VB6 pour lire le port série tourne correctement et remplie parfaitement son role, jusqu'au jour ou nous l'avons controlé de plus prés ...
Pour ma part, j'ai utilisé avec succès ce genre de méthode.
RThreshold=1 InputLen=1 etc ...
Et dans la procédure événement OnComm, je réalise quelque chose du style :
Select Case MSComm1.CommEvent Case comEvReceive char=MSComm1.Input If char <> Chr(10) Then Trame = Trame & char Else Print #fichier, Trame; Trame = "" End If
Cela oblige à avoir une variable globale [Trame] À toi de voir si tu ouvres et fermes le fichier à chaque écriture.
-- Fred http://www.cerbermail.com/?3kA6ftaCvT
Dans : news:1126196062.748283.40540@o13g2000cwo.googlegroups.com,
Pierremag disait :
Bonjour,
Bonjour,
Une application créé en VB6 pour lire le port série tourne
correctement et remplie parfaitement son role, jusqu'au jour ou nous
l'avons controlé de plus prés ...
Pour ma part, j'ai utilisé avec succès ce genre de méthode.
RThreshold=1
InputLen=1
etc ...
Et dans la procédure événement OnComm, je réalise quelque chose du style
:
Select Case MSComm1.CommEvent
Case comEvReceive
char=MSComm1.Input
If char <> Chr(10) Then
Trame = Trame & char
Else
Print #fichier, Trame;
Trame = ""
End If
Cela oblige à avoir une variable globale [Trame]
À toi de voir si tu ouvres et fermes le fichier à chaque écriture.
Une application créé en VB6 pour lire le port série tourne correctement et remplie parfaitement son role, jusqu'au jour ou nous l'avons controlé de plus prés ...
Pour ma part, j'ai utilisé avec succès ce genre de méthode.
RThreshold=1 InputLen=1 etc ...
Et dans la procédure événement OnComm, je réalise quelque chose du style :
Select Case MSComm1.CommEvent Case comEvReceive char=MSComm1.Input If char <> Chr(10) Then Trame = Trame & char Else Print #fichier, Trame; Trame = "" End If
Cela oblige à avoir une variable globale [Trame] À toi de voir si tu ouvres et fermes le fichier à chaque écriture.
-- Fred http://www.cerbermail.com/?3kA6ftaCvT
Pierremag a écrit :
Bonjour,
Une application créé en VB6 pour lire le port série tourne correctement et remplie parfaitement son role, jusqu'au jour ou nous l'avons controlé de plus prés ...
Et la, surprise, nous nous aperçevons que nous perdons enormement de données.
Chaque trame envoyée et lu sur le port série fait précisement 114 caracteres, et se termine par un CRLF.
Or, il semblerait que la lecture puis ecriture dans un fichier text se fasse "à la volée" sans traitement d'un buffer, ce qui expliquerait la perte des trames surnumeraires ...
Bonjour,
Comme te l'a répondu Fred, à une variante près:
private tampon as string private comptetampon as integer
Private Sub MSComm1_OnComm() Dim a$
a$ = MSComm1.Input
If a$ <> Chr(13) Then If a$ = Chr(10) Then Else comptetampon = comptetampon + 1 tampon = tampon & a$ 'utiliser pour séparer les données d'une trame If comptetampon = 1 Or comptetampon = 3 Or comptetampon = 5 Then comptetampon = comptetampon + 1 tampon = tampon & " " End If If comptetampon = 6 Then comptetampon = 0 End If Text1.Text = tampon End If
Else 'ecrit la ligne dans fichier texte (objet lever) lever.writeline (tampon) tampon = "" Text1.Text = ""
End If
End Sub
A+
Christophe
Pierremag a écrit :
Bonjour,
Une application créé en VB6 pour lire le port série tourne
correctement et remplie parfaitement son role, jusqu'au jour ou nous
l'avons controlé de plus prés ...
Et la, surprise, nous nous aperçevons que nous perdons enormement de
données.
Chaque trame envoyée et lu sur le port série fait précisement 114
caracteres, et se termine par un CRLF.
Or, il semblerait que la lecture puis ecriture dans un fichier text se
fasse "à la volée" sans traitement d'un buffer, ce qui expliquerait
la perte des trames surnumeraires ...
Bonjour,
Comme te l'a répondu Fred, à une variante près:
private tampon as string
private comptetampon as integer
Private Sub MSComm1_OnComm()
Dim a$
a$ = MSComm1.Input
If a$ <> Chr(13) Then
If a$ = Chr(10) Then
Else
comptetampon = comptetampon + 1
tampon = tampon & a$
'utiliser pour séparer les données d'une trame
If comptetampon = 1 Or comptetampon = 3 Or comptetampon = 5
Then
comptetampon = comptetampon + 1
tampon = tampon & " "
End If
If comptetampon = 6 Then
comptetampon = 0
End If
Text1.Text = tampon
End If
Else
'ecrit la ligne dans fichier texte (objet lever)
lever.writeline (tampon)
tampon = ""
Text1.Text = ""
Une application créé en VB6 pour lire le port série tourne correctement et remplie parfaitement son role, jusqu'au jour ou nous l'avons controlé de plus prés ...
Et la, surprise, nous nous aperçevons que nous perdons enormement de données.
Chaque trame envoyée et lu sur le port série fait précisement 114 caracteres, et se termine par un CRLF.
Or, il semblerait que la lecture puis ecriture dans un fichier text se fasse "à la volée" sans traitement d'un buffer, ce qui expliquerait la perte des trames surnumeraires ...
Bonjour,
Comme te l'a répondu Fred, à une variante près:
private tampon as string private comptetampon as integer
Private Sub MSComm1_OnComm() Dim a$
a$ = MSComm1.Input
If a$ <> Chr(13) Then If a$ = Chr(10) Then Else comptetampon = comptetampon + 1 tampon = tampon & a$ 'utiliser pour séparer les données d'une trame If comptetampon = 1 Or comptetampon = 3 Or comptetampon = 5 Then comptetampon = comptetampon + 1 tampon = tampon & " " End If If comptetampon = 6 Then comptetampon = 0 End If Text1.Text = tampon End If
Else 'ecrit la ligne dans fichier texte (objet lever) lever.writeline (tampon) tampon = "" Text1.Text = ""
End If
End Sub
A+
Christophe
Fred
Dans : news:4320808c$0$17217$, <pas-despam> @Bwanadoo.fr>" < disait :
Bonjour,
Bonsoir :-)
private tampon as string private comptetampon as integer
Private Sub MSComm1_OnComm() Dim a$
a$ = MSComm1.Input
If a$ <> Chr(13) Then If a$ = Chr(10) Then Else comptetampon = comptetampon + 1 tampon = tampon & a$ 'utiliser pour séparer les données d'une trame If comptetampon = 1 Or comptetampon = 3 Or comptetampon > 5 Then comptetampon = comptetampon + 1 tampon = tampon & " " End If If comptetampon = 6 Then comptetampon = 0 End If Text1.Text = tampon End If
Else 'ecrit la ligne dans fichier texte (objet lever) lever.writeline (tampon) tampon = "" Text1.Text = ""
End If
End Sub
Alors là, j'aimerais quelques explications :-) Je ne vois absolument pas pourquoi tu insères un espace tous les deux caractères ! Et encore moins pourquoi cette limite de 6 ?
Peux-tu développer un peu ?
Sinon j'en profite pour expliquer un petit point du programme que j'ai posté. Je teste le LF (qui vient après le CR). Donc le CR est ajouté dans Trame. Il se traduira par un saut de ligne dans le fichier texte (et un seul car il y a un point-virgule).
-- Fred http://www.cerbermail.com/?3kA6ftaCvT
Dans : news:4320808c$0$17217$8fcfb975@news.wanadoo.fr,
<pas-despam> @Bwanadoo.fr>" < disait :
Bonjour,
Bonsoir :-)
private tampon as string
private comptetampon as integer
Private Sub MSComm1_OnComm()
Dim a$
a$ = MSComm1.Input
If a$ <> Chr(13) Then
If a$ = Chr(10) Then
Else
comptetampon = comptetampon + 1
tampon = tampon & a$
'utiliser pour séparer les données d'une trame
If comptetampon = 1 Or comptetampon = 3 Or comptetampon > 5 Then
comptetampon = comptetampon + 1
tampon = tampon & " "
End If
If comptetampon = 6 Then
comptetampon = 0
End If
Text1.Text = tampon
End If
Else
'ecrit la ligne dans fichier texte (objet lever)
lever.writeline (tampon)
tampon = ""
Text1.Text = ""
End If
End Sub
Alors là, j'aimerais quelques explications :-)
Je ne vois absolument pas pourquoi tu insères un espace tous les deux
caractères !
Et encore moins pourquoi cette limite de 6 ?
Peux-tu développer un peu ?
Sinon j'en profite pour expliquer un petit point du programme que j'ai
posté.
Je teste le LF (qui vient après le CR). Donc le CR est ajouté dans
Trame.
Il se traduira par un saut de ligne dans le fichier texte (et un seul
car il y a un point-virgule).
Dans : news:4320808c$0$17217$, <pas-despam> @Bwanadoo.fr>" < disait :
Bonjour,
Bonsoir :-)
private tampon as string private comptetampon as integer
Private Sub MSComm1_OnComm() Dim a$
a$ = MSComm1.Input
If a$ <> Chr(13) Then If a$ = Chr(10) Then Else comptetampon = comptetampon + 1 tampon = tampon & a$ 'utiliser pour séparer les données d'une trame If comptetampon = 1 Or comptetampon = 3 Or comptetampon > 5 Then comptetampon = comptetampon + 1 tampon = tampon & " " End If If comptetampon = 6 Then comptetampon = 0 End If Text1.Text = tampon End If
Else 'ecrit la ligne dans fichier texte (objet lever) lever.writeline (tampon) tampon = "" Text1.Text = ""
End If
End Sub
Alors là, j'aimerais quelques explications :-) Je ne vois absolument pas pourquoi tu insères un espace tous les deux caractères ! Et encore moins pourquoi cette limite de 6 ?
Peux-tu développer un peu ?
Sinon j'en profite pour expliquer un petit point du programme que j'ai posté. Je teste le LF (qui vient après le CR). Donc le CR est ajouté dans Trame. Il se traduira par un saut de ligne dans le fichier texte (et un seul car il y a un point-virgule).
-- Fred http://www.cerbermail.com/?3kA6ftaCvT
Fred a écrit :
Alors là, j'aimerais quelques explications :-) Je ne vois absolument pas pourquoi tu insères un espace tous les deux caractères ! Et encore moins pourquoi cette limite de 6 ?
Peux-tu développer un peu ?
Sinon j'en profite pour expliquer un petit point du programme que j'ai posté. Je teste le LF (qui vient après le CR). Donc le CR est ajouté dans Trame. Il se traduira par un saut de ligne dans le fichier texte (et un seul car il y a un point-virgule).
Salut,
En fait, j'ai fait un copier/coller d'un code que j'ai écrit il y a longtemps, donc j'ai pas trop regardé, la variante était dans le test de Chr(13). Pour les espaces insérés c'est pour rendre plus lisible le fichier texte généré (dans mon cas il s'agit d'un mélange de code, de mesures, de date et d'heure). Si tu regardes bien, l'espace est inséré tous les caractères. La méthode utilisée est débile je le reconnais mais je crois me souvenir avoir fait ça pour le déboggage, et en bon feignant j'ai pas optimisé, sachant que cette appli est à mon usage unique ... J'ai même pas créé d'exe je l'utilise toujours dans l'IDE. (!) Et même plus: j'utilise le FSO dans cette appli (là y'a Zouri qui va s'énerver).
Bon bref j'accepte humblement de me faire traiter d'idiot sur ce coup là! Ca prouve au moins qu'il y en a qui lise le code avec attention.
A+
Christophe
Fred a écrit :
Alors là, j'aimerais quelques explications :-)
Je ne vois absolument pas pourquoi tu insères un espace tous les deux
caractères !
Et encore moins pourquoi cette limite de 6 ?
Peux-tu développer un peu ?
Sinon j'en profite pour expliquer un petit point du programme que j'ai
posté.
Je teste le LF (qui vient après le CR). Donc le CR est ajouté dans Trame.
Il se traduira par un saut de ligne dans le fichier texte (et un seul
car il y a un point-virgule).
Salut,
En fait, j'ai fait un copier/coller d'un code que j'ai écrit il y a
longtemps, donc j'ai pas trop regardé, la variante était dans le test de
Chr(13).
Pour les espaces insérés c'est pour rendre plus lisible le fichier texte
généré (dans mon cas il s'agit d'un mélange de code, de mesures, de date
et d'heure).
Si tu regardes bien, l'espace est inséré tous les caractères.
La méthode utilisée est débile je le reconnais mais je crois me souvenir
avoir fait ça pour le déboggage, et en bon feignant j'ai pas optimisé,
sachant que cette appli est à mon usage unique ...
J'ai même pas créé d'exe je l'utilise toujours dans l'IDE. (!)
Et même plus: j'utilise le FSO dans cette appli (là y'a Zouri qui va
s'énerver).
Bon bref j'accepte humblement de me faire traiter d'idiot sur ce coup là!
Ca prouve au moins qu'il y en a qui lise le code avec attention.
Alors là, j'aimerais quelques explications :-) Je ne vois absolument pas pourquoi tu insères un espace tous les deux caractères ! Et encore moins pourquoi cette limite de 6 ?
Peux-tu développer un peu ?
Sinon j'en profite pour expliquer un petit point du programme que j'ai posté. Je teste le LF (qui vient après le CR). Donc le CR est ajouté dans Trame. Il se traduira par un saut de ligne dans le fichier texte (et un seul car il y a un point-virgule).
Salut,
En fait, j'ai fait un copier/coller d'un code que j'ai écrit il y a longtemps, donc j'ai pas trop regardé, la variante était dans le test de Chr(13). Pour les espaces insérés c'est pour rendre plus lisible le fichier texte généré (dans mon cas il s'agit d'un mélange de code, de mesures, de date et d'heure). Si tu regardes bien, l'espace est inséré tous les caractères. La méthode utilisée est débile je le reconnais mais je crois me souvenir avoir fait ça pour le déboggage, et en bon feignant j'ai pas optimisé, sachant que cette appli est à mon usage unique ... J'ai même pas créé d'exe je l'utilise toujours dans l'IDE. (!) Et même plus: j'utilise le FSO dans cette appli (là y'a Zouri qui va s'énerver).
Bon bref j'accepte humblement de me faire traiter d'idiot sur ce coup là! Ca prouve au moins qu'il y en a qui lise le code avec attention.
A+
Christophe
Fred
"<pas-despam> @Bwanadoo.fr>" <"<pas-despam> a écrit dans le message de news:4320a288$0$7829$
Salut,
Bonjour,
En fait, j'ai fait un copier/coller d'un code que j'ai écrit il y a longtemps, donc j'ai pas trop regardé, la variante était dans le test
de
Chr(13). Pour les espaces insérés c'est pour rendre plus lisible le fichier
texte
généré (dans mon cas il s'agit d'un mélange de code, de mesures, de
date
et d'heure). Si tu regardes bien, l'espace est inséré tous les caractères.
Vu,
La méthode utilisée est débile je le reconnais mais je crois me
souvenir
avoir fait ça pour le déboggage, et en bon feignant j'ai pas
optimisé,
sachant que cette appli est à mon usage unique ... J'ai même pas créé d'exe je l'utilise toujours dans l'IDE. (!) Et même plus: j'utilise le FSO dans cette appli (là y'a Zouri qui va s'énerver).
:-)
Bon bref j'accepte humblement de me faire traiter d'idiot sur ce coup
là!
Ce n'étais mon intention ! Je croyais avoir loupé quelque chose. Une précision de Pierremag dans un post que je n'aurais pas vu passer par exemple.
Ca prouve au moins qu'il y en a qui lise le code avec attention.
On a toujours à apprendre. Cette méthode de déclenchement d'événement à chaque caractère me paraît la plus simple et la plus fiable. Dès qu'on commence à lire les octets reçus par paquets (possible dans ce cas puisque les paquets sont de longueur fixe), on est toujours susceptible d'être mal calé si on prend la conversation en cours de route d'où complication du programme. Avec nos façons de procéder, s'il y a erreur, un seul paquet sera altéré.
À propos de la perte de trames évoquée par Pierremag, il faudrait vérifier que la com n'est jamais fermée. Il y a effectivement des buffers qui sont réinitialisés dans ce cas.
-- Fred http://www.cerbermail.com/?3kA6ftaCvT
"<pas-despam> @Bwanadoo.fr>" <"<pas-despam> a écrit dans le message de
news:4320a288$0$7829$8fcfb975@news.wanadoo.fr...
Salut,
Bonjour,
En fait, j'ai fait un copier/coller d'un code que j'ai écrit il y a
longtemps, donc j'ai pas trop regardé, la variante était dans le test
de
Chr(13).
Pour les espaces insérés c'est pour rendre plus lisible le fichier
texte
généré (dans mon cas il s'agit d'un mélange de code, de mesures, de
date
et d'heure).
Si tu regardes bien, l'espace est inséré tous les caractères.
Vu,
La méthode utilisée est débile je le reconnais mais je crois me
souvenir
avoir fait ça pour le déboggage, et en bon feignant j'ai pas
optimisé,
sachant que cette appli est à mon usage unique ...
J'ai même pas créé d'exe je l'utilise toujours dans l'IDE. (!)
Et même plus: j'utilise le FSO dans cette appli (là y'a Zouri qui va
s'énerver).
:-)
Bon bref j'accepte humblement de me faire traiter d'idiot sur ce coup
là!
Ce n'étais mon intention ! Je croyais avoir loupé quelque chose. Une
précision de Pierremag dans un post que je n'aurais pas vu passer par
exemple.
Ca prouve au moins qu'il y en a qui lise le code avec attention.
On a toujours à apprendre. Cette méthode de déclenchement d'événement à
chaque caractère me paraît la plus simple et la plus fiable. Dès qu'on
commence à lire les octets reçus par paquets (possible dans ce cas
puisque les paquets sont de longueur fixe), on est toujours susceptible
d'être mal calé si on prend la conversation en cours de route d'où
complication du programme. Avec nos façons de procéder, s'il y a erreur,
un seul paquet sera altéré.
À propos de la perte de trames évoquée par Pierremag, il faudrait
vérifier que la com n'est jamais fermée. Il y a effectivement des
buffers qui sont réinitialisés dans ce cas.
"<pas-despam> @Bwanadoo.fr>" <"<pas-despam> a écrit dans le message de news:4320a288$0$7829$
Salut,
Bonjour,
En fait, j'ai fait un copier/coller d'un code que j'ai écrit il y a longtemps, donc j'ai pas trop regardé, la variante était dans le test
de
Chr(13). Pour les espaces insérés c'est pour rendre plus lisible le fichier
texte
généré (dans mon cas il s'agit d'un mélange de code, de mesures, de
date
et d'heure). Si tu regardes bien, l'espace est inséré tous les caractères.
Vu,
La méthode utilisée est débile je le reconnais mais je crois me
souvenir
avoir fait ça pour le déboggage, et en bon feignant j'ai pas
optimisé,
sachant que cette appli est à mon usage unique ... J'ai même pas créé d'exe je l'utilise toujours dans l'IDE. (!) Et même plus: j'utilise le FSO dans cette appli (là y'a Zouri qui va s'énerver).
:-)
Bon bref j'accepte humblement de me faire traiter d'idiot sur ce coup
là!
Ce n'étais mon intention ! Je croyais avoir loupé quelque chose. Une précision de Pierremag dans un post que je n'aurais pas vu passer par exemple.
Ca prouve au moins qu'il y en a qui lise le code avec attention.
On a toujours à apprendre. Cette méthode de déclenchement d'événement à chaque caractère me paraît la plus simple et la plus fiable. Dès qu'on commence à lire les octets reçus par paquets (possible dans ce cas puisque les paquets sont de longueur fixe), on est toujours susceptible d'être mal calé si on prend la conversation en cours de route d'où complication du programme. Avec nos façons de procéder, s'il y a erreur, un seul paquet sera altéré.
À propos de la perte de trames évoquée par Pierremag, il faudrait vérifier que la com n'est jamais fermée. Il y a effectivement des buffers qui sont réinitialisés dans ce cas.
-- Fred http://www.cerbermail.com/?3kA6ftaCvT
> On a toujours à apprendre. Cette méthode de déclenchement d'événement à chaque caractère me paraît la plus simple et la plus fiable. Dès qu'on commence à lire les octets reçus par paquets (possible dans ce cas puisque les paquets sont de longueur fixe), on est toujours susceptible d'être mal calé si on prend la conversation en cours de route d'où complication du programme. Avec nos façons de procéder, s'il y a erreur, un seul paquet sera altéré.
À propos de la perte de trames évoquée par Pierremag, il faudrait vérifier que la com n'est jamais fermée. Il y a effectivement des buffers qui sont réinitialisés dans ce cas.
Salut,
La méthode caractère par caractère (RThreshold=1) me parait effectivement la meilleure. Concernant la longueur des paquets, je vois pas où il est préciser qu'ils sont de longueur fixe, dans mon cas il ne le sont pas, la seule certitude est la terminaison CR/LF.
Pour la verif comm ouvert je gère un on_error sur les setting (si le port est déjà ouvert : erreur), mais dans mon cas Handshaking = 1 ou 0 il appartient à l'utilisateur d'établir la connection et de lancer le comm depuis l'appareil de mesure, pour une conversation bidirectionnelle j'ai jamais fait. En fait la gestion d'un comm dépend beaucoup de l'appareil connecté et de la notice constructeur qui va avec.
A+
Christophe
> On a toujours à apprendre. Cette méthode de déclenchement d'événement à
chaque caractère me paraît la plus simple et la plus fiable. Dès qu'on
commence à lire les octets reçus par paquets (possible dans ce cas
puisque les paquets sont de longueur fixe), on est toujours susceptible
d'être mal calé si on prend la conversation en cours de route d'où
complication du programme. Avec nos façons de procéder, s'il y a erreur,
un seul paquet sera altéré.
À propos de la perte de trames évoquée par Pierremag, il faudrait
vérifier que la com n'est jamais fermée. Il y a effectivement des
buffers qui sont réinitialisés dans ce cas.
Salut,
La méthode caractère par caractère (RThreshold=1) me parait
effectivement la meilleure.
Concernant la longueur des paquets, je vois pas où il est préciser
qu'ils sont de longueur fixe, dans mon cas il ne le sont pas, la seule
certitude est la terminaison CR/LF.
Pour la verif comm ouvert je gère un on_error sur les setting (si le
port est déjà ouvert : erreur), mais dans mon cas Handshaking = 1 ou 0
il appartient à l'utilisateur d'établir la connection et de lancer le
comm depuis l'appareil de mesure, pour une conversation bidirectionnelle
j'ai jamais fait.
En fait la gestion d'un comm dépend beaucoup de l'appareil connecté et
de la notice constructeur qui va avec.
> On a toujours à apprendre. Cette méthode de déclenchement d'événement à chaque caractère me paraît la plus simple et la plus fiable. Dès qu'on commence à lire les octets reçus par paquets (possible dans ce cas puisque les paquets sont de longueur fixe), on est toujours susceptible d'être mal calé si on prend la conversation en cours de route d'où complication du programme. Avec nos façons de procéder, s'il y a erreur, un seul paquet sera altéré.
À propos de la perte de trames évoquée par Pierremag, il faudrait vérifier que la com n'est jamais fermée. Il y a effectivement des buffers qui sont réinitialisés dans ce cas.
Salut,
La méthode caractère par caractère (RThreshold=1) me parait effectivement la meilleure. Concernant la longueur des paquets, je vois pas où il est préciser qu'ils sont de longueur fixe, dans mon cas il ne le sont pas, la seule certitude est la terminaison CR/LF.
Pour la verif comm ouvert je gère un on_error sur les setting (si le port est déjà ouvert : erreur), mais dans mon cas Handshaking = 1 ou 0 il appartient à l'utilisateur d'établir la connection et de lancer le comm depuis l'appareil de mesure, pour une conversation bidirectionnelle j'ai jamais fait. En fait la gestion d'un comm dépend beaucoup de l'appareil connecté et de la notice constructeur qui va avec.
A+
Christophe
Pierremag
Merci pour toutes ces infos.
Quelques unes ont été appliquées, et nous cherchons toujours.
La méthode caractere par caractere reste à tester, et j'ai bon espoir ...
Merci.
Pierre
Merci pour toutes ces infos.
Quelques unes ont été appliquées, et nous cherchons toujours.
La méthode caractere par caractere reste à tester, et j'ai bon espoir
...
