09.04.2010, 11:43
Hallo LVF,
das dürfte was für die Fortgeschrittenen sein...
Folgende Ausgangssituation:
Ich habe ein etwas umfangreicheres Programm, mit dem von einem Framegrabber (bis zu acht Videokanäle in Verwendung) zyklisch Daten ausgelesen und dargestellt werden. Die erfassten Daten werden nach einer Umrechnung (2D-U8 -> LV picture) kontinuierlich auf dem Frontpanel dargestellt. Im Hintergrund werden die einzelnen 2D-Arrays (= Frames) in eine AVI-Datei geschrieben. Die Zykluszeiten (n Sekunden AVI-Aufnahme mal m Kameras, Wiederholung alle t Sekunden) variieren dabei je nach Prüfvorgabe der angeschlossenen Kameras. Es handelt sich dabei um Langzeitversuche die bis zu drei Monate dauern, das ganze läuft auf bis zu 5 Rechnern.
Problem:
Leider läuft aus irgendeinem Grund der Arbeitsspeicher voll...Was teilweise soweit ging, das sich der Rechner aufgrund von Arbeitsspeicher-Mangel ins Nirvana verabschiedet hat. Ich hab zuerst an ständig neu erzeugte Handles oder aufwändige Array-Operationen gedacht, aber in der Richtung wurde alles optimiert. Offenbar bleiben Speicherbereiche für die Bilddarstellung allokiert...Irgendwann haben wir dann festgestellt, dass der Arbeitsspeicher wieder freigegeben wird, wenn das Fenster per Mausklick (rechts oben) einmal kurz minimiert wird. Da sinkt dann der Speicherverbrauch von z.B. (über mehrere Tage aufgebauten) 350 MB auf ca. 50 MB...das variiert je nach Rechner.
Diese Tatsache konnten wir nachvollziehen:
http://digital.ni.com/public.nsf/allkb/9EA...625763300434D4D
Also haben wir uns folgenden Workaround ausgedacht: Wir minimieren programmatisch einmal kurz das Fenster (nachts um 0.xx Uhr, da ist sowieso keiner da) und sind damit aus dem Schneider. Leider funktioniert das ganze nicht mit den VI-Server-Funktionen (FP.State = Minimized bzw. Standard), da tut sich am Speicher gar nichts...
Ich hab mich dann an folgendes erinnert:
http://zone.ni.com/devzone/cda/epd/p/id/4935
Das hab ich vor X Jahren schon verwendet, als das per VI Server noch nicht möglich war.
Mit diesen Funktionen aus der User32.dll funktioniert das minimieren tadellos, siehe das angehängte
-Projekt im Zip-File!
[attachment=25640]
Wenn man allerdings eine Exe baut (ebenfalls im Zip-File enthalten), bekommt man nach dem Beenden des Programms vom Dr. Watson eine Fehlermeldung präsentiert:
[attachment=25639]
Auf einem anderen Rechner haben wir Visual Studio 2008 installiert, da wird der JIT-Debugger aktiv. Wenn man den deaktiviert, kommt die Warnung, dass man keinen Debugger aktiviert hat.
Ich hab schon sehr viel gegoogelt, z.B. hier und diverse Registry-Einträge probiert, aber das hat alles nichts gebracht. Auch das Löschen des Window-Handles mit der User32.dll-Funktion "DestroyWindow" hat nichts gebracht.
Hat jemand eine Idee? Früher gabs keine Probleme in dieser Richtung...zumindest hab ich keine bemerkt! Wir könnten für unsere Tests zwar mit der Fehlermeldung leben, schön ist aber was anderes...
Ich bin für Lösungsvorschläge dankbar!
Gruß
Achim
das dürfte was für die Fortgeschrittenen sein...
Folgende Ausgangssituation:
Ich habe ein etwas umfangreicheres Programm, mit dem von einem Framegrabber (bis zu acht Videokanäle in Verwendung) zyklisch Daten ausgelesen und dargestellt werden. Die erfassten Daten werden nach einer Umrechnung (2D-U8 -> LV picture) kontinuierlich auf dem Frontpanel dargestellt. Im Hintergrund werden die einzelnen 2D-Arrays (= Frames) in eine AVI-Datei geschrieben. Die Zykluszeiten (n Sekunden AVI-Aufnahme mal m Kameras, Wiederholung alle t Sekunden) variieren dabei je nach Prüfvorgabe der angeschlossenen Kameras. Es handelt sich dabei um Langzeitversuche die bis zu drei Monate dauern, das ganze läuft auf bis zu 5 Rechnern.
Problem:
Leider läuft aus irgendeinem Grund der Arbeitsspeicher voll...Was teilweise soweit ging, das sich der Rechner aufgrund von Arbeitsspeicher-Mangel ins Nirvana verabschiedet hat. Ich hab zuerst an ständig neu erzeugte Handles oder aufwändige Array-Operationen gedacht, aber in der Richtung wurde alles optimiert. Offenbar bleiben Speicherbereiche für die Bilddarstellung allokiert...Irgendwann haben wir dann festgestellt, dass der Arbeitsspeicher wieder freigegeben wird, wenn das Fenster per Mausklick (rechts oben) einmal kurz minimiert wird. Da sinkt dann der Speicherverbrauch von z.B. (über mehrere Tage aufgebauten) 350 MB auf ca. 50 MB...das variiert je nach Rechner.
Diese Tatsache konnten wir nachvollziehen:
http://digital.ni.com/public.nsf/allkb/9EA...625763300434D4D
Also haben wir uns folgenden Workaround ausgedacht: Wir minimieren programmatisch einmal kurz das Fenster (nachts um 0.xx Uhr, da ist sowieso keiner da) und sind damit aus dem Schneider. Leider funktioniert das ganze nicht mit den VI-Server-Funktionen (FP.State = Minimized bzw. Standard), da tut sich am Speicher gar nichts...
Ich hab mich dann an folgendes erinnert:
http://zone.ni.com/devzone/cda/epd/p/id/4935
Das hab ich vor X Jahren schon verwendet, als das per VI Server noch nicht möglich war.
Mit diesen Funktionen aus der User32.dll funktioniert das minimieren tadellos, siehe das angehängte
-Projekt im Zip-File![attachment=25640]
Wenn man allerdings eine Exe baut (ebenfalls im Zip-File enthalten), bekommt man nach dem Beenden des Programms vom Dr. Watson eine Fehlermeldung präsentiert:
[attachment=25639]
Auf einem anderen Rechner haben wir Visual Studio 2008 installiert, da wird der JIT-Debugger aktiv. Wenn man den deaktiviert, kommt die Warnung, dass man keinen Debugger aktiviert hat.
Ich hab schon sehr viel gegoogelt, z.B. hier und diverse Registry-Einträge probiert, aber das hat alles nichts gebracht. Auch das Löschen des Window-Handles mit der User32.dll-Funktion "DestroyWindow" hat nichts gebracht.
Hat jemand eine Idee? Früher gabs keine Probleme in dieser Richtung...zumindest hab ich keine bemerkt! Wir könnten für unsere Tests zwar mit der Fehlermeldung leben, schön ist aber was anderes...
Ich bin für Lösungsvorschläge dankbar!
Gruß
Achim
gibts denn noch.
