DAQmx Control Task.v LabView-Ladefehlercode 3: Frontpanel konnte nicht geladen werden

Hallo liebe LabView Spezies,
ich habe aktuell auf einem Prüfstand ein sehr seltsames Verhalten und komme einfach nicht weiter trotz Recherche hier im Forum und im Netz.
Auf dem Rechner ist die LV Runtime 2016 installiert. Gestern habe ich eine Änderung an meinem LV Programm gemacht (mit LV2016), die exe erstellt und auf den Rechner kopiert.

Führe ich die exe aus, erscheint die Meldung:
LabView: Ressource nicht gefunden.
Beim Laden des VIs 'DAQmx Control Task.vi' ist ein Fehler aufgetreten.
LabView-Ladefehlercode 3: Frontpanek konnte nicht geöffnet werden.

Führe ich die bisherige exe aus, lädt das Programm problemlos. Geändert habe ich allerdings nur einige wenige Nuimerische Ausgabefelder, nichts an den Tasks o.Ö.
GerdW schrieb in einem anderen Thread, DAQmx würde fehlen...das ist aber auf dem Rechner installiert.

Hat Jemand eine Idee wieso die exe plötzlich nicht mehr starten will? Das 'DAQmx Control Task.vi' hat außerdem doch gar kein Frontpanel...

Hat vielleicht Jemand eine Idee?

Anzeige

Hallo Flug,

Zitat:LabView-Ladefehlercode 3: Frontpanek konnte nicht geöffnet werden.
Das 'DAQmx Control Task.vi' hat außerdem doch gar kein Frontpanel...

Dann passt die Fehlermeldung doch exakt…

Zitat:LabView: Ressource nicht gefunden.
eine Idee wieso die exe plötzlich nicht mehr starten will?

Es fehlt eine Resource, die in diesem subVI benötigt wird.
Es wäre vielleicht hilfreich, dieses subVI hier mal anzuhängen…

Hallo Gerd,
du bist echt immer zur Stelle wenn es Fragen gibt... ich glaube fast du BIST das Forum

Meinst du das subVI in dem die Tasks liegen? Das hänge ich hier gerne mal an, auch wenn es echt dreckig "programmiert" ist (Vielleicht ein gutes Negativbeispiel? *kicher*). In diesem VI habe ich auch die Änderung gemacht.

Welche Version DAQmx hast du auf DEINEM Rechner installiert - also auf dem, auf dem du die neue Exe erstellt hast?

Aus eigener (leidvoller) Erfahrung: Es scheint eine Inkompatibilität ab DAQmx 17 zu exisiteren, eine gegen diesen Treiber erstellte Exe läuft nicht auf Zielrechnern, auf denen nicht mindestens DAQmx 17 installiert ist.

Gruß, Jens

hallo jg,
auf dem Entwickler PC scheint der Treiber 19.0 installeirt zu sein (siehe Screenshot). Auf dem Entwickler PC habe ich auch neuere LabView Versionen ausprobiert.

Kann ich auf dem PC auf dem nur die RTE läuft ein aktuelles DAQmx (19?) installieren.
Sorry für meine Unbedarftheit beim Thema DAQmx, Versionen usw...

Hallo Flug,

Zitat:Meinst du das subVI in dem die Tasks liegen?

Ich meine das VI, welches in deiner Fehlermeldung genannt wird: "Beim Laden des VIs 'DAQmx Control Task.vi' ist ein Fehler aufgetreten."

Zitat:Vielleicht ein gutes Negativbeispiel?

Ja, da könntest du recht haben.
So viele lokale und globale Variablen in nur einem VI habe ich schon lange nicht mehr gesehen! Selbst die Statemachines werden über Zugriffe auf lokale Variablen gesteuert…

Anzeige

(17.10.2019 14:41 )RabenFlug schrieb:  Kann ich auf dem PC auf dem nur die RTE läuft ein aktuelles DAQmx (19?) installieren.

Ja, kannst du.

Gruß, Jens

(17.10.2019 14:59 )GerdW schrieb:  

Zitat:Vielleicht ein gutes Negativbeispiel?

Ja, da könntest du recht haben.
So viele lokale und globale Variablen in nur einem VI habe ich schon lange nicht mehr gesehen! Selbst die Statemachines werden über Zugriffe auf lokale Variablen gesteuert…

Dieses VI ist wirklich äußerst unschön, schuldig im Sinne der Anklage! Es ist noch aus 2012 und tut was es soll, daher lasse ich das erst mal so. Never touch a running system...

(17.10.2019 14:32 )jg schrieb:  ..., eine gegen diesen Treiber erstellte Exe...

