GPIB-Fehlercodes und gängige Lösungen

Überblick

Nachfolgend finden Sie eine Liste von GPIB-Fehlern mit entsprechenden Lösungen.

 

Ein Großteil des folgenden Textes stammt aus dem "NI-488.2 User Manual for Windows", zu dem Sie unter Weitere Ressourcen weiter unten einen Link finden.

Inhalt

EDVR (0)

Fehlerbedingung: Treiberfehler.

Beschreibung: EDVR wird ausgegeben, wenn die GPIB-Hardware nicht richtig konfiguriert ist oder wenn der an die ibfind-Funktion übergebene Schnittstellen- oder Gerätename falsch ist.

Mögliche Ursache: EDVR-Fehler treten häufig auf, wenn der Schnittstellenname einer Karte oder der Gerätename falsch buchstabiert ist. Zum Beispiel tritt dieser Fehler auf, wenn der Standard-Schnittstellenname für NI-Karten ("GPIB0") mit dem Buchstaben "O" anstelle einer Null angegeben wird ("GPIBO"). Dieser Fehler kann auch auftreten, wenn der an die Funktion ibdev übergebene Kartenindex falsch ist. Die Kartennummer ist der Zahlenanteil des Namens der Schnittstelle für die GPIB-Karte, doch viele Benutzer gehen fälschlicherweise davon aus, dass die Nummer die Primäradresse der Karte ist. Beispiel: Sie installieren in Ihrem Computer eine PCI-GPIB-Karte und weisen dieser die Primäradresse 2 zu. Der Standard-Schnittstellenname für die Karte ist jedoch "GPIB0", das heißt, die Nummer der Karte lautet 0 und nicht 2.

Lösungen:

  • Nutzen Sie im GPIB-Konfigurationsprogramm die Standardeinstellungen für Ihre GPIB-Hardware (das heißt GPIB0 für den Schnittstellennamen und 0 für die Primäradresse).
  • Verwenden Sie die Funktion ibdev anstelle der Funktion ibfind zum Start der Kommunikation mit Ihrem Messgerät (die Notwendigkeit des Gerätenamens entfällt dadurch).
  • Wenn Sie den Gerätenamen für Ihre Messgeräte angeben müssen, sorgen Sie dafür, dass diese in den Gerätevorlagen für das GPIB-Konfigurationsprogramm ordnungsgemäß konfiguriert sind (weitere Informationen finden Sie im Benutzerhandbuch Ihres NI-488.2).
  • Verwenden Sie den von ibdev oder ibfind ausgegebenen Deskriptor als den ersten Parameter in nachfolgenden NI-488-Funktionen. Schauen Sie sich die Variable vor der fehlerhaften Funktion an, um sich zu vergewissern, dass ihr Wert unverändert gültig ist.

ECIC (1)

Fehlerbedingung: Für die Funktion muss die GPIB-Karte der verantwortliche Controller (CIC) sein.

Beschreibung: Für bestimmte Funktionen muss die GPIB-Karte der verantwortliche Controller sein. Die betreffenden Funktionen sind im "NI-488.2 Function Reference Manual" aufgeführt, zu dem Sie weiter unten einen Link finden. Ihre GPIB-Karte ist per Standardeinstellung der System-Controller. Dies ist jedoch nicht das Gleiche wie der verantwortliche Controller. Der System-Controller kann jederzeit zum verantwortlichen Controller werden (auf jedem GPIB kann es immer nur einen System-Controller geben).

Mögliche Ursache: Mögliche Ursache: ECIC-Fehler kommen häufig zustande, wenn zum Beginn des Programms der Befehl "Interface Clear" nicht gesendet wird.

