Bonjour,

Ce mois d’Avril a été propice et l’actualité « Ada for Automation » est donc plus étoffée que de coutume.

Nouvelle présentation du site

Commençons par la nouvelle la plus visible, le changement de thème de WordPress. L’aspect n’est pas tant ce qui m’a conduit à en changer bien que je le trouve assez réussi. C’est surtout le « Responsive Design » ou la faculté de s’adapter à la taille de la fenêtre du navigateur qui a motivé mon choix.

Que vous accédiez au site depuis un PC, une tablette ou un smartphone, même un pas très smart, le site devrait être lisible, même si le contenu peut être indigeste…
Même sur un PC vous pouvez expérimenter en jouant avec la taille de la fenêtre et observer comment les différents éléments se replacent magiquement.

Hormis le choix et la disposition des « Widgets », le thème est standard.

J’espère que cette nouvelle présentation vous soit agréable.

Interface Homme-Machine – Gnoga et AICWL

Tandis que j’étudiais, comme évoqué dans cet article, les technologies Web pour une utilisation avec « Ada for Automation », Monsieur David BOTTON a créé Gnoga, un framework pour développer des applications Web en Ada :
http://www.gnoga.com/

Aussi, je suis particulièrement intéressé par ce cadre applicatif et je compte bien l’utiliser pour l’IHM d’applications « Ada for Automation » comme App1.

Pouvoir piloter l’arrosage de son potager depuis son smartphone ou sa tablette est à n’en pas douter un must ! 😉

Cependant, pour un affichage plus dynamique et des composants graphiques évolués, la bibliothèque ADA INDUSTRIAL CONTROL WIDGET LIBRARY de Monsieur Dmitry A. KAZAKOV est sans conteste plus adaptée :
http://www.dmitry-kazakov.de/ada/aicwl.htm

Ces deux solutions partagent quelques composants dont le serveur web de Monsieur Kazakov.

Bien sûr, GtkAda permet également de réaliser une IHM et les trois technologies ne s’opposent pas mais se complètent à merveille.

Vérification de style et correction des avertissements

L’un des avantages les plus proéminents du « libre » c’est qu’il permet d’apprendre beaucoup en étudiant le code écrit par la communauté.

Comme les projets évoqués ci-dessus mettent en œuvre des options permettant la vérification de style et générant un maximum d’avertissements lors de la compilation, je me suis penché sur le sujet et ai intégré dans les fichiers projets ces options documentées ici et là :
https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gnat_ugn/Style-Checking.html
https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gnat_ugn/Warning-Message-Control.html
https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gnat_ugn/Compiler-Switches.html

Il a fallu évidemment corriger beaucoup de choses… ce qui a été fait pour l’essentiel.

Réorganisation des tests

Je n’avais pas encore eu l’occasion de remercier Monsieur François FABIEN pour ses conseils avisés.

Comme François me l’avait suggéré il y a quelque temps déjà j’ai réorganisé les tests afin qu’ils aient leurs propres projets et répertoires.
Ainsi, ils n’interfèrent plus avec les autres projets et cela permet de rendre les choses plus « lisibles », du moins je l’espère.

HilscherX – réusinage de la communication acyclique

Le plus gros du travail sur le code a porté sur la partie permettant l’utilisation des cartes de communication Hilscher ainsi que des modules comX et netJACK qui partagent la même interface applicative.

Le principe de cette communication acyclique a été abordé dans un certains nombre d’articles, le premier de la série étant sans doute celui-ci. La page Plan du site liste les articles concernant l’infrastructure mise en œuvre dans « Ada for Automation » pour gérer ce type de communication.

Il y est question de Paquets, de Pool de paquets, de Queues de paquets, etc… Si le principe reste inchangé, l’implémentation a été revue car le problème était le suivant :

L’en-tête des paquets contient des identifiants de source et de destination qui permettent le routage de ces paquets. La documentation Hilscher explique ce routage en indiquant que les champs Source et Source_Id doivent identifier l’application et le processus émetteurs. Le procédé de routage doit en fonction de ces champs retrouver la queue de messages correspondante.

Cependant, un raccourci employé est de renseigner ces champs avec les pointeurs de queues directement comme on peut le constater couramment dans la documentation relative aux piles de protocoles. Dans le firmware des produits, le système d’exploitation rcX utilisé est un système 32 bits et les pointeurs ont une taille de 32 bits. Indiquer la valeur du pointeur de la queue permet donc un routage très rapide puisqu’il n’y a pas lieu de rechercher ce pointeur ailleurs.

