Zitat:

---

Original geschrieben von Oliver Arend
CSV ist doch auch ein schön "standardisiertes" Format und dazu erheblich menschenlesbarer und weniger datenintensiv als XML. Viel mehr als die Spaltennamen und dann einfach die Daten hintereinander weg brauchen wir doch nicht? Alles andere könnte man in Kommentarzeilen über den eigentlichen Datensatz in Klartext schreiben (z.B. Informationen zum Treibsatz wie Name, Masse, usw.).
Oliver

---

CSV kennt sehr wohl Dialekte, z.B. waren sich Lotus 1-2-3 und Excel nie einig. Ferner kann man üblicherweise das Trennzeichen definieren, sprich statt Komma auch mal Strichpunkt verwenden, was sinnvoll ist, weil wir ja ein Dezimalkomma haben.

Vor allem aber: CSV ist ein sehr "armes" Format. Nimm einfach mal eine schöne Excel Tabelle, speichere sie in csv und lese diese csv Datei hinterher wieder ein. Du wirst alle Formatierungen, Farben etc, verloren haben. Also ist csv kein taugliches Gebrauchsformat. Und als "Urformat" könnte man auch wie Neil vorschlägt blanken Text nehmen.

Auf einen ganz wichtigen Punkt will ich an dieser Selle noch hinweisen: Wie speichern wir eigentlich die Messdaten? Die bisherige Diskussion (Text, csv, Excel..) setzt stillschweigend voraus, daß die einzelnen Werte als textuelle Ziffen abgelegt werden. Nur dann sind sie "menschenlesbar". Ich mache das in meinem Format ganz anders: Ich speichere die Zahlen in je zwei Byte, also binär.

Nun kann man ja sagen, das sei nicht menschenlesbar. ABER: Wenn ihr eure Text-bzw. csv Dateien erst mal in Excel gespeichert habt, dann ist da auch nichts mehr lesbar. Dann seid ihr komplett abhängig von einem kommerziellen Produkt, und die Excel .xls Datei ist nichts als eine binäre Black Boxdatei für euch.

Geändert von Peter am 22. April 2008 um 13:04

Hi,

ich will nicht Textdateien haben um diese in Excel lesen zu können. Ich will Textdateien haben damit ich die selber lesen kann als Mensch. Wenn jemand auf die Idee kommt und seine eigene Software schreibt, ist es sehr hilfreich wenn man selber lesen kann was da in der Datei steht. Kann man es nicht, weiß man nicht ob die falschen Werte aus der Datei oder dem Lesevorgang stammen. Deswegen will ich menschenlesbare Daten haben. Da Speicher kein Problem ist, wäre ich für Klartext.
Das mit dem Trennzeichen kann man später einführen. Evtl. sogar in der Software auswählbar oder am Anfang einmal definiert.

Gruß

Neil

Zitat:

---

Original geschrieben von Neil
ich will nicht Textdateien haben um diese in Excel lesen zu können. Ich will Textdateien haben damit ich die selber lesen kann als Mensch. Wenn jemand auf die Idee kommt und seine eigene Software schreibt, ist es sehr hilfreich wenn man selber lesen kann was da in der Datei steht. Kann man es nicht, weiß man nicht ob die falschen Werte aus der Datei oder dem Lesevorgang stammen.

---

Das klingt zwar auf Anhieb sehr plausibel, aber ganz logisch ist es nicht. Denn Du willst Dich ja nicht damit begnügen, eine endlose Zahlenkolonne zu lesen. Du willst die Werte ja als Kurve dargestellt haben, und du möchtest die Leistungsdaten ausgerechnet bekommen, also Brenndauer, Impuls, Ausströmgeschwindigkeit und was es so gibt.

Die Kernfrage lautet also: Mit welcher Software möchten wir die Daten auswerten? Da gibt es ziemlich genau zwei Möglichkeiten: Entweder mit einer selbst programmierten Auswertungssoftware, oder mit irgendeinem Standardpaket. Das kann Excel sein, das kann auch irgendein universelles Messwerte-Darstellungstool sein, wie es mit der AD-Wandlerkarte des Volksprüfstandes vermutlich mitgeliefert wird.

Egal welche Software, sobald du sie benutzt ist es vorbei mit der menschenlesbaren Datei. Die Software liest deine Textdatei ein, und was sie daraus macht, kannst du zunächst nicht kontrollieren, jedenfalls nicht so einfach.

