kontinuierlichen Messdaten speichern

[Oracle]

Ich habe momentan ein Projekt, wo ich Temperaturfühler auslese und diese Messdaten speichern soll.
Die Messung kann bis zu einer Woche gehen, was heißt dass jede Menge Daten zusammen kommen.
Es soll jede Sekunde der Temperaturwert (als double) und die aktuelle Zeit (auch double) gespeichert werden.

Wie wäre es am geschicktesten das umzusetzen? Sollte jeder Wert sofort in eine Datei geschrieben werden, oder lieber immer Gruppenweise, wie zum Beispiel einmal in der Minute.
Macht man das mit einem Filestream?

Ich habe gehört, dass die Daten wenn sie binär gespeichert werden weniger Platz verbrauchen. Wie muss ich dafür vorgehen.
Ist es am besten jedes Wertepaar als Record zu behandeln?

So Vielen dank schon mal an euch im Vorraus :-D

[sirius]

Wenn du die Sache mit der Datenbank ausgeschlossen hast, dann würde ich in Blöcken schreiben. Damit verlierst du bei einem Systemabsturz nicht alle Daten.

Was heist denn binär für dich? Ein Double belegt immer 8 Byte. Und so speicherst du die auch. Ob du das jetzt in einen Record packst, bringt (je nach Anwendung) keinen Vor- und Nachteil im Platzverbrauch. Es könnte nur für dich leichter in der Programmierung werden.
Ich würde mir aber nochmal Gedanken über die Messgenauigkeit machen. Wahrscheinlich kannst du sowieso auf Single gehen. Das wären dann nur 4 Bytes. Auch gesehen habe ich schon Festkommawerte (mit 2 Kommastellen; ähnlich wie Currency).
Wenn du weiterhin sparen willst, kannst du dir ja mal Gedanken über den Zeitstempel machen. Entweder du speicherst nur am Anfang einmal die Zeit und weist dann einfach, dass jeder Wert entsprechend eine Sekunde später ist, oder du speicherst die ZeitDifferenz zum vorherigen Messwert, oder, oder oder.... du kannst dir in deinem Datenformat so einiges überlegen. Das hängt aber auch von deiner Technik und deinen Anfforderungsgenauigkeiten ab.

Etwas anderes ist es, wenn du die Messwerte später in Notepad (oder auch Excel) lesen willst. Dann mach dir mal keine Gedanken über Speicherplatzeinsparung, sondern eher über das notwendige Datenformat. Da musst du auch meistens die Zahlen in Text umwandeln, was je nach Länge der Zahlen (in Textformat) entspr. Bytes benötigt.

[Oracle]

Danke erstal für die ausführliche Antwort.
Mit Binär meinte ich, dass es nicht im Klartext gespeichert wird. Also dass man es eben nicht mit Notepad öffnen kann.

Das mit der Zeit nur einmal am Anfang speichern, das finde ich gut, da die Abstände ja wirklich immer gleich sind.
Auch würde single als Datentyp für die Temperaturwerte reichen. Das spart auch nochmal ordentlich.

Jetzt würde ich gerne noch wissen wie ich das Programmiertechnisch am besten löse. Bisher habe ich in Delphi ausser ini Dateien noch nichts gespeichert. Mach ich das am besten mit einem TFilestream, dem ich dann jeden Messwert, bzw. jeden Block von Messwerten übergebe?

[himitsu]

Da Windows ja über eine nette Dateicache verfügt, kannst du eigentlich sofort die Werte in die Datei schreiben.

TFileStream und eigentlich fast alles andere geht da auch ganz gut.
und wenn du möchtest, dann kannst du ja alle 15, 30 oder 60 Sekunden ein "Flush" (Dateipuffer leeren) ausführen.


Wegen der Zeit:
ich weiß ja nicht wie genau die Zeitbestimmung sein muß,
aber wenn es schon genauer sein muß (die Timer und Windows arbeiten ja nicht soooo genau) ...
eventuell wäre es da gut, wenn du zwischendurch nochmals die aktuelle Zeit mit einfließen läßt, dann verringern sich die Rechenungenauigkeiten.

Delphi-Quellcode:

[single]  // x = INF  // Signalwert für nachfolgende Zeit
[double]  // aktuelle Zeit

[single]  // Temperatur
[single]  // Temperatur
[single]  // Temperatur
[single]  // Temperatur
[single]  // Temperatur
...

