Discussion :

[homeostasie]

Bonjour,

Voici le contexte, j'effectue un stage dans la supervision technique centralis�e d'un groupe et l'une de mes taches est de v�rifier si les informations transmises par les �quipements sont coh�rentes.
Pour cela, je dois r�aliser un soft qui jouera le r�le de ma�tre et qui me permettra de communiquer par liaison s�rie RS232 avec un TES.

Remarque : Les TES convertissent leurs entr�es( 32 par exemple), chaque broche correspondant � l'�tat d'un �quipement, en mots qui sont � s�rialis�s � et dans l�autre sens, � d�s�rialisent � les mots en provenance du ma�tre pour commander les sorties.
Le protocole de communication s�rialis� utilis� est le Modbus/Jbus.

J'ai commenc� � faire des recherches et des questions me viennent en t�te :
A l'aide de fonction de lecture et d'�criture ( par ex : ReadFile,WriteFile ou SendData et ReadData de la classe CSerial pour ceux qui connaissent), je dois emettre le protocole JBUS sous forme de CString??
Pour emettre des donn�es � travers une liaison s�rie, sont elles toujours de type char, cstring?
PLusieurs classes sont disponiblibes sur codeguru, je n'arrive pas � avoir assez de recul pour le choix de la classe :
CSerial qui me semble simple : http://www.codeguru.com/Cpp/I-N/network/serialcommunications/article.php/c2503/
CSerialPort : http://www.codeguru.com/Cpp/I-N/network/serialcommunications/article.php/c5395
Serial Communication in Windows : http://www.codeguru.com/Cpp/I-N/network/serialcommunications/article.php/c5425/

Merci si vous pouvez r�pondre � ces questions, ou m'expliquer, m'orienter.

Bonne journ�e

Nicolas

[farscape]

salut,
regarde ce post dans la faq et l'exemple qui va avec:
http://c.developpez.com/faq/vc/?page...WithSerialPort

[Caine]

Bonjour,

A l'aide de fonction de lecture et d'�criture ( par ex : ReadFile,WriteFile ou SendData et ReadData de la classe CSerial pour ceux qui connaissent), je dois emettre le protocole JBUS sous forme de CString??
Pour emettre des donn�es � travers une liaison s�rie, sont elles toujours de type char, cstring?

Les ports s�ries ont deux mode de fonctionnement : En mode texte ou en mode binaire. Les trames Modbus sont des suite d'octets protocol�s, donc le mode binaire est mieux. Il te suffit d'avoir une tableau d'�l�ments "unsigned char" que tu envois par la RS232 via WriteFile.

Pour les classes que tu proposes, je ne les connais pas, mais tu as aussi l'excellente classe de Farscape qui fonctionne tr�s bien (sauf sur Embedded Visual C++). Bonne trames

[homeostasie]

Je vous remercie pour ces conseils, je vais me plonger dedans...Je sens que je vais m'amuser hum hum
Je ne mets pas tout de suite le post it r�solu, on ne sait jamais ;o)

Bonne journ�e

Nicolas

[homeostasie]

Voila je viens de lire en grande partie le code utilis� dans la classe de Farscape et j'ai quelques petites questions :

1) Pour la fonction SetTimeouts qui permet de r�gler le temps ou la ligne est utilis� en �mission et en r�ception, � quelle dur�e corresponds dwRxTimeout=5000? apparemment 5s? sur quoi est bas� ce calcul?

2) Pour la fonction : int ReadBuffer(char *buffer,unsigned int ucount), � quoi corresponds la variable ucount?

3) Dans la fonction ReadBuffer(), que signifie les variables counttoread et countread?

4) Dans la fonction WriteBuffer(), que repr�sente comstat.cbOutQue dans la ligne amounttowrite = m_nOutputBufferSize - comstat.cbOutQue;

5) J'utilise visual c++ 6.0, la classe devrait fonctionner?

Merci d'avance si vous pouvez me r�pondre.

Nicolas

[farscape]

Voila je viens de lire en grande partie le code utilis� dans la classe de Farscape et j'ai quelques petites questions :

1) Pour la fonction SetTimeouts qui permet de r�gler le temps ou la ligne est utilis� en �mission et en r�ception, � quelle dur�e corresponds dwRxTimeout=5000? apparemment 5s? sur quoi est bas� ce calcul?

2) Pour la fonction : int ReadBuffer(char *buffer,unsigned int ucount), � quoi corresponds la variable ucount?

3) Dans la fonction ReadBuffer(), que signifie les variables counttoread et countread?

4) Dans la fonction WriteBuffer(), que repr�sente comstat.cbOutQue dans la ligne amounttowrite = m_nOutputBufferSize - comstat.cbOutQue;

5) J'utilise visual c++ 6.0, la classe devrait fonctionner?

Merci d'avance si vous pouvez me r�pondre.