Lösungen:

  • Wenn Ihre GPIB-Karte als System-Controller dienen soll, verwenden Sie ibrsc 1, um zu gewährleisten, dass Ihre GPIB-Karte als System-Controller konfiguriert ist.
  • Wenn Ihre GPIB-Karte der System-Controller ist, sollte mit der Funktion ibsic (oder der Funktion SendIFC) der IFC-Befehl ("Interface Clear") gesendet werden. Dadurch wird Ihre GPIB-Karte der verantwortliche Controller, und die GPIB-Kommunikation wird erneut initialisiert.
  • Wenn Ihre GPIB-Karte einer von mehreren Controllern des Busses ist, sollten Sie vor jedem Aufrufen einer Funktion, für die Ihre GPIB-Karte der verantwortliche Controller sein muss, das CIC-Bit des Status-Worts ibsta überprüfen. Wenn dieses nicht angezeigt wird, können Sie die Funktion ibwait aufrufen (mit dieser wird die Wartezeit-Maske für das CIC-Bit festgelegt), um die weitere Verarbeitung so lange zu verzögern, bis Ihre GPIB-Karte die Steuerung erlangt hat.

ENOL (2)

Fehlerbedingung: Funktion hat keine Listener gefunden.

Beschreibung: Die GPIB-Kommunikation erfordert ein einzelnes Sendegerät (Talker) zum Schreiben von Datennachrichten und ein oder mehrere Empfangsgeräte (Listener) zum Lesen von Datennachrichten. ENOL tritt in der Regel auf, wenn ein Schreibvorgang unternommen wurde, jedoch keine Empfangsgeräte adressiert werden oder unter den angegebenen Adressen keine Empfangsgeräte vorhanden sind. Bei einem Sendegerät zeigt ENOL an, dass die GPIB-Adresse, mit der kommuniziert werden soll, nicht die GPIB-Adresse des an den Bus angeschlossenen Geräts ist.

Mögliche Ursache: Das Messgerät, mit dem kommuniziert werden soll, befindet sich nicht an der erwarteten Primäradresse, das Messgerät ist nicht eingeschaltet oder das Kabel zum Messgerät ist entweder nicht eingesteckt oder defekt.

Lösungen:

  • Vergewissern Sie sich, dass die GPIB-Adresse Ihres Geräts mit der GPIB-Adresse des Geräts übereinstimmt, an das die Daten geschrieben werden sollen.
  • Überprüfen Sie, dass das Kabel ordnungsgemäß an das Gerät angeschlossen ist. Tauschen Sie das Kabel aus, um sicherzugehen, dass das Kabel nicht schadhaft ist.
  • Stellen Sie sicher, dass mindestens zwei Drittel Ihrer Geräte eingeschaltet sind.
  • Verwenden Sie für den Datenaustausch auf Kartenebene den entsprechenden Hex-Code in der Funktion ibcmd, um Ihr Gerät als Empfangsgerät zu adressieren.
  • Rufen Sie die Funktion ibpad Funktion (und bei Bedarf ibsad) auf, um die Primäradresse des Geräts festzulegen. Die Funktion ibpad gibt aus, was die vorige Einstellung für das Gerät war, und Sie können prüfen, ob die konfigurierte Adresse des Geräts mit der tatsächlichen Adresse übereinstimmt.

EADR (3)

Fehlerbedingung: Die GPIB-Karte (GPIB0 oder GPIB1) wurde falsch adressiert.

Beschreibung: EADR tritt auf, wenn die GPIB-Karte der verantwortliche Controller ist und sich vor Beginn der Lese- und Schreibfunktionen nicht richtig adressiert. Die Fehlermeldung EADR wird auch von der Funktion ibgts ausgegeben, wenn ein Shadow-Handshake angefordert wird und die GPIB-ATN-Leitung deaktiviert ist. In diesem Fall kann der Shadow-Handshake nicht ausgeführt werden, und der Fehler dient als entsprechender Hinweis.

Mögliche Ursache: Ihre GPIB-Karte ist auf die gleiche Primäradresse wie das Messgerät konfiguriert, mit dem kommuniziert werden soll.

