Serial Polling und SRQ Servicing mit NI-488.2 und LabVIEW

Die Kommunikation zwischen dem GPIB-Controller und den Geräten könnte mit der Kommunikation zwischen einem Kursleiter und den Kursteilnehmern in einem Klassenzimmer verglichen werden. Im Klassenzimmer ist ein Kursleiter für den Unterricht zuständig und steuert die Aktivitäten. Der GPIB arbeitet ähnlich, wobei der Controller bestimmt, wann Tasks ausgeführt werden. Im Klassenzimmer muss ein Schüler die Berechtigung haben, laut zu sprechen, und auf dem GPIB können keine Geräte kommunizieren, es sei denn, sie sind adressiert, um im Bus zu sprechen. Aber wie kann ein Gerät dem Controller mitteilen, dass er etwas zu kommunizieren hat, wenn er nicht ohne Anweisung des Controllers mit dem Controller sprechen kann?

Die Frage kann in der Klassenanalogie so interpretiert werden, wie ein Schüler dem Kursleiter mitteilen kann, dass er etwas zu sagen hat, da der Kursteilnehmer nicht mit dem Kursleiter sprechen kann, es sei denn, der Kursleiter sagt es? Eine gute Methode ist, dass der Schüler seine Hand hebt. Ebenso kann das Gerät eine Hardwareleitung mit dem Namen SRQ aktivieren. Dies ist eine komplett separate Leitung im GPIB-Bus, die dem Controller mitteilt, dass ein Gerät Aufmerksamkeit benötigt.

Warum sollte ein Gerät jemals einen Service anfordern müssen? In manchen Fällen kann ein Controller Daten von einem Gerät anfordern (in das Gerät schreiben) und die Daten zurücklesen, sobald der Schreibvorgang abgeschlossen ist. Dies ist aber nicht in jedem Fall möglich. Manchmal versucht ein Controller, Daten von einem Gerät zurückzulesen, bevor Daten verfügbar sind (die Erzeugung der Daten kann sehr lange dauern), und es wird ein Timeout-Fehler ausgegeben. Diese Situation ist vergleichbar damit, dass ein Professor den Studenten um die Antwort auf ein Problem bittet, bevor der Student das Problem beenden kann. In diesem Fall wartet der Professor lieber darauf, dass der Student seine Hand hebt, wenn er das Problem gelöst hat. Sobald der Student die Hand hebt, fragt der Professor den Studenten nach der Antwort. Da jedoch alle Geräte die SRQ-Leitung gemeinsam nutzen, weiß der Controller nicht, welches Gerät den Dienst angefordert hat. Es ist ein serielles Polling erforderlich, damit die Steuereinheit herausfinden kann, welches Gerät Aufmerksamkeit angefordert hat.

Serial Polling ist eine Methode, um spezifische Informationen von GPIB-Geräten zu erhalten, wenn diese einen Service anfordern. Wenn Sie einen seriellen Poll durchführen, fragt der Controller jedes Gerät ab und sucht nach dem Gerät, das die SRQ-Leitung bestätigt hat. Jedes Gerät reagiert auf den Poll, indem es den Wert des Status-Bytes in seinem Status-Byte-Register ausgibt (siehe Abbildung 1). Geräteabhängige Bedingungen, wie das Vorhandensein verfügbarer Daten oder eine Fehlerbedingung, bestimmen diesen Wert. ANSI/IEEE-Standard 488.1-1987 legt fest, dass ein Bit im Status-Byte, das RQS-Bit (Bit 6), TRUE ist, wenn das Gerät einen Dienst angefordert hat. Die anderen Bits im Statusbyte werden dem Gerätehersteller überlassen. IEEE-488.1-kompatible Geräte können Bits haben, die bestimmen, ob ein Gerätefehler aufgetreten ist oder ob das Gerät einen Selbsttest durchführt. Da diese Bitdefinitionen zwischen Geräteherstellern nicht einheitlich sind, variiert die Methode zur Bestimmung der Ursache einer Serviceanfrage je nach Gerät.


