problème de récupération de trame

Coucou à tous.

Voici la situation.

je dois communiquer avec un matériel par une connexion RS232
pour gérer la communication je me suis inspiré de la classe "SerialCom" situé
http://c.developpez.com/faq/vc/?page...WithSerialPort.

Lorsque l'on en voit une trame au matériel, celui ci envois une trame pour confirmer la réception.

Mon problème est que je ne par vient pas à récupérer cette trame.
:cry:

Pourriez vous me dire ce qui ne va pas dans mon code SVP?

Citation:

---

CCom com;

unsigned char *buffer;
DWORD EvtMask =EV_BREAK ;

com.PortOpen(1,19200,'N',8,1);
com.UseRtsCts(false);
com.UseDtrDsr(false);
com.UseXonXoff(false);
com.SetCommMask(EvtMask);
com.PurgeCom();

//initialise la bar de progress
m_progress.SetRange(0,nombrefonction);
m_progress.SetPos(0);

//met tous les voyants en rouge
for(int i=0; i<nombrefonction; i++)
{
voyant[i].SetBkColor(RGB(255,0,0));
UpdateData(FALSE);

}

//pour chaque fontion
for(i=0; i<nombrefonction; i++)
{
creerTrame(&nomcommande[i]);
calculerPoidBits(trame[1]);

com.WriteBuffer(trame);

com.StartThread(com.m_pParent);
AfxMessageBox(com.GetStringError());

buffer = new unsigned char[100];
com.ReadBuffer(buffer,sizeof(buffer));
AfxMessageBox(com.GetStringError());

//si la réponse est correcte mettre le voyant en vert
if(buffer[0]==129)
{
voyant[i].SetBkColor(RGB(0,255,0));
m_progress.SetPos(i+1);
UpdateData(FALSE);
RedrawWindow();
}
com.StopThread();
}

AfxMessageBox("test terminé");
com.PortClose();

---

Essaie d'initialiser les time out (SetCommTimeouts)

salut ,
ça ne risque pas de fonctionner, tu melanges les deux modes de fonctionnement, et tu appelles plusieurs fois la creation du thread de travail...
que tu detruis plus bas.

le premier exemple d'utilisation de la faq montre un usage sequentiel qui convient par exemple a l'utilisation d'une balance :
inconvenient si la reception bloque le programme est bloqué.
la deuxieme méthode est evenementielle et utilise un thread pour la reception des données.
il faut deja savoir dans quel mode tu veux travailler.
:D

Ok merci pour les conseils
Je travail en mode asynchrone,
A l’origine je ne lancé pas de Thread.
J’avais mis un time out et j’appelais la fonction « WaitCommEvent », mais cette dernière me retourné un message d’erreur.
« fichier spécifier un trouvable »

Après avoir regarder les exemples de la faq, je suis revenu à ma programmation initiale, que j'ai expliqué précédemment.
Malheureusement.
:cry:
J'ai une lecture incorrecte accuse de la fonction "WaitCommEvent"...
Chose intéressante, c'est qu’avec le débogueur et malgré une erreur qui s'affiche, j'ai une lecture correcte de temps en temps
8O
Quelqu'un aurait une explication ou une petite idée à ma proposé SVP

tu peux montrer ton code ?

voici le demandé code:

Citation:

---

CCom com;
CString reponse;
unsigned char *buffer;
DWORD EvtMask =EV_RXCHAR;

com.PortOpen(1,19200,'N',8,1);
com.UseRtsCts(false);
com.UseDtrDsr(false);
com.UseXonXoff(false);
com.SetCommMask(EvtMask);
com.PurgeCom();
com.SetTimeouts(1000,1000);

//initialise la bar de progress
m_progress.SetRange(0,nombrefonction);
m_progress.SetPos(0);

//met tous les voyants en rouge
for(int i=0; i<nombrefonction; i++)
{
voyant[i].SetBkColor(RGB(255,0,0));
UpdateData(FALSE);

}

//pour chaque fontion
for(i=0; i<nombrefonction; i++)
{
creerTrame(&nomcommande[i]);
calculerPoidBits(trame[1]);

com.WriteBuffer(trame);

com.WaitCommEvent(EvtMask);

long nr;
buffer = new unsigned char [(nr=(com.SizeUsedInRXBuf()+1))];
memset(buffer,0,nr);

com.ReadBuffer(buffer,nr);

//si la réponse est correcte mettre le voyant en vert
if(buffer[0]==129)
{
voyant[i].SetBkColor(RGB(0,255,0));
m_progress.SetPos(i+1);
UpdateData(FALSE);

}

}

AfxMessageBox("test terminé");
com.PortClose();

---

j'espère que vous pourrez dire ou je me suis planté...

salut,
cette ligne :

Code:

---

1 2	com.WriteBuffer(trame);

---

suppose que trame se termine par un \0 , c'est le cas ?
:D

oui, j'ai mis un caractère de fin de chaine à ma trame.
pourquoi?
j'ai mon écriture sur le port fonctionne.
C'est l'attente d'évenement et la lecture qui me pose problème...

hum ça me parait correcte,
une remarque tu n'as pas de gestion de flux (même materiel) c'est normal ?
les packets recus sont gros ?
le cable est long ?
:D

