Aufruf externer Lib dauert sehr lange

Hallo,

ich habe eine Lib: Ordner mit den VIs, Beispielen, eine .lvlib, zwei dll's und eine dir.mnu

Bisher war die Installation immer problemlos - einfach in die userlib kopiert und fertig. Bei zwei Anlagen habe ich jetzt aber das Problem, dass beim erstmaligen Aufruf einer Lib-Funktion, LV erstmal 20-30 Sekunden sucht (nach den dll's vermute ich). Weder ein Neustart von LV noch ein Mass-Compile vom Projekt haben Abhilfe geschaffen.

Wo/Wie such ich jetzt am besten das Problem?



Beste Grüße
Dimitri

Anzeige

Nach was sucht er den genau und was ist das Ergebnis der Suche? Findet er die Dateien oder sind die VIs danach gebrochen?

(03.05.2013 18:49 )Holy schrieb:  Nach was sucht er den genau und was ist das Ergebnis der Suche?

Kann ich nicht genau sagen. Es poppt kein Fenster auf. Der Mauszeiger wechselt einfach für 20-30 Sekunden zur Sanduhr. Danach startet das VI dann ganz normal und ab dann geht's auch ganz normal. Nach LV-Neustart dauert das erste Mal wieder ewig.

Zitat:Findet er die Dateien oder sind die VIs danach gebrochen?

Der findet, wonach er auch immer sucht und danach funktioniert alles wunderbar.


Ich komm nicht drauf was an den beiden Anlagen-PCs anders ist, als auf meinem Entwicklungsrechner. Auf allen anderen PC startet alles immer direkt.

Nachdem ich nen Haufen Updates installiert habe (alle Windowsupdates, Acrobat (weil PDF Toolkit), LV SP1_f2), verhält sich das ganze anders:

Es kommt jetzt immer brav ein Suchfenster und LV findet die gesuchte dll (PDF Generator.dll) auch deutlich schneller (ca. 3s). Das Problem: LV sucht in "...\Program Files (x86)\ ..." es gibt aber nur den "...\Program Files\ ...", da ein 32 bit System. Das blöde ist, und da war der NI-Support auch erstmal stutzig geworden, der erfolgreich gefundene Pfad wird nicht gespeiechert - nach jedem LV-Neustart sucht LV wieder in "...\Program Files (x86)\ ...", jeder mal.

Jetzt hab ich was von ".NET-Konfigurationsdateien" gelesen. Ich könnte mir vorstellen, dass eine explizite Angabe von dem richtigen Pfad innerhalb einer solchen Datei das Problem lösen könnte. Ich finde aber nirgends eine genaue Beschreibung wie der XML-Code einer solchen Definition aussehen könnte. Hat da jemand einen Tip?

PS: Habe zu Testzwecken den Pfad "...\Program Files (x86)\ ..." einfach mal künstlich angelegt (nur mit der .dll) und siehe da, LV hat alles sofort ohne Suchfenster gefunden. Dieser Workaround ist mir aber zu schmutzig.

PPS: Ich könnte euch das Toolkit hier hochladen, wenn die Mods nix dagegen haben. Mittlerweile kostet es Geld (SAI PDF Toolkit), aber ich hab es noch auch einer Zeit wo es umsonst war. K.A. ob das dann iO ist ...?

Ich resigniere. Der Workaround klappt irgendwie von einem Tag zum nächsten nicht mehr. Das Suchfenster poppt auch nicht auf.

Versucht habe ich:
-Mass-Compile
-den VI-Suchpfad absolut angegeben
-die .NET Assembly an allen nur denkbaren Orten abgelegt
-die .NET Konfigurationsdatei (kA ob ich die richtig geschrieben hab)

und alles in ca. 5-10-facher Ausführung.

Kennt jemand zufällig noch ein kostenloses PDF-ToolKit?

PS: hier: https://decibel.ni.com/content/docs/DOC-10952 besteht das identische Problem
und hier: http://sine.ni.com/nips/cds/view/p/lang/de/nid/209030 funktioniert alles bestens, kostet aber und da zögern wir noch ...

Eine unbefriedigende Lösung: Der Start der Applikation dauert ohnehin lang ... ok ... einfach einen Aufruf der Lib in einen der Init-Frames gelegt - fällt nicht weiter auf, aber wenn's drauf ankommt geht alles schnell. Na gut ...


Und noch etwas zum anschauen:    
Was stimmt hier nicht?


PS: Das hier: http://www.aspheute.com/artikel/20011114.htm habe ich auch ausprobiert ... das Tool funktioniert wohl - leider ohne Effekt für mein Problem.

Anzeige

Haben deine 2 Anlagenrechner evtl. eine andere LabVIEW-Version? Ich meine hier inbesondere SP-Stand bzw. Hotfix-Stand.
Sonst hast du noch die Variante den Report anders erzeugen und dann durch einen PDF-Drucker jagen.

LV 2011 neuester Stand überall ... alles was NI-Updater hergibt. Nur Win7 unterscheidet sich: Anlagen 32 bit - Rest 64 bit. Wobei der NI-Support das Problem auf einem 32 bit OS nicht nachstellen konnte. Irgendwas ist bei den Anlagen anders ...