Bonjour,
Recevez mes meilleurs vœux pour cette nouvelle année !
Jusqu’à présent votre application « Ada for Automation » ne disposait que d’une maigre interface en ligne de commande.
Bien sûr, il était déjà possible de s’y connecter via le serveur Modbus TCP et de réaliser une interface graphique évoluée avec PcVue de Arc Informatique par exemple comme démontré ici.
L’interface en ligne de commande est certes un peu frustre mais a des avantages :
- votre application ne nécessite pas de matériel (écran, clavier, souris) ni de bibliothèque supplémentaire, c’est parfait si vous installez la CPU qui exécute celle-ci dans une armoire ou un coffret électrique,
- elle est moins lourde, sur de petites configuration ça compte,
- et elle est plus simple, ce qui est un avantage important quand on débute.
Mais l’interface graphique c’est quand même sympathique. Elle permet une interaction utilisateur – application bien plus riche et une prise en main plus rapide.
Vous en rêviez, c’est aujourd’hui disponible ! 😉
– Hein ?
Oui ça marche sous Linux comme sous Windows® car l’on utilise le binding Ada de la bibliothèque GTK+, GtkAda.
– GTK+ 2 ou 3 ?
Pour l’instant GTK+ 2. Sous Debian Linux, le binding Ada GTK+ 3 n’est pas encore disponible. Et sous Windows® il est encore un peu jeune.
Donc, sous Windows® j’installe la version 2013 de GNAT et la version 2012 de GtkAda depuis :
http://libre.adacore.com/
Et ça ressemble à quoi ? Hé bien à ceci :
On y trouve des boutons :
- Quit : l’équivalent du Ctrl+C disponible dans l’application en ligne de commande, qui permet de quitter l’application proprement.
- Stop : arrête le traitement du programme utilisateur. Cela n’interrompt pas les tâches de communication qui continuent donc de s’exécuter. Les sorties sont cependant mises à 0.
- Start : démarre le traitement du programme utilisateur.
Et des onglets présentant :
- l’identité de l’application,
- l’état général de celle-ci,
- l’état du serveur Modbus TCP,
- l’état des clients Modbus TCP, (pas encore terminé)
L’état général ci-dessous montre l’application au démarrage. Le programme utilisateur est à l’arrêt, ce qui est signalé par les deux loupiotes rouges, la première, verte ici, indique que le chien de garde de la tâche n’est pas déclenché.
On y voit également la date et heure à laquelle l’application a été démarrée ainsi que la durée d’exécution.
Ci-après, le programme utilisateur est démarré, les loupiotes sont toutes vertes. Sont également présentées les informations concernant la configuration des tâches et des statistiques qu’il faut prendre avec des pincettes comme toutes les statistiques.
Ainsi les valeurs mini et maxi de la durée d’exécution des tâches sont indicatives. En effet, elles peuvent être préemptées par le système d’exploitation et donc le maxi est très approximatif.
La moyenne est une moyenne glissante calculée sur 256 échantillons. Au bout d’un temps, fonction de la période affectée, elle donne une valeur plutôt correcte.
Les données concernant l’ordonnancement donnent une idée du comportement plus ou moins temps réel selon le système d’exploitation utilisé et la charge système.
Ces mesures montrent l’écart entre le temps de réveil de la tâche programmé et le réalisé.
Sous Windows®, c’est pas terrible, comme attendu, mais ça convient pour beaucoup d’usages cependant.
Ci-dessous, la vue présente l’état du serveur Modbus TCP intégré. On y trouve le nombre de clients Modbus TCP connectés et les compteurs des requêtes servies.
Enfin, les logs sont toujours affichés dans la fenêtre de démarrage de l’application.
Pour terminer, voici une démonstration sous Debian Linux (Sid). Ce qui frappe, hormis l’esthétique plutôt réussie à mon goût, c’est la qualité de l’ordonnancement.
Attention aux conclusions hâtives, ce n’est pas du tout la même machine cependant, des années les séparent. Il faudrait que je réalise un test sous Windows® 7
N’hésitez pas à vous inscrire et participer sur le forum :
http://forum.slo-ist.fr
Cordialement,
Stéphane