Debug LabVIEW shared library calls by troubleshooting the functionality of your library and your Call Library Function Node configuration.

Fehlersuche in Knoten zum Aufruf externer Bibliotheken

Wenn beim Aufrufen von DLLs in LabVIEW Fehler angezeigt werden, prüfen Sie, ob der Knoten zum Aufruf externer Bibliotheken ordnungsgemäß konfiguriert ist.

  • Stellen Sie sicher, dass der Knoten zum Aufruf externer Bibliotheken den richtigen Namen oder Pfad für die DLL hat. Stellen Sie außerdem sicher, dass Sie den Speicherort auf dem Datenträger für Ihren Anwendungsfall angemessen angeben. In einigen Anwendungsfällen müssen Sie die DLL unter Pfad angeben, und in anderen Anwendungsfällen müssen Sie die DLL unter Namen angeben.
  • Vergewissern Sie sich bei in LabVIEW erstellten DLLs, dass der Computer eine Version der LabVIEW Runtime Engine hat, die mit jeder LabVIEW-Version kompatibel ist, mit der DLLs erstellt wurden.
  • Wenn die Fehlermeldung Funktion nicht in Bibliothek gefunden wird, überprüfen Sie, ob der Knoten zum Aufruf externer Bibliotheken die korrekte Schreibweise, Syntax und Groß-/Kleinschreibung für den aufgerufenen Funktionsnamen hat.
  • Vergewissern Sie sich, dass der Compiler die Funktion nicht ergänzt hat.
  • Wenn Sie eine Fehlermeldung erhalten, dass eine sekundäre DLL nicht gefunden werden kann, Sie aber den Pfad zur primären DLL im Knoten zum Aufruf externer Bibliotheken ordnungsgemäß angegeben haben, benötigt die primäre DLL zusätzliche Funktionen von einer oder mehreren anderen DLLs. Finden Sie die anderen DLLs und platzieren Sie sie im gleichen Verzeichnis wie die DLL, die diese benötigt, oder in einem Verzeichnis, das sich im Suchpfad befindet. Weitere Informationen finden Sie in der KnowledgeBase auf ni.com.
  • Wenn Ihr VI abstürzt, vergewissern Sie sich, dass Ausgabetypen und Datentypen von Argumenten für Funktionen im Knoten zum Aufruf externer Bibliotheken genau den Datentypen entsprechen, die Ihre Funktion verwendet. Stellen Sie außerdem sicher, dass der Knoten zum Aufruf externer Bibliotheken die richtige Aufrufkonvention verwendet (C oder __stdcall auf der Registerkarte "Error Checking Level" im Dialogfeld "Call Library Function".
  • Alle Parameter werden so definiert, dass sie mit der richtigen Methode (z. B. Wert oder Zeiger) weitergeleitet werden. Stellen Sie außerdem sicher, dass der Knoten zum Aufruf externer Bibliotheken Argumente in der richtigen Reihenfolge an die Funktion übergibt.
  • Sie übergeben immer einen Puffer oder ein Array, das groß genug für alle Ergebnisse ist, welche die Funktion in den Puffer speichert. Wenn Sie sie jedoch als LabVIEW-Handles weitergeben, verwenden Sie die LabVIEW Manager-Funktionen, um ihre Größe unter Visual C++ oder Xcode-Compilern zu ändern.
  • Wenn Sie eine Nachricht erhalten, liegt die Ursache fast immer in einem Fehler im Code der DLL, z. B. beim Schreiben über das Ende des für ein Array reservierten Speichers hinaus. Diese Art von Abstürzen treten möglicherweise nicht immer zu dem Zeitpunkt auf, wenn der Aufruf der gemeinsamen Bibliothek im Blockdiagramm ausgeführt wird.
  • Für eine DLL mit ActiveX-Objekten verwenden Sie die Funktion Automation Open mit dem Eigenschaftsknoten und dem Methodenknoten.
  • HinweisFür alle Aufrufe von LabVIEW-DLLs sollte In beliebigem Thread ausführen ausgewählt sein. Wenn Sie den Knoten zum Aufruf externer Bibliotheken mit einer LabVIEW-eignen DLL konfigurieren und die Einstellung In UI-Thread ausführen auswählen, hängt sich LabVIEW möglicherweise auf und ein Neustart ist erforderlich.
  • Pascal-Strings überschreiten nicht die maximale Zeichenlänge von 255 Zeichen.
  • Die Größe von Arrays und Strings kann nur geändert werden, wenn der Knoten zum Aufruf externer Bibliotheken ein LabVIEW Array oder LabVIEW String Handle übergibt. Ändern der Größe von Arrays und Strings mit Hilfe von Funktionen, die über labviewv.lib in ein Visual-C++-Projekt und liblvexports.a in ein Xcode-Projekt exportiert werden
  • Denken Sie daran, dass C-Strings NULL beendet sind. Wenn Ihre DLL-Funktion numerische Werte im Binär-String-Format ausgibt, z. B. über GPIB oder den seriellen Port, gibt sie möglicherweise NULL Werte als Teil des Daten-Strings aus.

Fehlersuche in DLLs

Wenn beim Aufrufen von DLLs in LabVIEW Fehler angezeigt werden, lesen Sie die folgenden Tipps, um sicherzustellen, dass es keine Probleme mit der aufgerufenen DLL gibt.

  • Stellen Sie sicher, dass Funktionen von DLL, die von anderen Anwendungen aufgerufen werden, im Abschnitt EXPORTS der Moduldefinitionsdatei angezeigt werden, oder fügen Sie das Schlüsselwort _declspec (dllexport) in die Funktionsdeklaration ein. Um eine Plattformabhängigkeit in exportierten Funktionsnamen zu vermeiden, verwenden Sie den Befehl extern "C"{} in Ihrer Header-Datei (vgl. folgendes Beispiel).

    extern "C" {

    /* Ihre Funktionsprototypen hier */

    }

  • Denken Sie daran, dass Sie die Funktion mit dem Schlüsselwort _declspec (dllexport) in der Header-Datei und im Quellcode deklarieren müssen oder sie im Abschnitt EXPORTS der Moduldefinitionsdatei definieren.
  • Wenn Sie das Schlüsselwort _declspec (dllexport) verwenden und gleichzeitig die Aufrufkonvention __stdcall verwenden, müssen Sie den DLL-Funktionsnamen im Abschnitt EXPORTS der Moduldefinitionsdatei .def deklarieren. Wenn keine .def-Datei vorhanden ist, kann __stdcall Funktionsnamen in einem unvorhersehbaren Muster abschneiden, so dass der tatsächliche Funktionsname für Anwendungen, die die DLL aufrufen, nicht verfügbar ist.
  • Wenn eine Funktion nicht ordnungsgemäß exportiert wurde, müssen Sie die DLL neu kompilieren. Kompilieren Sie die DLL niemals neu, während die DLL von einer anderen Anwendung in den Speicher geladen wird, z. B. von Ihrem VI. Bevor Sie eine DLL neu kompilieren, stellen Sie sicher, dass alle Anwendungen, die mit der DLL arbeiten, aus dem Speicher entfernt werden. Dadurch wird verhindert, dass die DLL beim erneuten Kompilieren in den Speicher geladen wird. Die DLL kann möglicherweise nicht ordnungsgemäß neu erstellt werden, wenn Sie diesen Punkt vergessen und Ihr Compiler Sie nicht warnt. Die meisten Compiler warnen Sie jedoch, wenn die DLL von einer Anwendung verwendet wird.
  • Versuchen Sie, die DLL mit Hilfe des mit Ihrem Compiler bereitgestellten Quellcode-Debuggers auf Fehler zu untersuchen. Mit dem Debugger Ihres Compilers können Sie Haltepunkte setzen, den Programmcode schrittweise durchlaufen, die Werte der Variablen beobachten und so weiter. Die Fehlersuche mit herkömmlichen Werkzeugen kann äußerst nützlich sein. Weitere Informationen zur Fehlersuche finden Sie im entsprechenden Handbuch Ihres Compilers.
  • Eine weitere Möglichkeit zur Fehlersuche in der DLL ist das Aufrufen der DLL von einem anderen C-Programm. Wenn Sie die DLL von einem anderen C-Programm aufrufen, haben Sie die Möglichkeit, die DLL unabhängig von LabVIEW zu testen und so Probleme frühzeitig zu erkennen.
  • Wenn Sie eine LabVIEW-DLL aufrufen, die ein 2D-Array übergibt, müssen Sie zuerst die Handler-Variable deklarieren und die Variable auf NULL initialisieren, wie im folgenden C-Code dargestellt:

    Haupt

    {

    /*LabVIEW-Datenbehandlervariable für das Array */

    TD1Hd1myArray = NULL;

    ...

    /* Aufruf der LabVIEW-DLL-Funktion */

    DLLFunctionalCall(&myArray);

    ...

    }

    Wenn Sie die Handler-Variable nicht auf NULL initialisieren, wird beim Aufruf der DLL ein General Protection Fault ausgegeben.
  • Damit LabVIEW-DLL-Funktionen ohne Unterbrechung ausgeführt werden können, verzögert LabVIEW die Verarbeitung von Betriebssystemmeldungen bis zum Ende von Aufrufen von DLL-Funktionen oder bis zum Laden eines modalen Fensters aus der DLL. Das Verzögern von Betriebssystemmeldungen, wie Tastaturnachrichten von Benutzern, ist nützlich, um zu vermeiden, dass dieselbe DLL-Datei aufgerufen wird, während eine DLL-Funktion ausgeführt wird. Wenn eine DLL-Funktion also beispielsweise infolge eines Tastendrucks ausgeführt wird, sollte erst nach Ausführungsende der Funktion wieder auf ein Betätigen der Taste reagiert werden. Wenn LabVIEW die Verarbeitung von Betriebssystemmeldungen verzögert, werden alle Funktionsaufrufe derselben LabVIEW-DLL in eine Warteschlange eingereiht. Diese Warteschlange wird nach Abschluss des ursprünglichen DLL-Funktionsaufrufs ausgeführt. Ein modales Fenster ist ein Fenster, das so lange aktiv oder vor allen anderen LabVIEW-Fenstern sichtbar bleibt, bis es geschlossen oder ein anderes modales Fenster geöffnet wird. Wenn Sie ein modales Fenster von der DLL aus aufrufen, wird LabVIEW diese Prozessverzögerung ignoriert. Das heißt, Systemmeldungen zum Öffnen modaler Fenster werden ungehindert ausgeführt. Während ein modales Fenster geöffnet ist, kann kein anderes Fenster bedient werden. In LabVIEW sind die meisten Dialogfelder modale Fenster. Ein nicht modales Fenster kann nicht von einem LabVIEW-Callback-VI oder einer DLL aus geöffnet werden, während ein anderer Prozess ausgeführt wird. Wenn Ihr Callback-VI oder Ihre DLL ein nicht modales Fenster aufrufen soll, müssen Sie dies programmatisch tun, indem Sie die unter Callback-VIs beschriebenen Schritte ausführen.
  • Sie können wählen, ob Betriebssystemmeldungen in von Ihnen erstellten DDLs verzögert werden sollen. Navigieren Sie vor dem Erstellen der DLL zur Seite Fortgeschritten des Dialogfelds "Eigenschaften für DLL" und deaktivieren Sie die Option Betriebssystemmeldungen in DLL verzögern, um Betriebssystemmeldungen zu verarbeiten, während DLL-Funktionen ausgeführt werden.
  • In folgenden Situationen wird möglicherweise der Fehler Keine Anwendung oder Laufzeitbibliothek gefunden, bei der eine Fehlersuche möglich ist. angezeigt:
    • Die DLL, die auf Fehler geprüft werden soll, wurde nicht geladen oder das Laden wurde von der Anwendung rückgängig gemacht.
    • Die Konfigurationsdatei *ini der DLL, die vom Application Builder erstellt wurde, wurde nicht mit der DLL bereitgestellt.