Archives de catégorie : Ada4Automation

A4A : Lâché dans la nature, malingre

Bonjour,

Voici la première version de mon projet Ada for Automation présenté ici :
http://slo-ist.fr/ada4autom

Soyez indulgent, je balbutie en Ada et c’est le résultat de mes balbutiements que j’expose à votre sagacité.

Côté code, j’étudierai vos remarques avec attention et tâcherai de me conformer de mon mieux aux règles que j’ai trouvées ici :
http://en.wikibooks.org/wiki/Ada_Style_Guide

Ce wikibook m’est d’une grande aide aussi :
http://en.wikibooks.org/wiki/Ada_Programming

Ce n’est certes pas aussi fouillé que le Barnes, le Burns and Wellings ou le Mc Cormick qui trônent sur mon bureau mais c’est quelque fois plus rapide d’y trouver un exemple et les explications qui vont avec, avec le copier-coller en plus…

Je bute sur le binding de :
http://libmodbus.org/

Cela fonctionne en Client et en Serveur, voyez dans le dossier « test » mais je ne suis pas satisfait de ma solution pour la fonction :
http://libmodbus.org/site_media/html/modbus_mapping_new.html

Quant au reste, c’est exploratoire… Ada, c’est trop fort ! 😉

Je n’ai pas trop d’avis sur la « forge » susceptible d’accueillir ce projet, aussi en voilà une archive :
http://slo-ist.fr/Download/A4A/A4A_V06_20130124.7z

Je suis preneur de vos avis sur la question de la « forge » comme sur cette production en général et je vous en remercie d’avance.

Normalement ça doit compiler sans problème. Après tout, c’est du Ada.

Si c’est compilé avec succès, on trouve dans le dossier « exe » l’ensemble des binaires.

Les plus « drôles » sont :

  • « test_libmodbus_server_many » qui implémente un serveur Modbus TCP répondant à de multiples clients, il est dérivé de celui que l’on trouve dans les sources de libmodbus, « bandwidth-server-many-up.c »,
  • et « test_libmodbus_client2 « , inspiré de « unit-test-client.c », que vous pouvez exécuter en plusieurs instances, et qui discutera volontiers avec le précédent.

Comme la documentation est encore dans ma tête, voici quelques informations sur Ada for Automation :

  • c’est un framework, c’est à dire du code pour vous permettre d’écrire vos propres applications. Il est nécessaire d’y ajouter le code de votre application pour qu’il en sorte quelque chose d’utile.
  • il vous faudra apprendre Ada, doucement mais sûrement, pour l’utiliser. Cependant la disponibilité du code source vous y aidera et si vous connaissez le langage ST pour « Structured Text » vous serez surpris par une certaine familiarité.
  • c’est un langage compilé et il faudra apprendre à utiliser les outils et les techniques de debug.
  • en principe, votre code devrait se trouver dans le paquetage « A4A.Application ». Mais vous pouvez faire ce que vous voulez du moment que vous respectez la licence.
  • le framework organise les tâches comme celles que l’on trouve dans un automate, cycliques, périodiques ou événementielles, dans le paquetage « A4A.Kernel », et les tâches appellent les fonctions que vous définissez dans le paquetage « A4A.Application ». Dans ce paquetage, on trouve également les données et les objets de votre application.
  • le paquetage « A4A.Library » fournit une librairie de fonctions comme « Conversion » et de composants comme « Timers » et « Devices ». Cette librairie n’est pas très étoffée pour le moment…
  • le paquetage « A4A.Protocols » ne fournit pour le moment qu’un binding vers la librairie « libmodbus », ce qui permet déjà d’implémenter un serveur Modbus TCP pour la connexion d’un superviseur ou un client pour piloter un module d’entrées / sorties serveur Modbus TCP. Je n’ai pas encore eu le temps de réaliser le binding des fonctions Modbus RTU mais ça ne me semble pas hors de portée. Si cela intéresse quelqu’un, je peux réaliser un binding de la librairie du pilote pour les cartes Hilscher cifX… 😉
  • enfin, votre application pourra être soit en mode console, soit avec une interface graphique avec GtkAda.
  • et, cerise sur le gâteau, elle pourra s’exécuter tant sous Linux que sous Windows® par simple recompilation sur la plate-forme de votre choix.

Si la licence choisie, GMGPL, n’évoque rien pour vous et que vous vous demandez ce qu’il est légal de faire avec une telle licence, voyez avec votre juriste favori ou avec les gens de chez AdaCore, qui fournissent les outils Ada que j’utilise et qui ont conçu cette licence.
J’avoue ma grande incompétence dans ce domaine. N’hésitez pas à m’éclairer.

Je consulte régulièrement les forums Ada et notamment :
https://groups.google.com/forum/?fromgroups=#!forum/fr.comp.lang.ada

Si vos questions portent sur Ada, de très compétentes et sympathiques personnes pourront y répondre.
J’espère pour ma part pouvoir répondre à celles que vous poserez sur Ada for Automation.

Bien sûr, c’est un projet libre et je ne manquerai pas d’intégrer vos contributions si elles servent le projet.

Cordialement,
Stéphane

A4A : compilation de libmodbus avec GNAT GPS sous Windows