Lösungen:

  • Weisen Sie Ihrer GPIB-Karte stets eine andere Adresse als Ihrem Gerät zu. Die GPIB-Karte sollte (fast) immer die Primäradresse 0 haben und ohne Sekundäradresse konfiguriert sein. Rufen Sie ibpad 0 und ibsad 0 am Anfang Ihres Programms auf, damit die Adresse Ihrer Karte ordnungsgemäß eingerichtet wird.
  • Erst wenn die GPIB-Karte korrekt adressiert ist, sollten Funktionen wie ibrd, ibwrt, RcvRespMsg oder SendDataBytes aufgerufen werden.
  • Vermeiden Sie es,ibgts aufzurufen, außer sofort nach dem Aufrufen von ibcmd. Die Funktion ibcmd aktiviert die ATN-Leitung, woraufhin die Geräte auf Befehle statt auf Datennachrichten warten.

EARG (4)

Fehlerbedingung: Ungültiges Argument für einen Funktionsaufruf.

Beschreibung: EARG tritt auf, wenn an einen Funktionsaufruf ein ungültiges Argument übergeben wird.

Mögliche Ursache: Nachfolgend einige Beispiele: Die Funktion ibtmo wird mit einem Wert aufgerufen, der nicht im Bereich von 0 bis 17 liegt (die zulässigen Timeout-Werte entsprechen einer Wertetabelle von 0 bis 17, wobei die Standardeinstellung 13 einem Timeout von 10 Sekunden entspricht). Die Funktion ibeos wird mit wertlosen Bits im höchstwertigen Byte des zweiten Parameters aufgerufen, oder ibpad (oder ibsad) wird mit ungültigen Adressen aufgerufen.

Lösungen:

  • Informieren Sie sich im "NI-488.2 Function Reference Manual" (siehe den Link unten), wie die gültigen Parameter lauten.
  • Verwenden Sie keinen Gerätedeskriptor in einer Funktion auf Kartenebene und keinen Kartendeskriptor in einer Funktion auf Geräteebene.

ESAC (5)

Fehlerbedingung: Situation: Die GPIB-Karte ist nicht der System-Controller.

Beschreibung: ESAC tritt auf, wenn ibsic, ibsre, SendIFC oder EnableRemote aufgerufen wird und die GPIB-Karte nicht als System-Controller fungieren kann.

Mögliche Ursache: Die GPIB-Karte ist nicht als System-Controller konfiguriert.

Lösungen:

  • Weisen Sie der GPIB-Karte System-Controller-Funktion zu, indem Sie ibrsc 1 aufrufen, oder das GPIB-Konfigurationsprogramm verwenden.

EABO (6)

Fehlerbedingung: I/O-Operation wurde abgebrochen.

Beschreibung: EABO weist darauf hin, dass ein I/O-Vorgang abgebrochen wurde.

