MessDaten Speichern
Moderator: Moderatoren
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
MessDaten Speichern
Guten Morgen zusammen
bis anhin speichere ich einige Hundert Messdaten jeweils in 1-5 Sekunden Intervallen in einem Datensätz mit 4 Datenfeldern.
Feld1: 1 Zeichen = Art der Daten
Feld2: Zeit und Datum in lesbarer Form
Feld3: Zeit nummerisch im UnixTime Format
Feld4. 2000 Byte langer Hex Sting mit 500 Word Werten im Bin Format. Das Lese/Schreibprogramm weiss wie jeder Messwert gewandelt werden muss.
Dieses Konzept ist relativ alt, klappt aber problemlos. Es kommt auch daher dass die Werte als Binäre 16 Bit (Word) Werte von den Geräten gelesen werden.
Nun soll noch zu jedem Messwert ein Zeitstempel der letzten Lesung/Änderung gespeichert werden. Das ginge einfach mit einem 4 Feld .
Ich überlege nun ob es nicht ein besseres Konzept gäbe.
Wie speichert Ihr solche Datenberge?
bis anhin speichere ich einige Hundert Messdaten jeweils in 1-5 Sekunden Intervallen in einem Datensätz mit 4 Datenfeldern.
Feld1: 1 Zeichen = Art der Daten
Feld2: Zeit und Datum in lesbarer Form
Feld3: Zeit nummerisch im UnixTime Format
Feld4. 2000 Byte langer Hex Sting mit 500 Word Werten im Bin Format. Das Lese/Schreibprogramm weiss wie jeder Messwert gewandelt werden muss.
Dieses Konzept ist relativ alt, klappt aber problemlos. Es kommt auch daher dass die Werte als Binäre 16 Bit (Word) Werte von den Geräten gelesen werden.
Nun soll noch zu jedem Messwert ein Zeitstempel der letzten Lesung/Änderung gespeichert werden. Das ginge einfach mit einem 4 Feld .
Ich überlege nun ob es nicht ein besseres Konzept gäbe.
Wie speichert Ihr solche Datenberge?
Valar Morghulis
Gruss Carlo
Gruss Carlo
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: MessDaten Speichern
Hallo Carlo !
- Messwertdatei möglichst klein.
- Schnellstes Messen.
- Schnelle Auswertung.
- ...
Ist die Abtastrate für alle Kanäle gleich?
Ist die Abtastrate äquidistant durch einen internen Timer oder extern getriggert?
Im Automotive-Bereich gibt es für Messwerte das Standard-Format MDF, das sehr viele Tools beim Schreiben und Lesen beherrschen.
Was ist dein primäres Ziel?Wie speichert Ihr solche Datenberge?
- Messwertdatei möglichst klein.
- Schnellstes Messen.
- Schnelle Auswertung.
- ...
Ist die Abtastrate für alle Kanäle gleich?
Ist die Abtastrate äquidistant durch einen internen Timer oder extern getriggert?
Im Automotive-Bereich gibt es für Messwerte das Standard-Format MDF, das sehr viele Tools beim Schreiben und Lesen beherrschen.
--
Hans-Peter
Hans-Peter
- Herbert
- Der Entwickler von "Deep Thought"
- Beiträge: 1991
- Registriert: Do, 14. Aug 2008 0:22
- Wohnort: Gmunden am Traunsee, Österreich
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: MessDaten Speichern
Was hast in der "Art der Daten" drin?
Dir fehlt womöglich die Herkunft der Daten, also die Identifikation des liefernden Gerätes.
Denn in Feld 3 hast das Messdatum dabei. Die letzte Messung desselben Gerätes liefert dir so die vorherige Zeit.
Normalerweise leifert dir das Gerät irgendwo die eigene Seriennummer.
Dir fehlt womöglich die Herkunft der Daten, also die Identifikation des liefernden Gerätes.
Denn in Feld 3 hast das Messdatum dabei. Die letzte Messung desselben Gerätes liefert dir so die vorherige Zeit.
Normalerweise leifert dir das Gerät irgendwo die eigene Seriennummer.
Grüsse Herbert
Immer in Bewegung...
Immer in Bewegung...
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: MessDaten Speichern
Die Messwerte kommen aus Bus Systemen: ModBus(e) und Can-Bus mit sehr unterschiedlicher Abtastrate. Ein Zyklus kann bruchteile von Sekunden bis mehrere Sekunden dauern. So z.B. werden beim Modbus in einer Schleife einfach alle angeschlossenen Geräte angefragt.
Die Daten kommen Immer im Binärer Form von 2-4 Bytes pro Wert an.
Beim Can-Bus werden meist nur änderungen des Wertes gemeldet oder es kann auch abgefragt werden.
Die Daten in ModBus müssen immer aktiv abgefragt werden. Oft Registerweise. Die Herkunft ist bei allen Daten immer bekannt.
Ein gelesender Wert wird im Speicher vorgehalten und an einer dem Messwert zugeordneten Position Binär im Speicher Sting geschrieben und so lange für alle Aufgaben und das Schreiben der Messdateien(Zustände) verwendet bis über die Busse neue Wert gelesen werden.
Der Sting enthält so immer alle zur Zeit bekannten Werte in Binärer Form und kann ganz einfach benutzt werden oder nach Hex gewandelt und in eine Datenbank geloggt werden.
Antwortet ein Gerät wegen Defekt nicht ist das sofort ersichtlich: Es gibt ein Problem und einen Alarm, Stop, Not-Aus oder was auch immer.
Hängt ein Sensor mechanisch ist ein Problem wegen fehlendem Timestamp der letzten Wertändeung der Messung nicht einfach ersichtlich.
Deshalb soll nun auch Timestamp der Wertänderung jeweils gespeichert werden um bei bestimmten Adressen auf "hängende" Werte zu testen.
Genau getriggert wird einzig das Speichern aller zu der Zeit bekannten Werte.
Ziele:
1. Schnelle Auswertung
2. kleine Rechnerbelastung
3. kleine Datei
Natürlich laufen auch Steuerungsaufgaben und Ausgaben über die Busse ab, die habe ich ausgelassen.
Die Frage ist zur Zeit: Ist das Speicherkonzept noch einigermassen Zeitgemäss?
Die Daten kommen Immer im Binärer Form von 2-4 Bytes pro Wert an.
Beim Can-Bus werden meist nur änderungen des Wertes gemeldet oder es kann auch abgefragt werden.
Die Daten in ModBus müssen immer aktiv abgefragt werden. Oft Registerweise. Die Herkunft ist bei allen Daten immer bekannt.
Ein gelesender Wert wird im Speicher vorgehalten und an einer dem Messwert zugeordneten Position Binär im Speicher Sting geschrieben und so lange für alle Aufgaben und das Schreiben der Messdateien(Zustände) verwendet bis über die Busse neue Wert gelesen werden.
Der Sting enthält so immer alle zur Zeit bekannten Werte in Binärer Form und kann ganz einfach benutzt werden oder nach Hex gewandelt und in eine Datenbank geloggt werden.
Antwortet ein Gerät wegen Defekt nicht ist das sofort ersichtlich: Es gibt ein Problem und einen Alarm, Stop, Not-Aus oder was auch immer.
Hängt ein Sensor mechanisch ist ein Problem wegen fehlendem Timestamp der letzten Wertändeung der Messung nicht einfach ersichtlich.
Deshalb soll nun auch Timestamp der Wertänderung jeweils gespeichert werden um bei bestimmten Adressen auf "hängende" Werte zu testen.
Genau getriggert wird einzig das Speichern aller zu der Zeit bekannten Werte.
Ziele:
1. Schnelle Auswertung
2. kleine Rechnerbelastung
3. kleine Datei
Natürlich laufen auch Steuerungsaufgaben und Ausgaben über die Busse ab, die habe ich ausgelassen.
Die Frage ist zur Zeit: Ist das Speicherkonzept noch einigermassen Zeitgemäss?
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Herbert
- Der Entwickler von "Deep Thought"
- Beiträge: 1991
- Registriert: Do, 14. Aug 2008 0:22
- Wohnort: Gmunden am Traunsee, Österreich
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: MessDaten Speichern
Interessant.
Wie willst die Daten sonst speichern? Die Gröse ist nicht unbedingt Thema.
Die Frage ist, ob du die 2000 Byte alle gespeichert brauchst?
Falls nein:
Entweder vorausscheiden, um nur die relevanten Datenteile zu verwenden oder mehrere Datenfelder führen um verschiedene Teile der 2000 Byte separat abzulegen?
Die Geschwindigkeit der gewünschten Auswertung kann davon abhangen. Allerdings kann ein Auswerteteil sehr wohl und wohl auch sinnigerweise diese Arbeit besser übernehmen.
Falls ja: Könntest pro Art der Daten eine eigene Tabelle führen.
Wie willst die Daten sonst speichern? Die Gröse ist nicht unbedingt Thema.
Die Frage ist, ob du die 2000 Byte alle gespeichert brauchst?
Falls nein:
Entweder vorausscheiden, um nur die relevanten Datenteile zu verwenden oder mehrere Datenfelder führen um verschiedene Teile der 2000 Byte separat abzulegen?
Die Geschwindigkeit der gewünschten Auswertung kann davon abhangen. Allerdings kann ein Auswerteteil sehr wohl und wohl auch sinnigerweise diese Arbeit besser übernehmen.
Falls ja: Könntest pro Art der Daten eine eigene Tabelle führen.
Grüsse Herbert
Immer in Bewegung...
Immer in Bewegung...
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: MessDaten Speichern
Ja es braucht immer alle Messwerte gespeichert.
Aber ich überlege mir diese wieder binär in ein nornales File zu schreiben wie es früher mal war.
Dann wurde auf DBF gewechselt und der binäre Datenstring in HEX Schreibweise konvertiert
Danach kam SQL mit den Daten immer noch in Hex Schreibweise.
Aber ich überlege mir diese wieder binär in ein nornales File zu schreiben wie es früher mal war.
Dann wurde auf DBF gewechselt und der binäre Datenstring in HEX Schreibweise konvertiert
Danach kam SQL mit den Daten immer noch in Hex Schreibweise.
Valar Morghulis
Gruss Carlo
Gruss Carlo
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: MessDaten Speichern
Hallo Carlo !
Und einen weiteren Vorteil hast du noch gegenüber deinem bisheriger Verfahren. Zu jedem Messwert den zugehörigen TimeStamp.
In deinem bisherigen Verfahren sind fikive Messwerte drin, wenn du bei Messwerten mit geringeren Abtastraten diese einfach solange übernimmst bis Sie wieder geändert werden ...
=> da passt das MDF-Format wie A.. auf Ei....1. Schnelle Auswertung
2. kleine Rechnerbelastung
3. kleine Datei
Und einen weiteren Vorteil hast du noch gegenüber deinem bisheriger Verfahren. Zu jedem Messwert den zugehörigen TimeStamp.
In deinem bisherigen Verfahren sind fikive Messwerte drin, wenn du bei Messwerten mit geringeren Abtastraten diese einfach solange übernimmst bis Sie wieder geändert werden ...
--
Hans-Peter
Hans-Peter
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: MessDaten Speichern
Hallo Hans-Peter
genau so ist es. Die "fiktiven" Messwerte beginnen zu "stören" natürlich könnte in der Werte Datei gesucht werden das ist aber zu rechenintensiv deshalb der Wunsch nach einem Timestamp.
MDF-Formt klingt mal gut.
gibt es da eine gute Seite mit passenden Infos?
ode gar eine DLL die eingebunden werden könnte?
genau so ist es. Die "fiktiven" Messwerte beginnen zu "stören" natürlich könnte in der Werte Datei gesucht werden das ist aber zu rechenintensiv deshalb der Wunsch nach einem Timestamp.
MDF-Formt klingt mal gut.
gibt es da eine gute Seite mit passenden Infos?
ode gar eine DLL die eingebunden werden könnte?
Valar Morghulis
Gruss Carlo
Gruss Carlo
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: MessDaten Speichern
Hallo Carlo !
Um es vorweg zu sagen. Das MDF-Format kann sehr, sehr viel, ist dadurch aber auch sehr komplex.
Das ist nicht mal eben so eingebaut.
Die ASAM-Seite ist für das Format zuständig; Zugriff auf tiefergreifende Infos haben nur zahlende Benutzer
Fürs ältere MDF-Format 3.0 habe ich ein PDF dazu:
Um es vorweg zu sagen. Das MDF-Format kann sehr, sehr viel, ist dadurch aber auch sehr komplex.
Das ist nicht mal eben so eingebaut.
Die ASAM-Seite ist für das Format zuständig; Zugriff auf tiefergreifende Infos haben nur zahlende Benutzer
https://www.asam.net/standards/detail/mdf/wiki/MDF-Formt klingt mal gut.
gibt es da eine gute Seite mit passenden Infos?
https://www.turbolab.de/mdf_libf.htmode gar eine DLL die eingebunden werden könnte?
Fürs ältere MDF-Format 3.0 habe ich ein PDF dazu:
--
Hans-Peter
Hans-Peter
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: MessDaten Speichern
Danke Hans-Peter
Die Spezifikation zeigt einiges.
Die DLL's auf der Turbolab Seite habe ich mir zu "Gemüte" geführt.
Sehe ich das richtig; Gleichzeitiges Lesen und Schreiben ist nicht möglich.
Ein Programm schreibt alle Daten in die Datei andere Programme lesen nur Daten z.B. zeig mir Drehzahldiagramm Motor 23 der letzten 30 Minuten.
Geht nach meiner Aufffassung dann nicht? Arbeitest du mit dem Format?
Die Spezifikation zeigt einiges.
Die DLL's auf der Turbolab Seite habe ich mir zu "Gemüte" geführt.
Sehe ich das richtig; Gleichzeitiges Lesen und Schreiben ist nicht möglich.
Ein Programm schreibt alle Daten in die Datei andere Programme lesen nur Daten z.B. zeig mir Drehzahldiagramm Motor 23 der letzten 30 Minuten.
Geht nach meiner Aufffassung dann nicht? Arbeitest du mit dem Format?
Valar Morghulis
Gruss Carlo
Gruss Carlo
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: MessDaten Speichern
Hallo Carlo !
Beim Test auf Prüfständen fährt man eine gewisse Zeit und schreibt dabei die Daten in die MDF-Datei.
Je nach System, zb. das Applikations-System INCA, schreibt auf Anforderung für einen Betriebspunkt in eine Datei.
Im nächsten Betriebspunkt in eine weitere Datei deren Name automatisch hochgezählt wird.
Für das MDF-Einsatzgebiet im Automotive-Bereich, besteht nicht die Notwendigkeit einer permanenten Messung.
Dazu verwende ich entweder meine eigene Low-Lovel-Funktion in VFP oder den Umweg über MatLab.
Hmm, kann ich dir nicht sagen.Sehe ich das richtig; Gleichzeitiges Lesen und Schreiben ist nicht möglich.
Beim Test auf Prüfständen fährt man eine gewisse Zeit und schreibt dabei die Daten in die MDF-Datei.
Je nach System, zb. das Applikations-System INCA, schreibt auf Anforderung für einen Betriebspunkt in eine Datei.
Im nächsten Betriebspunkt in eine weitere Datei deren Name automatisch hochgezählt wird.
Für das MDF-Einsatzgebiet im Automotive-Bereich, besteht nicht die Notwendigkeit einer permanenten Messung.
Ja, ich lese und werte Messdaten von INCA im MDF-3-Format aus.Arbeitest du mit dem Format?
Dazu verwende ich entweder meine eigene Low-Lovel-Funktion in VFP oder den Umweg über MatLab.
--
Hans-Peter
Hans-Peter
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: MessDaten Speichern
Hallo Hans Peter
Das MDF Format ist für den Anwendungfall nicht geeignet.
Ich erarbeite mir jetzt ein neues Abbild und gehe mit der Messwertspeicherung zurück auf Binäre Files. Beim Lesen der Doku kam mir die Idee um die Sorgen die wir mit den Binären Files hatten zu lösen. Evtl. mit komprimierung eines Teils des Datensatzes wie es auch unter HTML gemacht wird.
Komprimiert könnte auch zu jedem Wert ein Timestamp gespeichert werden und die Datei ist noch immer viel kleiner als mit der Datenbank.
Das bin ich jetzt am testen.
Das MDF Format ist für den Anwendungfall nicht geeignet.
Ich erarbeite mir jetzt ein neues Abbild und gehe mit der Messwertspeicherung zurück auf Binäre Files. Beim Lesen der Doku kam mir die Idee um die Sorgen die wir mit den Binären Files hatten zu lösen. Evtl. mit komprimierung eines Teils des Datensatzes wie es auch unter HTML gemacht wird.
Komprimiert könnte auch zu jedem Wert ein Timestamp gespeichert werden und die Datei ist noch immer viel kleiner als mit der Datenbank.
Das bin ich jetzt am testen.
Valar Morghulis
Gruss Carlo
Gruss Carlo
- dtmackenzie
- Rekursionen-Architekt
- Beiträge: 265
- Registriert: Do, 22. Nov 2007 9:02
- Wohnort: Leipzig
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 22 Mal
- Kontaktdaten:
Re: MessDaten Speichern
Hallo Carlo,
diese Antwort ist etwas spät, und es ist sowieso ein bisschen fragwürdig, ob es wirklich eine gute Idee ist, Binärdaten in einer SQL-Datenbank zu speichern, aber wenn das erwünscht wäre, dann vielleicht wie folgt (Beispiel für Postgres):
Typ bytea habe ich selber noch nicht benutzt, ist Postgres-spezifisch, in Standard-SQL wäre dies blob.
Das Ganze könnte man verfeinern mit weiteren Tabellen, z.B. für die Geräte und vielleicht für eine Geschichte der Zugriffen.
Für Spalte art könnte man ein Constraint definieren, oder alternativ eine kleine Tabelle haben mit Beschreibungen der Arten.
Aber das Problem hast Du sowieso schon anders gelöst.
diese Antwort ist etwas spät, und es ist sowieso ein bisschen fragwürdig, ob es wirklich eine gute Idee ist, Binärdaten in einer SQL-Datenbank zu speichern, aber wenn das erwünscht wäre, dann vielleicht wie folgt (Beispiel für Postgres):
Code: Alles auswählen
CREATE TABLE messdaten
(
id bigint PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
geraet_nr integer NOT NULL,
art character(1) NOT NULL,
gemessen timestamp with time zone NOT NULL,
letzter_zugriff timestamp with time zone,
werte bytea NOT NULL
)
Das Ganze könnte man verfeinern mit weiteren Tabellen, z.B. für die Geräte und vielleicht für eine Geschichte der Zugriffen.
Für Spalte art könnte man ein Constraint definieren, oder alternativ eine kleine Tabelle haben mit Beschreibungen der Arten.
Aber das Problem hast Du sowieso schon anders gelöst.
Viele Grüße,
David
David
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: MessDaten Speichern
Hallo David
es ist nicht ein bisschen fragwürdig sondern höchst fragwürdig.
Binäre Daten können auch in Postgres nicht direkt gespeichert werden. Alle nicht Druckbaren Zeichen müssen ins Hexformt oder Postgres Escape Format umgewandelt werden. Der Unterschied von ByteA und Character ist eigentlich hauptsächlich der dem Programmierer zu sagen das Feld enthält keinen lesbaren Text .....
Evtl nimmt dir die PGDBU diese Umwandlung automatisch ab, das weiss ich nicht. Wenn du direkt, ohne PGDBU arbeitest musst du dich um diese Umwandlung selbst kümmern.
es ist nicht ein bisschen fragwürdig sondern höchst fragwürdig.
Binäre Daten können auch in Postgres nicht direkt gespeichert werden. Alle nicht Druckbaren Zeichen müssen ins Hexformt oder Postgres Escape Format umgewandelt werden. Der Unterschied von ByteA und Character ist eigentlich hauptsächlich der dem Programmierer zu sagen das Feld enthält keinen lesbaren Text .....
Evtl nimmt dir die PGDBU diese Umwandlung automatisch ab, das weiss ich nicht. Wenn du direkt, ohne PGDBU arbeitest musst du dich um diese Umwandlung selbst kümmern.
Valar Morghulis
Gruss Carlo
Gruss Carlo
- dtmackenzie
- Rekursionen-Architekt
- Beiträge: 265
- Registriert: Do, 22. Nov 2007 9:02
- Wohnort: Leipzig
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 22 Mal
- Kontaktdaten:
Re: MessDaten Speichern
Hallo Carlo,
Du hast Recht.
Und da PGDBE DBF emuliert, gibt es ja auch dort keinen binär-Typ.
Dü könntest vielleicht (klar, rein theoretisch) Postgres Arrays interessant finden (z.B. smallint[]).
Das scheint in Postgres die effizienteste Lösung zu sein für Messdaten, allerdings haben wir dies nicht in Zusammenhang mit Xbase++ benutzt.
Außerdem sind Arrays Postgres-spezifisch, nicht Standard SQL.
https://www.postgresql.org/docs/11/arrays.html
Du hast Recht.
Und da PGDBE DBF emuliert, gibt es ja auch dort keinen binär-Typ.
Dü könntest vielleicht (klar, rein theoretisch) Postgres Arrays interessant finden (z.B. smallint[]).
Das scheint in Postgres die effizienteste Lösung zu sein für Messdaten, allerdings haben wir dies nicht in Zusammenhang mit Xbase++ benutzt.
Außerdem sind Arrays Postgres-spezifisch, nicht Standard SQL.
https://www.postgresql.org/docs/11/arrays.html
Viele Grüße,
David
David
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: MessDaten Speichern
Hallo David
die Lösung mit den Binären Dateien läuft jetzt gut.
Dabei geht es ja auch darum alle Daten im Rohformat, Binär, in Big- oder Little Endian, eben so wie sie gelesen werden zu speichern ohne sie zu bearbeiten.
die Lösung mit den Binären Dateien läuft jetzt gut.
Dabei geht es ja auch darum alle Daten im Rohformat, Binär, in Big- oder Little Endian, eben so wie sie gelesen werden zu speichern ohne sie zu bearbeiten.
Valar Morghulis
Gruss Carlo
Gruss Carlo