Nicolas

1)le temps est exprim� en ms ,aucun calcul c'est arbitraire ,
tu n'est pas oblig� d'appeler cette fonction par defaut le timeout est regl� sur 1s. ,

// r�glage du timeout sur la reception et l'�mission
// Note par d�faut le reglage de la voie est a 1s.
bool SetTimeouts(DWORD dwRxTimeout=5000,DWORD dwTxTimeout=5000);

et puis c'est des valeurs par defaut de la fonction tu es libre de choisir ta valeur.

2)

// lecture d�une cha�ne de caract�res d�une taille donn�e.
// GetCountRead() contiendra la taille reellement lue .
int ReadBuffer(char *buffer,unsigned int ucount);

ucount= taille a lire .

3)counttoread== octets a lire ,countread== octets lus.

4)comstat.cbOutQue ==

cbOutQue
Number of bytes of user data remaining to be transmitted for all write operations. This value will be zero for a nonoverlapped write.

le nombre d'octets restant a transmettre.

5) oui , le projet de test qui est joint est en VC6.0

[homeostasie]

Bonjour,

J'ai commen�� � bien m'interesser la la fonction int ReadBuffer(char *buffer,unsigned int ucount) de la classe CCom de Farscape et j'aurais voulu avoir des petits renseignements la concernant.
La variable ucount avertit le nombre de caract�re que l'on d�sire lire.
Si on ne connait pas � l'avance le nombre de caract�res que l'on doit recevoir, la technique serait d'associer une grande valeur � ucount et de compter combien on a re�u de caract�re avec la fonction : int GetCountRead(){return m_count;}?

De plus je me demandais, fixe t'on le le temps de lecture grace au timeout? Une fois le timeout de r�c�ption termin�, il n'est plus possible de lire les donn�es sur la ligne? OU la fonction de lecture tente de lire le nombre exact de caract�re fix� par ucount?

Merci d'avance pour vos r�ponse

Bonne journ�e

Nicolas[/code]

[homeostasie]

En attendant d'�ventuelles r�ponses sur les questions pr�c�dentes ;o), j'ai tent� de recevoir des donn�es que j'ai �mise par le port s�rie.

Voici comment je m'y suis pris :
Sur le com 1, j'ai branch� le rs232 et de l'autre cot� du cable j'ai reli� les broches Rx et Tx pour r�cup�rer mes propres donn�es.
Mais voila, je n'arrive pas � les recevoir, plutot embetant.

Mon code pour effectuer des essais :

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
	// Initialisation du port
	m_Com.PortOpen(1,9600,'N',8,1); //N°port:Com1, Baudrate, Parité, Nb bits, Bit stop:oui 
	//Trame à envoyer
	strTrameEmise = "nicolasfzfghjghhhtrehfdjhrgsfjkgfjqsdsbfzqegrziueunbcvbehfirurezhchrhr";
	//Envoie de la requête
	if (!m_Com.WriteBuffer(strTrameEmise+"\0",0)) //longueur de chaine facultative si se termine par ‘\0
		MessageBox("Erreur de transmission","Etat Trame",MB_OK);
 
	//Fonction de récupération de la trame de réponse à la requête
	char *szTrameRecue;
    	szTrameRecue = new char [20];
	szTrameRecue = NULL;
	m_Com.ReadBuffer(szTrameRecue,20);
 
	int NbCaractLu;
	NbCaractLu = m_Com.GetCountRead();
 
	//la valeur 20 est aléatoire -> nécessite de faire un calcul sur le nb de mots à lire
	//spécifié dans la trame de question
 
	m_strTrameRecue = m_strTrameRecue + "\r\nTrame de réponse :"+ szTrameRecue;
	GetDlgItem(IDC_EDIT_TrameRecue)->SetWindowText(m_strTrameRecue);

Je me dis que peut �tre les donn�es sont arriv�es trop t�t ou trop tard par rapport � l'appel de la fonction ReadBuffer(szTrameRecue,20).
Comment rem�dier � cela?
Je me dis qu'il faudrait qu'un buffer r�cup�re constamment ce qu'il y a sur le port s�rie tant que et d�s que le ma�tre ne pose plus de questions.
Si vous avez une solution...

Merci

Nicolas

[Caine]

La variable ucount avertit le nombre de caract�re que l'on d�sire lire.
Si on ne connait pas � l'avance le nombre de caract�res que l'on doit recevoir, la technique serait d'associer une grande valeur � ucount

Tout d�pend, car si la lecture est bloquante, tu ne sortiras pas de la fonction de lecture avant d'avoir lu ucount octets. Je ne me souviens plus si cette classe est synchrone ou asynchrone, ni si elle supporte les deux modes en param�rtage.

Ta solution ne marche que sur une com asynchrone... et encore, la gestion du beffer et l'attribution des trames va �tre cotton !

