kontinuierlichen Messdaten speichern

[sirius]

Ich habe den Vorteil von "ASCII"-Dateien im eigenen Programm noch nie gesehen. die Pro-Argumente von Reinhard klingen aber logisch. Ich hatte mich gewundert als LEM (Messgerätehersteller) auf seine letzten Tage (vor der Zerschlagung) für seine Messdateien XML eingeführt hat. Vielleicht war es einer der Gründe und ich dachte schon an irgend eine neue Norm.
Siemens hält es unterschiedlich. Entweder billig Text (fast CSV) oder in Blöcken binär. Ansonsten habe ich schon ganz andere lustige Textformate gefunden (kein XML). Die sind weder wartbar noch komprimiert.

Edit: zu Chemiker, man sieht es gibt tausend Möglichkeiten. Wenn du Chemikers Variante betrachtest, kannst du neben dem Mittelwert auch andere statistische Werte nehmen: Maximalwert, Minimalwert, 50%-Percentil (oder anderes Percentil), Schwankungsbreite. Und davon einen oder mehrere abspeichern. Da kann man auch gleich Bezüge zu irgendwelchen speziellen werten errechnen und speichern (Grenzwerte, Schmelzpunkt...)

[messie]

Ich bleibe deshalb auch bei dem Ansatz, aufgabenorientiert zu entscheiden. Man kann tollste Datenaufzeichnung, tollste Datenbanken oder tollste GUIs kreiren - trotzdem zählen die Ergebnisse. Hier zählt zunächst nicht die Programmierkunst, sondern die Fähigkeit, die Aufabe so zu formulieren, dass sie dann später programmtechnisch umgesetzt werden kann.

Grüße, Messie

[BUG]

Hallo,

man könnte die Daten ja auch erstmal temporär speichern,
so das bei einem Messfühler und 2 Byte-Werten ca. alle 17 min eine neue temporäre (binäre) Datei angelegt wird.
Diese wäre ca. 2 MB groß und würde damit nicht unnötig Platz für die Verwaltung verschwenden.

Nach Ende der Messung können diese Dateien dann zusammen- und in ein beliebiges anderes Format überführt werden.

Diese Methode hat den Vorteil, das bei einem Absturz (mit anschließenden Neustart) wahrscheinlich nur 17min Messung verloren gehen.


MfG,
Bug

[Chemiker]

Hallo,

Zitat:

man könnte die Daten ja auch erst mal temporär speichern,
so das bei einem Messfühler und 2 Byte-Werten ca. alle 17 min eine neue temporäre (binäre) Datei angelegt wird.

Warum 17 min. ?

Zitat:

Diese Methode hat den Vorteil, das bei einem Absturz (mit anschließenden Neustart) wahrscheinlich nur 17min Messung verloren gehen.

17 min. währen mir zu lang. Ich glaube, dass man die Daten schon relativ zeitnah physikalisch speichern sollte, um größeren Datenverlust zu vermeiden. Aber ich muss zugeben dafür kenne ich das Projekt zu wenig, um da eine Vernünftige Aussage machen zu können.

Bis bald Chemiker

[BUG]

Zitat:

Zitat von Chemiker

Warum 17 min. ?

Weil das knapp 2MB/2Byte/60sek sind.

Und 2MB weil ich nicht glaube es allzu häufig vorkommt, dass jmd. eine Clustergröße von über 2MB hat.
War ja nur ein Vorschlag ... andere Zeiten/Größen dürfen natürlich auch :mrgreen:

MfG,
Bug

[Chemiker]

Hallo BUG,

alles klar!

Bis bald Chemiker

[Oracle]

Mensch da sind ja über Nacht eine Menge Antworten hinzugekommen. :P

Zum Projekt:
Die Temperaturen sollen aufgenommen werden, um daraus später Wärememengen zu bestimmen.

Um die Datenmenge zu reduzieren, hatte ich mir auch schon überlegt, dass wenn ein neuer Wert kein großes Delta zum vorherigen hat, diesen einfach nicht zu speichern. Stattdessen sollen nur Werte abgelegt werden, bei denen wirklich was passiert. Also Werte wo ein großes delta zum vorherigen Wert ist.

Die Variante mit der Datenbank hatte ich bisher ehrlich gesagt nicht weiter betrachtet. Da ich mit Datenbanken (trotz meines Namens, der eher an das Orakel von Delphi angelehnt ist :P ) bisher nicht beschäftigt habe, hab ich da einfach nicht drüber nachgedacht. Wäre es denn eine lohnende Überlegung?

[DeddyH]

Zitat:

Zitat von Oracle

Wäre es denn eine lohnende Überlegung?

Hmmm... siehe #22 ;)

[Jelly]

Ich denke, du solltest nicht vergessen, dass diese grossen Datenmenge (immerhin bis zu Millionen Messwerte pro Woche, bei 16 Temp. Sensoren), ja auch irgendwie ausgegwertet werden müssen. Diese Menge wirst du nicht einfach mal so in Excel oder Origin via Copy&Paste einfügen, und dir Kurven erstellen lassen.

Da denke ich bist du bei einer Datenbak recht leichter dabei, die Daten nachher zu verarbeiten. du kannst die Macht von SQL nutzen, um deine Daten entsprechend zu filtern. Exportieren in irgendwelche Fremdformate geht dann immer noch.

Hängt aber trotzdem immer noch von der Komplexität der auswertung ab. Ich denk mal, bei Wärmemengen wirst du aufintegrieren müssen... Eventuell müsste man sich da ein anderes Speicherkonzept überlegen. Dazu müssten wir aber wissen, wie nachher ausgewertet wird.

[Oracle]

Die Auswertung der Daten soll direkt in meiner Software stattfinden. Dazu soll man dann eine vorher abgespeicherte Messung öffnen können. Diese wird dann über TeeChart (ich benutze TeeChart Professional) angezeigt. Also ein Export nach aussen ist nicht nötig.