+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: Der richtige Umgang mit (Langzeit)Messdaten (/Thread-Der-richtige-Umgang-mit-Langzeit-Messdaten)
Der richtige Umgang mit (Langzeit)Messdaten - NoWay - 01.10.2014 13:19
Hallo zusammen.
Aus gegebenen Anlass beschäftigt mich die im Topic versteckte Frage.
Folgendes Beispiel sei gegeben:
Eine Messung produziert Messdaten von 36 Bytes pro Messzyklus. Diese Daten werden in Form von Cluster Arrays gespeichert wodurch sich der Speicherverbrauch aufsummiert. Nun möchte man eventuell Langzeitmessungen durchführen und will keine Daten seit Start der Messung verlieren. Die Konsequenz aus der aktuellen Situation wäre demnach die, dass das Array immer weiter aufgeblasen wird, bis letztendlich kein Speicher mehr vorhanden ist. Dies geschieht relativ zügig, da die Messungen im Millisekunden Takt erfolgen.
Soweit das Szenario. Mich beschäftigt nun die Frage, wie man mit solchen Situationen speziell in Labview umgeht. Wie verhindert man einen Speicherüberlauf und wie realisiert man Langzeitmessungen in der Praxis?
NoWay
RE: Der richtige Umgang mit (Langzeit)Messdaten - GerdW - 01.10.2014 13:25
Hallo NoWay,
also als wichtigstes: niemals Daten nur im Speicher sammeln! In regelmäßigen Abständen speichern, z.B. alle 10s (=36*1000*10=360kB)…
Zitat:Diese Daten werden in Form von Cluster Arrays gespeichert wodurch sich der Speicherverbrauch aufsummiertWarum ein Array of Cluster? Warum nicht ein 2D-Array?
RE: Der richtige Umgang mit (Langzeit)Messdaten - NoWay - 01.10.2014 13:42
Hallo GerdW.
Mit speichern meinst du vermutlich, dass die Daten auf die Festplatte geschrieben werden sollen. Demnach also immer warten, bis man z.B. 10 Datensätze zusammen hat, diese wegschreiben und das Array wieder löschen?
Wie verhält sich das dann, wenn man diese Daten z.B. für einen Graphen heranziehen will? Liest man dann die "Messdatei" zyklsich für die Graphdaten aus?
Zitat:Zitat:Zitat:Diese Daten werden in Form von Cluster Arrays gespeichert wodurch sich der Speicherverbrauch aufsummiert
Warum ein Array of Cluster? Warum nicht ein 2D-Array?
Gegenfrage: Warum nicht? Welchen Vorteil würde man aus einem 2D Array ziehen? Ich persönlich arbeite gerne mit Clustern, da diese recht angenehm zu handhaben sind.
RE: Der richtige Umgang mit (Langzeit)Messdaten - GerdW - 01.10.2014 14:21
Hallo NoWay,
Zitat:Demnach also immer warten, bis man z.B. 10 Datensätze zusammen hat, diese wegschreiben und das Array wieder löschen?Noch schöner sind natürlich Queues: diese können als Zwischenpuffer Daten aufnehmen, ohne das man sich um ein Arrayhandling (selbst) kümmern muss…
Zitat:Wie verhält sich das dann, wenn man diese Daten z.B. für einen Graphen heranziehen will? Liest man dann die "Messdatei" zyklsich für die Graphdaten aus?Gott bewahre!
Nein, man speichert schon ein paar Daten für die Anzeige im Speicher. Aber man beschränkt die Datenmenge auf das nötigste! Und das heißt: entweder begrenzt man die Historie auf die letzten Minuten (statt Stunden/Tage) oder man reduziert die Daten sinnvoll (wenn ein Graph nur 800 Pixel breit ist, kann er kaum 100tausende Pixel sinnvoll darstellen)!
Für dieses Thema gibt es einen extra Eintrag in der LabVIEW-Hilfe, vielleicht solltest du die mal lesen? (Hilfe->Grundlagen->Leistungs- und Speichermanagement)
Zitat:Gegenfrage: Warum nicht?Weil ein Cluster eine weitere Verschachtelungs-Ebene in deine Datenstruktur einzieht. Und es lästig werden kann, wenn man immer erst ein Array of Cluster elementeweise indizieren muss, um die Daten für einen Plot auszulesen…
RE: Der richtige Umgang mit (Langzeit)Messdaten - NoWay - 02.10.2014 12:09
Danke für diese wertvollen Informationen. Ich werde das in zukunft beherzigen und konnte nun bereits schon etwas an der Performance meiner Anwendung schrauben.
Bis zum nächsten thread
NoWay
RE: Der richtige Umgang mit (Langzeit)Messdaten - Kiesch - 02.10.2014 13:28
Vielleicht noch eine Anmerkung zum Thema 2D Array vs. Cluster Array:
bei einem 2D Array sind alle Zeilen und Spalten immer gleich lang. Werden kürzere hinzugefügt, dann werden die "fehlenden" stellen mit dem Standardwert aufgefüllt, bei längeren werden alle anderen einträge auf die gleiche länge verlängert (ebenfalls mit dem Standardwert). Effektiv geht bei dieser Lösung also die Array Länge verloren (was nicht immer ein Problem ist, zum Beispiel wenn eh alle 1D Arrays aus denne das 2D Array besteht gleich lang sind, oder durch ein Steuerzeichen terminiert werden etc.).
Entsprechend kann es schon Sinn machen ein Array erst in einen Cluster zu packen und dann die Cluster in einem Array zu sammeln (dabei geht die Länge des ursprünglichen Arrays nämlich nicht verloren).
Gruß Kiesch
RE: Der richtige Umgang mit (Langzeit)Messdaten - mathez - 13.05.2015 13:57
Hallo,
ich hänge mich mal an diesen Thread an, da auch mich mit sehr großen Datenmengen herumschlage und mir momentan so ein bisschen der richtige Weg fehlt. In einem anderen Thread wurde mir schon sehr geholfen - vielen Dank dafür.
Nun geht es bei mir darum, dass ich 200 Kanäle im Milisekundentakt auslese und speichere. Alles funktioniert soweit.
Idealerweise sollen jetzt diese 200 Kanäle auch noch visualisiert werden und über einen möglichst langen Zeitraum abrufbar sein. Mittlerweile ist mir klar, dass die Visualisierung niemals alleine über die Historielänge des Signalverlaufs funktionieren kann, da die Datenmenge schlicht weg viel zu groß ist.
Meine Idee wäre, die Daten aus den (momentan *.txt-Dateien) praktisch dynamisch auszulesen und zu visualieren. Dazu müsste ich aber ja durch verschieben des Plots die jeweiligen Daten aus den Textdateien lesen?! Noch besser wäre es ja, wenn ich je nach "Zoom" im Diagramm die relevanten Werte herausfiltern kann, da ich ja ohnehin niemals alles in einem Plot darstellen kann. Würde das überhaupt funktionieren? Wenn ja, könnt ihr mir ein paar Stichpunkte nennen? Oder ist der Ansatz völliger Blödsinn und es funktioniert evtl. sogar leichter?
Ich habe auch viel über Signalexpress gelesen, aber letztlich bleibt das Problem der großen Datenmengen je zunächst bestehen.
Gruß, Mathes