Resourcen-Problem bei LV 8.2???

Hallo zusammen

Bin momentan an einem grösseren Prüfsystem entwickeln.
Das Prüfsystem soll unter LV 8.2 laufen.

Folgendes Problem ist nun aufgetaucht:
Ich bin jetzt beim Testing angekommen.
Teste die einzelnen Module und die ganze LV-SW auf dem
Prüfsystem. Das Projekt beinhaltet nun schon 38 VI's!
Das aufwendigste VI hat nun eine grösse von 1.8MB.
Eigentlich überhaupt nicht gross, jedoch bekomme ich nun Resourcen-Probleme!

Wenn ich im aufwendigsten VI selber etwas kleines abändern will, hat er für diese Änderung mindestens 20sekunden.
Während er diese Änderung vollzieht, darf ich nicht anderes auf dem PC machen!
Noch schlimmer ist das Abspeichern und Schliessen von dem geändertem VI!
Für dies hat er 1 Minute! Während diesem Prozess darf ich gar nichts anderes auf dem System machen, sonst
stürtzt das LV ab!

Jetzt die Frage:
Ist dies ein bekanntes Problem?
Könnt Ihr mir hierbei helfen?
Würde es ev. etwas nützen wenn ich das Update LV 8.2.1 installiere und das Projekt auf
diese Version Migriere?

Ich bin froh wenn sich darüber jemand äussern kann!
Denn in der Testphase ist dieses Problem extrem nervig!

Besten Dank an Euch und Grüsse

MWS

Hallo,
was für einen PC hast du denn?
CPU?
RAM?
Betriebssystem?

Liegen deine VIs auf dem Rechner lokal oder auf nem Server?
Was für ein Antivierenprogramm läuft?
Was läuft sonst noch?

Grüße
Achimedes

' schrieb:Würde es ev. etwas nützen wenn ich das Update LV 8.2.1 installiere und das Projekt auf
diese Version Migriere?

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.

' schrieb:Hallo,
was für einen PC hast du denn?
CPU?
RAM?
Betriebssystem?

Liegen deine VIs auf dem Rechner lokal oder auf nem Server?
Was für ein Antivierenprogramm läuft?
Was läuft sonst noch?

Grüße
Achimedes

PC: Dell OptiPlex
CPU: 2.8GHz
RAM: 512MB
Betriebssystem: Windows XP Professional

Meine VIs liegen auf diesem Prüfsystem nicht auf einem Server, sondern normal auf einer
lokalen Festplatte. Nebenbei läuft kein Antivirenprogramm, da sich der PC nicht am Netz befindet.

Hatte das Problem zuerst auf meinem Entwicklungssystem.
Dieses ist auf meinern PC, welcher am Firmennetzwerk ist und noch vieles nebenbei läuft.
Da dacht ich das dies ev. das Problem sein könnte.
Doch später habe ich dieses Problem auch auf dem PC der Prüfsystems festgestellt!
Daher wende ich mich jetzt nun an Euch!

Meint Ihr ich solle auf LV 8.2.1 migrieren?
Wäre das sinnvoll?

Grüsse
MWS

Erstens:
Der Rechner ist ausreichend. Was sagt denn der Speicherbedarf und die Prozessorauslastung während des Fehlers?

Zweitens:
Ich will doch noch von dem einen Problem, das wir unter LV7 gelegentlich hatten, erzählen. Sofern mir die Einzelheiten noch einfallen. Problem war, dass ein VI - meistens auch der Größe 1 bis 5 MB - aus nicht nachvollziehbaren Gründen plötzlich nicht mehr speichern ging. Oft kam eine dieser "Insane object"-Meldungen, manchmal auch nicht. Manchmal hat sich LV ohne jeden Kommentar, ob von LV oder BS, geschlossen. Das Programm selbst hat aber fehlerfrei funktioniert. Lösen lies sich dieses Problem immer wie folgt: Ein bestimmtes Propertynode löschen, alle Wires, die dran hingen, entfernen, neuen Knoten erstellen, neu verbinden - und gut war wieder.

' 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

Anzeige

Gut das werde ich sowieso noch mache beim Optimieren!
Ich werde verschiedene Routinen in Sub-Vis zerlegen!
Jedoch habe ich nicht viele lokale Variablen!

Problem besteht auch, dass dies nach geraumer Zeit aufgetreten ist.
Dch da ist das VI auch schon so gross gewesen!

Schlägst du mir somit vor ich solle das ganze in Sub-Vis zerlegen!
So dass ich im VI selbt nicht mehr viel Code habe sondern alles in Sub-Vis zerlegen konnte?

Cheeerzs
MWS

' schrieb:Gut das werde ich sowieso noch mache beim Optimieren!
Ich werde verschiedene Routinen in Sub-Vis zerlegen!
Jedoch habe ich nicht viele lokale Variablen!

Problem besteht auch, dass dies nach geraumer Zeit aufgetreten ist.
Dch da ist das VI auch schon so gross gewesen!

Schlägst du mir somit vor ich solle das ganze in Sub-Vis zerlegen!
So dass ich im VI selbt nicht mehr viel Code habe sondern alles in Sub-Vis zerlegen konnte?

Also sinnlos SubVIs machen hat da sicher auch keinen Sinn. Aber die Struktur überschauen und sehen wo Du eventuel einfach und gut Code in SubVIs verschieben kannst kann nie schaden. Und dann bitte nicht nur einfach "Create SubVI from Code Selection" benützen. Kann zwar hilfreich sein um das als Start zu gebrauchen aber das entsprechende SubVI MUSS danach editiert werden und eine sinnvolle Connector-Pane als auch ein überarbeitetes Diagramm erhalten. Sonst ist der ganze Codewust im HauptVI noch allemal besser!

Noch eine Idee: Verwendest Du zufällig Shared Variablen in Deinem VI und arbeitest mit Projekten? Da ist ein bekanntes Problem in LabVIEW 8.2 damit wenn man VIs aus einem Projekt öffnet, wenn dieses VI Gebrauch macht von Shared Variablen. Edit-Funktionen werden proportional mit der Anzahl Shared-Variablen in dem VI langsamer. NI arbeitet daran kann aber noch nicht sagen ob es in der nächsten Version von LabVIEW schon behoben ist.

Workarounds:
1) Viele Shared Variablen in ein Array zusammenfassen um die Anzahl zu minimalisieren.
2) Alle oder zumindest die meisten Shared Variablen in ein separates SubVI ausslagern um es so vom Diagram des Haupt-VIs zu entkoppeln.

Rolf Kalbermatter