Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
wie wurden Sie Riesenmengen von Daten mit 20 HZ und mehr am besten im Text Speichern?. Mit "write to spreadsheet" werden die zeitgesteurte Schleifen (langsamer) bzw. halten ihren Zyklus nicht!. Die Software wurde für Grenz-Überwachung, Daten Bearbeitung, Geräte Steuerung uvm entwicklet.
Danke im Voraus.
Anzeige
29.07.2010, 05:35 (Dieser Beitrag wurde zuletzt bearbeitet: 29.07.2010 05:43 von Matze.)
das kommt auf den Einsatzzweck an. Mit 20 Hz sollten sich Daten (je nach Anzahl der Eingänge) problemlos direkt im ASCII-Format speichern lassen können.
"Write to Spreadsheet" ist meiner Meinung nach ungeeignet für eine fortlaufende Protokollierung, da bei jedem Protokollierungsvorgang die Datei geöffnet und wieder geschlossen wird und das kostet richtig viel Zeit.
Sinnvoller ist es, die Datei vor der Messung anzulegen bzw. zu öffnen. Dann folgen die Schreibvorgänge und erst nach der Messung wird die Datei geschlossen (s. Datei-VIs in der Palette "File I/O"). Der Nachteil hierbei ist, dass bei einem Programmabsturz die Daten seit dem Erstellen der Datei mit hoher Wahrscheinlichkeit verloren gehen, sofern die Datei nicht noch korrekt geschlossen wird. Normalerweise stürzt ein Programm natürlich nicht so schnell ab.
Sollte das die zeitgesteuerten Schleifen immer noch verlangsamen, würde ich das TDMS-Format nutzen. Dabei werden viele Daten per Streaming protokolliert und zwar binär. Wird DAQmx verwendet, kann damit sogar die Protokollierung direkt über den Treiber erfolgen. Da gibt es einen entsprechenden DAQmx-Baustein.
Auch bei einer Protokollierung, die über Tage, Wochen oder Monate erfolgt, würde ich TDMS dem ASCII-Format vorziehen, da hier die Daten auch bei Abstürzen erhalten bleiben. Erfolgt die Protokollierung z.B. alle 2 Minuten für 10 Minuten o.ä. ist das ASCII-Format geeignet.
Doch wie gesagt, so schnell gibt's auch im ASCII-Format keinen Datenverlust. Man beendet die Programme ja nicht über den roten, runden Knopf in der Menüleiste, sofern dieser überhaupt sichtbar ist.
Der Nachteil an TDMS ist, dass die Daten nicht für jeden lesbar sind, da sie binär vorliegen. Deshalb geht das Speichern auch so schnell. LabVIEW bringt VIs mit, um auf diese Daten zugreifen zu können und für Excel bzw. OpenOffice gibt es kostenlose Addons.
Wenn es also im ASCII-Format zeitkritisch wird, würde ich TDMS nutzen.
Einen Versuch, es wie oben erwähnt im ASCII-Format zu speichern, ist es jedoch wert. Denn 20 Hz ist keine hohe Abtastrate. Da habe ich schon deutlich mehr Daten im ASCII-Format gespeichert (kHz-Bereich). Nur darf die Datei nicht in jedem Schleifendurchlauf geöffnet und geschlossen werden, wie bereits angesprochen.
' schrieb:Sinnvoller ist es, die Datei vor der Messung anzulegen bzw. zu öffnen. Dann folgen die Schreibvorgänge und erst nach der Messung wird die Datei geschlossen (s. Datei-VIs in der Palette "File I/O"). Der Nachteil hierbei ist, dass bei einem Programmabsturz die Daten seit dem Erstellen der Datei mit hoher Wahrscheinlichkeit verloren gehen, sofern die Datei nicht noch korrekt geschlossen wird.
Der beschriebene Nachteil ist nicht ganz so gravierend...
Das Einzige was verloren geht, sind die Daten im Dateipuffer. Schreib einfach mal Daten in eine Textdatei, ohne sie ordnungsgemäß zu schließen und du wirst sehen, dass du (fast immer) alles lesen kannst. Sonst fehlt evtl mal die letzte Zeile.
Diesen Puffer kann man deaktivieren oder per Hand leeren. Wobei ich bisher nur Letzters bereits getan habe, also keine Aussage zum Deaktivieren treffen kann.
Gruß SeBa
Dieser Beitrag soll weder nützlich, informativ noch lesbar sein.
Er erhebt lediglich den Anspruch dort wo er ungenau ist, wenigstens eindeutig ungenau zu sein.
In Fällen größerer Abweichungen ist es immer der Leser, der sich geirrt hat.
Rette einen Baum!
Diesen Beitrag nur ausdrucken, wenn unbedingt nötig!
Ich würde die Schreibfunktion auf jeden Fall in eine andere Schleife auslagern und dort das File IO unterbringen. Mit den normelan Stringschreibefunktionen wirst du wohl schnell genug sein. Als Verbindung zwischen den beiden Teilen tut's eine Queue. Da würde ich gleich vorsehen, den Q-Status zum Debugging auslesen zu können. Nur den Fall, daß die Schreibschleife tatsächlich nicht nachkommt.
Den Dateipuffer beim Öffenen zu deaktivieren würde ich nur in absoluten Ausnahmefällen in Betracht ziehen, kannst dann nur ganze Sektorgrößen beim Schreiben benutzen und musst dich darum selbst kümmern (Padding).
Ein großer Vorteil von Txt-Dateien -> wenn was schief geht, sind die Daten einfacher zu rekonstruieren.