Bonjour,

Pour mon premier article concernant « Ada for Automation » j’ai choisi de mettre en exergue d’une part GNAT GPL, l’atelier de développement édité par AdaCore, et d’autre part la bibliothèque libmodbus que j’utilise pour développer des outils de test ou de démonstration par exemple et aussi dans « Ada for Automation ».

Je me propose donc de montrer une facette de GNAT GPL, que j’utilise bien évidemment pour développer en Ada, mais qui est également très capable pour développer dans d’autres langages dont le C, ce que je vais mettre à profit pour compiler libmodbus sous Windows® XP.

J’apprécie beaucoup libmodbus, une bibliothèque qui permet de réaliser très simplement une application Modbus, RTU Maitre ou Esclave / TCP Client ou Serveur, qui présente de nombreux avantages comme la disponibilité du code source, une licence LGPL, disponibilité pour plusieurs plateformes dont Linux et Windows®.

Comme je suis souvent sous Windows®, ainsi que bon nombre d’entre nous, et que cette bibliothèque n’est pas fournie sous forme binaire, il est nécessaire de disposer d’une chaine d’outils pour obtenir la DLL qui va bien pour nos projets.

En cherchant un peu sur la page de Monsieur Stéphane Raimbault on trouve que, pour compiler sa bibliothèque sous Windows®, on peut utiliser MinGW et MSYS. Il est également possible d’utiliser Microsoft Visual Studio®.

C’est très bien pour ceux qui ont une certaines expérience de ces outils mais c’est un peu complexe pour beaucoup, dont le public espéré pour « Ada for Automation ».

Or il se trouve que GNAT GPL est disponible sous Windows®, intègre MinGW et les outils nécessaires à cette compilation, et s’installe le plus simplement.

Moyennant un petit fichier définissant les chemins, les fichiers et quelques options de compilation, l’outil GPRbuild va gérer compilateur, linker…

Voici donc le contenu de ce fichier « lib_modbus32x86.gpr », que je trouve assez auto-explicatif :

library project Lib_Modbus32X86 is

   for Languages use ("C");
   for Library_Dir use "..\libmodbus-3.0.3\libs\x86";
   for Library_Kind use "dynamic";
   for Library_Name use "modbus";
   for Source_Dirs use ("..\libmodbus-3.0.3\src");
   for Source_Files use ("modbus.c", "modbus.h", "modbus-data.c", "modbus-private.h", "modbus-rtu.c", "modbus-rtu.h", "modbus-rtu-private.h", "modbus-tcp.c", "modbus-tcp.h", "modbus-tcp-private.h", "modbus-version.h");
   for Object_Dir use "..\libmodbus-3.0.3\obj";
   for Library_Options use ("-lws2_32");

   package Linker is
      for Linker_Options use ();
   end Linker;

end Lib_Modbus32X86;

J’ai donc téléchargé le code source de libmodbus et je l’ai désarchivé dans mon arborescence avec 7-Zip. J’ai créé les répertoires « libs » et « obj » parce que j’aime bien que tout ne soit pas mélangé.

Pour un projet en C utilisant cette bibliothèque, il suffit d’inclure le fichier projet de celle-ci dans le fichier de notre projet « c01.gpr » :

with "lib_modbus32x86.gpr";

project C01 is

   for Languages use ("C");
   for Source_Dirs use ("src");
   for Source_Files use ("unit-test-server.c", "unit-test.h");
   for Main use ("unit-test-server.c");
   for Object_Dir use ".\obj";
   for Exec_Dir use ".\exe";

   package Naming is
      for Spec_Suffix ("c") use ".h";
      for Body_Suffix ("c") use ".c";
   end Naming;

end C01;

Bien sûr, j’ai créé l’arborescence correspondante :

Pour ce projet de test je ne me suis pas embêté ; j’ai récupéré les fichiers sources dans le dossier « tests » de libmodbus.

En ouvrant le projet « lib_modbus32x86.gpr » avec GNAT GPL et en tentant de le compiler j’ai obtenu une erreur comme quoi le fichier « config.h » inclus dans les fichiers « modbus.c » et « modbus-private.h » n’existait pas. C’est normal car ce fichier est généré par les autotools que l’on n’utilise pas dans ce cas. J’ai donc commenté les lignes et « Build All » a réussi à générer la DLL.

Ta ! Tan ! Yeah !

So far, so good…

Voyons avec le projet de test.

Ça compile d’un coup de « Build All » et je trouve mon exécutable là où il est censé se trouver. J’y colle avec la DLL car le chemin de celle-ci n’est pas dans mon %PATH%.

Je peux lancer mon programme de test obtenu et il attend la connexion d’un client :

Comme client, je vais utiliser l’utilitaire « Modbus Poll« .
Je définis une connexion vers le PC exécutant mon programme de test. Le port est le « 1502 », celui qui est défini par défaut dans le programme de test car sous Linux le port « 502 » nécessite des droits administrateur.

Et le compteur qui s’incrémente est de bon augure.

Tandis que côté programme de test Modbus TCP Server, qui a été compilé avec l’option « Debug » sur « On », on observe les traces de nos échanges.

N’est-ce pas merveilleux ? 😉

Cordialement,
Stéphane