Datenanzeige wird langsamer

Liebes Forum,

mit eurer Unterstützung wächst das Programm für meinen Versuchsstand fortlaufen. Zuletzt hat mir GerdW prima in diesem Thread geholfen.

Nun eine allgemeine Frage zum "Leistungsvermögen" meines Messprogramms:
Im ersten Ansatz habe ich meine Daten mit 1kHz abgegriffen und sie mit einem Notifier in einen Chart geschickt. Die 1kHz Messfrequenz waren da kein Problem in der Darstellung
   

Im jetzigen Zustand mit einer eigenen Messagequeue für den DisplayLoop und einigen dazugekommenen Umrechnungen wird die Aufzeichnung bei 1kHz langsamer. Nach ca. 15 Sekunden Messzeit wird die Anzeige fortlaufend langsamer, sodass ich, nach 2 Minuten Messzeit "nur" 51000 Messpunkte habe, was ja, bei 1kHz Messfrequenz, gerade mal 51 Sekunden entspricht. Wenn ich in die erzeugte TDMS Datei schau habe ich die kompletten 120k Messwerte jedoch gespeichert.
   

Bei 1kHz ist die Rechnerleistung auch vollständig ausgelastet, bei 250Hz jedoch steigt die Auslastung in 4 Minuten zu 100% und dann wird das ganze wieder langsam. Wenn ich jetzt auf 20Hz runtergehe wird es demnach auch irgendwann passieren. Die Belastung des Arbeitsspeicher steigt nicht, was für mich heißt, ich schiebe nirgendswo Unmengen an Daten hin und laste ihn damit aus (zB. mit meiner Datenqueue zum Speichern der Daten), sondern es ist irgendein wachsender Berechnungsaufwand.

Meine Vermutung liegt beim Schieberegister und dem damit verbundenen Aufwand, den der Graph hat sich mit wachsender Datenmenge "immer wieder durch t0, dt und das (wachsende) Y-Array aufzubauen".
Weiß jemand woran es liegen könnte und wie ich das angehen könnte?

VG
Abongile

Anzeige

Hallo Abongile,

das Problem ist das BuildArray mittendrin!

Dein Graph soll immer mehr Samples anzeigen - und das dauert eben. Da muss man irgendwann die Datenmenge auf eine vernünftige Größe beschränken!
Außerdem: Es ist wenig sinnvoll, auf einem Graph von vielleicht 500Pixel Breite mehrere Tausend Samples darstellen zu wollen. Das Stichwort dazu lautet "Daten dezimieren"…

Hallo zusammen,

nach Gerds Hinweis habe ich mich länger damit befasst, wie ich meine Daten sinnvoll in dem Graphen reduziere und mich entschlossen meine Datenerfassung von "N Kanäle 1 Sample" auf "N Kanäle N Sample" umzustellen und meinen AcquisitionLoop einen Timer zu gegeben (s. Bild 2). Somit kann ich meinem Verständnis nach weiterhin mit 1kHz Messdaten erfassen, die Messwerte werden jedoch in ein 1D Array geschrieben und nur alle 100ms (=10Hz) über die Queue und den Notifier weitergegeben.

In meinem DisplayLoop wird der Notifier ausgelesen und die Waveform indiziert, sodass nur der erste Messwert des übertragenen Arrays weiterverarbeitet wird (s. Bild 1). Somit ist meine Anzeigefrequenz 10Hz und zwar egal mit welcher Frequenz ich Messdaten erfassen will.

Was haltet Ihr von dem Lösungsansatz?

VG
Abongile

Hallo Abongile,

beim Aquire in der Producer-Loop sollte/darf keine Wartezeit sein: hier wird das Delay über DAQmxRead realisiert, da es ja eben 100ms benötigt, um 100 Samples bei 1kHz Samplerate zu lesen!

In der Display-/Consumer-Loop sollte auch keine Wartezeit sein, da hier ja auf neue Werte im Notifier gewartet wird…
(Bei einem Notifier könnte man mit einer Wartezeit arbeiten, da immer nur der aktuellste/letzte Wert bereitgestellt wird. Dann eben auch ein Timeout beim Lesen einsetzen.
Bei einer Queue dagegen sollte die Queue möglichst schnell gelesen werden, da ja dort alle Werte angesammelt werden. Oder man holt die Daten "blockweise" aus der Queue, indem man sie in definierten Zeitabständen leert…)

Hallo Gerd,

verdammt, die Option "Numbers of Samples per Channel" in DAQmxRead ist mir erst nach deinem Hinweis aufgefallen.