Mögliche Ursache: Mögliche Ursache: EABO tritt normalerweise bei einem Timeout während eines Lese- oder Schreibvorgangs auf. Der Fehler kann jedoch auch daher rühren, dass während eines I/O-Vorgangs ibstop, ibclr oder eine ähnliche Funktion aufgerufen wurde. Beim Schreiben von Daten an eine PCI-GPIB-Karte kann es zu einem Timeout kommen, wenn das PCI-Bus-Mastering (eine Option im BIOS Ihres Computers) nicht aktiviert ist. Beim Lesen von Daten kann ein Timeout auftreten, wenn das Sendegerät den letzten Befehl nicht verstanden hat und daher nicht reagiert. Wenn ein Gerät nichts sendet, kommen folgende Ursachen dafür in Frage:

  • Die Nachricht an das Gerät wurde falsch buchstabiert. Zum Beispiel ist "*IDN?" eine gängige Identifizierungsabfrage für IEEE-488.2-konforme Geräte. Es kommt gelegentlich vor, dass man "*IND?" eingibt, so dass das Gerät nicht versteht und folglich keinen Nachrichten-String ausgibt, der empfangen werden kann.
  • Die Nachricht an das Gerät kann auch einen Befehl enthalten, den das Gerät nicht versteht. So wird zum Beispiel die Nachricht "*IDN?" aus dem vorherigen Beispiel nur von IEEE-488.2-konformen Geräten verstanden. Ein älteres, nicht IEEE-488.2-konformes Gerät kann mit "*IDN?" nichts anfangen und erzeugt folglich keinen Nachrichten-String.
  • Das Gerät verwendet möglicherweise ein bestimmtes EOS-Zeichen (EOS = Ende des Strings) zum Signalisieren des Datenendes und Sie vergessen, dieses an die Nachricht anzuhängen. Wenn Ihr Gerät zum Beispiel einen Zeilenvorschub als EOS-Zeichen erwartet, funktioniert "ID?" nicht, sondern nur "ID?\n" (wobei \n einen Zeilenvorschub in IBIC darstellt).\nWenn Ihr Gerät zum Beispiel einen Zeilenvorschub als EOS-Zeichen erwartet, funktioniert "ID?" nicht, sondern nur "ID?\n" (wobei \n einen Zeilenvorschub in IBIC darstellt). \n Wenn Ihr Gerät zum Beispiel einen Zeilenvorschub als EOS-Zeichen erwartet, funktioniert "ID?" nicht, sondern nur "ID?\n" (wobei \n einen Zeilenvorschub in IBIC darstellt).
  • Möglicherweise erwarten Sie ein EOI ("End or Identify", eine der fünf Leitungen zur Busverwaltung) zum Signalisieren des Datenendes. Doch wenn das Messgerät beim Abschluss des Sendevorgangs seiner Nachricht die EOI-Leitung deaktiviert lässt, tritt bei jedem Lesevorgang ein Timeout auf.

Lösungen:

  • Sorgen Sie dafür, dass Ihre Nachrichten nur aus Befehlen aus dem Repertoire des Messgeräts bestehen. Eine Liste der möglichen Befehle finden Sie in der Regel im Benutzerhandbuch Ihres Geräts.
  • Sehen Sie im Benutzerhandbuch nach, ob sich Ihr Gerät in einem GPIB- oder 488.2-Modus befinden muss, um als GPIB-Empfangsgerät zu fungieren.  Oft reagieren Instrumente nur auf die Standardbefehle, nachdem sie in diesen Modus versetzt wurden, und sie geben sonst einen Fehler aus, obwohl ein gültiger Befehl gesendet wurde.
  • Verwenden Sie die für Ihr Gerät angemessene Methode zum Signalisieren des Datenendes. Die Byte-Anzahl (eine bestimmte Anzahl erwarteter empfangener Bytes in einer Nachricht) wird immer verwendet. Manche Geräte arbeiten mit EOS und der Byte-Anzahl, manche mit EOI und der Byte-Anzahl und manche nur mit der Byte-Anzahl. Die für Ihr Messgerät möglichen Methoden zum Signalisieren des Datenendes sind im Benutzerhandbuch aufgeführt.
  • Wenn das Gerät das Datenende durch EOS signalisiert, sorgen Sie dafür, dass das Abschlusszeichen an das Ende der Nachricht angehängt wird. Sie können das Abschlusszeichen im GPIB-Konfigurationsprogramm angeben. Beachten Sie, dass der NI-488.2-Treiber nicht automatisch ein Abschlusszeichen anfügt.
  • Verlängern Sie die Timeout-Zeitspanne für I/O-Operationen mit Hilfe des Befehls ibtmo.
  • Wenn Sie alle Daten empfangen und eine EABO Fehlermeldung erhalten, suchen Sie nach einem bestimmten String-Abschlusszeichen (z. B. Zeilenvorschub oder Wagenrücklauf) und konfigurieren Sie die GPIB-Karte zum Beenden des Lesevorgangs bei diesem Zeichen mit Hilfe der Funktion ibeos.

ENEB (7)

Fehlerbedingung: GPIB-Karte nicht vorhanden.