[single]  // x = INF  // Signalwert für nachfolgende Zeit
[double]  // aktuelle Zeit

[single]  // Temperatur
[single]  // Temperatur
[single]  // Temperatur
[single]  // Temperatur
...

z.B. viele Videoformate speichern nur den Unterschied zwischen folgebildern und fügen alle einer gewissen Zeit ein Vollbild in den Datenstrom mit ein, damit sich z.B. komprimierungsfehler nicht aufaddieren und man auch mal schön schnell in dem Film rumspringen muß, ohne gleich alle vom Dateianfang an durchgehn zu müssen.

[sirius]

Du kannst auch nochmal über Festkommawerte nachdenken. Unter Umständen kommst du dann auf 2 Bytes runter. Wenn du z.B. eine Genauigkeit von 2 Nachkommastellen haben willst, dann schaffst du damit einen Temperaturbereich von 0 bis 650 Kelvin. (wenn du z.B. eine 24533 abspeicherst, bedeutet dies 245.22) Festkommawerte entsprechen ja auch eher dem Verhalten von A/D-Wandlern.

TFileStream ist ganz einfach. (ungetestet)

Delphi-Quellcode:

const Dateiname='xyz.dat';
var Datei:TfileStream;
...
if fileexists(Dateiname) then
begin
  Datei:=Tfilestream.create(Dateiname,fmopenread);
  Datei.seek(0,sofromend);
end
else
begin
  Datei:=Tfilestream.create(Dateiname,fmopenread);
  //Header schreiben, z.B.
  Datei.write(zeit,sizeof(zeit)); //zeit ist z.B. TDateTime
