Discussion :

[Papy_Guik]

Bonjour

J'ai une appli qui discute avec une pompe à essence via le port série j'utilise donc l'evenement datareceived pour ecouté le port en continu .

mon problème est lors de la reception de ma trame celle ci est en plusieurs morceaux .

Exemple de trame type : 00 6434 0016 18/06/08 10H49 312636 G 000037.2L 000006.4L 000000.8L 1

Malheuresement il peut arrivé que je recoivent d'autres type de trame qui n'ont rien a voir mais que je veux quand meme récupéré.

Je voulais donc savoir si il était possible de savoir si le port avait finit d'émettre afin de stocker les bouts de trames dans une variable et ainsi récupré n'importe quelle trame en entiere.

J'ai déja essayé ReadLine mais ma pompe n'envoie pas de "\n"
mais aussi ReadTo("L 1") qui ne me recupere que la trame situé au dessus en rouge.

J'utilise actuellement ReadExisting.

Si quelqu'un à une idée ça serait le bienvenu pasque la je tourne en rond

Mon code est le suivant

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
 
 
        private void serialPort1_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
        {
            receptionTrame();                           //Réception de la trame émise via le port série
 
            BeginInvoke(new InvokeDelegate(invokeLectureTxt));
        }
        private void receptionTrame()
        {
            string msg="";                                     //Message Recu
            byte[] ACK = new byte[1];                          //Tableau de byte afin d'envoyer en Hexadecimal
            ACK[0] = 0x06;                                     //Valeur de retour de trame ACK = 0x06 (ETX = 0x03)
            string hex = "";
            char[] test = new char[77];
 
            int i = 0;
 
            msg = serialPort1.ReadExisting();
 
 
          //msg = serialPort1.ReadLine();                     //Lecture de la donnée recu
 
            msg = msg.Replace("\0", "");
            trameRecu = msg;           
 
 
            BeginInvoke(new InvokeDelegate(invokeReception)); //Affiche dans la textBox la trame recu
 
           //Si la trame recu ne contient qu'un seul caractère alors on transforme le caractere ASCII en valeur Hexa
 
            if (msg.Length == 1)
            {
                char msg1 = Convert.ToChar(msg);            //Transforme le Msg(String) en Char
                int value = Convert.ToInt32(msg1);          //Transforme le Char en Int
                hex = String.Format("{0:X}", value);        //Convertit le Int dans sa valeur Hexa
 
                string hex2 = String.Format("{0:X}", "6");  //Format la chaine au format Hexa
 
                if (hex == "3")
                {
                    serialPort1.Write(ACK, 0, 1);           //Retourne 0x06 à l'emeteur de 0x03
                }
            }

et la configuration du port série est la suivante Baudrate : 300 Databits :7 Parity : Even StopBits : 1

D'avance merci .

[theMonz31]

salut

la communication avec le port série, c'est toujours un petit peu chiant au niveau de la gestion des trames...

Une solution consisterait à avoir une définition de tes trames via une longueur fixe... soit avec un protocol du genre

Code Debut Trame, Longueur Trame, Fin Trame

ou sinon avec une longueur bien précise...

Sinon, tu peux aussi définir une longueur Unique pour tes trames , genre X octets, et que ta trame de X octets soit toujours du type :

ID Trame + Data

Comme cela, dans le received de ton port série, tu te contentes de faire un read(x) octets.. et ensuite, tu gères en fonction de l'ID

Comme cela, tu pourras en fonction de la reconstruction de tes trames ayant un ID commun gérer la commande à faire

Sans plus d'info, je ne pourrais dire mieux !

The Monz, Toulouse

[Papy_Guik]

Salut TheMontz

Le problème c'est que je ne peu pas modifier mes trames elles sont envoyeé par une pompe à essence d'un client et celles-ci ne sont pas forcement fixes.

Comme tu a pu le voir dans le code avant d'envoyer la trame demande l'autorisation pour envoyer (je recoit un bit de valeur 0x03 et je lui renvoi 0x06 ) pour l'autoriser.

Deplus il peu arriver que je recoivent des trames d'en-tête qui ne correspondent pas à la trame que j'ai mise plus dans le precedent post.

il n'existe pas une methode pour savoir si le port série à finit d'envoyer afin de tester afin que je teste à chaque réception si c'est la derniere.

[theMonz31]

salut

Non, il n'y a aucun ACQUITTEMENT sur un port série...

Le port série, c'est juste un tuyau qui émet des octets et c'est tout.

Si il n'y aucun protocole défini entre l'émetteur et le recepteur, ca va pas être la joie...

La seule solution que je vois est que tu puisses "arriver" à "router" les octets dans le bon décodeur de trame

Cela dit, c'est "hallucinant" que l'émetteur n'est pas un protocole d'émission avec une "garanti" qu'il émet des trames "finies" ou au pire, des trames coupées mais avec un système de reprise de trame..

En TCP/IP, tu as ce type de mécanisme dans la couche transport qui "remet" en ordre les trames recus

The Monz, Toulouse

[Papy_Guik]

Je vais essayer de récupéré les trames au format hexadecimal et voir si il y aurai pas un caractére que je ne vois pas

mais je pense qu'il doit bien y avoir une solution puisque mon appli doit permettre de remplacer une vielle imprimante sur laquelle est brancher la pompe.

Celle-ci faisant des sauts de lignes a la fin de chacune des trames.

Serait il possible de récupéré ma trame au format hexadecimal ?

[Pol63]

(lu en diagonale)

si tu as un caractère de fin de trame, ou un moyen de l'analyser, tu stockes tout ce qui arrive dans un string et quand ton string contient le caractère de fin, tu retires ta trame de cette chaine et tu la traites
comme ca meme si y a un bout de trame en plus derrière il restera utilisable

sinon des fois il est possible de mettre une tempo à la réception d'un octet
si pendant x temps y a plus d'octets qu'arrivent ta trame est considérée comme complète
si elle est illisible, tu la jettes

dans tous les cas ça dépend du protocole de transmission établi

et ta trame, tu peux la récupérer en octet ou hexa aussi

enfin vu l'exemple ca ressemble à une chaine de longueur fixe (qui donc est à peu près simple à traiter)

[Papy_Guik]

Salut Sperot je viens de lire ton post

Ma trame mise en exemple est la trame principal a récupéré

cependant il m'arrive aussi de recevoir des trames d'en tête ou d'autre trames plus courtes mais dont la longueur varie (pas plus longue)

mon réel probléme est que je n'ait pas de caractére de fin de chaine (ou pas visible dans les trames qui m'ont été donnés).

Mais je pense franchement qu'il doit bien y en avoir sinon je ne voit pas comment l'imprimante qui éditait cela pouvait faire ses passages à la ligne

[Pol63]

parfois c'est CrLf ou même un double CrLf

[Papy_Guik]

Quest ce que tu appel CrLf ou double CrLf

[Pol63]

normalement je traine sur le forum vb donc je parle de vbcrlf, étant chez les c#iens j'ai retiré le vb

trève de plaisanterie
crlf = carriage return line feed je crois
caractère généré par la touche entrée d'un clavier
il doit bien y avoir une enum dans un coin de c# qui y correspond (comme notre VbCrLf)

c'est du coup un caracatère invisible qui est souvent utilisé comme délimiteur (le protocole http par exemple c'est 2 crlf qui indiquent la fin de trame)

[Papy_Guik]

Oki merci pour cette info
maintenant il me reste plus qu'a trouver quel est se caractere de finqui est utilisé dans ma trame malheuresement je n'ai pas la pompe à essence toujours à disposition donc c'est pas toujours simple pour se genre de test.

Je pense que je vait faire un tour demain à la boite de mes clients bien que ca ne m'enchante pas trop.