Interrogation série et entretien SRQ avec le logiciel NI-488.2 et LabVIEW

La communication entre le contrôleur GPIB et les instruments pourrait être comparée à celle entre un instructeur et les étudiants dans une classe. Dans la classe, un moniteur est responsable de la classe et contrôle l’activité. Le GPIB fonctionne de manière similaire, où le contrôleur détermine quand les tâches sont effectuées. Dans la classe, un étudiant doit avoir l’autorisation de parler à haute voix, et sur le GPIB, aucun appareil ne peut communiquer s’il n’est pas adressé pour parler dans le bus. Mais, comment un périphérique peut-il indiquer au contrôleur qu'il a quelque chose à communiquer s'il ne peut pas commencer à parler au contrôleur sans que celui-ci lui dise de le faire ?

La question peut être interprétée dans l’analogie de la classe comme suit : comment un étudiant peut-il faire savoir à l’instructeur qu’il a quelque chose à dire, considérant que l’étudiant ne peut pas parler à l’instructeur à moins que celui-ci ne le dise ? Une bonne méthode consiste à lever la main. De même, l’instrument peut activer une ligne matérielle appelée SRQ. Ceci est une ligne complètement distincte dans le bus GPIB dédiée à indiquer au contrôleur qu'un périphérique a besoin d'attention.

Pourquoi un appareil devrait-il demander un service ? Dans certains cas, un contrôleur peut demander des données à un périphérique (en écrivant sur le périphérique) et les lire dès que l'opération d'écriture est terminée. Mais ce n'est pas possible dans tous les cas. Parfois, un contrôleur peut essayer de lire les données d'un instrument avant qu'elles ne soient disponibles (un instrument peut mettre beaucoup de temps à générer les données) et obtenir une erreur de timeout. Cette situation est semblable à celle d’un professeur qui demande à l’étudiant la réponse à un problème avant que l’étudiant ne soit capable de terminer le problème. Dans ce cas, le professeur préférera attendre que l'étudiant lève la main lorsqu'il aura terminé le problème. Une fois que l'étudiant lève la main, le professeur lui demande la réponse. Cependant, dans le cas GPIB, comme tous les périphériques partagent la ligne SRQ, le contrôleur ne sait pas quel périphérique a demandé le service. Une interrogation série est nécessaire pour que le contrôleur puisse déterminer quel périphérique a demandé de l'attention.

L'interrogation série est une méthode permettant d'obtenir des informations spécifiques des périphériques GPIB lorsqu'ils demandent un service. Lorsque vous effectuez une interrogation série, le contrôleur interroge chaque périphérique et recherche celui qui a activé la ligne SRQ. Chaque périphérique répond à l'interrogation en renvoyant la valeur de l'octet d'état contenu dans son registre d'octets d'état (voir Figure 1). Des conditions dépendantes du périphérique, comme la présence de données disponibles ou une condition d'erreur, déterminent cette valeur. La norme ANSI/IEEE 488.1-1987 spécifie qu'un bit de l'octet d'état, le bit RQS (bit 6), est VRAI si le périphérique a demandé un service. Les autres bits de l'octet d'état sont laissés au fabricant de l'instrument pour les définir. Les instruments compatibles IEEE 488.1 peuvent avoir des bits qui déterminent si une erreur d'instrument a eu lieu ou si le périphérique effectue un auto-test. Comme ces définitions de bits ne sont pas cohérentes entre les fournisseurs d'instruments, la méthode pour déterminer la cause d'une demande de service varie selon chaque périphérique.


La norme ANSI/IEEE 488.2-1987 résout ce problème en définissant certaines conditions de demande de service de sorte qu'un modèle décrit l'octet d'état pour tous les périphériques conformes à la norme 488.2. La norme IEEE 488.2 s’appuie sur l’octet d’état IEEE 488.1 examiné dans la dernière section (voir Figure 2). L'IEEE 488.2 définit le bit RQS comme la norme IEEE 488.1. IEEE 488.2 ajoute le bit Message Available (MAV) et le bit Event Status (ESB). Le bit MAV est défini si le périphérique a déjà été interrogé pour des données et a un message de données en attente à envoyer. Le bit ESB indique qu'un des événements standard définis dans le registre d'état d'événement standard a eu lieu. En définissant les bits correspondants dans le registre Standard Event Status Enable, vous définissez quels événements standard définiront l'ESB. Ces événements incluent Mise sous tension, Requête utilisateur, Erreur de commande, Erreur d'exécution, Erreur dépendante du périphérique, Erreur de requête, Contrôle de requête et Opération terminée. En définissant les bits correspondants dans le registre Service Request Enable, vous pouvez configurer un instrument pour qu'il active la ligne SRQ lorsque ESB ou MAV sont définis, ou lorsqu'une condition définie par le fabricant se produit.

Les fonctions suivantes sont incluses dans la sous-palette LabVIEW GPIB 488. Elles sont essentielles pour effectuer des interrogations série dans LabVIEW :

GPIB Serial Poll ( ibrsp dans NI-488) effectue une interrogation série et renvoie la valeur de Status Byte à partir d'un seul périphérique. Le programme doit vérifier manuellement le bit RQS dans la valeur d'octet d'état pour déterminer si ce périphérique a demandé un service.