Der ANSI/IEEE-Standard 488.2-1987 löst dieses Problem, indem bestimmte Serviceanfragebedingungen definiert werden, so dass ein Modell das Statusbyte für alle 488.2-konformen Geräte beschreibt. Der IEEE-488.2-Standard baut auf dem IEEE-488.1-Status-Byte auf und erweitert es (siehe Abbildung 2). IEEE 488.2 definiert das RQS-Bit wie der Standard IEEE 488.1. IEEE 488.2 fügt das MAV-Bit (Message Available) und das ESB-Bit (Event Status Bit) hinzu. Das MAV-Bit wird gesetzt, wenn das Gerät zuvor nach Daten abgefragt wurde und eine ausstehende Datennachricht zu senden hat. Das ESB-Bit zeigt an, dass eines der im Standardereignisstatusregister definierten Standardereignisse aufgetreten ist. Durch Festlegen der entsprechenden Bits im Register "Standard Event Status Enable" definieren Sie, welche Standardereignisse den ESB festlegen. Zu diesen Ereignissen gehören Einschalten, Benutzeranfrage, Befehlsfehler, Ausführungsfehler, Geräteabhängiger Fehler, Abfragefehler, Anfragesteuerung und Operation abgeschlossen. Durch Setzen der entsprechenden Bits im Service Request Enable Register können Sie ein Gerät so konfigurieren, dass es die SRQ-Leitung aktiviert, wenn ESB oder MAV gesetzt sind oder wenn eine vom Hersteller festgelegte Bedingung eintritt.

Die Unterpalette LabVIEW GPIB 488 enthält folgende Funktionen, die für das serielle Polling in LabVIEW unerlässlich sind:

GPIB Serial Poll (ibrsp in NI-488) führt einen seriellen Poll durch und gibt den Wert des Statusbytes von einem Gerät aus. Das Programm muss das RQS-Bit im Statusbyte manuell überprüfen, um festzustellen, ob das Gerät einen Dienst angefordert hat.

GPIB Wait (ibwait in NI-488) wartet auf den Zustand, der durch eine bestimmte Statuswortmaske in einem bestimmten GPIB-Bus angezeigt wird. Das Statuswort ist eine globale Variable (16 Bit), die unter anderem den Zustand der SRQ-Leitung (Bit 12, SRQI) und ob ein Gerät einen Dienst angefordert hat (Bit 11, RQS) enthält. Wenn der übergebene Vektor 0 ist, wartet er auf keinen Case und aktualisiert ibsta oder das Statuswort. Wenn die Maske jedoch auf Bit 12 (SRQI) prüft, wartet die Funktion, bis diese bestimmte Leitung für eine bestimmte GPIB-Karte bestätigt wird, deren Adresse in GPIB: Warten angegeben ist.

Das Warten auf GPIB RQS (ibwait in NI-488, mit Maske für Bit 11) ähnelt der Verwendung der GPIB-Wartefunktion mit Maske für Bit 11, jedoch unter Verwendung der GPIB-Adresse der jeweiligen Geräteadresse anstelle der Adresse der GPIB-Karte (beim Warten auf Bit 12). Diese Funktion wartet darauf, dass ein bestimmtes Gerät einen Service anfordert, und nicht darauf, dass eine Karte (mit der mehrere Geräte verbunden sein könnten) eine Serviceanfrage empfängt. Diese Funktion wartet, bis entweder das RQS-Bit aktiviert oder das Timeout überschritten wird.

In den folgenden Beispielen wird gezeigt, wie mit Hilfe von LabVIEW GPIB-Funktionen SRQs bedient und Geräte seriell abgefragt werden.

