Discussion :

[petitclem]

Bonjour � tous,

Voici mon soucis : j'ai une fonction de lecture du port com (celui-ci est bien d�tect�), il y a bien des infos qui circule sur le port mais cela ne vient pas dans mon appli !!!

Je vous post le code de lecture :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
 
ErrCom Com::LectureCom (void *lpBuf,unsigned int nCountMax, unsigned int* pCountRead)
{
 
	COMSTAT Stat;
	DWORD Errors;
	unsigned int nCarALire;
	NCarLus = 0;
 
	if(hdl!=NULL)
	{
		//on pari sur pas d'erreur
		EtatCom = ErrCom_None;
 
		//Pour éviter de gérer un time out
		//Sleep((unsigned long)500);
 
		int TimeoutRead=500;
		timeouts.ReadIntervalTimeout=MAXWORD;
		timeouts.ReadTotalTimeoutMultiplier=0;
		timeouts.ReadTotalTimeoutConstant=TimeoutRead;
		timeouts.WriteTotalTimeoutMultiplier=0;
		timeouts.WriteTotalTimeoutConstant=0;
 
 
		//Pour connaitre le nombre d'octets dans le buffer d'entrée
		ClearCommError(hdl,&Errors,&Stat);
		nCarALire=Stat.cbInQue;
 
		//On effectue la lecture si il y a des caractères présents
		if( (nCarALire>0)&&(nCarALire<=nCountMax) )
		{
			if(ReadFile(hdl,lpBuf,nCarALire,&NCarLus,NULL)==0)
			{
				EtatCom = ErrCom_Reception;
			}
 
		}
		*pCountRead=NCarLus;
	}
	else
		//Le port n a pas été ouvert
		EtatCom = ErrCom_Creation;
 
	//Compte rendu de l'exécution
	return EtatCom;
 
 
}

et voici l'appe de la fonction situ�e dans un thread :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
 
do
		{
			Nblu = laCom.NCarLus;
			laCom.LectureCom(buf,sizeof(buf), &Nblu);
		}
		while (Nblu!=18);

Merci d'avance pour votre aide.

[Crayon]

J'ai pas le temps de trop regarder ton code en d�tail, mais tu pourrais aller le site Web suivant: http://maikel.galeon.com/serie/bcbcomm.html

Sinon tu peux toujours utiliser le composant TComPort: http://trote.developpez.com/tutoriel...ear-rad-studio

[petitclem]

Bonjour Crayon et merci d'avoir r�pondu.

Pour mieux comprendre, je post mon fichier qui g�re la Com s�rie :
UCom.cpp

UCom.h

