6.2 l’interface standard IEEE 488 pour Java
Le bus IEEE488 pouvant ˆetre consid´er´e comme un port de communication `a part enti`ere, nous avons rapproch´e tant que possible notre mod`ele de description et d’utilisation du bus en Java de celui propos´e dans l’extension standard relative au ports d’entr´ee/sorties.
Cette extension, connue sous le nom de Java Communication API (JavaComm) offre ac-tuellement la possibilit´e de traiter avec les ports s´eries et parall`eles de n’ importe quel syst`eme. l’approche retenue par Sun consiste `a
1. ´enum´erer tous les ports pr´esents au moyen d’une classe d’´enum´eration gardant trace de tous les ports trouv´es
2. les initialiser
3. permettre d’instancier une classe par port repris dans l’´enum´eration du premier point et d’ainsi prendre le contrˆole d’un instrument pr´esent sur le bus
4. mettre `a disposition des m´ethodes dans la classe du port relatives `a l’exploitation de ses capacit´es (envoi, ´ecoute, cr´eation d’unstream pour y injecter des donn´ees, etc. ) Nous avons adopt´e exactement la mˆeme approche afin de nous conformer au standard de la JavaComm et de proposer ce gestionnaire de p´eriph´erique comme compl´ement `a l’ex-tension existante. Notre implantation comporte 5 classes qui sont d´ecrites ci-dessous ainsi que sur la figure 6.1.
GPIBDeviceIdentifier.java Cette classe est la premi`ere `a devoir ˆetre instanci´ee.
Elle se charge de prendre le contrˆole du bus GPIB et de le r´einitialiser. Dans un second temps, elle d´etecte et ´enum`ere tous les p´eriph´eriques pr´esents et, pour chaque appareil, garde trace de toutes les informations connues (identification, position sur le bus,etc.) . Il s’agit ici d’une r´epr´esentation passive de l’instrument vu que celui-ci ne peut ˆetre encore contrˆol´e `a ce point. On peut obtenir un instance de la classe GPIBDevice, repr´esentant un p´eriph´erique GPIB, par l’appel `a la m´ethode open().
GPIBDevice.java Chaque instance de cette classe repr´esente un p´eriph´erique pr´esent sur le bus IEEE488. Via les m´ethodes de cette classe, nous sommes `a mˆeme d’envoyer des messages `a l’appareil ou d’obtenir des mesures.
GPIBDriver.java La r´ealisation de certaines m´ethodes requiert l’utilisation de code natif comme nous l’avons vu. Cette classe abstraite d´ecrit les fonctionnalit´es que tout gestionnaire natif du bus doit impl´ementer. Un fichier de configuration plac´e dans un lieu standard permet de sp´ecifier le nom d’une classe `a charger, celle-ci impl´ementera le gestionnaire natif du bus sur le syst`eme local.
WindowsGPIBDriver.java Sous-classe de GPIBDriver, cette classe impl´emente les m´ethodes natives permettant l’initialisation et l’envoi de messages sur le bus. C’ est la seule qui comporte du code natif.
La figure 6.2 pr´esente le mod`ele suivant lequel l’utilisateur a acc`es `a un appareil sp´ecifique. La prise en charge du bus GPIB par le code Java, au travers de la carte
contrˆoleur pr´esente sur le PC, est initi´ee d`es l’instantiation de la classe GPIBDeviceIden-tifier. Le constructeur de cette classe d´ebute le dialogue avec le bus par la cr´eation d’une instance d’une classe implantant l’interfaceGPIBDriver. Cette classe, e.g. WindowsGPIB-Driver, comporte tout le code natif n´ecessaire afin d’interagir avec le bus. C’ est vers cette classe que seront concentr´es les appels de bas niveaux aux instruments du bus. Une classe d’´enum´eration, associ´ee `a la classe d’identification, permet de passer en revue l’ensemble des p´eriph´eriques qui auront ´et´e d´etect´es lors de l’initialisation du bus IEEE 488 par le GPIBDriver. Le p´eriph´erique est pr´esent´e au travers de la classe GPIBDeviceIdentifier, ce qui permet d’obtenir des renseignements sans devoir r´eellement prendre le contrˆole du p´eriph´erique. Enfin, la prise en charge proprement dite du dit p´eriph´erique se fera par l’ins-tanciation d’une classe GPIBDevice. Cr´eer une instance de cette classe initialise et prend le contrˆole de l’appareil correspondant, mais prend ´egalement en charge tous les appels n´ecessaires `a la gestion des ´etats d’erreur ´eventuel de l’appareil (e.g. erreurs de timeout).
La classe GPIBDevice offre des m´ethodes permettant de communiquer efficacement avec l’instrument qu’ elle repr´esente. A cet effet, plusieurs types de messages sont disponibles :
– demande de fermeture du port de communication – r´einitialisation de l’instrument
– envoi d’un chaˆıne de caract`eres et acquisition du message de r´eponse
Cette interface r´eduite d´ecoule des principes mˆemes de l’utilisation du bus GPIB : seuls des messages et des textes sont transf´er´es sur les fils. Les changements d’´etat du bus sont trait´es de mani`ere totalement transparente pour l’utilisateur : des exceptions sont lev´ees lors de la communication afin d’effectuer une correspondance coh´erente entre le changement d’´etat d’un fil d’erreur et le mod`ele ´ev´enementiel de Java. La figure 6.3 pr´esente un diagramme de s´equence montrant une utilisation de cette interface afin de recueillir la tension aux bornes d’un voltm`etre num´erique. Il est ici important de noter que
”demander la tension” n’ a aucun sens dans le mod`ele GPIB. Il faut donc, pour tout mod`ele d’appareil, mettre en correspondance les m´ethodes que conceptuellement tout voltm`etre pourrait pr´esenter avec le code de la chaˆıne de caract`ere `a envoyer sur le bus de mani`ere `a r´ealiser la demande proprement dite. Ainsi, ”demander la tension” se dira ”VOLT :10 :100”
dans le langage de l’appareil repris sur la figure.
6.2. L’INTERFACE STANDARD IEEE 488 POUR JAVA
Fig.6.1 – Classes utilis´ees pour la mise en oeuvre d’une interface de communication relative58
Fig. 6.2 – Mod`ele d’initialisation du bus GPIB en Java
6.2. L’INTERFACE STANDARD IEEE 488 POUR JAVA
Fig.6.3 – Envoi de commandes `a destination de l’instrument au moyen de la classe GPIB-Device
Utilisation de JINI dans le cadre de l’instrumentation virtuelle
Sommaire
7.1 Introduction . . . 61 7.2 Interfa¸cage des instruments de mesure . . . 62 7.2.1 Interfaces standardis´ees . . . 62 7.2.2 Introspection dynamique des capacit´es des instruments . . . 65 7.3 Exploitation du r´eseau . . . 67 7.3.1 Les domaines . . . 67 7.3.2 Instrumentation distante . . . 67 7.4 Les apports propres `a Jini . . . 68 7.4.1 Robustesse . . . 68 7.4.2 Interfaces graphiques . . . 69
7.1 Introduction
Afin de montrer ´egalement que notre approche peut parfaitement s’int´egrer dans un environnement de prise de mesure actuel, tel que LabVIEW, nous avons r´ealis´e une appli-cation offrant les mˆemes possibilit´es de programmation visuelle, d’interfa¸cage utilisateur, etc. que pr´esentent les logiciels disponibles sur le march´e. Cette application pr´esente un module de gestion prenant enti`erement en charge le bus Jini et interagissant avec celui-ci au moyen d’un nombre extrˆemement restreint de m´ethodes. Ainsi, nous montrerons que l’int´egration de Jini dans les solutions existantes ne requiert pas la reconversion compl`ete ou partielle de l’application et qu’il est r´eellement envisageable de d´evelopper une sorte