end;
try

  //Messwert schreiben
  Datei.write(Messwert,sizeof(Messwert);
  ...

finally
  Datei.free;
end;

Wahrscheinlich ist es güntstiger das Auslesen der Messwerte in einem Thread zu gestalten, damit du wirklich jede Sekunde lesen kannst, falls mal das Speichern (oder das GUI) etwas länger dauert.

Edit: himitsus Variante wird auch von vielen Messgeräteherstellern genutzt. Du hast eben Blöcke, die am Anfang einen Zeitstempel und eine Länge haben. Dadurch kannst du auch nach einer Pause in derselben Datei weiterschreiben und einfach einen neuen Block anfangen.

[Nikolas]

Der Datentyp für die Messwerte hängt davon ab, was und wie du messen willst. Wenn du nur deine Zimmertemperatur ohne Nachkommastelle hin messen willst, reicht die ein byte. Wenn du sehr genaue Messwerte hast, die im schlimmsten Fall noch groß streuen, brauchst du was größeres.
Wie sehen denn deine Messwerte aus? (In welchem Intervall und mit welcher Genauigkeit).
Ich gehe fast davon aus, dass du auch schon mit einem word (2Byte: 0 bis 65535) auskommst. Du kannst dir ja eine einfache lineare Funktion basteln, die dann die Temperaturen auf dieses Intervall abbilden.
Mit der Speicherung wäre mein Gedanke der, dass du eher viele kleine Dateien anlegst, jeweils vielleicht für 10min. An den Anfang kommt der Zeitstempel und dann die Werte. Das hat auch den Vorteil, dass du nicht immer die Riesendatei anfassen musst, wenn du nachschauen willst, wie warm es am Donnerstag um 12 war. Und falls was kaputt geht, verlierst du nur wenige Messwerte.

[sirius]

Zitat:

Zitat von Nikolas

Ich gehe fast davon aus, dass du auch schon mit einem word (2Byte: 0 bis 65535) auskommst.

siehe mein Post :zwinker:

Zitat:

Zitat von Nikolas

Du kannst dir ja eine einfache lineare Funktion basteln, die dann die Temperaturen auf dieses Intervall abbilden.

Sie muss nichtmal linear sein. Quadratisch hilft auch, wenn du im unteren Messbereich eine höhere Genauigkeit verlangst als im oberen.

Zitat:

Zitat von Nikolas

Das hat auch den Vorteil, dass du nicht immer die Riesendatei anfassen musst, wenn du nachschauen willst, wie warm es am Donnerstag um 12 war. Und falls was kaputt geht, verlierst du nur wenige Messwerte.

Aber eben den Nachteil der filebasierten Datenablage. Da kann schnell mal etwas verloren gehen. Bei einem Messgerät mag das noch gehen, aber bei vielen und einem verteilten Netzwerk..... :warn:

[Oracle]

Also meine Messwerte haben zwei Nachkommastellen, deshalb finde ich die Variante sie mit 100 zu multiplizieren sehr gut.
Dann komm ich wirklich mit 2 Byte aus. Mehrere Dateien finde ich allerdings nicht so praktisch, da jede Datei eine Messung darstellen soll. Die Zeiten jeweils in Intervallen abzuspeichern finde ich sehr clever das werde ich mir gleich mal genauer überlegen.

[himitsu]

nja groß ... bei dem Intervall und mit Singel für Temperatur so etwa 1,2 MB pro Woche.

da wäre die Mehrdateivariante alle 10 Minuten mit ~1300 Byte pro Datei schon reichlich Platzverschwendung (wann man den Platzverbrauch im Dateisystem betrachtet)

[Reinhard Kern]

Zitat:

Zitat von Oracle

Also meine Messwerte haben zwei Nachkommastellen, deshalb finde ich die Variante sie mit 100 zu multiplizieren sehr gut.
Dann komm ich wirklich mit 2 Byte aus. Mehrere Dateien finde ich allerdings nicht so praktisch, da jede Datei eine Messung darstellen soll. Die Zeiten jeweils in Intervallen abzuspeichern finde ich sehr clever das werde ich mir gleich mal genauer überlegen.

Hallo,

das mit binär oder Text würde ich mir nochmal überlegen. Ich habe das zwar jahrzehntelang auch so gemacht, komme aber immer mehr davon ab. Binäre Dateien sind eben nicht offen lesbar (was das Debuggen erschwert), nicht reparierbar und können auch ohne die zugehörige Software überhaupt nicht gelesen werden. Daher geht der Trend in der IT ganz allgemein zu lesbaren Protokollen (FTP,HTTP) und lesbaren Dateien (XML). Eine XML-formatierte Datei mit Messwerten ist auch noch lesbar, wenn deine Software längst untergegangen ist.

Ich weiss natürlich nicht, ob du das überhaupt willst, aber meiner Meinung nach ist Verschleierung von Daten nicht Aufgabe eines Programmierers, im Gegenteil. Meine Kunden dürfen meine Dateien gerne auch noch lesen, wenn ich tot bin. Ich weiss aber, dass nicht jeder Programmierer so denkt.

Die Datenmenge kannst du ja nachrechenen, lohnt sich aber nicht: je Sekunde 2 Doubles geben nicht mal 2 MByte am Tag. Eine durchschnittliche heutige Festplatte reicht also ein paar Jahre. Ich würde wegen der leichteren Handhabung Monatsdateien anlegen.

Gruss Reinhard

[Oracle]

Ein lesbares Format zu erzeugen, habe ich aus der Sicht noch überhaupt nicht betrachtet. Aber du hast sicher nicht unrecht, wenn du sagst dass die Daten damit auch noch lesbar sind, wenn es die Software nicht mehr gibt. Mit XML habe ich mich bisher aber noch gar nicht auseinander gesetzt.

Naja und nicht mal 2 MB am Tag ist bei der bisherigen Variante richtig.
Allerdings habe ich 16 Temperaturwerte pro Sekunde auszulesen, was die Menge dann schon wieder etwas aufbläht. Und auch wenn Festplatten heute riesig sind, finde ich es trotzdem nicht gut wenn man verschwenderisch mit dem Platz umgeht.

[himitsu]

erzeugst für die 16 Temperaturwerte verschiene Dateien, oder wäre für dich alles in einer lieber?

Wegen der Lesbarkeit:
Wenn das Dateiformat ausreichend dokumentiert ist, dann kann das immer ausgelesen werden (solange es passede Computer gibt).

[Jelly]

Ich denke, wir bewegen uns noch in einer Bandbreite, wo man sicherlich die ganzen Messdaten bequem in einer Datenbank ablegen kann. Damit wird die Auswertung später wesentlich leichter.

Wenn ich das richtig verstehe: Du hast 16 Temperaturfühler. Jeder eine Messung/sec, und ein Messzeitraum von max. 7 Tagen... Dann komme ich auf weniger als 10 Millionen Messwerte/Woche. Das schafft jedes auf dem Markt befindliche Datenbanksystem locker... Und wenns mal eng wird, so würde ich jedes Speichern in einem getrennten Thread auslagern, damit ja auch kein Messwert verloren geht... Die Tabellen indizieren würde ich nicht. Erst nach den Messungen würde ich entsprechende Indizes auf die Spalten hauen.

[DerDan]

Ich finde die Idee,

die Daten im Klartext abzuspeichern am besten.
ich würde pro Zeile eine Messzeitpunkt mit allen Werten in eine datei schreiben.
Auch würde ich die Daten alle 10min oder jede Stunde in eine neue Datei speichern.
Und falls diese Klartext Dateien zu groß werden, würde ich die packen (Zip).
denn besser als mit zip bekommt es kein Binärformat hin.

StarOffice speichert seine Dateien auch so ähnlich.
(Inhalt eines Docs in mehrere XML Dateien und diese dann zusammen packen und speichern)


mfg

DerDan

[Oracle]

Also eine Datei für alle Messfühler halte ich am Sinnvollsten. Woher soll der Kunde nachher sonst wissen welche Datei er öffnen soll.

[Oracle]

Was mir jetzt noch Probleme bereitet:

Wenn ich nun kontinuierlich Daten in meine Datei schreibe, und irgendwann nach einer gewissen Zeit damit fertig bin, woher weiß ich dann wieviele Datensätze diese enthält.
Anders gefragt: Wie lese ich die Datei wieder aus, ohne zu wissen wieviele Schleifendurchläufe ich machen muss, bis ich alle Datensätze habe?

[Nikolas]

Wenn es eine normale textdatei ist, musst du mal nach EOF suchen (End Of File).
Also grob

Delphi-Quellcode:

öffnen(datei);
while (not EOF(datei))
auslesen(datei)
end;

Alternativ weisst du wie groß ein Datensatz ist und du weisst, wie groß die Datei ist. Daran solltest du die Anzahl der Werte ausrechnen können.

[DeddyH]

Bei einer typisierten Datei kannst Du nach dem Öffnen FileSize() erfragen.

[himitsu]

@DeddyH:
aber nur wenn du mit einer festen Datenblockgröße arbeitest

wenn man jetzt hier die Zeit nur sporatisch einfügt, dann ist die Blockgröße nicht mehr fest.



Also du kannst
* entwerder vorm Einlesen die Datei durchgehen und zählen
und dann nochmal alles auslesen und behandeln
* einfach bis zum Dateiende (oder einem Fehler) einlesen
* wärend die datei geschrieben wird mitzählen und dieses dann in einem Header (Dateianfang) nachtragen oder einen Fotter (Daeiende) anhängen
vorm einlesen wird dann nur noch der Heder/Fotter gelesen.


Allgemein solltest du bei den kurzen Messabständen die Datei/Datenbank nicht für jeden Messwert neu öffnen.

hier mal 'ne binäre Variante mit Temperatur als Word gespeichert und direkt über die WinAPI (alles andere wie z.B. TFileStream geht im Grunde auch über die WinAPI).
Außerdem in süßen Klassen und es wird nur alle mindestens 60 Sekunden die Zeit mitgespeichert:

Code:

[Word=$FFFF][Double]  // Zeit
[Word]  // Temperatur
[Word]  // Temperatur
...
[Word=$FFFF][Double]  // Zeit
[Word]  // Temperatur

Delphi-Quellcode:

Uses Windows, SysUtils;

Type TFileSave = Class
    hFile: THandle;
    Time: LongWord;
    Constructor Create; //Override;
    Destructor Destroy; Override;
  Public
    Function Open(Const FileName: String; CreateNew: Boolean = False): Boolean;
    Function Save(Temp: Single): Boolean;
    Function Close: Boolean;
  End;

  TFileLoad = Class
    hFile: THandle;
    Time: TDateTime;
    Constructor Create; //Override;
    Destructor Destroy; Override;
  Public
    Function Open(Const FileName: String): Boolean;
    Function Load(Out Time: TDateTime; Out Temp: Single): Boolean;
    Function Close: Boolean;
  End;

Constructor TFileSave.Create;
  Begin
    Inherited;
    hFile := INVALID_HANDLE_VALUE;
  End;

Destructor TFileSave.Destroy;
  Begin
    CloseHandle(hFile);
    Inherited;
  End;

Function TFileSave.Open(Const FileName: String; CreateNew: Boolean = False): Boolean;
  Var CD: LongWord;

  Begin
    CloseHandle(hFile);
    If CreateNew Then CD := CREATE_ALWAYS Else CD := OPEN_ALWAYS;
    hFile  := CreateFile(PChar(FileName), GENERIC_WRITE, FILE_SHARE_READ,
      nil, CD, FILE_ATTRIBUTE_NORMAL or FILE_FLAG_SEQUENTIAL_SCAN, 0);
    SetFilePointer(hFile, 0, nil, FILE_END);
    Time   := GetTickCount - 60000;
    Result := hFile <> INVALID_HANDLE_VALUE;
  End;

Function TFileSave.Save(Temp: Single): Boolean;
  Var D: TDateTime;
    W: Word;
    W2: LongWord;

  Begin
    Result := True;
    If GetTickCount >= Time + 60000 Then Begin
      W      := $FFFFFFFF;
      D      := Now;
      Result := Result and WriteFile(hFile, W, SizeOf(W), W2, nil) and (W2 = SizeOf(W));
      Result := Result and WriteFile(hFile, D, SizeOf(D), W2, nil) and (W2 = SizeOf(D));
      Time   := GetTickCount;
    End;
    W := Round(Temp * 100);
    If W = $FFFF Then W := $FFFE;  // Spezialwert als Temperatur verhindern
    Result := Result and WriteFile(hFile, W, SizeOf(W), W2, nil) and (W2 = SizeOf(D));
  End;

Function TFileSave.Close: Boolean;
  Begin
    Result := CloseHandle(hFile);
  End;

Constructor TFileLoad.Create;
  Begin
    hFile := INVALID_HANDLE_VALUE;
  End;

Destructor TFileLoad.Destroy;
  Begin
    CloseHandle(hFile);
  End;

Function TFileLoad.Open(Const FileName: String): Boolean;
  Begin
    CloseHandle(hFile);
    Time   := 0;
    hFile  := CreateFile(PChar(FileName), GENERIC_READ, FILE_SHARE_READ,
      nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL or FILE_FLAG_SEQUENTIAL_SCAN, 0);
    Result := hFile <> INVALID_HANDLE_VALUE;
  End;

Function TFileLoad.Load(Out Time: TDateTime; Out Temp: Single): Boolean;
  Var D: TDateTime;
    W: Word;
    W2: LongWord;

  Begin
    Result := ReadFile(hFile, W, SizeOf(W), W2, nil) and (W2 = SizeOf(W));
    If Result Then
      If W = $FFFFFFFF Then Begin
        Result := ReadFile(hFile, D, SizeOf(D), W2, nil) and (W2 = SizeOf(D));
        If Result Then Begin
          Result := Load(Time, Temp);
          Time   := D;
        End;
      End Else Begin
        Time := Time + 1/24/60/60;
        Temp := W / 100;
      End
  End;

Function TFileLoad.Close: Boolean;
  Begin
    Result := CloseHandle(hFile);
  End;

Delphi-Quellcode:

Uses Windows, SysUtils, Unit3;

Var FS: TFileSave;
  FL: TFileLoad;
  Temp: Single;
  Time: TDateTime;
  S: String;

Begin
  FS := TFileSave.Create;
  If not FS.Open('Project3.dat') Then
    Raise Exception.Create('TFileSave - create/open file');

// {wiederholen}
//   Temp := Wert_holen;
//   FS.Save(Temp);
// {/wiederholen}

  {test}
    FS.Save(12.3);
    Sleep(1000);
    FS.Save(4.56);
    Sleep(1000);
    FS.Save(78.9);
  {/test}

  FS.Close;



  FL := TFileLoad.Create;
  If not FL.Open('Project3.dat') Then
    Raise Exception.Create('TFileLoad - create/open file');

// {wiederholen}
//   FL.Load(Time, Temp);
//   Zeit_ausgeben       := Time;
//   Temperatur_ausgeben := Temp;
// {/wiederholen}

  {test}
    While FL.Load(Time, Temp) do Begin
      S := DateTimeToStr(Time) + ' = ' + FloatToStr(Temp);
      MessageBox(0, PChar(S), '', 0);
    End;
  {/test}

  FL.Close;
End;

Dieses könnte man jetzt noch um mehr TempWert erweitern (eventuell sogar mit einer dynamischen Anzahl) und falls sich das Messintervall mal ändern könnte, dann sollte man es auch noch mit in der Datei speichern.

Wertebereich: 0.00 <= Temp <= 655.36

und falls man Word durch SmallInt (für Temp) ersetzt, dann -327.68 <= Temp <= 327.67

[DeddyH]

Zitat:

Zitat von himitsu

...wenn man jetzt hier die Zeit nur sporatisch einfügt, dann ist die Blockgröße nicht mehr fest.

Dann ist das aber auch keine typisierte Datei ;)

