Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Ich verweise in einem Main VI auf andere VI´s, via Methodenknoten. (Bild "Test")
Wenn ich das in der Programmierumgebung laufen lasse geht das supi. Die VI´s werden angezeigt, laufen, geben Werte aus...
Mache ich aber eine EXE, werden 3 von 4 VI´s nicht geladen, weil sie nicht lauffähig sind (Bad) das vierte läuft aber so wie erwartet. (Bilder "Error_1" und "Error_2")
Programmieren tue ich auf einem Win10 Rechner und mein Ausführungsrechner ist mit Win7.
Hat da jemand eine Idee???
06.09.2017, 13:34 (Dieser Beitrag wurde zuletzt bearbeitet: 06.09.2017 13:34 von GerdW.)
Wo genau holst du die VIs her, die da nachgeladen werden?
Ich nutze üblicherweise zwei Möglichkeiten:
1. Die nachzuladenden VIs liegen in einem Verzeichnis auf der Festplatte - mitsamt aller von ihnen benötigten subVIs.
2. Die nachzuladenden VIs befinden sich auch schon im Executable, dann sorgt der AppBuilder dafür, dass die benötigten subVIs ebenfalls in der EXE inkludiert sind.
Hallo Logosh,
zwei Sachen fallen mir spontan ein.
1. Wenn Du den Installer verwendest musst Du Kategorie -> Fortgeschritten -> Systemvorraussetzung = "Mindestens Windows7 SP1" setzten
2. Beim Compiler Kategorie -> Fortgeschritten -> den Haken bei "Fehlersuche aktivieren" entfernen.
Wo genau holst du die VIs her, die da nachgeladen werden?
Ich nutze üblicherweise zwei Möglichkeiten:
1. Die nachzuladenden VIs liegen in einem Verzeichnis auf der Festplatte - mitsamt aller von ihnen benötigten subVIs.
2. Die nachzuladenden VIs befinden sich auch schon im Executable, dann sorgt der AppBuilder dafür, dass die benötigten subVIs ebenfalls in der EXE inkludiert sind.
Hallo Gerd,
die VI´s liegen auf der Festplatte, mit den SubVI´s. Zumindest denen, die ich erstellt hab. Die die mir fehlen, sind unter Abhängigkeiten -> vi.lib zu finden gewesen.
Hab die mal aus dem Projekt entfernt, konnte kompilieren, hat aber nichts genützt.
Diese Space Constant.vi so heißt auch die Leerzeichenkonstante unter String.
Hab die nach zu ladenden VI´s auch im App Builder unter "immer enthalten"
(06.09.2017 13:39 )Freddy schrieb: Hallo Logosh,
zwei Sachen fallen mir spontan ein.
1. Wenn Du den Installer verwendest musst Du Kategorie -> Fortgeschritten -> Systemvorraussetzung = "Mindestens Windows7 SP1" setzten
2. Beim Compiler Kategorie -> Fortgeschritten -> den Haken bei "Fehlersuche aktivieren" entfernen.
Gruß
Freddy
Hallo Freddy,
Punkt 2 hat geholfen, aber umgekehrt. Harken reingemacht und dann ging es. Cool. Vielen Dank.
Find das aber trotzdem komisch.
06.09.2017, 14:35 (Dieser Beitrag wurde zuletzt bearbeitet: 06.09.2017 14:36 von GerdW.)
Zitat:Punkt 2 hat geholfen, aber umgekehrt. Harken reingemacht und dann ging es. Cool. Vielen Dank. Big Grin
Find das aber trotzdem komisch.
Durch das Aktivieren der Debuggingunterstützung werden mehr VIs in das Executable mit hineingenommen, deshalb finden die VIs ihre subVIs. (Meine Interpretation.)
Eine saubere Lösung ist das aber nicht…
Zitat:sind unter Abhängigkeiten -> vi.lib zu finden gewesen.
Eigentlich sollten alle Abhängigkeiten, auch die aus der vi.lib, in einem Executable landen - wenn die entsprechenden aufrufenden VIs auch im Executable sind.
Wenn du das VI aber von einem Pfad außerhalb der EXE nachlädst, dann weiß die RuntimeEngine nicht unbedingt, wo deine LabVIEW-IDE ihre vi.lib verwaltet und kann deshalb diese subVIs nicht finden. (Meine Interpretation der Fehlerbeschreibung.)
Wie ich oben sagte: die aufzurufenden VIs müssen mitsamt aller benötigten subVIs nachgeladen werden können!
Eine Möglichkeit dazu: das nachzuladende VI mitsamt seiner kompletten Hierarchie an einen neuen Ort speichern…
ja ganz sauber ist das echt nicht, mal geht es mal nicht. Die Frage jetzt wäre, wie kann ich den eigenständig laufende VI´s in ein Main VI einbinden? Das ist nämlich genau das was ich versuche. Notifire hab ich schon drin, auch mit Stop, aber wie bekomme ich die verlinkt? das die auch gestartet werden???
Eine Möglichkeit:
Alle VIs, die du dynamisch aufrufst, im Application Builder unter "Always Included" hinzufügen. Dann musst du aber mglw. den Aufrufpfad anpassen, den die VIs sind ja dann innerhalb der Exe mit abgelegt.
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Bei dynamisch geladenen VIs nutze ich immer den relativen Pfad ab dem ApplicationDir. In der Entwicklungsumgebung ist das AppDir der Ordner der Projektes und in der RTE die Exe selber.
Hast Du im Projekt alle VIs von der Verpfadung unterhalb des Projektes liegen geht das so.
Ein weiterer Kandidat für fehlende SubVIs ist die Option ungenutzte polymorphe Instanzen von VIs zu entfernen. Das hat mich mal nen halben Tag gekostet und knall in folgender Konstellation:
- Das polymorphe Vi ist innerhalb einer Lib (Klasse würde auch gehen) ein public member.
- Alle Instanzen von diesem sind private.
- Jemand von außerhalb der Lib ruft das polymorphe public VI auf.
- In der DevEnv funktioniert das wunderbar.
- Hast Du in der BuildSpec unter Additional Exclusions den Haken bei Remove unused polymorphic VI instances gesetzt, so werden nicht etwas, wie man bei dem Namen denken könnte, alle unbenutzten Instanzen (in dem Szenario private VIs) dem Kompilat nicht hinzugefügt, sondern auch das public VI. Die Caller des Public VI werden dann direkt an die jeweilige Instanz verwiesen und versuchen dann auf private Member der Lib/Klasse zuzugreifen.
Warum LabVIEW das so macht, ist mir nicht klar aber es ist fies da unerwaret.
(11.09.2017 15:16 )Logosh schrieb: ... Die Frage jetzt wäre, wie kann ich den eigenständig laufende VI´s in ein Main VI einbinden? ...
Also ich mache das immer so, dass ich die Sub-VIs im Main in eine Casestruktur lege, die auf FALSE steht, so dass diese VIs geladen aber nicht ausgeführt werden. Man darf an diese Casestruktur nur keine FALSE-Konstante anschließen, weil der APPB sie dann nicht einbindet, weil er ja schlau ist.
Man muss also ein BOOL-CTRL nehmen, das auf dem Panel nicht erreicht werden kann.
Wenn du dieses Sub-VI dann irgendwo mit dem Aufruf über "open VI-Reference" aufrufst, dann darf nicht der VI-Pfad, sondern nur der VI-Name angegeben werden.
(s. Hilfe: "VI-Pfad kann entweder der Name des VIs oder der vollständige Pfad des VIs sein. Wenn Sie das VI anhand seines Namens angeben, muss dieser mit dem vollständigen Namen des VIs im Speicher auf dem ausgewählten Rechner übereinstimmen. Bei Pfadangaben wird im Arbeitsspeicher nach einem VI gesucht, das vorher von diesem Pfad geladen wurde. Wenn kein VI im Speicher gefunden wird, versucht LabVIEW, das VI von der Festplatte zu laden. Bei Fehlen des VIs oder bei Konflikten mit anderen VIs im Speicher wird eine Fehlermeldung ausgegeben")
Die Sub-VIs dieses VIs werden automatisch mit in die EXE eingebunden.
Gruß, Marko
07.07.2019, 08:37 (Dieser Beitrag wurde zuletzt bearbeitet: 07.07.2019 08:38 von achim @ FZK.)
(11.09.2017 15:16 )Logosh schrieb: ... Die Frage jetzt wäre, wie kann ich den eigenständig laufende VI´s in ein Main VI einbinden? ...
Also ich mache das immer so, dass ich die Sub-VIs im Main in eine Casestruktur lege, die auf FALSE steht, so dass diese VIs geladen aber nicht ausgeführt werden. Man darf an diese Casestruktur nur keine FALSE-Konstante anschließen, weil der APPB sie dann nicht einbindet, weil er ja schlau ist.
Man muss also ein BOOL-CTRL nehmen, das auf dem Panel nicht erreicht werden kann.
Also ein Control und eine CaseStruktur zu verwenden um dynamisch geladene VIs
in die Exe zu zwingen klingt mehr als schräg! Mag gehen, ist aber kein guter Stil.
Normalerweise macht man das über die BuildSpec. Ich glaube unter sourcen, gibt man das zu startende VI an und unten dran gibt es eine Liste "always included". Da gehören die VIs und übrigens alles andere auch (DLL, XMLs oder was man sonst noch so verarbeitet) rein.
