Beispielprojekt "Kontinuierliche messung und Protokollierung" füllt Arbeitsspeicher

Hi,

Ich hab die letzte Tage versucht ein Messprogramm zu schreiben, mit dem ich Schwinungen nach DIN 45669-1 Messen kann. Dazu habe ich das Besipielprojekt "Kontinuierliche Messung und Protokollierung" als Vorlage verwendet. Jetzt habe ich jedoch festgestellt, dass dieses Beispielprgramm eine Bestimmte Anzahl an Sampel-Paketen in irgend einenen Puffer zu schreiben scheint.
Mein Problem ist nun, dass ich große Sampelpakete brauche um vernünftige Ffts machen zu können und dann das Beispielprojekt meinen Abreitsspeicher füllt.
Wenn man dem Sinunsgenerator in dem Beispielprojekt einen Samplerate von 102400 und eine Sample-Anzahl (pro Block) von 204800 vorgibt dann kann man richtig zuschauen wie sich der Arbeitsspeicher füllt solang bis Windows dem ganzen einen Grenze setzt.
Kann mir jemand sagen wo diese ganzen Werte landen? Es scheint ja irgendwo Speicherplatz reserviert zu werden der nicht mehr freigegeben wird, aber ich kann mir nicht erklären wo. Wenn ich die Queques überprüfe enthalten alle maximal einen Wert.
Ich hoffe euch fällt etwas ein.

mit freundlichen Grüßen
und einen schönen Tag!!

Julian

Anzeige

(11.02.2013 11:08 )JulianS. schrieb:  Ich hab die letzte Tage versucht ein Messprogramm zu schreiben, mit dem ich Schwinungen nach DIN 45669-1 Messen kann. Dazu habe ich das Besipielprojekt "Kontinuierliche Messung und Protokollierung" als Vorlage verwendet. Jetzt habe ich jedoch festgestellt, dass dieses Beispielprgramm eine Bestimmte Anzahl an Sampel-Paketen in irgend einenen Puffer zu schreiben scheint.

Wenn Du nichts daran geändert hast, werden die Daten in eine TDMS Datei geschrieben. Schau mal in Deinem
Standard-Ordner für LabView. Da sollten Dateien sein, die ungefährt so aussehen (Dateiname):

Logged Data_2013_02_11_12_18_51.tdms
Logged Data_2013_02_11_12_19_01.tdms
Logged Data_2013_02_11_12_20_04.tdms
Logged Data_2013_02_11_12_21_57.tdms
Logged Data_2013_02_11_12_22_18.tdms

(11.02.2013 11:08 )JulianS. schrieb:  Mein Problem ist nun, dass ich große Sampelpakete brauche um vernünftige Ffts machen zu können und dann das Beispielprojekt meinen Abreitsspeicher füllt.
Wenn man dem Sinunsgenerator in dem Beispielprojekt einen Samplerate von 102400 und eine Sample-Anzahl (pro Block) von 204800 vorgibt dann kann man richtig zuschauen wie sich der Arbeitsspeicher füllt solang bis Windows dem ganzen einen Grenze setzt.

Habe das mal auf meinem Rechner laufen lassen und sehe da keine Probleme. Auch mit Deinen Werten
hat mein PC zumindestens kein Problem damit. Arbeitsspeicher etc. bleibt frei und die CPU Auslastung
geht nicht über 5% (Core i5, 3,2 GHz, 8 BG Speicher, Windows 7 x64). Kann evtl. auch an Deinem
Rechner liegen.

(11.02.2013 11:08 )JulianS. schrieb:  Kann mir jemand sagen wo diese ganzen Werte landen? Es scheint ja irgendwo Speicherplatz reserviert zu werden der nicht mehr freigegeben wird, aber ich kann mir nicht erklären wo.

Ja, wie oben. TDMS Datei im "LabView Data" Ordner von Dir.

Stefan

Vielen Dank für die schnelle Antwort dali4u

Das mit den tdms Dateien habe ich schon verstanden und das funktioniert auch soweit. Aber mein Problem mit dem vollen Arbeitsspeicher habe ich auch, wenn ich das logging einfach durch eine Schleife ersetze die die Queque leert. Vlt liegt es echt an meinem Rechner. Ich habe hier nur 2 gb drin.
Ich habe das Gefühl, dass er eine bestimmte Anzahl Werte in einen Puffer schreibt.
Wann gibt den Labwview den Reservierten Arbeitsspeicher eines VIs wieder frei?
Meine Version macht das erst wenn ich das vi neu öffne. Roter Boller und dan den Pfeil reicht nicht. Ist das normal?
Ich versuch im Momment mein Programm so umzuschreiben, dass ich mit 6040 großen Paketen arbeite. Dann pendelt sich die RAM-Speicher-Belegeung bei ca 300mb ein. Allerdings gefällt mir das alles nicht so gut :/

schönen Tag!

(11.02.2013 13:48 )JulianS. schrieb:  Meine Version macht das erst wenn ich das vi neu öffne. Roter Boller und dan den Pfeil reicht nicht. Ist das normal?

Ja, falls du z.B. mit nicht initialisierten Schieberegistern arbeitest.
Für eine genauere Analyse müsstest du aber einmal deinen Sourcecode hochladen.

Gruß, Jens

Inzwischen habe ich Zugriff auf und habe mir das Projekt angeschaut.

Der Speicherfresser ist in deinem Fall das Chart im Main.vi, aber auch nur, weil du die Samplezahlen im Sinusgenerator so extrem verändert hast.

Das Chart ist eingestellt auf einer Historie-Länge von 1000 Waveform-Charts. Du pumpst mit deinen veränderten Einstellungen bei jeder Waveform mehr als 200000 Datenpunkte in den Speicher. Bei 8 byte pro Double-Wert sind das pro Waveform also schon gut 1,56 MB, bei 1000 Waveforms im Chart dann > 1,5 GB!

Die Historie des Chart wird nirgendwo im Programm gelöscht und wird erst durch Neuladen des VI zurückgesetzt.

Gruß, Jens