Serielles Polling ist eine Methode, um spezifische Informationen von GPIB-Geräten zu erhalten, wenn diese einen Service anfordern. Wenn Sie ein serielles Polling durchführen, fragt der Regler jedes Gerät ab, um das Gerät zu finden, das SRQ aktiviert hat. Das Gerät reagiert auf den Poll mit dem Wert seines Statusbytes. Geräteabhängige Bedingungen, wie das Vorhandensein verfügbarer Daten oder eine Fehlerbedingung, bestimmen diesen Wert. ANSI/IEEE-Standard 488.1-1987 gibt nur ein Bit im Statusbyte Bit 6 an, was TRUE ist, wenn das Gerät einen Dienst anfordert. Die anderen Bits im Statusbyte werden dem Gerätehersteller überlassen. IEEE-488.1-kompatible Geräte haben Bits, die bestimmen, ob ein Gerätefehler aufgetreten ist oder ob das Gerät einen Selbsttest durchführt. Diese Bit-Definitionen sind zwischen den Geräteherstellern nicht einheitlich und die Methode zur Bestimmung der Ursache einer Serviceanfrage variiert 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 konformen Geräte beschreibt. Bit 6, das RQS-Bit (Device Request Service), entspricht der IEEE-488.1-Definition. Wenn Bit 6 gesetzt ist, hat das Gerät den Dienst angefordert. Der IEEE-488.2-Standard definiert Bit 4 und 5; Gerätehersteller definieren die verbleibenden Bits (0 bis 3 und 7). Bit 4 ist das MAV-Bit (Message Available). Dieses Bit wird gesetzt, wenn das Gerät zuvor nach Daten abgefragt wurde und eine ausstehende Datennachricht gesendet werden muss. Bit 5 ist das Ereignisstatusbit (ESB). Dieses Bit wird gesetzt, wenn mindestens eines der aktivierten IEEE-488.2-definierten Ereignisse auftritt. Zu diesen Ereignissen gehören Einschalten, Benutzeranfrage, Befehlsfehler, Ausführungsfehler, geräteabhängiger Fehler, Abfragefehler, Anfragesteuerung und Abschluss der Operation. Das Gerät kann SRQ aktivieren, wenn ESB oder MAV gesetzt sind oder wenn eine vom Hersteller definierte Bedingung eintritt.
Die Routinen NI-488.2 basieren auf den Sequenzen des IEEE-488.2-Standards. Routinen für SRQ-Service und serielles Polling sind AllSpoll, FindRQS, ReadStatusByte, TestSRQ und WaitSRQ.
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 Geräts aus, das den Dienst anfordert.
ReadStatusByte gibt den Wert des Statusbytes von einem Gerät aus, d. h. es führt einen einzelnen seriellen Poll durch. Das Programm muss das RQS-Bit im Statusbyte manuell überprüfen, um festzustellen, ob das Gerät einen Dienst angefordert hat.
TestSRQ bestimmt, ob die SRQ-Leitung aktiviert oder nicht aktiviert ist.
WaitSRQ ähnelt TestSRQ mit dem Unterschied, dass WaitSRQ das Anwendungsprogramm so lange anhält, bis entweder SRQ aktiviert oder das Timeout überschritten wird.
Das folgende QuickBASIC-Beispiel führt eine SRQ-Wartung durch und ermittelt anhand von NI-488.2 Routinen, welches Gerät den gewünschten Dienst anfordert. Im folgenden Beispiel werden diese Annahmen getroffen: Auf dem GPIB befinden sich drei Geräte an den Adressen 3, 4 und 5, und die GPIB-Schnittstelle wird als Busindex 0 bezeichnet.
REM $include: 'qbdecl.bas'
REM SRQ-Serviceprogramm unter Verwendung von NI-488.2-Routinen. Dieser Code REM wartet unbegrenzt in einer Schleife auf die Bestätigung von SRQ. Wenn REM SRQ aktiviert ist, springt das Programm zu einem benutzerdefinierten REM-Unterprogramm, das die Geräte seriell abfragt und das Statusbyte für den seriellen Poll analysiert.
.
Karte% = 0
100 CALL TestSRQ(Karte%, Ergebnis%) WENN Ergebnis% = 1 DANN
Seriell aufrufen.SONST abfragen
GOTO 100 END, WENN
Alternativ können Sie die WaitSRQ-Routine implementieren, um dieselbe Aufgabe auszuführen, wie im folgenden Beispiel gezeigt. Der Hauptunterschied besteht darin, dass der Betrieb so lange unterbrochen wird, bis SRQ aktiviert wird oder das Timeout-Limit überschritten wird.
WartenAufrufSRQ(Karte%, Ergebnis%) WENN Ergebnis% = 1 DANN
CALL serial.poll ELSE
DRUCKEN "WaitSRQ Timeout; kein SRQ" END IF
Sobald der GPIB-Controller die SRQ-Leitung mit Hilfe einer der NI-488.2 Routinen erkannt hat, wird jedes Gerät seriell abgefragt. Das von jedem Gerät ausgegebene Statusbyte für den seriellen Poll liefert wertvolle Statusinformationen, z. B. ob das Gerät einen Dienst angefordert hat und warum. Die Steuereinheit kann das Statusbyte für den seriellen Poll jedes Geräts analysieren, um diese Informationen zu erhalten.
Sie können die FindRQS-Routine verwenden, um zu bestimmen, welches Gerät einen Service angefordert hat. FindRQS fragt jedes Gerät seriell ab und gibt nur das Statusbyte des Geräts aus, das den Dienst angefordert hat. Die Routine prüft automatisch das RQS-Bit in jedem Statusbyte für den seriellen Poll. Der im Adress-Array aufgeführte Index des Geräts, das den Dienst angefordert hat, wird in der globalen Variablen ibcnt ausgegeben. Im folgenden Beispiel sei angenommen, dass drei Geräte an den Adressen 3, 4 und 5 mit dem GPIB verbunden sind und dass eines davon SRQ aktiviert hat.
REM $include: 'qbdecl.bas'
DIM-Adressliste%(3) .
. Adressliste% (0) = 3 Adressliste% (1) = 4 Adressliste% (2) = 5 Adressliste% (3) = NOADDR
FindRQS AUFRUFEN (0, Adressliste% (), Ergebnis%)
DRUCKEN "Gerät am Index";ibcnt;"angeforderter Dienst"
REM Analysieren Sie result%, um festzustellen, warum das Gerät SRQ aktiviert hat. REM Weitere Informationen zu den Statusbyte-Definitionen für den seriellen Poll finden Sie in der Dokumentation Ihrer Geräte für REM.
Mit AllSpoll oder ReadStatusByte kann ein Gerät seriell abgefragt werden. Der folgende Programmcode zeigt eine mögliche Implementierung von AllSpoll. Angenommen, es befinden sich drei Geräte an den Adressen 3, 4, 5 auf dem GPIB und SRQ wird vom Controller erkannt. Die Statusbytes des seriellen Polls für jedes Gerät werden zur weiteren Analyse im Array resultlist%() gespeichert.
REM $include: 'qbdecl.bas'
DIM-Ergebnisliste% (2) .
.
AlleSpoll aufrufen (0, Adressliste% (), Ergebnisliste% ())
FÜR i% = 0 bis 2
WENN Ergebnisliste% (i%) UND &H40 DANN
DRUCKEN "Gerät am Index";i%;"Service angefordert" END IF
Nächste i%
Die NI-488-Funktionen sind ein Industriestandard für Gerätesteuerungsanwendungen. In diesem Abschnitt werden die Funktionen zur Erkennung von SRQ und zur Durchführung eines seriellen Polls beschrieben.
NI-488-Funktionen werden in zwei Gruppen unterteilt: Gerätefunktionen und Kartenfunktionen. Gerätefunktionen führen die Adressierung eines Geräts und die Datenübertragung in einem einzigen Aufruf durch. Im Vergleich dazu kann eine Kartenfunktion die Geräte auf der GPIB-Karte adressieren und eine andere die Datenübertragung durchführen. Ob eine Funktion als Karten- oder Gerätefunktion bezeichnet wird, hängt vom Einheitsdeskriptorwert ab, der als einer der Parameter in der Funktion übergeben wird. Wenn sich der Einheitendeskriptor auf eine Schnittstellenkarte bezieht, wird die Funktion als Kartenfunktion bezeichnet.
Die für serielle Polls verwendete NI-488-Funktion ist ibrsp. ibrsp führt einen einzelnen seriellen Poll durch und gibt das Antwortbyte für serielle Polls an das Anwendungsprogramm aus. Sie entspricht der zuvor beschriebenen Routine NI-488.2 ReadStatusByte.
NI-488.2-Treiber verfügen über eine interne Funktion namens Automatisches serielles Polling oder Autopolling. Wenn Autopolling aktiv ist und die SRQ-Leitung auf High wechselt, führt der Treiber automatisch folgende Schritte aus: 1) mit dem seriellen Polling jedes Geräts beginnen, das von ibfind oder ibdev geöffnet wurde, und stoppen, wenn die SRQ-Leitung auf Low wechselt; 2) das Antwort-Statusbyte(s) für das spätere Abrufen in einer Speicherwarteschlange speichern; 3) das RQS-Bit im Statuswort (ibsta) jedes Geräts setzen, das ein Statusbyte mit Bit 6 ausgegeben hat.
Um aktiv zu sein, muss Autopolling aktiviert und zugelassen sein. Ob Autopolling aktiviert ist, richtet sich nach dem Treiberkonfigurationsprogramm oder der Funktion ibconfig. Beachten Sie, dass alle NI-Treiber per Voreinstellung mit aktiviertem Autopolling geliefert werden. Autopolling ist nach der Ausführung jeder Gerätefunktion auf NI-488-Ebene zulässig. Autopolling ist nach Ausführung von Funktionen des Typs NI-488 auf Kartenebene oder Routinen des Typs NI-488.2 unzulässig.
Wenn der GPIB-Karte ein Interrupt zugewiesen ist, kann Autopolling sofort auf die SRQ-Leitung reagieren, solange keine GPIB-I/O läuft. Wenn die Karte keinen Interrupt hat, kann Autopolling nur auf eine Serviceanfrage reagieren, während ein Gerät auf RQS wartet oder direkt nachdem eine Gerätefunktion abgeschlossen ist und im Begriff ist, zum Anwendungsprogramm zurückzukehren.
Der Hauptvorteil von Autopolling besteht darin, dass Geräte, die Service anfordern, so schnell wie möglich abgefragt werden. Wenn der GPIB-Karte ein Interrupt zugewiesen ist, ist Autopolling eine Interrupt-Dienstroutine, die die schnellste Reaktion auf die festgelegte SRQ-Leitung garantiert. Der Nachteil bei der Verwendung von Autopolling besteht darin, dass Sie bei der Programmierung Ihrer Anwendungen vorsichtig sein müssen, um sicherzustellen, dass Autopolling aktiv (aktiviert und erlaubt) ist.
Aus programmtechnischer Sicht eignet sich Autopolling am besten für Situationen, in denen nur jeweils ein Gerät einen Service anfordert. Dies liegt daran, dass die Überwachung der SRQ-Leitung als Hinweis auf eine Serviceanfrage bei aktivem Autopolling nicht zuverlässig ist. Um also bei aktivem Autopolling nach einer Serviceanfrage zu suchen, müssen Sie das RQS-Bit im ibsta-Statuswort jedes Geräts überprüfen, das möglicherweise gewartet werden muss. Wenn Autopolling nicht aktiv ist, werden Serviceanfragen durch Überprüfen der SRQ-Leitung überwacht. Dies kann durch einfaches Überprüfen des SRQI-Bits einer beliebigen ibsta oder durch Verwendung von iblines erfolgen.
Der folgende Programmcode veranschaulicht die Verwendung der Funktionen ibwait und ibrsp in einer typischen SRQ-Servicesituation, wenn Automatic Serial Polling deaktiviert ist. ibwait hält die Programmausführung an, bis bestimmte Bedingungen auf dem GPIB erfüllt sind.
REM $include: 'qbdecl.bas'
REM In diesem Beispiel wird angenommen, dass zwei Geräte REM mit dem GPIB verbunden sind. Jedes Gerät kann SRQ aktivieren. REM Eines der Geräte ist ein Oszilloskop (als scope bezeichnet) REM und das andere ist ein Digitalmultimeter (als dmm bezeichnet).
REM Die erste Aufgabe besteht darin, auf die Bestätigung der SRQ-Leitung zu warten. Dieses REM kann durch ein ibwait für SRQI oder durch eine Schleifenstruktur REM mit der Funktion ibwait 0 oder iblines erfolgen. In dieser Abbildung, REM, warten wir mit der Funktion ibwait entweder auf das Setzen des SRQI-Bits auf REM oder auf einen Timeout.
ibfind aufrufen ("gpib0", brd0%) ibfind aufrufen ("dev1", scope%) ibfind aufrufen ("dev2", dmm%)
Aufruf ibwait (brd0%, SRQI|TIMO)
REM Wenn ibwait aufgrund von SRQI beendet wurde, werden die REM-Geräte abgefragt und ausgegebene Statusbytes interpretiert, um zu sehen, welches, wenn nicht beide REMs, den Dienst angefordert haben.
WENN (ibsta% UND SRQI) DANN
REM Da Autopolling in diesem Fall nicht aktiv ist, verwendet ibrsp REM den gpib-Bus, um das Statusbyte aus dem Oszilloskop zu erhalten. ibrsp(scope%, spr.scope%) IF (spr.scope% AND &H40) AUFRUFEN UND DANN "Scope asserted SRQ" DRUCKEN.
REM Hier würden Sie das Statusbyte für den seriellen Poll, REM spr.scope%, analysieren, um die Ursache für den SRQ zu ermitteln.
ibrsp(dmm%, spr.meter%) aufrufen
WENN (spr.meter% AND &H40) DANN "DMM hat SRQ bestätigt" DRUCKEN.
REM Analysieren Sie den Rest des Statusbytes für den seriellen Poll, REM spr.meter%, um die Ursache des SRQ zu ermitteln.
END, WENN
Wenn Autopolling aktiv ist, muss das RQS-Bit von ibsta für das betreffende Gerät verwendet werden, um festzustellen, ob das Gerät einen Service angefordert hat. Beachten Sie, dass ibrsp wieder verwendet wird, um das Statusbyte auszugeben, aber dieses Mal wissen wir bereits, dass Bit 6 gesetzt ist, da das RQS-Bit nur von einem Gerät geprüft wird. Außerdem greift ibrsp nur auf das Statusbyte zu, das zuvor von der Autopolling-Routine ermittelt und gespeichert wurde.
REM Wenn Autopolling aktiv ist, kann der folgende Codeausschnitt als Unterprogramm verwendet werden, um zu überprüfen, ob ein bestimmtes Gerät einen REM-Dienst anfordert.
SUB RQScheck(Gerät%)
ibwait (device%, 0) IF (ibsta% AND RQS) DANN AUFRUFEN
DRUCKEN "Gerätegestützte SRQ."
REM In diesem Fall pollt ibrsp das Gerät nicht, sondern REM gibt lediglich das Antwortbyte aus dem Speicher aus. REM Das Statusbyte wird verwendet, um zu bestimmen, wie das Gerät REM gewartet werden soll.
ibrsp aufrufen (Gerät%, spr.Gerät%)
END, WENN
END-SUB
In diesem Dokument wird beschrieben, wie der GPIB-Controller mit Hilfe der NI-488.2 Software Serviceanfragen von IEEE-488-Geräten auf dem Bus erkennt und beantwortet. Mit den in diesem Dokument beschriebenen NI-488.2 Routinen und NI-488-Funktionen können Sie SRQ-Services und serielle Pollings durchführen. Die Codebeispiele zeigen, wie Routinen und Funktionen in einem Anwendungsprogramm verwendet werden können.