[himitsu]

Zitat:

Zitat von DeddyH

Dann ist das aber auch keine typisierte Datei ;)

Wer sagt das?

wenn die Datei als File of Word definiert ist und [Word=$FFFF][Double] = 3 * [Word],
dann paßt das auch in eine derart typisierte Datei rein, nur weiß man dann noch nicht wie oft die Zeit in der Datei vorkommt.

[Jelly]

@Himitsu:
Das, was du über paar Seiten Code schreibst, sähe bei mir so:

SQL-Code:

Insert into Messwerte (SensorId, Creation, Temperatur) values (1,'2007-12-12 17:58:03',23.2)

und so

SQL-Code:

Select Creation, Temperatur from Messwerte where SensorId = 1 order by Creation

Ich will damit nur sagen, warum bis jetzt hier keinen ausser mir eine Datenbanklösung interessiert.

[DeddyH]

Zitat:

Zitat:

Zitat von DeddyH

Dann ist das aber auch keine typisierte Datei ;)

Wer sagt das?

wenn die Datei als File of Word definiert ist und [Word=$FFFF][Double] = 3 * [Word],
dann paßt das auch in eine derart typisierte Datei rein, nur weiß man dann noch nicht wie oft die Zeit in der Datei vorkommt.

Wenn Du davon ausgehst, ist jede Datei typisiert, notfalls als File of Byte.