Non, je n'ai pas gestion de flux spécifique.
D’un point vu perso, je trouve ça bizarre, mais l'ancienne version en basic fonctionne ainsi.
les trames réception sont du même genre que les envois
exemple "129 6 3 1 41 9"
Quant à la longueur du câble environ 1 mètre.

aprés un essai rapide ,ce qui cause probleme c'est le fait de ne selectionner aucune gestion de flux .
essaye de mettre :com.UseDtrDsr(true); ou RtsCts(true);
il faut toujours une gestion de flux, au pire le cable doit etre strappé en consequence..

:D

j'ai mis "UseRtsCts(true)"
rien à changer
même avec différent évènemnt possible(EV_CTS, EV_RXCHAR...)
en r'ajoutent "AfxMessageBox(com.GetStringError());" juste après "WaitCommEvent"
j'ai toujour le même message "chemin spécifier introuvable"

Attention la lecture d'erreur doit être réalisée si waitcomEvent renvoie false...

Code:

---

1 2 3 4 5

if(! com.WaitCommEvent(EvtMask)) { AfxMessageBox(com.GetStringError()); }

---

EV_RXCHAR suffit pour SetCommMask.
:D

ok merci.
mais le problème est toujours là.
avant de quitter mon programme, je lui demande de afficher les trame qu'ils a lu.
j'ai pus remarqué que le début des trames est correcte maintenant, mais la suite non
exemple:
pour l'envoi "129 6 3 1 41 9"
à la reception"129 6 3 1 0 204" au lieu de "129 6 3 1 41 9"
de plus il arrive que la première trame soit correcte

quand la reception fonctionne le pb n'est plus lié a la gestion de la voie série mais au reste du programme.
es tu sur de ne pas te planter dans ton diagnostic ?
un moyen simple c'est d'automatiser une séquence envoi /reception pour verifications en utilisant la macro TRACE par exemple en debug.
:D

je n'ai jamas utilise TRACE
:oops:
ça fonctionne comme un printf mais je fait comment pour le visualiser
SVP

oui ça fonctionne comme printf .exemple:

Code:

---

1 2 3

TRACE("\n emission %s",pbufferOut); TRACE("\n Reception %s",pBufferIn);

---

l'affichage apparait dans l'onglet trace debug.
:D

merci pour le TRACE
pour tester mon programme je lui envois 3 trames
129 6 3 1 41 9
129 6 3 0 233 200
129 6 3 0 41 9

normalement il devrait me revoyer les même trames mais voici ce que de TRACE m'affiche:
129 6 3 1 41 9
129 6 3 0 204 204
1 6 3 1 41 9

je vais modifier le time out pour voir si c'est de la que vient mon problème

l'idéal serait de s'assurer qu'une gestion de flux materiel classique Rts/Cts soit possible.
apres c'est une question de protocole d'envoi/reception.
tu dis j'envois :
129 6 3 1 41 9
129 6 3 0 233 200
129 6 3 0 41 9
comment le recepteur sait qu'il peut commencer à renvoyer la réponse ?
:D

pour ce qui est du time out, c'est pas gagné.
par contre avec le ci dessou la reception c'est amélioré

Citation:

---

if(! com.WaitCommEvent(EvtMask))
{
Sleep(1000);
}

---

:?
cela dit les 2 derniers bits sont une fois sur deux faux et je n'aime pas trop ce genre de méthode, c'est limite remplacer un jouint usagé par un chewing-gum...
:)

c'est pas terrible tout ça !
tu devrais reflechir a la gestion de flux ....
:D

Citation:

---

Envoyé par farscape

l'idéal serait de s'assurer qu'une gestion de flux materiel classique Rts/Cts soit possible.
apres c'est une question de protocole d'envoi/reception.

comment le recepteur sait qu'il peut commencer à renvoyer la réponse ?
:D

---

je suis d'accord sur le principe, mais le problème est que le matériel que je test à été conçu pour que seulement RX et TX soit utiliser...je vais voir ce que je peux faire pour ça...


Pour ce qui est du récepteur:
il reçoit une trame
fait la commande qui lui est demander
envoi une trame pour dire ce qu'il a fait

Il ne prévient pas ou ne demande pas à émettre.

salut,
Alors dans ce mode de fonctionnement:
tu dois envoyer une trame attendre la reponse avant d'envoyer une autre trame.
si il n'y a que Rx/Tx c'est classique d'une gestion de flux par Xon/Xoff.
mais bon vu les debits en question ça ne devrait pas causer de probleme.(du moins coté windows)
le probleme se situe plus dans la synchro entre l'emission reception.
:D

savez vous comment on utilise les tempon FIFO de Windows

idée:
lorsque des données sont envoyer sur le port COM, il devrait se mettre dans le tampon et généré une interuption.
si je détecte cette interuption je devrait pouvoir lire le contenu du tampon et récupérer le trame.

reste savoir comment utilisé le tampon et récupérer l'interuption.

au fait ça marche...
:lol:

désoler de ne pas avoir prévenu plus tot mais ça m'était sorti de l'esprit.
:roll:

pour résoudre mon problème j'ai fait ma propre class "SerialCom" afin de savoir ce que je fait...
les classes toutes faite c'est sympa, mais faut mieux sans inspirer plutot que de les réutiliser sans savoire le role de chaque methodes et attributs.

alors merci :D