Une architecture pour un système évolutif de contrôle...

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

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


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


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


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.


θ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


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


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


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


� χ : 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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


� 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


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


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


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


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


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


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é :


>>> a=theta.position

>>> a

1000.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


� 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


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


� 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


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


#---- 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


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


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


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


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


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 )


__str__(self )


113


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




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

Une architecture pour un système évolutif de contrôle...

Documents

Transcript of Une architecture pour un système évolutif de contrôle...