' schrieb:Ok, vermutlich habe ich eine falsche Vorstellung vom Ringpuffer. Bisher habe ich mir den manuell vorgestellt (Array ist 2 Pufferlängen groß, erster Pufferinhalt wird reingeschrieben, zweiter Pufferinhalt wird reingeschrieben, dritter wird reingeschrieben mit Überschreiben des ersten, vierter wird reingeschrieben mit Überschreiben des zweiten, etc). Das nennt man scheinbar "linear"? So meinst du es aber vermutlich nicht, sondern eben dynamisch mit Lese- und Schreibzeigern, von denen ich aber (bisher) nichts verstehe/kenne.
Mit linear hab ich gemeint: Hat einen Anfang immer bei 0 und ein Ende immer bei MaxLength-1. (Das ergibt dann einen "linearen Pfeil", der immer bei 0 beginnt in in Richtung Ende kuckt und MaxLength lang ist).
Ein Ringpuffer ansich hat - wie eben ein Ring, also ein Kreis - keinen Anfang und kein Ende, (respektive ist der Anfang immer mit dem Ende identisch, wenn der Puffer ganz voll ist). Anfang und Ende werden festgelegt durch die beiden Zeiger "Lese ab hier" und "Schreibe ab hier". Außerdem müssen die Teile, die in den Puffer geschrieben werden sollen, nicht zwangsläufig alle gleich lang sein. Bei einen Ringpuffer muss auch folgendes Problem beachtet werden: Der Ringpuffer selbst ist organisiert als linearer Speicherbereich - also mit Anfang und Ende. Der Ringpuffermanager muss sich nun darum kümmern, dass nicht über das "lineare Ende" hinausgeschrieben werden darf, sondern dass ein Umbruch auf den linearen Anfang gemacht werden muss.
Zitat:Aber: Ist das notwendig? Reicht für meine Anwendung ein linearer Ringpuffer nicht völlig aus?
Wenn du alles im Griff hast, kannst du selbstverständlich auch einen optimierten Ringpuffer verwenden. So wie du gesagt hast: Der Ringpuffer ist so groß wie zwei Datensätze, die einfach wechselweise überschrieben werden. Aber vorsicht hier: Die neuen Datensätze müssen immer die gleiche Größe haben (was selbstverständlich möglich ist, wenn man mit dem DaqMX immer eine feste Zahl ausliest)
Zitat:Folgende Idee: Für die Verarbeitung ist es ja nicht notwendig, dass ich so viele "Vergangenheitswerte" mitnehme. Es würde, um zB den Knick beim Intergieren zu vermeiden, völlig ausreichen jeweils den Pufferinhalt vom letzten Durchlauf mitzunehmen. Ich muss hier ja sowieso begrenzen, weil sonst in der Verarbeitung viel zu viele Daten ankommen und die Schleifengeschwindigkeit mit zunehmender Datenmenge ins unendliche geht.
Also: "Manueller Ringpuffer". Dh, immer nur den aktuellen Pufferinhalt und den vom Durchlauf zuvor in die Verarbeitung schicken, dort verarbeiten, im Graf nur den letzten anzeigen und die Daten (falls Speicherung gewünscht) dann in ein sehr groß initialisiertes Array schicken, welches so mit der Zeit aufgefüllt wird. Vor der Speicherung evtl noch den leeren Rest abschneiden und das wars.
Aber wahrscheinlich habe ich es doch noch nicht verstanden und auch hier ist wieder ein Denkfehler drin?
Wie, wo soll hier ein Denkfehler sein?
Jetzt, als du erklärt hast, was du brauchst und was du nicht brauchst, sehe ich gleich, dass das auch so geht. Es könnte auch noch so gehen: Du hast drei Arrays parallel laufen. Zwei der Länge MaxLength (M1, M2) und eines der Länge 2*MaxLength (MM). Außerdem gibt es eine Boolsche Variable M?, die mit jedem DaqMX-Rd getoggelt wird. Ist M? true, wird M1 überschrieben und MM ergibt sich aus M2+M1. Ist M? false, wird M2 überschieben und MM ergibt sich aus M1+M2. Beachte: Alle drei Arrays sind initialisiert und werden nur mit Replace ersetzt.
Zitat:@Datentypen: Gut, da werde ich dann wohl leider nicht viel einsparen können.
Jetzt hast du's aber schriftlich und kannst nachweisen, warum du so viel Speicher brauchst.
Zitat:Und vor allem, wieso bleibt die Auslagerungsdatei auch nach Programmende so groß? Ist das ein Windows-Problem? (Windows XP Prof mit SP3 hier)
JaNein.
Wenn du alles so gemacht hast wie erklärt, sollte es nicht zu solchen Problemen kommen. Speichermanager sind immer sehr kompliziert. Wer (LV oder Win32) da genau wo seine Finger drinnen hat, weis hier nur einer. Normalerweise würde ich aber sagen, dass LV, also dein Programm daran schuld ist (einen speziellen Fehler in LV, den du gerade gefunden hast, schließen wird vorerst aus genauso wie einen in WinXP).
Der Fehler muss nicht zwangsläufig von der Array-Geschichte kommen, die hier gerade diskutiert wird. Möglicherweise generierst du ständig Handle und schließt sie nicht wieder. Das führt früher oder später (bei 3MHz eher früher) zu einen Überlastung des Systems.
Kannst du mal ein Bild vom Blockdiagramm mit den Arrays und den Datenflüssen davor machen? Vielleicht sehe ich ja was.
/
Grundkonzept einer Datenerfassung/Auswertung