[sirius]

Zitat:

Zitat von Jelly

Ich will damit nur sagen, warum bis jetzt hier keinen ausser mir eine Datenbanklösung interessiert.

Zitat:

Zitat von Sirius

Wenn du die Sache mit der Datenbank ausgeschlossen hast, dann ...

Edit: Sch*** QuoteTag-Fehler
Edit2: Nun aber :wall:

[Jelly]

Zitat:

Zitat von sirius

Zitat:

Zitat von Sirius

Wenn du die Sache mit der Datenbank ausgeschlossen hast, dann ...

Edit2: Nun aber :wall:

Das hast bislang nur du behauptet. Oracle hat nirgends geschrieben, dass er das ausschliesst. Und deshalb wunderts ich, dass hier alle kompliziert mit irgendwelchen typisierten Dateien hantieren, wenn auch anders und in meinen Augen leichter, ausfallsicherer geht.

[sirius]

najajaja. Du hast gesagt, dass keiner außer du sich für DB interessiert. Das stimmte ja so nicht :zwinker:
Ich hatte es allerdings nur kurz erwähnt, da aber Oracle (man könnte sogar beinahe am Namen vermuten, dass er Datenbanken kennt :angel2: ) nicht drauf eingegangen ist, habe ich (und wahrscheinlich nicht nur ich) gedacht, dass er diese Lösung aus irgendwelchen Gründen schon ausgeschlossen hat.

