Une architecture pour un système évolutif de contrôle commande d'expériences de physique. Olivier Taché

Transcription

1 Conservatoire National des Arts et Métiers PARIS Mémoire présenté en vue de l'obtention du diplôme d'ingénieur CNAM Spécialité : Informatique Option : Informatique et Systèmes Automatisés Une architecture pour un système évolutif de contrôle commande d'expériences de physique Olivier Taché Paris, 28 novembre 2006

2 2

3 Table des matières Table des matières 3 Introduction 7 I Etudes 9 1 Contexte Le laboratoire Le Commissariat à l'energie Atomique La Direction des Sciences de la Matière Le Département de Recherche sur l'état Condensé, les Atomes et les Molécules Le Service de Chimie Moléculaire Le Laboratoire Interdisciplinaire sur L'Organisation Nanométrique et Supramoléculaire La diusion des rayons X Les Rayons X La diraction des rayons X Technique de diusion des rayons X aux petits angles Etude préliminaire Gestion du projet - Objectifs Résultats à atteindre Tests à réaliser Délais Acteurs du projet Ressources Risques Marges de manoeuvre Sujet d'étude Montage USAXS État des lieux matériel État des lieux logiciel Problèmes existants Interface matérielle et logicielle

4 TABLE DES MATIÈRES Logique d'expérience Interface HM Problèmes futurs Solutions proposées Gestion des éléments matériels Gestion des éléments logiciels Interface homme machine Présentation des diérents systèmes de contrôle-commande Description d'un système de contrôle-commande à base de PC Elements matériels Éléments logiciels Qu'est ce qu'une couche d'abstraction matériel-logiciel? Solutions commerciales National Instruments Tests réalisés - Retour d'expérience Conclusion sur les solutions National Instruments Solutions Open Source Description TANGO Tests réalisés - Retour d'expérience Conclusion sur TANGO Présentation des diérents systèmes d'interface homme-machine pour expériences Spécicités d'une interface Homme Machine pour expériences Solutions à interface graphique Exemple d'ihm Langage de programmation graphique : LabView Visual Basic Java Conclusion Solutions à ligne de commande SPEC Python Conclusion - choix 51 II Réalisations 53 6 TANGO Fonctionnement général de TANGO Installation de TANGO Fonctionnement d'un device server Développement d'un device server Le générateur de code POGO

5 TABLE DES MATIÈRES Implémentation du code Développement d'un device server Utilisation Jive Astor Synoptique Conclusion Architecture de device servers Description générale Device servers de bas niveau Interface GPIB Acquisition Analogique simple Sortie Analogique simple Entrées-Sorties Numériques Device servers de niveau intermédiaire Device servers de haut niveau Shutter Filtres Evaluateur d'expression mathématique Conclusion Interface Homme-Machine Description générale et cahier des charges Documentation Accès à TANGO pytango pytangodevice pytangobeamline Interface logique d'expérience Environnement scientique Module de Scan Module d'enregistrement Conclusion - Résultats Conclusion générale - Perspectives 91 A Photographies du montage USAXS 97 B Documentation des device servers développés 101 C Exemple de device server en langage Python 103 D Documentation des programmes Python développés 107 D.1 pyrecorder D.1.1 Class pyrecorder D.1.2 Variables D.2 Scan

6 TABLE DES MATIÈRES D.2.1 Class Scan D.3 PyTangoDevice D.3.1 Variables D.3.2 Class pytangodevice D.4 PyTangoBeamline D.4.1 Variables D.4.2 Class Beamline E Procédure d'installation d'un Device Server 115 Bibliographie 119 6

7 Introduction De nos jours, l'informatique prend de plus en plus de place dans une expérience de physique. Les secrets des montages expérimentaux d'antan tenaient souvent dans la précision de la mécanique. Plus celle-ci était intelligemment conçue, plus les résultats expérimentaux étaient précis. Leur qualité venait également de la patience des expérimentateurs, qui reportaient les observations et mesures sur des cahiers et des graphes. Aujourd'hui, l'heure est à l'automatisation et à la collecte sans limite des données. La gure ci-dessous présente une photo d'un des premiers montage de diusion des rayons X aux petits angles, qui date des années 50. Ici, pas d'électronique, pas d'ordinateurs. Les mesures sont réalisées grâce à une plaque photographique. Sur la photo de droite, prise en 2006, on peut voir une partie de l'expérience ID2 de l'esrf (European Synchrotron Research Facilities) de Grenoble. Celle-ci réalise le même type de mesures, mais est composée de plus d'une centaine de moteurs et d'instruments. A gauche : montage expérimental des années 50, à droite, partie du montage ID2 en 2006 L'ordinateur est désormais au coeur de l'expérience, irriguant les diérents appareils qui la compose de demandes d'informations et de commandes diverses. La tendance actuelle est de connecter le moindre système de mesure au réseau, s'aranchissant ainsi des distances. Les composants de l'expérience peuvent être déportées à plusieurs mètres du poste de commande, voire dans des pièces diérentes. Les protocoles de communication sont bousculés, car il n'est plus besoin de relier physiquement l'instrument et l'ordinateur. Tout se passe au niveau du lo- 7

8 . INTRODUCTION giciel. Maîtriser l'informatique permet d'augmenter les possibilités expérimentales de manière considérable. Mais comment faire pour communiquer avec ces composants et les synchroniser? Par exemple, comment faire dialoguer deux appareils interfacés sur des systèmes d'exploitation diérents? Comment garder une cohérence et une stabilité logicielle lorsque le matériel des expériences est hétérogène et nécessite de fréquentes mises à niveau? C'est la problématique principale de ce projet, réalisé dans le cadre d'un mémoire présenté en vue de l'obtention du diplôme d'ingénieur CNAM. Les objectifs sont de mettre au point une nouvelle architecture informatique de contrôlecommande permettant d'interfacer les diérents instruments que l'on peut rencontrer sur des montages scientiques. Elle doit permettre de développer une logique d'expérience (séquence de mesures et d'actions à réaliser) grâce à une interface homme-machine adaptée. Ce nouveau système doit être évolutif et doit pouvoir être déployé sur divers types de montages. An de tester des solutions et des méthodes, nous avons choisi de nous intéresser à un montage expérimental conçu il y a 15 ans. Les composants mécaniques et certains éléments électroniques ont remarquablement bien vieillis et sont robustes. La faiblesse du montage résidait dans l'interface logicielle développée à l'époque pour coller au mieux aux demandes des scientiques. Le besoin d'évolution de l'expérience impose désormais de modier la philosophie générale de l'architecture informatique. On passe d'une architecture monobloc à une architecture basée sur des composants interchangeables et communiquants. On retrouve ces changements au niveau de l'interface homme-machine. Elle se doit d'être intelligente, c'est à dire comprendre et s'adapter à son environnement qui sont les éléments matériels et logiciels de l'expérience, mais également les utilisateurs. L'interface utilisateur doit être une extension de la pensée du physicien. Qui mieux que le physicien peut savoir quelle commande ou quelle mesure il faut exécuter? Elle doit également proposer des solutions simples et graphiques pour des utilisateurs non expérimentés. Après une présentation du contexte dans lequel s'est déroulé le projet, je vais exposer les études réalisées et la démarche utilisée. Les études sont basées sur des tests et divers logiciels développés ces dernières années sur les expériences de physique du laboratoire. Elles vont nous permettre une réexion profonde sur ce que doit être un système de contrôle commande pour expériences de physique, aussi bien au niveau de l'interface matérielle que de l'interface homme-machine. Elles vont nous permettre de choisir une architecture logicielle. Dans une deuxième partie, je présenterais l'architecture mise en place qui basée sur le système TANGO et le langage de programmation Python. J'exposerais les composants que j'ai développé, et l'interface homme-machine mise au point. Le travail mené lors de ce projet va permettre de mettre en place un système de contrôle commande évolutif et adapté aux demandes des utilisateurs, pour les expériences de physique du laboratoire. 8

9 Première partie Etudes 9

10

11 Chapitre 1 Contexte 1.1 Le laboratoire Le Commissariat à l'energie Atomique Le Commissariat à l'énergie Atomique (CEA) a été créé en 1945 an de poursuivre "les recherches scientiques et techniques en vue de l'utilisation de l'énergie atomique dans divers domaines de la science, de l'industrie et de la défense nationale". Implanté sur neuf centres de recherche répartis dans toute la France, le CEA est un acteur majeur de la recherche sur trois grands domaines : l'énergie, les technologies pour l'information et la santé, la défense. L'énergie Le CEA mène des recherches sur des formes d'énergie compétitives, sûres et propres, en particulier non émettrices de gaz à eet de serre. Il cherche à optimiser le parc actuel des réacteurs nucléaires et à mettre au point des solutions techniques pour la gestion des déchets radioactifs. Il participe aux programmes de recherches internationaux sur les réacteurs et combustibles nucléaires du futur qui assureront une production à la fois plus économique, plus sûre et générant moins de déchets. Il conduit enn des programmes sur l'impact sanitaire et environnemental de l'énergie nucléaire. Les recherches du CEA soutiennent également l'essor des nouvelles technologies pour l'énergie : l'hydrogène, le photovoltaïque, la biomasse... La fusion thermonucléaire, dont la maîtrise pourrait permettre dans l'avenir de disposer d'une source quasi innie d'énergie, est également au coeur de ses recherches. Le CEA est ainsi fortement impliqué dans le projet international du réacteur expérimental ITER. En amont des recherches et développements sur les énergies, il conduit diérents programmes dans les domaines des sciences du climat et de l'environnement, des sciences de la matière, de la chimie et des interactions rayonnement-matière. Les technologies pour l'information et la santé An de favoriser l'innovation industrielle, le CEA dispose d'une recherche technologique de haut niveau dans le domaine des micro et nanotechnologies. Les applications industrielles de ces recherches concernent notamment les télécommunications et les objets communicants. Il 11

12 CHAPITRE 1. CONTEXTE exerce ses compétences dans le domaine des technologies logicielles : systèmes embarqués et interactifs, capteurs et traitement du signal. Grâce aux compétences qu'il développe autour des biotechnologies et des technologies nucléaires pour la santé (marquage biomoléculaire, imagerie médicale...), il est également un acteur de la recherche médicale. Ces programmes appliqués s'appuient sur des recherches de base en nanophysique et ingénierie moléculaire, sciences des matériaux et cryotechnologies. La défense Dans le cadre des lois de programmation militaire, le CEA développe les programmes nécessaires pour garantir la pérennité de la dissuasion nucléaire française. A la suite de l'arrêt des essais nucléaires, il met en oeuvre le programme Simulation, qui s'appuie sur d'importants moyens expérimentaux et de calcul (Airix, Laser Mégajoule, Supercalculateur Tera). En matière de propulsion nucléaire (sous-marins, porte-avions), le CEA est notamment responsable de la conception et de la maintenance des réacteurs. Il intervient enn dans les instances nationales et internationales, où il contribue à la surveillance du respect des traités internationaux tels que le traité d'interdiction complète des essais nucléaires. Il participe à la lutte contre la prolifération des armes nucléaires La Direction des Sciences de la Matière La Direction des Sciences de la Matière (DSM) contribue à approfondir nos connaissances fondamentales sur la structure de la matière, à appliquer ces connaissances dans le domaine de l'innovation industrielle, spécialement dans les secteurs stratégiques pour le pays, à étudier de nouvelles formes d'énergie compatibles avec un développement durable et équitable. Ses diérents laboratoires sont abrités par les Centres d'études du CEA à Saclay, Grenoble et Cadarache, et également par des structures mixtes telles que le GANIL à Caen Le Département de Recherche sur l'état Condensé, les Atomes et les Molécules Le Département de Recherche sur l'état Condensé, les Atomes et les Molécules (DRECAM), département de recherche fondamentale, rassemble 650 chercheurs, ingénieurs-chercheurs et techniciens de la recherche dans 8 Services ou laboratoires de recherche, dont la plupart sont en association avec d'autres partenaires (CNRS, École Polytechnique,...). Ses activités de recherche fondamentales sont orientées vers les technologies de l'information et de la santé, en particulier en nanoscience, et les énergies du futur. Les chercheurs du DRECAM développent et maîtrisent de nombreuses techniques expérimentales à des échelles du nanomètre ou de l'attoseconde, ils sont aussi très présents autour des grands instruments européens Le Service de Chimie Moléculaire Le Service de Chimie Moléculaire (SCM) est un service de recherche fondamentale qui regroupe une cinquantaine de personnels statutaires (CEA, CNRS, université) et une vingtaine d'étudiants de tous niveaux. Les diérentes études qui y sont menées peuvent être rassemblées 12

13 1.2. LA DIFFUSION DES RAYONS X Fig. 1.1 Édices auto-assemblés : structure en sandwich d'un nanodisque ultra-rigide et icosaèdre creux. en deux thèmes majeurs : la nanochimie et la radiolyse, avec comme domaines d'applications principaux, les technologies de la santé, les nanosciences et l'amont de programmes nucléaires du CEA Le Laboratoire Interdisciplinaire sur L'Organisation Nanométrique et Supramoléculaire Le Laboratoire Interdisciplinaire sur l'organisation Nanométrique et Supramoléculaire (LIONS) réunit des chimistes, des physico-chimistes et des physiciens expérimentateurs et théoriciens dans un objectif commun de compréhension de la structure et des propriétés de uides organisés ou de solides nanostructurés. Le laboratoire dispose de cinq appareils de diraction ou diusion de rayons X, possédant chacun des caractéristiques propres qui permettent l'étude de divers systèmes organisés tels que ceux montrés sur la gure La diusion des rayons X Les Rayons X Les rayons X sont une forme de rayonnement électromagnétique dont la longueur d'onde est comprise approximativement entre 0,01 nm et 10 nm. C'est un rayonnement ionisant utilisé dans de nombreuses applications dont l'imagerie médicale et la cristallographie. Production des rayons X Les rayons X peuvent être produits par deux systèmes principaux : 1. Dans un tube à rayons X, des électrons sont produits par un lament chaué et vont percuter une anode généralement en cuivre. Le ralentissement des électrons par les atomes de la cible provoque un rayonnement. 2. Dans un synchrotron (voir gure 1.3), des électrons sont produits par un accélérateur. Un champ magnétique va courber leur trajectoire qui devient circulaire et les électrons vont émettre un rayonnement. Celui-ci est utilisé dans des "lignes de lumière". 13

14 CHAPITRE 1. CONTEXTE Fig. 1.2 Spectre électromagnétique. Fig. 1.3 Schéma d'un synchrotron. Détection des rayons X Les rayons X sont invisibles à l'oeil, traversent des parois opaques, sont stoppés par des matériaux denses (comme les os) et impressionnent les pellicules photographiques. Les principaux détecteurs électroniques de rayons X sont : des scintillateurs qui mesurent les photons X transformés en photons lumineux, des chambres à ionisation qui mesurent le courant induit par l'ionisation d'un gaz suite au passage des photons X, des photodiodes qui transforment l'énergie des photons en courant, des cameras CCD, qui possèdent des matrices de cellules permettant de capter l'information lumineuse sous forme de pixels et transformant ainsi les photons X en image La diraction des rayons X Lorsqu'une onde rencontre un obstacle pas complètement transparent d'une taille relativement petite par rapport à la longueur d'onde, se produit un phénomène d'interférences, appelé aussi diraction. 14

15 1.2. LA DIFFUSION DES RAYONS X la loi de Bragg Un cristal est un solide à structure régulière et périodique, formée d'un empilement ordonné d'un grand nombre d'atomes, de molécules ou d'ions. La conséquence de cette disposition est la formation de réseaux de plans. Les distances interatomiques des cristaux forment des réseaux ecaces pour la diraction des rayons X. La loi de Bragg (voir gure 1.4) dit que les rayons X de longueur d'onde λ sont rééchis à un angle θ par un réseau cristallin possédant une distance d entre deux plans tels que : λ = 2d sin(θ) Rayons X θ d Réseau cristallin Fig. 1.4 A gauche, loi de Bragg (λ = 2d sin(θ)), à droite image de diraction de rayons X sur un cristal Si on connaît la longueur d'onde λ, en mesurant les angles de diraction θ obtenus sur des images de diraction, tels que montrés sur la gure 1.4, on peut calculer les distances interplanaires d qui existent dans le cristal. On peut ainsi mesurer les propriétés structurelles des cristaux. C'est ce que l'on appelle la cristallographie. Si un faisceau de rayons X composé de plusieurs longueurs d'ondes est envoyé sur un cristal très pur (Germanium, Silicium), alors le faisceau rééchi à un angle θ donné correspondra à une seule longueur d'onde λ et sera monochromatique. De tels cristaux sont appelés monochromateurs. Diractomètre Un diractomètre (voir gure 1.5) est un instrument permettant de mesurer la diraction des rayons X. Il est composé en général d'un générateur de rayons X, d'un monochromateur qui permet de sélectionner une longueur d'onde, d'un goniomètre qui permet de mesurer des angles entre les diérents éléments de l'instrument et de positionner un échantillon, et d'un détecteur. Les techniques oertes par les rayons X sont très variées et dépendent du type d'échantillon à analyser ou des informations que l'on veut obtenir. Ainsi, il existe de nombreux types de diractomètres, qui se distinguent par les possibilités oertes de faire varier les angles entre les diérents éléments qui le compose (gure 1.6). Un diractomètre classique permet de réaliser un spectre θ 2θ : on mesure la quantité de rayons X diractés à un angle 2θ, en fonction de l'angle θ incident. On peut également se placer à un angle θ donné et réaliser des mesures autour de l'angle 2θ. Il existe aussi des diractomètres dit à "4 cercles", qui possède quatre 15

16 CHAPITRE 1. CONTEXTE Source de rayons X Monochromateur Détecteur Echantillon θ 2θ Fig. 1.5 Schéma et photographie d'un diractomètre. axes de rotation. Du fait de la complexité ds mouvements les axes des diractomètres sont motorisés et gérés par un système informatique. Source de rayons X Détecteur Source de rayons X Détecteur θ 2θ θ 2θ θ 2θ 2θ constant 4 cercles Fig. 1.6 Diérents types de mouvements sur un diractomètre Technique de diusion des rayons X aux petits angles Les rayons X interagissent également avec les électrons et peuvent fournir des informations sur la uctuation de densités électroniques dans une matière hétérogène (solides, liquides ou gels). Dans ce cas, les rayons X sont diusés à de très petits angles, inférieurs à quelques degrés. La gure 1.7 montre une expérience type : un faisceau monochromatique illumine un échantillon. L'intensité diusée est collectée. Les expériences de diusion de rayons X, telles que décrites au chapitre suivant (p. 23), sont conçues pour mesurer cette intensité à de petits angles, an d'étudier des systèmes de taille caractéristiques de quelques Å à quelques microns. Exemple d'étude réalisée : altération des verres Dans l'objectif du stockage des déchets radioactifs, ceux-ci sont vitriés et conditionnés dans des fûts. Or, le verre s'altère au contact de l'eau et sous de fortes températures, conditions que l'on peut retrouver lors d'un stockage souterrain. La compréhension de l'altération des verres 16

17 1.2. LA DIFFUSION DES RAYONS X Rayons X D:\data\saxs\ot b-octadec-1800.dat.spe Echantillon Rows Faisceau diffusé Columns Fig. 1.7 Schéma de principe de la diusion des rayons X aux petits angles et image obtenue avec un échantillon possédant une structure organisée. 1.E est donc importante pour le CEA. Des études menées au laboratoire 1 ont consisté à accélérer articiellement cette altération et à mesurer l'évolution de la structure du verre au cours du temps. Celle-ci peut être étudiée à l'aide des montages de diusion des rayons X aux petits angles. Sur la gure 1.8, on peut voir les spectres de diusion des rayons X réalisés sur les trois montages du laboratoire, USAXS (Ultra Small Angle X-Ray Scattering), SAXS (Small Angle X-Ray Scattering) et WAXS (Wide Angle X-Ray Scattering) qui permettent de mesurer la diusion des rayons X à des angles diérents, donc des échelles structurelles diérentes. Il a été montré que la structure du verre était diérente après une altération et qu'une couche de gel se forme à la surface des grains. Intensity Verre non altéré Grain de verre t Enveloppe du verre intact Enveloppe du verre altéré Enveloppe du coeur intact Quantité de rayons X diffusés USAXS SAXS WAXS Verre altéré Angle de diffusion Fig. 1.8 Schéma de principe de la diusion des rayons X aux petits angles et image obtenue avec un échantillon possédant une structure organisée. 1 16, Spalla, O., 2003, JOURNAL OF APPLIED CRYSTALLOGRAPHY 17

18 18 CHAPITRE 1. CONTEXTE

19 Chapitre 2 Etude préliminaire 2.1 Gestion du projet - Objectifs Nous avons décidé de conduire ce projet selon une méthodologie propre au CEA. Celle-ci impose de dénir dès le début du projet quatre paramètres : les résultats à atteindre, les délais à respecter, les ressources à mettre en place ou disponibles, et les risques à identier. Des marges de manoeuvre doivent être prévues au lancement du projet. Résultats Ressources Risques Délais Fig. 2.1 Les quatre paramètres à dénir pour un projet selon la méthodologie du CEA Résultats à atteindre Nous avons choisi le montage "Ultra Small Angle X-ray Scattering" (USAXS) qui servira de prototype. L'objectif de ce projet est de mettre au point une nouvelle architecture de contrôle-commande 19

20 CHAPITRE 2. ETUDE PRÉLIMINAIRE qui doit interfacer tous les instruments présents sur le montage existant an d'améliorer le fonctionnement actuel. Il s'agit d'une refonte totale du système informatique et peu d'éléments logiciels seront repris. Le matériel existant sur l'expérience et détaillé sur la gure 2.3 doit être réutilisé et connecté sur une nouvelle machine. Les drivers de tous les éléments, doivent être développés. La nouvelle architecture doit avoir une ergonomie étudiée, permettant le développement facile d'un driver, et l'ajout de nouveaux instruments ou de nouvelles fonctionnalités. L'architecture doit être modulaire et robuste. Dans l'interface homme-machine (IHM), on veut ajouter/modier de nouveaux appareils sans modication majeure de code. Le système développé doit pouvoir être installé et déployé facilement sur d'autres expériences de même type. Il faut concevoir une IHM en fonction des recommandations faites lors de l'étude des possibilités techniques et qui doit pouvoir contrôler le matériel. A partir des outils mis au point, on doit implanter la logique d'expérience USAXS, spéciée par les scientiques spécialistes du montage, dont voici une description sommaire, en pseudo code : #-- Initialisation de matériel #-- Rocking curve à vide Obturateur.Ouvrir ChoisirAttenuateur for angle in (start=-xx,end=xx,step=xx): Moteur2theta.Deplacer(angle)# se déplacer à l'angle theta I=Scintillateur.Mesurer(1s) #mesurer 1s Tracer(angle,I) Moteur2Theta.Deplacer(centre) #-- Mesure de Transmission EnleverAttenuateur Ivide=ChambreIonisation.Mesurer(10s) Obturateur.Fermer Message("Insérez l'echantillon") Obturateur.Ouvrir Iech=ChambreIonisation.Mesurer(10s) Transmission=Iech/Ivide #-- Séquence d'acquisition for angle in (start=-xx,end=xx,step=xx): Moteur2theta.Deplacer(angle)# se déplacer à l'angle theta ChoisirAttenuateur I=Scintillateur.Mesurer(1s) #mesurer 1s Tracer(angle,I) #-- Fin Acquisition Obturateur.Fermer 20

21 2.1. GESTION DU PROJET - OBJECTIFS Tests à réaliser An de vérier et valider les diérents objectifs, voici pour chaque fonctionnalité demandée les moyens/méthodes permettant de mesurer si les objectifs ont été atteints : Fonctionnalités Moyens/méthodes Reprise de l'existant Test du matériel à l'aide des outils basiques fournis par les constructeurs Développement d'une couche d'abstraction Test du matériel avec les outils basiques proposés par la nouvelle couche d'abstraction matériel-logiciel matériel-logiciel. Développement de l'ihm Test du matériel avec les outils proposés par l'ihm. Reprise logique expérience Test du bon fonctionnement de la logique d'expérience sur des échantillons réels. Ergonomie de l'ihm Test de l'ergonomie de l'ihm avec des utilisateurs de diérents niveaux d'interaction. En mode "expert", on va modier la logique d'expérience. En mode "novice", on utilise la logique d'expérience précédente sur des échantillons réels et des utilisateurs novices Robustesse de la CAM et de l'ihm Ajouter de nouveaux matériels sur l'expérience. Le nouveau matériel doit communiquer avec les autres composants du système. L'IHM ne doit pas être modifée. Déploiement sur d'autres expériences On déploie le système sur un autre diractomètre Délais Voici les diérents jalons à atteindre et le calendrier indicatif : Jalons Durée Date objectif État des lieux 1 mois Décembre 2005 Étude d'opportunité 1 mois Janvier 2006 Exploration des possibilités techniques - Etat 1 mois Février 2006 de l'art Rédaction du cahier des charges 1 mois Mars 2006 Développement 3 mois Avril-Mai-Juin 2006 Mise au point et tests 3 mois Juillet-Août-Septembre 2006 Rédaction de la documentation 3 mois Octobre-Novembre-Décembre Acteurs du projet Le responsable du projet est Olivier Taché qui s'occupe des études et du développement. Les chercheurs du laboratoire qui seront les utilisateurs futurs participent à la rédaction du cahier des charges et aux tests. On distingue les utilisateurs experts de l'expérience, qui vont spécier 21

22 CHAPITRE 2. ETUDE PRÉLIMINAIRE la logique d'expérience, et les utilisateurs non spécialistes qui vont spécier les diérents résultats auxquels ils s'attendent. Un responsable CEA valide les orientations stratégiques, tels que les choix de TANGO et de Python, permet de les généraliser au niveau du laboratoire et fournit les ressources nécessaires au déroulement du projet Ressources On dispose pour la réalisation du projet : d'une nouvelle machine de type PC sous Windows, d'un compilateur Microsoft Visual Studio C++ 8, d'une nouvelle carte NI-GPIB, d'une nouvelle carte d'acquisition National Instrument, d'un accès à l'expérience USAXS évalué à 2 jours/semaine (le reste du temps, l'expérience reste accessible pour les expériences) Risques An d'éviter tout problème qui pourrait compromettre le projet ou bien entraîner des délais important, il convient d'identier et d'évaluer les risques. Le risque le plus important est la probabilité non négligeable d'une panne matérielle survenant sur l'expérience. En général les pannes sont résolues dans les cas les plus graves en quelques semaines, mais cela pourrait bloquer la phase de tests. Un autre risque non négligeable serait l'incompatibilité entre le nouveau matériel (PC, nouvelles cartes,...) et le matériel existant sur l'expérience. Par exemple, on peut imaginer que la nouvelle carte GPIB ne pourrait pas communiquer avec les contrôleurs de l'expérience. Il conviendrait alors d'étudier la possibilité de laisser coexister matériel informatique de nouvelle génération avec ancienne génération. Enn, on ne peut pas négliger la diculté à maîtriser le développement des device servers TANGO. Il conviendra alors de prendre contact avec la communauté TANGO (située à Grenoble ou Gif/Yvette) an de bénécier d'une expertise ou d'une formation Marges de manoeuvre Des marges de manoeuvre doivent être prévues dès le lancement du projet an de prévenir les aléas qui peuvent apparaître. Nous disposons de faibles marges au niveau des ressources humaines et des délais. Il est prévu d'améliorer le montage expérimental en n d'année 2006, et le projet doit être opérationnel. Par contre, on dispose de marges au niveau des résultats. En eet, si l'interface avec le matériel doit fonctionner parfaitement, l'ergonomie de l'interface homme-machine n'a pas besoin d'être forcément très poussée, ni de bénécier d'une interface graphique. 22

