Institut National des Sciences Appliques de Toulouse

Dpartement de Physique 4me anne

Communication avec des instruments de mesure

Anne 2008-2009

Communication avec des instruments l'aide des bus GPIB et RS-232

Objectifs du cours:
Comprendre le fonctionnement dtaill de ces deux bus et tre capable de mettre en uvre ses connaissances pour piloter un appareil

"PC Interfacing and Data Acquisition", par Kevin James "Practical Data Acquisition for Instrumentation and Control Systems" par John Park et Steve Mac Kay Le site de National Instrument France

Bibliographie :

I. Contexte
(voir le schma correspondant) Les bus GPIB et RS-232 sont deux bus trs frquemment utiliss pour communiquer avec des instruments. Pour communiquer avec un instrument en utilisant ces bus, il faut bien entendu que l'instrument lui-mme soit dot d'un port RS-232 ou GPIB. Sur certains instruments, ces ports sont prsents par dfaut. Parfois, ils font partie des options l'achat d'un instrument. D'autre part, il faut aussi que l'ordinateur soit muni du port correspondant. Jusqu' encore trs rcemment, le port RS-232 tait toujours prsent sur les ordinateurs de bureau; il s'agissait du port COM1 ou COM2 de l'ordinateur. Sa prsence sur tous les ordinateurs s'expliquait par le fait que ce port tait utilis pour la connexion du modem ou de la souris. Il semblerait que les ordinateurs les plus rcents n'en soient plus forcment pourvus. Le port GPIB n'est pas prsent sur un ordinateur standard, car il s'agit d'un bus qui a t dvelopp exclusivement pour la communication avec des instruments de mesure. Sa prsence sur un ordinateur n'est donc que moyennement utile au grand public, mais quasi-indispensable tout physicien/ingnieur/chercheur cherchant automatiser des mesures, et donc communiquer avec des instruments.

En dehors de ces deux bus, d'autres bus permettent de communiquer avec des instruments, notamment le bus Ethernet, et le bus USB. Ils ne seront pas abords dans ce cours.

II. Le bus GPIB

1. Historique
Dvelopp l'origine par HP en 1965 pour communiquer avec ses instruments (sous le nom HPIB), ce bus fut par la suite adopt par plusieurs fabricants. Plusieurs normes se sont succdes: IEEE-488.1 : Datant de 1978, cette premire norme fixe uniquement les contraintes mcaniques et lectriques du bus. Le protocole de communication reste non-dfini. IEEE-488.2 : Datant de 1987, cette norme prcise certaines rgles du protocole de communication, le format des donnes changes avec les instruments, la gestion des erreurs, et un petit nombre de messages qui doivent tre compris par tous les instruments (ceux commenant par le caractre *).

On utilise souvent le mot GPIB pour tout dsigner : bus GPIB, cble GPIB, port GPIB, communication GPIB, instrument GPIB. Pour la communication, il faut par contre vrifier quelle est la norme et le protocole exact que vrifie l'instrument (IEEE-488.1, IEEE-4882), car cela influence fortement la manire de la programmer et les fonctions utiliser.

2. Connexions
(voir le schma correspondant) Le bus GPIB comprend 24 lignes, dont 8 masses ou tresse de blindage --> 16 lignes "utiles". On peut connecter jusqu' 15 instruments, l'ordinateur (ou contrleur) comptant pour un. Il faut respecter certaines rgles sur la longueur des cbles pour connecter les diffrents instruments (voir le schma).

3. Description du bus et du protocole de communication

(voir le schma correspondant) a. Prsentation gnrale Le bus GPIB permet:

