Discussion :

[bfespi69]

Bonjour à tous,

Je dois faire communiquer un PC et un équipement sur le port série ( en protocole ModBus ).
Le PC interroge l'équipement pour connaitre les valeurs de certains de ses registres.
Ensuite le PC enregistre les valeurs dans une base de donnée sur un serveur ( mySQL ou PostgreSQL ) en local.

Jusque là, rien de compliqué, j'ai pu réaliser toutes ces actions séparées dans divers projets de tests.

Cependant, je cherche à mettre en place cette communication en permanence.
C'est à dire que le PC et l'équipement ne serait jamais mis hors tension ( ou le moins possible ) et que la communication entre les 2 serait à intervalle réguliers 24h/24 7j/7 sur le port série.

C'est là que beaucoup de questions se posent pour moi. Ce programme doit :
être autonome, se lancer au démarrage de Windows, redémarrer s'il a planté, relancer la communication entre le PC et l'équipement si nécessaire.
Enfin il doit réagir à tous les problèmes potentiels pour fiabiliser la communication et éviter au maximum les pertes de données éventuelles, débordement de piles, etc ( le 0% de perte serait l'idéal mais bon je ne miserais pas ma main là-dessus sur une telle application surtout développée par moi )

Je précise que l'application sur le PC doit acquérir des données toutes les 10 minutes. Les données sont récupérées en moins d'une minute.
Donc la plupart du temps l'application attend et scrute l'heure du PC jusqu'au prochain relevé.

Comment aborder le développement ?
Comment définir le type de mon application ( service, dll, Forms, etc ... )
Comment mettre en place l'application en sachant que j'ai déjà validé les différentes fonctionnalités du logiciel séparément ? La difficulté étant de les faire s'exécuter en permanence.

Je développe sous C++ Builder 5 et/ou C++Builder 2007.

Toutes les fonctionnalités ( communication entre PC et équipement + stockage vers base de données ) ont été validées dans divers projets de tests.


Voilà, tous les conseils sont bons à prendre alors n'hésitez pas à conseiller !

PS : je ne savais pas dans quel forum poster mon message, désolé si je me suis trompé

[Invité]

Bonjour,
Je ne suis pas spécialiste de ce type de problème, mais je développe aussi avec Builder, et ce sujet m'intéresse (je suis en retraite, donc très disponible).
Mais dans un premier temps, je ne sais pas trop quoi répondre, par exemple pour u lancement automatique au démarrage de Windows, il suffit le le mettre dans la liste de programme au démarrage.
Par contre, une chose importante, est-ce que ce PC servira à autre-chose qu'à communiquer avec cet équipement.
Il y a une dizaine d'années, j'ai vu une configuration identique, et ça ne semblait pas avoir posé de problème au développeur.

[bfespi69]

pour un lancement automatique au démarrage de Windows, il suffit le le mettre dans la liste de programme au démarrage.

Pour cet aspet j'y ai déjà pensé, je pensais mettre un raccourci dans le dossier Démarrage du menu Démarrer.

Par contre, une chose importante, est-ce que ce PC servira à autre-chose qu'à communiquer avec cet équipement.

Oui le PC devra être opérationnel pour afficher certains graphiques par le biais d'un logiciel déjà développé. Mais cependant les 99% du temps il ne sera utilisé par personne.

Merci en tout cas de t'intéresser à mon problème.
J'espère que ça fera en venir d'autres qui donneront pleins de conseils

[bacelar]

Pour cet aspet j'y ai déjà pensé, je pensais mettre un raccourci dans le menu démarrage.

Non, le menu démarrage est associé à une session utilisateur, il faudrait donc qu'un utilisateur soit connecté. C'est donc hors du scope d'utilisation.

Sous Windows, je vois deux manières de faire votre projet.
- un service Windows
- une tâche planifiée

Ces "solutions" peuvent s'exécuter sans utilisateur connecté, être automatiquement lancé au démarrage de Windows pour les services, et automatiquement lancé par le scheduleur du système pour les tâches. Les services peuvent être relancés automatiquement en cas de problème, les tâches, elles, sont relancées par définition.

Le choix de l'un où l'autre doit prendre en compte que :
- un service prend des ressources en permanence
- une tâche ne prend pas des ressources en permanence mais le chargement et le déchargement de l'application récurrent peu être couteux.
- un service est nettement plus complexe à mettre au point (mais vous pouvez transformer votre projet en service à la fin du développement).

[bfespi69]

Bonjour bacelar,

- un service est nettement plus complexe à mettre au point (mais vous pouvez transformer votre projet en service à la fin du développement).

En quoi un service est nettement plus complexe à mettre au point si on peut transformer son projet à la fin ? Y'a t'il des précautions à prendre si je sais déjà que je vais le transformer ?

En tout cas merci d'avoir donner votre avis, je pensais m'orienter vers une application service. Je crois que ça sera bien le cas.

Je ne connais rien dans le développement de tâches planifiées. Je sais juste que l'on peut en réaliser dans Windows ( programmer l'arrêt du PC par exemple ) mais c'est tout, je ne connais rien de complexe qui serait de planifier l'ouverture du port COM et l'envoi du requete SQL au serveur de BDD.