Dans le protocole Modbus la longueur des trames est connue pourtant.

[Aymerik]

Pour la r�ception, je te conseille vivement de mettre en place un thread comme indiqu� dans l'exemple de la FAQ. Personnellement, c'est ce que j'ai fait et cela fonctionne tr�s bien. J'avais essay� en sans, mais c'est ing�rable ; et pour peu qu'une trame n'arrive pas enti�re, ton appli est bloqu�e.
Par rapport � la r�ception de trames de longueur non sp�cifi�e auparavant, j'ai mis en place quelque chose de similaire : la longueur de la trame � lire est la valeur du premier octet re�u +1. Je ne connais pas le protocole Modbus, mais tu peux t'inspirer de ce que j'ai fait.
De plus, les trames que je re�oit sont �mises de fa�on asynchrone et n'arrivent pas forc�ment 'enti�res'.

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
LONG Controler::OnReceiveCom(WPARAM ch, LPARAM port)
{
	CCom *pCom=(CCom*)ch;
	static char sizeOfFrame = 0;
	unsigned char tmpTab[20];
	char *p_tmpTab = (char*)tmpTab; // ReadBuffer method need 'char' type, others methods 'unsigned char' type
	int bufferContent = pCom->SizeUsedInRXBuf(); // how many bytes in buffer ?
 
	while(bufferContent!=0) {
		if(sizeOfFrame==0) 
			pCom->ReadBuffer((char*)(&sizeOfFrame),1); // lenght of the next frame to load
		tmpTab[0] = sizeOfFrame; // length in the tab (needed for the frame decode process)
		if(bufferContent >= sizeOfFrame) {
			pCom->ReadBuffer(p_tmpTab+1, sizeOfFrame); // reading the end of the frame
 
			// TRAITEMENT DE TA TRAME A FAIRE ICI : tmpTab contient une trame 'entière'
 
			sizeOfFrame = 0;
			bufferContent=pCom->SizeUsedInRXBuf(); // how many bytes left in buffer ?
			}
		else break;
		}
	return 0L;
}

En esp�rant que �a t'aide.

[homeostasie]

Bien bien merci deja pour toutes ces informations.

Pour ce qui est du bout de code que tu m'as fourni pour la r�ception, je l'ai lu et essay� mais j'ai plutot conserv� le mien qui semble fonctionner maintenant, quoique j'ai un pb � r�gler.

A propos du protocole JBUS en mode RTU, je dois envoyer ma trame octet par octet? C'est � dire 01 pour le num de l'esclave puis 03 pour le code fonction etc... OU constitut� ma trame compl�te de cette forme : 01/03/00/00/00/32/C4/1F est envoyer directement cela sur la ligne.

Je demande cela car dans une doc technique l'exemple de trame donn�e est de la forme 01/03/00/00/00/32/C4/1F avec des '/', ainsi que la r�ponse.

Dans le cas ou il faut envoyer octet par octet, si le num�ro d'esclave est 10, dois je envoyer 0 puis A pour faire 0A ou 0A d'un coup ou tout simplement A?
De plus pour envoyer une trame, il serait donc n�cessaire de faire une boucle avec la fonction WriteBuffer � l'int�rieur pour envoyer octet par octet alors et non une trame toute faite d'un coup??

MErci si vous pouvez me r�pondre, car d'ici peu va falloir que je les envoie mes trames ;o)

Bonne soir�e

Nicolas

[Caine]

Bonjour,
A part ton cahier des charges peut-�tre, ou des contraintes sur ton projet, rien ne t'oblige � envoyer les trames octet par octet.

La bonne m�thode consiste � mettre l'int�gralit� de la trame dans un buffer priv�, que tu envoies sur la rs232 d'un bloc.

La m�thode WriteFile peut �tre bloquante dans ce cas, mais c'est alors au driver bas niveau d'assurer l'envoi correct de la trame.

Bien sur, il te faut impl�menter des timeout ... et pr�voir le cas o� toute la trame ne pourrait pas partir, car dans une com bloquante, ce cas signifie que le thread de traitement sera en "deadlock".

[farscape]

Bonjour,
A part ton cahier des charges peut-�tre, ou des contraintes sur ton projet, rien ne t'oblige � envoyer les trames octet par octet.

La bonne m�thode consiste � mettre l'int�gralit� de la trame dans un buffer priv�, que tu envoies sur la rs232 d'un bloc.

La m�thode WriteFile peut �tre bloquante dans ce cas, mais c'est alors au driver bas niveau d'assurer l'envoi correct de la trame.

Bien sur, il te faut impl�menter des timeout ... et pr�voir le cas o� toute la trame ne pourrait pas partir, car dans une com bloquante, ce cas signifie que le thread de traitement sera en "deadlock".