Anscheinend befürchtest du "falsche Daten" z.B. aus dem Lesevorgang. Aber wenn das eintritt, hilft dir kein menschlenlesbares Format, sondern du mußt das eigentliche Hardware- oder Übertragungsproblem lösen.

Ein PS3 Datensatz besteht z.B. aus rund einem halben MB. Bei 2,5s Brenndauer und knapp 40k Messungen pro Sekunde sind es allein 100.000 kurvenrelevante Zahlen- einhunderttausend! Glaub mir, die möchtest Du nicht im Ernst manuell durchblättern, um einzelne, falsche Werte zu finden. Ich lasse mir sofort die Kurve anzeigen, und wenn da falsche Daten wären, würde das z.B. als auffällige Sprünge in der Kurve erscheinen.

Aber da sind auch keine "falschen Werte". Sobald die PS3 Datei aufs Byte genau so groß geworden ist, wie man das erwartet, muß die Übertragung vom Prüfstand ziemlich korrekt gewesen sein. Und wenn dann noch eine plausible Kurve angezeigt wird, interessieren mich die Einzelwerte in einer Tabelle nicht die Bohne mehr.

Geändert von Peter am 22. April 2008 um 15:10

Zitat:

---

Anscheinend befürchtest du "falsche Daten" z.B. aus dem Lesevorgang. Aber wenn das eintritt, hilft dir kein menschlenlesbares Format, sondern du mußt das eigentliche Hardware- oder Übertragungsproblem lösen.

---

Das beziehe ich nur auf den Zeitraum der Entwicklung des Prüfstandes und der eigenen Software. Deine Werte ergeben keine Kurve obwohl doch eine da sein müßte. Wo verschwindet die Kurve? Wenn man die Datei lesen kann, hat man es deutlich einfacher.
Ja und es gibt auch welche die sich Seitenweise die Werte manuel anschauen. Was man da alles für Softwarebugs heraus finden kann glaubst du nicht. Nicht umbedingt bei Motorprüfständen, sondern auch bei anderen Messgeräten.
Im übrigen bekommt man bei Excel bei einem so großen Datensatz wie du ihn beschreibst Probleme. Excel kann nur maximal 2^16 Zeilen darstellen. Aber mal eine Gegenfrage, wenn du mit 40kHz sampelst, und du dir nicht jeden einzelnen Messwert anschaust, warum machst du dann soviele davon ;-)

Und nochmal anders herum gefragt, was schadet denn an einer Klartextdatei so sehr das man lieber eine verschlüsselte Binärdatei haben möchte?

Gruß

Neil

Zitat:

---

Original geschrieben von Neil
Das beziehe ich nur auf den Zeitraum der Entwicklung des Prüfstandes und der eigenen Software.

---

Dann geht es da speziell um Deine Entwicklungsumgebung, aber die ist nicht maßgeblich für den Dauerbetrieb. Denn irgendwann laufen Hard- und Software. Wenn ich Fehler suche, dann lasse ich statt des kompilierten Programms den Quellcode laufen und genieße den darin enthalten Luxus- damit kann keine Textdatei konkurrieren.

Zitat:

---

Im übrigen bekommt man bei Excel bei einem so großen Datensatz wie du ihn beschreibst Probleme. Excel kann nur maximal 2^16 Zeilen darstellen.

---

Sehr richtig. Das ist einer von mehreren, schwerwiegenden Gründen, sich nicht auf Excel zu verlassen.

Frage an dieser Stelle: Können wir uns darauf einigen, daß wir zur Auswertung nicht Excel nehmen, sondern selbst erstellte, für diesen Zweck optimierte Programme?

Zitat:

---

Aber mal eine Gegenfrage, wenn du mit 40kHz sampelst, und du dir nicht jeden einzelnen Messwert anschaust, warum machst du dann soviele davon ;-)

---

Doch, ich schau mir jeden Wert an- aber nur als Meßpunkt auf der Kurve. Die einzelnen Messwerte sind ohne große Bedeutung.

Zitat:

---

was schadet denn an einer Klartextdatei so sehr das man lieber eine verschlüsselte Binärdatei haben möchte?

---

Ich glaube, da tut sich ein Erfahrungsunterschied zwischen "Jungprüfständlern" und "Altprüfständlern" auf. Alles, was Du da forderst, hatte ich mir vor sehr langer Zeit als unbedingt notwendig vorgenommen: Zeitmarken, menschenlesbare Textdateien usw. Im Lauf der Jahre bin ich von alledem abgekommen.

