Lesen großer txt ohne Laufzeiteinbußen

Hallo wertes Forum,

ich möchte während einer Langzeitaufzeichnung von 8 AI´s, (1s/sek, 2 Wochen), auf die bereits geschriebenen Daten zugreifen und diese darstellen. Dabei ist es wichtig, dass die Durchlauf- & Abtastzeiten der Hauptanwendung zumindest einigermaßen konstant bleiben. (Kleine Schwankungen, bzw. einmalige Stillstände/Ausfälle von 2-10 Sek wären zu verkraften aber unschön).

Im Anhang befindet sich ein VI (+Beispieldatei) welches bereits das tut was es soll. Nämlich, die Daten aus der .txt lesen, die von der Hauptanwenung generiert wird und diese Darstellen. Meine Frage ist nun, wie ich diesen Funktionsumfang in die bestehende Hauptanwendung integrieren kann ohne dass diese in Sachen Laufzeit erheblich darunter leidet.

Der große Haken: Die .txt Files können bis zu 200 MB (!) groß werden.

Mein Rechner fängt bereits bei bei 100MB-großen Dateien an zu haken, und das ohne die Hauptanwendung! :-(

Ideen und Lösungsansätze bitte Anfängertauglich verpacken.

Vielen Dank,
Philipp

Hallo Philipp,

Zitat:Der große Haken: Die .txt Files können bis zu 200 MB (!) groß werden.
Mein Rechner fängt bereits bei bei 100MB-großen Dateien an zu haken, und das ohne die Hauptanwendung! :-(

Und was ist die logische Konsequenz dieser Beobachtung?
Einfach nicht die komplette Datei (auf einmal) einlesen!
Immer nur kleinere Teile davon einlesen…
Einfaches Beispiel:
Momentan liest du die komplette Datei ein und wandelst sie in ein 2D-Array um. Dann löscht du die ersten 3 Zeilen aus dem Array. Beides benötigt (bei deinen großen Dateien) richtig viel Speicher.
Bessere Lösung: lies doch einfach erst die ersten 3 Zeilen aus der Datei und danach mit einem zweiten ReadTextFile die nächsten Zeilen. Schon hast du dir eine resourcenfressende DeleteFromArray-Funktion gespart…

- Als "schwierig" stufe ich hier nicht die eigentliche Dateioperation ein, sondern das nachfolgende Umwandeln von Text nach 2D-DBL-Array: hier wird massiv Speicher belegt und CPU beansprucht. Hier besser mit kleineren Datenblöcken arbeiten.
- Du willst anscheinend auch die komplette Datei darstellen: 2Wochen*7Tage*1440Min*60s*1S/s~=1.2M Samples. Wie willst du >1Mio Samples in einem Graph darstellen, der nur ~1000 Pixel breit ist? Auch hier gilt: soviele Samples darzustellen, frisst einfach nur Resourcen. Daten vor der Darstelleung dezimieren!
- Wieso verwendest du nicht TDMS-Dateien? Die sind für solche Sachen auch sehr gut geeignet?
- Ich finde es auch problematisch, wenn zwei Anwendungen (oder Funktionen in einer Anwendung) parallel auf dieselbe Datei zugreifen wollen…
- Warum willst du diese riesige Datei erneut einlesen, wenn du nur ein paar Parameter (diese "Adjuster") anpassen willst???

Hallo Gerd & danke für die Antwort.

ich fang mal hinten an:

Zitat: - Warum willst du diese riesige Datei erneut einlesen, wenn du nur ein paar Parameter (diese "Adjuster") anpassen willst???

Es geht "nur" darum eine Möglichkeit zu schaffen, sich während des laufenden Versuchs die bereits aufgezeichneten Daten anzuschauen und so langzeittrends auszumachen. Das Hineinzoomen in bestimmte Zeitabschnitte wäre ein "nice to have", ist jedoch kein muss. (Die Adjuster sind gerade nur da um Graphen, die auf einer Achse dargestellt werden, nahe aneinander zu bringen).

Zitat:- Ich finde es auch problematisch, wenn zwei Anwendungen (oder Funktionen in einer Anwendung) parallel auf dieselbe Datei zugreifen wollen…

Ich habe noch keine Erfahrung damit, glaube Dir das aber gerne.

Zitat:- Wieso verwendest du nicht TDMS-Dateien? Die sind für solche Sachen auch sehr gut geeignet?

Mein Job ist eine bestehende Anwendung (ohne Dokumentation) zu modifizieren und ich tue mich bereits reichlich schgwer damit. In dem bestehden VI, sowie in vielen weiteren noch zu modifizierenden Anwendungen wird mit .txt Dateien gearbeitet. Nach der Aufzeichnung werden die .txt-Datein in MATLAB weiter prozessiert. Daher wird es vermutlich erstmal bei .txt bleiben. (Nur mal weil neugierig: Liessen sich TDMS Datei später in .txt konvertieren?)

Zitat:- Als "schwierig" stufe ich hier nicht die eigentliche Dateioperation ein, sondern das nachfolgende Umwandeln von Text nach 2D-DBL-Array: hier wird massiv Speicher belegt und CPU beansprucht. Hier besser mit kleineren Datenblöcken arbeiten.

Klingt sinnvoll. Für die Umsetzung bräuchte ich jedoch noch weitere Instruktionen.

Zitat:Bessere Lösung: lies doch einfach erst die ersten 3 Zeilen aus der Datei und danach mit einem zweiten ReadTextFile die nächsten Zeilen. Schon hast du dir eine resourcenfressende DeleteFromArray-Funktion gespart…

Gerne werde ich diesen Ansatz umsetzen. Allerdings habe ich ihn noch nicht so ganz verstanden. Die ersten drei Zeilen werden nur raus gelöscht, da sie sonst als Nullen im Graph dargestellt werden -> dies zerschießt mir dann in den Plots die Autoscale-Funktion. Könntest du mir noch einmal näher beschreiben, wie du dir das vorstellst?

Ich fasse meine gesammelten Ansätze zum Reduzieren des Aufwands für CPU/RAM mal zusamm´:
- Andere Bausteine/Funktionen zum Einlesen verwenden
- Einlesen aus der Datei von nur jedem 2.-200. Sample (bzw. Zeile)
- Nicht alle Spalten einlesen. Das .txt Dokument enthält momentan 26 per Tab getrennte Spalten, benötigt werden jedoch "nur" neun.
- Einlesen der Datei komplett weglassen und dafür einen neuen separaten Graphen im Main VI erstellen , in dem "Live" nur jedes X te Sample angezeigt wird. Dieser Graph wäre dann so auszulegen, dass die Historienlänge = Versuchsdauer*Samplerate/Faktor entspricht. Sind Historienlängen von 100.000 Samples ok?

Welchen Ansatz sollte ich verfolgen?

Und abschließend würde mich nochmal interessieren, wann genau verwendet man Verlaufsgraphen und wann X-Y Diagramme. Gibt es einen grundlegenden Unterschied (auch in Bezug auf CPU/RAM)?

Danke Dir!

Hallo Philipp,

Zitat:- Andere Bausteine/Funktionen zum Einlesen verwenden
- Einlesen aus der Datei von nur jedem 2.-200. Sample (bzw. Zeile)

Jein.
Du kannst schon die Funktionen wie bisher weiterverwenden - aber du musst ja nicht die komplette Datei auf einmal einlesen.
Ein Ansatz wäre z.B. pro Leseoperation "nur" 1000 Zeilen einzulesen…

Zitat:- Nicht alle Spalten einlesen. Das .txt Dokument enthält momentan 26 per Tab getrennte Spalten, benötigt werden jedoch "nur" neun.

Du kannst nur komplette Zeilen lesen - ein Nachteil des Text-Formats.
Also Zeilen einlesen und die unnötigen Spalten dann eben wegfiltern…

Zitat:- Einlesen der Datei komplett weglassen und dafür einen neuen separaten Graphen im Main VI erstellen , in dem "Live" nur jedes X te Sample angezeigt wird. Dieser Graph wäre dann so auszulegen, dass die Historienlänge = Versuchsdauer*Samplerate/Faktor entspricht. Sind Historienlängen von 100.000 Samples ok?

Mal überlegen: 100k*8Byte*20 (?) Kanäle = 16MB RAM. Prinzipiell machbar, dauert aber trotzdem lange zu plotten…

Zitat:Welchen Ansatz sollte ich verfolgen?

Daten noch mehr dezimieren: aus 100000 Samples sind zuviel für einen Plot mit 1000 Pixel Breite…

Zitat:Und abschließend würde mich nochmal interessieren, wann genau verwendet man Verlaufsgraphen und wann X-Y Diagramme. Gibt es einen grundlegenden Unterschied (auch in Bezug auf CPU/RAM)?

Da ist kein großer Unterschied: du stellst für beide die Daten bereit.
Der XY-Graph braucht tendenziell doppelt soviel Speicher für die gleiche Anzahl Samples, da ja 2 Koordinaten (XY) statt nur einer (Y) erwartet werden…

So groß ist die Datei doch gar nicht, aber Du hast viel getan, damit das Programm langsam ist. Wenn man z.B. die Schieber bewegt, gibt das ein Maschinengewehrfeuer von Wertänderungen. Das hat bei Dir ein Maschinengewehrfeuer von Neueinlesungen der Datei zu Folge.
Habe mal einiges geändert, versuchs mal damit.

  Read Tab-Delimited File_2WA.vi (Größe: 22,14 KB / Downloads: 254)

Hallo Lucki,

vielen Dank für die Modifikation! So nimmt die Anwendung ja wirklich immens weniger Ressourcen in Anspruch! Respekt!

Allerdings werden die Werte nun ohne Nachkommastellen abgebildet. Da in dem Block "Tabelle mit Trennzeichen lesen" als Standarddatenfomat bereits (%.3f) hinterlegt ist, habe ich gerade keinen Ansatz wie ich die Zahlen wieder als Fließkomma dargestellt bekomme. Hier wäre ich dir für einen Tipp dankbar!

Gruß,
Philipp

Anzeige

Das ist ein allzu bekanntes Problem. Dann wird der Dezimalpunkt in Deiner Datei nicht als Dezimal-Trennzeichen anerkannt. Wenn Du Labview und ein deutsches Windows installiert hast und in beiden die Standardeinstellungen gelassen hast, dann ist das leider der Fall. Das zu ändern gibt es mehrere Möglichkeiten:
1. Ganz einfach: Das Formatzeichen "%.;" (ohne Anführungszeichen) verwenden.
2. In den Labview-Optionen "Frontpanel/Lokales Dezimalzeichen" das Häkchen entfernen.
3. In Windows in den Zeit- und Datumseinstellungen den Dezimalpunkt statt des Kommas als lokale (Länder-) Einstellung festlegen.

Ich habe bei mir das Letzgenannte gemacht, und deshalb hatte ich das Problem nicht.
Gruß Lucki

Hallo Lucki,

funktioniert alles super; vielen Dank!!
(Nachdem das mit der 1. Variante nicht hingehauen hat (Diagramm zeigte dann garnichts mehr an), habe ich es mit der 2. umgesetzt; das hat dann funktioniert!)

Natürlich habe ich jetzt jedoch noch eine weitere Frage, und zwar:
In der ersten Spalte meiner .TXT befindet sich ja ein Zeitstempel. Lässt es sich einrichten, dass diese Zeitangaben auf der X-Achse des Graphen angezeigt werden?

Ich habe schon das ein- oder andere probiert, war aber leider noch nicht erfolgreich..

Danke,
Philipp

Hallo Philipp,

einfach die CSV-Datei als Strings einlesen und die erste Spalte selbst in Timestamps umwandeln.
Deine Plots dann in einem XY-Graphen darstellen.

Falls die Samples zeit-äquidistant ermittelt wurden, reicht es auch aus, aus den ersten beiden Timestamps das t0 und dt zu bestimmen und deine Plots als Waveforms zu verpacken. Dann einen Waveform-Graph verwenden…

Hy Gerd,

danke für deine Antwort. Das mit dem Darstellen im XY-Plot geschieht ja bereits (siehe Read Tab-Delimited File_2WA.vi von Lucki, fünf Posts weiter oben).

Zitat:...als Strings einlesen und die erste Spalte selbst in Timestamps umwandeln.

Könntest du dies noch etwas konkretisieren? Bzw. an dem VI von Lucki erklären? Ich gehe davon aus, dass dies in diesem VI bereits erfolgt. Es ist lediglich die Einstellung am Graph, bzw. dass ich den Offset (Startdatum der Aufzeichnung) nicht berücksichtigt bekomme.

Ah - moment. Vermutlich habe ich etwas Falsches behauptet, wenn ich sage, dass ich über ein "Spalte mit Zeitstempeln" verfüge. Es ist so, dass ich in der ersten Zeile einen String mit Startdatum und Uhrzeit habe und dann fortlaufend eine "Art" Zeitstempel, die z.B. bei 4.960.185 beginnt und über 1000 Zeilen bis 13.424.732.451 geht.

Demnach enthält mein darzustellender Datensatz einen Startwert und dann halt die relativ verstrichene Zeit in einem mir nicht bekannten Format..

Danke Dir !

Philipp