Dans ma première implémentation j’avais donc utilisé le même artifice… Mais il s’est posé un problème avec ma Debian 64 bits, le pointeur de la queue ne tenait plus dans le champs !

J’ai donc revu le routage afin de passer par une table intermédiaire, la Queue_Map, qui associe les pointeurs de queues et des indices, ces indices étant utilisés dans le champs Source_ID. Et puis, comme j’ai fait quelques progrès en Ada, j’ai également retravaillé les Pool et Queue de paquets.

HilscherX – RCX_GET_DPM_IO_INFO_REQ

Dans l’interface standard Hilscher, la fameuse Dual Port Memory, les zones réservées à l’image procédé, « les IO areas » comportent 5760 octets en entrée et autant en sortie.
Dans la plupart des cas d’utilisation c’est plutôt confortable et seule une partie de ces octets sont utilisés.

Les fonctions de l’API, xChannelIORead et xChannelIOWrite, qui permettent l’accès à ces zones prennent en paramètres un offset et une taille de données, ce qui permet de ne rafraîchir que les données effectivement configurées, avec bien sûr un gain de temps à la clef.

Il est possible avec la requête RCX_GET_DPM_IO_INFO_REQ de récupérer les informations concernant les zones IO, offset et taille, et nous avons donc implémenté un bloc fonction pour cela, le test qui va avec et modifié la tâche principale du projet « A4A_HilscherX » en conséquence.

Ainsi, les projets comme « App2 » qui héritent de « A4A_HilscherX » en profitent naturellement.

HilscherX – Diagnostic générique

Le document consacré à la Dual Port Memory mentionne, pour chaque canal de communication,

• un « Common Status » qui permet de connaître un état de la communication commun à toutes les piles de protocoles,
• un « Extended Status » qui permet de connaître un état de la communication relatif à chaque pile de protocole et documenté dans le manuel de la pile.

L’état étendu n’est pas utilisé par toutes les piles.

Pour certaines piles comme PROFIBUS DP Maitre, CANopen Maitre ou DeviceNet Maitre, cette zone contient la structure de diagnostic fournie par l’ancienne gamme des CIF, aujourd’hui obsolète, afin de faciliter la migration d’applications vers la nouvelle gamme cifX.

Cependant les capacités des bus de terrain basés sur Ethernet Temps Réel requièrent de repenser le principe du diagnostic. Pa exemple, PROFIBUS DP ne permet que 126 nœuds sur le réseau quand EtherCAT en prévoit en théorie jusqu’à 65535 !

Aussi, le manuel de la DPM indique que le diagnostic des protocoles maîtres se passe en deux temps.

Dans un premier temps, on utilise la requête RCX_GET_SLAVE_HANDLE_REQ pour récupérer une liste de « handles » d’esclaves, configurés, actifs ou présentant une information de diagnostic disponible, selon la liste demandée.

Dans un second temps, pour chaque « handle » de la liste retournée, la requête générique RCX_GET_SLAVE_CONN_INFO_REQ permet de récupérer les informations de connexion de l’esclave considéré.

Chaque pile de protocole maître retourne une structure documentée dans le manuel propre à la pile.

Nous avons donc créé un bloc fonction pour RCX_GET_SLAVE_HANDLE_REQ et un pour RCX_GET_SLAVE_CONN_INFO_REQ et créé les applications de test pour PROFIBUS DP Maître et EtherCAT Maître.

Et puis ?

Je lorgne du côté de la partie « Motion Control » chez PLCopen :
http://www.plcopen.org/pages/tc2_motion_control/

J’aimerais bien construire une telle bibliothèque en Ada intégrée dans « Ada for Automation ». La spécification est téléchargeable sur le site.

Bien sûr, si un tel projet vous intéresse pour vos propres réalisations, travaillons ensemble !

Pour l’instant je ne dispose pas de matériel pour tests. A minima il me faudrait un variateur communicant, avec son moteur et son codeur.
Aussi, si un tel matériel traîne dans vos placards et vous embarrasse, pensez à moi avant de le jeter à la benne.

D’ailleurs, je suis preneur de tout équipement communicant pourvu qu’il fonctionne encore et que son alimentation ou sa taille ne soient pas incongrues.
Merci d’avance pour vos contributions matérielles, qui me permettront de réaliser expériences, démonstrations et articles sur ce blog comme j’ai déjà pu le faire ici avec un radar de chez Endress + Hauser ou là avec du matériel Eaton !

N’hésitez pas à nous faire part de vos remarques et propositions éventuelles via le forum ou par email (contact).

Cordialement,
Stéphane