Früher nannte ich mein "Urformat" .232, und diese Datei speicherte alles, was direkt aus Winfrieds Prüfstand kam. Diese Datei hat mein Programm eingelesen und zusammen mit allen Parametern in eine "menschenlesbare" .CRS Datei geschrieben. Ich war ziemlich genau da, wo Du hinwillst. Ich hab mich aber weiter entwickelt. Ich habe die "menschenlesbaren" Dateien nicht mehr gelesen- wozu denn? Ein Bild sagt mehr als 1000 Zahlen, also hat mich die Schubkurve interessiert. Und natürlich sind auch die errechneten Leistungsdaten ganz extrem wichtig. Beides zusammen beschreibt den Motor und gibt mir die Informationen, die ich wissen will. Ich habe keine Zeit, lange über einer Zahlenkolonne zu meditieren, dann steht auch schon der nächste Test an- wie in Edenkoben zum x-ten Mal demonstriert.

Mit der Trennung zwischen .232 und .CRS Format bin ich in eine Falle gelaufen: Als Winfried die nächste Generation Prüfstand auflegte, paßte mein CRS Format überhaupt nicht, und ich mußte längere Zeit beide Formate parallel pflegen. Das ist die größte Dummheit, die man begehen kann. Irgendwann reichte es mir, und ich habe alles dem neusten, binären Prüfstandformat angeglichen. Damit konnte ich plötzlich bequem Schubkurven überlagern, die ursprünglich unter ganz verschiedenen Formaten gespeichert worden waren.

Ich bin mit diesem neuen "PS3-Format" auch gut gerüstet für den nächsten Prüfstand, den Winfried möglicherweise baut. Der wird dieses Binärformat wieder verwenden, vielleicht um einige Parameter erweitert, aber dafür haben wir im Format "Puffer" vorgesehen.

Es ist einfach unrealistisch, dem Prozessor des Prüfstands bzw. eines Datenloggers "menschenlesbaren Text" oder gar etwas uferloses wie "XML" aufnötigen zu wollen. Prozessor = Binärformat, diese Gleichung ist realistisch.

Geändert von Peter am 22. April 2008 um 17:59

Zitat:

---

Doch, ich schau mir jeden Wert an- aber nur als Meßpunkt auf der Kurve. Die einzelnen Messwerte sind ohne große Bedeutung.

---

Bei 100.000 Punkten mußt du aber einen verdammt breiten Monitor haben. Wenn ich dann noch überlege das mal einer mit einem Laaaaaanbrenner vorbei schaut

Ich habe die Erfahrung gemacht, das man öfters als man denkt in die Dateien schauen muss. Daher finde ich eine Klartextdatei immer noch besser. Die von dir aufgeführten Nachteile sehe ich nicht. Warum sollten bei einem Klartext Probleme auftreten die es in einer Binärdatei nicht gibt. Könnte ich binär lesen, wäre das ja auch eine Klartextdatei. Es ist nur eine Frage der Interpretation. Daher glaube ich, das nicht der Klartext das Problem ist (das ist nur eine andere Darstellung der gleichen Information), sondern das der Aufbau deiner Datei fehlerhaft war. Daher meine Frage, was geht in einer Klartextdatei nicht, was in einer Binärdatei geht?

Zu Excel. Wir sollten uns in der Tat nicht darauf fest legen das die Datei in ihrer maximalen möglichen ausführung in Excel geladen werden kann. Aber wenn es machbar ist das es geht, wäre es ja kein Beinbruch.

Ich habe so die Vermutung, das du dir viel Arbeit sparen willst und uns deinen Standard aufzwingen willst

Gruß

Neil

@Peter:
Schon richtig, ich habe auch schon Software geschrieben, bei der Nicht-Binärformate nur in Speicherplatzverschwendung resultieren, aber:
Binärformate haben den Nachteil, nur schlecht erweiterbar zu sein, nicht umsonst hat Microsoft inzwischen seine alten Dokumentformate aufgegeben und einen auf (MS)XML basierten Nachfolger geschaffen. Bei XML kannst du jederzeit erweitern wie du willst, eine Software die bestimmte Tags nicht zuordnen kann, ignoriert sie einfach weil sie sie nicht "sieht".
Und es gibt sicherlich für die meisten Programmiersprachen Open-Source-XML-Parser, als Betrachter kann ich z.Bsp den XML Viewer von mindfusion empfehlen.