la classe de la faq est asynchrone ,de toute fa�on comme je l'ai d�j� dis pas de com synchrone sous windows. (voir faq).
les donn�es peuvent ecrites d'un seul bloc il n'y aura pas de blocage.

[Caine]

Effectivement, mais il peut aussi vouloir en faire une extension synchrone.

Je ne me souvenais plus pour la classe.

Au fait, bravo et merci d'avoir mis cette classe � disposition.

[homeostasie]

Bonjour,

Bien en fait je ne cherche pas � faire une extension synchrone, on va rester en asynchrone sourire.

En fait, j'envoie sur la ligne une suite d'octets correspondant � une requete JBUS ma�tre gr�ce � un buffer szTrameEmise de type char*.
Voici ce qu'il contient :

00422DC0 01 03 00 00 00 20 44 ..... D
00422DC7 12

En r�ception un probl�me semble se poser car le buffer szTrameRecue recoit seulement les 2 premiers octets 01 03.
Apparemment des que le buffer de r�ception voit un z�ro, il ne prends plus en compte les valeurs suivantes?
Il y a t'il un moyen de rem�dier � cela? surement! En attendant vos suggestions, je vais m'y pencher.

Merci encore et encore

Nicolas

[homeostasie]

Bien bien, je suis toujours confront� au m�me soucis, comment emettre la valeur binaire 0 � travers le buffer de type char*. En effet, si je pense avoir bien cern�, le caract�re 0 signifie la fin de chaine et ceci cause un probl�me pour l'emission de ma trame.

La trame a par exemple cette configuration :
1(n�esclave) 3(type d'op�ration) FF00(adresse de d�part) 0016(nb mots � lire) + CRC16(2octets)

des que je mets la valeur 0 dans le buffer de l'addresse FF00, alors la valeur 0016 (2octets) et le crc ne sont pas �mis alors que que j'ai enregistr� ces valeurs dans le buffer.

Si vous avez une id�e pour outrepasser le pb, elle sera la bienvenue!
Peut �tre dois je faire plutot un tableau d'entier � transmettre?!

Merci

Nicolas

[homeostasie]

voila je crois qu'avec la classe CCom de Farscape, il n'est pas possible d'�mettre la valeur 0 par le port s�rie et de la r�cup�rer.

Voici un bout de code ou j'�met la valeur 0 et pourtant en r�ception je n'ai rien, alors que pour tout autre valeur except� 0, cela fonctionne.

Code :

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

1
2
3
4
5
6
char* a = new char[1];
	*(a) = 0x0;
	if (!m_Com.WriteBuffer(a,0))
		MessageBox("Erreur de transmission","Etat Port Série",MB_OK | MB_ICONWARNING);
	else MessageBox("Trame émise","Etat Port Série",MB_OK);
	delete [] a;

Bien qu'en pensez vous? est ce normal? Comment pourrais je faire si je veux envoyer 2 octets avec le poids forts � 00 puis le poids faible 45 sachant que des que la fonction d'ecriture voit 0 dans le buffer alors il n'ecrit pas les autres valeurs qui se trouvent apres dans le buffer?

Delicat d�licat, je m'y prends p-e mal...

Bonne soir�e

Nicolas

[homeostasie]

voila je crois qu'avec la classe CCom de Farscape, il n'est pas possible d'�mettre la valeur 0 par le port s�rie et de la r�cup�rer.

Voici un bout de code ou j'�met la valeur 0 et pourtant en r�ception je n'ai rien, alors que pour tout autre valeur except� 0, cela fonctionne.

Code :

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

1
2
3
4
5
6
char* a = new char[1];
	*(a) = 0x0;
	if (!m_Com.WriteBuffer(a,0))
		MessageBox("Erreur de transmission","Etat Port Série",MB_OK | MB_ICONWARNING);
	else MessageBox("Trame émise","Etat Port Série",MB_OK);
	delete [] a;

Bien qu'en pensez vous? est ce normal? Comment pourrais je faire si je veux envoyer 2 octets avec le poids forts � 00 puis le poids faible 45 sachant que des que la fonction d'ecriture voit 0 dans le buffer alors il n'ecrit pas les autres valeurs qui se trouvent apres dans le buffer?

Delicat d�licat, je m'y prends p-e mal...

Bonne soir�e

Nicolas

[farscape]

salut,
c'est sur que si tu mets zero dans la longueur du buffer a emettre �a va pas le faire lol.
pour envoyer un octet :if (!m_Com.WriteBuffer(a,1)) pas z�ro

[homeostasie]

oui, ca fonctionne, en fait dans mon cas pour l'envoie d'une trame qui peut contenir la valeur 0, il �tait n�cessaire de sp�cifier le nombre d'octets dans la trame. Me suis fig� au niveau de la lecture alors que ca venait de la fonction d'�criture...;o)

Merci en tout cas

Bonne journ�e