Zitat:beim Aquire in der Producer-Loop sollte/darf keine Wartezeit sein: hier wird das Delay über DAQmxRead realisiert, da es ja eben 100ms benötigt, um 100 Samples bei 1kHz Samplerate zu lesen!

Deine Antwort verstehe ich nun so:
Es ist sinnvoller bzw. besser die "Number of Samples per Channel" auf 100 zu setzen und dann mit einer einheitlich großem Array unabhängig von der Messfrequenz zu arbeiten? Aber dann änder sich die "Anzeigefrequenz" in meinem Graphen bei jeder Änderung der Messfrequenz.

Zitat:In der Display-/Consumer-Loop sollte auch keine Wartezeit sein, da hier ja auf neue Werte im Notifier gewartet wird…

Genau, das habe ich während dem "Rumprobieren" auch verstanden, daher ist da auch keine Wartezeit drin, sondern eben in der Datenerfassung womit die Notifiermeldezeit auch festgelegt wird

Zitat:Bei einer Queue dagegen sollte die Queue möglichst schnell gelesen werden, da ja dort alle Werte angesammelt werden. Oder man holt die Daten "blockweise" aus der Queue, indem man sie in definierten Zeitabständen leert

Aber genau das passiert doch, wenn ich jetzt mit 100ms bzw. 100 Samplen arbeite, oder? Es kommen in festen Zeitabständen Daten in die Queue --> mein LoggingLoop wartet nur auf die Daten --> Sobald da, werden sie in die TDMS geschrieben.
Habe ich die Abfolge richtig?

VG
Abongile

Hallo Abongile,

Zitat:Es ist sinnvoller bzw. besser die "Number of Samples per Channel" auf 100 zu setzen und dann mit einer einheitlich großem Array unabhängig von der Messfrequenz zu arbeiten?

Das halte ich für sehr sinnvoll. Die Auswerteroutinen können so davon ausgehen, dass Daten fester Blockgröße zu erwarten sind…

Zitat:Aber dann änder sich die "Anzeigefrequenz" in meinem Graphen bei jeder Änderung der Messfrequenz.

Niemand zwingt dich, einen Graph bei jedem neuen Datenblock zu aktualisieren!
Man könnte z.B. programmatisch sicherstellen, dass erst nach 100ms neue Daten in den Graph kommen. Oder nur bei jedem 5. Datenblock der Graph aktualisiert wird. Oder…

Zitat:Habe ich die Abfolge richtig?

Ja.
Nur, dass du munter die Begriffe "Notifier" und "Queue" durcheinander wirfst. Was genau verwendest du?

Anzeige

Hallo Gerd,

Zitat:Nur, dass du munter die Begriffe "Notifier" und "Queue" durcheinander wirfst. Was genau verwendest du?

beides -> Notifier für den DisplayLoop, Queue für das Speichern der Daten in der TDMS. Diese Struktur habe ich aus dem Labview Beispiel "Continoues Measurment and Logging" übernommen und halte sie mit der Begrüdung "Anzeigen und Speichern zu trennen" für gut. Was ist dein Gedanke dazu?
   

Zitat:Niemand zwingt dich, einen Graph bei jedem neuen Datenblock zu aktualisieren!
Man könnte z.B. programmatisch sicherstellen, dass erst nach 100ms neue Daten in den Graph kommen. Oder nur bei jedem 5. Datenblock der Graph aktualisiert wird. Oder…

Das behalte ich im Hinterkopf und hoffe mich demnächst damit nochmal besser befassen zu können! Für eine Umsetzung einer solch "vermutlich" einfachen Idee, brauche ich als Laie immer noch fast einen ganzen Tag...
Ich habe mich daher gerade dazu entschlossen meine Messfrequenz einfach festzulegen, so dass kein Student auf dumme Ideen kommt. Dann kann ich perfekt mit einem Datenblock arbeiten und stelle die Größe des Blocks halt passend zur Mess- und Anzeigefrequenz ein.

Wenn ich das habe, geht es darum mit meinem 1. Thema weiterzuarbeiten und in diese Messroutine die Kamera zur InSitu Dokumentation des Versuchs zu integrieren Ich bin mir sicher, dass ich dafür noch oft auf dein Wissen zurückgreifen werden muss! Zwei Ansätze fallen mir dazu ein:

1. 2 weitere Loops mit Acquisiton der Kamera und Logging der Kamera
2. Integration der Kamera in die existierenden Loops
   

Irgendein Tip, welche Variante besser wäre? ^^ Ich tendiere zu Variante 1, da die Versuche auch ohne Kamera ausgeführt werden sollen.

Danke dir auf jeden Fall, ich würde die Lösungen markieren und den Thread für fertig erklären.

VG
Abongile