D'autres idées ou remarques ?

[ram-0000]

En quoi un service est nettement plus complexe à mettre au point si on peut transformer son projet à la fin ?

C'est moins facile de déboguer un service qu'un programme simple.

Y'a t'il des précautions à prendre si je sais déjà que je vais le transformer ?

Un service n'est pas réellement connecté à la machine, il y a donc une branche de la base de registres, HKEY_CURRENT_USER, qui n'existe pas dans l'environnement de ce service.

L'identité sous laquelle s'exécute un service est souvent "LocalSystem". C'est un compte système privilégié mais local seulement. Il aura peu/aucun privilège au travers du réseau pour par exemple monter un disque d'une machine distante ou parcourir un disque réseau.

Si on décide que le service doit être lancé sous une identité réelle, il y a la possibilité de le spécifier un utilisateur et un mot de passe dans les propriétés du service. Par contre il ne faudra pas oublier de revenir dans les propriétés du service et modifier le mot de passe s'il y a une politique de vieillissement des mots de passes appliquée sur ce compte.

[bacelar]

Un service Windows ne doit pas avoir d'IHM (ni console ni fenêtre).

Une tâche planifiée peut lancer n'importe quel exécutable et cela de manière répétée.

Donc pour une tâche planifiée, vous créez un simple programme qui initialise l'environnement, fait son travail à un instant t, puis se ferme.
Le fait de faire cela à intervalle régulier n'est plus gérer par votre programme mais par le scheduler de Windows.
Le programme ne sera plus résident en mémoire de manière permanent mais sera automatiquement lancé régulièrement.

[bfespi69]

Bonjour,

Mon programme doit être paramétrable, donc je voulais savoir si une tâche planifiée et un service pouvait accéder à un fichier de configuration ( type .ini par exemple ) pour connaître le nombre et l'adresses des registres à interroger sur l'équipement connecté au port série ?

Selon moi je pense que oui, et que rien ne pourrait empêcher cela mais je demande toujours au cas où.

Je dois pouvoir modifier le fichier .ini pendant que le service tourne ou que la tâche s'exécute. Cependant la modification du fichier .ini de configuration ne doit pas forcément intéragir sur les relevés en cours mais sur les prochains relevés qui seront effectués.

Avec toutes ces informations de la part des membres du forum je ne sais plus trop vers quoi m'orienter car les taches planifiés et les services ont chacun leurs avantages et inconvénients.
En général je programme des applications type fenêtrés assez conséquentes, cependant je n'ai peu de connaissances en service et tâche planifiée. J'ai une assez bonne connaissance du C++ en général.

N'hésitez pas à donner vos avis sur le type d'application, ça m'aidera surement à chosir !

Merci.

[bacelar]

Vous pouvez tout à fait utiliser un fichier ini pour un service Windows ou une tâche planifiée mais, généralement, on lui préfère l'utilisation de paramètre en ligne de commande.
Le problème du fichier ini c'est que cela fait accéder au système de fichier et il n'est pas forcement évident que le compte sous lequel tourne le programme ait les droits de le lire, et le working directory du programme n'est pas trivial et change d'un OS à l'autre ou d'une installation à l'autre.
En utilisant les paramètres en ligne de commande, vous n'avez plus ces problèmes.

Je dois pouvoir modifier le fichier .ini pendant que le service tourne ou que la tâche s'exécute. Cependant la modification du fichier .ini de configuration ne doit pas forcément intéragir sur les relevés en cours mais sur les prochains relevés qui seront effectués.

Avec des tâches planifiées et des paramètres en ligne de commande, il n'y a aucun problème puisque vous n'avez qu'à modifier ou ajouter une tâche avec les nouveaux paramètres en ligne de commande.

Pour un service Windows, il faut implémenter soi-même une relecture d'un fichier de configuration. Mais un service Windows est souvent accompagné d'un programme "client" qui communique avec lui. Un service Windows doit souvent être administrable depuis une console d'administration et l'utilisation d'un module "client" du service est indispensable dans ce cas là.
Les changements de configurations pourront donc transiter par le client vers le service Windows. A la charge du service Windows de les prendre en comptes.