23 2.2. SUJET D'ÉTUDE 2.2 Sujet d'étude Montage USAXS Fig. 2.2 schéma de l'expérience de diusion de rayons X aux très petits angles Le sujet d'étude choisi par le laboratoire est le montage "Ultra Small Angle X-Ray Scattering" (USAXS). Ce diractomètre permet de mesurer la diusion des rayons X aux très petits angles grâce à un montage original, dont le schéma est montré en gure 2.2 et une photographie en page 97. Les rayons X sont produits par un générateur à anode tournante. Ils sont rendus monochromatiques en se rééchissant sur un cristal monochromateur. Après avoir illuminé l'échantillon, ils se rééchissent encore sur un cristal analyseur qui permet de sélectionner précisément les angles, et sont mesurés par un scintillateur. Un système de motorisation permet de faire varier l'angle (2θ) entre le faisceau incident et le faisceau diusé mesuré. Les possibilités de l'expérience sont aujourd'hui limitées par le système informatique. Il est en eet très dicile de faire évoluer les instruments (ajout de moteurs, mesures automatiques,...) sans eectuer de grosses modications logicielles. An de pouvoir étendre les possibilités des expériences, nous souhaitons rénover le système de contrôle/commande État des lieux matériel Sur l'expérience USAXS, voici l'inventaire des instruments et des diérents matériels électroniques (résumé sur la gure 2.3) : 1. Moteurs : 2α : translation du scintillateur 2α : translation du scintillateur α : rotation 3 cercles de l'analyseur ψ : rotation 3 cercles de l'analyseur 23

24 CHAPITRE 2. ETUDE PRÉLIMINAIRE χ : rotation 3 cercles de l'analyseur 2θ : translation du marbre (induit une rotation) θ : rotation de l'échantillon 2. Détecteurs Scintillateur via SR400 (compteur) Chambre à ionisation 3. Capteurs Codeur Heidenain 4. Actionneurs Atténuateurs Obturateur du faisceau ("shutter") Interface Informatique Carte NI-GPIB Contrôleurs MC1 - IT6D CA2 MC2 - IT6D CA2 MC3 - IT6D CA2 Capteurs Actionneurs 2u u x a a 2a c PC SR400 SR400 Scintillateur Carte E/S num Carte Acquisition Analogique RS232 Atténuateurs Obturateur RX Chambre Ionisation Codeur Heidenain u Fig. 2.3 Schéma détaillé des diérents matériels de l'expérience État des lieux logiciel Logiciels utilisés Le logiciel USAXS3 est programmé en Visual Basic et s'occupe du contrôle des moteurs, de l'acquisition sur le scintillateur, du contrôle des atténuateurs, de la sauvegarde des données, du tracé à l'écran. L'interface utilisateur (sous windows) est identique que se soit pour eectuer des réglages ou pour lancer des acquisitions (ce qui revient souvent au même). Ce programme est très peu modulaire. Si un des éléments est à modier, cela implique de grosses répercussions à travers tout le code. Le programme BH-trait écrit en Quick-Basic permet de traiter les données après acquisition. 24

