Je vais essayer la manipe.
Version imprimable
Je vais essayer la manipe.
Je n'arrive pas à résoudre le problème de la récupération de la chaine pour la découper et récupérer la partie qui m'interresse. J'ai placé ma trame dans la variable c
int c;
c = inportb(THR_RBR);
à partir de là je bloque. Je ne peut pas utiliser strcpy car je ne peux pas copier du int dans du char. Peut tu m'aider?
Ce que tu as mis dans c, c'est pas une trame, c'est un caractère.Citation:
Envoyé par 202UH
Il faut définir au préalable un tableau de char de taille suffisante pour stocker la trame avec un 0 final et un indice à 0.
A chaque caractère reçu, tu places ce caractère dans le tableau à l'aide de l'indice et tu augmentes l'indice de 1 (si on atteint les limites, c'est qu'il y a un bug : EOL jamais reçu. Purger, c'est à dire remettre i a 0).
Quand tu reçois EOL, tu mets un 0 à la place, tu appelles la fonction de traitement de la chaine et tu remets l'indice à 0.
Fait de ton mieux et ecrit l'algorithme puis le code et poste le tout en cas de problèmes.
Il faut absolument m'aider. Je dois finir ce prog pour cette semaine et on va être vendredi. Si quelqu'un peut me donner la solution, se serai sympa. Il est 22 h est je vais arrêter pour aujourd'hui. Voilà ou j'en suis, alors ne croyer pas que j'attends les réponse toutes finis en me tournant les pouces. Mais je suis réellement bloqué. Merci d'avance...
Code:
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
Tu pourrais au moins poster du code complet... ou alors si c'est du pseudo-code, précise le... Ca ne dispense pas des balises code... http://www.developpez.net/forums/images/editor/code.gifCitation:
Envoyé par 202UH
Je reprends l'algorithme textuel, et je m'en sers pour écrire le pseudo code :
Il a fallut légèrement modifier l'ordre de l'algorithme textuel pour arriver à construire un algorithme formel cohérent.Code:
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
Voilà. Le travail de reflexion (conception) est terminé. Reste plus que le codage...
Je vais faire de mon mieux et essayer de trouver les bon codes. Merci...
Voilà le codage que j'ai fais. Il y a encore un problème. Pourrais-tu m'indiquer ce que je dois corriger?
Code:
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
J'ai modifier mon source en rajoutant une boucle while comme ci-dessous. Mais rien ne s'affiche à l'écran. J'ai repris le (!fin) que tu avais mis dans tes premier code. Est ce que fin signifie fin de la chaine de caractères? Faut-il le remplacer par (!EOL)?
Code:
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
:tagcode: comme indiqué dans les règles du forum. C'est fatiguant de répéter toujours les même choses...Citation:
Envoyé par 202UH
Elle est où la boucle ? L'initialisation de l'index doit être fait en dehors da la boucle, comme indiqué dans l'algorithme.Citation:
/* Boucle de r‚ception */
/***********************/
#define ELO 10
fin = 0;
char trame_lue[41];
int c;
int i = 0;
Ceci doit être dans le else. Pourquoi tu ne suis pas l'algorithme ? Sauf erreur de ma part, l'étude est terminé. Il n'y a plus qu'à coder l'algorithme fidèlement. et à le tester. Si tu codes autre chose, on est dans l'inconnu et on ne peut rien vérifier.Citation:
if (inportb (LSR) & 0x01) c = inportb (THR_RBR);
if (c == ELO)
{
trame_lue[41] = 0;
char resultat[6] = "";
strncat (resultat, trame_lue + 11, 5);
printf("%s", resultat);
i = 0;
}
else
{
trame_lue[i] = c;
i = i+1;
}
if (i > 41) i = 0;
Citation:
}
Voilà. Aucun mystère, il suffisait de suivre le pseudo-code à la lettre Si ce code ne fonctionne pas, c'est soit qu'il est mal codé (je ne peux pas le compiler ni le tester) soit que l'algorithme est faux (tout est possible, je n'ai pas de moyens de valider), soit que le port série, la liaison ou le capteur ne fonctionnent pas.Code:
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
50
51
52
53
54
55
56
57
58
59
60
61
62
Mais je suis un peu désespéré, car je n'ai pas l'impression que mes conseils servent à quoi que ce soit... et c'est très désagréable d'avoir l'impression de parler dans le vide... Si tu voulais m'extorquer du code, tu as gagné, mais tu n'auras pas appris grand chose tant que ça ne viendra pas de toi...
J'ai dit.
Je fais de mon mieux et j'ai suivit tes derniers conseilles dans le dernier programme. Par contre je pense ne pas t'extorquer les codes comme tu dis. J'ai juste du mal a comprendre le fonctionnement pour enregister ma trame dans un table et récupérer le résultat qui m'interesse et c'est normale car quand on est débutant, on ne peut tout savoir. Si vraiment je voulais t'extorquer les codes, je ne me casserais pas la tête le soir jusqu'a 22 heures. J'attendrai que ça se passe et que quelqu'un finisse par me donner la solution toute finie. Si le dernier codage ne correspond pas à ce que tu m'as indiquer, alors explique mois ou j'ai fais l'erreur!
22h, arf... A minuit j'y étais encore, et depuis 8 heures du matin...Citation:
Envoyé par 202UH
Tu n'as tout simplement pas suivi l'algorithme tel que je l'ai écrit.Citation:
Si le dernier codage ne correspond pas à ce que tu m'as indiquer, alors explique mois ou j'ai fais l'erreur!
Si tu ne le comprends pas, pose des questions...
Je vais tout reprendre calmement et on verra. En tous cas, je ne suis pas un profiteur, sache le. Merci et à plus.
A part mettre au point le code que j'ai posté, je ne vois pas trop ce qu'il y a à reprendre. Je croyais que ça devais être fini aujourd'hui ? On m'aurait menti à l'insu de mon plein gré ?Citation:
Envoyé par 202UH
Ca ne t'a pas empêché de sortir les violons hier soir... voire de donner des ordres...Citation:
En tous cas, je ne suis pas un profiteur, sache le. Merci et à plus.
Citation:
Il faut absolument m'aider. Je dois finir ce prog pour cette semaine et on va être vendredi.
J'ai corrigé le code.Citation:
Envoyé par 202UH
Je n'ai pas sorti de violon et je n'ai pas donné d'ordre, je demande que de l'aide. Enfin, comme tu peux voir, j'ai appliqué à la lettre ton codage et je l'ai placé dans une fenêtre code;) . La compile ne m'a pas généré d' erreur. Mais lorsque je lance l'exe, il se referme de suite. Comment parer ce problème.
Code:
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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
8O Je ne me souviens pas avoir parlé de boucle for dans l'algorithme, mais de boucle tout court, c'est à dire sans condition de sortie, ce que j'ai codé :Citation:
Envoyé par 202UH
Je reviens vers 18:00Code:
2
3
4
5
6
7
8
9
Ca se trouve un peut plus haut sir la page 4 dans ton code.
Dois-je réutiliser (!fin)? Que représente se fin. Merci...Citation:
/* LOOP */
for (;;)
{
Ben oui, je l'ai même cité. Mais je n'ai pas parlé de variable ni d'expression concernant ce for. As-tu compris le rôle de la boucle (LOOP-END-LOOP codée en C for(;;){} ou while(1){}, mais c'est plus long à taper... )Citation:
Envoyé par 202UH
C'est un autre problème. La boucle inconditionnelle (for(;;){}) ne s'arrête jamais. C'est acceptable pour ton programme, car tu n'as pas précisé comment il s'arrêtait. Mais si tu veux qu'il s'arrête sur appui d'une touche genre ESC ou Alt-F4, il faut le préciser dans la spécification et on ajoutera le bout de code qui va bien...Citation:
Dois-je réutiliser (!fin)? Que représente se fin.
Pour le moment, tu laisses for(;;).
Si j'ai bien compris ce que j'ai fais, je résumerai ça de cette façon :
Comme ma trame est toujour la même, j'aurrai au maximum 41 cases dans mon tableau (0...40), y compris le end of line. Donc pour ranger mes 41 cases, une incrémentation de 40 sur un indice = 0 me font bien 41 rangements pour mes caractères. Puis je quitte la boucle avec mes 41 traitements de fait.
C'est vrai que actuellement je quitte le programme d'une façon assez sauvage qui ne me plait pas du tout (clic sur la croix de fermeture de la fenêtre, puis clic sur le message "Terminer maintenant"). Pourrais tu m'expliquer comment programmer une sortie du programme par une combinaison que moi je définirai (ex : Ctrl + P + S). Si je peux choisir mes touches à additionner à Ctrl, je serai sur de ne pas perturber le Second programme qui lui à de multiples combinaisons de touches. Le programme que j'essais de mettre au point avec ton aide tournera en fond de tâche. C'est en fait un Thread.
Si tu te rappels le début de cette discution, je te parlais d'un soft de supervision WinCC. J'ai trouvé la solution pour afficher le résultat de ma trame dans une fenêtre I/O de ce soft. Je vais finir le programme par un enregistrement du résultat dans un fichier texte et la fenêtre I/O de WinCC permet la récupération de valeurs écrites dans un fichier txt.
Je vais commencer à étudier l'enregistrement de la valeur dans un fichier txt (fopen,fwrite,fclose... d'après les premiers éléments que j'ai pu trouver).
Si tu peux me tenir au courant pour la fermeture du programme proprement, ce serais sympa. Merci beaucoup.
PS Si je t'ai parlé que le programme devait être fini aujourd'hui, je ne t'ai pas raconté de conneries. C'est un impératif que je me suis imposé car il ne me reste plus que 2 semaines de stage pour rédiger mon rapport. Le 11/12/06 je passe mes exames est je serai interrogé sur mon stage, ce que j'ai fais pendant mon stage et ce que j'ai compris. Tu comprends un peut mieux mon stress.
Le week end je ne peut pas accéder à l'entreprise pour les essais, mais j'aimmerai être Ok pour Lundi matin avec l'enregistrement dans un fichier.
On en sait rien... On sait juste qu'elle ne doit pas faire plus de 41 caractères y compris le EOL.Citation:
Envoyé par 202UH
Non. Y compris le 0 final de fin de trame. Le EOL n'est pas enregistré. Il sert à déclencher 3 opérations :Citation:
j'aurrai au maximum 41 cases dans mon tableau (0...40), y compris le end of line.
- Terminer la chaine reçue par un 0 de façon à ce qu'elle puisse être traitée par des fonctions C standards.
- Lancer le traitement de la-dite chaine
- Remettre l'indice à 0. (réinitialiser l'acquisition pour être prêt à la saisie suivante.).
Tout ceci a déjà été expliqué dans l'algorithme textuel, dans le pseudo-code et codé tel quel...
Rien ne dit que le capteur va envoyer exactement 41 caractères. Il en envoi un certain nombre, peu importe combien et quand c'est EOL, on sait que c'est fin. Mais on a une sécurité. Si au bout du 41ème, on a toujours pas reçu le EOL, les caractères reçus précédemment sont ignorés et on relance l'acquisition de la trame suivante. On a déjà expliqué tout ça...Citation:
Donc pour ranger mes 41 cases, une incrémentation de 40 sur un indice = 0 me font bien 41 rangements pour mes caractères. Puis je quitte la boucle avec mes 41 traitements de fait.
Si tu as <conio.h>, getch(), kbhit(), aucun problème. J'attends ta confirmation.Citation:
C'est vrai que actuellement je quitte le programme d'une façon assez sauvage qui ne me plait pas du tout (clic sur la croix de fermeture de la fenêtre, puis clic sur le message "Terminer maintenant"). Pourrais tu m'expliquer comment programmer une sortie du programme par une combinaison que moi je définirai (ex : Ctrl + P + S).
Aucune importance. Sous Windows, seul le programme qui a le focus est sensible au clavier. (Heureusement, tu vois le cirque ? Je fais ctrl-F4, toutes les applications se ferment. Bravo !)Citation:
Si je peux choisir mes touches à additionner à Ctrl, je serai sur de ne pas perturber le Second programme qui lui à de multiples combinaisons de touches.
Tâche de fond...Citation:
Le programme que j'essais de mettre au point avec ton aide tournera en fond de tâche.
What ? A ma connaissance, un thread tourne en Win32, pas en Win16. Je te rappelle que le code en question n'est pas du tout compatible Win32. Tu as insisté pour accéder directement à l'UART, mais je t'avais bien prévenu que ça ne fonctionnais que sous DOS (disons en mode réel vrai ou ou réel simulé par la VM 16-bit des anciens Windows avant 98SE).Citation:
C'est en fait un Thread.
Et tu l'as essayé ça, avec <dos.h>, inportb() etc ? Ca compile ? Ca fonctionne ?Citation:
Si tu te rappels le début de cette discution, je te parlais d'un soft de supervision WinCC. J'ai trouvé la solution pour afficher le résultat de ma trame dans une fenêtre I/O de ce soft.
C'est pas dur. Pour éviter les bêtises, je suggère une ouverture en mode "a" (text append) avec fopen(), puis un enregistrement (fprintf() et une fermeture immédiate (fclose()), le tout à chaque traitement de la chaine (EOL detected). C'est un peu le B.A. BA du C, que tu n'as pas l'air de conaitre...Citation:
Je vais finir le programme par un enregistrement du résultat dans un fichier texte et la fenêtre I/O de WinCC permet la récupération de valeurs écrites dans un fichier txt.
Pas fwrite(). Sans intérêt ici. Tu as fortement interêt à enregistrer en mode texte (genre une valeur par ligne codée en décimal). En fait, c'est ce que t'envoie le capteur. C'est donc même pas la peine de convertir la chaine, tu peux l'enregistrée telle quelle (après extraction).Citation:
Je vais commencer à étudier l'enregistrement de la valeur dans un fichier txt (fopen,fwrite,fclose... d'après les premiers éléments que j'ai pu trouver).
L'usage des fonctions de gestion des flux est décrit dans ton livre de C et dans les tutoriels sérieux.
Je les ai. Pour le Thread, oublie (j'ai buggé).Citation:
Si tu as <conio.h>, getch(), kbhit(), aucun problème. J'attends ta confirmation.
Te casses pas la tête pour çà. Je compilerai mon programm avec TC++ pour avoir mon EXE. Ensuite mon exe sera lancé et ne sera plus jamais fermé (sauf grosse panne de la machine). A chaque fin de teste le capteur envoie la trame sur mon COM2 et mon exe enregistrera la valeur du résultat dans un fichier txt. 10 secondes plus tard, un automate industriel enverra un signal à WinCC via le COM1 qui irra lire le fichier txt et afficher la valeur. Je pense que pour toi la manipe devrait être un peut plus claire maintenant:PCitation:
Et tu l'as essayé ça, avec <dos.h>, inportb() etc ? Ca compile ? Ca fonctionne ?
Ca, ça me va.Citation:
Envoyé par 202UH
Moui...Citation:
A chaque fin de teste le capteur envoie la trame sur mon COM2 et mon exe enregistrera la valeur du résultat dans un fichier txt. 10 secondes plus tard, un automate industriel enverra un signal à WinCC via le COM1 qui irra lire le fichier txt et afficher la valeur. Je pense que pour toi la manipe devrait être un peut plus claire maintenant
Alors pas de sortie autre que la 'X' de la fenêtre de la console. Ca suffira. On laisse tomber la sortie par une commande spéciale. (Alt-F4, suffit).
Tu fais ce que j'ai indiqué avec les fichiers et ça va marcher. L'important est que le temps pendant le quel le fichier est inaccessible (ouvert) soit minimum.
Tu as donc bien compris où il fallait mettre la séquence fopen(), fprintf(), fclose().
Au fait, le format du ficher est bien défini ?
Si tu veux parler du format txt, c'est oui il ne changera jamais. J'avais fait un essais avec un fichier que j'ai nommé Data.txt dans lequel j'avais mis la valeur 3728. Après un clic sur un bouton dans WinCC qui avait pour rôle de simuler le signale de l'automate, la valeur 3728 est apparue dans la fenêtre I/O WinCC.Citation:
Au fait, le format du ficher est bien défini ?
Pour Alt-F4 il faudra plus que m'aider car là c'est de l'unconnu pour moi à 100%.
Bien. Mais ça ne me dit pas quel est ce format. Si il y a 2 valeurs, c'est comment ? Et 10, 100, 10000 ? Il faut spécifier.Citation:
Envoyé par 202UH
Il n'y a rien à faire de plus. C'est déjà géré automatiquement par Windows (si la console est en mode fenetre). Toute fenêtre programme de Windows peut se fermer au clavier par Alt-F4 ou à la souris par un click sur [X] ou par un click droit sur la barre du haut puis click gauche sur "fermer".Citation:
Pour Alt-F4 il faudra plus que m'aider car là c'est de l'unconnu pour moi à 100%.
Il faut apprendre à utiliser son système...
Par contre, l'application que l'on a prévue avec sa boucle, va prendre 100% du CPU (sympa pour les autres...). Si c'est une application Windows, il faudra prévoir un suspension dans la boucle
Mais ca risque d'être incompatible avec le programme qui est en 16-bit... Sinon, il va falloir regler le 'time-slicing' de l'application... On est pas sortis...Citation:
#include <windows>
/* dans la boucle d'attente de receptioni */
Sleep(1);
Rappelle moi pourquoi c'est pas une appiclication Win32 ?
La valeur sera toujours composée de quatre chiffres. Elle sera toujours comprise entre 1500 et 3000.Citation:
Bien. Mais ça ne me dit pas quel est ce format. Si il y a 2 valeurs, c'est comment ? Et 10, 100, 10000 ? Il faut spécifier.
Pour Alt-F4, encore un bugg de ma part. J'ai pas trop l'habitute de travailler avec les raccourcis claviers.
Pour ce soir je vais décrocher et je tiendrai au courant ce weekend de ce que j'ai fais. Merci et à plus:zzz:
Mamma mia ! OK, on a le format des données. Le format du fichier, il est comment ?Citation:
Envoyé par 202UH
ouCode:
2
3
4
ouCode:1500;1500;1500;1500;1500;1500;1500;
ou que sais-je encore...Code:1500150015001500150015001500
spé-ci-fier. La réponse se trouve dans la doc du logiciel qui attend ces données.
Il va me rendre dingue... Tiens, j'en remets une petite couche...
Y'a pas d'horodatage ?
Mais non.Citation:
Il va me rendre dingue... Tiens, j'en remets une petite couche...
A chaque fois qu'on va enregistrer une valeur dans le fichier, on effacer l'ancienne. Notre fichier sera toujours composé de 4 chiffres et rien d'autre.
Exemple : mesure 1 : 1665; mesure 2 : 2347; mesure 3 : 1759;
le fichier DATA.TXT sera :
puisCode:1665
puisCode:2347
Ca me parraissais logique, le but étant d'afficher le résultat de la mesure qui venait d'être faite dans une fenêtre (c'est en sorte un afficheur qui nous montre en permanence la valeur en cour comme un comptour, en compteur, une montre, un thermomètre.....)Code:1759
OK. Donc mode "w" et non "a".Citation:
Envoyé par 202UH
Notre fichier sera toujours composé de 4 chiffres et rien d'autre.
Exemple : mesure 1 : 1665; mesure 2 : 2347; mesure 3 : 1759;
le fichier DATA.TXT sera :
OK. Pas de \n en fin de ligne ?Code:1665
Il faut penser aussi aux cas d'erreurs. Si par exemple, on a pas réussi à détecter le EOL ou si la valeur n'est pas dans les limites, on fait quoi ?
Pour moi, le plus simple serait de ne pas modifier le fichier, comme ça ce serait la valeur précédente qui serait lue.
Et si on ne reçoit plus rien ? Quelle est la période d'émission du capteur déjà ?
Ce genre de question doit être posé par le spécifieur à son client. Je rappelle que l'étape initiale de réalisation d'un projet est la spécification. Celle-ci doit être claire, rassemblée dans document unique signé par le client. Rien ne peu se faire sans. C'est l'étape originelle.
Pour le moment tout ce qu'on a fait, c'est un peu de 'maquettage' pour vérifier certains principes de base. Maintenant, il s'agit de réaliser véritablement le projet. Je suppose (mais je me trompe peut être) que ce qu'attendent tes examinateurs, c'est une démarche industrielle, à savoir le respect des étapes de production d'un projet qui sont, je le rappelle :
- spécification (quoi ?)
- conception (comment ?)
- réalisation (codage et test)
- intégration (faire fonctionner le bouzin en situation réelle)
- validation (vérification du strict respect de la spécification.)
Je peux t'aider à réaliser tout ça ce weekend, à savoir :
- spécification complète
- conception complète (sauf gros bug à l'intégration)
- codage et tests unitaires (ça fait le ménage)
- préparation de l'intégration
- rédaction du cahier de validation
de façon à ce que lundi, tu n'ai plus qu'à finaliser le codage, faire la mise au point en situation réelle, les tests d'intégration et la validation.
Je propose que tu commences par rédiger le document de spécifications et qu'on le mette au point ensemble.
La valeur sera toujours dans les limites, sinon le boîtier n'émet pas de résultat.Citation:
Il faut penser aussi aux cas d'erreurs. Si par exemple, on a pas réussi à détecter le EOL ou si la valeur n'est pas dans les limites, on fait quoi ?
Pour la non-détection du EOL, je pensais écrire 0000 dans le fichier.txt, mais je ne vois pas comment détecter ce EOL pour ne pas le confondre avec IF (!=EOL).
Si sur les chaînes de montage amont il y a un prob, la machine peut être au repos pendant 5min, 10min, 1h ...Notre programme devra toujours rester en attente de recevoir un trame. il ne sera jamais mis à l'arrêt.Citation:
Et si on ne reçoit plus rien ? Quelle est la période d'émission du capteur déjà ?
Pour répondre à tes questions, voilà le cahier des charges que j'ai reçu de mon tuteur de stage.Citation:
spécification (quoi ?)
conception (comment ?)
réalisation (codage et test)
intégration (faire fonctionner le bouzin en situation réelle)
validation (vérification du strict respect de la spécification.)
Citation:
Les machines "Teste Hélium" utilisées pour le teste de débit et d 'étanchéité des condenseurs
de climatisation sont équipées d'un PC de supervision, d'un automate Siemens CPU 400 et d'un
boîtier " TEST ATEQ". L'automate gère toute la partie process de la machine et est relié
au PC de supervision via le port COM1.
Le boîtier TEST ATEQ fonctionne entièrement en autonome. C'est lui qui gère le cycle de teste
d'étanchéité et de débit dans le condenseur. Lorsqu'un teste d'étanchéité et de débit est
bon, il émet le resultat sur sa sortie RS232. La durée entre deux testes dépend du temps que mettent
les opérateurs pour préparer le prochain condenseur. Elle ne passera pas en dessous d'environ 30 secondes.
Votre travail sera de réaliser une routine en "langage de programmation C" permettant de récupérer le
résultat du teste envoyé par le boîtier "TEST ATEQ" et de l'afficher dans une fenêtre entrée/sortie
de WinCC. Le boîtier sera relier au PC via le port COM2 et votre programme devra également gérer la
configaration de ce port. Sachez que le boîtier émet le résultat dans une trame du type :
<16>:(PB): 1665 l/h
Nous désirons récupérer uniquement la valeur de mesure (1665).
Sont à votre disposition, un PC portable équipé de WinCC et Turbo C++, une bible du langage C, un cable
Null modem ainsi que la documentation du construsteur du boîtier "TEST ATEQ".
Si vous avez également besoin d'Internet comme source de recherche, un pc réservé à internet est à votre
disposition dans l'autre batiment, dans le bureau de la secrétaire de direction.
Pour effectuer vos essais, vous aurrez accès à une machine que nous vous montrerons.
OK. Mais que se passe-t-il sur un des caractères n'est pas reçu ? (avec une liaison série, tout peut arriver)Citation:
Envoyé par 202UH
Et si le caractère non reçu est EOL ?
Ce sont sont des cas réels d'erreur possible que l'on peut décider d'ignorer (il suffit d'écrire dans la spécification "les cas '...' ne sont pas traités". Advienne que pourra : il ne faudrait pas que ça plante tout le bazar, d'où le 'garde-fou' que j'ai instinctivement intégré sans savoir si il servira un jour : if (i > 41) i = 0)).
Ou alors, on décide de prendre le défaut en compte et de le traiter correctement. Si le client (celui qui a commandé le programme et qui l'utilisera) ne sait pas, le fournisseur (celui qui réalise le programme), doit lui proposer une solution simple et fiable.
"Bonne question", comme on dit ! On peut essayer de décrire ce qui se passe normalement, et voir les conséquences d'un défaut sur ce fonctionnement 'normal'.Citation:
Pour la non-détection du EOL, je pensais écrire 0000 dans le fichier.txt, mais je ne vois pas comment détecter ce EOL pour ne pas le confondre avec IF (!=EOL).
Le principe retenu jusqu'à présent est :
On voit bien que c'est la réception de EOL qui déclenche le traitement.Code:
2
3
4
5
6
7
8
9
10
11
12
13
Chronogramme :
On voit aussi que tant que EOL n'est pas reçu, i s'incrémente.Code:
2
3
4
5
6
7Temps : T0 T1 T2 Reçu : "XXX1234"EOL "XXX1234"EOL "XXX1234"EOL Indice : 0123456 7 0123456 7 0123456 7 Reset(Cause) : 0(EOL) 0(EOL) 0(EOL) Stocké : "XXX1234"EOL "XXX1234"EOL "XXX1234"EOL Enregistré : "1234" "1234" "1234"
Si pour une raison ou pour une autre, on a pas reçu EOL, ca ne va pas empêcher le capteur d'envoyer ses données quelques temps plus tard.
Si on laisse le programme se dérouler tel quel, il y a un sérieux risque de débordement de tableau, puisque i n'a pas été remis à 0. D'où l'idée du 'garde fou :
Quelles sont les conséquences du garde fou sur la non réception d'un EOL ?Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Chronogramme (on suppose que le garde fou (GF) se déclenche à 8)
On constate que pour T0, aucune donnée n'a été enregistrée dans le fichier. La valeur précédente est donc toujours présente, ça ne devrait donc pas perturber l'automate qui lit le fichier.Code:
2
3
4
5
6
7Temps : T0 T1 T2 Reçu : "XXX1234" "XXX1234"EOL "XXX1234"EOL Indice : 0123456 7812345 6 0123456 7 Reset(Cause) : 0(GF) 0(EOL) 0(EOL) Stocké : "XXX1234" "XX1234"EOL "XXX1234"EOL Enregistré : "1234"? "1234"
On voit aussi qui suite à l'incident, la chaine stockée (donc à traiter) n'a pas le format habituel. Le traitement de la chaine saura-t-il résister à ça ? Faut-il imposer qu'il y résiste et donc 'solidifier' la fonction de traitement (dans la mesure du possible). Et pour l'impossible, on fait quoi ?
Tu remarques que les cas d'erreur, c'est pas facile à spécifier et pour leur traitement, c'est encore pire.
C'est pour ça qu'au début, j'ai évoqué une 'solution simple'. On pourrait imaginer de surveiller le temps mis a un message pour être reçu, etestimer que si au bout de ce temps, le EOL n'a pas été reçu, soit on le simule (on traite quand même), soit on ignore la trame reçue (i = 0)
Reste à trouver ce qui va déclencher la surveillance de la réception et la durée du timer.
C'est simple :
Le premier caractère reçu arme le timer
Quand à la durée, il suffit de calculer la durée minimale d'un message:
- Format : 9600 N 8 1
- 1 caractère = 8 data + 1 start + 1 stop soit 10 bits
- Le débit est de 9600 baud, soit ici 9600 bit/s
- Comme un caractère vaut 10 bits, le débit en caractères est de 960 car/s
- Le message comportant jusqu'à 41 caractères, sa durée maximale est donc (en ms) de 1000 * 41 / 960 = environ 41 ms.
On peut donc estimer que si au bout de 100 ms on a pas reçu de EOL, on ne le recevra jamais.
La limite inférieure du timer sera donc de 100 ms.
La valeur max est le temps entre 2 émission du capteur. Un bonne valeur garantie pifométrique serait donc d'une seconde environ. Il faut donner une fourchette, car à priori on ne connait pas la capacité de nos ressources à nous donner un temps fiable, ni sa résolution. Demande un timer de 100 ms à un système qui a une résolution de temps de 1 seconde n'a pas de sens. La valeur exacte sera donnée par l'implémentation. L'important est que le déclenchement se fasse.
Et ne pas oublier d'arrêter le timer quand on reçoit un EOL (piège classique !)
La mise en place d'un tel timer devrait résoudre le cas de la perte de EOL. Par contre, il faut quand même que la fonction de traitement de la chaine résiste à la perte de 1 ou plusieurs caractères...
Je rappelle que le but du traitement des erreurs n'est pas de garantir une mesure fiable à tout prix (une absence de résultat, c'est à dire la répétition du résultat précédent est néanmoins préférable à un résultat faux), mais que le programme ne soit pas être perturbé par les erreurs et qu'il se resynchronise tout seul.
D'autre part, je ne donne pas de solutions miracles. Je ne fais que réfléchir 'à haute voix' (c'est à dire en notant au fur et à mesure) sur ce problème.
OK. L'état de 'non réception de données' doit il être pris en compte (dans ce cas, il faudrait un deuxième timer 'capteur'), peut-on simplement l'ignorer et laisser le ficher dans l'état (dernière valeur acquise).Citation:
Si sur les chaînes de montage amont il y a un prob, la machine peut être au repos pendant 5min, 10min, 1h ...Notre programme devra toujours rester en attente de recevoir un trame. il ne sera jamais mis à l'arrêt.
Il me semble de la disparition (volontaire ou non) d'un capteur est une information capitale pour une gestion de processus industriel... Je vois mal le compteur de vitesse de ma voiture rester bloqué à 50 alors qu'il est débranché... Je préfèrerais qu'il affiche 0 ou "ALARM"
Cool, on aurait peut être pu commencer par là... Les cas d'erreurs ne sont pas évoqués... Le fichier non plus...Citation:
Pour répondre à tes questions, voilà le cahier des charges que j'ai reçu de mon tuteur de stage.
Bref, comme toujours, un cahier des charges est le germe de la spécification, et il nous incombe de le faire grandir pour en faire un document de spécification permettant disposer de touts les éléments nécessaire à la réalisation du but fixé.
Ce n'est qu'une fois que ce document est écrit et (en principe) approuvé par le client, que l'on peut commencer la phase de rédaction du document de conception.
Alors tu en es où de la rédaction de la spécification ?
On est déjà dimanche midi...
Quelque précisions sur le « CAPTEUR » : Ne considère plus le Boîtier TEST ATEQ comme un capteur, car c’est une boîte qui comporte son propre processeur, sa Ram…etc…Citation:
Il me semble de la disparition (volontaire ou non) d'un capteur est une information capitale pour une gestion de processus industriel...
Si ce boîtier tombe en panne, la machine ne fonctionne plus car ce boîtier est le maître qui donne les ordre à l’automate. On ne traite pas sa disparition.
On peut sans problème ignorer et laisser le fichier dans l’état, mais je préfèrerai afficher « 0000 ».Citation:
OK. L'état de 'non réception de données' doit il être pris en compte (dans ce cas, il faudrait un deuxième timer 'capteur'), peut-on simplement l'ignorer et laisser le ficher dans l'état (dernière valeur acquise).
Proposition :Citation:
Alors tu en es où de la rédaction de la spécification ?
Pour avancer dans le programme, est ce que les spécifications suivantes pour la réception des données te suffisent :
- on réceptionne la trame et on la place les caract. dans un tableau (trame finie si EOL)
- on décortique le tableau pour récupérer les caractères qui nous intéressent
- on enregistre les caractères dans le fichier txt en écrasant les valeurs précédentes
Ces trois questions, on en a assez discuté, je pense.
On rajoute comme traitements de sécurités :
- contrôle de la non émission du EOL ( peut on se limiter au if > 41 et dans ce cas écrire « 0000 » dans le fichier et réinitialiser le tableau).
- contrôle des caractères perdus ( on écrit « 0000 » dans le fichier et on réinitialise le tableau
J’ai fait un essai d’écriture avec fwrite en simulant EOL par ‘m’, mais la compile bloque au niveau de fwrite. Peut tu m’indiquer ce qui coince ?
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
STOP ! Je rappelle le principe du couple définition/conception.Citation:
Envoyé par 202UH
- La définition explique le quoi
- La conception décrit le comment.
Pour le moment, on part de la définition la plus simple et la plus générale qui soit à partir du cahier des charges. Je dirais :
1 Définition
Il s'agit de réaliser une application qui reçoit des données en provenance d'un capteur, les conditionne et les inscrit dans un fichier.
En une ligne, on a posé le problème selon le schéma de base de quasiment tout traitement informatique, à savoir :
A partir de là, le plan est posé. On peut commencer à entrer dans les détails de spécification qui nous intéressent.Code:Entree--> traitement -->sortie
1.1 Entrée
Le capteur est autonome. Il effectue une mesure et transmet son résultat de manière spontanée. Il se passe au moins 30 secondes entre chaque résultat.
Le résultat est une chaine de caractères de la forme "<16>:(PB): 1665 l/h" codés en ASCII terminé par une marque de fin de ligne (code 10 décimal ou LF en ASCII). La longueur maximale de la chaine, fin de ligne incluse, est de 41 caractères.
Les données sont transmises, donc reçues par une liaison série asynchrone configurée en 9600 N 8 1.
La liaison série est raccordée au port COM2 du PC.
1-2 Traitement
Une fois la chaine récupérée, il faut en extraire la valeur numérique (ici 1665 en décimal) et l'inscrire dans un fichier texte sous forme décimale (donc 1665).
1-3 Sortie
Le ficher est mis à la disposition d'un dispositif externe qui le lit et en affiche le contenu.
Bel exemple de conception. !Citation:
- on réceptionne la trame et on la place les caract. dans un tableau (trame finie si EOL)
Citation:
On rajoute comme traitements de sécurités :
- contrôle de la non émission du EOL ( peut on se limiter au if > 41 et dans ce cas écrire « 0000 » dans le fichier et réinitialiser le tableau).
- contrôle des caractères perdus ( on écrit « 0000 » dans le fichier et on réinitialise le tableau
1.4 sécurité
Les cas d'erreurs suivant sont détectés :
- absence de EOL
- format des données erronées (caractères manquants)
- valeur numérique hors norme
Dans ces cas la chaine "0000" est inscrite dans le fichier.
L'application doit tout mettre en oeuvre pour rester stable et être en mesure de recevoir les mesures suivantes.
Si ce document de définition convient, il faut ensuite en tirer le document de conception...
<A l'étude ...>Citation:
J’ai fait un essai d’écriture avec fwrite en simulant EOL par ‘m’, mais la compile bloque au niveau de fwrite. Peut tu m’indiquer ce qui coince ?
Sympa. C'est si dur que ça de poster un code qui compile ? Faut que je passe encore un quart d'heure à faire de la rétro-ingéniérie sans savoir que tu as réellement oublié?Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Pour mettre une chaine dans le fichier, c'est plutôt fprintf() avec "%s".
D'autre part, il faut absolument que tu apprennes à utiliser fopen() etc. Parce que là, tu fais n'importe quoi. Des exemples dans ton livre de C et ici :
http://emmanuel-delahaye.developpez....s.htm#fichiers
J'ai réétudié mon problème d'écriture dans un fichier et j'ai trouvé la solution. J'ai placé un pointeur FILE *fichier; pour commencer. Puis j'ai précisé dans fopen que je voulais ouvrir un format txt avec "wt" puis je fais un fprintf pour écrire dans le fichier txt.
C'est marrant, quand on fait les choses dans les règles de l'art, ça marche. Seul bugg, après l'ecriture dans le fichier, le programme se ferme aulieu de tourner en boucle. AÏE...Code:
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
OKCitation:
Envoyé par 202UH
8O Je ne sais pas qui t'a dit de faire ça, mais c'est faux. Le mode texte, c'est "w". Tu n'as donc pas lu l'article que je t'ai passé ? Je perds mon temps ou quoi ?Citation:
Puis j'ai précisé dans fopen que je voulais ouvrir un format txt avec "wt"
OKCitation:
puis je fais un fprintf pour écrire dans le fichier txt.
Evidemment, comme il ne respecte pas l'algorithme qu'on a défini précédement, et il ne boucle pas... Y'a pas de miracle...Citation:
Seul bugg, après l'ecriture dans le fichier, le programme se ferme aulieu de tourner en boucle. AÏE...
Pour ouvrir un fichier texte en mode ecriture, 'est "w" pas "W" ni "wt".Citation:
Envoyé par 202UH
"wt" est une extension de certains compliateurs (Borland entre autres), cette extension n'est pas portable et, sauf utilisation d'autres fonctionnalites specifiques (ce qui n'est pas le cas ici), pas utile.
C'est normal, dans ton code, tu ecris dans ton fichier, puis tu arrives a la fin de la fonction main(), donc tu quitte le programme.Citation:
Envoyé par 202UH
Il faut placer to code dans une boucle infinie, par exemple for(;;) (Emmanuel n'en avait-il pas deja parler dans un message precedent ? Il me semble bien).
Sinon quelques remarques sur ton code :
* les lignes affiches par printf (echec d'ouverture) ne sont pas completes, il faut donc, afin d'etre sur d'avoir l'affichage de l'erreur au bon moment, la terminer (rajouter \n) ou forcer l'ecriture (fflush(stdout)).
* Pourquoi utiliser des chemins de fichiers avec '\\' ? '/' suffit et ne fonctionne pas que sous windows.
* Tu n'as pas la gestions d'erreurs que tu as decrits precedement:
- pas de gestion de la taille maximale.
- pas de gestion de l'absence de fin de ligne.
- pas de gestion de chaines mal formattees. En particulier plutot que recopier les caracteres depuis un offset fixe (11 ici), une analyse de la chaine avec recherche du debut de l'information utile serait plus sure.
voilà ce que l'aide Turbo C donne pour fopen.
Je suis peut être mauvais en C étant donné que je suis débutant, mais pour l'histoire du "wt", regarde un peut ce que j'ai marqué en rouge dans L'AIDE DE TC et deplus, au début de ma formation, on avait fait un peut de C et ce sont les profs qui nous avait déjà parlé de "wt". Marrant non...Citation:
La chaŒne de mode qui sert dans les appels … fopen, freopen et _fsopen (ou
celle de type pour les appels … fdopen) prend l'une des valeurs ci-dessous:
ChaŒne³ Description
ÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
r ³ Ouverture en Lecture Seule
w ³ Cr‚ation pour ‚criture.
³ Si un tel fichier pr‚existe, le contenu est perdu.
a ³ Ajout; ouvert en ‚criture en fin de fichier ou cr‚ation pour
³ ‚criture si inexistant.
r+ ³ Ouverture de fichier pr‚existant pour mise … jour (lecture/‚criture)
w+ ³ Cr‚ation pour mise … jour (lecture/‚criture)
³ Si un tel fichier pr‚existe, le contenu est perdu.
a+ ³ Ouverture pour ajout; ouverture pour mise … jour en fin
³ de fichier ou cr‚ation si inexistant.
þ Pour indiquer qu'un fichier doit ˆtre ouvert ou cr‚‚ en mode texte,
ajoutez t … la chaŒne (rt, wt, etc.).
þ Pour le mode binaire, ajoutez b (wb, a+b, etc.).
TurboC est vieux.
"t" sert généralement à certains vieux compilateurs (dont ceux de Borland et de Microsoft) qui proposaient, avec certaines options, d'ouvrir les fichiers en mode binaire par défaut, plutôt qu'en mode texte.
Ainsi, il fallait donc une option pour dire "ouvrir en mode texte" quand le programme est réglé pour ouvrir en mode binaire sans paramètre...
Ces extensions ne sont pas standard, et d'après le standarrd, un fichier est TOUJOURS ouvert en mode texte si on ne précise pas qu'on veut le mode binaire.
Que ça existe comme une extension de tel ou tel compilateur, c'est possible, mais ce n'est pas du C standard.Citation:
Envoyé par 202UH
Règle de codage impérative : "Autant que faire se peut, on cherche à écrire du code standard."
Ne perd pas de temps avec ça. Mets "w" et tout le monde sera content. Si ton prof fait une remarque, tu lui fais lire ce thread, il appréciera !
voilà la conception. Qu'en pense tu.
2.1 Méthode choisie :Citation:
2. La conception décrit le comment.
Le logiciel WinCC ne nous permet pas de réceptionner directement la trame entrant par le port de communication com2 et de l’afficher dans un champ I/O. Par contre, ce logiciel de supervision a une fonction qui permet d’afficher des valeurs écrites dans un fichier texte.
Nous allons donc créer un programme dont la tâche sera de configurer le port COM et d’assurer le traitement de la réception de la trame ainsi que son écriture dans le fichier texte.
2.2 Langage de programmation :
Le programme s’écrira en langage C à l’aide du programme Turbo C++ mis à disposition.
2.3 Algorithme de programmation :
Le programme sera écrit selon l’algorithme suivant :
- configuration du port Com
- ouverture et écoute du port Com
- si réception d’une trame, enregistrement de celle-ci dans un tableau de caractères, contrôle de la réception du EOL et du dépassement du nombre de caractère maximum écrit dans le tableau (41 avec le 0 final)
- si EOL non atteint, écriture de « 0000 » dans le fichier txt et initialisation du tableau
- si EOL atteint, écriture du zéro final
- contrôle des caractères perdus et si caractères perdus, initialisation du tableau et écriture de « 0000 » dans le fichier txt
- si aucun caractère perdu, découpage du tableau et enregistrement des cases 11, 12, 13 et 14 dans un tableau résultat
- ouverture du fichier texte et contrôle de l’ouverture du fichier
- si fichier ouvert, écriture des caractères du tableau résultat dans le fichier
- fermeture du fichier texte
L’algorithme sera écrit dans une boucle infinie.
Erreurs soulignées. J'ai sorti mon feutre à 3 couleurs :Citation:
Envoyé par 202UH
2.1 Méthode choisie :
Le logiciel WinCC ne nous permet pas de réceptionner recevoir directement la trame entrant par le port de communication com2 et de l’afficher dans un champ I/O. Par contre, ce logiciel de supervision a une fonction qui permet d’afficher des valeurs écrites dans un fichier texte.
OK
Nous allons donc créer un programme dont la tâche sera de configurer le port COM et d’assurer le traitement de la réception de la trame ainsi que son écriture dans le fichier texte.
OK
2.2 Langage de programmation :
Le programme s’écrira en langage C à l’aide du programme Turbo C++ mis à disposition.
Hors-sujet
2.3 2 Algorithme de programmation Description du comportement:
Le programme sera écrit selon Le comportement de l'application est décrit par l’algorithme suivant :
- configuration du port Com
- ouverture et écoute du port Com
- si réception d’une trame, enregistrement de celle-ci dans un tableau de caractères, contrôle de la réception du EOL et du dépassement du nombre de caractère maximum écrit dans le tableau (41 avec le 0 final)
- si EOL non atteint, écriture de « 0000 » dans le fichier txt et initialisation du tableau
- si EOL atteint, écriture du zéro final
- contrôle des caractères perdus et si caractères perdus, initialisation du tableau et écriture de « 0000 » dans le fichier txt
- si aucun caractère perdu, découpage du tableau et enregistrement des cases 11, 12, 13 et 14 dans un tableau résultat
- ouverture du fichier texte et contrôle de l’ouverture du fichier
- si fichier ouvert, écriture des caractères du tableau résultat dans le fichier
- fermeture du fichier texte
OK
L’algorithme sera écritCet algorithme s'exécute dans une boucle infinie.Préciser quand même que l'initialisation n'en fait pas partie. Un algorithme formel en pseudo-code (LDA, par exemple) est le bienvenu a la suite sous le titre "2.3 Algorithme formel"
La méthode pour détecter l'absence de EOL reste à spécifier
La méthode pour tester l'intégrité des données reste à définir.