LabVIEW Entiwicklungsumgebung langsam!

Hallo Leute,

ich habe seit einigen Tagen das Problem, dass meine Entwicklungsumgebung von Labview in einem HaupVI abartig langsam ist.
Es handelt sich dabei um das HauptVi meiner Applikation an dem ich schon länger arbeite. Das Problem trat für mich scheinbar ohne Grund auf. Wenn ich nur eine Leitung in diesem VI lösche ist ein Kern des Rechners vollkommen ausgelastet und benötigt ca. 10sec um die Änderung vorzunehmen.

Zuerst dachte ich es liegt daran, dass ich mein LVWorkspace auf einem Netzlaufwerk untergebracht ist. Allerdings tritt das gleiche Problem auch bei lokaler Speicherung auf. Wenn ich andere VIs bearbeite geht das, wie zuvor auch beim HauptVI, schnell und quasi ohne verzögerung.

Hatte Jemand schonmal ein ähnliches Problem oder einen Rat für mich?

Danke schonmal!

Anzeige

Wie groß ist denn dein Main-VI?
Wenn das BD "zu viel" Code enthält, oder wenn das Frontpanel "zu kompliziert" wird (z.B. mehrere Tab-Controls ineinander verschachtelt etc. etc.), dann kann die Bearbeitung schon mal deutlich lahmen.

Gruß, Jens

Hallo,

Das MainVI hat schon eine beträchtliche Größe, Allerdings war die Bearbeitung bis eben vor kurzem ohne nennenswerten zeitlichen Versatz möglich! Meiner Meinung nach muss es eine andere Ursache haben, warum die Endwicklungsumgebung genau in diesem VI so lahmt.

Im Blockdiagramm sind einige paralelle Schleifen die das UserInterface mit mehreren Events verarbeiten und eine sekündliche Messwertaktualisierung in einer Whileschleife.
Ausserdem ist es möglich einige SubVIs per Referenz aufzurufen.

Wie gesagt bis neulich konnte ich im HauptVI uneingeschränkt ändern, kopiern etc..

Danke für die zügige Antwort!

PS: Hab grad geschaut wie lange sich die Verzögerungen hinziehen! das Löschen einer wirklich trivialen Verbindung (kein Array oder sowas) dauert ca. 20 Sekunden! Wenn das ein schleichender Prozess mit Wachstum des VIs gewesen wäre hätte ich das ja gemerkt *durchdreh*

Hallo Bart,

hast du vielleicht große Datenmengen als Defaultwert in irgendwelchen Graphen eingestellt?

Was sagen die VI-Infos zum benötigten Speicher des VIs (Ctrl-I -> "Speicherauslastung")?

Ich habe in ähnlichen Fällen feißig die Deaktivierungstruktur benutzt und so lange Code ausgeblendet, bis der Fehler weg war. Allerdings hatte ich die Probleme bei laufendem Programm. Ob das in der reinen Entwicklungsumgebung ohne Start eines Programms auch funktioniert, sei dahingestellt. Das Gleiche frage ich mich auch bei dem Vorschlag von Gerd.

Hallo Ludwig,

Zitat:Das Gleiche frage ich mich auch bei dem Vorschlag von Gerd.

Pack mal 100MB Defaultdaten in einen Graph und fange dann an, das VI zu editieren/speichern...

    Hallo Leute und vielen Dank für Eure Hilfe,

Ich habe mal die Speicherauslastung von dem HauptVI angeschaut. Was sagt Ihr dazu?

(17.05.2013 12:51 )GerdW schrieb:  

Zitat:Das Gleiche frage ich mich auch bei dem Vorschlag von Gerd.

Pack mal 100MB Defaultdaten in einen Graph und fange dann an, das VI zu editieren/speichern...

Habe übersehen, dass Du zwei verschiedene Vorschläge gemacht hattest. Ich meinte die Anzeige der Speicherauslastung, und die Frage war, ob diese außer für laufende oder gelaufene VIs auch für die gewissermassen rein "stationäre" Entwicklungsumgebung hilfreiche Ergebnisse liefert.

Hallo Bart,
3MB Blockdiagrammobjekte? Was hast du denn da so angesammelt?
Ich habe bei einem meiner größten VIs gerade mal 800kB an dieser Stelle stehen - und das ist auch schon (ungünstigerweise) 4 FullHD-Bildschirme groß...

Das würde ich so als "Bremse" identifizieren: Bei Änderungen am VI muss neu kompiliert werden - üblicherweise sofort bei jeder Änderung, die über ein Verschieben von Drähten hinausgeht. Und je mehr Blockdiagrammobjekte, desto länger wird kompiliert...

Hallo,
eventuell kommen auch die "beliebten" Express Vis in Betracht.
Bis LV 8.5 haben die TDM-Express Vis extrem verlangsamt, danach die LV-Versionen kann ich nicht beurteilen, weil ich die TDM-EX
nicht mehr benutzt habe.
Vielleicht spielen auch die Undo-Steps pro Vi eine Rolle. Dies ist ja leicht zu testen.

Gruß
Ralf