' schrieb:Hierzu würde ich auf jeden Fall raten. Besonders, wenn du die deutsche Version hast.
Noch einige Bemerkungen.
Eine Anzahl von 38 VI's halte ich für wenig. Hier dürfte das allergeringste Problem liegen. 1.8MB ist zwar groß für ein VI, zu groß für den Styleguide, aber kein Problem für LV (hier ginge sogar 12MB). Ein "Zeitproblem", das es in LV gibt, ist das Schließen der Eigenschaftsmaske von Charts. Das kann schon mal 10 Sekunden dauern - führt aber nie zum Absturz.
Desweiteren tippe ich vorerst auch auf die üblichen Verdächtigen, die von Archimedes bereits genannt wurden.
12MB VIs kann ich nicht empfehlen. Habe mal ein Projekt geerbt von jemandem der so ein VI geschrieben hatte. Hunderte von Sequenzen, noch mehr lokale und globale Variablen, und Drähte die dreimal ums Haus gingen bis sie endlich irgenwo angebunden waren. Jede kleinste Edit-Operation dauerte mehrere Sekunden.
Eine komplette Überarbeitung des VIs, mit Auslagerung der verschiedenen Modi in SubVIs, Umwandlung der Sequenzen in Zustandsmaschinen mit Schieberegisteren sowie Auslagerung von Zustandsinformation in sogenannte LV2Style intelligente Globals, um die unsinningen lokalen Variablen zu vermeiden und aufräumen der Drähte um unnötige Knicke und Umwege zu vermeiden brachte das ganze runter auf vier HauptVIs von je etwa 1MB plus noch eine grössere Zahl von subVIs und das Verschieben einer Funktion oder Drahtes dauerte nicht mehr Sekunden sondern war endlich wieder sofort.
Aber persönlich finde ich 1MB wirklich die Obergrenze für VIs. Selbst meine meist komplizierten User Interfaces schaffen das normal nicht aber dafür verwende ich auch sehr oft und sehr schnell SubVIs um Funktionen zu kapseln und haben typische Projekte meist um die 700 oder mehr VIs. SubVIs scheint oft extra Arbeit (wegen der Connector-Pane, Icon, usw) aber das zahlt sich auf die Dauer immer aus wenn man eine grössere Applikation schreibt (und bei kleineren auch da mit dem Essen oft der Appetit kommt und die Applikation plötzlich doch noch 5 neue Features haben muss und damit eben nicht mehr klein bleibt.
Das ursprüngliche Problem sieht mir aber irgendwie nach korrumpierten VIs aus. Sehe ich selber nicht sehr oft aber es scheint Leute zu geben die damit regelmässig geplagt werden. Persönlich könnte ich mir vorstellen dass schlechter Speicher langsam Fehler in Vis verursachen kann die zwar nicht sofort fatal werden aber die Struktur doch soweit stören, dass das mit der Zeit zu Fehlern führt. Eine andere meist vernachlässigte Möglichkeit ist die Verwendung von Aufrufknoten die entweder nicht ganz korrekt konfiguriert sind oder Fehler in den externen Komponenten die durch diese Knoten aufgerufen werden. So eine DLL kann in den gesamten LabVIEW Speicher schreiben und subtile Probleme verursachen, die manchmal erst nach Stunden oder Tagen auftreten oder auch erst wenn man LabVIEW abschliesst und es über korrumpierte Speicherbereiche stolpert, wenn es alle seine angeforderten Speicherbereiche ordentlich ans Betriebssystem zurückgeben will.
Rolf Kalbermatter