et je fais appel aux fonctions de ce fichier dans un thread :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
        Com laCom;
 
	AnsiString COM = laCom.InitCom();
	laCom.ConnectCom(COM.c_str(),38400,8,0,1);
 
 
	while (Suspended == false)
	{
 
		do
		{
 
			laCom.LectureCom(buf,sizeof(buf), &Nblu);
		}
		while (Nblu!=18);

J'ai test� avec un "sniffer" de port et il y a bien des infos qui arrivent du port, cependant je n'ai rien qui vient sur mon appli : le programme n'arr�te pas de boucler au niveau de la lecture !!!

[Crayon]

Un petit conseil rapide, tu devrais regarder en premier lieu si cette commande fonctionne:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

	laCom.ConnectCom(COM.c_str(),38400,8,0,1);

Si la valeur de retour est ErrCom_None, alors tu peux aller dans le while.

[petitclem]

Bonjour,

J'ai v�rifi� la valeur de retour de cette fonction et j'ai bien "ErrCom_None" !!!

Je pense vraiment que le probl�me vient de ma boucle while et/ou de ma fonction de lecture.

Vraiment l� je suis � court d'id�es, je ne sais pas comment r�soudre ce probl�me.

[totoche76]

Hello,

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
		//On effectue la lecture si il y a des caractères présents
		if( (nCarALire>0)&&(nCarALire<=nCountMax) )
		{
			if(ReadFile(hdl,lpBuf,nCarALire,&NCarLus,NULL)==0)
			{
				EtatCom = ErrCom_Reception;
			}
 
		}

Question: Que vaut nCountMax ?? Et que se passe-t'il s'il y a plus de nCountMax octets dans le buffer du port COM ?

[petitclem]

Bonjour,

nCountmax vaut 18 car la trame qui arrive sur mon port COM a toujours 18 octets.

[totoche76]

Et, du coup, que vaut nCarALire ??

[petitclem]

Oui, c'est vrai "nCarALire" dans le coup vaut aussi 18 !!!

A vrai dire je suis un peu perdu !!!

J'ai voulu en fait mettre dans une unit� tout ce qui concerne la communication avec le port COM au lieu de mettre tout � la suite dans mon thread.

[totoche76]

Marrant (enfin, fa�on de parler...), j'ai essay� ton code chez moi (UCom.cpp, sans utiliser la fonction InitCom ), et j'arrive � lire avec...



L�, je n'ai pas d'id�es...

[petitclem]

A�e, et bien moi non plus, je suis d�sesp�r� !!!

Voila maintenant plus d'une semaine que je planche dessus et rien !!!

[Luc84]

Bonjour,

tu dis que tu appelles tes fonctions � partir d'un thread, mais il ne faut pas oublier que tout n'est pas autoris� dans le code d'un thread. Dailleurs, lors de la cr�ation d'un thread, l'IDE Borland ajoute syst�matiquement ce petit commentaire :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
//---------------------------------------------------------------------------
//   Important : les méthodes et les propriétés des objets dans la VCL ne peuvent
//   être utilisées que dans une méthode appelée en utilisant Synchronize, par exemple :
//
//      Synchronize(UpdateCaption);
//
//   où UpdateCaption pourrait être du type :
//
//      void __fastcall MonThread::UpdateCaption()
//      {
//        Form1->Caption = "Mise à jour dans un thread";
//      }
//---------------------------------------------------------------------------

D'apr�s ce que j'ai lu dans ton code :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

	ShowMessage ("Base de collecte connectée sur le port " + COM);

--> Cr�er une fonction � part et l'appeler par la m�thode "Synchronize()", ou supprimer dans un premier temps pour faire tes essais.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

			COM = AnsiString(szPortName);

Les "AnsiString" sont des objets VCL et NE DOIVENT PAS ETRE UTILISES DANS UN THREAD. J'en ai fait l'exp�rience. A remplacer par une chaine de caract�res :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

char COM[10];

Pour te simplifier les choses, tu pourrais tester ton code � partir d'une fiche et non pas � partir d'un thread.

[petitclem]

Bonjour et merci Luc84 pour ton aide !

Le soucis vient je pense de la fonction de lecture : j'ai une autre application qui faisait la m�me chose que je veux faire maintenant sauf qu'avant toutes les fonctions d'ouverture, de lecture, ... du port COM �taient mises � la suite dans un thread.
Maintenant, en ayant mis ces fonctions � part dans une unit�, je n'ai plus rien.
Le point flou est que lorsque je lance mon ancienne application (�a d�tecte...), que je la referme et que j'ouvre ma nouvelle apr�s �a fonctionne !!!!!!!

C'est � ne plus rien n'y comprendre !

[Luc84]

Bonjour,

je n'ai pas tout compris !
D�cris pr�cis�ment "l'ancienne application" et la "nouvelle".

Le soucis vient je pense de la fonction de lecture : j'ai une autre application qui faisait la m�me chose que je veux faire maintenant sauf qu'avant toutes les fonctions d'ouverture, de lecture, ... du port COM �taient mises � la suite dans un thread.
Maintenant, en ayant mis ces fonctions � part dans une unit�, je n'ai plus rien.

L'important n'est pas l'endroit o� sont �crites ces fonctions, mais plut�t, � partir de quel module elles sont appel�es.
Si elles sont appel�es � partir de la fonction "Execute()" d'un thread, alors il faut respecter les restrictions que j'ai cit� dans mon message pr�c�dent.

Maintenant, en ayant mis ces fonctions � part dans une unit�, je n'ai plus rien.

Qu'est-ce que �a veut dire? "Je n'ai plus rien qui marche" ou "Je n'ai plus de probl�me"?

Le point flou est que lorsque je lance mon ancienne application (�a d�tecte...), que je la referme et que j'ouvre ma nouvelle apr�s �a fonctionne !!!!!!!

Qu'est-ce que �a veut dire "�a d�tecte..."?
Si la "nouvelle" fonctionne apr�s avoir lanc� "l'ancienne application", c'est que "l'ancienne application" initialise quelque chose que ne fait pas la nouvelle.
Mais une fois de plus, teste tes fonctions dans une fiche, pas dans un thread.
Une fois que les fonctions sont ok, appelle les � partir d'un thread en respectant les restrictions.

[nirgal76]

Avec ton code, si nCountMax vaut 18, cela veut dire que si tu as plus de 18 octets d'arriv�s dans le port COM, tu ne passe pas par la fonction de lecture et tu vas boucler infiniment. �a peut durer longtemps !

Le mieux dans ce genre de lecture est de lire sur le port com octet par octet, de concat�ner les octets re�us dans un buffer et de traiter ce dernier � chaque arriv�e d'une nouvelle donn�e pour voir s'il a la bonne taille ou contient le bon type de trame (avec la bonne syntaxe etc...). Dans un buffer circulaire de 18 octet dans ton cas.
Mais �a va d�pendre beaucoup de l'appareil branch� sur le port com. Par exmple certaines balances � l'allumage vont envoyer des infos d'identification sur le port com. avec ta boucle de lecture de 18 octets pas plus pas moins, tu bouclerais � l'infini car tu aurais ... 10 octets d'identification + 18 de tes trames de don�nes =28. ta boucle ne fonctionne plus.

sans compter qu'au moment ou tu vide le port com avant de l'ouvrir et le lire, qui te dis qu'il n'�tait pas en milieu de r�ception de trame.
regarde ta boucle :
admettons, tu vide les buffers et tu ouvre le port com en milieu de trame => apr�s ton vidage, le p�riph�rique va envoyer les 9 octets restants de la trame qu'il venait d'envoyer. ta boucle attends 18 octects donc, elle ne lit pas. puis le p�riph envoie une nouvelle trame => +18 = 27 octet. ta boucle ne lit pas car > 18 et voila, tu boucle � l'infini.
la aussi �a va d�pendre du p�riph, certains n'enverrons rien tant que ton port n'est pas ouvert mais �a va d�pendre de comment il est param�tr� (notamment au niveau du controle de flux, j'ai deja eu le probleme).

bref, je te conseille de revoir s�rieusement ton algo de lecture et surtout de donner plus de renseignement si tu veux obtenir une aide plus cibl�e car l�, ce n'est pas �vident. on ne sait rien de la config du p�riph, des trames qu'il envoie, s'il en envoi continuellement etc...(ni le code complet de ta boucle de thread et du code qui le cr��/d�truit).

Nirgal76

nb: tu peux utiliser des objets VCL dans un thread si tu ne les appelle pas dans le contexte d'un autre thread (le principal par exemple). Dans ce dernier cas, il faut de la synchro mais si tout se passe dans le meme contexte, aucune synchro n'est n�cessaire (ni meme souhaitable, �a peut amener � des blocages si c'est fait n'importe comment).

[petitclem]

Bonjour,

merci encore pour votre aide.
Alors pour ce qui est de mon code, l'unit� g�rant la com :
UCom.cpp

UCom.h

Mon thread :
UThread.h
UThread.cpp

L'application qui marchait avant avec tout inclus dans mon thread :
Thread1.zip

Pour les 2 applis, le module branch� en usb au pc envoi r�guli�rement 18 octets (8 bits de donn�es, pas de parit� et 1 de stop).

Pour ce qui est de la lecture et je pense que le probl�me vient de cette fonction, j'ai beau y regarder mais je n'y comprend plus rien ... blas� !



Merci d'avance pour votre aide, � bient�t !

[petitclem]

Bonjour,

suite � mon probl�me, je n'ai toujours pas trouv� de solution et je suis toujours bloqu� !

Est ce que quelqu'un aurait une id�e de codage car l� je ne sais vraiment plus.

Merci et � bient�t !

[nirgal76]

Bonjour,

Aie aie aie...Ce genre de code dans un thread

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
 
FormClient->ChartPH->View3D = false;
FormClient->ChartConductivite->View3D = false;
FormClient->ChartTemperature->View3D = false;

est � proscrire ABSOLUMENT. Il ne faut pas modifier des objets de l'interface graphique depuis un thread sans synchronisation. et �a revient � plusieurs endroits.
Il te faut revoir toute l'architecture de ton application l�.
Car que ce soit les manques de synchro dans le thread ou la fa�on de lire sur le port com (lecture qui va boucler � l'infini s'il y a plus de 20 caract�res dans le buffer du port com), c'est un peu la cata :/

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
 
ErrCom Com::LectureCom (void *lpBuf,unsigned int nCountMax, unsigned int *pCountRead)
{
	COMSTAT Stat;
	DWORD Errors;
	unsigned int nCarALire;
	unsigned long NCarLus;
 
	if(hdl!=NULL)
	{
		//on pari sur pas d'erreur
		EtatCom=ErrCom_None;
 
		//Pour éviter de gérer un time out
		Sleep((unsigned long)500);
 
		//Pour connaitre le nombre d'octets dans le buffer d'entrée
		ClearCommError(hdl,&Errors ,&Stat);
		nCarALire=Stat.cbInQue;
 
		//On effectue la lecture si il y a des caractères présents
		if( (nCarALire>0)&&(nCarALire<=nCountMax) )
		{
			if(ReadFile(hdl,lpBuf,sizeof(lpBuf),&NCarLus,NULL)==0)
			{
				EtatCom=ErrCom_Reception;
			}
 
		}
		*pCountRead=NCarLus;
	}
	else
	//Le port n a pas été ouvert
	EtatCom=ErrCom_Creation;
 
	//Compte rendu de l'exécution
	return EtatCom;
 
}

L�, probl�me car si nCarALire est > � nCountMax (20), (par exemple, 2 trames de 18 sont pass�es donc il y a 36 octets dans le buffer) tu ne passe pas dans le ReadFile, mais ! tu fait qd meme l'affectation
*pCountRead=NCarLus.
Hors, NCarLus n'a pas �t� initialis� dans ce cas pr�cis. En mode debug, il contient 0 surement, mais en mode release c'est au petit bonheur la chance.

Et s'il contient effectivement 0, en revenant dans le thread

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
 
do
		{
 
			laCom.LectureCom(buf,sizeof(buf), &Nblu);
		}
		while (Nblu!=18);

comme nblu sera = � 0, �a va boucler. et comme le buffer de comm va continuer � se remplir (au pire, rester comme il est donc >20), et bien �a va boucler comme �a � l'infini.

En r�sum�, La com, con�ue comme elle est, elle peut boucler � l'infini et bloquer l'application.
Les erreurs de synchro vont provoquer des exceptions et/ou des fuites m�moires et autres d�calages dans tous les sens niveau m�moire.

Faut tout repenser de A � Z l�, j'suis d�sol� :/. Et surtout revoir l'utilisation des thread en VCL avant de te replonger dans le code.

Nirgal76


edit: ta version pr�c�dente "tout dans le thread" ne comportait pas cette boucle infini donc �a marchait. Mais les acc�s � l'interface graphique depuis le thread y �tait nombreux donc pas bon du tout quand meme.
Ca peut marcher si le thread principal n'acc�de pas aux objets en meme temps. Mais si c'�tait le cas ou alors dans un contexte o� ton thread de com serait lanc� plusieurs fois en parall�le, ce serait � coup sur l'exception.

[petitclem]

Ok, merci Nirgal76,

pour ce qui est de la modification des objets de l'interface graphique OK : je change cela, j'ai bien compris.

Par contre le gros point dur est la fonction de lecture de mes trames !!!

C'est l� vraiment que j'ai besoin d'aide pour le codage !

[nirgal76]

Ok, merci Nirgal76,

pour ce qui est de la modification des objets de l'interface graphique OK : je change cela, j'ai bien compris.

Par contre le gros point dur est la fonction de lecture de mes trames !!!

C'est l� vraiment que j'ai besoin d'aide pour le codage !

ben d�j�, dans la ligne
if( (nCarALire>0)&&(nCarALire<=nCountMax) )
de la fonction de lectureCom, je ne vois pas l'utilit� de tester nCarALire<=nCountMax car meme si c'est plus grand, tu ne demande qu'a lire sizeof(buf) caract�res.
!! et en plus, sizeof(lpBuf) va te retourner 4 et non pas 20, �a va te retourner la taille du pointeur, pas la taille du buffer allou� (tiens, je me demande si ton erreur vient pas de la d'ailleurs). car si tu ne demande qu'a lire 4 octets, t'aura jamais 18 de lu et donc, bouclage � l'infini.

Remplace

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
 
		//On effectue la lecture si il y a des caractères présents
		if( (nCarALire>0)&&(nCarALire<=nCountMax) )
		{
			if(ReadFile(hdl,lpBuf,sizeof(lpBuf),&NCarLus,NULL)==0)
			{

par

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
 
		//On effectue la lecture si il y a des caractères présents
		if(nCarALire>0)
		{
			if(ReadFile(hdl,lpBuf,nCountMax,&NCarLus,NULL)==0)
			{

pour voir


edit:

et surtout aussi :
unsigned long NCarLus=0;