25 2.3. PROBLÈMES EXISTANTS Ce logiciel récupère les données sauvées par USAXS3 et eectue un traitement numérique (déconvolution) du signal. Il n'est pas possible de récupérer le code source. Protocoles utilisés pour la communication avec le matériel GPIB Le protocole GPIB ("General Purpose Information Interface Bus") permet de commander les moteurs et de réaliser des acquisitions sur le SR400 (appareil qui contrôle le scintillateur). Ce protocole est un standard universellement utilisé pour interconnecter des instruments de mesure (générateurs, oscilloscopes, etc.). Normalisé sous la référence IEEE 488, GPIB est une liaison parallèle à 24 ls avec un débit de 1 Mo/s et qui est capable de piloter 14 instruments, identiés chacun par une adresse. Un ordinateur héberge une carte GPIB qui gère l'ensemble du bus. L'IEEE 488 dénit le protocole de communication entre tous les équipements d'un bus GPIB. Il s'agit d'une interface logicielle dénissant la structure des échanges sur le bus (protocole des contrôleurs, ouverture des lignes, renvoi d'états standards, etc.). C'est un protocole de type question-réponse. La machine envoie une suite de caractères vers l'appareil qui répond. Les séquences de caractères sont spéciées par le constructeur de l'instrument. L'IEEE 488 est désormais sérieusement concurrencée par Ethernet, USB et FireWire. Entrées/Sorties numériques La carte d'entrées/sorties numériques présente sur le système permet de commander l'ouverture et la fermeture des atténuateurs. Acquisition de données analogiques Des mesures sont réalisées à l'aide d'une carte d'acquisition analogique National Instruments. Cette carte permet de convertir des tensions électriques en données numériques exploitables par l'ordinateur. Elle permet de mesurer les valeurs de vide dans les enceintes du montage, et le courant produit par une chambre à ionisation. 2.3 Problèmes existants Interface matérielle et logicielle Les accès aux composants matériels sont incorporés dans le code du logiciel USAXS3. A l'heure actuelle l'ajout de nouveaux composants doit se traduire inévitablement par de grosses modications du code. De plus, le langage utilisé (Microsoft Visual Basic version 4) n'est plus suivi chez le développeur et n'est plus compatible avec les systèmes d'exploitation actuels (Windows XP ou Linux). Cela demande donc de maintenir une conguration logicielle obsolète. Nous sommes aussi à la merci d'une panne matérielle : un composant devant être remplacé par un composant moderne demandera une mise à niveau de la conguration informatique, incompatible avec le logiciel. Ainsi, l'ajout d'éléments matériels ou une mise à jour logicielle signie inévitablement la réécriture complète du logiciel. 25

26 CHAPITRE 2. ETUDE PRÉLIMINAIRE Logique d'expérience Dans le logiciel USAXS3, la logique d'expérience est gée. Il n'est pas possible de la modier. Il est possible d'interagir avec les diérents composants matériels séparément, mais pas de les synchroniser en dehors de la logique programmée Interface HM L'interface homme-machine proposée est programmée en Visual Basic. Comme décrit auparavant, celle-ci n'est pas évolutive. Au niveau ergonomie, on s'aperçoit quelle est soit trop complexe pour un simple utilisateur, soit limitée pour le scientique responsable de l'appareil Problèmes futurs Le système actuel est obsolète et ne permet pas l'ajout de nouveaux composants. Ces nouveaux composants peuvent être matériels (moteurs, capteurs,...) ou bien logiciels (programmes spéciques pilotant un matériel spécique, comme une caméra CCD par exemple). Ils peuvent aussi être connectés à des ordinateurs diérents, sous des systèmes d'exploitation diérents. 2.4 Solutions proposées Gestion des éléments matériels La principale problématique du système existant est que la gestion des éléments matériels est trop dépendante du logiciel. Il faudrait donc séparer ces deux éléments. Les diérents matériels qui composent l'expérience doivent pouvoir être modiés, ajoutés, supprimés, sans aucune répercussion sur l'application nale. Pour cela, il est courant d'utiliser une couche d'abstraction matériel-logiciel (voir gure 2.4) qui "virtualise" les instruments. Par exemple, un capteur de position sera vu comme une variable "position" par l'application et non comme une mesure de tension électrique sur la voie x de la carte n situé sur la machine 1. Cette couche d'abstraction peut également permettre de distribuer les diérents éléments sur un réseau. Une autre problématique est la gestion des diérents protocoles entre les éléments de l'expérience Gestion des éléments logiciels Il apparaît clairement que les protocoles et langages de programmation utilisés et nécessaires au fonctionnement de l'expérience peuvent être variés, voire utilisés sur des machines diérentes. Le nouveau système doit donc permettre de faire communiquer tous les composants matériels et logiciels. 26

27 2.4. SOLUTIONS PROPOSÉES Traitement Numérique Configuration Matérielle Application de physique Couche d'abstraction Matériel-Logiciel Réseau Machine 1 Protocole GPIB Machine 2 Acquisition E/S de Numériques données Contrôleur d'axes moteurs Contrôleur détecteurs Capteurs Actionneurs Fig. 2.4 Schéma de l'architecture du système proposé Interface homme machine Les interfaces utilisateurs proposées doivent correspondre aux demandes des utilisateurs selon leur niveau d'interaction avec le système, qu'il faut dénir. A certains niveaux, l'interface homme-machine (IHM) doit permettre de modier la logique d'expérience aisément. A d'autres, elle doit permettre le déroulement de l'expérience avec le minimum de connaissance du matériel, et acher des informations claires pour un scientique. 27

28 28 CHAPITRE 2. ETUDE PRÉLIMINAIRE

29 Chapitre 3 Présentation des diérents systèmes de contrôle-commande 3.1 Description d'un système de contrôle-commande à base de PC L'acquisition de données et le contrôle des instruments est devenu primordial dans le laboratoire. En général, chaque instrument de physique eectue des mesures ou des actions selon une logique programmée. La logique elle-même est souvent pilotée par un ordinateur de type PC, auquel sont envoyés les résultats (voir gure 3.1) Elements matériels Le type et la vitesse de l'acquisition des données inuent beaucoup sur le type de matériel utilisé. Pour des acquisitions relativement lentes, le contrôle-commande se fait souvent par des instruments dédiés et transmis au PC à travers une connection série RS232. Ce protocole est de type asynchrone et utilise un système de question/réponse : la machine interroge l'appareil Fig. 3.1 L'acquisition de données combine des logiciels et des matériels au sein du PC 29

30 CHAPITRE 3. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES DE CONTRÔLE-COMMANDE Fig. 3.2 Logiciels utilisés pour le contrôle-commande à base de PC qui répond. Il ne peut y avoir de réponse spontanée. Pour des applications plus complexes, on peut utiliser le protocole IEEE 488(GPIB). La communication avec l'appareil nécessite une carte GPIB spéciale. Plusieurs appareils peuvent être branchés simultanément et le débit d'information peut être élevé. La logique d'acquisition est à la charge de l'ordinateur. Il existe aussi des cartes d'acquisition spéciques que l'on insère dans les ordinateurs. Ces cartes possèdent des processeurs embarqués qui permettent des traitement rapides des informations Éléments logiciels Beaucoup d'environnement logiciels permettent d'interfacer tout ce matériel. En général, le constructeur du matériel fournit une application permettant de faire fonctionner immédiatement l'appareil et également quelques "drivers" an de piloter l'appareil par un langage de programmation. Comme montré sur la gure 3.2, dans le domaine du contrôle-commande d'expériences, les langages de programmation les plus répandus sont Labview de National Intruments, Microsoft Visual Basic et Visual C Qu'est ce qu'une couche d'abstraction matériel-logiciel? An d'améliorer la rapidité et la modularité des développements, on peut mettre en place une couche logicielle qui permet au langage de programmation d'accéder à certaines propriétés des éléments matériels en faisant abstraction de la conguration exacte et du protocole de communication utilisé. On appelle cela une couche d'abstraction matériel-logiciel (voir gure 3.3). Par exemple, un appareil mesurant une température et branché sur le PC pourra être interrogé directement par une variable "température". 30

31 3.2. SOLUTIONS COMMERCIALES Langage de programmation Langage de programmation Drivers spécifiques RS232 Couche d'abstraction Drivers spécifiques RS232 t g t g Fig. 3.3 Schéma des briques logicielles permettant d'interfacer les diérents appareils. A gauche, dans un système classique, le langage de programmation doit accéder directement aux drivers ou aux fonctions des appareils. A droite, une couche d'abstraction matériel permet d'accéder aux valeurs physiques (c'est cela qui intéresse l'utilisateur) sans se préoccuper du matériel. National Instruments propose ce type de couche d'abstraction et la nomme Measurement and Control Services, mais cette solution est limitée aux appareils vendus par National Intruments. 3.2 Solutions commerciales National Instruments Description du système proposé par National Instruments La société National Instruments 1 est leader du marché des systèmes d'acquisition basés sur des PC. Elle propose un ensemble de solutions matérielles et logicielles (évidemment compatible entre elles). C'est une des première a avoir introduit cette idée de couche d'abstraction matérielle. En fait chaque matériel vendu (carte d'acquisitions, cartes moteurs, cartes video,...) est piloté avec un ensemble de drivers qui sont uniés et qui proposent une interface simpliée 1 http :// 31

32 CHAPITRE 3. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES DE CONTRÔLE-COMMANDE Fig. 3.4 Copie d'écran du logiciel MAX. On peut y voir sur la gauche que l'on a créé une variable "ChambreIonisation" et sur la droite tous les paramètres matériels de cette mesure avec les valeurs physiques mesurées. Cet ensemble de drivers est nommé Measurement Automation explorer (MAX). Il donne accès à tous les périphériques d'acquisition de données (DAQ), GPIB, contrôle d'axes (moteurs),... de chez National Instruments. Il est également possible de congurer le matériel et les logiciels National Instruments. Le sujet ici n'est pas de décrire toutes les possibilités de cet outil, mais il faut présenter une fonctionnalité intéressante. Cet utilitaire permet de créer des "voies" virtuelles. Grâce à une série d'assistants, on peut dénir une variable (appelée "température" par exemple) en spéciant divers paramètres (emplacement de la carte, brochage, caractéristiques du capteur,...). Au nal, on peut visionner simplement les données mesurées. Les applications de programmation de National Instruments utilisent cette interface et orent des fonctionnalités intéressantes d'achage des données et de contrôle. Une programmation textuelle classique peut être réalisée grâce à LabWindows ou des utilitaires pour Visual Studio (C++, Visual Basic). National Instruments propose une programmation purement graphique avec LabView LabView Le logiciel LabView de National Intruments est un logiciel de programmation graphique qui permet d'interfacer quasiment tous les appareils de contrôle-commande, les constructeurs fournissant souvent les librairies LabView. Principe de fonctionnement de LabView La philosophie de LabView est de programmer à l'aide de diagrammes et d'icônes. Cette logique s'apparente à un schéma électronique et est donc bien adaptée pour les applications 32

33 3.2. SOLUTIONS COMMERCIALES de mesures. LabView utilise une programmation par ux de données, ce ux déterminant l'exécution. Le programmeur ne dispose pas de commandes textuelles, mais dessine son application à l'écran. Dans un premier temps il place des objets et contrôles graphiques (boutons, graphes, zones de saisies,...) sur un panneau appelé "face-avant", comme montré sur la gauche de la gure 3.5, et qui représentera son interface utilisateur nale. Dans un deuxième temps, sur une feuille de diagramme, comme montré sur la droite de la gure 3.5, il relie données issues des objets de la face-avant par des ux de données représentés par des ls, à des composants qui symbolisent les opérations à réaliser. Fig. 3.5 A gauche face avant et à droite diagramme d'une application LabView Caractéristiques importantes Une application LabView est appelée VI (Virtual Instrument) et peut (doit?) être réutilisée comme composant par d'autres applications. Cela rend les programmes très modulaires. Les composants de très bas niveau sont en fait programmés en C et s'exécutent très rapidement. Les composants de haut niveau étant directement programmés en LabView. Les ux de données peuvent s'eectuer en parallèle, rendant LabView multitâche. En dehors de cette programmation par graphiques, l'intérêt majeur de LabView est l'importance des librairies de composants qui concernent en grande partie les applications de contrôle-commande. On y retrouve évidement l'accès au matériel de National Instruments Tests réalisés - Retour d'expérience Nous avons réalisé plusieurs applications grâce à LabView dans le laboratoire. Sur la gure 3.6, on peut voir le diagramme développé pour la commande d'un appareil chargé de contrôler un débit de gaz. Le programme est relativement simple, puiqu'il s'agit d'une boucle cadencée à une certaine fréquence, et qui est chargée d'acher le débit. Lorsqu'une consigne est modié par l'utilisateur, les informations sont transmises au VI, sous-programme, "gaz". Celui-ci est un autre diagramme chargé de communiquer avec l'appareil. L'utilisation des VI permet de masquer les détails à l'utilisateur. Cet appareil n'étant pas fourni par National Instruments, il n'est pas possible de mettre en oeuvre la couche d'abstraction matériel-logiciel décrite précédemment. Il faut développer un code spécique pour chaque appareil. Si ce type de programmation graphique est très performant pour une application de contrôle ou de mesures continues, c'est plus délicat lorsqu'il 33

34 CHAPITRE 3. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES DE CONTRÔLE-COMMANDE s'agit de synchroniser et faire communiquer des appareils qui ont une vie propre. Plus que le type de programmation, textuelle ou graphique, c'est le modèle de programmation qui pose problème. Fig. 3.6 Diagramme d'une application LabView permettant le contrôle d'une vanne de régulation de débit de gaz Conclusion sur les solutions National Instruments LabView se révèle être un logiciel agréable à utiliser et très ecace. Les applications sont développées rapidement sans grandes connaissance en programmation. L'interface graphique est réalisée conjointement à la logique d'expérience. Il est possible d'interagir avec une multitude de matériel grâce à des librairies fournies. Par contre, le code nal est dicile à relire, et la logique d'expérience doit être xée. C'est un logiciel idéal pour une application d'automatisme ou de mesure en continu. Un inconvénient majeur réside également dans le fait que les versions des drivers du matériel National Instruments changent souvent et que le support des anciennes cartes d'acquisition n'est pas assuré. Il en est de même pour les versions de LabView. Une solution basée entièrement sur du matériel et logiciel National Instruments ne serait donc pas stable ou bien nécessiterait de nombreuses mise à jour (logicielles et matérielles) nalement très coûteuses. On dispose d'une couche d'abstraction matériel-logiciel, mais elle est assez limitée. 3.3 Solutions Open Source Description En dehors des solutions proposées par National Instruments, nous avons examiné les solutions proposées dans le cadre des Grands Instruments, installations scientiques de grande ampleur, de nature nationale (SOLEIL), européenne (ESRF) ou internationale (CERN, ITER). Les contraintes imposées, grand nombre de matériel hétérogène, grand nombre de langages de programmation, temps réels..., ne sont évidement pas les nôtres, mais ces solutions peuvent parfaitement convenir. 34

35 3.3. SOLUTIONS OPEN SOURCE Un avantage majeur de ces solutions est la disponibilité du code source et l'utilisation libre dans le cadre d'une activité non-commerciale qui est la nôtre. Une solution appelée TANGO est particulièrement intéressante parce qu'elle est développée conjointement par l'esrf (European Synchrotron Research Facilities), le synchrotron Soleil et d'autres grands instruments Européens (ALBA et ELLETRA), c'est à dire nos collaborateurs scientiques habituels TANGO TANGO est un système de contrôle-commande distribué, orienté objets. C'est un bus logiciel permettant de connecter les objets matériels et logiciels grâce à la technologie CORBA. Les éléments, devices, peuvent être situés sur le même ordinateur ou bien répartis sur des ordinateurs connectés par un réseau. La programmation peut se faire en C++, Java et Python. TANGO fournissant les librairies permettant de masquer les détails d'accès au réseau et permettant d'utiliser les objets. CORBA et la philosophie de TANGO CORBA (Common Object Request Brocker Architecture) est un standard d'objets distribués, indépendant de tout langage. CORBA permet à une application de demander à un objet distribué d'eectuer une opération et d'en obtenir le résultat. C'est une fonctionnalité client/- serveur basique où un client envoie une requête à un serveur et le serveur répond au client. TANGO utilise l'implémentation omniorb de CORBA, qui est disponible librement et "Open Source", c'est à dire que l'accès à son code source est autorisé par son auteur. Les programmeurs peuvent ainsi mettre en place des logiciels dérivés. TANGO vise à cacher les détails de CORBA à l'application nale en fournissant un modèle "device pattern" au programmeur, ainsi que des librairies API (Application Programmer Interface). TANGO fournit également des modèles génériques pour tous les éléments à contrôler, appelés "device servers". An d'avoir une exibilité maximale, TANGO utilise une base de données qui contient les propriétés et méthodes de tous les éléments. TANGO n'utilise que des logiciels disponibles librement. Fonctionnement de TANGO TANGO fonctionne sur le principe d'un bus logiciel. On appelle bus, en informatique, un ensemble de liaisons (câbles, pistes de circuits imprimés, etc...) pouvant être exploitées en commun par plusieurs éléments an de communiquer. Tous les éléments connectés au bus vont pouvoir dialoguer ensemble. Ainsi, les applications de conguration, supervision (surveillance de l'état de certains appareils), interfaces d'expérience,... vont communiquer entre-elles, mais également avec l'ensemble des éléments matériels comme schématisé sur la gure 3.7. Les éléments matériels sont connectés à ce bus grâce à une application serveur appelée "device server" qui possède les interfaces TANGO. Pour chaque device server, le programmeur dispose de méthodes et d'attributs génériques 35

36 CHAPITRE 3. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES DE CONTRÔLE-COMMANDE Configuration Supervision Archivage Environnements utilisateurs: MATLAB, IGOR, python, interfaces Bindings Bus Logiciel TANGO Device Device (mesure ) Hardware Hardware (moteur ) Fig. 3.7 Schéma de principe du bus logiciel de TANGO et peut écrire des méthodes et attributs spéciques. Une partie du code peut être générée automatiquement à l'aide des outils fournis. Il sut d'ajouter le code permettant le contrôle du matériel. Ce code peut accéder au système de contrôle (dll, librairies, commandes RS232, GPIB,...) fournis par le constructeur. Ainsi des matériels hétérogènes peuvent être connectés au bus TANGO et dialoguer ensemble, sans que cette diversité soit visible par l'utilisateur nal, qui dispose de méthodes et attributs bien référencés et accessibles Tests réalisés - Retour d'expérience An d'évaluer les possibilités de TANGO, nous avons réalisé quelques tests d'utilisation, qui ont consisté à installer TANGO, installer quelques serveurs de tests, utiliser les outils fournis, et accéder à un device server à l'aide d'un langage de programmation. Installation de TANGO L'installation de TANGO sera décrite plus en détails au chapitre 6. Elle dépend de la conguration de la machine de test (Windows ou Linux) et de la distribution choisie. Chaque application qui utilise TANGO peut être localisée sur des machines diérentes, ou sur une seule machine. Pour les tests, on a installé toutes les applications sur un seul PC équipé de Windows XP. La base de donnée est installée sur une machine nommée TANGO-HOST. Il est possible alors de lancer des applications de test ou de conguration qui vont se connecter à TANGO-HOST. 36

37 3.3. SOLUTIONS OPEN SOURCE Fig. 3.8 Copie d'écran de l'application JIVE Installation d'un device server L'application Java JIVE (gure 3.8) permet de se connecter au TANGO-HOST et d'installer des device servers. Pour réaliser les tests, nous allons utiliser un programme serveur symbolique "Mouse", qui interface une souris avec TANGO et qui permet de connaître la position du curseur sur l'écran, et d'eectuer quelques opérations basiques, comme de centrer le curseur sur l'écran. Pour cela, nous disposons d'un chier exécutable possédant l'interface TANGO. Avant tout, il faut déclarer cet élément à TANGO-HOST, comme montré en gure 3.9. On demande l'ajout d'un device server, et on spécie son nom (ds_mouse/souris), la classe implémentée dans le code (mouse) et l'arborescence (deviceservers/ds_mouse/souris). Le service est démarré par une ligne de commande telle que : c:\deviceservers\mouse\ds_mouse.exe souris Les propriétés du device server sont alors visibles dans Jive et il est possible d'y accéder par l'intermédiaire d'une autre application Java AtkPanel (gure 3.10). Celle-ci fournie une interface générée automatiquement à partir des propriétés du device server et permet de réaliser des tests sur celui-ci. Ainsi un déplacement de la souris, modie l'achage et peut déclencher une alarme par un changement de couleur. Les procédures d'installation et de conguration des devices servers sont décrites en détail en Annexe E. 37

38 CHAPITRE 3. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES DE CONTRÔLE-COMMANDE Fig. 3.9 Déclaration d'un device server dans JIVE Accès au device server à l'aide de Python On va s'intéresser maintenant à l'accès de ces devices servers par un langage de programmation qui fera l'interface homme-machine. TANGO propose des "bindings", librairies qui permettent d'utiliser TANGO pour les langages C++, Java, LabView, Igor, Matlab et Python (voir chapitre 4.3.2). L'idée est de tester l'utilisation du device server "Mouse" avec Python. Nous avons utilisé le binding PyTango (Python pour TANGO). Le code qui suit permet d'accéder à notre device server "souris", de lire sa position. On peut également lister tous les attributs et les commandes accessibles de cet objet. #--- Import de la librairie et connection au device server from PyTango import * device_name="deviceservers/ds_mouse/souris" tangotest=deviceproxy(device_name) #--- appel simple a un attribut connu X=tangotest.read_attribute("positionX") print "Valeur de la position X : "+ str(x.value) #--- appel simple a une commande connue tangotest.command_inout("center") #--- Liste de tous les attributs et de leurs valeurs print "\nliste des attributs" 38

39 3.3. SOLUTIONS OPEN SOURCE Fig L'application AtkPanel permet d'accéder aux propriétés d'un device server. list_att=tangotest.get_attribute_list() for attribute in list_att: print attribute+" : "+str(tangotest.read_attribute(attribute).value) #--- Liste de tous les commandes accessibles print "\nliste des commandes" list_cmd=tangotest.command_list_query() for i in list_cmd: print i.cmd_name On peut installer TANGO sur une autre machine. Il sut alors de spécier l'adresse du TANGO-HOST, et les applications clientes telles que Jive ou Python accéderont à ce device server de la même manière et de façon transparente Conclusion sur TANGO La solution TANGO est délicate à aborder. Nous sommes loin du confort d'une solution commerciale. De plus, l'écriture du code qui permet de contrôler le matériel, appelé device server est à la charge du programmeur, même si il existe une liste assez fournie de device servers déjà développés. Toutefois, comme les expériences d'utilisation de LabView l'ont montré, il faut toujours développer un morceau de code qui permettra d'utiliser au mieux l'instrument. Pour faciliter les développements, TANGO fournit des outils pour générer des squelettes automatiques pour ce code et le programmeur va pouvoir s'appuyer sur la généricité des device servers. Par exemple, tous les moteurs pourront posséder les mêmes commandes et les mêmes attributs, tout en ayant des interfaces matérielles diérentes. La philosophie de TANGO permet en outre de dénir 39

40 CHAPITRE 3. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES DE CONTRÔLE-COMMANDE des device servers qui sont des ensembles d'autres device servers. TANGO modie le modèle de programmation classique et fait que chaque composant est contrôlé par une application serveur répartie sur le système. TANGO masque ces détails et cela en fait une vraie couche d'abstraction Matériel-Logiciel. Nous avons ainsi la possibilité de réaliser une Interface Homme-Machine dans un langage non imposé. 40

41 Chapitre 4 Présentation des diérents systèmes d'interface homme-machine pour expériences Dans ce chapitre nous allons présenter divers systèmes d'interface Homme Machine (IHM) pour les expériences de physique. 4.1 Spécicités d'une interface Homme Machine pour expériences Une Interface Homme Machine pour expérience de physique est de premier abord identique à une IHM pour une application standard. C'est la nature même de l'application qui la diérencie d'une autre IHM. On peut dénir une expérience de physique comme un ensemble d'éléments matériels de mesure ou d'action (moteurs) interagissant ensemble en respectant une certaine logique. Un fonctionnement logique de l'expérience est nécessaire an de pouvoir ordonner des processus en fonction de conditions précises. Si on se place dans le cadre d'un ensemble de matériel xe avec une logique expérimentale xe, l'ihm ne pose pas de problèmes particulier, et sera construite de manière classique. La contrainte est toutefois plus forte pour une IHM d'expérience de physique : les éléments matériels et la logique expérimentale peuvent varier. Celle ci doit être construite de manière "intelligente" : elle doit comprendre et s'adapter aux conditions qui l'entourent. Dans le domaine des IHM d'expériences de physique, plusieurs approches de philosophies diérentes sont utilisées : des interfaces graphiques et des interfaces avec ligne de commande. 4.2 Solutions à interface graphique Ce que l'utilisateur attend d'une interface graphique c'est une représentation à l'écran des éléments et de leurs propriétés. L'utilisateur doit pouvoir faire varier ces propriétés en les ordonnant selon la logique de l'expérience. 41

42 CHAPITRE 4. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES D'INTERFACE HOMME-MACHINE POUR EXPÉRIENCES Source de rayons X Monochromateur Fentes θ Echantillon Détecteur 2θ Quantité de rayons X mesurée Angle 2θ Fig. 4.1 Schéma de principe du diractomètre SIEMENS qui permet d'obtenir un spectre indiquant la quantité de rayons X diractés par l'échantillon en fonction de l'angle 2θ Exemple d'ihm Penons pour exemple l'ihm qui permet de contrôler un diractomètre SIEMENS, qui est vraiment symbolique des problèmes posés et des solutions qui sont trouvées. Cet appareil est un diractomètre. On envoie un faisceau de rayons X avec un certain angle thêta sur un échantillon et on mesure le faisceau rééchi avec un autre angle 2thetha. On obtient un spectre d'intensité en fonction de thêta, qui donne des informations sur la structure de l'échantillon. L'instrument (voir gure 4.1) est composé d'un certain nombre d'éléments (source de rayons X, fentes, détecteur, support échantillon) qui sont motorisés. Chaque élément peut être déplacé d'un certain angle et le mouvement peut être synchronisé avec un autre élément. La logique expérimentale n'est pas xe : l'utilisateur doit pouvoir choisir les éléments qu'il veut faire bouger et mesurer avec le détecteur. Même si cette logique est souvent identique pour un type d'expérience, lors d'une phase de réglage, elle est à l'appréciation de l'utilisateur. L'IHM fournie avec l'appareil est présentée en gure 4.2. Elle montre la solution trouvée par le développeur. On propose à l'utilisateur un certain nombre de choix de mouvements possibles. Sur la partie gauche de l'interface, l'utilisateur spécie les moteurs qu'il désire déplacer, ainsi que l'angle de déplacement. Les mouvements réalisés dépendent du type de séquence de mouvement ("scan") demandé. Le résultat (quantité de rayons X mesurée en fonction de l'angle imposé) est tracé à l'écran sur la partie centrale. Cette interface est ecace pour une logique expérimentale typique (mesure de diagramme, c'est à dire Intensité en fonction de l'angle). Dans le cadre d'autres mouvements, l'interface n'est pas ergonomique, l'utilisateur a du mal à comprendre les choix proposés. Cette IHM ne peut pas s'adapter si le matériel est modié, et propose une interface complexe pour une utilisation simple et inecace pour une utilisation complexe. 42

43 4.2. SOLUTIONS À INTERFACE GRAPHIQUE Fig. 4.2 Copie d'écran de l'application XRD Commander, qui sert à piloter le diractomètre SIEMENS Langage de programmation graphique : LabView Comme expliqué dans le chapitre 3, LabView de National Instruments est fréquemment utilisé pour des systèmes informatique d'expériences. LabView simplie l'interfaçage avec le matériel 43

44 CHAPITRE 4. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES D'INTERFACE HOMME-MACHINE POUR EXPÉRIENCES grâce à un grand nombre de librairies et permet de développer l'ihm en même temps que le reste de l'application. LabView propose aussi de nombreux objets de contrôle graphique. Pourtant LabView ne permet pas de s'adapter automatiquement à un changement de matériel. De plus, la logique expérimentale ne peut être modiée. Il faut proposer à l'écran toutes les possibilités oertes à l'utilisateur. Cela peut donner une interface complexe et chargée comme proposée en gure Visual Basic Le langage de programmation Microsoft Visual Basic est très utilisé dans le domaine du contrôle-commande d'expérience du fait de sa relative simplicité et de son environnement de développement intégré. Celui-ci réunit tous les outils nécessaires à la création d'applications, comme la saisie du code et le placement des contrôles graphiques. Visual Basic permet de développer des interfaces évoluées, mais comme avec LabView, il faut proposer à l'utilisateur toutes les actions possibles, ce qui peut produire une interface complexe. Par exemple, on a réalisé une IHM pour un diractomètre expérimental sur lequel il fallait synchroniser des mouvements ("scan") et des acquisitions sur une caméra CCD. La gure 4.4 montre les possibilités oertes à l'utilisateur pour réaliser un "scan", déplacement d'un moteur (rotation ou translation) et paramètres de mesure sur une image. On obtient au nal une interface compliquée. La programmation de cette interface nous permet de tirer des enseignements intéressants : nous avons besoin d'une IHM qui peut s'adapter à l'environnement matériel du montage expérimental et qui puisse prendre en compte des paramètres compliqués et variés pour les actions ou mesures à réaliser. Dans ce cas, si Visual Basic est très pratique, n'étant pas orienté-objet il ne permet pas de s'adapter à des éléments non dénis au préalable. Par exemple, il ne peut pas générer une interface graphique dynamiquement, en fonction par exemple de la liste du matériel Java Le langage Java, est un langage de programmation orienté objet, développé par Sun Microsystems. Il n'est pas très utilisé dans le domaine du contrôle-commande, car assez complexe à maîtriser : les programmeurs d'ihm d'expériences sont souvent des scientiques qui développent les applications pour leurs besoins spéciques. Par contre, ses possibilités en programmation d'ihm sont intéressantes : il existe de nombreuses librairies graphiques et il est possible de générer dynamiquement une interface graphique. La gure 3.10 (voir page 39) montre l'application ATK Panel qui est une application Java et qui utilise les fonctionnalités de TANGO pour créer une interface graphique en fonction des propriétés et opérations possibles sur un objet matériel. Au niveau de l'achage de la logique expérimentale, il faudrait également proposer toutes les actions possibles à l'utilisateur, ce qui n'est pas très satisfaisant. 44

45 4.2. SOLUTIONS À INTERFACE GRAPHIQUE Conclusion Fig. 4.3 Interface générée grâce à LabView. Les exemples précédents nous permettent de bien dénir les besoins et les attentes d'un utilisateur envers une IHM d'expérience de physique : 45

46 CHAPITRE 4. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES D'INTERFACE HOMME-MACHINE POUR EXPÉRIENCES Fig. 4.4 Interface créée grâce à Visual Basic. En bas, le contenu des onglets permettant de paramétrer un scan 1. Acher de manière graphique et dynamique les éléments présents sur l'expérience. Pouvoir modier leur propriétés et lancer des commandes basiques. 2. Pouvoir modier la logique d'expérience de manière simple en achant le résultat de manière graphique Si les solutions à interfaces graphiques sont bien adaptées pour contrôler des éléments matériels, elles n'arrivent pas à proposer des méthodes simples pour acher/modier les logiques d'expériences. 4.3 Solutions à ligne de commande Depuis des années, cette question d'interfaçage de la logique expérimentale est posée dans le cadre des grands instruments et du pilotage des diractomètres. Une solution à base de ligne de commande a émergé et a conquis un public de scientiques. 46

47 4.3. SOLUTIONS À LIGNE DE COMMANDE SPEC SPEC est un langage de macro pour UNIX/Linux développé par Certied Scientic Software 1 depuis SPEC permet grâce à un interpréteur de saisir des commandes de manière textuelle. L'interface graphique, montrée sur la gure 4.5, est composée d'une fenêtre de saisie et d'une ou plusieurs fenêtres d'achage des données sous forme de graphe. Fig. 4.5 Copie d'écran de SPEC : fenêtre de saisie des commandes, et fenêtres d'achage graphique des données Les commandes sont très simples. Par exemple, la programmation de mouvements des moteurs d'un diractomètre se fait de la manière suivante : mv moteur1 0 déplace le moteur moteur1 en position 0 ct 1 eectue une mesure pendant 1 seconde et l'ache scan moteur déplace le moteur de la position -0.4 à 0.4 avec 40 pas, à chaque pas, mesure pendant 1 seconde et trace la courbe mv moteur1 CEN déplace le moteur au centre de la courbe Les commandes peuvent être sauvegardées dans des chiers macros. Ainsi l'utilisateur garde une sauvegarde exacte des commandes exécutées pour eectuer une mesure ou un type d'expé- 1 http :// 47

48 CHAPITRE 4. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES D'INTERFACE HOMME-MACHINE POUR EXPÉRIENCES rience. SPEC propose une grande quantité de macros dédiées aux calculs à partir des données expérimentales. Les macros sont en grande partie élaborées et diusées librement par les utilisateurs de SPEC. Malgré tout, SPEC est un logiciel commercial avec un système de licence annuelle payante, ce qui freine toute amélioration logicielle. D'autre part, le logiciel n'est pas multi-plateforme : il est uniquement disponible sous Unix. Le langage de macro utilisé interdit l'utilisation de types de données évolués : chaque variable doit être explicitement déclarée, mais n'est pas typée et il est impossible de générer d'autres variables dynamiquement. De plus, chaque variable a une visibilité globale dans tout le programme, ce qui peut poser des problèmes lors d'appels de fonctions : une variable a peut être écrasée par une fonction utilisant une autre variable a. Autre limitation : SPEC ne peut pas générer d'interface graphique. Malgré une mauvaise ergonomie dûe au fait que l'utilisateur doit connaître la syntaxe des commandes, un avantage majeur d'un système basé sur des lignes de commandes est la possibilité laissée à l'utilisateur de modier la logique expérimentale. En ce sens SPEC est très bien adapté. Ce langage peut se connecter au système TANGO mais chaque modication matérielle, correspondant à un ajout de variable doit au préalable être déclarée, limitant par là les possibilités Python Python, développé depuis 1989, est un langage de programmation orienté objet. Les qualités de ce langage dans le domaine du contrôle-commande sont les suivantes : Python est "Open Source", Python est portable, il peut être utilisé sur des machines Windows, Linux, Mac OS, Python peut appeler facilement des applications et librairies programmées dans d'autres langages (C, C++, Fortran, Java, DLL Windows,...), Python est orienté objet, Python possède une interface en ligne de commande, tout en permettant la création d'applications indépendantes, Python peut interfacer de nombreuses librairies graphiques (Tk, Qt, Qtk,...), de nombreuses bibliothèques scientiques sont disponibles, la syntaxe est très facile et les types de données sont évolués, Python permet d'interfacer TANGO (voir chapitre 3.3.2) Exemple : Pour illustrer ces propos, voici un petit script basique permettant d'interfacer l'application présentée en gure 4.2 et qui permet de piloter le diractomètre SIEMENS : #--- Connection au diffractomètre et appel à la librairie DLL --- meas=win32com.client.dispatch('meashost.diffractometer') meas.connect("diffractometer!drec-ea ") #--- On va initialiser le moteur "tube" tube=drives.item("tube") 48

49 4.3. SOLUTIONS À LIGNE DE COMMANDE % #--- Initialisation du détecteur detectors=meas.detectors #--- Initialisation de l'obturateur Shutter=meas.TubeWindow Dans ce programme, Python utilise les librairies Windows fournies par l'application du diffractomètre. #--- On change la tension du générateur de rayons X g=meas.generator g.voltage=30 g.current=20 On peut accéder aux diérents composants à l'aide de simples variables. #--- Quels-sont les moteurs disponibles? drives=meas.drives drives.count #print all the drive names for d in drives: print d.name On peut connaître le nombre de composants moteurs présents sur l'appareil. #--- Ouverture de l'obturateur Shutter.Open #--- Scan : on déplace le moteur "tube" et on réalise un comptage for p in range(60,20,-1): tube.position=p print p,detectors[0].rate(1) En quelques lignes, il est possible de réaliser un "scan" qui va synchroniser un mouvement d'un moteur et un comptage sur un détecteur. Python étant un langage de programmation, les possibilités d'action sur l'appareil sont alors innies. Contrairement à SPEC, il n'existe pas de commandes spécialisées pour le contrôle-commande pour le langage Python. Cela reste à la charge du développeur. Mais Python est capable de générer dynamiquement des interfaces graphiques. De plus, ce langage n'est pas dédié au domaine du contrôle-commande et est très employé pour les applications scientiques. L'utilisation de ce langage pourrait orir des perspectives de calcul scientique sur des appareils et mesures. 49

50 CHAPITRE 4. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES D'INTERFACE HOMME-MACHINE POUR EXPÉRIENCES 50

51 Chapitre 5 Conclusion - choix Cette première partie nous a permis de présenter les possibilités techniques et l'état de l'art dans le domaine du contrôle-commande d'expériences de physique. Il est clair désormais qu'un système intelligent s'adaptant à son environnement, c'est à dire à l'expérience, doit comporter une couche d'abstraction matériel-logiciel et une interface hommemachine. Pour la couche d'abstraction matériel-logiciel, une solution basée sur TANGO présente des possibilités très intéressantes et très puissantes, mais nécessite un apprentissage et une programmation des interfaces, appelées "device servers". Il faut utiliser alors un système de device servers qui soit réutilisables et modulaire. Pour l'ihm, si une solution d'interface graphique, à l'aide de Java ou Python, permet de Aide Ergonomique (Python) CONFIGURATION Interface graphique (Java,Python) LOGIQUE D'EXPERIENCE Interface en ligne de commande (Python) TANGO DEVICES SERVERS (C++, Python) Fig. 5.1 Schéma représentant les diérents éléments de l'application proposée. piloter des appareils, ce n'est pas du tout ecace pour programmer la logique d'expérience. On préférera plutôt une interface en ligne de commande grâce à Python. Il faudra cependant développer un système d'aide en ligne ou aide graphique ergonomique an de guider l'utilisateur. 51

52 CHAPITRE 5. CONCLUSION - CHOIX Je propose donc une architecture logicielle en pile, comme montrée sur la gure 5.1, et reposant sur les fonctionnalités du système TANGO et de CORBA. Chaque composant est basé sur un composant de plus bas niveau et rend un service à un composant de niveau supérieur. Les composants peuvent être programmés dans des langages diérents, conformes à CORBA, et adaptés aux besoins. On utilisera Python et/ou Java pour l'interface graphique ou le calcul scientique et C++ pour l'interfaçage matériel. 52

53 Deuxième partie Réalisations 53

54

55 Chapitre 6 TANGO 6.1 Fonctionnement général de TANGO Les systèmes classiques de contrôle-commande pour des expériences de physique sont en général basés sur un programme maître (voir gure 6.1) qui contrôle tous les composants matériels ou logiciels de l'expérience. An de pouvoir réutiliser les composants logiciels, les accès se font par des appels à des librairies qui peuvent implémenter les diérents protocoles de communication avec les appareils. Ces librairies peuvent êtres utilisées sur tout le système. Par exemple, le logiciel LabView présenté au chapitre fait un usage important de composants réutilisables. Une telle architecture peut conduire à des problèmes complexes. Lors de l'ajout ou la modication de composants, ces mises à jour doivent être répercutées à travers tout le système. De même, le système doit gérer l'accès simultané lorsque plusieurs applications communiquent avec le même appareil et demandent des actions contradictoires. Séquenceur A B C Moteur A Détecteur Mesure Fig. 6.1 Architecture de contrôle commande classique Ainsi sur des expériences de physique se pose très vite le problème de l'accès à des équipements qui peuvent êtres variés (détecteur, moteurs, actionneurs, capteurs,...) et connectés sur des machines diérentes. On aimerait pouvoir ajouter/enlever/modier les équipements de l'expérience, sans revoir le système informatique. On veut pouvoir communiquer avec chaque appareil, que ceux-ci puissent communiquer entre eux, tout en gardant une certaine exibilité. 55

56 CHAPITRE 6. TANGO Le système TANGO a été développé à l'european Synchrotron Research Facility (E.S.R.F). L'objectif principal est de résoudre le problème de lecture et écriture sur des équipements distribués. C'est un système basé sur CORBA, qui permet de dénir une interface entre les objets et le système. Les actions dénies par cette interface peuvent être des attributs ou des commandes. Le fait d'invoquer une action sur un objet provoque un appel distant vers cet objet ou bien un appel de fonction si l'objet n'est pas distant. TANGO fonctionne à la manière d'un bus logiciel qui permet à tous les composants du système de dialoguer ensemble, comme montré sur la gure 6.2. Séquenceur Interface TANGO Base de données Interface TANGO Bus logiciel Tango Interface TANGO Interface TANGO Interface TANGO Moteur Détecteur Mesure Fig. 6.2 Architecture de contrôle-commande utilisant TANGO Il ore également un modèle de programmation. L'idée de ce modèle est de traiter chaque composant, "device", de l'expérience comme un objet possédant ses propres propriétés, attributs et commandes, et également des commandes et attributs génériques, comme schématisé sur la gure 6.3. Un device peut être un instrument, un élément matériel, simple moteur par exemple, un ensemble d'éléments matériels, groupe de moteurs, ou bien un programme de calcul, voire une combinaison de tout cela. Un "device server" (DS) est un programme serveur qui fonctionne en permanence et qui répond aux demandes d'actions (services) sur les "devices" par des programmes clients. Chaque élément du système, base de données comprise, est un device server et donc un composant indépendant. Les appels aux librairies sont incorporés dans le code du device server, qui gère les demandes d'accès simultanés. Les devices sont reliés entre eux grâce CORBA et identiés dans le système avec un nom tel que : usaxs/motors/theta_motor. Le nommage des devices est laissé à l'appréciation de l'utilisateur. Dans la suite du chapitre, tous les exemples feront référence à ce device theta_motor qui permet de contrôler un des moteurs de l'expérience USAXS. Chaque device server implémente la même interface CORBA, ce qui facilite les développements et permet la mise en commun de certains attributs, comme son état, son nom, sa description. Chaque device server dispose également de fonctions d'administration distante comme l'arrêt, 56

57 6.1. FONCTIONNEMENT GÉNÉRAL DE TANGO Bus Logiciel TANGO Génériques Init State Status Commandes Spécifiques On Off Interface CORBA Génériques Attributs Spécifiques - position Propriétés spécifiques Nom du Server Gpib Système de contrôle fournisseur (dll, librairies, commandes RS232,...) Device Server Fig. 6.3 Les diérentes parties d'un "device server" le redémarrage, la réinitialisation,... Un DS est dénit comme une classe qui possède des propriétés : propriétés de la classe (titre, commentaires,...) propriétés du device (données utilisées pour la conguration du device server lors de son démarrage) Commandes (actions à réaliser sur le device) Attributs (propriétés qui peuvent être modiées lors de l'exécution et qui peuvent conduire à réaliser des actions sur le device) Etats (qui reètent l'état de fonctionnement du device) Une base de données permet d'enregistrer chaque DS ainsi que ses propriétés. Elle rend ces informations disponibles à travers le système. Chaque attribut possède également des propriétés (unité, format d'achage, commentaires, description,...) qui sont dénis et modiables dans la base de données. Il est possible de demander un stockage des valeurs pour chaque attribut, an de garder un historique. TANGO permet aussi le déclenchement d'événements. Un DS peut déclencher un événement et ainsi avertir d'autres DS du changement d'un état où d'une valeur d'attribut. Les types de données échangeables dans le système TANGO (entiers, réels, tableaux, chaînes de caractères,...) sont prédénis et sont issus de types de données de CORBA. De la même manière, les états des device servers sont prédénis et correspondent à diérents états que l'on peut retrouver dans un système de contrôle commande : ON, OFF, MOVING, FAULT, ALARM,... A chaque état est associé une couleur (vert pour ON, blanc pour OFF,...) que l'on retrouve dans les diérentes interfaces graphiques développées pour les tests, ou monitoring (comme Astor p64, AtkPanel p39, ou Synoptic p64) 57

58 CHAPITRE 6. TANGO Les applications clientes ne s'adressent plus véritablement à un matériel mais à un programme serveur. En ce sens, le système TANGO constitue une véritable couche d'abstraction matériellogiciel. 6.2 Installation de TANGO Les pré-requis à l'installation de TANGO sont les suivants : installation de l'implémentation de CORBA en OpenSource, OmniOrb 1, installation de Java 2, pour l'exécution des applications utiles à la conguration de TANGO, sur une machine nommée TANGO-HOST, il faut installer un serveur de base de données MySql, qui est une base de données Open Source 3. Lors de l'installation, il faut déclarer MySql en tant que service Windows qui s'exécute automatiquement. Sur une machine cliente, il faut déclarer une variable d'environnement TANGO-HOST contenant le nom de la machine qui héberge la base de donnée. Les tables de la base de données sont créées par un petit script. La base de données MySql s'exécute alors en tâche de fond. Elle va accepter toutes les requêtes des applications TANGO. L'équipe TANGO fournit un exécutable pour Windows qui va installer TANGO, ainsi que toutes les librairies nécessaires. Il faut ensuite congurer un certain nombre de variables d'environnement, comme le nom de TANGO-HOST par exemple, ou le chemin de OmniOrb, Fonctionnement d'un device server Un device server peut être écrit en langage Java ou bien en C++, qui sont tout deux des langages compatibles avec CORBA. Tous les device servers développés dans ce projet ont été développés en C++, pour des raisons de compatibilités avec les librairies des diérents matériels à interfacer. Il est désormais possible d'en développer en langage Python. Un device server utilise un modèle de programmation appelé "device pattern". Ce modèle comporte deux classes principales. La classe deviceimpl implémente CORBA et permet d'initialiser le DS en se connectant à la base de données. La classe deviceclass implémente tout ce qui est spécique au device, comme les commandes, les attributs,... La compilation du device server donne naissance à un chier exécutable qu'il faut enregistrer sous un nom d'instance dans la base de données TANGO. Dans un même chier exécutable, il est possible de créer plusieurs instances d'un même device ayant des propriétés diérentes et pouvant contrôler des matériels diérents. Ainsi comme montré en gure 6.4, trois matériels du même type donneront trois instances du même device server dans un seul exécutable. Le chier exécutable peut être réutilisé sur d'autres machines, mais enregistré sous un nom d'instance diérent. 1 disponible sur http ://sourceforge.net/projects/omniorb 2 version Java 2 Standard Edition disponible sur http ://java.sun.com/j2se/ 3 http ://dev.mysql.com/ 58

59 6.4. DÉVELOPPEMENT D'UN DEVICE SERVER Exécutable Instance Device Nom du device Motor.exe Machine 1 Motor_usaxs Classe motor theta 2theta alpha usaxs/motors/theta_motor usaxs/motors/2theta_motor usaxs/motors/alpha_motor Motor.exe Motor_Saxs passeur saxs/motors/passeur_motor Machine 2 Classe motor Fig. 6.4 Fonctionnement d'un device server Un device server peut également posséder plusieurs classes, c'est à dire qu'il peut implémenter des devices diérents dans un même serveur. Cela permet de regrouper dans un seul exécutable plusieurs types de devices qui sont liés ensemble. Par exemple, comme schématisé sur la gure 6.5, un device server MotorGPIB implémente une classe du protocole GPIB et une classe Motor contrôlant un moteur qui a besoin du protocole GPIB. Les connexions entre les diérents devices, se font dans un même exécutable par des appels de fonctions. Ce type d'implémentation est transparente pour l'application nale, qui accède aux device servers normalement. Exécutable Instance Device Nom du device MotorGPIB.exe Motor_MC Classe motor Classe protocole GPIB GPIB1 theta GPIB2 2theta usaxs/config/gpib1 usaxs/motors/theta_motor usaxs/config/gpib2 usaxs/config/2theta_motor Fig. 6.5 Implémentation de plusieurs classes dans un même device server 6.4 Développement d'un device server Pour développer un device server en C++ on peut utiliser le générateur de code POGO (phase de conception), puis le code source généré est modié dans un éditeur (phase de codage). 59

60 CHAPITRE 6. TANGO Le générateur de code POGO Le générateur de code Pogo est un outil très pratique pour la mise au point des device servers TANGO. Cette application propose une interface qui permet de dénir les propriétés, attributs, commandes, et états d'un device server, comme montré sur la gure 6.6. Une fois tous ces éléments dénis, on peut demander la génération du code C++ ou Java, ainsi que la documentation. Celle-ci est générée à partir des informations fournies. Les device servers ont ainsi tous une documentation uniforme. Pogo vérie si des modications du code ont eu lieu entre chaque génération. Le développeur peut alors modier le code source dans une autre éditeur (Microsoft Visual C++ par exemple) et retourner ensuite dans Pogo. Fig. 6.6 Capture d'écran du générateur de code Pogo. Au nal, sont générés 2 chiers C++ pour l'implémentation du device server et 5 chiers pour l'implémentation des classes. Par exemple, pour le device server de la gure 6.6 qui ne possède qu'une classe, sont générés les chiers suivants : main.cpp ClassFactory.cpp MCMotor.cpp MCMotor.h MCMotorClass.cpp MCMotorClass.h 60

61 6.4. DÉVELOPPEMENT D'UN DEVICE SERVER MCMotorStateMachine.cpp Implémentation du code Pour la mise au point nale et la compilation, nous avons utilisé Microsoft Visual C++ version 6. Sous environnement Windows, les librairies TANGO nécessitent cette version de compilateur, qui semble la plus stable. En pratique, seuls les chiers MCMotor.cpp et MCMotor.h sont modiés. Déclarations Dans le chier.h gurent toutes les déclarations des fonctions et variables qui sont implémentés dans le chier.cpp. Ci-dessous un extrait du chier MCMotor.h généré par Pogo : // Here is the Start of the automatic code generation part // /** attributes * Attributs member data. */ TANGO::DevDouble *attr_position_read; TANGO::DevDouble attr_position_write; TANGO::DevDouble *attr_zero_read; TANGO::DevDouble attr_zero_write; /** * name device properties * device properties member data. */ /** name of the gpib device server */ string gpibservername; /** * Number of the axis on the MC rack (1 is down 2 is upper */ TANGO::DevShort axisnumber; /** IT6CA2Motor methods prototypes */ /** * reset the memorized faults on the hardware if necessary DevFailed */ void reset(); 61

62 CHAPITRE 6. TANGO Les propriétés gpibservername et axisnumber du device server sont déclarées comme de simples variables, et utilisables en tant que tel. De la même façon, les commandes, par exemple reset(), sont déclarées et utilisables comme de simples fonctions. Les attributs disponibles sont accessibles par l'intermédiaire de deux variables, pour lecture-écriture. Par exemple attr_position_read et attr_position_write pour l'attribut position. Initialisation Le device server est initialisé dans la fonction init_device(). Ici doivent gurer les tests de validation des propriétés. Ces propriétés sont modiables uniquement lors de la déclaration du device server dans la base de données, grâce à l'application Jive comme décrit au chapitre Ici, sont également allouées les variables d'attributs. Connection à d'autres device servers Les device servers peuvent se connecter à d'autres device servers, dont les noms sont spéciés à l'aide des propriétés (telles que gpibservername). La connection se fait par l'intermédiaire de fonctions de la classe DeviceProxy. Il est alors possible de demander la réalisation de commandes et de lire/écrire des attributs. L'exemple suivant permet d'exécuter la commande WriteRead sur un device server implémentant le protocole GPIB. gpib_server_proxy = new Tango::DeviceProxyHelper(gpibServerName,this); gpib_server_proxy->command_inout("writeread",argin,argout); Commandes Lorsque l'utilisateur déclenche une demande de commande sur le device server, c'est la fonction correspondante qui est exécutée. Il peut y avoir des arguments en entrée et/ou en sortie. La fonction suivante reset() stoppe les mouvements du moteur et réinitialise les achages des positions. // /** * method: IT6CA2Motor::reset * * description: method to execute "Reset" * reset the memorized faults on the hardware if necessary * * */ // void IT6CA2Motor::reset() { DEBUG_STREAM << "IT6CA2Motor::reset(): entering...!" << endl; // Add your own code to control device here // stop the movements ans set to zero indicators and positions // gpib command must be : C1O 'o' letter string cmd; cmd="c"+xstring<short>::converttostring(axisnumber)+"o\n"; 62

63 6.4. DÉVELOPPEMENT D'UN DEVICE SERVER write_command(cmd); } Attributs Lorsque l'on veut modier ou lire un attribut, les fonctions read_attribute() ou write_attribute() sont exécutées. Le passage des valeurs se fait par l'intermédiaire d'objets WAttribute et Attribute. Ainsi, la lecture d'un attribut position se fait de la manière suivante : // // // method : IT6CA2Motor::read_position // // description : Extract real attribute values for position acquisition result. // // void IT6CA2Motor::read_position(TANGO::Attribute &attr) { *attr_position_read = read_gpib_position(); attr.set_value(attr_position_read); } La fonction read_gpib_position() permet de lire la position sur le matériel. C'est ici que le développeur insère les appels aux librairies ou les diérents protocoles permettant de communiquer avec le matériel. // // // method : IT6CA2Motor::write_position // // description : Write position attribute values to hardware. // // void IT6CA2Motor::write_position(Tango::WAttribute &attr) { DEBUG_STREAM << "IT6CA2Motor::write_position(Tango::WAttribute &attr) entering... "<< endl; std::string cmd; Tango::DevDouble future_position; string movement_str; // write the position attr.get_write_value(attr_position_write); future_position=attr_position_write; // convert position given in string movement_str=convert_to_mc_digit(future_position); // gpib command must be : I1=+xxxxxx! 63

64 CHAPITRE 6. TANGO cmd="i"+xstring<short>::converttostring(axisnumber)+"="+movement_str+"!\n"; write_command(cmd); } 6.5 Développement d'un device server 6.6 Utilisation Jive Jive est une application client qui permet de gérer les device servers en se connectant à la base de donnée TANGO. On peut ajouter de nouveaux DS, modier leur propriétés et eectuer des tests sur des attributs et commandes. Il est également possible de générer diérentes instances d'un même serveur : à partir d'un seul exécutable, plusieurs serveurs peuvent coexister. L'interface (voir gure 6.7) se découpe en deux parties : à gauche, l'arborescence de la base de donnée TANGO, et à droite, l'état du device server selectionné. Par un menu contextuel, on peut modier ses propriétés (voir gure en page 75), ses attributs, ou réaliser des tests. En annexe, on trouvera la procédure permettant de déclarer un device server grâce à Jive. Ces fonctionnalités sont importantes et démontrent les possibilités du système TANGO à installer simplement un matériel virtuel Astor Lorsque le device server est enregistré dans la base de données et correctement conguré, l'exécutable serveur tourne en permanence. On utilise l'application Astor an d'automatiser les démarrages et arrêts des serveurs. Par l'intermédiaire d'une interface, montrée en gure 6.8, on peut déléguer à Astor le démarrage automatique des device servers. L'ordre de démarrage peut être hiérarchisé an de respecter les dépendances des serveurs. Les exécutables sont alors considérés comme des "services" Windows. Les services sont des programmes qui s'exécutent au démarrage de Windows. Par la suite ils continuent de fonctionner. L'interface Astor permet de les arrêter et de les relancer Synoptique L'application JDraw, présentée sur la gure 6.9 est programmée en Java. Elle utilise des composants graphiques nommés ATK qui permettent de représenter génériquement des attributs et commandes de device servers TANGO. Elle permet de placer ces composants dans une fenêtre. Lors de l'exécution grâce à un Viewer, il est possible de visualiser les valeurs de ces attributs, avec des couleurs qui reètent les états des DS. Le rafraîchissement de l'achage se fait toutes les secondes, mais est paramétrable. On peut également eectuer des actions sur les DS grâce à des boutons. Ainsi on réalise facilement un synoptique, représentation graphique d'une expérience, sans aucune ligne de programmation. 64

65 6.7. CONCLUSION Fig. 6.7 En haut, écran principal de l'application Jive. En bas, écran de test 6.7 Conclusion Du fait de sa relative complexité, TANGO est de premier abord dicile à maîtriser. En eet, il existe de nombreux paramètres à spécier pour une installation correcte, un modèle de 65

66 CHAPITRE 6. TANGO Fig. 6.8 Interface de l'application Astor Fig. 6.9 Interface de l'application JDraw. programmation à comprendre, de nombreuses applications utilisant des langages diérents... Mais nalement, le programmeur peut se concentrer sur le développement de son device server et bénécie de l'aide du générateur de code Pogo et du grand nombre d'applications clientes, telles que JDraw, Jive, Astor, qui facilitent les tests. L'utilisation du langage Python permet de simplier le développement des serveurs. Le code est plus clair et compact, les erreurs de 66

67 6.7. CONCLUSION compilation sont oubliées. On trouvera un exemple de device server écrit en Python en Annexe (p. 104). Le système basé sur CORBA est très performant et les diérents composants interagissent parfaitement, même s'ils sont situés sur des machines diérentes, ou utilisent des protocoles de communication (GPIB, RS232,...) diérents. 67

68 68 CHAPITRE 6. TANGO

69 Chapitre 7 Architecture de device servers 7.1 Description générale Dans le modèle TANGO décrit au chapitre précédent, un device server est décrit comme un programme serveur communiquant avec un matériel (device) ou bien un programme de calcul, ou bien un ensemble de tout cela. Les device servers peuvent être également clients d'autres device servers. Dans notre architecture on s'est attaché à être modulaire et exploiter ces possibilités an de pouvoir réutiliser les serveurs. Si on veut proposer des fonctionnalités de haut-niveau à l'utilisateur ou bien à une application scientique, un device server doit implémenter un protocole de communication avec l'instrument, une interface de contrôle du matériel et une interface utilisateur. On peut développer Interface Utilisateur Haut niveau Interface Matériel Niveau intermédiaire Interface de communication Bas niveau Matériel Fig. 7.1 Schéma de principe de la chaîne de devices servers des device servers évolués et communiquant directement avec les instruments et l'utilisateur. On peut aussi développer toute une chaîne de serveurs dépendants les uns des autres, mais simples et paramétrables, comme schématisé sur la gure 7.1. Dans la communauté TANGO les deux approches cohabitent. Nous avons choisi la deuxième méthode. Pour que chaque device server soit modulaire, on va 69

70 CHAPITRE 7. ARCHITECTURE DE DEVICE SERVERS utiliser au maximum les possibilités de paramétrage des propriétés des serveurs. En général sur tous les devices de niveaux élevés, il faudra spécier le nom du serveur dont ils dépendent. On peut distinguer, comme schématisé sur la gure 7.2 : des serveurs que l'on appellera "bas niveau" et qui communiquent directement avec les appareils ou implémentent des protocoles de communication (RS232, GPIB), les serveurs de "niveau intermédiaire" qui sont l'interface logicielle du matériel, les serveurs de plus "haut niveau" qui permettent de virtualiser le matériel ou bien d'eectuer des calculs. Ainsi, pour le contrôle des moteurs, le protocole GPIB est géré par un device server GPIB, l'interface avec le contrôleur Micro-Contrôle par un DS dédié, et sur le haut de la pile, un DS permet de convertir les pas moteurs en radians ou en mm. De la même manière, la mesure sur des jauges à vide réalisée par une carte National Instruments est gérée par un device server d'acquisition, qui est lui-même serveur d'un DS permettant de convertir les données. Evaluateur d'expression (pas moteurs radians) Evaluateur d'expression Volts mbar Haut niveau Contrôleur Moteurs Niveau intermédiaire GPIB NiDAQ (acquisition) Bas niveau Rotation Jauge à vide Fig. 7.2 Chaîne des device servers pour le contrôle de moteurs, ou pour la mesure d'une jauge à vide. La communauté TANGO maintient à jour une liste de devices servers accessibles librement 1. Certains des devices servers qui suivent sont des adaptations de device servers existant (interface GPIB ou PicoAmpèremètre). Les autres sont des "créations originales" et également mis à disposition de la communauté TANGO à travers un site Internet Device servers de bas niveau Les serveurs de bas niveau communiquent directement avec le matériel ou bien implémentent un protocole de communication et fournissent un service aux serveurs de plus haut niveau. Dans notre application, ils s'appuient sur les DLL fournies par les fournisseurs de matériel. Ces serveurs sont fondamentaux puisqu'ils sont la base de tout le système. Ils sont généralement réutilisés pour communiquer avec diérents appareils. 1 http :// 2 http ://www-drecam.cea.fr/scm/lions 70

71 7.2. DEVICE SERVERS DE BAS NIVEAU radians vecteur d'onde Evaluateur mathématique pas moteur radians Evaluateur mathématique Contrôleur IT6DCA2 GPIB Device Moteurs Micro-Contrôle Devices Servers Ampère picoampère V mbar Evaluateur mathématique Evaluateur mathématique Filters Shutter Contrôleur SR400 PicoAmpèremètre Keithley 615 GPIB Device GPIB Device Single Analogic Input Digital Input-Output Digital Input-Output Contrôleur SR400 Pico Ampèremètre Jauges à vide Atténuateurs Obturateur RX Matériel Fig. 7.3 Carte complète de tous les devices servers utilisés pour l'expérience USAXS Interface GPIB Le serveur GPIB implémente les fonctionnalités des DLL pour les cartes GPIB de National Instrument. Tout d'abord, il s'assure que la communication peut s'eectuer avec le matériel, 71

72 CHAPITRE 7. ARCHITECTURE DE DEVICE SERVERS qui est identié par une adresse GPIB. Dans ce cas il ore comme service la possibilité d'envoyer une chaîne de caractère au matériel, et retourne la réponse. Ce serveur permet de dialoguer avec les contrôleurs de moteurs Micro-Contrôle, avec les contrôleurs SR400, puis le pico-ampèremètre Keithley 615. Il y a en tout neuf device servers GPIB. C'est le seul device server qui n'a pas été développé au laboratoire Acquisition Analogique simple Le serveur SingleAI pour "Single Analogic Input" utilise les DLL Ni-Daq fournies par National Instruments. Il permet de réaliser une acquisition simple sur une voie de la carte National Instruments. Les cartes National Instruments permettent de réaliser des acquisitions de données sur diérentes "voies" dont le nombre, le débit,... dièrent. Il existe selon les cartes des entrées-sorties analogiques et entrées-sorties numériques. Pour ce montage, nous avons expérimenté un nouveau système d'acquisition, appelé CompactDAQ et composé d'un boîtier relié par connection USB à l'ordinateur et dans lequel il est possible d'insérer des modules d'acquisition, de génération de tension ou d'entrée/sortie numérique,... On peut voir une photographie de ce système en p. 99. Comme expliqué auparavant lors de la description du système National Instruments, ces drivers sont "uniés" : normalement un unique driver permet de piloter pour toutes les cartes du catalogue. Mais nous avons été amené à utiliser diérentes générations de cartes, et qui n'utilisaient pas les mêmes versions de drivers. Il existe des drivers NI-DaqOld et Ni-DaqMx... An d'avoir un device server qui puisse s'adapter à ces deux possibilités, j'ai implémenté les appels aux diérentes versions de DLL. On aurait pu développer deux device servers diérents avec le risque d'avoir des fonctionnalités diérentes, et d'induire l'utilisateur en erreur. Le paramétrage des propriétés permet de spécier la version de driver. Des device servers pour ces cartes orent de nombreuses possibilités et peuvent intéresser potentiellement beaucoup d'utilisateurs. Le serveur réalise une acquisition "simple" sur une seule voie de la carte. Les propriétés du device server permettent de spécier la voie utilisée de la carte, le gain d'acquisition,... En pratique ce serveur est très utile. Grâce à l'utilisation combinée de Jive et Astor, qui permet le démarrage et conguration d'un device server, il est possible d'ajouter la réalisation de mesures à travers l'expérience en quelques secondes. Celles-ci sont prises en compte par le système instantanément, orant des possibilités intéressantes (enregistrement sur de longues durées, achage de synoptique,...) Sortie Analogique simple Lors des tests nous avons eu besoin de générer une tension analogique sur une carte National Instruments et nous avons développé un serveur Single AnalogicOuput. Celui-ci reprend les fonctionnalités du device serveur précédent, mais en génération de signal. 72

73 7.3. DEVICE SERVERS DE NIVEAU INTERMÉDIAIRE Entrées-Sorties Numériques Les cartes National Instrument permettent également de réaliser des entrées-sorties numériques. Nous avons donc développé de la même manière un device server "DigitalIO" (pour Digital Input-Output). Celui-ci tient compte des diérentes versions de drivers. Il permet en outre de spécier quelles voies numériques sont utilisées en entrée ou sorties. Une conversion binaire-entier est oerte. Un attribut acceptant un nombre entier est donc accessible, orant un service qui sera utile aux serveurs de plus haut-niveau. Par exemple le nombre binaire 1001 sera convertit en base décimale par Device servers de niveau intermédiaire Les serveurs de niveau intermédiaire s'appuient sur des serveurs de bas-niveau an de communiquer avec le matériel. Ils sont en fait une interface logicielle dèle des contrôleurs d'instruments et reprennent si possible toutes leurs fonctionnalités. Les serveurs développés pour le montage USAXS sont au nombre de trois : Controleur IT2DCA6 pour moteurs Micro-Contrôle Contrôleur SR400 pour comptage sur scintillateur picoampèremetre Keithley 615 (développé initialement par Soleil et modié pour tenir compte de certaines possibilités du matériel) Nous n'allons pas décrire ici toutes les fonctionnalités de ces DS, puisqu'ils ont le reet exact du fonctionnement des contrôleurs. On retrouvera la documentation de ces device servers en annexe. 7.4 Device servers de haut niveau Les serveurs de haut niveau s'appuient sur certaines fonctionnalités des serveurs de niveaux plus bas et pour orir une interface générique à l'utilisateur. L'idée est d'avoir une interface unique pour chaque type d'instrument rencontré, quelque soit l'implémentation matérielle. Cela apporte ainsi une vraie abstraction du matériel au système. Pour notre application nous avons identié trois besoins fondamentaux d'interfaces génériques : une interface d'obturateur de rayons X ("shutter"), une interface pour les atténuateurs qui se rapproche d'un système de positionnement de ltres, une conversion de valeur mesurée ou matérielle à l'aide d'un évaluateur d'expression mathématique Shutter Un obturateur ("shutter") de rayons X est un dispositif qui obture le faisceau. Il peut exister plusieurs types d'obturateurs, mais on peut dénir deux actions ouvrir et fermer ainsi que les états associés. Le device server shutter correspondant aura deux commandes génériques open et close, les 73

74 CHAPITRE 7. ARCHITECTURE DE DEVICE SERVERS deux états associés plus un état intermédiaire moving, s'il existe un temps de latence entre l'ouverture et la fermeture. Le paramétrage des propriétés du device server, vont nous permettre d'associer les commandes et états à un attribut à lire ou à écrire sur un serveur de plus bas niveau. Cela permet ainsi d'utiliser ce serveur générique avec des dispositifs d'obturation variés. Shutter optocoupleur Open-Close Digital Input-Output 0V-5V 0V-5V R Open-Close Obturateur RX Fig. 7.4 Device server shutter permettant de déclencher l'ouverture de l'obturateur du générateur des rayons X par l'intermédiaire d'une entrée-sortie numérique et d'un optocoupleur An de déclencher l'ouverture et la fermeture de l'obturateur de notre générateur de rayons X, nous allons utiliser ce serveur comme montré sur la gure 7.4. Celui-ci va modier la valeur de l'attribut d'un device server Digital Input-Output contrôlant une sortie numérique et permettant de commander un optocoupleur. Un optocoupleur est un circuit électronique qui permet, entre autre, de réaliser un interrupteur numérique : si une tension électrique est appliquée à ses bornes, le circuit est fermé. Dans le cas inverse, le circuit est ouvert Filtres Sur les expériences de rayons X, un atténuateur est un élément matériel, constitué la plupart du temps par une feuille de matériau déni (par exemple 100 µm de Nickel), qui permet d'atténuer la puissance du faisceau de rayons X avec une constante connue. Sur l'expérience USAXS, il existe un système composé de 4 atténuateurs qui peuvent s'insérer séparément, tous ensemble, ou en combinaison. Cela fait donc une combinaison de 2 4 = 16 possibilités d'atténuation. Le dispositif montré en gure 7.5, est contrôlé par une carte d'entrées-sorties numériques qui permet d'activer ou non un atténuateur. On l'interface grâce à un device server DigitalIO (voir p. 73). Des photographies du dispositif sont montrées en page 100. An de pouvoir utiliser un serveur générique, on peut considérer ce système comme un système de positionnement où chaque élément a une position bien déterminée, numérotée, et possédant des caractéristiques uniques. Ces informations ne changent jamais. Ce device server que l'on a appelé "lters" (ltres) peut être réutilisé si le système d'atténuateur est modié (remplacé par un carrousel par exemple) ou bien pour un système de positionnement d'échantillons. Lors de l'initialisation, le device server va charger un chier qui contient les données concernant la position matérielle, l'identiant et la constante d'atténuation. Lorsque l'utilisateur demande le positionnement d'un atténuateur, il le fait en spéciant l'identiant. Le serveur va alors 74

75 7.4. DEVICE SERVERS DE HAUT NIVEAU Filters 0-5V Rayons X Digital Input-Output Atténuateurs Attenuateurs Fig. 7.5 Device server lters permettant contrôler les atténuateurs chercher la correspondance et demander le positionnement sur un device server de plus bas niveau qui interface le matériel. De cette manière, on a pu ordonner les diérentes combinaisons d'atténuateurs en fonction de leur constante d'atténuation. L'utilisateur s'aranchit alors de la connaissance exacte du matériel et dispose de commandes qui lui permettent de passer d'un atténuateur au suivant ou précédent Evaluateur d'expression mathématique Fig. 7.6 Copie d'écran de l'interface Jive permettant de modier les propriétés d'un device server. Dans notre cahier des charges, nous avions la volonté de permettre à l'utilisateur scientique d'accéder aux valeurs physiques de l'expérience. Pour ce faire, il faut convertir des valeurs d'attributs en d'autres unités spéciées par l'utilisateur. Nous avons développé un device server qui permet d'évaluer des expressions mathématiques dont les variables sont des attributs d'autres devices servers. 75

76 CHAPITRE 7. ARCHITECTURE DE DEVICE SERVERS Fonctionnement Ce serveur utilise des librairies C++ qui permettent d'évaluer des expressions mathématiques pouvant contenir plusieurs variables. Par l'intermédiaire des propriétés (voir gure 7.6), il faut spécier : les expressions Expression_read et Expression_write (une pour la lecture et une autre pour l'écriture) sous forme de chaîne de caractères, les attributs serveurs AttributeName_read et AttributeName_write auxquels on accède, la liste des noms de variables utilisés. A l'initialisation du serveur les expressions mathématiques sont converties en un objet C++ exploitable. Lorsque l'utilisateur demande la lecture ou l'écriture de l'attribut Value, l'évaluation est réalisée. Alors, le device server écrit ou lit les attributs distants spéciés. Utilisation Sur le montage USAXS, on veut mesurer les valeurs du vide des enceintes à l'aide de plusieurs jauges à vide. Les capteurs génèrent une tension électrique comprise entre 0 et 10 Volts en fonction de la valeur de vide, mesurée en mbar. Le fournisseur de l'appareil donne la formule mathématique suivante, qui permet de convertir les Volts en mbar : P mbar = 10 6 (log(p mesure) + 3) où p mesure est la valeur mesurée en Volts et P mbar la pression en mbar. Les mesures sont réalisées avec un device server "SingleAI" qui contrôle une carte d'acquisition National Instruments. En combinaison avec le device server d'acquisition analogique, on a pu ajouter le "monitoring" des jauges à vide et le rendre accessibles en unités scientiques aux utilisateurs et aux autres applications clientes du système (comme l'achage du synoptique). Avec ce device server, le système permet une réelle abstraction du matériel. L'utilisateur interagit désormais avec l'expérience à l'aide d'unités scientiques sans avoir à connaître les détails de l'implémentation du matériel. 7.5 Conclusion Cette architecture à trois niveaux, permet une grande exibilité dans l'utilisation des devices servers. Ils sont facilement réutilisables. La gestion des serveurs se fait de manière graphique à l'aide de Jive. Il est possible d'ajouter à un serveur des devices, dont on modie les propriétés. Cette architecture permet d'orir une interface générique à l'utilisateur et de préserver cette couche de haut-niveau, même si les devices servers de niveaux plus bas sont modiés. En eet, ceux-ci sont directement concernés par une modication du matériel, mais il sura de modier les propriétés des serveurs de haut-niveau pour que tout fonctionne sans changement pour l'utilisateur nal. On pourra ainsi remplacer un instrument de mesure par autre (possédant un protocole de communication diérent), et simplement modier les propriétés des devices servers de haut niveau. 76

77 Chapitre 8 Interface Homme-Machine 8.1 Description générale et cahier des charges L'interface développée est composée d'une fenêtre principale de saisie des commandes et de fenêtres d'achage des données sous forme de graphiques, comme montré sur la copie d'écran en p. 90. Elle est réalisée grâce au langage Python dont l'interpréteur nous servira de fenêtre de saisie des commandes. On peut aussi exécuter les programmes de manière classique et les résultats s'acheront de la même façon mais il ne sera pas possible d'interagir avec le système. L'architecture mise en place est montrée en gure 8.1 et se compose de plusieurs librairies Python. Pour communiquer avec le système TANGO, on peut utiliser la librairie pytango. A l'usage cette librairie se révèle assez lourde à utiliser et nous avons développé des librairies de plus haut-niveau, pytangodevice et pytangobeamline, qui permettent de manipuler les devices comme des objets Python. Au niveau de la logique d'expérience, nous avons donc développé des modules pour réaliser des scans et des enregistrements. Un scan permet d'exécuter une ou plusieurs actions de manière incrémentale puis récupérer et acher le résultat graphiquement. Un enregistrement permet d'eectuer des mesures ou des relevés régulièrement ou bien en nombre déterminé. 8.2 Documentation La documentation des modules est réalisée conjointement au développement : Python propose un outil qui génère la documentation d'un objet en fonction des commentaires placés dans le code. Il sut de taper la commande help(objet) pour obtenir une aide en ligne dans l'interpréteur. Par exemple, voici l'aide générée pour le module scan : >>> help(scan) Help on class Scan in module scan2: class Scan class Scan 77

78 CHAPITRE 8. INTERFACE HOMME-MACHINE Scan pytangobeamline pytangodevice Enregistrements Interface Homme-Machine pytango Bus logiciel Tango Fig. 8.1 Architecture mise en place pour l'interface homme-machine Offer the posibilities to do some actions and scientific measures synchronously. Results are print to screen and can be plot with gnuplot in real time. Methods defined here:... Elle peut aussi être générée au format html. Il est également possible d'obtenir des informations sur les objets en saisissant simplement leur nom dans l'interpréteur (voir p. 79). 8.3 Accès à TANGO An de rendre les explications plus claires, tous les exemples qui vont suivre dans ce chapitre feront référence à un même device server usaxs/motors/theta_motor. Les exemples de code montrés peuvent être saisis directement dans l'interpréteur Python, dans ce cas là ils sont précédés de >>>, ou bien exécutés comme des programmes classiques. Ce device server permet de piloter un moteur et possède 4 attributs : position qui représente la position du moteur (quand cette valeur est modiée, l'ordre est donné au moteur de se déplacer à la nouvelle valeur), zero qui représente la position du zéro moteur, position servant de référence aux déplacements du moteur (cette valeur peut être modiée, mais elle est juste mémorisée par le système, et n'a aucune incidence sur le mouvement du moteur), State qui renvoie un entier correspondant à l'état du device server tel que déni par TANGO, Status qui renvoie une chaîne de caractère décrivant explicitement l'état, et plusieurs commandes dont findreferenceposition qui demande au moteur de se déplacer en position de référence. 78

79 8.3. ACCÈS À TANGO pytango La librairie pytango est développée par l'équipe de TANGO. Cette librairie permet de faire un lien entre les librairies de TANGO et le langage Python. Les possibilités sont les suivantes : se connecter à la base de donnée TANGO, l'interroger et connaître la liste des device servers, ainsi que leur propriétés (attributs, commandes,...) se connecter à un device server et exécuter une commande, interroger ou modier un attribut Si cette librairie fonctionne très bien, elle se révèle nalement lourde à utiliser dans l'interpréteur Python, puisqu'il faut saisir 2 lignes de code pour lire un attribut et 3 pour écrire un attribut, comme le montre les exemples suivants. Import du module pytango et connection au device server : >>> from pytango import * >>> theta=deviceproxy("usaxs/motors/theta_motor"') Après importation de la librairie et connection au device server, lecture d'un attribut : >>> attribut=theta.read_attribute("position") >>> print attribut.value Ecriture de cet attribut : >>> attribut=theta.read_attribute("position") >>> attribut.value=0.0 >>> theta.write_attribute(attribut) A l'usage cette syntaxe est lourde, et nous avons développé des librairies de plus haut niveau qui permettent de manipuler les devices servers comme des objets Python et qui simplient les lectures/écritures des attributs pytangodevice Utilisation Le module pytangodevice permet de se connecter facilement à un device server à partir de son nom (voir chapitre 6) et de le manipuler aussi simplement qu'un objet Python classique. Les attributs sont utilisés comme des variables et les commandes comme des fonctions. Reprenons l'exemple précédent en utilisant cette librairie : >>> from pytangodevice import * >>> theta=pytangodevice("usaxs/motors/theta_motor") >>> theta -- TANGO device Binding to : usaxs/motors/theta_motor -- * Added attributes : zero, position, * Added methods : Reset(), On(), Off(), Velocity_slow(), Move(), Stop(), Init(), FindReferencePosition(), Velo * Added methods : State(), Status(), waitstateon() and get_attribute() for each attribute Current device state is : ON 79

80 CHAPITRE 8. INTERFACE HOMME-MACHINE L'appel de la classe pytangodevice créée un objet qui possède des attributs et des commandes identiques au device server. Ainsi la lecture d'un attribut se fait comme un appel de variable : >>> theta.position 0.0 l'écriture également : >>> theta.position=1000 l'execution d'une commande : >>> test.findreferenceposition() ou bien pour connaitre l'état du moteur : >>> theta.state() pytango.devstate.on Fonctionnement Le module utilise les fonctionnalités orientées objet de Python qui permettent d'aecter une fonction à une variable. Par exemple, on peut aecter une fonction x(y) à une variable a : >>> def x(y): return x*x >>> x(2) 4 >>>a=x >>>a(2) 4 Lors de la phase d'initialisation de la classe, Python se connecte à la base de données TANGO et récupère la liste de tous les attributs et méthodes du device server. Pour chaque attribut, une variable (dont le nom est identique) est créée qui correspond à une fonction eectuant la lecture et/ou écriture de l'attribut. Lors de l'appel de cette variable, Python exécute automatiquement les fonctions getattr et setattr qui vont a leur tour exécuter les appels aux fontions du module pytango (tels que décris p ). Pour chaque commande, la fonction correspondante est aectée. Des méthodes State() et Status() sont crées automatiquement pour chaque device. Problèmes soulevés et réponses La philosophie de TANGO fait que lorsqu'une action est demandée à un device server, celui-ci peut changer d'état indiquant que l'action est en cours ou terminée mais le serveur "rend la main" immédiatement. Pour savoir si le serveur a terminée l'action, le client doit l'interroger à nouveau. Si on veut séquencer les actions sur les device servers, il faut donc attendre que les actions soient nies. Une fonction waitstateon() est donc dénie pour chaque device server. Par convention, nous avons décidé que lorsque l'action est en cours, le serveur est dans un état intermédiaire (déni par TANGO selon le type de device server) comme MOVING, FAULT,... 80

81 8.3. ACCÈS À TANGO L'action terminée, le device server bascule dans un état ON. La fonction waitstateon() se contente donc d'interroger le serveur jusqu'à ce que celui-ci soit dans l'état ON. Or certains appareils peuvent être submergés par un trop grand nombre de requêtes State. Une variable WAIT_TIME qui dénit un temps de latence entre deux requêtes et initialisée à 0.3 s peut donc être modiée. Un autre problème survient lorsque l'on veut aecter une variable-attribut de notre classe à un autre objet Python. Celle ci est interprétée comme un appel à l'exécution de la fonction getattr et non pas à une aectation de variable. Par exemple, on lit l'attribut de la manière suivante : >>> theta.position 0.0 mais si on aecte cette variable-attribut à un autre objet Python, c'est logiquement la réponse de l'exécution de la fonction qui lui est aecté : >>> theta.position=1000 >>> a=theta.position >>> a >>> theta.position=0 >>> a Il est donc impossible de passer une variable-attribut par "référence". On pourrait utiliser les fonctions getattr (nom_attribut) et setattr (nom_attribut), qui font partie du langage Python, mais nous avons jugé préférable (par convention des noms commençant et nissant par représentent des membres privés de la classe) de créer une référence de fonction set_nomattribut() et get_nomattribut() pour chaque attribut, ce qui se traduira pour notre exemple à l'ajout des fonctions set_position() et get_position(). En langage Python, un nom de variable ne peut pas commencer par un chire. Or cette restriction ne s'applique pas à TANGO (programmé en C et Java). Un device server peut donc posséder des attributs ou commandes dont le nom commence par un chire. Pour contourner ce problème, on décide que chaque fois que cela sera nécessaire, la lettre "t" commencera les noms de variables Python. Par exemple, l'attribut 2theta pourra être accédé par la variable t2theta. En principe, le fait que les noms de variables dièrent entre un device server TANGO et sa représentation Python n'est pas très gênant : l'utilisateur doit normalement accéder à TANGO avec l'interpréteur Python. Conclusion Finalement, chaque device server est représenté par un objet Python qui possède : pour chaque attribut, une variable correspondante, et deux fonctions permettant la lecture et/ou écriture de l'attribut, pour chaque commande, une fonction correspondante, 81

82 CHAPITRE 8. INTERFACE HOMME-MACHINE une fonction State(), une fonction Status(), une fonction waitstateon() pytangobeamline Fonctionnement L'utilisateur dispose désormais d'une représentation Python d'un device TANGO. On veut maintenant accéder à tous les appareils disponibles sur l'expérience (donc déclarés dans la base TANGO). On utilise pour cela le module pytangobeamline. Le fonctionnement de ce module est relativement simple, il se connecte à la base de données TANGO, et à partir d'un mot clé spécié par l'utilisateur, il va rechercher tous les devices correspondants dont le nom contient ce mot clé. Cela permet de lister une branche de l'arbre des device servers 1. Pour chaque élément trouvé, on va générer un objet pytangodevice. Exemple : >>> usaxs=beamline("usaxs") Welcome to usaxs... Connected to TANGO... L'achage de la variable usaxs donne un état de l'expérience : >>> usaxs found : usaxs/angles/2alpharad ->t2alpharad : ON found : usaxs/angles/2thetaq ->t2thetaq : ON found : usaxs/angles/2thetarad ->t2thetarad : ON found : usaxs/angles/alpharad ->alpharad : ON found : usaxs/angles/chirad ->chirad : ON found : usaxs/angles/phirad ->phirad : ON found : usaxs/angles/theta ->theta : ON found : usaxs/counter/flux ->flux : UNKNOWN found : usaxs/counter/flux_pico ->flux_pico : UNKNOWN found : usaxs/counter/sr400_1 ->sr400_1 : STANDBY found : usaxs/filters/attenuators ->attenuators : ON found : usaxs/motors/2alpha_motor ->t2alpha_motor : ON found : usaxs/motors/2theta_motor ->t2theta_motor : ON found : usaxs/motors/alpha_motor ->alpha_motor : ON found : usaxs/motors/chi_motor ->chi_motor : ON found : usaxs/motors/phi_motor ->phi_motor : ON found : usaxs/motors/theta_motor ->theta_motor : ON found : usaxs/shutter/shutter ->shutter : CLOSE found : usaxs/vacuum/back ->back : ON found : usaxs/vacuum/front ->front : ON found : usaxs/vacuum/generator ->generator : ON 1 Par convention, on décide que tous les device servers présents sur une même expérience doivent être rassemblés sur une branche de l'arborescence des devices TANGO. 82

83 8.4. INTERFACE LOGIQUE D'EXPÉRIENCE L'utilisation est identique à celle de pytangodevice, et se fait par l'intermédiaire d'un objet PyTangoBeamline : >>> usaxs.theta_motor.position Interface logique d'expérience Environnement scientique Par défaut, le langage Python n'est pas ourni avec des modules scientiques. Pour une utilisation poussée, il faut installer des modules complémentaires : Numerical Python ore un nouveau type de tableau sous forme de matrices, ainsi que des fonctions et outils mathématiques permettant de les manipuler, Scientic Python est une collection de modules pour le calcul scientique, Gnuplot permet de bénécier d'un achage scientique sérieux des données. Gnuplot Gnuplot 2 est un logiciel de "tracé" de données scientiques très complet possédant une interface sobre, mais ecace, basée sur la ligne de commande. Contrairement à de nombreux logiciels, Gnuplot sépare l'achage graphique et les données, qui sont enregistrées dans des chiers. L'achage est spécié par l'utilisateur, soit par l'intermédiaire de la ligne de commande, soit à l'aide d'un chier de macros. Il est ainsi possible de tracer des graphes selon un modèle rigoureux, déni par l'utilisateur, avec des données diérentes. Un grand nombre de modèles de graphiques est disponible. La commande plot 'c:\gnuplot\ds a.dsm' commande le tracé d'un graphe à partir des données enregistrées dans le chier DS A.dsm. Le résultat graphique est montré en gure 8.2. L'usage de Gnuplot est répandu parmi les chercheurs qui sont familiers avec la syntaxe. Interface avec Python Grâce à un module nommé Gnuplot.py, ce logiciel s'interface rapidement avec Python et on dispose de méthodes permettant d'y accéder et de lancer des commandes. La manière la plus classique de l'utiliser est d'enregistrer les données dans un chier et de donner l'ordre à Gnuplot de les tracer. Il est également possible d'eectuer des tracés à partir de données sous forme de tableaux Python. L'intérêt principal de l'utilisation de Gnuplot est de se décharger de l'achage des résultats. L'exemple suivant montre l'utilisation de ce module, et permet de tracer la courbe de la gure 8.2 précédente. import Gnuplot # Initialize Gnuplot 2 http :// 83

84 CHAPITRE 8. INTERFACE HOMME-MACHINE Fig. 8.2 Tracé des données enregistrées dans un chier g = Gnuplot.Gnuplot() g.plot("'c:\gnuplot\ds a.dsm'") Enn, l'achage graphique est paramétrable à volonté en fonction des besoins de l'utilisateur Module de Scan Nous avons besoin de réaliser des "scans", c'est à dire une ou plusieurs actions synchronisés de manière incrémentale puis récupérer et acher le résultat graphiquement. Par exemple, on veut déplacer un moteur 2theta de à pas avec un pas de 1 et mesurer la quantité de rayons X à chaque fois. Les données mesurées sont enregistrées. La classe scan va permettre à l'utilisateur de spécier les actions à réaliser avec les paramètres à incrémenter, les mesures, les options d'enregistrement et d'achage graphique. L'achage des données est réalisé par Gnuplot qui trace au fur et à mesure les données enregistrées. Cette classe dispose des méthodes principales suivantes : addaction(action) permet d'ajouter une action à un scan, addmeasure() permet d'ajouter une fonction de mesure avec ses arguments, execute() permet de lancer le scan. Actions Les actions à réaliser et les paramètres associés sont spéciés par l'intermédiaire d'une classe Action. Une action doit donc être dénie en précisant : 84

85 8.4. INTERFACE LOGIQUE D'EXPÉRIENCE un nom pour l'action (sous forme de chaine de caractère) la fonction Python a exécuter la séquence de paramètres sous forme de liste On peut utiliser n'importe quelle fonction Python, mais également les outils de pytangodevice, qui permettent d'accéder à un device. Exemple : >>>r=range(0,10,1) >>>a=action("scan 2theta",usaxs.t2theta_Motor.set_position,r) D'autres options d'exécution peuvent être spéciés, comme la possibilité d'attendre la n d'un évènement, mouvement moteur par exemple, en indiquant une fonction renvoyant vrai lorsque l'action est nie (waitstateon() par exemple). Par la suite, on dispose de méthodes qui vont permettre de séquencer cette action : doaction() : exécute l'action avec le paramètre courant donext() : exécute l'action suivante. Si l'action courante est la dernière, exécute encore. doall() : exécute toutes les actions depuis le début donaction(n) : exécute l'action demandée getcurrentparameter() : renvoie le paramètre courant hasreturnvalue() : est-ce que l'action renvoie une valeur? Mesures La classe Scan permet de dénir des mesures à l'aide de la méthode addmeasure(). Les mesures se diérencient des actions, par le fait que leur exécution sera toujours identique (on ne spécie pas les paramètres à incrémenter) et surtout qu'elles sont le résultat du scan. Si on continue l'exemple précédent : >>>s=scan() >>>s.addaction(a) >>>s.addmeasure(countsr400,'coups',1) >>>s.execute() Cela dénit et exécute un scan contenant une mesure, nommée coups, de 1 s avec la fonction countsr400(). Fonctionnement Lors de l'exécution, chaque action est réalisée avec une incrémentation des paramètres et les mesures sont eectuées. La première action sert de référence. Elle doit posséder la séquence de paramètres la plus grande. L'achage des données se fait au fur et à mesure du scan. Il représente un graphe avec en abscisse les paramètres de la première action, et en ordonnées les mesures réalisée. Si plusieurs mesures sont eectuées, plusieurs courbes s'achent. Il est possible de spécier des paramètres d'achage de Gnuplot en renseignant une variable GnuplotParameters. Le chier de stockage des données est spécié par DataFilename. 85

86 CHAPITRE 8. INTERFACE HOMME-MACHINE La gure 8.3 montre le résultat d'un scan. On trouvera en annexe la documentation de ce module. Fig. 8.3 Résultat d'un scan Module d'enregistrement On utilise le module pyrecorder qui peut enregistrer une ou plusieurs mesures dans le temps. Une mesure est dénie par une fonction Python qui peut être une commande de device TANGO. Un système de cadencement permet d'eectuer les mesures à intervalles réguliers. Fonctionnement La classe pyrecorder permet d'initialiser le module et possède les méthodes suivantes : addmeasure() permet de spécier une mesure à réaliser. Il faut préciser un nom, sous forme de chaîne de caractère, une fonction Python à exécuter, et éventuellement des arguments. start() permet de lancer l'enregistrement. On peut spécier le chier dans lequel seront enregistrés les données, le nombre ou l'intervalle de temps entre deux mesures. Si le nombre de mesures est égal à 0, l'enregistrement a une durée illimité. L'arrêt est alors possible en appuyant sur CTRL+C. Si l'intervalle de temps est nul, les mesures s'enchaînent sans cadencement. Exemple Dans l'exemple suivant, dont le résultat graphique est montré en gure 8.4, on va enregistrer deux attributs sur des devices servers TANGO : from pytangodevice import * from pyrecorder import * 86

87 8.4. INTERFACE LOGIQUE D'EXPÉRIENCE #---- declaration des attributs à enregistrer vide=pytangodevice("usaxs/vacuum/generator") back=pytangodevice("usaxs/vacuum/back") #---- ajout des mesures à réaliser r=pyrecorder() r.addmeasure("vide",vide.get_value) r.addmeasure("back",back.get_value) #---- demarrage r.start(many=300) Résultats La méthode start() retourne le tableau numérique des données enregistrées. Celles-ci sont également accessibles via une variable datas. La variable mean regroupe les moyennes des données mesurées. >>> r.mean array([ , ]) >>> r.mean[0] L'utilisateur peut donc utiliser ces données dans des programmes ultérieurs. Fig. 8.4 Résultat d'un enregistrement 87

88 CHAPITRE 8. INTERFACE HOMME-MACHINE 8.5 Conclusion - Résultats L'idée principale de notre interface graphique est de séparer saisie de commandes et achage des données (voir gure 8.7). Par l'intermédiaire des modules de connection à TANGO py- TangoDevice et pytangobeamline, l'utilisateur peut accéder interactivement sans limites aux composants matériels de l'expérience. Il est possible de les synchroniser en utilisant des modules de scan et d'enregistrement. A l'aide de ces outils, la logique d'expérience est mise au point en quelques heures seulement. Cette architecture ore également une grande exibilité : le physicien peut développer une séquence de réglages en saisissant les commandes dans l'interpréteur Python et par la suite orir une interface limitée pour des expériences de routine. L'utilisateur non spécialiste saisit juste une commande qui va déclencher la logique d'expérience. Il est également possible de créer interface graphique. Les modules de scan et d'enregistrement ne sont pas spéciques à TANGO, ce qui permet leur réutilisation sur d'autres expériences. Enn, l'utilisation de Python permet de supprimer les barrières qui existaient jusqu'à présent entre logique d'expérience et exploitation des résultats. Ainsi, ce langage étant utilisé à la fois pour piloter l'expérience et pour les calculs scientiques il est possible d'enchaîner les mesures et le traitement des données de manière transparente direct beam mesured gaussian fit CENTER= Intensities theta position Fig. 8.5 Scan du faisceau direct et t gaussien 88

89 8.5. CONCLUSION - RÉSULTATS Résultats En concertation avec les physiciens du laboratoire, nous avons compilé dans un script Python usaxs.py toutes les fonctions utiles à l'expérience USAXS. Il regroupe des mesures automatiques de faisceau et des calculs. Par exemple, lors d'un scan du faisceau direct, la courbe obtenue est de forme Gaussienne. On a ajouté un t, calcul de l'équation à partir des données expérimentales, qui permet de déterminer le centre de la courbe et donc le centre du faisceau. On peut voir le résultat sur la gure 8.5. Nous avons élaboré des algorithmes qui évaluent quels atténuateurs il faut insérer en fonction du nombre de coups mesurés par le compteur. Ainsi nous avons reproduit la logique d'expérience USAXS telle que dénie au chapitre 2. Les premiers résultats sont satisfaisants. La gure 8.6 montre un spectre de diusion de rayons X aux très petits angles obtenu avec un échantillon de latex. 1e+008 1e slatex Rocking Curve 1e+006 Number of counted X-rays e q (A-1) Fig. 8.6 Spectre de diusion de rayons X aux très petits angles obtenu sur l'expérience USAXS avec un échantillon de latex. 89

90 CHAPITRE 8. INTERFACE HOMME-MACHINE Fig. 8.7 L'interface développée est composée d'une fenêtre de saisie des commandes, et de fenêtres d'achage graphique. Simultanément, il peut y avoir un achage du synoptique. 90

91 Conclusion générale - Perspectives Bilan La problématique principale de notre projet était de trouver une solution évolutive pour communiquer avec les éléments matériels et logiciels d'une expérience de physique. De toutes les solutions étudiées le système TANGO, qui est une implémentation de CORBA pour le contrôle-commande, s'est révélée la plus ecace. Nous avons réussi à mettre en place une architecture basée sur des composants réutilisables et communiquants. Le système TANGO permet de contrôler chaque élément grâce à un programme serveur appelé device servers. Il est relativement rapide de développer ces serveurs grâce au modèle de programmation Device Pattern et à un générateur de code. Les autres outils fournis permettent leur installation et leur conguration. Il était prévu initialement une durée de développement d'une semaine pour chaque device server et cette durée a pu être ramenée à un jour à la n du projet. Grâce à la grande modularité de l'architecture, et à la simplication des serveurs, les tests sont réalisés en quelques heures seulement et la documentation est générée dans la foulée. Nous avons mis en place une architecture à plusieurs niveaux de device servers qui permettent de gérer les protocoles de communication, les interfaces avec les instruments, et orent à l'utilisateur ou l'application scientique des fonctionnalités pratiques. Ceci permet une vraie abstraction du matériel. Comme demandé dans le cahier des charges du départ, il est possible d'accéder et de congurer facilement les vraies valeurs physiques de l'expérience. TANGO propose diérents niveaux d'interface utilisateur. Ainsi les applications TANGO (Jive, AtkPanel,...), permettent de tester et congurer graphiquement chaque composant de l'expérience. L'application Synoptic permet en outre un achage graphique général, permettant en un clin d'oeil de superviser l'expérience. Après avoir étudié divers systèmes d'interface homme-machine, nous avons choisi un système de saisie de commande qui est réalisé dans l'interpréteur du langage Python. Des modules d'interface Python pour TANGO ont été développés an de simplier l'accès aux devices servers. Les utilisateurs peuvent interagir directement avec les composants du système comme de simples variables ou commandes Python. Cela correspondait à une demande forte de la part des scientiques. Les avantages sont multiples. C'est le physicien qui saisit lui-même les commandes et qui peut contrôler chaque instrument. Il est le mieux placé pour mettre au 91

92 . CONCLUSION GÉNÉRALE - PERSPECTIVES point et modier la logique d'expérience. Celle-ci n'est plus gée et peut évoluer en fonction des besoins, mais la suite des commandes peut être imprimée, enregistrée et retrouvée ultérieurement. Nous avons développé des modules Python qui permettent de réaliser des balayages (scans), c'est à dire séquencer des actions et des mesures, et des enregistrements. Notre interface permet de tracer les données sur d'autres fenêtres au fur et à mesure du déroulement de l'expérience. Pour cette fonctionnalité, nous avons choisi d'utiliser le logiciel Gnuplot. Le choix du langage Python est primordial dans notre architecture, car c'est un langage facile à apprendre, à utiliser et disponible sous environnement Windows, Unix et Macintosh. Les scientiques du laboratoire étant familiers avec le langage Python (des formations ont été organisés depuis le début de l'année), la phase d'apprentissage du langage est réduite. L'usage de Python permet aux scientiques de se passer de la présence d'un expert en informatique pour l'écriture de la logique d'expérience. De plus, des outils mathématiques développés pour d'autres usages peuvent être incorporés facilement. L'originalité de notre interface par rapport à d'autres solutions logicielles telles que SPEC, Matlab, ou IGOR, qui proposent également un système de saisie des commandes textuelles, est qu'elle est basée intégralement sur des composants Open Source et gratuits. Le déploiement et la réutilisation de cette interface est alors facilitée puisqu'il n'y a aucune dépendance nancière ni technique vis à vis de fournisseurs. Améliorations à envisager Malgré tout, l'ergonomie de ce système de ligne de commande n'est pas optimale. L'utilisateur doit connaître les commandes, qui sont diérentes pour chaque device server. Il faut donc travailler à une harmonisation. On peut aussi utiliser certaines distributions de Python qui fournissent une "auto-completion", c'est à dire, qui proposent lors de la saisie, les méthodes et variables associées à chaque objet. On peut également proposer une interface graphique pour la création des scans et des enregistrements. Un travail peut être mené en amont, au moment de la création des device servers, en uniant les commandes des devices qui sont semblables. C'est ce que propose un modèle proposé par l'équipe TANGO, et qui permet d'orir pour certains types de matériel une interface commune. Par exemple, tous les serveurs de moteurs, quelque soient les fabriquants, auraient les mêmes attributs et mêmes commandes. Certaines possibilités oertes par TANGO n'ont pas été utilisées : comme décrit au chapitre 6, il est possible de gérer des évènements générés par les device servers, réduisant ainsi le nombre d'informations échangés sur le système. Par exemple, l'application Synoptic, qui ache une représentation graphique très pratique de l'expérience demande une mise à jour de tous les attributs environ une fois par seconde. Avec la gestion des événements, l'achage est mis à jour seulement si les attributs sont modiés. On peut également imaginer des systèmes de sécurité qui commanderaient certaines actions en cas de déclenchement d'alarmes sur des attributs. 92

93 Perspectives : Depuis septembre 2006, il est possible de développer des device servers en langage Python. Ce langage étant plus facile à utiliser que le C++ ou Java, le temps et la diculté de développement sont réduit. La portabilité des serveurs va être accrue, car un même code pourra être utilisé sous Windows et sous Unix, sans besoin de recompilation. Les utilisateurs non-experts en programmation pourront également développer des serveurs. Le système basé sur TANGO et Python, permet d'envisager les évolutions sur les expériences avec sérénité. Suite à ce projet, plusieurs éléments vont être remplacés sur le montage USAXS, d'autres vont être ajoutés. Il sura de développer les device servers correspondants mais l'interface homme-machine ne sera pas modiée. L'utilisateur pourra tout simplement accéder à de nouveaux composants. Sur une autre expérience du laboratoire, nous voulons installer un détecteur qui nécessite le système d'exploitation Unix et il faut le synchroniser avec des composants logiciels sous Windows. Sans TANGO, nous aurions des dicultés à développer le logiciel de contrôle-commande. Avec TANGO, chaque appareil peut être contrôlé par des device servers situés sur des machines diérentes. Ceci étant transparent pour l'interface nale. Cette architecture ouvre beaucoup de perspectives intéressantes. Elle va pouvoir être déployée sur d'autres montages expérimentaux et permet de lever des blocages liés à l'informatique. Dans une expérience de physique l'informaique doit être le bras de levier qui permet de produire des résultats plus nombreux, plus précis et de meilleure qualité. 93

94 . CONCLUSION GÉNÉRALE - PERSPECTIVES 94

95 Annexes 95

96

97 Annexe A Photographies du montage USAXS Fig. A.1 Vue d'ensemble du montage USAXS 97

98 ANNEXE A. PHOTOGRAPHIES DU MONTAGE USAXS Fig. A.2 Photographie de la baie électronique Fig. A.3 Contrôleur Micro-Contrôle IT6 DCA 2 98

99 Fig. A.4 Contrôleurs SR400 Fig. A.5 Contrôleur de jauges à vide Leybold Fig. A.6 Système d'acquisition National Instruments, composé d'un contrôleur USB cdaq, de deux modules d'e/s numériques et d'un module d'acquisition analogique 99

100 ANNEXE A. PHOTOGRAPHIES DU MONTAGE USAXS Fig. A.7 A gauche, système de contrôle des atténuateurs. A droite, boîtier des atténuateurs 100

101 Annexe B Documentation des device servers développés Device servers développés : Single Analogic Input Single Analogic Output Digital Input-Output IT6CA2 Motor Controler SR400 Controler Keithley197 Shutter Filters Physical Value 101

102 ANNEXE B. DOCUMENTATION DES DEVICE SERVERS DÉVELOPPÉS 102

103 Annexe C Exemple de device server en langage Python 103

104 ANNEXE C. EXEMPLE DE DEVICE SERVER EN LANGAGE PYTHON # This is an example of Tango Device Server in Python # this class implement Serial port # needs the Serial module ## # commands : # WriteRead : write and read string to the port # attributes # LastResponse : last string recieve from port # import PyTango import sys import time # class PyDsSerial(PyTango.Device_3Impl): """ PyDsSerial class """ def get_device_property(self): """ return a dictionary with all devices properties """ db=pytango.database() property_list=db.get_device_property_list(self.get_name(),"*") self.property_dict=db.get_device_property(self.get_name(),property_list) def init (self,cl,name): """ class initialisation """ PyTango.Device_3Impl. init (self,cl,name) PyDsSerial.init_device(self) def init_device(self): """ server initialisation """ self.set_state(pytango.devstate.on) self.attr_lastresponse = "" #retrieve properties self.get_device_property() for i in self.property_dict: print i,"->",self.property_dict[i][0] # test properties if self.property_dict.has_key("portnumber"): PortNumber=int(self.property_dict["PortNumber"][0]) if self.property_dict.has_key("baudrate"): Baudrate=int(self.property_dict["Baudrate"][0]) else: Baudrate=9600 if self.property_dict.has_key("newline"): self.newline=chr(int(self.property_dict["newline"][0])) else: self.newline=chr(13) if PortNumber<>"": #print "port to open : ",port #test if serial port is already open self.ser=serial.serial() self.ser.port=portnumber self.ser.baudrate=baudrate if self.ser.isopen(): print "port already open" else : print "port was not open" self.ser.open() if self.ser.isopen(): self.set_state(pytango.devstate.on) print "now is open" print str(self.ser) else: self.set_state(pytango.devstate.off) def delete_device(self): 104

105 """ delete method """ print "[Device delete_device method] for device",self.get_name() if self.ser.isopen(): print "port ",self.ser.port, " will be close" self.ser.close() else : print "port ",self.ser.port, " not open" # # ---- COMMANDS def is_writeread_allowed(self): if (self.get_state() == PyTango.DevState.ON): return True else: return False def WriteRead(self,in_data): print "[WriteRead::execute] received string",in_data self.command = in_data+self.newline self.ser.write(self.command) print "writing :"+self.command time.sleep(0.05) #wait 50ms self.attr_lastresponse=self.ser.read(self.ser.inwaiting()) print "reading :"+self.attr_lastresponse #self.ser.write(self.attr_lastresponse) return self.attr_lastresponse # # ATTRIBUTES # def read_attr_hardware(self,data): print 'In read_attr_hardware' def read_lastresponse(self,the_att): print "[PyDsSerial::read_attr] attribute name LastResponse_attr" the_att.set_value(self.attr_lastresponse) # class PyDsSerialClass(PyTango.PyDeviceClass): def init (self,name): PyTango.PyDeviceClass. init (self,name) self.set_type("testdevice") print 'In DevTestClass init ' self.add_wiz_dev_prop('portnumber','number of the port com','1') self.add_wiz_dev_prop('timeout','timeout','1') self.add_wiz_dev_prop('parity','enable parity checking','n') self.add_wiz_dev_prop('stopbits','number of stopbits','1') self.add_wiz_dev_prop('baudrate','baudrate','9600') self.add_wiz_dev_prop('newline','end of message Character default=13','13') #defining attributes and command cmd_list = {'WriteRead':[[PyTango.ArgType.DevString, "Command to write on the port"], [PyTango.ArgType.DevString, "Response of the device"]] } attr_list = {'LastResponse':[[PyTango.DevString,PyTango.SCALAR,PyTango.READ], {'label':"last Response",'description':"Last Response"}] } if name == ' main ': """ execution """ py = PyTango.PyUtil(sys.argv) py.add_tgclass(pydsserialclass,pydsserial,'pydsserial') import serial U = PyTango.Util.instance() U.server_init() U.server_run() 105

106 ANNEXE C. EXEMPLE DE DEVICE SERVER EN LANGAGE PYTHON 106

107 Annexe D Documentation des programmes Python développés 107

108 ANNEXE D. DOCUMENTATION DES PROGRAMMES PYTHON DÉVELOPPÉS D.1 pyrecorder D.1.1 Class pyrecorder class pyrecorder for plotting recorded value Methods init (self ) class pyrecorder for plotting recorded value addmeasure(self, name, measure, *args) add a measure (function) to be recorded start(self, lename=sys.prefix+"\\tempo.txt", many=0, scheduler =1) launch the recording lename : the lenama where the data are saved many : recording number (if 0 then no limi, stop with ctrl+c) scheduler : time in seconds between each measures (if 0 then no waiting time) Class Variables mean datas g Name mean of datas Value : [] list of datas recorded Value : [] gnuplot instance Value : '' Description D.1.2 Variables Name NoParameter FilenameTemp GnuplotSeparator Description Value : '' Value : 'c :\\python\\temp.txt' Value : '\t' 108

109 D.2. SCAN D.2 Scan D.2.1 Class Scan To do some actions and measures synchronously Methods init (self ) addaction(self, Action, Sequence, name='?') Add an action (function) to process with parameters in Sequence ActionName is a string which represent the physical value : >>> s.addaction(movemotor,[1,2,3,4,5],'theta') Each action function must have the same numbers of parameters (no sense if dierent) except a function without parameters ex : >>> s.addaction(dosomething,[]) addmeasure(self, function, name, *args) Add a measure action Measure : function to execute and which return a result Parameters : parameters for the function ex : >>> def x2(x,y): return x*y >>>s.addmeasure(x2,'x2',1,2) addplot(plot) link to a gnuplot instance repr (self ) get a str representation of class str (self ) execute(self ) execute action Class Variables Name ListAction Value : [] Description continued on next page 109

110 ANNEXE D. DOCUMENTATION DES PROGRAMMES PYTHON DÉVELOPPÉS Name Description ListMeasure Value : [] DataFilename Value : 'c :\\python\\temp.txt' results Value : [] GnuplotInstance Value : '' GnuplotParameters Value : '' GnuplotParametersFile Value : '' GnuplotCommand Value : '' OptionPlot Value : False OptionSave Value : False D.3 PyTangoDevice D.3.1 Variables Name Description author Value : "Olivier Tache <[email protected]>" date Value : "23 may 2006" version Value : 1 WAIT_TIME Value : 0.3 device Value : "tango/tangotest/1" test Value : pytangodevice(device) long_value Value : raw_input("enter a value to send to tangotest : ") D.3.2 Class pytangodevice Class to use easily a Tango device pytangodevice version 1 ex : >>> test=pytangodevice("tango/tangotest/1") Now tango can access easily to the device Read an attribute : >>> test.short_scalar 45 Write an attribute : >>> test.short_scalar_w=3 Execute a command : >>> test.init() Execute a command with a return value : >>> test.devlong(1) 110

111 D.3. PYTANGODEVICE 1 Get the current state : >>> device.state() PyTango.DevState.ON --- for some use we need a function to access to atributes, so each attribute have a set and get command >>> test.get_double_scalar() >>> test.set_short_scalar_w(3) for READ attribute only --- for some use we need to wait that a device is ready (ON) so I add a function waitstateon() to wait the DevState::ON >>> test.waitstateon() will not work because tangotest state is UNKNOWN Methods init (self, name) Class to use easily a Tango device name : device server name getattr (self, name) call for an attribute 'name' ex : >>> print mydevice.name call the function read_attribute('name').value setattr (self, name, arg) pass a value to an atribute name ex : >>> mydevice.name=10.2 check if attribute is writable call the function read_attribute and write_attribute repr (self ) str (self ) waitstateon(self ) function to wait the DevState : :ON (DevState.ON) of the device server Class Variables Name DeviceName Value : "" State Value : "" Description 111

112 ANNEXE D. DOCUMENTATION DES PROGRAMMES PYTHON DÉVELOPPÉS Instance Variables Status Name scanning attributes Description D.4 PyTangoBeamline D.4.1 Variables Name Description author Value : 'Olivier Tache <[email protected]>' date Value : '22 nov 2006' version Value : 1 D.4.2 Class Beamline Class to use a TANGO beamline import into one variable a branch of devices TANGO tree ex : >>> usaxs=beamline("usaxs") Welcome to usaxs... Connected to Tango... >>> usaxs found : usaxs/angles/2alpharad -> but not working!!! found : usaxs/angles/2thetaq ->t2thetaq : ON found : usaxs/angles/2thetarad ->t2thetarad : ON found : usaxs/angles/alpharad ->alpharad : ON found : usaxs/angles/chirad ->chirad : ON found : usaxs/angles/phirad -> but not working!!! found : usaxs/angles/theta ->theta : ON found : usaxs/counter/flux ->flux : ON found : usaxs/counter/flux_pico ->flux_pico : ON found : usaxs/counter/sr400_1 ->sr400_1 : RUNNING found : usaxs/filters/attenuators ->attenuators : ON found : usaxs/motors/2alpha_motor -> but not working!!! found : usaxs/motors/2theta_motor ->t2theta_motor : ON found : usaxs/motors/alpha_motor ->alpha_motor : ON found : usaxs/motors/chi_motor ->chi_motor : ON found : usaxs/motors/phi_motor -> but not working!!! found : usaxs/motors/theta_motor ->theta_motor : ON found : usaxs/shutter/shutter ->shutter : OPEN found : usaxs/vacuum/back ->back : ON found : usaxs/vacuum/front ->front : ON found : usaxs/vacuum/generator ->generator : ON 112

113 D.4. PYTANGOBEAMLINE Methods init (self, BeamlineName) repr (self ) get a str representation of class str (self ) get a str representation of class 113

114 ANNEXE D. DOCUMENTATION DES PROGRAMMES PYTHON DÉVELOPPÉS 114

115 Annexe E Procédure d'installation d'un Device Server 115

116 ANNEXE E. PROCÉDURE D'INSTALLATION D'UN DEVICE SERVER L'objectif de ce petit guide est de montrer la facilité oerte par l'application Jive pour installer et déclarer un Device Server dans la base de donnée TANGO. Il permet également d'expliciter les termes utilisés dans le système TANGO. Pour cela nous avons développé un Device server PyDsSerial en langage Python qui est chargé de la gestion du protocole des ports Series. Exécutable Instance Device Device name PyDsSerial.py Expérience 1 SerialExp1 Classe PyDsSerial COM1 COM2 COM3 manip1/protocoles/com1 manip1/protocoles/com2 manip1/protocoles/com3 PyDsSerial.py Expérience 2 SerialExp2 Classe PyDsSerial COM1 COM2 manip2/protocoles/com1 manip2/protocoles/com2 lancement de l'assistant de Jive Dans l'application Jive, on lance l'assistant Server Wizard Enregistrement du serveur Le serveur est enregistré dans la base de données TANGO en spéciant le Server Name (nom de l'exécutable) et le nom d'instance. 116

117 Lancement du serveur L'écran suivant invite l'utilisateur à lancer l'exécution du serveur. Ceci est fait en tapant la commande DOS : python PyDsSerial.py SerialPort. Déclaration de la classe L'assistant a détecté la présence d'une seule classe dans ce serveur, dont il va falloir spécier les propriétés. Nommage du device Il faut nommer le serveur. 117

118 ANNEXE E. PROCÉDURE D'INSTALLATION D'UN DEVICE SERVER Enregistrement des propriétés On spécie les propriétés du serveur (ici portnumber pour le numéro de port série). Ajout d'un nouveau device pour un serveur Il est possible d'ajouter un nouveau device au serveur (nouvel instrument ou appareil situé sur la même machine). 118

119 Bibliographie [1] LabView. Manuel de l'utilisateur [2] Référentiel méthodologique des projets au CEA [3] The TANGO control system manual [4] Claude Delannoy. Programmer en C++. Eyrolles, [5] J.-N Clot du Hecquet Ph. Escoer-Gentile. Aide mémoire de C. Marabout informatique, [6] Andy Gotz. The abstract device pattern or how to implement multiple classes of the same device type in tango. [7] André Guinier. Théorie et technique de la radiocristallographie. DUNOD, [8] André Guinier. Les Rayons X. Presses Universitaires de France, [9] Nicolas Leclerc. Evaluation des frameworks ACS et TANGO pour le contrôle/commande de la machine SOLEIL [10] Nicolas Leclerc. Exigences relatives au Logiciel Commun de Soleil [11] Mark Lutz. Python : Pocket reference. O'Reilly, [12] Alex Martelli. Python en concentré. O'Reilly, [13] F. Né, I. Grillo, O. Taché, and T. Zemb. From raw image to absolute intensity : Calibration of a guinier-mering camera with linear collimation. JOURNAL DE PHYSIQUE IV, 10(P10) :403413, [14] Alain Pénicaud. Les cristaux, fenêtres sur l'invisible. L'esprit des sciences, [15] L. Sicard, O. Spalla, P. Barboux, F. Ne, and O. Tache. A rst contribution of the grazing incidence small angle x-ray scattering to the study of the corrosion of glass monoliths. JOURNAL OF NON-CRYSTALLINE SOLIDS, :230233, [16] O. Spalla, S. Lyonnard, and F. Testard. Analysis of the small-angle intensity scattered by a porous and granular medium. JOURNAL OF APPLIED CRYSTALLOGRAPHY, 36 :338347, [17] Bjarne Stroustrup. Le Langage C++. Parson Education, [18] Erich Gamma Richard Helm Ralph Johnson John Vlissides. Design Patterns : Catalogue de modèles de conception réutilisables. Vuibert, [19] T. Zemb, O. Taché, F. Né, and O. Spalla. A high-sensitivity pinhole camera for soft condensed matter. JOURNAL OF APPLIED CRYSTALLOGRAPHY, 36 :800805, [20] Tarek Ziadé. Programmation Python. Eyrolles,