Discussion :

[202UH]

Si tu as <conio.h>, getch(), kbhit(), aucun problème. J'attends ta confirmation.

Je les ai. Pour le Thread, oublie (j'ai buggé).

Et tu l'as essayé ça, avec <dos.h>, inportb() etc ? Ca compile ? Ca fonctionne ?

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

[Emmanuel Delahaye]

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).

Ca, ça me va.

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

Moui...

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 ?

[202UH]

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.
Pour Alt-F4 il faudra plus que m'aider car là c'est de l'unconnu pour moi à 100%.

[Emmanuel Delahaye]

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.

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 il faudra plus que m'aider car là c'est de l'unconnu pour moi à 100%.

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".

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

#include <windows>

/* dans la boucle d'attente de receptioni */
Sleep(1);

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...

Rappelle moi pourquoi c'est pas une appiclication Win32 ?

[202UH]

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.

La valeur sera toujours composée de quatre chiffres. Elle sera toujours comprise entre 1500 et 3000.
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

[Emmanuel Delahaye]

La valeur sera toujours composée de quatre chiffres. Elle sera toujours comprise entre 1500 et 3000.

Mamma mia ! OK, on a le format des données. Le format du fichier, il est comment ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
1500
1500
1500
1500

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1500;1500;1500;1500;1500;1500;1500;

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1500150015001500150015001500

ou que sais-je encore...

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 ?

[202UH]

Il va me rendre dingue... Tiens, j'en remets une petite couche...

Mais non.
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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1665

puis

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

2347

puis

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1759

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.....)

[Emmanuel Delahaye]

A chaque fois qu'on va enregistrer une valeur dans le fichier, on effacer l'ancienne.

OK. Donc mode "w" et non "a".

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1665

OK. Pas de \n en fin de ligne ?

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 :

1. spécification (quoi ?)
2. conception (comment ?)
3. réalisation (codage et test)
4. intégration (faire fonctionner le bouzin en situation réelle)
5. 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.

[202UH]

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 ?

La valeur sera toujours dans les limites, sinon le boîtier n'émet pas de résultat.
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).

Et si on ne reçoit plus rien ? Quelle est la période d'émission du capteur déjà ?

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.

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.)

Pour répondre à tes questions, voilà le cahier des charges que j'ai reçu de mon tuteur de stage.

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.

[Emmanuel Delahaye]

La valeur sera toujours dans les limites, sinon le boîtier n'émet pas de résultat.

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)

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.

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).

"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'.

Le principe retenu jusqu'à présent est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
i := 0
LOOP
  c := lire_caractere_recu()
  IF c = EOL
   trame[i] = 0
   i = 0
   traiter(trame)
  ELSE
   trame[i] = c
   i := i + 1 
  ENDIF
LOOP END

On voit bien que c'est la réception de EOL qui déclenche le traitement.

Chronogramme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
     Temps   : 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"

On voit aussi que tant que EOL n'est pas reçu, i s'incrémente.

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 :

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
 
i := 0
LOOP
  c := lire_caractere_recu()
  IF c = EOL
   trame[i] = 0
   i = 0
   traiter(trame)
  ELSE
   trame[i] = c
   i := i + 1 
 
   ; garde fou
   IF i > SIZEOF tab
    i = 0
   ENDIF
 
  ENDIF
LOOP END

Quelles sont les conséquences du garde fou sur la non réception d'un EOL ?

Chronogramme (on suppose que le garde fou (GF) se déclenche à 8)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
     Temps   : 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 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.

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.

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.

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).

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"

Pour répondre à tes questions, voilà le cahier des charges que j'ai reçu de mon tuteur de stage.

Cool, on aurait peut être pu commencer par là... Les cas d'erreurs ne sont pas évoqués... Le fichier non plus...

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...

[202UH]

Il me semble de la disparition (volontaire ou non) d'un capteur est une information capitale pour une gestion de processus industriel...

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…
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.

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).

On peut sans problème ignorer et laisser le fichier dans l’état, mais je préfèrerai afficher « 0000 ».

Alors tu en es où de la rédaction de la spécification ?

