Fehlercode 2002200

Hallo zusammen,

ich habe folgendes Problem:

Ich starte aus einer Exe heraus ein VI aus einer DLL, welches wiederum ein anderes VI aus einer anderen DLL startet.
in der fertigen EXE / DLLs bekomme ich dann den Fehler 2002200.
Wenn ich diese Starterei in der Entwicklungsumgebung mache und die jeweiligen VIs nicht aus den DLLs sondern aus meinem VI-Verzeichnis starte, dann läuft alles, wie es soll.

Hat jemand ggf. schonmal mit dem Fehler 2002200 zu tun gehabt oder gar eine Idee, was LV stören könnte?


Danke im voraus für Vorschläge

Ich benutze LV 8.0

Anzeige

Hi
Nebenbemerkung: LabVIEW 8.0 ist mit Abstand die schlechteste Version, die NI jemals veröffentlicht hat. Du solltest unbedingt auf eine neuerer Version aktualisieren. Welche ist fast egal. Alle sind besser! Dadurch erledigt sich Dein Problem ja möglicherweise von selbst.

Nur zum eigentlichen Problem:
Wenn Du VIs in DLL, zudem verschiedene, kompilierst, werden diese in verschiedenen Laufzeitumgebungen ausgeführt, die nichts miteinander zu tun haben. Z.B. kannst Du zwischen diesen VIs nicht einfach via Queue kommunizieren. Das gilt vermutlich auch für verschiedenen Referenzen etc.

Was auch immer die Gründe für das Kompilieren in verschiedene DLL anstelle des einfachen Linkens in das eine Executable sind, Du solltest diesen Ansatz überdenken.

Gruß Holger

Vielleicht irgendwas mit Sonderzeichen in VI-Namen, vgl. hier:
http://forums.ni.com/t5/LabVIEW/Error-20...-p/1148224

Gruß, Jens

Deutsche Umlaute auf 'nem arabisch-sprachigem Betriebssystem ist schon sehr außergewöhnlich.
Gruß Holger

Hallo Holger, Hallo Jens

vielen Dank erstmal für Eure Anregungen.
Ich programmiere bisher in LV 8.0, weil NI die Angewohnheit hat, dass in Nachfolgeversionen immer irgend etwas nicht mehr geht, was schonmal ging, beispielsweise zeigte sich in der 2011-er Version ein Dateidialog hinter Floating-Fenstern.( Sowas kann ich meinen Kunden nicht anbieten)
Zudem funktionierte die Abfrage, ob ein Bedienelement den Focus hat nicht mehr (Das waren nur 2 Bugs, die ich bemerkt hatte - wer weiß, was es noch so gab. Deshalb bin ich im Laufe der Jahre sehr vorsichtig mit Updates geworden und bin irgendwann von 7.1 auf 8.0 gesprungen - werden jetzt aber wohl mal auf 2012 gehen.

Die Sache, dass verschiedene DLLs in 8.0 nicht mit Queues untereinander kommunizieren könnten stimmt nicht - Meine gesamte innerhalb von 8 Jahren entstandene, recht umfangreiche Software basiert darauf, dass die DLLs untereinander über Queues und globale Variablen kommunizieren können.
Die Aufteilung in DLLs als Software-komponenten hat seinen Grund darin, dass ich, wenn ich an einem Kundenprojekt arbeite, nur diese application.dll neu erstellen muss und nicht den ganzen Kram drum herum, außerdem läge der Gesamtumfang einer EXE inzwischen bei gut 30 MB.

Nun aber zum eigentlichen Problem, dem ich ein Stück näher gekommen bin. Ich habe meine Kunden-DLL soweit reduziert, bis ich nur noch das Express-VI "Masken und Grenzwerttest" im VI hatte. Das Starten dieser DLL brachte dann 2 Mal die Fehlermeldung 2002200.
Als ich dann dafür sorgte, dass eine früher aufgerufene DLL, die dann später die Kunden-DLL aufruft schon dieses Express-VI lädt, ging es dann. - Verstanden habe ich das Ganze aber nicht!

Ein Support-Mensch von NI konnte mir bisher auch nicht sagen, wann denn dieser Fehlercode generiert wird, genausowenig wie die Homepage von NI - gibt man dort in der Suche diesen Code ein, findet er nix.
Sehr mysteriös, das ganze.

Gruß, Marko

(01.09.2012 18:06 )Trinitatis schrieb:  Die Sache, dass verschiedene DLLs in 8.0 nicht mit Queues untereinander kommunizieren könnten stimmt nicht - Meine gesamte innerhalb von 8 Jahren entstandene, recht umfangreiche Software basiert darauf, dass die DLLs untereinander über Queues und globale Variablen kommunizieren können.
Die Aufteilung in DLLs als Software-komponenten hat seinen Grund darin, dass ich, wenn ich an einem Kundenprojekt arbeite, nur diese application.dll neu erstellen muss und nicht den ganzen Kram drum herum, außerdem läge der Gesamtumfang einer EXE inzwischen bei gut 30 MB.

Sorry, ich hatte ungenau formuliert. I referenziere Queues gern mit Namen, und das geht dan schief. Wenn man die Queue-Referenz in die DLL verdrahtet funktioniert es, wie Du richtig feststellst.

Gruß Holger

Anzeige

(03.09.2012 13:49 )BNT schrieb:  Sorry, ich hatte ungenau formuliert. I referenziere Queues gern mit Namen, und das geht dan schief. Wenn man die Queue-Referenz in die DLL verdrahtet funktioniert es, wie Du richtig feststellst.

Das sollte keinen Unterschied machen. Solange die DLLs alle mit der gleichen LabVIEW Version erstellt sind und daher in der gleichen LabVIEW Runtime laufen sind Queues ob nun By Name oder By Refnum von allen DLLs zugänglich. Die einzige Einschränkung hierzu ist, dass LabVIEW 8.0 einen Bug hat der Queues und die anderen Synchronisationsobjekte Prozess global macht. Von LabVIEW 8.2 an haben sie das korrigiert so dass diese Objekte nur innerhalb eines Applikationskontextes austauschbar sind. Jedes Projekt ist ein Applikationskontext, daneben gibt es noch den Main Kontext wenn VIs ausserhalb eines Projektes ausgeführt werden, und innerhalb eines Executables ist auch ein Applikationskontext.

Das Ganze geht garantiert schief, wenn die DLLs nicht alle in der selben LabVIEW Version kompiliert sind. Dann werden sie nämlich in einer Art Out of Process Methode innerhalb eines für die jeweils der LabVIEW Version entsprechenden Runtimesystems ausgeführt und das ist für alle praktischen Gegebenheiten vergleichbar mit einer Ausführung in einem eigenen Prozess.

Hi Rolf

Vielen Dank für die Erläuterungen. Es ist doch schon recht lange her, dass ich mit Queues und Notifications in DLLs experimentiert habe.

Gruß Holger