GPIB-Fehlercodes und gängige Lösungen (Teil 3)

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.

Situation: 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.

Situation: 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:

• Achten Sie darauf, dass der von der Callback-Funktion ausgegebene Wert ein gültiger ibnotify-Maskenwert ist.
• Sorgen Sie dafür, dass die Callback-Funktion den Wert 0 ausgibt, um asynchrone Ereignis-Benachrichtigungen aufzuheben. Durch anschließendes Aufrufen von ibnotify kann die Benachrichtigung anschließend wieder aktiviert werden.

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-ID außerhalb des Bereichs von 0 bis 99 wird an eine herkömmliche NI-488.2-Funktion oder -Routine auf Kartenebene übergeben.
  Die Funktion ibconfig oder ibmask wird mit einem Geräteeinheitsdeskriptor und einer ausschließlich für Karten geltenden Konfigurationsoption bzw. mit einem Karteneinheitsdeskriptor und einer ausschließlich für Geräte geltenden 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.

Situation: Warten auf ein angegebenes Handle.

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 ein ibwait-Aufruf für den angegebenen Einheitsdeskriptor bereits ausgeführt wird, und ein anderer Thread versucht, ibwait für denselben Deskriptor aufzurufen.

Lösung:

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

Situation: Die Ereignisbenachrichtigung wurde abgebrochen, weil 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:

• Vermeiden Sie ein Aufrufen von ibonl, solange im Treiber noch ibwait-Aufrufe ausstehen.
• Verhindern Sie, dass andere Anwendungen ibonl aufrufen, indem Sie die Schnittstelle mit iblck blockieren.

Situation: Schnittstelle ist stromlos.

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.

Der vorliegende Artikel gehört zu einer Artikelreihe. Die anderen Teile finden Sie unter GPIB-Fehlercodes und gängige Lösungen (Teil 1) und GPIB-Fehlercodes und gängige Lösungen (Teil 2).

• GPIB-Fehlercodes und gängige Lösungen (Teil 1)
• GPIB-Fehlercodes und gängige Lösungen (Teil 2)
• ENEB Error (Non-existent GPIB Board Error) During Communication with Instrument
• NI-488.2 User Manual for Windows
• Legacy: Introduction to the Interactive Control (IBIC)