[Jelly]

Zitat:

Zitat von sirius

Ich hatte es allerdings nur kurz erwähnt, da aber Oracle (man könnte sogar beinahe am Namen vermuten, dass er Datenbanken kennt :angel2: ) nicht drauf eingegangen ist, habe ich (und wahrscheinlich nicht nur ich) gedacht, dass er diese Lösung aus irgendwelchen Gründen schon ausgeschlossen hat.

Es gibt viele Oracle: In der Matrix kam auch eins vor :zwinker:

Wie dem auch sei... Ich finde wir sollten hier einfach mal beide Lösungsvorschläge betrachten.

[sirius]

Zitat:

Zitat von Jelly

Wie dem auch sei... Ich finde wir sollten hier einfach mal beide Lösungsvorschläge betrachten.

jo :bouncing4:

[messie]

Zitat:

Zitat von Reinhard Kern

das mit binär oder Text würde ich mir nochmal überlegen. Ich habe das zwar jahrzehntelang auch so gemacht, komme aber immer mehr davon ab. Binäre Dateien sind eben nicht offen lesbar (was das Debuggen erschwert), nicht reparierbar und können auch ohne die zugehörige Software überhaupt nicht gelesen werden. Daher geht der Trend in der IT ganz allgemein zu lesbaren Protokollen (FTP,HTTP) und lesbaren Dateien (XML). Eine XML-formatierte Datei mit Messwerten ist auch noch lesbar, wenn deine Software längst untergegangen ist.

