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