Proposition :
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 :

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
 int main ()
{
 i=0;
 while (c!='m')
      {
       c = getch();
       tableau[i]=c;
       i++;
      }
 if (c == 'm')
  {
   char resultat[6] = "";
   strncat (resultat, tableau + 11, 4);
   fopen("C:\\aauser\\data.txt", "W");
   fwrite ("%s", resultat);
   fclose ();
  }
  return (0) ;
}

[Emmanuel Delahaye]

Pour avancer dans le programme, est ce que les spécifications suivantes pour la réception des données te suffisent :

STOP ! Je rappelle le principe du couple définition/conception.

1. La définition explique le quoi
2. 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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Entree--> traitement -->sortie

A partir de là, le plan est posé. On peut commencer à entrer dans les détails de spécification qui nous intéressent.

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.

- on réceptionne la trame et on la place les caract. dans un tableau (trame finie si EOL)

Bel exemple de conception. !

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...

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 ?

<A l'étude ...>

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
 
Project   : Forums
Compiler  : GNU GCC Compiler (called directly)
Directory : C:\dev\forums2\
--------------------------------------------------------------------------------
Switching to target: default
Compiling: main.c
main.c:2: warning: function declaration isn't a prototype
main.c: In function `main':
main.c:3: error: `i' undeclared (first use in this function)
main.c:3: error: (Each undeclared identifier is reported only once
main.c:3: error: for each function it appears in.)
main.c:4: error: `c' undeclared (first use in this function)
main.c:6: warning: implicit declaration of function `getch'
main.c:7: error: `tableau' undeclared (first use in this function)
main.c:13: warning: implicit declaration of function `strncat'
main.c:14: warning: implicit declaration of function `fopen'
main.c:15: warning: implicit declaration of function `fwrite'
main.c:15: warning: passing arg 2 of `fwrite' makes integer from pointer without a cast
main.c:15: error: too few arguments to function `fwrite'
main.c:16: warning: implicit declaration of function `fclose'
main.c:19:2: warning: no newline at end of file
Process terminated with status 1 (0 minutes, 2 seconds)
6 errors, 8 warnings

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é?

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

[202UH]

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.

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
int main ()
{
 i=0;
 while (c!='m')
      {
       c = getch();
       tableau[i]=c;
       i++;
      }
 if (c == 'm')
  {
   FILE *fichier;
   char resultat[6] = "";
   strncat (resultat, tableau + 11, 4);
   fichier = fopen("C:\\aauser\\data.txt", "wt");
   if (fichier == NULL)
    {
      printf(" impossible d'‚crire");
    }
    else
      {
	fprintf (fichier, "%s", resultat);
	fclose (fichier);
      }
   }
  return (0);
}

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...

[Emmanuel Delahaye]

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.

OK

Puis j'ai précisé dans fopen que je voulais ouvrir un format txt avec "wt"

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 ?

puis je fais un fprintf pour écrire dans le fichier txt.

OK

Seul bugg, après l'ecriture dans le fichier, le programme se ferme aulieu de tourner en boucle. AÏE...

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...

[gl]

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.

Pour ouvrir un fichier texte en mode ecriture, 'est "w" pas "W" ni "wt".
"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.

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
int main ()
{
 i=0;
 while (c!='m')
      {
       c = getch();
       tableau[i]=c;
       i++;
      }
 if (c == 'm')
  {
   FILE *fichier;
   char resultat[6] = "";
   strncat (resultat, tableau + 11, 4);
   fichier = fopen("C:\\aauser\\data.txt", "wt");
   if (fichier == NULL)
    {
      printf(" impossible d'‚crire");
    }
    else
      {
	fprintf (fichier, "%s", resultat);
	fclose (fichier);
      }
   }
  return (0);
}

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...

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.
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.

[202UH]

voilà ce que l'aide Turbo C donne pour fopen.

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.).

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...

[Médinoc]

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.

[Emmanuel Delahaye]

voilà ce que l'aide Turbo C donne pour fopen.

Que ça existe comme une extension de tel ou tel compilateur, c'est possible, mais ce n'est pas du C standard.

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 !

[202UH]

voilà la conception. Qu'en pense tu.

2. La conception décrit le comment.

2.1 Méthode choisie :

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.

[Emmanuel Delahaye]

voilà la conception. Qu'en pense tu.

Erreurs soulignées. J'ai sorti mon feutre à 3 couleurs :

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.