Avec toutes ces informations de la part des membres du forum je ne sais plus trop vers quoi m'orienter car les taches planifiés et les services ont chacun leurs avantages et inconvénients.

Ne vous inquiétez pas. Contrairement à une application graphique monolitique, avec une conception un peu soignée, vous pourrez très facilement faire passer un service Windows à une tâche planifiées et vis-vers-ça.
Il faut juste que la boucle du service Windows soit la plus externe possible.
Avec cette histoire de changement de configuration, je trouve que las tâches planifiées seraient plus simple, mais il faut que l’overhead de lancement de l’application (que l’ont paye à chaque itération avec une tâche planifiée) soit raisonnable.

[bfespi69]

Pour info, le PC qui accumule des données sera dans un système complet. C'est à dire qu'il sera dédié à la communication vers l'équipement, donc que l'on maîtrisera l'installation, les droits/mot de passes et sessions de Windows, ainsi que la version d'OS installée ( pour l'instant XP dans la plupart des cas ).
C'est pourquoi une application graphique ( avec IHM pour plus de souplesse et facilité ) servant à modifier le fichier de configuration ( .ini ) destiné à paramétrer mon service me semblait une bonne idée.
Si ce n'est pas le cas, faites part de vos avis.

Cependant je ne sais pas trop par où commencer.

Je pense que je vais d'abord m'intéresser à la façon de créer une application services avec les outils de développement que je possède car je pense que c'est une première étape indispensable .

Encore quelques questions pour les plus courageux à répondre :

Es-ce que le résultat de la compilation d'une application service est un .EXE ?
Peut-on créer une tâche planifiée avec un outil tel que C++Builder ?
A quoi ressemble une tâche planifiée une fois écrite/compilée ?

Je vais commencer à me documenter sur le développement d'un service.
Je viendrais faire part de mon avancement si ça en intéresse certains.

A bientôt et encore merci pour votre soutien.

[ram-0000]

Es-ce que le résultat de la compilation d'une application service est un .EXE ?

Oui

Peut-on créer une tâche planifiée avec un outil tel que C++Builder ?

Pas tout à fait. On peut créer un exécutable avec un outil tel que C++Builder. Cet exécutable peut ensuite être lancé/exécuté/planifié par le planificateur de tâche.

La planificateur de tâche est un service du système dont le rôle est de lancer périodiquement des tâches.

[bfespi69]

Ok donc si j'ai bien compris :

si je décide d'utiliser le planificateur de tâches pour réaliser cette application, il faudra que le planificateur lance toutes les 10 minutes mon .EXE avec des paramètres différents ?

Merci

[ram-0000]

Oui

[bfespi69]

Ok donc comme je désire relever des données toutes les 10min ( 6 fois/heure ) 24h/24 7j/7, je dois déclarer 144 tâches planifiées ? ou 1008 ?

6 x 24 = 144
144 x 7 = 1008

Je dirais plutôt 144 avec dans le code source une détection du jour mais qu'en pensez vous ? N'est-ce pas trop lourd à déclarer plutôt qu'un service qui s'exécute en permanence ?

Cordialement.

[ram-0000]

Comme la granularité du planificateur de tâche est de 1 jour, si tu veux une tâche toutes les 10 minutes, il va falloir créer 144 tâches (6*24).

[bfespi69]

Est-ce qu'une tâche planifiée peut être déclarée grâce à un programme en C++ ?

Je me vois mal configurer 144 tâches planifiées dans Windows pour chacun des systèmes qui seront mis en place ...

[bacelar]

Je voudrais rectifier quelque chose, si la tâche doit être appelée toute les dix minutes avec les mêmes paramètres, il seul tâche planifiée suffit.
Vous pouvez données un intervalle de temps entre chaque démarrage.

Mais si les paramètres changent, il faudra enregistrer autant de tâche planifiée que de jeux de paramètre différent. Il y aura plusieurs tâches planifiées mais il n'y aura qu'un programme à développer.

Je me vois mal configurer 144 tâches planifiées dans Windows pour chacun des systèmes qui seront mis en place ...

Il est très facile de scripter l'enregistrement des tâches planifiées. Donc qu'il ait 100 tâches ou 1, l'installation et la désinstallation sont toujours aussi simples.

Est-ce qu'une tâche planifiée peut être déclarée grâce à un programme en C++ ?

Une tâche planifiée lance n'importe quel exécutable, donc avec n'importe quel langage capable de générer un exécutable. On pourrait même lancer l'interpréteur d'un langage et passant le code source à interprété en paramètre de l'interpréteur.

[bfespi69]

En fait, mon application doit intérroger toutes les 10 minutes les mêmes registres des mêmes esclaves modbus, qui dialoguent avec l'équipement connecté au port série du PC.

Par exemple :

à 0h00, je dois consulter et enregistrer :
les valeurs des registres 22,23,24 de l'esclave modbus d'adresse 121.
les valeurs des registres 31,32,33 de l'esclave modbus d'adresse 124.

à 0h10, je dois consulter et enregistrer :
les valeurs des registres 22,23,24 de l'esclave modbus d'adresse 121.
les valeurs des registres 31,32,33 de l'esclave modbus d'adresse 124.

à 0h20, je dois consulter et enregistrer :
les valeurs des registres 22,23,24 de l'esclave modbus d'adresse 121.
les valeurs des registres 31,32,33 de l'esclave modbus d'adresse 124.

etc... jusqu'à 23h50. ( donc 144 fois par jour )

Donc si je développe par tâche planifiée, la tâche lancera un .EXE avec les mêmes paramètres ? Cependant la détection de l'heure et du jour de l'année se fera dans le code du programme de la tache planifiée. C'est ça ?

Donc je dois déclarer une tâche planfiée qui se lance toutes les 10 minutes mais sur des dizaines pleines. C'est à dire à 00h00, 00h10, 00h20, ..., 23h50 ?

Comment déclarer une tache planfiée qui se lance toutes les 10minutes et calées sur les dizaines de minutes de l'horloge du PC ?

[bacelar]

Schtasks :
http://technet.microsoft.com/en-us/l...85(WS.10).aspx

Moi, j'ai toujours tendance à faire le code le plus simple possible, donc la liste des adresses et des registres, je les passerais en paramètres de ma ligne de command.
C'est plus facile à lire et à modifier dans un fichier .bat que dans le code, qu'il faudra en plus recompiler et réinstaller en cas de changement.
Le programme sera nettement plus facile à tester avec ces paramètres en lignes de commande que dans le code ou dans un fichier ini.

Vous pouvez donc faire un programme qui interprétera les paramètres en ligne de commande, fait son travail sur les adresses et les registres passés en paramètres et sort.

Vous n'aurez donc aucune modification autre que de changer la configuration de la tâche planifiée dans l'interface dédiée de Windows, ou en utilisant encore une fois Schtasks. En plus, pour lancer un simple test de l'exécutable sans passer par les tâches planifiée, vous n'avez qu'à lancer un fichier .bat contenant que le chemin vers l'exécutable avec les paramètres adéquats.

Si vous pouvez spécifier plusieurs adresses avec plusieurs registres chacun dans une ligne de commande (et c'est très facile ), vous n'avez qu'à enregistrer une seule tâche planifiée et non 144.

[bfespi69]

Merci bacelar pour tes informations utiles encore une fois.
Je me familiarise petit à petit avec Schtasks et cela va beaucoup m'aider pour la suite.

Cependant j'ai une nouvelle question .
J'ai choisi la solution d'une tâche planifiée qui lance un executable.
Mon executable doit être lancé, faire l'acquisition des données et ensuite se fermer. Jusque là aucun soucis.

Cependant je voudrais que cela se fasse de façon transparente sur la session windows. C'est à dire que lorsque ma tache s'execute, rien a l'écran ne me le fait remarquer.

J'ai pensé à faire mon .exe en mode console, cepedant à chaque fois que ma tâche se lance, j'ai une fenêtre ms-dos vide qui apparait et disparait aussitot ( une fois les données acquises ).

Cela ne me convient guère car ce n'est pas du tout transparent (visuellement).
J'ai cherché une solution pour que mon .exe en mode console n'affiche pas la fenêtre ms-dos, cependant cela semble impossible. Windows génère automatique une fenêtre avec un programme en mode console.

Il reste une solution qui serait de faire une application fenêtrée, sur laquelle on cacherait la fenêtre au commencement du programme, mais je trouve ça très barbare, surtout que cette fenêtre n'aurait aucun bouton, aucun menu, donc aucune utilité à part sa propriété Visibile à mettre à false .

Est-il vraiment impossible de lancer un .exe en mode console sans afficher la fenêtre ms-dos ?

Quelle solution alternative s'offre à moi ?

Une idée ? Une remarque ? Une solution ? N'hésitez surtout pas !

Merci d'avoir lu jusque là encore une fois !

A bientot.

PS : je développe toujours sous C++Builder 5 ou C++Builder 20007