Kann ich irgendwie beeinflussen gegen welchen Treiber die EXE erstellt wird? In den Build Optionen habe ich nichts gefunden. Wird immer der "letzte" Treiber verwendet?
Oder müsste ich die aktuelleren Treiber (19) wieder deinstallieren um überall einen einheitlichen Treiberstand zu haben?

Das Aktuelle Treiberpaket hat unfassbare 12,7GB!!! In Worten, Zwölf komma sieben Gigabyte! Solche Datenmengen lassen sich (bei uns) nicht ohne weiteres im Täglichen Betrieb handeln. Ich verstehe sowieso nicht, weshalb bei LabView alle Pakete so riesig sind? Dagegen ist die Runtime Environment (2016) mit ~300MB ja noch winzig. Beispiel: NIDAQ16: 2GB.
Aber okay, wenn das "nötig" ist

Hallo Rabe,

Zitat:Kann ich irgendwie beeinflussen gegen welchen Treiber die EXE erstellt wird? In den Build Optionen habe ich nichts gefunden. Wird immer der "letzte" Treiber verwendet?
Oder müsste ich die aktuelleren Treiber (19) wieder deinstallieren um überall einen einheitlichen Treiberstand zu haben?

Es wird der aktuell installierte DAQmx-Treiber verwendet. Den kann es nämlich nur in einer Version auf dem Rechner geben…

Zitat:Das Aktuelle Treiberpaket hat unfassbare 12,7GB!!! In Worten, Zwölf komma sieben Gigabyte! Solche Datenmengen lassen sich (bei uns) nicht ohne weiteres im Täglichen Betrieb handeln. Ich verstehe sowieso nicht, weshalb bei LabView alle Pakete so riesig sind? Dagegen ist die Runtime Environment (2016) mit ~300MB ja noch winzig. Beispiel: NIDAQ16: 2GB.
Aber okay, wenn das "nötig" ist

1. Schau dir mal an, wieviel Hardware mit diesen knapp 13GB unterstützt wird… (Außerdem dürfte das evtl. mehr sein als nur DAQmx.)
2. Die muss man ja nicht aus dem Internet runterziehen. Ich lasse mir mit jeder neuen Version immer einen USB-Stick schicken: da hat man alles drauf, wofür man bezahlt hat! Und wenn man dann nur die Software vom USB-Stick verwendet, gibt es nie Probleme mit unterschiedlichen Treiberversionen. Zum Installieren heißt es dann nur: USB-Stick lokal auf die Festplatte des PCs kopieren (immer hilfreich, wenn der AppBuilder hinterher nach Installationspaketen sucht), mit Admin-Account anmelden, LabVIEW wie gewünscht installieren…

(21.10.2019 09:15 )RabenFlug schrieb:  Kann ich irgendwie beeinflussen gegen welchen Treiber die EXE erstellt wird? In den Build Optionen habe ich nichts gefunden. Wird immer der "letzte" Treiber verwendet?
Oder müsste ich die aktuelleren Treiber (19) wieder deinstallieren um überall einen einheitlichen Treiberstand zu haben?

Nein, du hast immer nur 1 DAQmx-Version mit Entwicklngs-VIs aktiv. Wenn NI jetzt was ändert in einer Version, was nicht mehr zur Vorgänger-Version passt, dann kommt es zu dem Effekt, dass die Exe auf einem anderen System mit anderer DAQmx-Version nicht mehr lauffähig ist.

(21.10.2019 09:15 )RabenFlug schrieb:  Das Aktuelle Treiberpaket hat unfassbare 12,7GB!!! In Worten, Zwölf komma sieben Gigabyte! Solche Datenmengen lassen sich (bei uns) nicht ohne weiteres im Täglichen Betrieb handeln. Ich verstehe sowieso nicht, weshalb bei LabView alle Pakete so riesig sind? Dagegen ist die Runtime Environment (2016) mit ~300MB ja noch winzig. Beispiel: NIDAQ16: 2GB.
Aber okay, wenn das "nötig" ist

DAQmx 19 in der Vollversion (inkl. API Unterstützung) ist 3.4 GB groß:
https://www.ni.com/de-de/support/downloa...tml#301173

Alternative: Du erstellst auf deinem Rechner einen Installer, und dort bindest du DAQmx in der Runtime-Version ein.

Leider hat NI den Einzel-Download für die Runtime-Version von DAQmx mit Version 19 eingestellt - darüber kannst du dich gleich mal selber bei NI beschweren...

https://knowledge.ni.com/KnowledgeArticl...AA&l=de-DE

Gruß, Jens

EDIT: Gut möglich, dass es langt, eine DAQmx Runtime 17-Version auf deinem Zielrechner zu installieren. Wie schon geschrieben, der Bruch kam aus eigener Erfahrung zwischen DAQmx 16 und DAQmx 17.