mfG
Markus

PS: Ich würde auch unterscheiden zwischen dem Datenübertragungsprotokoll des Prüfstandes und dem Format, in dem die Daten gespeichert werden. Hier reicht vermutlich schon ein intelligent ausgelegtes Protokoll, um alle Informationen getrennt voneinander zu erfassen, was die Software nicht kennt, liefert sie nicht, will sie etwas vom Prüfstand was dieser nicht kennt, teilt er das eben mit.

Edit: @Neil: Excel würde ich von vornherein höchstens als Zaungast betrachten ... für solche Zwecke ist es weder gedacht noch geeignet.

Geändert von MarkusJ am 22. April 2008 um 18:10

Zitat:

---

Original geschrieben von Neil
Daher glaube ich, das nicht der Klartext das Problem ist (das ist nur eine andere Darstellung der gleichen Information), sondern das der Aufbau deiner Datei fehlerhaft war.

---

Weder noch. Der Fehler lag darin, das Urformat und das Gebrauchsformat trennen zu wollen. Was ich gelernt habe ist dies: Nimm möglichst schon das Urformat als endgültiges Gebrauchsformat.

Wenn Du einen Motor in der hohlen Hand hältst, ihn abbrennen läßt und hinterher wortlos die richtige Schubkurve an die Tafel zeichnest, dann kannst Du dir aussuchen, welches Format du möchtest. Da aber nur der Prozessor dieses Kunststück mit der gezeichneten Kurve beherrscht, darf ER es sich wünschen. Und analog zu Whiskas gilt:

Prozessoren würden binär kaufen!

Geändert von Peter am 22. April 2008 um 18:30

Hi,

ich gehe jetzt mal davon aus dass es sich hierbei um ein offenes Format zum Austausch zw. Fliegern in einer mehr oder weniger heterogenen Umgebung dient. In diesem Fall bin ich dafür dass die Messdaten inkl. Zeitmarken in Textform vorliegen und es sich dabei um Werte in SI Einheiten handelt. (Nein, ich will damit nicht Peter ärgern )

Die Gründe dafür sind relativ einfach. Derart kodierte Messdaten kann man mit einer Vielzahl von Softwarewerkzeugen (Excel, Matlab, Origin, Gnuplot, LabVIEW,...) ohne Probleme verwenden und das Format wird zu einem gewissen Grade selbsterklärend. Jeder kann ohne große Probleme die Daten auch manuell oder teilautomatisch verarbeiten. Damit gewinnt das Format sehr stark an universeller Verwendbarkeit. Mit einem Binärformat zieht man sich hingegen ohne zwingenden Grund auf eine proprietäre Insel zurück.

Zu den SI Daten brauche ich wohl nicht viel sagen, die sind der etablierte Standard. Es spricht nichts dagegen wenn eine SW die Daten auch in kp oder lbf darstellen kann, aber in einem "Standardformat" haben solche Einheiten imho nichts verloren.
Eine alternative Möglichkeit zur Speicherung im SI-Format ist es direkt die Rohdaten aufzuzeichnen. Dann muss man sich aber Gedanken über die Speicherung der Kalibrierungsinformationen machen. Das wirft aber weiter Probleme auf. Es gibt nämlich mehrere Arten dies zu tun. In den meisten Fällen reichen wohl die 2 Koeffizienten einer linearen Funktion, aber es kann unter Umständen sinnvoll sein eine komplexere Funktion oder eine Kalibriertabelle zu verwenden. Das kann man zwar auch allgemein kodieren, aber es macht das Format komplexer und auch die Auswertung merklich komplexer. Im Austauschformat würde ich das eher nicht tun, aber das ist nur meine Meinung.