- un contrleur de grer les changes de donnes avec diffrents instruments qui lui sont connects, alors que le temps de lecture de donnes sur le bus par les diffrents instruments n'est pas normalis. - un instrument de signaler une demande de service au contrleur n'importe quel moment Le dbit de donnes sur ce bus peut atteindre 1 MO/s. Trs grossirement, le principe de la communication est le suivant: - le contrleur dfinit quel est l'instrument qui parle sur le bus (le parleur), et quels sont ceux qui doivent couter (les couteurs). Dans 99 % des cas, le contrleur lui-mme est soit parleur, soit couteur dans un change donn, mais ce n'est pas une obligation (le contrleur peut aussi demander deux instruments de communiquer entre eux, si cela est utile). Ensuite, - le parleur parle aux couteurs, qui coutent! - lorsque le parleur a fini de parler, le contrleur redfinit les rles - le nouveau parleur parle aux nouveaux couteurs, etc... Afin de pouvoir adresser individuellement chaque instrument sur le bus, chaque instrument possde une adresse primaire, comprise entre 0 et 30. L'adresse d'un instrument sur le bus est choisie par l'instrument lui-mme. Pour viter le partage de la mme adresse par deux instruments, on peut changer l'adresse par dfaut d'un instrument, soit l'aide de switchs, soit dans les menus de configuration de l'instrument en face-avant. Le contrleur luimme possde une adresse sur le bus GPIB (c'est gnralement l'adresse 0). Pour des instruments complexes, possdant par exemple plusieurs modules ou fonctionnalits dans un mme instrument, on peut aussi dfinir une adresse secondaire, qui permet d'accder chaque module. Pour les instruments simples, l'adresse secondaire est donc nulle. b. Description des lignes du bus Le bus GPIB est constitu de : 8 lignes de donnes Sur ce bus vont circuler 2 types d'information: les caractres changs entre le contrleur et un instrument sont gnralement sous format ASCII (mais du binaire peut tre employ). On les appelle "messages". A part quelques messages dfinis par la norme IEEE 488-2, la syntaxe de ces messages dpend de l'instrument (voir nanmoins la partie "SCPI" plus loin). Un utilisateur de GPIB doit comprendre ces messages, car il en est l'origine (pour les messages envoys) ou doit les interprter (pour les messages reus). exemple : "qui es-tu ?") le contrleur envoie la suite de caractres : *, I, D, N, ? (traduction

l'instrument rpond K, E, I, T, H, L, E, Y, ,2, 4, 0, 0 N.B. : Chaque caractre est un octet; ils sont donc envoys un par un sur le bus. des instructions spciales, changes entre le contrleur et les instruments, destines grer le bus. On les appelle "commandes". La syntaxe de ces messages est

compltement normalis par la norme IEEE-488-2, et est donc comprise par tous les instruments GPIB. Cependant un utilisateur GPIB ne connat pas la syntaxe de ces commandes, car il ne les crit pas directement. Il utilise des fonctions "haut-niveau" de gestion du bus GPIB qui se chargent de ces tches. exemple : Le contrleur envoie l'octet 01100110 sur le bus de donne, ce qui peut vouloir dire: "instrument 10 parleur", ou "instrument 8 couteur", ou "instrument 4 tu es maintenant le nouveau contrleur du bus", ou "instrument 5 tais-toi" ou " prparez-vous tous une scrutation srie".... ---> Le bus GPIB est donc un bus dit "parallle", car plusieurs bits (ici 8) sont envoys la fois sur le bus. Ceci s'oppose aux bus dit "srie", pour lesquels un seul bit est envoy la fois. 3 lignes de handshake Comme le temps de lecture des donnes sur le bus par les instruments n'est pas dfini, l'change de donnes entre parleur et couteur doit suivre un protocole assez complexe, impliquant l'utilisation de ces 3 lignes. (voir le schma correspondant) (0) : La ligne DAV est relche par le parleur, et la ligne NDAC (Not Data Accepted) active par tous les instruments couteurs. Les instruments sont occups autre chose et maintiennent la ligne NRFD (Not Ready For Data) active. (1) : les instruments relchent la ligne NRFD (Not Ready For Data) lorsqu'ils sont disponibles. La ligne ne passe 0 que lorsque tous les instruments ont relch la ligne. (2) : Le parleur place alors un octet sur le bus de donne (3) : Il le signale aux couteurs en activant la ligne DAV (Data AVailable) (4) : Lorsque les couteurs reprent que la ligne DAV est active, ils activent la ligne NRFD, car ils sont occups lire la donne. (5) : Lorsqu'un instrument a lu la donne, il relche la ligne NDAC. La ligne NDAC ne repasse donc 0 que lorsque tous les couteurs ont lu la donne. (6) : Le parleur relche la ligne DAV quand tous les instruments ont lu la donne (7) : Tous les instruments re-activent la ligne NDAC. (8) : Lorsque les instruments sont nouveau prts pour la communication, ils relchent la ligne NRFD Les 3 lignes sont alors revenues leur tat initial, et un nouveau cycle peut commencer. ---> La communication est dite "asynchrone", car les donnes ne sont pas envoyes intervalle de temps constant sur le bus, mais s'adaptent aux appareils. Lors de l'envoi de commandes sur le bus (lorsque tous les instruments coutent), le dbit de donnes est donc limit par l'appareil le plus lent. Ceci s'oppose la communication "synchrone", pour laquelle le dbit de donnes est constant dans le temps.

 5 lignes de gestion du bus - ATN (ATtentioN): Lorsque le contrleur active cette ligne, tous les instruments l'coutent. Il active cette ligne pour envoyer des commandes sur le bus de donnes (dfinir parleur et couteur, etc...). Lorsqu'elle est dsactive, seuls les couteurs coutent le bus. Ce sont alors des messages qui circulent sur le bus de donnes. - IFC (InterFace Clear) : Lorsque le contrleur active cette ligne, il demande aux instruments de rinitialiser leur interface GPIB. En pratique, ce que fait rellement un instrument la suite de cet vnement dpend des instruments. A faire par scurit au dbut de chaque programme GPIB. - REN (Remote ENable) : Lorsque cette ligne est active, les instruments se placent dans l'tat "remote", l'coute du bus. Si cette ligne n'est pas active, l'instrument ne rpond qu'aux boutons de sa face-avant : il est dans l'tat "local". - EOI (End Or Identification): cette ligne peut tre utilise par le parleur pour signaler la fin d'un message de plusieurs caractres. Dans ce cas, le parleur active cette ligne la fin du message pour signaler aux couteurs qu'il a fini de parler (voir aussi plus loin). - SRQ (Service ReQuest) : ligne trs importante. Cette ligne peut tre active n'importe quel moment par un instrument sur le bus pour demander l'attention du contrleur. On appelle ce phnomne "demande de service". Bien entendu, le contrleur ne sait pas quel instrument a activ la ligne! Il doit donc oprer une scrutation (Poll en anglais) pour savoir lequel des instruments a fait la demande de service (voir plus loin). La demande de service sur le bus GPIB est un concept proche de celui des interruptions dvelopp dans le cours de T.D.O. La mise 1 de la ligne SRQ est la seule initiative possible pour un appareil sur le bus.

---> La structure du bus GPIB nous montre qu'il suffit de 13 lignes de bus pour rsoudre le problme pos pendant le cours de T.D.O.!

c. Dtection de la fin des messages. Dans le protocole de communication entre un parleur et un couteur, il est important que l'couteur sache que le parleur a fini son message. Deux mthodes sont possibles, et peuvent tre utilises par diffrents instruments. La mthode dite "EOI" Comme nous l'avons vu prcdemment, une ligne spciale du bus, la ligne EOI, est ddie cette tche. Il faut que le parleur active cette ligne aprs l'envoi de son dernier caractre; l'couteur sait alors que le message est fini. Il peut alors l'excuter. La mthode dite "EOS" (End Of String) Certains instruments demandent ce qu'un caractre spcial, soit rajout la fin de tout message qui leur est envoy, et font de mme lorsqu'ils parlent. Ce caractre spcial est spcifi dans la documentation de l'appareil. Dans les vieux appareils, c'est surtout la mthode EOS qui tait utilise, avec un caractre non normalis. Il faut donc bien tudier la documentation de l'appareil dans ces casl. La norme IEEE 488-2 spcifie qu'un instrument moderne doit comprendre les deux

mthodes, qui peuvent tre utilises indpendamment ou conjointement par le contrleur. Le caractre spcial de la norme est le "new-line ou line-feed"="\n"="code ASCII 10". Lorsqu'un instrument moderne parle, il utilise conjointement les deux mthodes: il rajoute le "\n" la fin de son message et active la ligne EOI. Voir aussi plus loin pour la norme SCPI de fin de message.

III. Le bus RS-232

1. Historique et nomenclature
(voir le schma correspondant)

Il a t dvelopp dans les annes 60 pour communiquer avec des modems. Il est normalement compos de 25 pins, mais seulement 9 sont gnralement utilises. Deux types de broches, 9 pins, et 25 pins, et leurs adaptateurs existent. Les ordinateurs prsentent toujours un port 9 pins. Son dveloppement pour le besoin des modem a donn lieu une nomenclature... qu'il faut intgrer, malgr son peu de rapport avec les besoins pour l'instrumentation. Dans la nomenclature RS-232, l'ordinateur ou un instrument fournissant des donnes sont appels DTE (Data Terminal Equipment). Le modem est appel DCE (Data Communication Equipment).

2. Description du bus
Le nom des 9 lignes du bus fait rfrence leur usage par le DTE. lignes de donnes : TxD (Transmit Data) et RxD (Receive Data) et Terre-Signal. La ligne TxD est utilis par le DTE uniquement pour transmettre les donnes, et la ligne RxD pour en recevoir. Bien entendu, pour le DCE (modem), la ligne TxD est utilis pour recevoir, et la ligne RxD pour transmettre. lignes de handshake: sonnerie : indique que le modem est connect un autre modem distant. DSR (Data Set Ready) est active lorsque le modem est prt fonctionner (sous tension). DTR (Data Terminal Ready) est active lorsque le DTE est prt fonctionner (sous tension). DCD (Data Carrier Ready): Indique que le modem est connect un modem distant CTS (Clear to Send) : Active par le modem lorsqu'il est prt recevoir des donnes. RTS (Request to Send) : Active par le DTE lorsqu'il dsire mettre des donnes.

Protocole de communication trs simplifi entre le DTE et le DCE : - Avant de pouvoir changer des donnes avec le modem, le DCE s'assure que le modem est sous tension (DTR active). Il active RTS pour demander l'change de donnes. Le modem rpond en activant CTS. - Ensuite, l'change de donnes a lieu (voir plus loin).

3. La communication entre 2 DTE

Le RS-232 a ensuite t utilis pour la communication entre un ordinateur et un instrument, qui sont 2 DTE. 1er problme : Le cblage prsent prcdemment ne peut pas fonctionner. Sinon, la ligne TxD de l'instrument et celle de l'ordinateur sont connectes ensemble... idem pour la ligne RxD... la communication va tre difficile. 2me problme : Certains instruments ne grent pas du tout le handshake; certains le grent de manire partielle. Dans ces cas, les lignes DSR, DCD, CTS ne sont jamais actives, ou sont partiellement actives par l'instrument. L'ordinateur peut donc penser que l'instrument n'est pas prt communiquer... 3me problme : Certains constructeurs ont cbl de manire fantaisiste certaines broches. ---> 95 % des problmes de communications en utilisant le bus RS-232 proviennent des problmes ci-dessus. Il faut donc absolument vrifier dans la documentation d'un instrument qu'on veut connecter via le bus RS-232 ce qu'il en est.

Rsolution des problmes : Pour rsoudre ces diffrents problmes il faut absolument utiliser un cble qui convient ET configurer convenablement le handshake de l'ordinateur. En faisant quelques courts-circuits astucieusement penss sur le cble, on peut aussi simuler un handshake. Il est aussi possible de demander l'ordinateur de ne pas tenir compte des lignes de handshake (c'est--dire dsactiver le handshake matriel, voir plus loin). (voir les schmas correspondants) Exemple : on croise les lignes TxD et RxD, et on court-circuite certaines broches pour faire croire l'ordinateur que l'instrument rpond ou inversement! On peut faire soit mme son cble, ou utiliser un cble crois "null-modem". Dans tous les cas, il faut rflchir pour tre sur que la cble fabriqu ou achet va rsoudre le problme de communication avec l'instrument, tester le cble et diffrentes configurations.

3. Format et vitesse des donnes changes

(voir le schma correspondant)

La structure du bus montre bien qu'un seul bit peut tre envoy la fois entre l'ordinateur et l'instrument. Le bus RS-232 est donc un bus srie. Les donnes changes sur le bus sont des paquets de bits, dont chacun reprsente gnralement un caractre ASCII (mais pas toujours). Le temps coul entre la transmission de chaque caractre tant nondfini, la communication entre l'ordinateur et l'instrument est donc de type asynchrone. Cependant, les bits l'intrieur d'un paquet sont envoys de manire synchrone. Chaque paquet de bits comporte des bits supplmentaires, en plus du caractre proprement dit: - le start bit : un seul bit 0 en dbut de srie, qui permet au rcepteur de se synchroniser et d'tre prt recevoir les autres bits. - les bits de donnes (5, 6, 7 ou 8 bits). Il faut 7 bits pour coder un caractre avec le format ASCII. - bit de parit (parity bit): permet une dtection d'erreur simple. On le configure soit pair (even en anglais) soit impair (odd en anglais). S'il est configur pair, cela signifie que le nombre total de bits 1 dans la donne, y compris le bit de parit, doit tre pair. On peut aussi supprimer ce bit (none), ou bien le mettre toujours 1, ou toujours 0. - bit de fins (stop bits) : 1, 11/2 ou 2 bits 1 en fin de paquet. 11/2 bit signifie que la ligne est maintenu dans son tat 50% de temps de plus que le temps d'un bit normal. Le temps de dure d'un bit est fix par l'utilisateur. On doit distinguer 2 grandeurs diffrentes: - le bit rate (en bps) : caractrise combien de bits utiles sont transfres par seconde. - le baud rate (en baud) : caractrise combien de bits sont transfres par seconde. Dans le schma donn en exemple, si on suppose que la dure d'un bit est de 1 ms, Le baud rate = 1000 baud Le bit rate : Il faut 11 ms pour transfrer 7 bits utiles ---> bit rate = 636 bps Le baud rate est fix par l'utilisateur et suit des valeurs normalises: 50, 110, 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200 baud. Une valeur couramment utilise par les instruments est 9600 bauds. L'ensemble de ces paramtres doit tre commun l'ordinateur et l'instrument... sinon la communication ne fonctionne pas.

4. Le handshake logiciel
Nous avons vu prcdemment que dans la communication RS-232 "normale", le handshake est assur par des lignes physiques du bus, qui passent 0 ou 1 quand les metteurs/rcepteurs sont prts recevoir des donnes. On parle alors de handshake matriel. Nous avons aussi vu qu'on pouvait dsactiver le handshake matriel, c'est--dire demander l'ordinateur de ne pas tenir compte de l'tat des lignes de handshake lors de la communication. Dans ce cas, il faut quand mme trouver un moyen pour vrifier que le rcepteur reoit bien les donnes. On tablit alors un handshake logiciel.

(voir la table des codes ASCII) Voici deux exemples de protocoles possibles pour du handshake logiciel: ACK/ETX : L'metteur envoie des blocs de caractres de longueur fixe, et envoie la fin de chaque bloc un caractre spcial (le caractre ASCII ETX). Le rcepteur rpond en renvoyant le caractre ACK si il a bien reu l'ensemble des donnes, et le caractre NAK sinon. XON/XOFF : Le rcepteur remplit une mmoire tampon (buffer en anglais) avec les donnes envoyes par l'metteur. Lorsque son buffer est plein 80 %, il envoie le caractre ASCII DC1 (XOFF) l'metteur qui suspend alors l'mission. Lorsque le buffer du rcepteur s'est vid jusqu' 50%, il envoie le caractre ASCII DC3 (XON) l'metteur qui reprend l'mission.

IV. Communication avec un instrument

1. Structure de l'instrument, lecture, criture et mmoire-tampon
(voir le schma correspondant) Un instrument capable de communiquer via un bus donn possde toujours une interface avec ce bus: un microprocesseur connect au bus et qui respecte le protocole de communication du bus. Lorsqu'on envoie un message vers un instrument (on dit aussi opration d'criture), il est stock dans le buffer d'entre de l'instrument. L'existence de ce buffer d'entre permet de stocker plusieurs messages pendant l'attente de leur traitement par l'appareil. De mme, l'appareil dispose d'un buffer de sortie, dans lequel il stocke les donnes en attendant que le contrleur vienne les chercher (lorsqu'il le fait, c'est alors une opration de lecture). La partie spcifique l'instrument se charge d'interprter et d'excuter les instructions prsentes dans le buffer d'entre et de placer les donnes dans le buffer de sortie.

2. Langage
Nous venons de voir qu'on peut plus ou moins pniblement arriver changer des messages avec un instrument, par le bus GPIB, par le bus RS-232, ou par d'autres bus que nous n'avons pas tudis. Reste donc dcouvrir la nature des messages changs. Avant 1987, il n'existait aucune normalisation dans la syntaxe des messages changs entre un ordinateur et un instrument. La norme IEEE488-2, en plus de fixer certaines spcifications du bus GPIB, a fix la syntaxe de quelques messages qui doivent tre compris par tous les instruments, quelle que soit la manire dont ces messages arrivent l'instrument (GPIB, RS-232, Ethernet, soucoupe volante, tlpathie,...). Nous verrons plus loin l'utilit de ces messages. Ces messages ("Common commands and queries") ne servent pas demander un instrument de faire des

Quelques branches de l'arbre des messages SCPI d'un multimtre.

mesures, mais surtout se renseigner sur son statut (voir plus loin). Ils commencent tous par le caractre *. La norme SCPI (prononcer skipi), datant de 1990, fixe une syntaxe commune pour tous les messages envoys des instruments, notamment ceux utiliss pour faire des mesures. Le but est de pouvoir changer d'instrument dans une manip ou un banc de test sans avoir recrire les messages envoys aux instruments. Le SCPI conduit une compatibilit horizontale : deux instruments compltement diffrents mais pouvant faire la mme mesure se programment de la mme manire. Exemple : un compteur et un oscilloscope peuvent tout les 2 faire une mesure de largeur d'impulsion. Le mme message sera utilis pour faire cette mesure sur ces deux instruments. Le SCPI conduit aussi une compatibilit verticale : deux appareils de marque diffrentes utiliseront le mme message pour effectuer la mme action. Exemple : le trigger, le rglage de la base de temps et le rglage de la sensibilit se font en envoyant des messages identiques sur tous les oscilloscopes SCPI.

3. Exemples et syntaxe de messages SCPI

Voici quelques exemples de messages SCPI: MEAS? est un message destin un instrument lui demandant de faire une mesure et d'envoyer la valeur mesure. +1.4568895614E-3 peut tre une rponse de l'instrument. CONF:VOLT:DC 10, 0.001 est un message configurant un multimtre pour qu'il se mette en mode de mesure de tension DC, sur le calibre 10 Volts, avec une rsolution de 1 mV (mais il ne fait pas de mesure). Les messages envoys un instrument et suivis d'un point d'interrogation entranent une rponse de l'instrument. Les messages sans point d'interrogation sont des ordres, et n'entranent pas de rponse de l'instrument. Les caractres peuvent tre envoys en minuscule ou majuscule, cela n'a aucune importance. Chaque message SCPI a une version courte et une version longue. La version longue des messages ci-dessus est: MEASURE? CONFIGURE:VOLTAGE:DC 10,0.001 Les messages SCPI sont organiss suivant un arbre hirarchique (voir la figure). Dans les "dictionnaires" SCPI , les {} proposent un choix de paramtres possibles, spars par des |. Les [ ] proposent un choix de paramtres optionnels. Les < > signifient qu'une valeur numrique doit tre entre la place de ce paramtre. Ces diffrents sparateurs ne sont pas envoys avec la commande finale. Les majuscules et minuscules permettent de connatre les versions longues et courtes d'un message. Lorsqu'une suite de paramtres doit tre envoye dans un message, ils sont spars par des virgules . Exemple: On peut trouver dans le manuel d'un multimtre la dfinition d'un message SCPI suivante: CONFigure:VOLTage:DC {<range>|MIN|MAX|DEF, <res>|MIN|MAX|DEF} Ceci signifie que tous les messages suivants sont corrects: CONFIGURE:VOLTAGE:DC MIN, 0.01 conf:volTAge:DC 10, MAX CONF:VOLT:DC MIN, DEF Une srie de message peut-tre envoye un instrument en une seule fois, condition de les sparer par des points-virgules. Exemple: CONF:VOLT:DC MIN, MAX; MEAS? Lorsque des valeurs numriques doivent tre envoyes (exemple <res>), il faut bien entendu vrifier dans la documentation de l'instrument lesquelles sont acceptes ou valables.

4. Norme de fin des messages en SCPI

Elle prcise que tous les messages envoys et envoys par un instrument doivent se terminer par un "\n".

Nous avons vu que, alternativement, dans le cas prcis du bus GPIB, l'activation de la ligne EOI est interprte comme la fin d'un message. On peut donc se passer de l'envoi d'un "\n" la fin de chaque message si on active la ligne EOI la fin du message. Par contre, lors de l'utilisation du bus RS-232, il n'y a pas d'quivalent la ligne EOI; il faut donc un "\n" la fin de tous les messages envoys un instrument.

5. Connatre le statut d'un instrument

Il est parfois intressant pour un programmeur de connatre rapidement le statut d'un instrument, c'est--dire l'tat global dans lequel il se trouve : a-t-il compris les messages qui lui ont t envoys, a-t-il russi faire ce qui lui a t demand, a-t-il fini sa mesure, etc... A cet effet, il existe l'intrieur de chaque instrument des registres. Dans ces registres, gnralement composs d'un seul octet, chaque bit a une signification particulire qui peut intresser le programmeur. Ces registres ont t dfini par la norme 488.2 (Status Report Model) (voir le schma correspondant) Certains registres peuvent aussi tre modifis par le programmeur pour rpondre certains besoins (voir en T.P.). Notamment, c'est en manipulant convenablement ces registres qu'on peut conduire un instrument faire une demande de service sur le bus GPIB. La signification de certains de ces registres et de leurs bits associs a t normalis par la norme IEEE488-2, puis SCPI. Certains bits sont cependant non-dfinis par la norme, et ont une signification qui peut dpendre de l'instrument. Le registre le plus important du multimtre rsume l'tat global de l'instrument; il est appel registre d'tat (status byte register). Le bit n6 du registre d'tat, lorsqu'il passe 1, entrane une demande de service de l'instrument, qui active la ligne SRQ du bus GPIB. Parmi les "Common command and queries" dfinies par la norme IEEE488-2, beaucoup sont destines manipuler ou interroger ces registres.

6. "Common command and queries"

Vous dcouvrirez en T.P. l'ensemble de ces messages et leur utilit. Ces messages sont tous prcd d'une *. Quelques exemples: *IDN? ce message est le seul que vous devez absolument connatre. Il demande un instrument de dcliner son identit. C'est le message-type pour tester la communication avec un instrument. *RST *TST? 0 sinon. demande un instrument de se remettre dans son mode de mesure par dfaut. demande un instrument d'effectuer un self-test. Il renvoie 1 si le test est russi, et

*STB? est un message demandant un instrument de renvoyer la valeur de son registre d'tat. Il rpond par un nombre compris entre 0 et 255 qui permet de connatre l'tat de chaque bit du registre. Exemple : L'instrument rpond 0 : chaque bit du registre est zro L'instrument rpond 255 : chaque bit du registre est 1

L'instrument rpond 4 : le registre est L'instrument rpond 7 : le registre est

00000100 00000111

7. La demande de service (spcifique au bus GPIB).

Nous avons vu prcdemment qu'un instrument connect au bus GPIB peut activer la ligne SRQ pour demander l'attention du contrleur du bus. C'est le programmeur lui-mme qui a configur l'instrument pour qu'il fasse une demande de service lorsqu'un vnement spcial se produit. Lorsque la demande de service arrive, le contrleur du bus ne sait pas quel instrument a fait la demande, et doit procder une scrutation (polling) pour savoir quel instrument en est l'origine. Il existe deux types de scrutation: la scrutation srie (serial poll): en utilisant des commandes du bus GPIB, le contrleur demande successivement chaque instrument prsent sur le bus de dposer la valeur de son registre d'tat sur le bus de donne, et la rcupre. Si le bit n6 du registre d'tat est 1, le contrleur sait que cet instrument avait fait une demande de service. la scrutation parallle (parallel poll) : le contrleur demande chaque instrument de placer la valeur du bit n6 de son registre d'tat sur une ligne du bus de donne. Par exemple, l'instrument n1 le place sur la ligne n1, l'instrument n2 sur la ligne n2, etc... Ceci permet de scruter en une opration 8 instruments, au lieu d'un seul dans le cas de la scrutation srie. Dans tous les cas, un appareil qui avait fait une demande de service et qui est scrut par le contrleur lve sa demande de service et relche la ligne SRQ du bus GPIB.

V. Quelques principes de programmation en instrumentation

1. Diffrencier le bus et l'instrument.
Vous allez communiquer avec des instruments en utilisant un bus. Bien entendu, des erreurs et bugs vont survenir lors de l'excution de vos programmes. Il faut distinguer les erreurs provenant du bus et les erreurs provenant de l'instrument. Exemples : - Vous envoyez un message un instrument l'adresse primaire 24. Vous vous tes tromps, il n'y a pas d'instrument ayant l'adresse primaire 24. ---> erreur du bus - Vous envoyez le message "MEAC?" un instrument au lieu de "MEAS?" ---> pas d'erreur de bus, erreur de l'instrument, qui ne comprend le message. - Vous cherchez faire une opration de lecture sur un instrument qui n'a rien dans son buffer de sortie: ---> erreur du bus Les erreurs de bus sont faciles dtecter dans un programme: il existe des mthodes permettant de tester en permanence au cours du programme l'tat du bus. Les erreurs d'instruments sont par contre plus dlicates dtecter; parfois, un instrument "bippe" lors

d'une erreur, mais pas toujours! De plus une erreur qui est l'origine de type "instrument" peut entraner par cascade une erreur du bus. Exemple : Dans votre programme, - vous faites une opration d'criture "MEAC?" vers un instrument. - vous faites une opration de lecture vers ce mme instrument pour lire la mesure qu'il vient d'effectuer. L'instrument n'ayant pas compris le "MEAC?", il ne fait pas la mesure escompte, et ne place rien dans son buffer de sortie. L'opration de lecture gnre une erreur de bus!

2. L'initialisation
Vous crirez parfois des programmes qui marchent quand tout va bien, et qui ne marchent plus pour une raison qui vous chappe. Si vous teignez/rallumez l'instrument et/ou l'ordinateur, a remarche. Dans 90 % des cas, ce type de comportement provient d'un problme d'initialisation. En effet, il ne faut pas supposer que, lorsque vous lancer votre programme, le bus, les interface du bus, les registres et les buffers de sorties de l'instrument, etc, sont dans un tat idal connu : buffers vides, registres zro, pas, d'erreurs, pas de demande en cours, pas de demande de service d'un instrument non satisfaites, etc... En pratique, des bugs dans un programme ou une interruption brutale d'un programme laissent le bus et les instruments dans un tat indtermin... qui peut gnrer des bugs surprenant dans un programme mal initialis lanc la suite. Vous devez donc commencer un programme par une srie d'instructions visant tout initialiser, et placer correctement vos instruments dans l'tat "remote". Il faut donc initialiser l'interface du bus ct ordinateur, l'interface du bus ct instrument, les registres d'tat des instruments, vider les buffers, annuler les erreurs, activer les bonnes lignes du bus, etc...

3. Progression
Ca va sans dire, mais a va mieux en le disant : il vaut mieux commencer par crire un programme simple qui marche (ex: j'cris "*IDN?" un instrument, et je lis sa rponse), puis le complexifier, que partir de suite dans un programme trs long et complexe...qui ne marchera bien entendu pas du premier coup... et qui sera compliqu dbuguer. De plus, vous avez gnralement sur un ordinateur sur lequel ont t installs des logiciels et du matriel d'instrumentation de petits utilitaires (exemple : "Measurement and Automation Explorer" chez National Instrument), qui vous permettent de dialoguer rapidement et facilement de manire interactive avec des instruments sans crire une seule ligne de code. C'est trs utile pour: - tester rapidement la communication avec un instrument (le cble est-il bon ?, l'instrument rpond-il ?) - tester des messages envoyer et voir si les rponses et ractions d'un instrument correspondent vos attentes.