Conservatoire National des Arts et MétiersPARIS
Mémoire présenté en vue de l'obtentiondu diplôme d'Ingénieur CNAM
Spécialité : InformatiqueOption : 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
Table des matières
Table des matières 3
Introduction 7
I Etudes 9
1 Contexte 111.1 Le laboratoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.1 Le Commissariat à l'Energie Atomique . . . . . . . . . . . . . . . . . . . 111.1.2 La Direction des Sciences de la Matière . . . . . . . . . . . . . . . . . . 121.1.3 Le Département de Recherche sur l'État Condensé, les Atomes et les
Molécules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.1.4 Le Service de Chimie Moléculaire . . . . . . . . . . . . . . . . . . . . . . 121.1.5 Le Laboratoire Interdisciplinaire sur L'Organisation Nanométrique et
Supramoléculaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2 La di�usion des rayons X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.1 Les Rayons X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2.2 La di�raction des rayons X . . . . . . . . . . . . . . . . . . . . . . . . . 141.2.3 Technique de di�usion des rayons X aux petits angles . . . . . . . . . . 16
2 Etude préliminaire 192.1 Gestion du projet - Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.1 Résultats à atteindre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.2 Tests à réaliser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1.3 Délais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1.4 Acteurs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1.5 Ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.6 Risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.7 Marges de manoeuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 Sujet d'étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.1 Montage USAXS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.2 État des lieux matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.3 État des lieux logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Problèmes existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3.1 Interface matérielle et logicielle . . . . . . . . . . . . . . . . . . . . . . . 25
3
TABLE DES MATIÈRES
2.3.2 Logique d'expérience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.3.3 Interface HM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.3.4 Problèmes futurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 Solutions proposées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.4.1 Gestion des éléments matériels . . . . . . . . . . . . . . . . . . . . . . . 262.4.2 Gestion des éléments logiciels . . . . . . . . . . . . . . . . . . . . . . . . 262.4.3 Interface homme machine . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3 Présentation des di�érents systèmes de contrôle-commande 293.1 Description d'un système de contrôle-commande à base de PC . . . . . . . . . . 29
3.1.1 Elements matériels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1.2 Éléments logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.1.3 Qu'est ce qu'une couche d'abstraction matériel-logiciel ? . . . . . . . . . 30
3.2 Solutions commerciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2.1 National Instruments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2.2 Tests réalisés - Retour d'expérience . . . . . . . . . . . . . . . . . . . . . 333.2.3 Conclusion sur les solutions National Instruments . . . . . . . . . . . . . 34
3.3 Solutions Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.2 TANGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.3.3 Tests réalisés - Retour d'expérience . . . . . . . . . . . . . . . . . . . . . 363.3.4 Conclusion sur TANGO . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4 Présentation des di�érents systèmes d'interface homme-machine pour ex-périences 414.1 Spéci�cités d'une interface Homme Machine pour expériences . . . . . . . . . . 414.2 Solutions à interface graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.1 Exemple d'IHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.2 Langage de programmation graphique : LabView . . . . . . . . . . . . . 434.2.3 Visual Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.4 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3 Solutions à ligne de commande . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3.1 SPEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3.2 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5 Conclusion - choix 51
II Réalisations 53
6 TANGO 556.1 Fonctionnement général de TANGO . . . . . . . . . . . . . . . . . . . . . . . . 556.2 Installation de TANGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.3 Fonctionnement d'un device server . . . . . . . . . . . . . . . . . . . . . . . . . 586.4 Développement d'un device server . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4.1 Le générateur de code POGO . . . . . . . . . . . . . . . . . . . . . . . . 60
4
TABLE DES MATIÈRES
6.4.2 Implémentation du code . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.5 Développement d'un device server . . . . . . . . . . . . . . . . . . . . . . . . . . 646.6 Utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.6.1 Jive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.6.2 Astor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.6.3 Synoptique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7 Architecture de device servers 697.1 Description générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697.2 Device servers de bas niveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2.1 Interface GPIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717.2.2 Acquisition Analogique simple . . . . . . . . . . . . . . . . . . . . . . . . 727.2.3 Sortie Analogique simple . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.2.4 Entrées-Sorties Numériques . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.3 Device servers de niveau intermédiaire . . . . . . . . . . . . . . . . . . . . . . . 737.4 Device servers de haut niveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.4.1 Shutter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737.4.2 Filtres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747.4.3 Evaluateur d'expression mathématique . . . . . . . . . . . . . . . . . . . 75
7.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8 Interface Homme-Machine 778.1 Description générale et cahier des charges . . . . . . . . . . . . . . . . . . . . . 778.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778.3 Accès à TANGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
8.3.1 pyTango . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798.3.2 pyTangoDevice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798.3.3 pyTangoBeamline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.4 Interface logique d'expérience . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838.4.1 Environnement scienti�que . . . . . . . . . . . . . . . . . . . . . . . . . 838.4.2 Module de Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848.4.3 Module d'enregistrement . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.5 Conclusion - Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
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 107D.1 pyRecorder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
D.1.1 Class pyRecorder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108D.1.2 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
D.2 Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5
TABLE DES MATIÈRES
D.2.1 Class Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109D.3 PyTangoDevice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
D.3.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110D.3.2 Class pyTangoDevice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
D.4 PyTangoBeamline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112D.4.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112D.4.2 Class Beamline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
E Procédure d'installation d'un Device Server 115
Bibliographie 119
6
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 étaientprécis. Leur qualité venait également de la patience des expérimentateurs, qui reportaient lesobservations et mesures sur des cahiers et des graphes. Aujourd'hui, l'heure est à l'automati-sation et à la collecte sans limite des données.La �gure ci-dessous présente une photo d'un des premiers montage de di�usion des rayonsX aux petits angles, qui date des années 50. Ici, pas d'électronique, pas d'ordinateurs. Lesmesures sont réalisées grâce à une plaque photographique. Sur la photo de droite, prise en2006, on peut voir une partie de l'expérience ID2 de l'ESRF (European Synchrotron ResearchFacilities) de Grenoble. Celle-ci réalise le même type de mesures, mais est composée de plusd'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 lacompose de demandes d'informations et de commandes diverses. La tendance actuelle est deconnecter le moindre système de mesure au réseau, s'a�ranchissant ainsi des distances. Lescomposants 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'estplus besoin de relier physiquement l'instrument et l'ordinateur. Tout se passe au niveau du lo-
7
. INTRODUCTION
giciel. Maîtriser l'informatique permet d'augmenter les possibilités expérimentales de manièreconsidé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ériencesest hétérogène et nécessite de fréquentes mises à niveau ? C'est la problématique principalede ce projet, réalisé dans le cadre d'un mémoire présenté en vue de l'obtention du diplômed'ingénieur CNAM.
Les objectifs sont de mettre au point une nouvelle architecture informatique de contrôle-commande permettant d'interfacer les di�érents instruments que l'on peut rencontrer sur desmontages scienti�ques. Elle doit permettre de développer une logique d'expérience (séquencede mesures et d'actions à réaliser) grâce à une interface homme-machine adaptée. Ce nouveausystème doit être évolutif et doit pouvoir être déployé sur divers types de montages.
A�n de tester des solutions et des méthodes, nous avons choisi de nous intéresser à un montageexpérimental conçu il y a 15 ans. Les composants mécaniques et certains éléments électroniquesont remarquablement bien vieillis et sont robustes. La faiblesse du montage résidait dansl'interface logicielle développée à l'époque pour coller au mieux aux demandes des scienti�ques.Le besoin d'évolution de l'expérience impose désormais de modi�er la philosophie générale del'architecture informatique. On passe d'une architecture monobloc à une architecture baséesur des composants interchangeables et communiquants.On retrouve ces changements au niveau de l'interface homme-machine. Elle se doit d'êtreintelligente, c'est à dire comprendre et s'adapter à son environnement qui sont les élémentsmatériels et logiciels de l'expérience, mais également les utilisateurs. L'interface utilisateurdoit être une extension de la pensée du physicien. Qui mieux que le physicien peut savoirquelle commande ou quelle mesure il faut exécuter ? Elle doit également proposer des solutionssimples 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 logicielsdéveloppés ces dernières années sur les expériences de physique du laboratoire. Elles vontnous permettre une ré�exion profonde sur ce que doit être un système de contrôle commandepour expériences de physique, aussi bien au niveau de l'interface matérielle que de l'interfacehomme-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 sys-tème TANGO et le langage de programmation Python. J'exposerais les composants que j'aidé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ôlecommande évolutif et adapté aux demandes des utilisateurs, pour les expériences de physiquedu laboratoire.
8
Première partie
Etudes
9
Chapitre 1
Contexte
1.1 Le laboratoire
1.1.1 Le Commissariat à l'Energie Atomique
Le Commissariat à l'Énergie Atomique (CEA) a été créé en 1945 a�n de poursuivre "lesrecherches scienti�ques et techniques en vue de l'utilisation de l'énergie atomique dans diversdomaines de la science, de l'industrie et de la défense nationale". Implanté sur neuf centres derecherche répartis dans toute la France, le CEA est un acteur majeur de la recherche sur troisgrands 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 parti-culier non émettrices de gaz à e�et de serre. Il cherche à optimiser le parc actuel des réacteursnuclé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 combustiblesnucléaires du futur qui assureront une production à la fois plus économique, plus sûre etgénérant moins de déchets. Il conduit en�n des programmes sur l'impact sanitaire et envi-ronnemental de l'énergie nucléaire. Les recherches du CEA soutiennent également l'essor desnouvelles technologies pour l'énergie : l'hydrogène, le photovoltaïque, la biomasse... La fusionthermonucléaire, dont la maîtrise pourrait permettre dans l'avenir de disposer d'une sourcequasi in�nie d'énergie, est également au coeur de ses recherches. Le CEA est ainsi fortementimpliqué dans le projet international du réacteur expérimental ITER. En amont des rechercheset développements sur les énergies, il conduit di�érents programmes dans les domaines dessciences du climat et de l'environnement, des sciences de la matière, de la chimie et des inter-actions rayonnement-matière.
Les technologies pour l'information et la santé
A�n de favoriser l'innovation industrielle, le CEA dispose d'une recherche technologique dehaut niveau dans le domaine des micro et nanotechnologies. Les applications industrielles deces recherches concernent notamment les télécommunications et les objets communicants. Il
11
CHAPITRE 1. CONTEXTE
exerce ses compétences dans le domaine des technologies logicielles : systèmes embarqués etinteractifs, capteurs et traitement du signal. Grâce aux compétences qu'il développe autourdes 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 programmesappliqué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éces-saires pour garantir la pérennité de la dissuasion nucléaire française. A la suite de l'arrêt desessais nucléaires, il met en oeuvre le programme Simulation, qui s'appuie sur d'importantsmoyens expérimentaux et de calcul (Airix, Laser Mégajoule, Supercalculateur Tera). En ma-tière de propulsion nucléaire (sous-marins, porte-avions), le CEA est notamment responsablede la conception et de la maintenance des réacteurs. Il intervient en�n dans les instances natio-nales et internationales, où il contribue à la surveillance du respect des traités internationauxtels que le traité d'interdiction complète des essais nucléaires. Il participe à la lutte contre laprolifération des armes nucléaires.
1.1.2 La Direction des Sciences de la Matière
La Direction des Sciences de la Matière (DSM) contribue à approfondir nos connaissancesfondamentales sur la structure de la matière, à appliquer ces connaissances dans le domainede l'innovation industrielle, spécialement dans les secteurs stratégiques pour le pays, à étudierde nouvelles formes d'énergie compatibles avec un développement durable et équitable. Sesdi�érents laboratoires sont abrités par les Centres d'Études du CEA à Saclay, Grenoble etCadarache, et également par des structures mixtes telles que le GANIL à Caen.
1.1.3 Le Département de Recherche sur l'État Condensé, les Atomes et lesMolé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 ettechniciens de la recherche dans 8 Services ou laboratoires de recherche, dont la plupart sonten association avec d'autres partenaires (CNRS, École Polytechnique,...). Ses activités derecherche fondamentales sont orientées vers les technologies de l'information et de la santé, enparticulier en nanoscience, et les énergies du futur. Les chercheurs du DRECAM développentet maîtrisent de nombreuses techniques expérimentales à des échelles du nanomètre ou del'attoseconde, ils sont aussi très présents autour des grands instruments européens.
1.1.4 Le Service de Chimie Moléculaire
Le Service de Chimie Moléculaire (SCM) est un service de recherche fondamentale qui re-groupe une cinquantaine de personnels statutaires (CEA, CNRS, université) et une vingtained'étudiants de tous niveaux. Les di�érentes études qui y sont menées peuvent être rassemblées
12
1.2. LA DIFFUSION DES RAYONS X
Fig. 1.1 � Édi�ces auto-assemblés : structure en sandwich d'un nanodisque ultra-rigide eticosaèdre creux.
en deux thèmes majeurs : la nanochimie et la radiolyse, avec comme domaines d'applicationsprincipaux, les technologies de la santé, les nanosciences et l'amont de programmes nucléairesdu CEA.
1.1.5 Le Laboratoire Interdisciplinaire sur L'Organisation Nanométriqueet 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éoriciensdans un objectif commun de compréhension de la structure et des propriétés de �uides orga-nisés ou de solides nanostructurés. Le laboratoire dispose de cinq appareils de di�raction oudi�usion de rayons X, possédant chacun des caractéristiques propres qui permettent l'étudede divers systèmes organisés tels que ceux montrés sur la �gure 1.1.
1.2 La di�usion des rayons X
1.2.1 Les Rayons X
Les rayons X sont une forme de rayonnement électromagnétique dont la longueur d'onde estcomprise 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 per-cuter une anode généralement en cuivre. Le ralentissement des électrons par les atomesde 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 électronsvont émettre un rayonnement. Celui-ci est utilisé dans des "lignes de lumière".
13
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 principauxdé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 aupassage 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'informationlumineuse sous forme de pixels et transformant ainsi les photons X en image.
1.2.2 La di�raction des rayons X
Lorsqu'une onde rencontre un obstacle pas complètement transparent d'une taille relativementpetite par rapport à la longueur d'onde, se produit un phénomène d'interférences, appelé aussidi�raction.
14
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 dispositionest la formation de réseaux de plans. Les distances interatomiques des cristaux forment desréseaux e�caces pour la di�raction des rayons X. La loi de Bragg (voir �gure 1.4) dit que lesrayons X de longueur d'onde λ sont ré�échis à un angle θ par un réseau cristallin possédantune distance d entre deux plans tels que : λ = 2d · sin(θ)
d
θ
Rayons X
Réseau cristallin
Fig. 1.4 � A gauche, loi de Bragg (λ = 2d · sin(θ)), à droite image de di�raction de rayons Xsur un cristal
Si on connaît la longueur d'onde λ, en mesurant les angles de di�raction θ obtenus sur desimages de di�raction, tels que montrés sur la �gure 1.4, on peut calculer les distances inter-planaires d qui existent dans le cristal. On peut ainsi mesurer les propriétés structurelles descristaux. 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 cristaltrè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 mono-chromateurs.
Di�ractomètre
Un di�ractomètre (voir �gure 1.5) est un instrument permettant de mesurer la di�ractiondes rayons X. Il est composé en général d'un générateur de rayons X, d'un monochromateurqui permet de sélectionner une longueur d'onde, d'un goniomètre qui permet de mesurer desangles entre les di�érents éléments de l'instrument et de positionner un échantillon, et d'undétecteur.
Les techniques o�ertes 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 dedi�ractomètres, qui se distinguent par les possibilités o�ertes de faire varier les angles entre lesdi�érents éléments qui le compose (�gure 1.6). Un di�ractomètre classique permet de réaliserun spectre θ − 2θ : on mesure la quantité de rayons X di�ractés à un angle 2θ, en fonctionde l'angle θ incident. On peut également se placer à un angle θ donné et réaliser des mesuresautour de l'angle 2θ. Il existe aussi des di�ractomètres dit à "4 cercles", qui possède quatre
15
CHAPITRE 1. CONTEXTE
Source de rayons XDétecteur
Echantillon
θ2θ
Monochromateur
Fig. 1.5 � Schéma et photographie d'un di�ractomètre.
axes de rotation. Du fait de la complexité ds mouvements les axes des di�ractomètres sontmotorisés et gérés par un système informatique.
Source de rayons XDétecteur
θ2θ
Source de rayons X
θ2θ
θ − 2θ 2θ constant
Détecteur
4 cercles
Fig. 1.6 � Di�érents types de mouvements sur un di�ractomètre.
1.2.3 Technique de di�usion des rayons X aux petits angles
Les rayons X interagissent également avec les électrons et peuvent fournir des informations surla �uctuation de densités électroniques dans une matière hétérogène (solides, liquides ou gels).Dans ce cas, les rayons X sont di�usé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 échan-tillon. L'intensité di�usée est collectée. Les expériences de di�usion de rayons X, telles quedécrites au chapitre suivant (p. 23), sont conçues pour mesurer cette intensité à de petitsangles, a�n 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 dansdes fûts. Or, le verre s'altère au contact de l'eau et sous de fortes températures, conditions quel'on peut retrouver lors d'un stockage souterrain. La compréhension de l'altération des verres
16
1.2. LA DIFFUSION DES RAYONS X
Rayons X
Echantillon
Faisceau diffusé
100 150 200 250 300 350
100 150 200 250 300 350
150
200
250
300
350
150
200
250
300
350
D:\data\saxs\ot-2005-06-20-b-octadec-1800.dat.spe
Columns
1.E-2 0.1 1 10 100 1000
Intensity
Row
s
Fig. 1.7 � Schéma de principe de la di�usion des rayons X aux petits angles et image obtenueavec un échantillon possédant une structure organisée.
est donc importante pour le CEA.Des études menées au laboratoire1 ont consisté à accélérer arti�ciellement 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 di�usion des rayons X aux petits angles. Sur la �gure 1.8, on peut voirles spectres de di�usion 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) etWAXS (WideAngle X-Ray Scattering) qui permettent de mesurer la di�usion des rayons X à des anglesdi�é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.
Enveloppe du verre intact
Enveloppe du coeur intact
Enveloppe du verre altéréGrain de
verre
tVerre altéré
Verre non altéré
Qua
ntité
de
rayo
ns X
diff
usés
Angle de diffusion
USAXS SAXS WAXS
Fig. 1.8 � Schéma de principe de la di�usion des rayons X aux petits angles et image obtenueavec un échantillon possédant une structure organisée.
116, Spalla, O., 2003, JOURNAL OF APPLIED CRYSTALLOGRAPHY
17
CHAPITRE 1. CONTEXTE
18
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-ciimpose de dé�nir dès le début du projet quatre paramètres : les résultats à atteindre, lesdélais à respecter, les ressources à mettre en place ou disponibles, et les risques à identi�er.Des marges de manoeuvre doivent être prévues au lancement du projet.
Résultats
RisquesRessources
Délais
Fig. 2.1 � Les quatre paramètres à dé�nir pour un projet selon la méthodologie du CEA
2.1.1 Résultats à atteindre
Nous avons choisi le montage "Ultra Small Angle X-ray Scattering" (USAXS) qui servira deprototype.L'objectif de ce projet est de mettre au point une nouvelle architecture de contrôle-commande
19
CHAPITRE 2. ETUDE PRÉLIMINAIRE
qui doit interfacer tous les instruments présents sur le montage existant a�n d'améliorer lefonctionnement actuel. Il s'agit d'une refonte totale du système informatique et peu d'élémentslogiciels 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 faciled'un driver, et l'ajout de nouveaux instruments ou de nouvelles fonctionnalités. L'architecturedoit être modulaire et robuste. Dans l'interface homme-machine (IHM), on veut ajouter/mo-di�er de nouveaux appareils sans modi�cation majeure de code. Le système développé doitpouvoir ê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 possi-bilité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 scienti�ques spécialistes dumontage, 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
2.1. GESTION DU PROJET - OBJECTIFS
2.1.2 Tests à réaliser
A�n de véri�er et valider les di�érents objectifs, voici pour chaque fonctionnalité demandéeles 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 basiquesfournis par les constructeurs
Développement d'une couche d'abstractionmatériel-logiciel
Test du matériel avec les outils basiques pro-posés par la nouvelle couche d'abstractionmatériel-logiciel.
Développement de l'IHM Test du matériel avec les outils proposés parl'IHM.
Reprise logique expérience Test du bon fonctionnement de la logiqued'expérience sur des échantillons réels.
Ergonomie de l'IHM Test de l'ergonomie de l'IHM avec des uti-lisateurs de di�érents niveaux d'interaction.En mode "expert", on va modi�er la logiqued'expérience. En mode "novice", on utilisela 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 communi-quer 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 di�racto-mètre.
2.1.3 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 2006Exploration des possibilités techniques - Etatde l'art
1 mois Février 2006
Rédaction du cahier des charges 1 mois Mars 2006Développement 3 mois Avril-Mai-Juin 2006Mise au point et tests 3 mois Juillet-Août-Septembre 2006Rédaction de la documentation 3 mois Octobre-Novembre-Décembre 2006
2.1.4 Acteurs du projet
Le responsable du projet est Olivier Taché qui s'occupe des études et du développement. Leschercheurs du laboratoire qui seront les utilisateurs futurs participent à la rédaction du cahierdes charges et aux tests. On distingue les utilisateurs experts de l'expérience, qui vont spéci�er
21
CHAPITRE 2. ETUDE PRÉLIMINAIRE
la logique d'expérience, et les utilisateurs non spécialistes qui vont spéci�er les di�érentsrésultats auxquels ils s'attendent.Un responsable CEA valide les orientations stratégiques, tels que les choix de TANGO et dePython, permet de les généraliser au niveau du laboratoire et fournit les ressources nécessairesau déroulement du projet.
2.1.5 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ériencereste accessible pour les expériences)
2.1.6 Risques
A�n d'éviter tout problème qui pourrait compromettre le projet ou bien entraîner des délaisimportant, il convient d'identi�er et d'évaluer les risques.Le risque le plus important est la probabilité non négligeable d'une panne matérielle survenantsur l'expérience. En général les pannes sont résolues dans les cas les plus graves en quelquessemaines, mais cela pourrait bloquer la phase de tests.Un autre risque non négligeable serait l'incompatibilité entre le nouveau matériel (PC, nou-velles cartes,...) et le matériel existant sur l'expérience. Par exemple, on peut imaginer quela nouvelle carte GPIB ne pourrait pas communiquer avec les contrôleurs de l'expérience. Ilconviendrait alors d'étudier la possibilité de laisser coexister matériel informatique de nouvellegénération avec ancienne génération.En�n, on ne peut pas négliger la di�culté à maîtriser le développement des device serversTANGO. Il conviendra alors de prendre contact avec la communauté TANGO (située à Gre-noble ou Gif/Yvette) a�n de béné�cier d'une expertise ou d'une formation.
2.1.7 Marges de manoeuvre
Des marges de manoeuvre doivent être prévues dès le lancement du projet a�n de prévenirles aléas qui peuvent apparaître. Nous disposons de faibles marges au niveau des ressourceshumaines 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 e�et, si l'interface avec le matériel doit fonctionner parfaitement, l'ergonomie de l'interfacehomme-machine n'a pas besoin d'être forcément très poussée, ni de béné�cier d'une interfacegraphique.
22
2.2. SUJET D'ÉTUDE
2.2 Sujet d'étude
2.2.1 Montage USAXS
Fig. 2.2 � schéma de l'expérience de di�usion 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 di�ractomètre permet de mesurer la di�usion des rayons X aux très petits anglesgrâce à un montage original, dont le schéma est montré en �gure 2.2 et une photographie enpage 97. Les rayons X sont produits par un générateur à anode tournante. Ils sont rendusmonochromatiques 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électionnerprécisément les angles, et sont mesurés par un scintillateur. Un système de motorisation permetde faire varier l'angle (2θ) entre le faisceau incident et le faisceau di�usé mesuré. Les possibilitésde l'expérience sont aujourd'hui limitées par le système informatique. Il est en e�et très di�cilede faire évoluer les instruments (ajout de moteurs, mesures automatiques,...) sans e�ectuer degrosses modi�cations logicielles. A�n de pouvoir étendre les possibilités des expériences, noussouhaitons rénover le système de contrôle/commande.
2.2.2 État des lieux matériel
Sur l'expérience USAXS, voici l'inventaire des instruments et des di�érents matériels électro-niques (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
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")
CarteNI-GPIB
u
a
MC1 - IT6D CA22u
x
a
2a
c
MC2 - IT6D CA2
MC3 - IT6D CA2
SR400
SR400
Scintillateur
CarteE/S num
Atténuateurs
Obturateur RX
CarteAcquisition Analogique
Chambre Ionisation
u
RS232 Codeur Heidenain u
Interface Informatique Contrôleurs Capteurs
Actionneurs
PC
Fig. 2.3 � Schéma détaillé des di�érents matériels de l'expérience
2.2.3 État des lieux logiciel
Logiciels utilisés
Le logiciel USAXS3 est programmé en Visual Basic et s'occupe du contrôle des moteurs, del'acquisition sur le scintillateur, du contrôle des atténuateurs, de la sauvegarde des données, dutracé à l'écran. L'interface utilisateur (sous windows) est identique que se soit pour e�ectuerdes réglages ou pour lancer des acquisitions (ce qui revient souvent au même). Ce programmeest très peu modulaire. Si un des éléments est à modi�er, 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
2.3. PROBLÈMES EXISTANTS
Ce logiciel récupère les données sauvées par USAXS3 et e�ectue 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 lesmoteurs 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 demesure (générateurs, oscilloscopes, etc.). Normalisé sous la référence IEEE 488, GPIB est uneliaison 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'ensembledu bus. L'IEEE 488 dé�nit le protocole de communication entre tous les équipements d'un busGPIB. Il s'agit d'une interface logicielle dé�nissant la structure des échanges sur le bus (proto-cole des contrôleurs, ouverture des lignes, renvoi d'états standards, etc.). C'est un protocole detype 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 488est 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'ouver-ture 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 exploitablespar l'ordinateur. Elle permet de mesurer les valeurs de vide dans les enceintes du montage, etle courant produit par une chambre à ionisation.
2.3 Problèmes existants
2.3.1 Interface matérielle et logicielle
Les accès aux composants matériels sont incorporés dans le code du logiciel USAXS3. Al'heure actuelle l'ajout de nouveaux composants doit se traduire inévitablement par de grossesmodi�cations du code. De plus, le langage utilisé (Microsoft Visual Basic version 4) n'estplus 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 con�guration 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 con�guration informatique,incompatible avec le logiciel.
Ainsi, l'ajout d'éléments matériels ou une mise à jour logicielle signi�e inévitablement laréécriture complète du logiciel.
25
CHAPITRE 2. ETUDE PRÉLIMINAIRE
2.3.2 Logique d'expérience
Dans le logiciel USAXS3, la logique d'expérience est �gée. Il n'est pas possible de la modi�er.Il est possible d'interagir avec les di�érents composants matériels séparément, mais pas de lessynchroniser en dehors de la logique programmée.
2.3.3 Interface HM
L'interface homme-machine proposée est programmée en Visual Basic. Comme décrit aupa-ravant, celle-ci n'est pas évolutive. Au niveau ergonomie, on s'aperçoit quelle est soit tropcomplexe pour un simple utilisateur, soit limitée pour le scienti�que responsable de l'appareil.
2.3.4 Problèmes futurs
Le système actuel est obsolète et ne permet pas l'ajout de nouveaux composants. Ces nou-veaux composants peuvent être matériels (moteurs, capteurs,...) ou bien logiciels (programmesspéci�ques pilotant un matériel spéci�que, comme une caméra CCD par exemple). Ils peuventaussi être connectés à des ordinateurs di�érents, sous des systèmes d'exploitation di�érents.
2.4 Solutions proposées
2.4.1 Gestion des éléments matériels
La principale problématique du système existant est que la gestion des éléments matériels esttrop 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'utiliserune couche d'abstraction matériel-logiciel (voir �gure 2.4) qui "virtualise" les instruments. Parexemple, un capteur de position sera vu comme une variable "position" par l'application etnon comme une mesure de tension électrique sur la voie x de la carte n situé sur la machine1. Cette couche d'abstraction peut également permettre de distribuer les di�érents élémentssur un réseau.
Une autre problématique est la gestion des di�érents protocoles entre les éléments de l'expé-rience.
2.4.2 Gestion des éléments logiciels
Il apparaît clairement que les protocoles et langages de programmation utilisés et nécessaires aufonctionnement 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érielset logiciels.
26
2.4. SOLUTIONS PROPOSÉES
Machine 2Machine 1
ProtocoleGPIB
Contrôleurd'axes
moteurs
Acquisitionde
données
Contrôleurdétecteurs Capteurs
Réseau
Couche d'abstraction Matériel-Logiciel
ConfigurationMatérielle
E/SNumériques
Actionneurs
Application de physique
Traitement Numérique
Fig. 2.4 � Schéma de l'architecture du système proposé
2.4.3 Interface homme machine
Les interfaces utilisateurs proposées doivent correspondre aux demandes des utilisateurs se-lon leur niveau d'interaction avec le système, qu'il faut dé�nir. A certains niveaux, l'inter-face homme-machine (IHM) doit permettre de modi�er la logique d'expérience aisément. Ad'autres, elle doit permettre le déroulement de l'expérience avec le minimum de connaissancedu matériel, et a�cher des informations claires pour un scienti�que.
27
CHAPITRE 2. ETUDE PRÉLIMINAIRE
28
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 labo-ratoire. En général, chaque instrument de physique e�ectue des mesures ou des actions selonune logique programmée. La logique elle-même est souvent pilotée par un ordinateur de typePC, auquel sont envoyés les résultats (voir �gure 3.1).
3.1.1 Elements matériels
Le type et la vitesse de l'acquisition des données in�uent beaucoup sur le type de matérielutilisé.Pour des acquisitions relativement lentes, le contrôle-commande se fait souvent par des ins-truments dédiés et transmis au PC à travers une connection série RS232. Ce protocole est detype 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
CHAPITRE 3. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES DECONTRÔ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 com-munication avec l'appareil nécessite une carte GPIB spéciale. Plusieurs appareils peuvent êtrebranché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éci�ques que l'on insère dans les ordinateurs. Cescartes possèdent des processeurs embarqués qui permettent des traitement rapides des infor-mations.
3.1.2 Éléments logiciels
Beaucoup d'environnement logiciels permettent d'interfacer tout ce matériel. En général, leconstructeur du matériel fournit une application permettant de faire fonctionner immédia-tement l'appareil et également quelques "drivers" a�n de piloter l'appareil par un langagede programmation. Comme montré sur la �gure 3.2, dans le domaine du contrôle-commanded'expériences, les langages de programmation les plus répandus sont Labview de NationalIntruments, Microsoft Visual Basic et Visual C++.
3.1.3 Qu'est ce qu'une couche d'abstraction matériel-logiciel ?
A�n d'améliorer la rapidité et la modularité des développements, on peut mettre en place unecouche logicielle qui permet au langage de programmation d'accéder à certaines propriétésdes éléments matériels en faisant abstraction de la con�guration exacte et du protocole decommunication utilisé. On appelle cela une couche d'abstraction matériel-logiciel (voir �gure3.3). Par exemple, un appareil mesurant une température et branché sur le PC pourra êtreinterrogé directement par une variable "température".
30
3.2. SOLUTIONS COMMERCIALES
Langage de
programmation
Driversspécifiques
RS
232
t° g
Driversspécifiques
RS
232
t° g
Couche d'abstraction
Langage de
programmation
Fig. 3.3 � Schéma des briques logicielles permettant d'interfacer les di�érents appareils. Agauche, dans un système classique, le langage de programmation doit accéder directement auxdrivers ou aux fonctions des appareils. A droite, une couche d'abstraction matériel permetd'accéder aux valeurs physiques (c'est cela qui intéresse l'utilisateur) sans se préoccuper dumatériel.
National Instruments propose ce type de couche d'abstraction et la nomme Measurement andControl Services, mais cette solution est limitée aux appareils vendus par National Intruments.
3.2 Solutions commerciales
3.2.1 National Instruments
Description du système proposé par National Instruments
La société National Instruments1 est leader du marché des systèmes d'acquisition basés sur desPC. Elle propose un ensemble de solutions matérielles et logicielles (évidemment compatibleentre 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,...) estpiloté avec un ensemble de drivers qui sont uni�és et qui proposent une interface simpli�ée
1http ://www.ni.com
31
CHAPITRE 3. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES DECONTRÔLE-COMMANDE
Fig. 3.4 � Copie d'écran du logiciel MAX. On peut y voir sur la gauche que l'on a créé unevariable "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 Au-tomation 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 égalementpossible de con�gurer 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 unefonctionnalité intéressante. Cet utilitaire permet de créer des "voies" virtuelles. Grâce à unesérie d'assistants, on peut dé�nir une variable (appelée "température" par exemple) en spé-ci�ant 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 o�rentdes fonctionnalités intéressantes d'a�chage des données et de contrôle. Une programmationtextuelle classique peut être réalisée grâce à LabWindows ou des utilitaires pour Visual Studio(C++, Visual Basic). National Instruments propose une programmation purement graphiqueavec LabView
LabView
Le logiciel LabView de National Intruments est un logiciel de programmation graphique quipermet d'interfacer quasiment tous les appareils de contrôle-commande, les constructeurs four-nissant souvent les librairies LabView.
Principe de fonctionnement de LabView
La philosophie de LabView est de programmer à l'aide de diagrammes et d'icônes. Cettelogique s'apparente à un schéma électronique et est donc bien adaptée pour les applications
32
3.2. SOLUTIONS COMMERCIALES
de mesures. LabView utilise une programmation par �ux de données, ce �ux déterminantl'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, surune feuille de diagramme, comme montré sur la droite de la �gure 3.5, il relie données issuesdes objets de la face-avant par des �ux de données représentés par des �ls, à des composantsqui 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éecomme composant par d'autres applications. Cela rend les programmes très modulaires. Lescomposants 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'e�ectuer en parallèle, rendant LabView multitâche.En dehors de cette programmation par graphiques, l'intérêt majeur de LabView est l'im-portance des librairies de composants qui concernent en grande partie les applications decontrôle-commande. On y retrouve évidement l'accès au matériel de National Instruments.
3.2.2 Tests réalisés - Retour d'expérience
Nous avons réalisé plusieurs applications grâce à LabView dans le laboratoire. Sur la �gure3.6, on peut voir le diagramme développé pour la commande d'un appareil chargé de contrôlerun 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'a�cher le débit. Lorsqu'une consigne est modi�épar l'utilisateur, les informations sont transmises au VI, sous-programme, "gaz". Celui-ci estun autre diagramme chargé de communiquer avec l'appareil. L'utilisation des VI permet demasquer les détails à l'utilisateur.Cet appareil n'étant pas fourni par National Instruments, il n'est pas possible de mettreen oeuvre la couche d'abstraction matériel-logiciel décrite précédemment. Il faut développerun code spéci�que pour chaque appareil. Si ce type de programmation graphique est trèsperformant pour une application de contrôle ou de mesures continues, c'est plus délicat lorsqu'il
33
CHAPITRE 3. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES DECONTRÔ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 programmationqui pose problème.
Fig. 3.6 � Diagramme d'une application LabView permettant le contrôle d'une vanne derégulation de débit de gaz
3.2.3 Conclusion sur les solutions National Instruments
LabView se révèle être un logiciel agréable à utiliser et très e�cace. Les applications sont dé-veloppées rapidement sans grandes connaissance en programmation. L'interface graphique estréalisée conjointement à la logique d'expérience. Il est possible d'interagir avec une multitudede matériel grâce à des librairies fournies.Par contre, le code �nal est di�cile à relire, et la logique d'expérience doit être �xée. C'est unlogiciel 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érielNational Instruments changent souvent et que le support des anciennes cartes d'acquisitionn'est pas assuré. Il en est de même pour les versions de LabView. Une solution basée en-tièrement sur du matériel et logiciel National Instruments ne serait donc pas stable ou bienné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
3.3.1 Description
En dehors des solutions proposées par National Instruments, nous avons examiné les solutionsproposées dans le cadre des Grands Instruments, installations scienti�ques de grande ampleur,de nature nationale (SOLEIL), européenne (ESRF) ou internationale (CERN, ITER). Lescontraintes imposées, grand nombre de matériel hétérogène, grand nombre de langages deprogrammation, temps réels..., ne sont évidement pas les nôtres, mais ces solutions peuventparfaitement convenir.
34
3.3. SOLUTIONS OPEN SOURCE
Un avantage majeur de ces solutions est la disponibilité du code source et l'utilisation libredans 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éeconjointement par l'ESRF (European Synchrotron Research Facilities), le synchrotron Soleil etd'autres grands instruments Européens (ALBA et ELLETRA), c'est à dire nos collaborateursscienti�ques habituels.
3.3.2 TANGO
TANGO est un système de contrôle-commande distribué, orienté objets. C'est un bus logicielpermettant 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 ordi-nateurs 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 per-mettant 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 objetdistribué d'e�ectuer 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 "OpenSource", c'est à dire que l'accès à son code source est autorisé par son auteur. Les program-meurs 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 In-terface). TANGO fournit également des modèles génériques pour tous les éléments à contrôler,appelés "device servers". A�n d'avoir une �exibilité maximale, TANGO utilise une base dedonnées qui contient les propriétés et méthodes de tous les éléments. TANGO n'utilise quedes logiciels disponibles librement.
Fonctionnement de TANGO
TANGO fonctionne sur le principe d'un bus logiciel. On appelle bus, en informatique, unensemble de liaisons (câbles, pistes de circuits imprimés, etc...) pouvant être exploitées encommun par plusieurs éléments a�n de communiquer. Tous les éléments connectés au bus vontpouvoir dialoguer ensemble. Ainsi, les applications de con�guration, supervision (surveillancede 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 "deviceserver" qui possède les interfaces TANGO.Pour chaque device server, le programmeur dispose de méthodes et d'attributs génériques
35
CHAPITRE 3. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES DECONTRÔLE-COMMANDE
Device
(moteur…)Hardware
Environnements utilisateurs:MATLAB, IGOR,
python,
Bindings
SupervisionConfiguration Archivage
Bus Logiciel TANGO
Device
Hardware(mesure…)
interfaces
Fig. 3.7 � Schéma de principe du bus logiciel de TANGO
et peut écrire des méthodes et attributs spéci�ques. Une partie du code peut être généréeautomatiquement à l'aide des outils fournis. Il su�t d'ajouter le code permettant le contrôledu 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 attributsbien référencés et accessibles.
3.3.3 Tests réalisés - Retour d'expérience
A�n d'évaluer les possibilités de TANGO, nous avons réalisé quelques tests d'utilisation, quiont 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 con�-guration de la machine de test (Windows ou Linux) et de la distribution choisie. Chaqueapplication qui utilise TANGO peut être localisée sur des machines di�érentes, ou sur uneseule machine. Pour les tests, on a installé toutes les applications sur un seul PC équipé deWindows 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 con�guration qui vont se connecterà TANGO-HOST.
36
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 desdevice 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 ducurseur sur l'écran, et d'e�ectuer quelques opérations basiques, comme de centrer le curseursur 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'ajoutd'un device server, et on spéci�e son nom (ds_mouse/souris), la classe implémentée dans lecode (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éderpar l'intermédiaire d'une autre application Java AtkPanel (�gure 3.10). Celle-ci fournie uneinterface générée automatiquement à partir des propriétés du device server et permet de réaliserdes tests sur celui-ci. Ainsi un déplacement de la souris, modi�e l'a�chage et peut déclencherune alarme par un changement de couleur.
Les procédures d'installation et de con�guration des devices servers sont décrites en détail enAnnexe E.
37
CHAPITRE 3. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES DECONTRÔ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 programma-tion qui fera l'interface homme-machine.TANGO propose des "bindings", librairies qui permettent d'utiliser TANGO pour les langagesC++, Java, LabView, Igor, Matlab et Python (voir chapitre 4.3.2). L'idée est de tester l'uti-lisation du device server "Mouse" avec Python.Nous avons utilisé le binding PyTango (Python pour TANGO). Le code qui suit permet d'ac-céder à notre device server "souris", de lire sa position. On peut également lister tous lesattributs 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
3.3. SOLUTIONS OPEN SOURCE
Fig. 3.10 � 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 su�t alors de spéci�er l'adresse duTANGO-HOST, et les applications clientes telles que Jive ou Python accéderont à ce deviceserver de la même manière et de façon transparente.
3.3.4 Conclusion sur TANGO
La solution TANGO est délicate à aborder. Nous sommes loin du confort d'une solution com-merciale. De plus, l'écriture du code qui permet de contrôler le matériel, appelé device serverest à 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éve-lopper un morceau de code qui permettra d'utiliser au mieux l'instrument. Pour faciliter lesdéveloppements, TANGO fournit des outils pour générer des squelettes automatiques pour cecode 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 ayantdes interfaces matérielles di�érentes. La philosophie de TANGO permet en outre de dé�nir
39
CHAPITRE 3. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES DECONTRÔLE-COMMANDE
des device servers qui sont des ensembles d'autres device servers.TANGO modi�e le modèle de programmation classique et fait que chaque composant estcontrôlé par une application serveur répartie sur le système. TANGO masque ces détails etcela en fait une vraie couche d'abstraction Matériel-Logiciel. Nous avons ainsi la possibilité deréaliser une Interface Homme-Machine dans un langage non imposé.
40
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éci�cité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�érencied'une autre IHM. On peut dé�nir une expérience de physique comme un ensemble d'élémentsmatériels de mesure ou d'action (moteurs) interagissant ensemble en respectant une certainelogique. Un fonctionnement logique de l'expérience est nécessaire a�n de pouvoir ordonner desprocessus en fonction de conditions précises. Si on se place dans le cadre d'un ensemble dematé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émentsmaté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 philosophiesdi�é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 lesordonnant selon la logique de l'expérience.
41
CHAPITRE 4. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES D'INTERFACEHOMME-MACHINE POUR EXPÉRIENCES
Source de rayons XDétecteur
Echantillon
θ2θ
Monochromateur
Fentes
Angle 2θ
Qua
ntité
de
rayo
ns X
mes
urée
Fig. 4.1 � Schéma de principe du di�ractomètre SIEMENS qui permet d'obtenir un spectreindiquant la quantité de rayons X di�ractés par l'échantillon en fonction de l'angle 2θ
4.2.1 Exemple d'IHM
Penons pour exemple l'IHM qui permet de contrôler un di�ractomètre SIEMENS, qui estvraiment symbolique des problèmes posés et des solutions qui sont trouvées. Cet appareilest un di�ractomè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 spectred'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 rayonsX, 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'ilveut faire bouger et mesurer avec le détecteur. Même si cette logique est souvent identiquepour 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 ledéveloppeur. On propose à l'utilisateur un certain nombre de choix de mouvements possibles.Sur la partie gauche de l'interface, l'utilisateur spéci�e les moteurs qu'il désire déplacer, ainsique l'angle de déplacement. Les mouvements réalisés dépendent du type de séquence de mou-vement ("scan") demandé. Le résultat (quantité de rayons X mesurée en fonction de l'angleimposé) est tracé à l'écran sur la partie centrale.Cette interface est e�cace 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'interfacen'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 complexepour une utilisation simple et ine�cace pour une utilisation complexe.
42
4.2. SOLUTIONS À INTERFACE GRAPHIQUE
Fig. 4.2 � Copie d'écran de l'application XRD Commander, qui sert à piloter le di�ractomètreSIEMENS.
4.2.2 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 simpli�e l'interfaçage avec le matériel
43
CHAPITRE 4. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES D'INTERFACEHOMME-MACHINE POUR EXPÉRIENCES
grâce à un grand nombre de librairies et permet de développer l'IHM en même temps quele 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 lespossibilités o�ertes à l'utilisateur. Cela peut donner une interface complexe et chargée commeproposée en �gure 4.3.
4.2.3 Visual Basic
Le langage de programmation Microsoft Visual Basic est très utilisé dans le domaine ducontrôle-commande d'expérience du fait de sa relative simplicité et de son environnement dedé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, ilfaut proposer à l'utilisateur toutes les actions possibles, ce qui peut produire une interfacecomplexe.
Par exemple, on a réalisé une IHM pour un di�ractomètre expérimental sur lequel il fallaitsynchroniser des mouvements ("scan") et des acquisitions sur une caméra CCD. La �gure4.4 montre les possibilités o�ertes à l'utilisateur pour réaliser un "scan", déplacement d'unmoteur (rotation ou translation) et paramètres de mesure sur une image. On obtient au �nalune 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 montageexpérimental et qui puisse prendre en compte des paramètres compliqués et variés pour lesactions ou mesures à réaliser.
Dans ce cas, si Visual Basic est très pratique, n'étant pas orienté-objet il ne permet pas des'adapter à des éléments non dé�nis au préalable. Par exemple, il ne peut pas générer uneinterface graphique dynamiquement, en fonction par exemple de la liste du matériel.
4.2.4 Java
Le langage Java, est un langage de programmation orienté objet, développé par Sun Microsys-tems. 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 scienti�ques qui développentles applications pour leurs besoins spéci�ques. Par contre, ses possibilités en programmationd'IHM sont intéressantes : il existe de nombreuses librairies graphiques et il est possible degénérer dynamiquement une interface graphique. La �gure 3.10 (voir page 39) montre l'appli-cation ATK Panel qui est une application Java et qui utilise les fonctionnalités de TANGOpour créer une interface graphique en fonction des propriétés et opérations possibles sur unobjet matériel.Au niveau de l'a�chage de la logique expérimentale, il faudrait également proposer toutes lesactions possibles à l'utilisateur, ce qui n'est pas très satisfaisant.
44
4.2. SOLUTIONS À INTERFACE GRAPHIQUE
Fig. 4.3 � Interface générée grâce à LabView.
4.2.5 Conclusion
Les exemples précédents nous permettent de bien dé�nir les besoins et les attentes d'un utili-sateur envers une IHM d'expérience de physique :
45
CHAPITRE 4. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES D'INTERFACEHOMME-MACHINE POUR EXPÉRIENCES
Fig. 4.4 � Interface créée grâce à Visual Basic. En bas, le contenu des onglets permettant deparamétrer un scan
1. A�cher de manière graphique et dynamique les éléments présents sur l'expérience. Pou-voir modi�er leur propriétés et lancer des commandes basiques.
2. Pouvoir modi�er la logique d'expérience de manière simple en a�chant le résultat demaniè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 a�cher/modi�er les logiquesd'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 lecadre des grands instruments et du pilotage des di�ractomètres. Une solution à base de lignede commande a émergé et a conquis un public de scienti�ques.
46
4.3. SOLUTIONS À LIGNE DE COMMANDE
4.3.1 SPEC
SPEC est un langage de macro pour UNIX/Linux développé par Certi�ed Scienti�c Software1
depuis 1986. SPEC permet grâce à un interpréteur de saisir des commandes de manière tex-tuelle. L'interface graphique, montrée sur la �gure 4.5, est composée d'une fenêtre de saisie etd'une ou plusieurs fenêtres d'a�chage 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'a�chagegraphique des données
Les commandes sont très simples. Par exemple, la programmation de mouvements des moteursd'un di�ractomètre se fait de la manière suivante :
mv moteur1 0 déplace le moteur moteur1 en position 0ct 1 e�ectue une mesure pendant 1 seconde et l'a�chescan moteur1 -0.4 0.4 40 1 déplace le moteur de la position -0.4 à 0.4 avec 40 pas,
à chaque pas, mesure pendant 1 seconde et trace la courbemv moteur1 CEN déplace le moteur au centre de la courbe
Les commandes peuvent être sauvegardées dans des �chiers macros. Ainsi l'utilisateur gardeune sauvegarde exacte des commandes exécutées pour e�ectuer une mesure ou un type d'expé-
1http ://www.certif.com/
47
CHAPITRE 4. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES D'INTERFACEHOMME-MACHINE POUR EXPÉRIENCES
rience. SPEC propose une grande quantité de macros dédiées aux calculs à partir des donnéesexpérimentales. Les macros sont en grande partie élaborées et di�usées librement par les uti-lisateurs de SPEC.
Malgré tout, SPEC est un logiciel commercial avec un système de licence annuelle payante, cequi freine toute amélioration logicielle. D'autre part, le logiciel n'est pas multi-plateforme : ilest uniquement disponible sous Unix. Le langage de macro utilisé interdit l'utilisation de typesde données évolués : chaque variable doit être explicitement déclarée, mais n'est pas typée etil est impossible de générer d'autres variables dynamiquement. De plus, chaque variable a unevisibilité globale dans tout le programme, ce qui peut poser des problèmes lors d'appels defonctions : 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 descommandes, un avantage majeur d'un système basé sur des lignes de commandes est la pos-sibilité laissée à l'utilisateur de modi�er la logique expérimentale. En ce sens SPEC est trèsbien adapté. Ce langage peut se connecter au système TANGO mais chaque modi�cation ma-térielle, correspondant à un ajout de variable doit au préalable être déclarée, limitant par làles possibilités.
4.3.2 Python
Python, développé depuis 1989, est un langage de programmation orienté objet. Les qualitésde 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'autreslangages (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'ap-plications indépendantes,
� Python peut interfacer de nombreuses librairies graphiques (Tk, Qt, Qtk,...),� de nombreuses bibliothèques scienti�ques 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'applicationprésentée en �gure 4.2 et qui permet de piloter le di�ractomètre SIEMENS :
#--- Connection au diffractomètre et appel à la librairie DLL ---
meas=win32com.client.Dispatch('Meashost.Diffractometer')
meas.Connect("diffractometer!drec-ea-000716")
#--- On va initialiser le moteur "tube"
tube=drives.Item("Tube")
48
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 dif-fractomè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 mouvementd'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 in�nies.
Contrairement à SPEC, il n'existe pas de commandes spécialisées pour le contrôle-commandepour le langage Python. Cela reste à la charge du développeur. Mais Python est capablede générer dynamiquement des interfaces graphiques. De plus, ce langage n'est pas dédié audomaine du contrôle-commande et est très employé pour les applications scienti�ques. L'uti-lisation de ce langage pourrait o�rir des perspectives de calcul scienti�que sur des appareilset mesures.
49
CHAPITRE 4. PRÉSENTATION DES DIFFÉRENTS SYSTÈMES D'INTERFACEHOMME-MACHINE POUR EXPÉRIENCES
50
Chapitre 5
Conclusion - choix
Cette première partie nous a permis de présenter les possibilités techniques et l'état de l'artdans 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 homme-machine.
Pour la couche d'abstraction matériel-logiciel, une solution basée sur TANGO présente despossibilités très intéressantes et très puissantes, mais nécessite un apprentissage et une pro-grammation des interfaces, appelées "device servers". Il faut utiliser alors un système de deviceservers qui soit réutilisables et modulaire.Pour l'IHM, si une solution d'interface graphique, à l'aide de Java ou Python, permet de
TANGO
LOGIQUE D'EXPERIENCEInterface en ligne de commande
(Python)
CONFIGURATIONInterface graphique
(Java,Python)
Aide Ergonomique (Python)
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 e�cace pour programmer la logique d'expérience.On préférera plutôt une interface en ligne de commande grâce à Python. Il faudra cependantdévelopper un système d'aide en ligne ou aide graphique ergonomique a�n de guider l'utilisa-teur.
51
CHAPITRE 5. CONCLUSION - CHOIX
Je propose donc une architecture logicielle en pile, comme montrée sur la �gure 5.1, et reposantsur les fonctionnalités du système TANGO et de CORBA. Chaque composant est basé surun composant de plus bas niveau et rend un service à un composant de niveau supérieur. Lescomposants peuvent être programmés dans des langages di�érents, conformes à CORBA, etadaptés aux besoins. On utilisera Python et/ou Java pour l'interface graphique ou le calculscienti�que et C++ pour l'interfaçage matériel.
52
Deuxième partie
Réalisations
53
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érielsou logiciels de l'expérience. A�n de pouvoir réutiliser les composants logiciels, les accès sefont par des appels à des librairies qui peuvent implémenter les di�érents protocoles de com-munication avec les appareils. Ces librairies peuvent êtres utilisées sur tout le système. Parexemple, le logiciel LabView présenté au chapitre 3.2.1 fait un usage important de composantsréutilisables. Une telle architecture peut conduire à des problèmes complexes. Lors de l'ajoutou la modi�cation de composants, ces mises à jour doivent être répercutées à travers toutle système. De même, le système doit gérer l'accès simultané lorsque plusieurs applicationscommuniquent avec le même appareil et demandent des actions contradictoires.
Séquenceur
DétecteurMoteur Mesure
A B C
A
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 équipe-ments qui peuvent êtres variés (détecteur, moteurs, actionneurs, capteurs,...) et connectés surdes machines di�érentes. On aimerait pouvoir ajouter/enlever/modi�er les équipements del'expérience, sans revoir le système informatique. On veut pouvoir communiquer avec chaqueappareil, que ceux-ci puissent communiquer entre eux, tout en gardant une certaine �exibilité.
55
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 équipementsdistribués. C'est un système basé sur CORBA, qui permet de dé�nir une interface entre lesobjets et le système. Les actions dé�nies par cette interface peuvent être des attributs ou descommandes. Le fait d'invoquer une action sur un objet provoque un appel distant vers cetobjet ou bien un appel de fonction si l'objet n'est pas distant. TANGO fonctionne à la manièred'un bus logiciel qui permet à tous les composants du système de dialoguer ensemble, commemontré sur la �gure 6.2.
Séquenceur
DétecteurMoteur Mesure
Bus logiciel Tango
Interface TANGO Interface TANGO Interface TANGO
Interface TANGO
Base de données
Interface TANGO
Fig. 6.2 � Architecture de contrôle-commande utilisant TANGO
Il o�re également un modèle de programmation. L'idée de ce modèle est de traiter chaquecomposant, "device", de l'expérience comme un objet possédant ses propres propriétés, attri-buts 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 parexemple, un ensemble d'éléments matériels, groupe de moteurs, ou bien un programme decalcul, voire une combinaison de tout cela. Un "device server" (DS) est un programme serveurqui fonctionne en permanence et qui répond aux demandes d'actions (services) sur les "de-vices" par des programmes clients. Chaque élément du système, base de données comprise, estun device server et donc un composant indépendant. Les appels aux librairies sont incorporésdans 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 nomtel que : usaxs/Motors/theta_Motor. Le nommage des devices est laissé à l'appréciation del'utilisateur.
Dans la suite du chapitre, tous les exemples feront référence à ce device theta_motor quipermet 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éveloppementset 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
6.1. FONCTIONNEMENT GÉNÉRAL DE TANGO
1
Interface CORBA
Commandes AttributsGénériques Spécifiques
InitStateStatus
OnOff - position
Device S
erver
Génériques Spécifiques
Système de contrôle fournisseur (dll, librairies, commandes RS232,...)
Bus Logiciel TANGO
Propriétésspécifiques
Nom duServer Gpib
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 con�guration du device server lors de sondé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 in-formations disponibles à travers le système. Chaque attribut possède également des propriétés(unité, format d'a�chage, commentaires, description,...) qui sont dé�nis et modi�ables dansla base de données.Il est possible de demander un stockage des valeurs pour chaque attribut, a�n de garder unhistorique. 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înesde caractères,...) sont prédé�nis et sont issus de types de données de CORBA. De la mêmemanière, les états des device servers sont prédé�nis et correspondent à di�érents états que l'onpeut retrouver dans un système de contrôle commande : ON, OFF, MOVING, FAULT, ALARM,... Achaque état est associé une couleur (vert pour ON, blanc pour OFF,...) que l'on retrouve dansles di�érentes interfaces graphiques développées pour les tests, ou monitoring (comme Astorp64, AtkPanel p39, ou Synoptic p64)
57
CHAPITRE 6. TANGO
Les applications clientes ne s'adressent plus véritablement à un matériel mais à un programmeserveur. En ce sens, le système TANGO constitue une véritable couche d'abstraction matériel-logiciel.
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 con�guration 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 Source3. Lors de l'installation, il faut déclarer MySql entant que service Windows qui s'exécute automatiquement. Sur une machine cliente, il fautdéclarer une variable d'environnement TANGO-HOST contenant le nom de la machine quihé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 lesrequêtes des applications TANGO.
L'équipe TANGO fournit un exécutable pour Windows qui va installer TANGO, ainsi quetoutes les librairies nécessaires. Il faut ensuite con�gurer un certain nombre de variables d'en-vironnement, comme le nom de TANGO-HOST par exemple, ou le chemin de OmniOrb,...
6.3 Fonctionnement d'un device server
Un device server peut être écrit en langage Java ou bien en C++, qui sont tout deux deslangages 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�érentsmaté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èlecomporte deux classes principales. La classe deviceImpl implémente CORBA et permet d'ini-tialiser le DS en se connectant à la base de données. La classe deviceClass implémente toutce qui est spéci�que au device, comme les commandes, les attributs,...
La compilation du device server donne naissance à un �chier exécutable qu'il faut enregistrersous un nom d'instance dans la base de données TANGO. Dans un même �chier exécutable, ilest possible de créer plusieurs instances d'un même device ayant des propriétés di�érentes etpouvant contrôler des matériels di�érents. Ainsi comme montré en �gure 6.4, trois matérielsdu 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 nomd'instance di�érent.
1disponible sur http ://sourceforge.net/projects/omniorb2version Java 2 Standard Edition disponible sur http ://java.sun.com/j2se/3http ://dev.mysql.com/
58
6.4. DÉVELOPPEMENT D'UN DEVICE SERVER
Exécutable
usaxs/Motors/theta_Motor
usaxs/Motors/2theta_Motor
usaxs/Motors/alpha_Motor
saxs/Motors/passeur_MotorMotor.exe
Motor_usaxs
Motor_Saxs
theta
2theta
alpha
passeur
Motor.exe
Instance Device Nom du device
Machine 1
Machine 2
Classe motor
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émenterdes devices di�érents dans un même serveur. Cela permet de regrouper dans un seul exécutableplusieurs 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 uneclasse Motor contrôlant un moteur qui a besoin du protocole GPIB. Les connexions entreles di�érents devices, se font dans un même exécutable par des appels de fonctions. Ce typed'implémentation est transparente pour l'application �nale, qui accède aux device serversnormalement.
Exécutable
usaxs/config/gpib1
usaxs/Motors/theta_Motor
usaxs/config/gpib2
Motor_MC GPIB1
theta
GPIB2
MotorGPIB.exe
Instance Device Nom du device
Classe motor
Classe protocoleGPIB usaxs/config/2theta_Motor2theta
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 (phasede conception), puis le code source généré est modi�é dans un éditeur (phase de codage).
59
CHAPITRE 6. TANGO
6.4.1 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 ser-vers 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 foistous ces éléments dé�nis, on peut demander la génération du code C++ ou Java, ainsi que ladocumentation. Celle-ci est générée à partir des informations fournies. Les device servers ontainsi tous une documentation uniforme. Pogo véri�e si des modi�cations du code ont eu lieuentre chaque génération. Le développeur peut alors modi�er 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 pourl'implémentation des classes. Par exemple, pour le device server de la �gure 6.6 qui ne possèdequ'une classe, sont générés les �chiers suivants :� main.cpp
� ClassFactory.cpp
� MCMotor.cpp
� MCMotor.h
� MCMotorClass.cpp
� MCMotorClass.h
60
6.4. DÉVELOPPEMENT D'UN DEVICE SERVER
� MCMotorStateMachine.cpp
6.4.2 Implémentation du code
Pour la mise au point �nale et la compilation, nous avons utilisé Microsoft Visual C++ version6. Sous environnement Windows, les librairies TANGO nécessitent cette version de compila-teur, qui semble la plus stable. En pratique, seuls les �chiers MCMotor.cpp et MCMotor.h sontmodi�és.
Déclarations
Dans le �chier .h �gurent toutes les déclarations des fonctions et variables qui sont implémen-té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
//-------------------------------------------------------------
/**
* @name 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;
/**
* @name IT6CA2Motor methods prototypes
*/
/**
* reset the memorized faults on the hardware if necessary
* @exception DevFailed
*/
void reset();
61
CHAPITRE 6. TANGO
Les propriétés gpibserverName et axisNumber du device server sont déclarées comme desimples variables, et utilisables en tant que tel. De la même façon, les commandes, parexemple reset(), sont déclarées et utilisables comme de simples fonctions. Les attributs dispo-nibles sont accessibles par l'intermédiaire de deux variables, pour lecture-écriture. Par exempleattr_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 devalidation des propriétés. Ces propriétés sont modi�ables uniquement lors de la déclarationdu device server dans la base de données, grâce à l'application Jive comme décrit au chapitre6.6.1. 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édiairede fonctions de la classe DeviceProxy. Il est alors possible de demander la réalisation decommandes et de lire/écrire des attributs. L'exemple suivant permet d'exécuter la commandeWriteRead 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 fonctioncorrespondante 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 a�chagesdes 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
6.4. DÉVELOPPEMENT D'UN DEVICE SERVER
write_command(cmd);
}
Attributs
Lorsque l'on veut modi�er 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 etAttribute. 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 ledéveloppeur insère les appels aux librairies ou les di�érents protocoles permettant de commu-niquer 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
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
6.6.1 Jive
Jive est une application client qui permet de gérer les device servers en se connectant à la basede donnée TANGO. On peut ajouter de nouveaux DS, modi�er leur propriétés et e�ectuer destests sur des attributs et commandes. Il est également possible de générer di�érentes instancesd'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 basede donnée TANGO, et à droite, l'état du device server selectionné. Par un menu contextuel,on peut modi�er ses propriétés (voir �gure en page 75), ses attributs, ou réaliser des tests. Enannexe, on trouvera la procédure permettant de déclarer un device server grâce à Jive. Cesfonctionnalités sont importantes et démontrent les possibilités du système TANGO à installersimplement un matériel virtuel.
6.6.2 Astor
Lorsque le device server est enregistré dans la base de données et correctement con�guré,l'exécutable serveur tourne en permanence. On utilise l'application Astor a�n d'automatiserles 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émarragepeut être hiérarchisé a�n de respecter les dépendances des serveurs. Les exécutables sont alorsconsidérés comme des "services" Windows. Les services sont des programmes qui s'exécutentau démarrage de Windows. Par la suite ils continuent de fonctionner. L'interface Astor permetde les arrêter et de les relancer.
6.6.3 Synoptique
L'application JDraw, présentée sur la �gure 6.9 est programmée en Java. Elle utilise des com-posants graphiques nommés ATK qui permettent de représenter génériquement des attributset commandes de device servers TANGO. Elle permet de placer ces composants dans unefenêtre. Lors de l'exécution grâce à un Viewer, il est possible de visualiser les valeurs de cesattributs, avec des couleurs qui re�ètent les états des DS. Le rafraîchissement de l'a�chage sefait toutes les secondes, mais est paramétrable. On peut également e�ectuer des actions sur lesDS grâce à des boutons. Ainsi on réalise facilement un synoptique, représentation graphiqued'une expérience, sans aucune ligne de programmation.
64
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 di�cile à maîtriser. En e�et,il existe de nombreux paramètres à spéci�er pour une installation correcte, un modèle de
65
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 serveret 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 permetde simpli�er le développement des serveurs. Le code est plus clair et compact, les erreurs de
66
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 interagissentparfaitement, même s'ils sont situés sur des machines di�érentes, ou utilisent des protocolesde communication (GPIB, RS232,...) di�érents.
67
CHAPITRE 6. TANGO
68
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 commeun programme serveur communiquant avec un matériel (device) ou bien un programme decalcul, ou bien un ensemble de tout cela. Les device servers peuvent être également clientsd'autres device servers. Dans notre architecture on s'est attaché à être modulaire et exploiterces possibilités a�n de pouvoir réutiliser les serveurs.
Si on veut proposer des fonctionnalités de haut-niveau à l'utilisateur ou bien à une applicationscienti�que, un device server doit implémenter un protocole de communication avec l'instru-ment, une interface de contrôle du matériel et une interface utilisateur. On peut développer
Interface Matériel
Interface de communication
Interface Utilisateur
Matériel
Haut niveau
Bas niveau
Niveau intermédiaire
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, maissimples et paramétrables, comme schématisé sur la �gure 7.1. Dans la communauté TANGOles deux approches cohabitent.
Nous avons choisi la deuxième méthode. Pour que chaque device server soit modulaire, on va
69
CHAPITRE 7. ARCHITECTURE DE DEVICE SERVERS
utiliser au maximum les possibilités de paramétrage des propriétés des serveurs. En généralsur tous les devices de niveaux élevés, il faudra spéci�er 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 lesappareils 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'e�ec-tuer 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 DSpermet de convertir les pas moteurs en radians ou en mm. De la même manière, la mesure surdes jauges à vide réalisée par une carte National Instruments est gérée par un device serverd'acquisition, qui est lui-même serveur d'un DS permettant de convertir les données.
Contrôleur Moteurs
GPIB
Evaluateur d'expression(pas moteurs radians)
Rotation
NiDAQ(acquisition)
Jauge à vide
Evaluateur d'expressionVolts mbar
Haut niveau
Bas niveau
Niveau intermédiaire
Fig. 7.2 � Chaîne des device servers pour le contrôle de moteurs, ou pour la mesure d'unejauge à vide.
La communauté TANGO maintient à jour une liste de devices servers accessibles librement1.Certains des devices servers qui suivent sont des adaptations de device servers existant (inter-face GPIB ou PicoAmpèremètre). Les autres sont des "créations originales" et également misà disposition de la communauté TANGO à travers un site Internet2.
7.2 Device servers de bas niveau
Les serveurs de bas niveau communiquent directement avec le matériel ou bien implémententun 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. Cesserveurs sont fondamentaux puisqu'ils sont la base de tout le système. Ils sont généralementréutilisés pour communiquer avec di�érents appareils.
1http ://www.esrf.fr/Infrastructure/Computing/TANGO2http ://www-drecam.cea.fr/scm/lions
70
7.2. DEVICE SERVERS DE BAS NIVEAU
GPI
B D
evic
e
Con
trôl
eur
IT6D
CA
2
Eval
uate
ur
mat
hém
atiq
ue
Con
trôl
eur
SR40
0
Sing
le A
nalo
gic
Inpu
t
Pico
Ampè
rem
ètre
Kei
thle
y 61
5
Dig
ital I
nput
-Out
put
Dig
ital I
nput
-Out
put
Shut
ter
Filte
rs
GPI
B D
evic
eG
PIB
Dev
ice
Mot
eurs
Mic
ro-C
ontr
ôle
Con
trôl
eur
SR40
0Pi
co A
mpè
rem
ètre
Jaug
es à
vid
eAt
ténu
ateu
rsO
btur
ateu
r RX
Dev
ices
Ser
vers
Eval
uate
ur
mat
hém
atiq
ueEv
alua
teur
m
athé
mat
ique
Eval
uate
ur
mat
hém
atiq
ue
pas
mot
eur
radi
ans
radi
ans
vec
teur
d'o
nde
Am
père
pic
oAm
père
V
m
bar
Mat
érie
l
Fig. 7.3 � Carte complète de tous les devices servers utilisés pour l'expérience USAXS.
7.2.1 Interface GPIB
Le serveur GPIB implémente les fonctionnalités des DLL pour les cartes GPIB de NationalInstrument. Tout d'abord, il s'assure que la communication peut s'e�ectuer avec le matériel,
71
CHAPITRE 7. ARCHITECTURE DE DEVICE SERVERS
qui est identi�é par une adresse GPIB. Dans ce cas il o�re comme service la possibilité d'en-voyer 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.
7.2.2 Acquisition Analogique simple
Le serveur SingleAI pour "Single Analogic Input" utilise les DLL Ni-Daq fournies par Natio-nal Instruments. Il permet de réaliser une acquisition simple sur une voie de la carte NationalInstruments. Les cartes National Instruments permettent de réaliser des acquisitions de don-nées sur di�érentes "voies" dont le nombre, le débit, ... di�èrent. Il existe selon les cartesdes entrées-sorties analogiques et entrées-sorties numériques. Pour ce montage, nous avonsexpérimenté un nouveau système d'acquisition, appelé CompactDAQ et composé d'un boîtierrelié par connection USB à l'ordinateur et dans lequel il est possible d'insérer des modulesd'acquisition, de génération de tension ou d'entrée/sortie numérique,... On peut voir une pho-tographie de ce système en p. 99.Comme expliqué auparavant lors de la description du système National Instruments, ces dri-vers sont "uni�és" : normalement un unique driver permet de piloter pour toutes les cartesdu catalogue.
Mais nous avons été amené à utiliser di�érentes générations de cartes, et qui n'utilisaient pasles mêmes versions de drivers. Il existe des drivers NI-DaqOld et Ni-DaqMx... A�n d'avoirun device server qui puisse s'adapter à ces deux possibilités, j'ai implémenté les appels auxdi�érentes versions de DLL. On aurait pu développer deux device servers di�érents avec lerisque d'avoir des fonctionnalités di�érentes, et d'induire l'utilisateur en erreur. Le paramétragedes propriétés permet de spéci�er la version de driver.
Des device servers pour ces cartes o�rent de nombreuses possibilités et peuvent intéresserpotentiellement beaucoup d'utilisateurs.
Le serveur réalise une acquisition "simple" sur une seule voie de la carte. Les propriétés dudevice server permettent de spéci�er 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, quipermet le démarrage et con�guration d'un device server, il est possible d'ajouter la réalisationde mesures à travers l'expérience en quelques secondes. Celles-ci sont prises en compte par lesystème instantanément, o�rant des possibilités intéressantes (enregistrement sur de longuesdurées, a�chage de synoptique, ...).
7.2.3 Sortie Analogique simple
Lors des tests nous avons eu besoin de générer une tension analogique sur une carte NationalInstruments et nous avons développé un serveur Single AnalogicOuput. Celui-ci reprend lesfonctionnalités du device serveur précédent, mais en génération de signal.
72
7.3. DEVICE SERVERS DE NIVEAU INTERMÉDIAIRE
7.2.4 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" (pourDigital Input-Output). Celui-ci tient compte des di�érentes versions de drivers. Il permet enoutre de spéci�er quelles voies numériques sont utilisées en entrée ou sorties. Une conversionbinaire-entier est o�erte. Un attribut acceptant un nombre entier est donc accessible, o�rantun service qui sera utile aux serveurs de plus haut-niveau. Par exemple le nombre binaire 1001sera convertit en base décimale par 9.
7.3 Device servers de niveau intermédiaire
Les serveurs de niveau intermédiaire s'appuient sur des serveurs de bas-niveau a�n de com-muniquer avec le matériel. Ils sont en fait une interface logicielle �dèle des contrôleurs d'ins-truments et reprennent si possible toutes leurs fonctionnalités. Les serveurs développés pourle 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 tenircompte 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 re�et exactdu fonctionnement des contrôleurs. On retrouvera la documentation de ces device servers enannexe.
7.4 Device servers de haut niveau
Les serveurs de haut niveau s'appuient sur certaines fonctionnalités des serveurs de niveauxplus bas et pour o�rir une interface générique à l'utilisateur. L'idée est d'avoir une interfaceunique 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 ma-thématique.
7.4.1 Shutter
Un obturateur ("shutter") de rayons X est un dispositif qui obture le faisceau. Il peut existerplusieurs types d'obturateurs, mais on peut dé�nir deux actions ouvrir et fermer ainsi queles états associés.Le device server shutter correspondant aura deux commandes génériques open et close, les
73
CHAPITRE 7. ARCHITECTURE DE DEVICE SERVERS
deux états associés plus un état intermédiaire moving, s'il existe un temps de latence entrel'ouverture et la fermeture. Le paramétrage des propriétés du device server, vont nous per-mettre d'associer les commandes et états à un attribut à lire ou à écrire sur un serveur de plusbas niveau. Cela permet ainsi d'utiliser ce serveur générique avec des dispositifs d'obturationvariés.
Digital Input-Output
Shutter
Obturateur RX
0V-5VR
0V-5V
Open-Closeoptocoupleur
Open-Close
Fig. 7.4 � Device server shutter permettant de déclencher l'ouverture de l'obturateur dugénérateur des rayons X par l'intermédiaire d'une entrée-sortie numérique et d'un optocoupleur
A�n de déclencher l'ouverture et la fermeture de l'obturateur de notre générateur de rayonsX, nous allons utiliser ce serveur comme montré sur la �gure 7.4. Celui-ci va modi�er lavaleur de l'attribut d'un device server Digital Input-Output contrôlant une sortie numériqueet permettant de commander un optocoupleur. Un optocoupleur est un circuit électroniquequi permet, entre autre, de réaliser un interrupteur numérique : si une tension électrique estappliquée à ses bornes, le circuit est fermé. Dans le cas inverse, le circuit est ouvert.
7.4.2 Filtres
Sur les expériences de rayons X, un atténuateur est un élément matériel, constitué la plupartdu temps par une feuille de matériau dé�ni (par exemple 100 µm de Nickel), qui permetd'atténuer la puissance du faisceau de rayons X avec une constante connue. Sur l'expérienceUSAXS, 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 24 = 16 possibilitésd'atténuation.
Le dispositif montré en �gure 7.5, est contrôlé par une carte d'entrées-sorties numériques quipermet d'activer ou non un atténuateur. On l'interface grâce à un device server DigitalIO (voirp. 73). Des photographies du dispositif sont montrées en page 100.A�n de pouvoir utiliser un serveur générique, on peut considérer ce système comme un systèmede positionnement où chaque élément a une position bien déterminée, numérotée, et possédantdes caractéristiques uniques. Ces informations ne changent jamais. Ce device server que l'ona 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 concernantla position matérielle, l'identi�ant et la constante d'atténuation. Lorsque l'utilisateur demandele positionnement d'un atténuateur, il le fait en spéci�ant l'identi�ant. Le serveur va alors
74
7.4. DEVICE SERVERS DE HAUT NIVEAU
3
Digital Input-Output
Filters
Atténuateurs
1 2 4
Rayons X
Attenuateurs
0 - 5
V
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 basniveau qui interface le matériel.
De cette manière, on a pu ordonner les di�érentes combinaisons d'atténuateurs en fonctionde leur constante d'atténuation. L'utilisateur s'a�ranchit alors de la connaissance exacte dumatériel et dispose de commandes qui lui permettent de passer d'un atténuateur au suivantou précédent.
7.4.3 Evaluateur d'expression mathématique
Fig. 7.6 � Copie d'écran de l'interface Jive permettant de modi�er les propriétés d'un deviceserver.
Dans notre cahier des charges, nous avions la volonté de permettre à l'utilisateur scienti�qued'accéder aux valeurs physiques de l'expérience. Pour ce faire, il faut convertir des valeursd'attributs en d'autres unités spéci�ées par l'utilisateur. Nous avons développé un device ser-ver qui permet d'évaluer des expressions mathématiques dont les variables sont des attributsd'autres devices servers.
75
CHAPITRE 7. ARCHITECTURE DE DEVICE SERVERS
Fonctionnement
Ce serveur utilise des librairies C++ qui permettent d'évaluer des expressions mathématiquespouvant contenir plusieurs variables. Par l'intermédiaire des propriétés (voir �gure 7.6), il fautspéci�er :� les expressions Expression_read et Expression_write (une pour la lecture et une autrepour 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'éva-luation 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 plusieursjauges à vide. Les capteurs génèrent une tension électrique comprise entre 0 et 10 Volts enfonction de la valeur de vide, mesurée en mbar. Le fournisseur de l'appareil donne la formulemathématique suivante, qui permet de convertir les Volts en mbar :Pmbar = 10
6 (log(pmesure) + 3)où pmesure est la valeur mesurée en Volts et Pmbar la pression en mbar. Les mesures sont réali-sé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 scienti�ques aux utilisateurs et aux autresapplications clientes du système (comme l'a�chage du synoptique). Avec ce device server,le système permet une réelle abstraction du matériel. L'utilisateur interagit désormais avecl'expérience à l'aide d'unités scienti�ques sans avoir à connaître les détails de l'implémentationdu matériel.
7.5 Conclusion
Cette architecture à trois niveaux, permet une grande �exibilité dans l'utilisation des devicesservers.Ils sont facilement réutilisables. La gestion des serveurs se fait de manière graphique à l'aidede Jive. Il est possible d'ajouter à un serveur des devices, dont on modi�e les propriétés.
Cette architecture permet d'o�rir une interface générique à l'utilisateur et de préserver cettecouche de haut-niveau, même si les devices servers de niveaux plus bas sont modi�és. Ene�et, ceux-ci sont directement concernés par une modi�cation du matériel, mais il su�ra demodi�er les propriétés des serveurs de haut-niveau pour que tout fonctionne sans changementpour l'utilisateur �nal.On pourra ainsi remplacer un instrument de mesure par autre (possédant un protocole decommunication di�érent), et simplement modi�er les propriétés des devices servers de hautniveau.
76
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 defenêtres d'a�chage des données sous forme de graphiques, comme montré sur la copie d'écranen p. 90. Elle est réalisée grâce au langage Python dont l'interpréteur nous servira de fenêtrede saisie des commandes. On peut aussi exécuter les programmes de manière classique et lesrésultats s'a�cheront 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 librairiesPython. Pour communiquer avec le système TANGO, on peut utiliser la librairie pyTango. Al'usage cette librairie se révèle assez lourde à utiliser et nous avons développé des librairies deplus haut-niveau, pyTangodevice et pyTangoBeamline, qui permettent de manipuler les devicescomme des objets Python.
Au niveau de la logique d'expérience, nous avons donc développé des modules pour réaliser desscans et des enregistrements. Un scan permet d'exécuter une ou plusieurs actions de manièreincrémentale puis récupérer et a�cher le résultat graphiquement. Un enregistrement permetd'e�ectuer 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 proposeun outil qui génère la documentation d'un objet en fonction des commentaires placés dansle code. Il su�t de taper la commande help(objet) pour obtenir une aide en ligne dansl'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
CHAPITRE 8. INTERFACE HOMME-MACHINE
Bus logiciel Tango
pyTango
pyTangoBeamline
Scan
pyTangoDevice
Enregistrements
InterfaceH
omm
e-Machine
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 simplementleur nom dans l'interpréteur (voir p. 79).
8.3 Accès à TANGO
A�n de rendre les explications plus claires, tous les exemples qui vont suivre dans ce chapitreferont référence à un même device server usaxs/motors/theta_motor. Les exemples de codemontrés peuvent être saisis directement dans l'interpréteur Python, dans ce cas là ils sontpré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 estdonné 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épla-cements du moteur (cette valeur peut être modi�ée, mais elle est juste mémorisée par lesystè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 parTANGO,
� 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éplaceren position de référence.
78
8.3. ACCÈS À TANGO
8.3.1 pyTango
La librairie pyTango est développée par l'équipe de TANGO. Cette librairie permet de faireun 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 modi�er un attributSi cette librairie fonctionne très bien, elle se révèle �nalement lourde à utiliser dans l'inter-préteur Python, puisqu'il faut saisir 2 lignes de code pour lire un attribut et 3 pour écrire unattribut, 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 niveauqui permettent de manipuler les devices servers comme des objets Python et qui simpli�entles lectures/écritures des attributs.
8.3.2 pyTangoDevice
Utilisation
Le module pyTangodevice permet de se connecter facilement à un device server à partir deson 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(), Velocity_quick(),
* Added methods : State(), Status(), waitStateON() and get_attribute() for each attribute
Current device state is : ON
79
CHAPITRE 8. INTERFACE HOMME-MACHINE
L'appel de la classe pyTangodevice créée un objet qui possède des attributs et des commandesidentiques 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'a�ecter unefonction à une variable. Par exemple, on peut a�ecter 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 TANGOet 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 à unefonction e�ectuant 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 leurtour exécuter les appels aux fontions du module pyTango (tels que décris p. 8.3.1).Pour chaque commande, la fonction correspondante est a�ectée. Des méthodes State() etStatus() 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-cipeut changer d'état indiquant que l'action est en cours ou terminée mais le serveur "rend lamain" 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 lesactions 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
8.3. ACCÈS À TANGO
L'action terminée, le device server bascule dans un état ON. La fonction waitStateON() secontente donc d'interroger le serveur jusqu'à ce que celui-ci soit dans l'état ON. Or certainsappareils peuvent être submergés par un trop grand nombre de requêtes State. Une variableWAIT_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 a�ecter 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 a�ectation de variable. Par exemple, on lit l'attribut de lamanière suivante :
>>> theta.position
0.0
mais si on a�ecte cette variable-attribut à un autre objet Python, c'est logiquement la réponsede l'exécution de la fonction qui lui est a�ecté :
>>> theta.position=1000
>>> a=theta.position
>>> a
1000.0
>>> theta.position=0
>>> a
1000.0
Il est donc impossible de passer une variable-attribut par "référence". On pourrait utiliserles fonctions __getattr__(nom_attribut) et __setattr__(nom_attribut), qui font partiedu langage Python, mais nous avons jugé préférable (par convention des noms commençantet �nissant par __ représentent des membres privés de la classe) de créer une référence defonction set_nomattribut() et get_nomattribut() pour chaque attribut, ce qui se traduirapour notre exemple à l'ajout des fonctions set_position() et get_position().
En langage Python, un nom de variable ne peut pas commencer par un chi�re. Or cetterestriction ne s'applique pas à TANGO (programmé en C et Java). Un device server peut doncposséder des attributs ou commandes dont le nom commence par un chi�re. Pour contournerce problème, on décide que chaque fois que cela sera nécessaire, la lettre "t" commencera lesnoms de variables Python. Par exemple, l'attribut 2theta pourra être accédé par la variablet2theta. En principe, le fait que les noms de variables di�èrent entre un device server TANGOet 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 lectureet/ou écriture de l'attribut,
� pour chaque commande, une fonction correspondante,
81
CHAPITRE 8. INTERFACE HOMME-MACHINE
� une fonction State(),� une fonction Status(),� une fonction waitStateON().
8.3.3 pyTangoBeamline
Fonctionnement
L'utilisateur dispose désormais d'une représentation Python d'un device TANGO. On veutmaintenant accéder à tous les appareils disponibles sur l'expérience (donc déclarés dans labase TANGO). On utilise pour cela le module pyTangoBeamline.Le fonctionnement de ce module est relativement simple, il se connecte à la base de donnéesTANGO, et à partir d'un mot clé spéci�é par l'utilisateur, il va rechercher tous les devicescorrespondants dont le nom contient ce mot clé. Cela permet de lister une branche de l'arbredes device servers1. Pour chaque élément trouvé, on va générer un objet pyTangoDevice.Exemple :
>>> usaxs=Beamline("usaxs")
Welcome to usaxs ...
Connected to TANGO...
L'a�chage 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
1Par convention, on décide que tous les device servers présents sur une même expérience doivent êtrerassemblés sur une branche de l'arborescence des devices TANGO.
82
8.4. INTERFACE LOGIQUE D'EXPÉRIENCE
L'utilisation est identique à celle de pyTangodevice, et se fait par l'intermédiaire d'un objetPyTangoBeamline :
>>> usaxs.theta_Motor.position
0.0
8.4 Interface logique d'expérience
8.4.1 Environnement scienti�que
Par défaut, le langage Python n'est pas ourni avec des modules scienti�ques. Pour une utili-sation poussée, il faut installer des modules complémentaires :� Numerical Python o�re un nouveau type de tableau sous forme de matrices, ainsi que desfonctions et outils mathématiques permettant de les manipuler,
� Scienti�c Python est une collection de modules pour le calcul scienti�que,� Gnuplot permet de béné�cier d'un a�chage scienti�que sérieux des données.
Gnuplot
Gnuplot2 est un logiciel de "tracé" de données scienti�ques très complet possédant une in-terface sobre, mais e�cace, basée sur la ligne de commande. Contrairement à de nombreuxlogiciels, Gnuplot sépare l'a�chage graphique et les données, qui sont enregistrées dans des�chiers. L'a�chage est spéci�é par l'utilisateur, soit par l'intermédiaire de la ligne de com-mande, soit à l'aide d'un �chier de macros. Il est ainsi possible de tracer des graphes selon unmodèle rigoureux, dé�ni par l'utilisateur, avec des données di�érentes. Un grand nombre demodèles de graphiques est disponible.
La commande plot 'c:\gnuplot\DS-12-07-A.dsm' commande le tracé d'un graphe à partirdes données enregistrées dans le �chier DS-12-07-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 lasyntaxe.
Interface avec Python
Grâce à un module nommé Gnuplot.py, ce logiciel s'interface rapidement avec Python eton dispose de méthodes permettant d'y accéder et de lancer des commandes. La manière laplus 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'e�ectuer des tracés à partir de données sousforme de tableaux Python. L'intérêt principal de l'utilisation de Gnuplot est de se déchargerde l'a�chage des résultats.L'exemple suivant montre l'utilisation de ce module, et permet de tracer la courbe de la �gure8.2 précédente .
import Gnuplot
# Initialize Gnuplot
2http ://www.gnuplot.info
83
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-12-07-A.dsm'")
En�n, l'a�chage graphique est paramétrable à volonté en fonction des besoins de l'utilisateur.
8.4.2 Module de Scan
Nous avons besoin de réaliser des "scans", c'est à dire une ou plusieurs actions synchronisésde manière incrémentale puis récupérer et a�cher le résultat graphiquement. Par exemple,on veut déplacer un moteur 2theta de 118380 à 118420 pas avec un pas de 1 et mesurer laquantité de rayons X à chaque fois. Les données mesurées sont enregistrées.La classe scan va permettre à l'utilisateur de spéci�er les actions à réaliser avec les paramètresà incrémenter, les mesures, les options d'enregistrement et d'a�chage graphique. L'a�chagedes 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 classeAction. Une action doit donc être dé�nie en précisant :
84
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 listeOn 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 lorsquel'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 me-sures se di�érencient des actions, par le fait que leur exécution sera toujours identique (on nespéci�e 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 fonctioncountSR400() .
Fonctionnement
Lors de l'exécution, chaque action est réalisée avec une incrémentation des paramètres et lesmesures sont e�ectuées. La première action sert de référence. Elle doit posséder la séquencede paramètres la plus grande.L'a�chage des données se fait au fur et à mesure du scan. Il représente un graphe avec enabscisse les paramètres de la première action, et en ordonnées les mesures réalisée. Si plusieursmesures sont e�ectuées, plusieurs courbes s'a�chent. Il est possible de spéci�er des paramètresd'a�chage de Gnuplot en renseignant une variable GnuplotParameters. Le �chier de stockagedes données est spéci�é par DataFilename.
85
CHAPITRE 8. INTERFACE HOMME-MACHINE
La �gure 8.3 montre le résultat d'un scan. On trouvera en annexe la documentation de ce
Fig. 8.3 � Résultat d'un scan
module.
8.4.3 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 deviceTANGO. Un système de cadencement permet d'e�ectuer 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éci�er une mesure à réaliser. Il faut préciser un nom, sous formede chaîne de caractère, une fonction Python à exécuter, et éventuellement des arguments.
� start() permet de lancer l'enregistrement. On peut spéci�er le �chier dans lequel serontenregistrés les données, le nombre ou l'intervalle de temps entre deux mesures. Si le nombrede mesures est égal à 0, l'enregistrement a une durée illimité. L'arrêt est alors possibleen appuyant sur CTRL+C. Si l'intervalle de temps est nul, les mesures s'enchaînent sanscadencement.
Exemple
Dans l'exemple suivant, dont le résultat graphique est montré en �gure 8.4, on va enregistrerdeux attributs sur des devices servers TANGO :
from pyTangodevice import *
from pyRecorder import *
86
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 desdonnées mesurées.
>>> r.mean
array([ 0.0790973 , 0.25660846])
>>> r.mean[0]
0.079097297869565292
L'utilisateur peut donc utiliser ces données dans des programmes ultérieurs.
Fig. 8.4 � Résultat d'un enregistrement
87
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 a�chagedes 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 auxcomposants matériels de l'expérience. Il est possible de les synchroniser en utilisant des mo-dules 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 o�re également une grande �exibilité : le physicien peut développer uneséquence de réglages en saisissant les commandes dans l'interpréteur Python et par la suiteo�rir une interface limitée pour des expériences de routine. L'utilisateur non spécialiste saisitjuste une commande qui va déclencher la logique d'expérience. Il est également possible decréer interface graphique.
Les modules de scan et d'enregistrement ne sont pas spéci�ques à TANGO, ce qui permet leurréutilisation sur d'autres expériences.En�n, l'utilisation de Python permet de supprimer les barrières qui existaient jusqu'à présententre logique d'expérience et exploitation des résultats. Ainsi, ce langage étant utilisé à la foispour piloter l'expérience et pour les calculs scienti�ques il est possible d'enchaîner les mesureset le traitement des données de manière transparente.
0
2000
4000
6000
8000
10000
12000
119650 119660 119670 119680 119690 119700 119710 119720 119730 119740
Inte
nsiti
es
2 theta position
direct beam mesuredgaussian fit CENTER=119696
Fig. 8.5 � Scan du faisceau direct et �t gaussien
88
8.5. CONCLUSION - RÉSULTATS
Résultats
En concertation avec les physiciens du laboratoire, nous avons compilé dans un script Pythonusaxs.py toutes les fonctions utiles à l'expérience USAXS. Il regroupe des mesures automa-tiques de faisceau et des calculs. Par exemple, lors d'un scan du faisceau direct, la courbeobtenue est de forme Gaussienne. On a ajouté un �t, calcul de l'équation à partir des donnéesexpé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 fonctiondu nombre de coups mesurés par le compteur. Ainsi nous avons reproduit la logique d'ex-périence USAXS telle que dé�nie au chapitre 2. Les premiers résultats sont satisfaisants. La�gure 8.6 montre un spectre de di�usion de rayons X aux très petits angles obtenu avec unéchantillon de latex.
1
10
100
1000
10000
100000
1e+006
1e+007
1e+008
1e-005 0.0001 0.001 0.01 0.1
Num
ber
of c
ount
ed X
-ray
s
q (A-1)
2006-11-16-slatex
Rocking Curve
Fig. 8.6 � Spectre de di�usion de rayons X aux très petits angles obtenu sur l'expérienceUSAXS avec un échantillon de latex.
89
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 defenêtres d'a�chage graphique. Simultanément, il peut y avoir un a�chage du synoptique.
90
Conclusion générale - Perspectives
Bilan
La problématique principale de notre projet était de trouver une solution évolutive pour com-muniquer avec les éléments matériels et logiciels d'une expérience de physique. De toutesles solutions étudiées le système TANGO, qui est une implémentation de CORBA pour lecontrôle-commande, s'est révélée la plus e�cace. Nous avons réussi à mettre en place unearchitecture 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 pro-grammation Device Pattern et à un générateur de code. Les autres outils fournis permettentleur installation et leur con�guration. Il était prévu initialement une durée de développementd'une semaine pour chaque device server et cette durée a pu être ramenée à un jour à la �ndu projet. Grâce à la grande modularité de l'architecture, et à la simpli�cation des serveurs,les tests sont réalisés en quelques heures seulement et la documentation est générée dans lafoulée.Nous avons mis en place une architecture à plusieurs niveaux de device servers qui permettentde gérer les protocoles de communication, les interfaces avec les instruments, et o�rent àl'utilisateur ou l'application scienti�que des fonctionnalités pratiques. Ceci permet une vraieabstraction du matériel. Comme demandé dans le cahier des charges du départ, il est possibled'accéder et de con�gurer 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 con�gurer graphiquement chaque composant de l'expé-rience. L'application Synoptic permet en outre un a�chage graphique général, permettant enun clin d'oeil de superviser l'expérience.
Après avoir étudié divers systèmes d'interface homme-machine, nous avons choisi un systèmede saisie de commande qui est réalisé dans l'interpréteur du langage Python. Des modulesd'interface Python pour TANGO ont été développés a�n de simpli�er l'accès aux devices ser-vers. Les utilisateurs peuvent interagir directement avec les composants du système commede simples variables ou commandes Python. Cela correspondait à une demande forte de lapart des scienti�ques. Les avantages sont multiples. C'est le physicien qui saisit lui-même lescommandes et qui peut contrôler chaque instrument. Il est le mieux placé pour mettre au
91
. CONCLUSION GÉNÉRALE - PERSPECTIVES
point et modi�er la logique d'expérience. Celle-ci n'est plus �gée et peut évoluer en fonc-tion des besoins, mais la suite des commandes peut être imprimée, enregistrée et retrouvéeulté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 permetde 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. Lesscienti�ques 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'usagede Python permet aux scienti�ques de se passer de la présence d'un expert en informatiquepour l'écriture de la logique d'expérience. De plus, des outils mathématiques développés pourd'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, estqu'elle est basée intégralement sur des composants Open Source et gratuits. Le déploiement etla réutilisation de cette interface est alors facilitée puisqu'il n'y a aucune dépendance �nancièreni 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'utilisa-teur doit connaître les commandes, qui sont di�érentes pour chaque device server. Il faut donctravailler à une harmonisation. On peut aussi utiliser certaines distributions de Python quifournissent une "auto-completion", c'est à dire, qui proposent lors de la saisie, les méthodes etvariables associées à chaque objet. On peut également proposer une interface graphique pourla création des scans et des enregistrements.Un travail peut être mené en amont, au moment de la création des device servers, en uni�antles commandes des devices qui sont semblables. C'est ce que propose un modèle proposé parl'équipe TANGO, et qui permet d'o�rir pour certains types de matériel une interface com-mune. Par exemple, tous les serveurs de moteurs, quelque soient les fabriquants, auraient lesmêmes attributs et mêmes commandes.
Certaines possibilités o�ertes 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 nombred'informations échangés sur le système. Par exemple, l'application Synoptic, qui a�che unereprésentation graphique très pratique de l'expérience demande une mise à jour de tous lesattributs environ une fois par seconde. Avec la gestion des événements, l'a�chage est mis à jourseulement 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
Perspectives :
Depuis septembre 2006, il est possible de développer des device servers en langage Python. Celangage étant plus facile à utiliser que le C++ ou Java, le temps et la di�culté de dévelop-pement sont réduit. La portabilité des serveurs va être accrue, car un même code pourra êtreutilisé sous Windows et sous Unix, sans besoin de recompilation. Les utilisateurs non-expertsen programmation pourront également développer des serveurs.
Le système basé sur TANGO et Python, permet d'envisager les évolutions sur les expériencesavec sérénité. Suite à ce projet, plusieurs éléments vont être remplacés sur le montage USAXS,d'autres vont être ajoutés. Il su�ra de développer les device servers correspondants mais l'in-terface 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 lesystème d'exploitation Unix et il faut le synchroniser avec des composants logiciels sous Win-dows. Sans TANGO, nous aurions des di�culté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 ma-chines di�érentes. Ceci étant transparent pour l'interface �nale.
Cette architecture ouvre beaucoup de perspectives intéressantes. Elle va pouvoir être déployéesur 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 produiredes résultats plus nombreux, plus précis et de meilleure qualité.
93
. CONCLUSION GÉNÉRALE - PERSPECTIVES
94
Annexes
95
Annexe A
Photographies du montage USAXS
Fig. A.1 � Vue d'ensemble du montage USAXS
97
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
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
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
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
ANNEXE B. DOCUMENTATION DES DEVICE SERVERS DÉVELOPPÉS
102
Annexe C
Exemple de device server en langage
Python
103
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 PyTangoimport sysimport 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
""" 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 LastRespons e_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
ANNEXE C. EXEMPLE DE DEVICE SERVER EN LANGAGE PYTHON
106
Annexe D
Documentation des programmes
Python développés
107
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 : recordingnumber (if 0 then no limi, stop with ctrl+C) scheduler : time in seconds between eachmeasures (if 0 then no waiting time)
Class Variables
Name Descriptionmean mean of datas
Value : []datas list of datas recorded
Value : []g gnuplot instance
Value : ''
D.1.2 Variables
Name DescriptionNoParameter Value : ''FilenameTemp Value : 'c :\\python\\temp.txt'
GnuplotSeparator Value : '\t'
108
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 stringwhich 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 di�erent)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 DescriptionListAction Value : []
continued on next page
109
ANNEXE D. DOCUMENTATION DES PROGRAMMES PYTHON DÉVELOPPÉS
Name DescriptionListMeasure Value : []DataFilename Value : 'c :\\python\\temp.txt'
results Value : []GnuplotInstance Value : ''GnuplotParameters Value : ''GnuplotParametersFile Value : ''GnuplotCommand Value : ''OptionPlot Value : FalseOptionSave Value : False
D.3 PyTangoDevice
D.3.1 Variables
Name Description__author__ Value : "Olivier Tache <[email protected]>"
__date__ Value : "23 may 2006"
__version__ Value : 1WAIT_TIME Value : 0.3device Value : "tango/tangotest/1"test Value : pyTangoDevice(device)long_value Value : raw_input("Enter a value to send to tang-
otest : ")
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
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()
221.70272980813175
>>> 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 functionread_attribute('name').value
__setattr__(self, name, arg)
pass a value to an atribute name ex : >>> mydevice.name=10.2 check if attribute iswritable 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 DescriptionDeviceName Value : ""State Value : ""
111
ANNEXE D. DOCUMENTATION DES PROGRAMMES PYTHON DÉVELOPPÉS
Instance Variables
Name DescriptionStatus scanning attributes
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 treeex :
>>> 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
D.4. PYTANGOBEAMLINE
Methods
__init__(self, BeamlineName)
__repr__(self )
get a str representation of class
__str__(self )
get a str representation of class
113
ANNEXE D. DOCUMENTATION DES PROGRAMMES PYTHON DÉVELOPPÉS
114
Annexe E
Procédure d'installation d'un Device
Server
115
ANNEXE E. PROCÉDURE D'INSTALLATION D'UN DEVICE SERVER
L'objectif de ce petit guide est de montrer la facilité o�erte par l'application Jive pour installeret déclarer un Device Server dans la base de donnée TANGO. Il permet également d'expliciterles termes utilisés dans le système TANGO. Pour cela nous avons développé un Device serverPyDsSerial en langage Python qui est chargé de la gestion du protocole des ports Series.
Exécutable
manip1/protocoles/com1
manip1/protocoles/com2
manip1/protocoles/com3
manip2/protocoles/com1
manip2/protocoles/com2PyDsSerial.py
SerialExp1
SerialExp2
COM1
COM2
COM3
COM1
COM2
PyDsSerial.py
Instance Device Device name
Expérience 1
Expérience 2
ClassePyDsSerial
ClassePyDsSerial
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éci�ant le Server Name (nomde l'exécutable) et le nom d'instance.
116
Lancement du serveur
L'écran suivant invite l'utilisateur à lancer l'exécution du serveur. Ceci est fait en tapant lacommande 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éci�erles propriétés.
Nommage du device
Il faut nommer le serveur.
117
ANNEXE E. PROCÉDURE D'INSTALLATION D'UN DEVICE SERVER
Enregistrement des propriétés
On spéci�e 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
Bibliographie
[1] LabView. Manuel de l'utilisateur. 06 2005.
[2] Référentiel méthodologique des projets au CEA. 2005.
[3] The TANGO control system manual. 2006.
[4] Claude Delannoy. Programmer en C++. Eyrolles, 1993.
[5] J.-N Clot du Hecquet Ph. Esco�er-Gentile. Aide mémoire de C. Marabout informatique,1990.
[6] Andy Gotz. The abstract device pattern or how to implement multiple classes of thesame device type in tango.
[7] André Guinier. Théorie et technique de la radiocristallographie. DUNOD, 1964.
[8] André Guinier. Les Rayons X. Presses Universitaires de France, 1984.
[9] Nicolas Leclerc. Evaluation des frameworks ACS et TANGO pour le contrôle/commandede la machine SOLEIL. 2002.
[10] Nicolas Leclerc. Exigences relatives au Logiciel Commun de Soleil. 2002.
[11] Mark Lutz. Python : Pocket reference. O'Reilly, 2005.
[12] Alex Martelli. Python en concentré. O'Reilly, 2004.
[13] F. Né, I. Grillo, O. Taché, and T. Zemb. From raw image to absolute intensity : Calibrationof a guinier-mering camera with linear collimation. JOURNAL DE PHYSIQUE IV,10(P10) :403�413, 2000.
[14] Alain Pénicaud. Les cristaux, fenêtres sur l'invisible. L'esprit des sciences, 1999.
[15] L. Sicard, O. Spalla, P. Barboux, F. Ne, and O. Tache. A �rst contribution of the grazingincidence small angle x-ray scattering to the study of the corrosion of glass monoliths.JOURNAL OF NON-CRYSTALLINE SOLIDS, 345-46 :230�233, 2004.
[16] O. Spalla, S. Lyonnard, and F. Testard. Analysis of the small-angle intensity scatteredby a porous and granular medium. JOURNAL OF APPLIED CRYSTALLOGRAPHY,36 :338�347, 2003.
[17] Bjarne Stroustrup. Le Langage C++. Parson Education, 2000.
[18] Erich Gamma Richard Helm Ralph Johnson John Vlissides. Design Patterns : Cataloguede modèles de conception réutilisables. Vuibert, 1999.
[19] T. Zemb, O. Taché, F. Né, and O. Spalla. A high-sensitivity pinhole camera for softcondensed matter. JOURNAL OF APPLIED CRYSTALLOGRAPHY, 36 :800�805, 2003.
[20] Tarek Ziadé. Programmation Python. Eyrolles, 2006.
119
Top Related