Beschreibung: ENEB tritt auf, wenn unter der im GPIB-Konfigurationsprogramm angegebenen I/O-Adresse keine GPIB-Karte vorhanden ist. Das Problem kann folgende Ursachen haben: Die Karte ist nicht physisch an das System angeschlossen; die während der Konfiguration angegebene I/O-Adresse weicht von der Einstellung der Karte ab; es besteht ein Systemkonflikt mit der Basis-I/O-Adresse; der Schnittstellenname der Karte unterscheidet sich vom Schnittstellennamen der Ihrem Gerät zugeordneten Karte.

Lösungen:

  • Ermitteln Sie die I/O-Basisadresse für Ihre Karte mit Hilfe des GPIB-Konfigurationsprogramms. Überprüfen Sie anhand des Ressourcen-Managers Ihres Systems, ob der Adressbereich von einer anderen Karte belegt ist oder sich mit dem einer anderen Karte überlappt. Vergewissern Sie sich, dass der Name für Ihr Gerät der gleiche ist wie der Schnittstellenname der Karte, die auf Ihrem Gerät als Kommunikationsadresse konfiguriert ist.
  • Bei alten Karten müssen die Jumper und Dip-Schalter der Karte auf die gleichen Ressourceneinstellungen konfiguriert sein, wie im GPIB-Konfigurationsprogramm festgelegt wurden.
  • Schalten Sie Ihren Computer aus und stellen Sie sicher, dass die Karte fest im Steckplatz sitzt.

EDMA (8)

Fehlerbedingung: Beim Übertragen von Daten mittels DMA tritt ein Fehler auf.

Beschreibung: EDMA zeigt an, dass beim Übertragen von Daten mittels DMA über den GPIB ein DMA-Fehler des Systems aufgetreten ist.

Lösungen:

  • Zum hardwareseitigen Beheben des EDMA-Fehlers müssen Sie Ihre GPIB-Karte lediglich im GPIB-Konfigurationsprogramm so konfigurieren, dass sie keine DMA-Ressource mehr verwendet.
  • Zum softwareseitigen Beheben des EDMA-Fehlers können Sie DMA mit Hilfe der Funktion ibdma deaktivieren.

EOIP (10)

Fehlerbedingung: Funktion kann nicht aufgerufen werden, solange ein asynchroner I/O-Vorgang läuft.

Beschreibung: EOIP tritt auf, wenn im Laufe eines asynchronen I/O-Vorgangs ein anderer GPIB-Aufruf getätigt wurde. Während asynchroner I/O-Operationen können nur die Funktionen ibstop, ibnotify, ibwait, oder ibonl verwendet werden. Bei einem anderen GPIB-Aufruf wird EOIP ausgegeben.

Mögliche Ursache: Während eines asynchronen I/O-Vorgangs wurde eine nicht unterstützte GPIB-Funktion aufgerufen.

Lösung:

  • Führen Sie vor weiteren GPIB-Aufrufen eine erneute Synchronisierung des Treibers und der Anwendung durch. Die erneute Synchronisierung erfolgt mit Hilfe einer der folgenden Funktionen: ibnotify (wenn der an den ibnotify-Callback übergebene ibsta-Wert CMPL enthält, werden der Treiber und die Anwendung neu synchronisiert), ibwait (wenn der ausgegebene ibsta-Wert CMPL enthält, werden der Treiber und die Anwendung neu synchronisiert), ibstop (bricht den asynchronen I/O-Vorgang ab, so dass der Treiber und Ihre Anwendung sofort neu synchronisiert werden) oder ibonl (bricht den asynchronen I/O-Vorgang ab, und die Schnittstelle wird zurückgesetzt, so dass der Treiber und Ihre Anwendung sofort neu synchronisiert werden).

ECAP (11)

Fehlerbedingung: Operation ist nicht durchführbar.

Beschreibung: ECAP tritt auf, wenn Ihre GPIB-Karte nicht zum Ausführen eines Vorgangs in der Lage ist oder wenn die entsprechende Funktion in der Software deaktiviert wurde und ein Aufruf getätigt wird, für den diese Funktion benötigt wird.

Lösung:

EFSO (12)

Fehlerbedingung: Dateisystemfehler.