In LabVIEW Beispiel 1 (Abbildung 3) wird ein Befehl an einen NI-Gerätesimulator übertragen. Der Befehl enthält Anweisungen für das Gerät, eine Service Request (SRQ) zu erzeugen, wenn ein Ereignis des Typs Operation Completed im Ereignisstatusregister (ESR) registriert ist. Die ersten beiden Befehle schreiben diese Anweisungen an das Service Request Enable Register und das Event Status Enable Register (IEEE-488.2). Der dritte Befehl fordert den Gerätesimulator auf, eine Sinusschwingung zu erzeugen; der letzte Befehl erzeugt ein Ereignis des Typs Operation abgeschlossen. Der folgende Programmabschnitt wartet darauf, dass der SRQ durch Prüfen des Bits 12 des Statusworts erzeugt wird. Nachdem es erzeugt wurde, wird ein serieller Poll am Gerätesimulator durchgeführt, um das Statusbyte zu lesen und den Grund für die Erzeugung eines SRQ zu erfahren. Wenn Bit 5 (aus dem Ereignisstatusregister mit dem Bit Operation Complete) und Bit 6 (RQS, das Gerät hat den Dienst angefordert) gesetzt ist, liest die Steuereinheit die Daten vom Gerätesimulator zurück. Beachten Sie, dass das ESR-Register gelöscht werden muss. Dadurch wird verhindert, dass das Gerät unerwünschte Serviceanfragen erzeugt.


LabVIEW Beispiel 2 (Abbildung 4) zeigt eine andere Möglichkeit, auf eine Serviceanfrage zu warten. Im letzten Beispiel hält der Prozessor jedoch an und wartet, ohne weitere Operationen durchzuführen. Im ersten Beispiel könnten andere Operationen parallel ausgeführt worden sein, während das Gerät auf eine Serviceanfrage gewartet hat.

Die GPIB-488.2-Funktionen bieten neue Funktionen für das serielle Polling, so dass mehrere Geräte mit einem GPIB-Befehl abgefragt werden können. LabVIEW hat diese Funktionen in die Unterpalette GPIB 488.2 aufgenommen – AllSpoll und FindRQS.

AllSpoll kann mit einem einzigen Routineaufruf mehrere Geräte seriell abfragen. AllSpoll speichert das Statusbyte jedes abgefragten Geräts in einem vordefinierten Array. Sie müssen das RQS-Bit im Statusbyte jedes Geräts manuell überprüfen, um festzustellen, ob das Gerät einen Dienst angefordert hat.

FindRQS kann mehrere Geräte seriell abfragen. Wenn eines der Geräte einen Dienst anfordert, indem es SRQ aktiviert, gibt die Routine den Index und den Statusbyte-Wert des ersten Geräts aus, das den Dienst anfordert.

Wenn Sie wissen, dass nur ein Gerät den SRQ aktiviert hat und wissen möchten, welches und das dazugehörige Antwortbyte, verwenden Sie die Funktion "FindRQS". Wenn Sie vermuten, dass mehrere Geräte den SRQ aktiviert haben, verwenden Sie AllSpoll, um die Antwortbytes für den seriellen Poll von allen Geräten zu empfangen. Wenn das Statusbyte Bit 6 hat, bedeutet dies, dass das Gerät einen Service angefordert hat. Mit anderen Worten, der Wert des Statusbytes ist mindestens Hex 40, wenn ein Gerät einen Dienst anfordert.

LabVIEW Beispiel 3 (Abbildung 5) zeigt, wie mit den Funktionen von LabVIEW NI-488.2 serielle Pollings durchgeführt werden. Beachten Sie, dass dieses GPIB-488.2-Beispiel den zuvor gezeigten GPIB-Beispielen sehr ähnlich ist. Die meisten LabVIEW GPIB-Funktionen wurden durch die entsprechenden LabVIEW GPIB 488.2-Funktionen ersetzt, z. B. „Senden“ und „Empfangen“ anstelle von „GPIB Schreiben“ und „GPIB Lesen“, „ReadStatus“ anstelle von „GPIB Serial Poll“ und „SRQ testen“ anstelle von „GPIB Warten“ und Setzen der Maske auf 0. Darüber hinaus zeigt dieses Beispiel eine bessere Möglichkeit, mögliche Fehler im Programm zu kontrollieren, indem der Fehler-Cluster zwischen den Zyklen der While-Schleife mit Hilfe eines Schieberegisters weitergeleitet wird.

In diesem Anwendungshinweis wird beschrieben, wie der GPIB-Controller mit Hilfe der NI-488-Software Serviceanfragen von IEEE-488-Geräten auf dem Bus erkennt und beantwortet. Es enthält auch LabVIEW-Codebeispiele, die zeigen, wie Sie mit den LabVIEW GPIB-Funktionen Geräte seriell abfragen können.