Problème avec l'évenement OnComm de l'objet MSComm

politorichard Messages postés 4 Date d'inscription jeudi 19 juin 2008 Statut Membre Dernière intervention 20 juin 2008 - 19 juin 2008 à 14:32
cs_Jack Messages postés 14006 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 - 20 juin 2008 à 13:19
Voila je vous explique brievement mon problème :

J'ai un capteur qui envoie en continu des données sur un port série, ce sont des strings de 6 caractères.J'utilise donc l'évenement OnComm avec LaserViaCom.RTHreshold 6 après avoir fait une recherche du caractère retour chariot qui marque la fin d'une donnée (avec cette fois LaserViaCom.RTHreshold 1).

J'ai donc le code suivant :

Private Sub LaserViaCom_Oncomm()

Select Case LaserViaCom.CommEvent
      Case comEvReceive
         If StartDataLaser = False Then      ' cette variable passe a vrai lorsque le début de chaîne est repérée et que la 
                                                               ' lecture se fait sur 6 caratères  
            ComDataLaser = LaserViaCom.Input
            If ComDataLaser = Chr(13) Then
               StartDataLaser = True
               LaserViaCom.InputLen = 6
               LaserViaCom.RThreshold = 6
            End If
         Else
            ComDataLaser = LaserViaCom.Input
            tabDef(nbDef).Def = Round(((CSng(Mid(ComDataLaser, 1, 5)) * 0.0000623167) - 0.01) * 750, 2) + 200
               nbDef = nbDef + 1
         End If
End Select
End Sub

Bon globalement tout va bien, sauf que par moment et en fait très rarement (mais ça arrive quand même !!!!!)
Il semble que la variable ComDataLaser qui devrait à chaque fois être égale à "XXXXX"&Chr(13) se retrouve avec le caractère chr(13) au beau milieu de la chaîne, il semble qu'a un moment donné un ou plusieurs caractères ne soit pas lu dans le tampon et que la lecture sur 6 caratères se décale, et entraine la lecture d'un chr(13) au beau milieu de la chaîne !!

Ou bien c'est mon capteur qui de temps en temps "oublie" des caractères (mais ça m'étonne)

Voila je suis ouvert à toutes les sugestions !!

Encore merci

7 réponses

lillith212 Messages postés 1229 Date d'inscription vendredi 16 novembre 2007 Statut Membre Dernière intervention 16 juin 2009
19 juin 2008 à 15:30
Salut,
Pourquoi faire le traitement directement dans l'évenement??? Tu peux stocker les infos dans un buffer et le traiter à l'extérieur de ton événement.
C'est juste une sugestion. Car a mon avis ton problème est une question de temps. Dans le sens ou le temps que le traitement est fait il passe au dessus de ton chr(13). Ton traitement est rapide mais il lui arrive d'avoir des ratés...

S.L.B.
<hr />
0
cs_Jack Messages postés 14006 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 79
19 juin 2008 à 16:19
Salut
Lilith à raison, il ne faut pas synchroniser la réception par la lecture de X caractères : Le flux de données peut se décaler car si ton PC est très occupé et ne traite pas l'arrivée de données assez rapidement --> Les trames d'infos se retrouvent collées les une aux autres --> Décalage probable des trames
Ou encore, la ligne série reçoit des parasites ...


Il faut tout lire à chaque fois que le OnComm se déclenche, stocker les données dans une variable déclarée dans "Déclaration"
Ensuite, dans un Timer par exemple ou à la sortie de OnComm, tu analyses le contenu de la chaine récupérée en faisant la détection du Chr$(13) pour isoler tes 6 caractères.
Il faut alors travailler avec les instructions de traitement de chaine : Instr, Mid, Left, Right, Split ...

Vala
Jack, MVP VB
NB : Je ne répondrai pas aux messages privés





<hr />