Beschreibung: EFSO tritt auf, wenn ein Aufruf von ibrdf oder ibwrtf auf ein Problem beim Ausführen einer Dateioperation stößt. Dieser Fehler signalisiert, dass die Funktion die Datei, auf die zugegriffen wird, nicht öffnen, erstellen, suchen, beschreiben oder schließen kann. Der spezifische Betriebssystemfehlercode für diese Bedingung ist in ibcntl enthalten.

Lösungen:

EBUS (14)

Fehlerbedingung: Befehlsbyte-Übertragungsfehler.

Beschreibung: EBUS tritt auf, wenn bestimmte GPIB-Busfehler während der Ausführung von Gerätefunktionen auftreten. Alle Gerätefunktionen senden Befehlsbytes zur Adressierung und zur Durchführung anderer Busverwaltungsoperationen. Von Geräten wird erwartet, dass sie diese Befehlsbytes innerhalb der Zeitspanne akzeptieren, die durch die Standardkonfiguration oder die ibtmo-Funktion festgelegt ist. EBUS kommt zustande, wenn beim Senden dieser Befehlsbytes ein Timeout aufgetreten ist.

Mögliche Ursache: An Ihren GPIB-Controller sind keine GPIB-Geräte angeschlossen. Das kann daran liegen, dass alle Messgeräte ausgeschaltet sind; dass eines der Messgeräte einen Fehlerzustand angenommen und eine Handshake-Leitung aktiviert hat; dass das GPIB-Kabel nicht mit der Karte verbunden ist oder dass das GPIB-Kabel defekt ist.

Lösungen:

  • Vergewissern Sie sich, dass alle Geräte ordnungsgemäß funktionieren, und dass die Geräte, mit denen Daten ausgetauscht werden sollen, tatsächlich eingeschaltet sind.
  • Trennen Sie alle Messgeräte und schließen Sie sie erneut an, um festzustellen, ob eines der Messgeräte das Problem verursacht.
  • Prüfen Sie nach, ob lose oder fehlerhafte Kabel vorhanden sind, und stellen Sie sicher, dass mindestens 2/3 der Geräte eingeschaltet sind (eine Anforderung der Spezifikation IEEE-488).
  • Wenn die Timeout-Zeitspanne für den Treiber zu kurz ist, um Befehlsbytes zu senden, erhöhen Sie die Timeout-Zeitspanne.

ESTB (15)

Fehlerbedingung: Statusbyte für den seriellen Poll gingen verloren.

Beschreibung: ESTB wird nur von der ibrsp-Funktion gemeldet. ESTB zeigt an, dass mindestens ein Statusbyte, das von automatischen seriellen Polls empfangen wurde, aufgrund fehlenden Speicherplatzes verworfen wurde. Zwar sind mehrere ältere Statusbytes verfügbar, jedoch wird vom ibrsp-Aufruf das älteste ausgegeben.

Mögliche Ursache: Das Gerät aktiviert wiederholt die SRQ-Leitung.

Lösungen:

  • Rufen Sie ibrsp häufiger auf, um die Queue zu leeren.
  • Deaktivieren Sie das automatische Polling mit der ibconfig-Funktion (Option IbcAUTOPOLL) oder im GPIB-Konfigurationsprogramm.

ESRQ (16)

Fehlerbedingung: SRQ hängt in ON-Position fest.

Beschreibung: ESRQ kann nur von einem ibwait-Aufruf auf Geräteebene herrühren. Die Funktion ibwait ist in diesem Fall so konfiguriert, dass der restliche Programmcode nach Aufruf der Funktion erst nach dem Aktivieren des RSQ-Bits des Statusworts (ibsta) seine Ausführung fortsetzen kann. ESRQ zeigt an, dass das Warten auf RQS nicht möglich ist, weil die SRQ-Leitung des GPIB im aktivierten Zustand feststeckt.

