Discussion :

[nainfe]

Bonjour à tous,

Je m'adresseà vous aujourd'hui car j'ai besoin de l'avis d'experts pour essayer de résoudre qques problèmes dans la conception de mon programme.

En gros, si je me présente rapidement, je suis un doctorant qui travaille sur les aérosols et les changements climatiques et je pars d'ici 13 jours à 1050km du pôle Nord pour y installer mon appareil de mesure. Mais voilà, là je galère à faire le programme qui gère cet instrument.

Je vais vous détailler rapidement le fonctionnement pour que vous appréhendiez mieux les problèmes qui me sont posés.

Toutes les 5 min, on communique avec un détecteur de précipitation pour savoir si il pleut (ou neige) et si on peut ouvrir la boite pour faire la mesure.
S'il fait beau, on dit au piston qui est dans la boite : Pousse. Ce qui prend 10 secondes.
Ensuite, on lance un autre programme qui a déjà été écrit en C++ et qui fait l'acquisition des données pendant 1 min.
On dit au piston de se fermer.

Et hop la boucle est bouclée. Ca doit être automatique et fonctionner toute l'année et le programme est le seul à tourner sur un ordi (donc pas de pb de gestion des ressources)

Ca peut paraitre simple comme ça, mais ça me pose pleins de difficultés.

Pour la gestion du temps, on m'a conseillé d'utiliser le SDL et ça marche plutôt bien.
Là j'ai déjà codé un timer qui me remet au début de mon programme toutes les 5 min (avec des SDL GetTicks de temps en temps pour voir si on est environ à 5min).
J'ai réussi également à faire un SDL Delay pour attendre que le piston s'étire.

Mais là où j'ai des problèmes, c'est pour dire à l'autre application (celle qui communqiue, via une dll, avec mon appareil de mesure) de ne fonctionner qu'une minute toutes les 5 min.
Pour l'instant j'arrive à la lancer, mais je n'ai pas encore trouvé la solution pour la killer au bout d'une minute. J'ai essayé avec taskkill ou pskill, mais ça ne fonctionne pas (J'ai fait un : system("C:\\windows\\system32\\taskkill.exe monprog.exe" ) et un system("C:\\windows\\system32\\pskill.exe <monprog.exe>" ))

Donc si vous pourriez m'aider làdessus ou m'aider à optimiser mon programme, ça serait vraiment très sympathique.

Merci d'avance

nainfe

[zais_ethael]

Wash, tu y crois vraiment à ton idée? C'est que, une applic ça ne se ferme jamais comme ça voyons
Le second programme a très certainement pour but d'acquérir les données puis de les sauver dans un fichier ou de les envoyer sur un réseau à destination d'une bdd. Ce serait l'idée pourrie de l'année de tuer le process à la brutale.
Désolé mais il va falloir que tu trouves une autre solution de pilotage de la seconde applic. Soit tu lui ordonnes de ne faire que des micro opérations (des opérations très courtes qui ne durent que quelques secondes, peut-être quelques minutes dans ton cas - mais si la machine le réclame pour faire un relevé correct tu n'as pas de raison de la bloquer en plein milieu de son boulot), soit il existe une façon de demander à l'applic de se fermer correctement (via la console, via une durée limite que tu lui passes en la lançant,...).
Si rien de tout cela n'est possible, alors cette applic a été faite par un stagiaire débile et elle ne te sert à rien , ce qui sera à mon avis fort probable (ça n'a jamais été du luxe les progs configurables en ligne de commande).

[nainfe]

C'est vrai qu'en y repensant, ce n'était peut être pas l'idée la plus fine que j'ai eu de la semaine ;-).

Mais justement, c'est que le travail a été trop bien fait, mais par un autre que je suis perdu. Dans le code pour gérer l'acquisition des données, il contrôle toujours si tout marche bien, si les données ont été transférées etc... Le problème vient du fait qu'il a été écrit pour fonctionner en continu, donc il n'a rien mis pour gérer la durée de la mesure.
L'autre problème auquel je suis confronté, c'est qu'il a codé ça en C++ en utilisant la librairie wxWidgets et je dois avouer que j'ai du mal à me retrouver dans son code (moi je suis surtout habitué à bosser en C). Et donc je ne sais pas vraiment où chercher ce que je dois modifier.