Für das Format in dem die Daten letztendlich gespeichert werden kommen mir zumindest 2 Varianten in den Sinn.
A)
Ein einfaches Textfile. Es beginnt mit dem Header in dem die Metainformationen (Name, Datum, Treibstoff,...) gespeichert werden. Nach dem Header kommen die Messkurven. So machen es auch die ganzen Messsysteme auf der Uni mit denen ich bis jetzt zu tun hatte.
B)
Ein komprimiertes Archiv dass die Daten in unterschiedlichen Dateien enthält. Das Vorbild für diese Idee ist z.B. das Datenformat das von Open Office genutzt wird, aber es gibt auch andere Programme die es so machen. Im einfachsten Fall enthält dieses Archiv u.a. ein Indexfile. Dieses verweist auf die anderen Dateien, z.B. eine für die Metadaten und eine für die Messkurven. Diese simple Variante bringt noch nicht viele Vorteile gegenüber Variante A), außer ein wenig Platzersparnis. Der Vorteil daran wäre dass man ein derartiges Format ohne Probleme "aufblasen" kann, wenn man es richtig macht sogar ohne dass man ältere Software damit aus dem Konzept bringt. Die Art der Zusatzinformationen die man so unterbringen kann ist sehr vielfältig. Beispiele wären: zusätzliche Rohdaten, mehrere Messungen in einem File oder multimediale Inhalte. Diese Variante ist natürlich, je nach gewünschter Funktionalität, aufwendiger zu implementieren.

In beiden Fällen ist es für die reinen Messdaten wohl am einfachsten sie in einem simplen Textformat zu speichern, z.B. Tabulatorgetrennte Werte. Bei Index und Metadaten denke ich mir aber dass eine Markupsprache wie XML keine schlechte Idee wäre. Man kanns natürlich auch simpler angehen, wie es z.B. bei .ini Dateien der Fall ist.

Variante A) ist eine simple Standardlösung, geradlinig und vielfach bewährt. Variante B) ist dafür bedeutend flexibler, was aber nur Sinn macht wenn man solche Zusatzfunktionen wirklich nutzen will.

Gruß
Reinhard

Aaaallllsooooo....

Nun muss ich auch mal meinen Senf dazugeben ...

Wir sprechen hier von einer "Auswertsowtware" und "Gebrauchsdaten" usw ...

Was ist den mit der Kompatiblität zwischen den einzelnen Prüfständen ??

Also meisst wird dieses über einen KLEINEN µC realisiert ... oder ??

Von dieser Seite aus gesehen sollten wir uns ersteinmal einig darüber sein, wie die Daten AUS dem Prüfstand IN eine Software XYZ kommen ...

Da die heutigen A/D Wandler mit einer hohen Auflösung immer günstiger werden, und 16Bit schon zum "Alltäglichem" gehört.. 20 Bit sind am kommen, und 24Bit sollte sie ausgeben. Das macht dann 3 Byte...

Hinzu müssen auf jeden Fall die Zeitmarken, wofür ich auch mindestens 2 Byte deklarieren würde.

Weiterhin würde ich 1 Byte aufteilen, wobei das hochwertige Nibble (4Bit) für die Messung und das niederwertige Nibble für den Kanal steht. Macht 1Byte

Abschließend sollten auf JEDEN Fall 4 Bytes für "Messtandtechnische" Parameter ausgegeben werden, die wenn nicht benötigt auf 0 gesetzt werden. Diese 4 Bytes könnte man "einfach" als Tabelle in einer Software anzeigen, wober der/diejenigen die den Prüfstand entwickelt haben mit einem Häckchen oder Kreuz umgehen können.

Rechnen wir mal zusammen: 3Bytes Daten, 2Bytes Messwerte, 1Byte Kanal, 4Bytes Parameter = 10Bytes

Das klingt nun ziemlich "Overszised" 10Bytes PRO Messwert, aber ich denke das wir dafür gut für die Zukunft gerüstet sind.

Weiterhin halte ich es für sicher notwendig einen "Header" mit auszugeben, welcher den Prüfstand (1Byte), das Datum (8Byte in DEZIMALER Schreibweise), und die Umgebungstemperatur (4Bytes) mit ausgeben. Diese Liste kann natürlich noch um das eine oder andere Byte erweitert werden.

Was soll mit "nicht genutzten" Daten passieren ??? ---> einfach Nullen ....

Wie erkennen wir das Ende einer Messkurve? --> Kanal = 0 und Messwerte = 0

Die Übertragunsrate sollte mit 115000 Baud auf jeden fall stattfinden können (gewünscht) und mindestens mt 9600 erfolgen.

Als Übertragung sollte weiterhin die RS-232 Schnittstelle dienen, da fast alle "Hardwareuser" einen entsprechenden Wandler zur verfügung haben

Dieses ist mein "Vorschlag" für die "Rohdaten" aus dem Prüfstand... was dann die Software speichert ... das überlasse ich den "Softwerkern"

viele Grüße
Pierre