Mögliche Ursache: Mögliche Gründe: Ein Kabelfehler kann dazu führen, dass die SRQ-Leitung aktiviert bleibt; ein der Software unbekanntes Gerät kann die SRQ-Leitung aktiviert halten – weil die Software dieses Gerät nicht kennt, kann es das Gerät nicht seriell pollen, um die Aktivierung der SRQ-Leitung aufzuheben; ein GPIB-Bustester (oder ein ähnliches Gerät) kann das Aktivieren der SRQ-Leitung erzwingen.

Lösungen:

  • Prüfen Sie, ob eines der Geräte am Bus (auch solche, die nicht Teil Ihrer Anwendung sind) die SRQ-Leitung aktiviert hat. Trennen Sie ggf. das Gerät vom Bus.
  • Untersuchen Sie die GPIB-Kabel und stellen Sie sicher, dass die Anschlüsse ordnungsgemäß sitzen.

ETAB (20)

Fehlerbedingung: Tabellenproblem.

Beschreibung: ETAB tritt nur während der Ausführung der Funktionen FindLstn und FindRQS auf. ETAB gibt an, dass ein Problem mit einer von diesen Funktionen verwendeten Tabelle aufgetreten ist.

Mögliche Ursache: Bei FindLstn bedeutet ETAB, dass die betreffende Tabelle nicht genügend Platz zum Speichern aller gefundenen Empfangsgeräte-Adressen hat. Bei FindRQS bedeutet ETAB, dass keines der Geräte in der gegebenen Tabelle einen Dienst angefordert hat.

Lösungen:

  • Erhöhen Sie im Fall von FindLstn die Größe der Ergebnis-Arrays.
  • Prüfen Sie im Fall von FindRQS, ob Geräte außerhalb Ihrer Anwendung die SRQ-Leitung aktivieren. Trennen Sie ggf. das Gerät vom Bus.

ELCK (21)

Fehlerbedingung: Die GPIB-Schnittstelle ist für den Zugriff gesperrt.

Mögliche Ursache: Dieser Fehler tritt üblicherweise auf, wenn zwei oder mehr Prozesse auf dieselbe Schnittstelle zugreifen und die Schnittstelle bereits von einem Prozess belegt wurde. Wenn ein Vorgang aufgrund der vorhandenen Sperre an der Schnittstelle nicht ausgeführt werden kann, wird dieser Fehler gemeldet. Er wird auch ausgegeben, wenn ein Prozess versucht, die Sperre einer Schnittstelle aufzuheben und keine solche Sperre vorhanden ist.

Lösung:

  • Der ELCK-Fehler lässt sich dadurch vermeiden, dass vor dem nächsten Sperren der Schnittstelle eine Zeit lang gewartet wird (wie lange, steht Ihnen frei). Falls Sie den Befehl iblck zum Sperren der Schnittstelle verwenden, erhöhen Sie den Wert für "LockWaitTime" und warten Sie, bis der andere Prozess die Steuerung der Schnittstelle abgibt. Verhindern Sie außerdem, dass Prozesse eine Schnittstelle über den gesamten Ausführungszeitraum hinweg sperren.

EARM (22)

Fehlerbedingung: ibnotify-Callback konnte nicht wieder aktiviert werden.

Mögliche Ursache: Dieser Fehler tritt auf, wenn NI-488.2-Anwendungen mit asynchroner Benachrichtigung (ibnotify) arbeiten. Diese Funktion ist nützlich, wenn Ihre Anwendung über das Auftreten von einem oder mehreren GPIB-Ereignissen asynchron benachrichtigt werden soll. Die Ereignisbenachrichtigung erfolgt über eine Callback-Funktion. Die Callback-Funktion wird beim Aufruf von ibnotify im NI-488.2-Treiber registriert. Der Fehler gibt an, dass diese Callback-Benachrichtigung sich nicht wieder aktivieren konnte, weil sie einen unzulässigen Wert ausgegeben hat oder ein schwerer Treiberfehler (EDVR) aufgetreten ist.

Lösungen:

EHDL (23)

Fehlerbedingung: Eingangs-Handle ist ungültig.