Le savoir est la seule matière qui s'accroit quand on la partage (Socrate)
0
politorichard Messages postés 4 Date d'inscription jeudi 19 juin 2008 Statut Membre Dernière intervention 20 juin 2008
19 juin 2008 à 16:21
Ok merci lillith212 pour ta réponse!

Si je comprend bien le temps mis par le traitement fait en sorte qu'à un moment le buffer est plein. Les données envoyées par le capteur ne sont plus stockées jusqu'à ce que 6 caratères soient lus dans le buffer. 6 autres caractères peuvent alors être stockés à nouveau, mais un chr(13) peut se trouver au milieu !! 

Bon mais si j'augmente la taille du buffer le problème devrait moins se poser (taille actuelle : LaserViaCom.InBufferSize = 2048). En fait j'ai testé plusieurs taille de buffer mais je n'ai pas pu conclure grand chose car le problème dans tous les cas ne se produit que très rarement.


Sinon Ok pour ne faire le traitement que lorsque la lecture du port est stopée.


 
0
politorichard Messages postés 4 Date d'inscription jeudi 19 juin 2008 Statut Membre Dernière intervention 20 juin 2008
19 juin 2008 à 17:01
Merci Jack !!
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
lillith212 Messages postés 1229 Date d'inscription vendredi 16 novembre 2007 Statut Membre Dernière intervention 16 juin 2009
19 juin 2008 à 23:40
Re:


Non ce n'est  pas une question de taille de buffer, c'est une question de traitement de données.et de durée de traitement...
je t'explique :
Voila ce que tu fais toi avec ton programme :
une trame arrive, tu la lis et tu la traite...
Seulement pendant que tu es entrain de la lire et/ou de la traiter, une autre trame peut arriver entre temps.
donc si une autre trame arrive en meme temps que ton traitement, il arrive qu'elle soit "desorganisée" et donc que tu te retrouve avec un chr(13) en plein milieu... Tu vois la taille du buffer n'interviens pas...
Ce que tu dois faire c'est gerer ceci a la maniere d'un automate... c'est a dire
un message arrive, il est stocké dans une variable, et c'est cette variable que tu traites en extérieur. comme ca, ton buffer de mscomm peut continuer à recevoir sans etre perturbé...
Jack a raison dans l'utilisation du traitement de caractere...
Voila, j'espere que tu y vois plus clair sinon n'hesite pas...

S.L.B.
<hr />
0
politorichard Messages postés 4 Date d'inscription jeudi 19 juin 2008 Statut Membre Dernière intervention 20 juin 2008
20 juin 2008 à 10:00
Ok j'ai compris !

Mais est ce qu'on peut supposer (en théorie, sans aller trop loin non plus !!) que le simple fait de lire la donnée et de la stockée (c'est le traitement minimum que l'on puisse faire) ne puisse pas engendrer ce même type de problème, avec par exemple des vitesses élevées de 115.2 kBd.

Dernière question (c'est juré !) :

Mon capteur peut effectuer des mesures à plusieurs vitesses : 312 pts/s, 625, 1250, 2500. La vitesse à laquelle elles sont transmises via le port com peut également varier 19200 Bd, 57600, 115200. Y a-t-il un lien ? Si je choisi 2500 pts/s faut-il que je choisisse 115200 Bd ? 

En tout les cas merci pour vos réponses !
0
cs_Jack Messages postés 14006 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 79
20 juin 2008 à 13:19
Re
Si ta comm est rapide et qu'elle ne te fournit qu'une seule valeur rafraichie, quand tu reçois un paquet de données, il n'y a que la dernière qui soit interessante (à moins que tu enregistres chaque valeur).
Dans ce cas, une fois que tu as récupéré tout le buffer, il te suffit de détecter le dernier Chr(13), avec InstrRev par exemple, et de lire la donnée dans les 6 caractères qui le précèdent.

Vala
Jack, MVP VB
NB : Je ne répondrai pas aux messages privés

<hr />Le savoir est la seule matière qui s'accroit quand on la partage (Socrate)
0
Rejoignez-nous