Je sais que l'idéal, ça serait de rajouter mon code dans le sien, mais je suis à l'arrache donc je n'utilise que le .exe qu'il a généré (pratique, mais je n'ai aucun contrôle sur l'application (à part pouvoir la killer))

En tout cas, si vous avez des idées simples et judicieuses, je suis preneur

Merci d'avance

nainfe

[zais_ethael]

Alors la, si l'applic a été conçue pour être controlée de manière graphique, c'est encore pire, il n'y a aucune raison pour que ça soit commandable depuis la ligne de commande.
Arrète tes bricolages, ça ne fonctionnera jamais ou pètera après 15 minutes en prod. Si tu n'es pas capable de modifier son code c'est que tu n'es pas qualifié -> mieux vaut le dire à ton chef plutot que de rendre un programme complètement bancal. C'est dans ton interet que je dis ça.

[nainfe]

C'est vrai que ça se défend. Mais bon, l'idée c'est d'avoir un programme qui fonctionne temporairement, avant qu'on nous livre un autre instrument.
Et le truc, c'est que pour l'instant, je n'ai pas trop le temps pour approfondir mes connaissances en C++, et donc je cherche surtout les solutions les plus simples pour que ça fonctionne.

Et là je pense que grâce à vos conseils, je réfléchis et je m'approche d'une solution viable : laisser tourner l'acquisition de l'appareil en continu et ne retenir qu'une minute parmi les 5 minutes de données. Je sais que c'est fortement critiquable, mais tant que ça marche, je pourrais m'en contenter.

Et dès mon retour du Pôle Nord, je me repencherai sur la programmation avec l'épineux problème de la communication, via une dll, avec mon instrument.

En tout cas encore merci, et je suis toujours preneur si vous avez d'autres idées constructives.

[Alp]

Mesurer en continu, donc faire tourner l'appli de mesure en continu, et faire une moyenne pour chaque grandeur toutes les 5 minutes et la stocker je ne sais où ?

[befalimpertinent]

Et hop la boucle est bouclée. Ca doit être automatique et fonctionner toute l'année et le programme est le seul à tourner sur un ordi (donc pas de pb de gestion des ressources)

Je voudrais pas être pessimiste mais un prog fait à l'arrache qui doit tourner en continue toute l'année j'y crois moyen. Il faudrait si tu as le temps pouvoir tester sa résistance sur une longue durée où mieux avec des outils de profiling ou de détection de fuite mémoire (Purify,...).

Sinon sous quel OS tourne l'appli ?

[zais_ethael]

Je voudrais pas être pessimiste mais un prog fait à l'arrache qui doit tourner en continue toute l'année j'y crois moyen.

Ben voila, c'est mon avis aussi.
D'autant plus que vous n'allez probablement pas envoyer un gars sur place toutes les semaines pour réparer la machine.
Crois moi, faire remarquer à son chef l'utopie de ses raisonnements quand il veut te faire bricoler un truc pro pour deux sous cinquante ça n'est jamais une mauvaise idée. Dis lui que oui, ça coutera plus cher sur le moment mais on économisera une fortune sur les futures réparations. Au pire, si c'est un imbécile fini, il te dira de le faire quand même. Mais au moins le jour où on se rendra compte que ça ne fonctionne pas, tu pourras dire "je vous avais prévenu".
Dans un cas comme celui ci, si vous n'avez aucun bon programmeur C++ dans le service (et c'est pas simple à trouver, les formations actuelles sont pourries et il faut quelques années pour être au point), il faudrait effectivement sous traiter. Par contre, ce que toi tu pourrais faire c'est tester le programme après (mises en condition, simulation de cas critiques, fuites mémoire,...).