Mögliche Ursache: Mehrere GPIB-Befehle nehmen das Eingangs-Handle der Karte oder des Geräts als Eingangsparameter an, wodurch dieser Fehler verursacht werden kann. Dieser Fehler kann jedoch unter diversen Umständen auftreten. Einige Situationen sind nachfolgend aufgeführt:

  • Ein gültiges Karten-Handle wird als Geräte-Handle-Parameter (oder umgekehrt) weitergeleitet.
  • Ein ungültiger Karten- oder Gerätedeskriptor wird als Eingangswert an eine NI-488.2-Funktion übergeben.
  • Eine Karten außerhalb des gültigen Bereichs von 0 bis 99 wird an eine traditionelle NI-488.2-Kartenfunktion oder an eine NI-488.2-Routine weitergeleitet.
  • ibconfig oder ibmask werden mit einem Geräte-Deskriptor und einer nur für die Karte gültigen Konfigurationsoption oder mit einem Karten-Deskriptor und einer nur für das Gerät gültigen Konfigurationsoption aufgerufen.

Lösungen:

  • Sorgen Sie dafür, dass die Funktionen auf Geräteebene und Kartenebene beim Aufrufen der entsprechenden Funktionen nicht vermischt werden.
  • Überprüfen Sie außerdem die Gültigkeit des Kartenindexes für den NI-488.2-Aufruf.

EWIP (26)

Fehlerbedingung: Warten auf ein angegebenes Handle.

Mögliche Ursache: Mögliche Ursache: Ein Prozess wird in mehreren Threads ausgeführt, von denen zwei oder mehr auf ein und dieselbe Schnittstelle zugreifen. EWIP zeigt an, dass bereits ein ibwait-Aufruf am angegebenen Einheitsdeskriptor ausgeführt wird. Dieser tritt auf, wenn ein Thread bereits einen ibwait-Aufruf mit demselben Deskriptor durchführt und ein anderer Thread versucht, ibwait am selben Deskriptor aufzurufen.

Lösung:

  • Sorgen Sie dafür, dass immer nur ein Thread einen ibwait-Aufruf für den angegebenen Einheitsdeskriptor ausführt.

ERST (27)

Fehlerbedingung: Die Ereignisbenachrichtigung wurde abgebrochen, da die Schnittstelle zurückgesetzt wurde.

Mögliche Ursache: ERST tritt auf, wenn die Ereignisbenachrichtigung aufgrund eines Rücksetzvorgangs an der Schnittstelle abgebrochen wurde. Ein im Treiber ausstehender ibwait-Aufruf gibt in folgenden Fällen ERST aus:

  • Ein anderer Thread im selben Prozess ruft ibonl mit Hilfe desselben Einheitsdeskriptors wie ibwait auf.
  • Ein anderer Thread oder Prozess gibt ibonl 1 auf Kartenebene aus.

Ein ibnotify-Callback kann im folgenden Fall mit ERST aufgerufen werden:

  • Ein anderer Prozess gibt ibonl 1 auf Kartenebene aus.

Lösungen:

  • Rufen Sie ibonl nicht auf, solange im Treiber noch ibwait-Aufrufe ausstehen.
  • Verhindern Sie, dass andere Anwendungen ibonl aufrufen, indem Sie die Schnittstelle mit iblck blockieren.

EPWR (28)

Fehlerbedingung: Die Schnittstelle hat Strom verloren.

Mögliche Ursache: EPWR tritt auf, wenn die Stromzufuhr einer Schnittstelle unterbrochen wird. Das passiert häufig, wenn das System in den Standby-Modus schaltet oder aus dem Standby-Modus zurückkehrt.

Lösungen:

  • Nehmen Sie alle Handles offline und initialisieren Sie die Anwendung neu.
  • Beenden Sie die Anwendung und führen Sie einen Neustart des Systems durch.
  • Deaktivieren Sie auf dem PC den Standby- und den Ruhezustandsmodus.

Was this information helpful?

Yes

No