GPIB Wait ( ibwait dans NI-488) attend l'état indiqué par un masque Status Word spécifié dans un bus GPIB particulier. Le mot d'état est une variable globale (16 bits) qui contient, entre autres informations GPIB, l'état de la ligne SRQ (bit 12, SRQI) et si un périphérique a demandé un service (bit 11, RQS). Si le vecteur passé en entrée est égal à 0, il n'attend aucune condition spécifiée et mettra à jour ibsta ou le mot d'état. Cependant, si le masque est configuré pour rechercher le bit 12 (SRQI), la fonction attendra que cette ligne particulière soit activée pour une carte GPIB particulière, dont l'adresse est spécifiée dans GPIB Wait.

Wait for GPIB RQS (ibwait dans NI-488, avec masque pour le bit 11) est similaire à l'utilisation de la fonction GPIB Wait avec un masque pour le bit 11, mais en utilisant l'adresse GPIB de l'adresse du périphérique particulier au lieu de l'adresse de la carte GPIB (lorsque vous attendez le bit 12). Cette fonction attend qu'un périphérique particulier demande un service et non qu'une carte (à laquelle plusieurs périphériques pourraient être connectés) reçoive une demande de service. Cette fonction attendra que le bit RQS soit activé ou que le timeout soit dépassé.

Les exemples suivants montrent comment entretenir les SRQ et interroger en série les périphériques en utilisant les fonctions LabVIEW GPIB.

Dans l'exemple LabVIEW 1 (figure 3), une commande est écrite dans un simulateur d'instruments NI. La commande inclut des instructions permettant à l'instrument de générer une requête de service (SRQ) si un événement Opération terminée est enregistré dans le registre d'état des événements (ESR). Les deux premières commandes écrivent ces instructions dans le registre d'activation de demande de service et dans le registre d'activation d'état d'événement (spécification IEEE-488.2). La troisième commande demande au simulateur d'instrument de générer un signal sinusoïdal ; la dernière commande génère un événement Opération terminée. La section suivante du code attend que la SRQ soit générée en vérifiant le bit 12 du mot d'état. Une fois qu'il a été généré, une interrogation série est effectuée sur le simulateur de périphérique pour lire l'octet d'état et connaître la raison pour laquelle il a généré une SRQ. Si le bit 5 est défini (du registre d'état d'événement avec le bit Operation Complete défini) et que le bit 6 est défini (RQS, le périphérique a demandé le service), le contrôleur continue et lit les données du simulateur de périphérique. Notez que le registre ESR doit être effacé. Cela empêche l'instrument de générer des requêtes de service indésirables.


L'exemple LabVIEW 2 (figure 4) montre une autre façon d'attendre que le périphérique demande un service. Cependant, dans ce dernier exemple, le processeur s'arrête et attend sans effectuer d'autres opérations. Dans le premier exemple, d'autres opérations auraient pu être exécutées en parallèle en attendant que le périphérique demande un service.

Les fonctions GPIB 488.2 ajoutent de nouvelles fonctionnalités pour les interrogations série afin que vous puissiez interroger plusieurs périphériques avec une commande GPIB. LabVIEW a inclus ces fonctions dans la sous-palette des fonctions GPIB 488.2, AllSpoll et FindRQS.

AllSpoll peut interroger en série plusieurs périphériques avec un seul appel de routine. AllSpoll place l'octet d'état de chaque instrument interrogé dans un tableau prédéfini. Vous devez vérifier manuellement le bit RQS dans l'octet d'état de chaque périphérique pour déterminer si ce périphérique a demandé un service.

FindRQS peut interroger en série plusieurs périphériques. Si l'un des périphériques demande le service en activant SRQ, le sous-programme renvoie l'indice et la valeur d'octet d'état du premier périphérique qui demande le service.

Si vous savez qu'un seul instrument a activé la SRQ et que vous voulez savoir lequel, et son octet de réponse d'interrogation série, utilisez la fonction FindRQS. Si vous soupçonnez que plusieurs instruments ont activé le SRQ, utilisez AllSpoll pour recevoir les octets de réponse d'interrogation série de tous les périphériques. Si le bit 6 de l'octet d'état est défini, cela signifie que le périphérique a demandé un service. Autrement dit, la valeur de l'octet d'état est au moins hexadécimale 40 lorsqu'un périphérique demande un service.

L'exemple LabVIEW 3 (figure 5) illustre comment effectuer des interrogations en série en utilisant les fonctions LabVIEW NI-488.2. Notez que cet exemple GPIB 488.2 est très semblable aux exemples GPIB précédemment montrés. La plupart des fonctions LabVIEW GPIB ont été remplacées par leurs fonctions équivalentes LabVIEW GPIB 488.2, comme « Send » et « Receive » au lieu de « GPIB Write » et « GPIB Read », « ReadStatus » au lieu de « GPIB Serial Poll » et « Test SRQ » au lieu d’utiliser « GPIB Wait » et de définir le masque à 0. De plus, cet exemple montre une meilleure façon de contrôler les erreurs possibles dans le programme en utilisant un registre à décalage pour transmettre le cluster d'erreur entre les cycles de la boucle While.

Cette note d'application décrit comment le contrôleur GPIB utilise le logiciel NI-488 pour détecter et répondre aux demandes de service des périphériques IEEE 488 sur le bus. Il inclut également des exemples de code LabVIEW qui montrent comment vous pouvez utiliser les fonctions LabVIEW GPIB pour interroger en série des périphériques.