Ich weiss natürlich nicht, ob du das überhaupt willst, aber meiner Meinung nach ist Verschleierung von Daten nicht Aufgabe eines Programmierers, im Gegenteil. Meine Kunden dürfen meine Dateien gerne auch noch lesen, wenn ich tot bin. Ich weiss aber, dass nicht jeder Programmierer so denkt.

Die Datenmenge kannst du ja nachrechenen, lohnt sich aber nicht: je Sekunde 2 Doubles geben nicht mal 2 MByte am Tag. Eine durchschnittliche heutige Festplatte reicht also ein paar Jahre. Ich würde wegen der leichteren Handhabung Monatsdateien anlegen.

Das finde ich witzig: ich bin gerade von der Textdatei abgekommen und zur binären gegangen. Davor habe ich "jahrzehntelang" jedem erklärt, wie vorteilhaft ASCII-Dateien sind. Da habe ich mir so manche blutige Nase geholt...
Ich denke, es hängt von der Aufgabenstellung ab. Im Moment schreibe ich binär, weil es um normkonforme Messungen geht, bei denen die Originaldaten möglichst manipulationsfrei aufbewahrt werden sollen. Für Anwendungen, bei denen es nur um die Informationen geht (ich habe lange Servicetools gewartet und weiterentwickelt) würde ich uneingeschränkt ASCII empfehlen: den Speicherverbrauch bestimmst Du selbst (1 Byte pro gespeichertem Zeichen), eine Datei kann auch nach irgendwelchen Fehlern mal restauriert werden (das ist bei binären Daten sehr aufwendig).
Zudem würde ich (habe nicht alle Posts vollständig gelesen) den Speicherzyklus an der Aufgabe orientieren. Temperaturen müssen oft nicht pro s gemessen bzw. geschrieben werden. meist reichen 10-15s aus. Das direkte Schreiben bei so "langsamen" Vorgängen ist auf jeden Fall zu bevorzugen - bei einem Stromausfall hast Du dann meist die aufgelaufenen Daten verfügbar. Von einer Datenbanklösung würde ich gar nichts halten, es sei denn, Du willst auf die Daten ca. 10mal pro Sekunde von zehn unterschiedlichen Stellen zugreifen und zehn unterschiedliche Auswertungen damit machen.
Wenn die Messungen ungefähr eine Woche dauern, kann man täglich eine Datei anlegen. Das hat den Vorteil, daß das Datum im Dateinamen erscheinen und somit zur Übersicht beitragen kann.
Ach ja, Du solltest das Auslesen und Speichern wirklich als Thread anlegen. Und zwar nicht, um auf eventuelle ausgedehnte Speichervorgänge zu warten wie sirius meint sondern um Deinen Rechner während des Messens freizustellen. Nochmal: Temperaturvorgänge sind relativ langsame Vorgänge, das Warten auf die Ergebnisse kann Deinen Rechner sehr langsam machen.

Grüße, Messie

[Chemiker]

Hallo Oracle,

ich stelle einfach mal eine Frage, warum willst Du Temperaturwerte jede Sekunde messen und abspeichern und das eine ganze Woche, für 16 Messpunkte kommen da 9.676.800 Messwerte zusammen. Ich finde bei der Messdatenflut ist nicht das abspeichern das Problem, sondern was fängst Du anschließend mit diesen Messwerten an. Was zu überlegen ist, sind so viele Messwerte notwendig? Wenn ja, ist die Temperaturabweichung innerhalb einer sek. so groß das man sie abspeichern muss?
Mein Ansatz währe, die einzelnen Messwerte in einem Ringbuffer zu schreiben, sagen wir mal 60 Messwerte (also 1 min.), wenn der Ringbuffer voll ist würde ich einen Durchschnittswert errechen und diesen Wert dann mit dem Zeitstempel abspeichern. Ich würde dann auch alle 16 Messstellen mit den Zeitstempel abspeichern und dann so vorgehen wie es Messie beschrieben hat.

Bis bald Chemiker

[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.