Zitat:

---

Original geschrieben von Andreas Mueller
Die Graphik hat eine Auflösung von ca 0.2ms, d.h. alles was man dort sieht, hätte man auch mit einer Samplingrate von 5kHz gesehen.

---

Äh- und was will uns der Künstler damit sagen? Sollen wir die Messrate der Prüfstände so zurückschrauben, daß sie ein Ereignis bestenfalls als vagen Zappler wahrnehmen können?

Nach dieser Logik bitte alle Digitalkameras wegwerfen, denn es genügt, wenn man die startende Rakete statt mit 8 Megapixel mit 8 Pixel fotografiert. Kaum hat man einem solchen Foto über ein dreizeiliges Pearl Script die numerische Integrationsfunktion unterlegt, heissa, schon ist signifikant nachgewiesen, daß startende Raketen einen vagen Hell-Dunkeleindruck auf den 8 Pixeln hinterlassen?

Ich glaube, ich hatte die ursprüngliche Intension dieses Threads gar
nicht verstanden. Es sollte wohl gar nicht darum gehen, ob eine Aufnahmerate
von 1000, 10000 oder 40000 Samples pro Sekunde nötig sind oder ob
irgendwelche Resonanzen ausreichend gedämpft werden. Es geht vielmehr
um eine Standardisierung von Prüfstandsdaten - und das ist ein wirklich
erstrebenswerter Ansatz.
Wenn wir ein einheitliches Datenformat für Prüfstandsdaten definieren
würden, könnten wir problemlos Daten aus unterschiedlichen Programmen, die
diesen Standard nutzen, austauschen und verwenden. Ich denke da an die
Auswerte-Software für die Prüfstands-Daten, an Flugbahn-Berechnungen oder
gar ein Vergleich von gemessenen Schubkurven mit Kurven aus Simulationen.
Wie können wir ein einheitliches Datenformat für Prüfstandsdaten finden?
Dazu sollten wir erstmal die Anforderungen an dieses Format zusammenstellen.

Ein Ziel wäre, nicht immer alle Daten in einer Treibsatz-Datei zur Verfügung
zu stellen, sondern die vorhandenen Daten in der Datei so zu kennzeichnen,
dass verschiedene Anwendungen nur die speziell benötigten Daten finden und
lesen und eventuell neu berechnete Daten eintragen können.

Welche Daten müssten als Minimal-Datenstamm immer vorhanden sein?
Wie könnte eine Kennzeichnung von Daten/Datenblöcken aussehen?
Welche Daten müssten gespeichert werden können?

Dieses Format sollte Feststoff-, Hybrid- oder Flüssig-Antriebe erfassen
können wie auch Daten von Wasserraketen.

Was fällt euch noch ein?

Oli

Hi,

ich würde ein Format wählen was auch excel verstehen kann. Es kann z.B. so sein, das die Spalten durch ein";" getrennt werden und zeilen durch einen Zeilenumbruch. Die Datensätze sind in Klartext abgelegt, das bedeutet, man kann das auch mit irgendeinem Editor öffnen und sofort die Tabelle lesen.
Man sollte auch ein Format vorgeben wie Zahlen geschrieben werden.
Jetzt kommt ein Problem hinzu. Die Samplerate. Je höher desto besser, doch haben einige Programme Probleme eine Kruve mit einigen tausend Punkten zu lesen. Manchmal wird sogar nur eine stilisierte Kurve abgelegt. Aber ich denke das ist ein Problem der Software. Evtl. muss eben ein Übersetzter gerschrieben werden.
Hier mal ein Beispiel



Wie man sieht, kann man alles lesen. Die Einheiten sind Sekunde und Newton. Neben den Spalten mit den Zeitwerten und dem Schub, ist eine Spalte wo von oben nach unten alles weitere rein geschrieben werden kann. Z.B: sowas wie Motordaten oder Daten zu der Messung. Da diese daneben stehen, ist das Format gleich so, das Excel das lesen kann oder auch jedes andere Programm.
Da führende und folgende Nullen ausgeschrieben werden, kann man selber mit einem einfachen Programm die Daten heraus suchen die man braucht.
Die Anzahl der Vor- und Nachkommastellen sollte reichen oder? Bei sehr hohen Sampleraten kommt man schon mal in den Bereich der 1/10.000 Sekunde. mN für die Kraft sollte auch reichen.
Bei den Zusatzdaten sind Infos über Samplerate und Kraftaufnehmer Genauigkeit wichtig.

Gruß

Neil

Geändert von Neil am 06. Oktober 2006 um 14:33

Hi Neil,

warum eine feste Angabe der Vor- und Nachkommastellen? Beschränkt etwas, daß man nicht beschränken muß.

Was ich nicht verstehe sind die Kommentare. Soll für jeden Meßpunkt ein Kommentar möglich sein, oder sind mehrere Messungen in einer Datei? Wo steht der Motorname?

Stelle gerne ein Python-Programm als Basis zur Weiterentwicklung zur Verfügung, daß die Daten einliest und diverse Berechnungen damit anstellt, wie z.B. Reduktion der Anzahl der Meßwerte für "schnelle" Sensoren und die Daten formatiert wieder ausgibt.

Das ist wirklich kinderleicht zu verstehen und anzupassen und läuft auf ALLEN Plattformen.

Userinterface ist dabei das aufwendigste, wird also eine Kommandozeilenapplikation. Wenn jemand Blut leckt könnte er ja auch ein Userinterface dazu bauen...

edit: Jetzt glaube ich zu verstehen. Uhrzeit, Datum und Kommentar sind in mehrere Zeilen aufgesplittet...
Für die maschinelle Verarbeitung suboptimal.
Ein Format wie im HTTP-Header mit "Keyword: wert " ware besser,
z.B.

Zeit (s); Schub (N); Header/Kommentar
0; 0; Datum: 2007-01-01 17:15:55
0.1; 0; Temperatur: 10°C
0.2; 10; Luftdruck: 1000mBar
0.3; 20;
0.4; 50; Nach einem leeren "Header" fangen die echten Kommentare an
0.4; 50; bla blub



Grüße
Malte

Geändert von hybrid am 06. Oktober 2006 um 15:36

Hi,

die Kommentare stehen nicht über oder unter den Messdaten sondern daneben. Wobei nicht jede Messzeile einen Kommentar haben muss.
Die Idee der festen Breite basiert darauf, das man später mit einer Stringextraktionsroutine die einzelnen Datensätze heraus schneiden kann. Man weiß wo in der Zeile was steht und muss nicht erst nach dem Semikolon suchen.
Das könnte dann so aussehen:

Schub = extrakt(Zeile,10,20)

Bei diesem Beispiel stehen die Werte für den Schub in ab dem Zeichen 10 und enden am Zeichen 20 in der Zeile n.
So wie ich aber deine Routine verstehe, sucht diese ein Semikolon und gut ist. Die würde also über all meine überflüssigen 0 hinwegsehen.
Die Idee hierzu habe ich von den Logfiles der Software der Anlagen die ich mal aufgebaut habe. Kann man gut im Klartext als Mensch lesen und auch die Maschine hat keine Probleme. Wenn man variable Längen für Zahlen vorsieht, macht das zwar der Maschine nichts, im Gegenteil wird sogar die Datenmenge weniger, aber der Mensch hat Probleme das zu lesen.

Vielleicht sollten wir uns erstmal auf Gründlägendes festlegen, sowas wie Einheiten und Trennzeichen.

Gruß

Neil

Geändert von Neil am 06. Oktober 2006 um 16:02

Fixed fomat ist aber wirklich out. Wieviele Stellen willst Du denn vorgeben?
00000.00 ist übrigens deutlich schlechter zu lesen als 0

Die optimale Lösung aus Maschinenlesbar und Menschenlesbar wäre eigentlich rechtsbündig mit Trenner.

Das Einlesen in Excel geht dann ohne Problem und programmtechnisch wäre das etwa so:

zeit, schub, kommentar = zeile.split( ";" )

Damit hätte man alle drei Werte

Deine Idee mit der dritten Spalte hatte ich am Anfang mißverstanden, finde sie aber jetzt gut, wg. excel-Komaptibilität. In Excel wäre die Dritte Spalte nur Text zum Lesen, wenn man die Daten aber per Programm einliest, kann man sie auch gleich als Meta-Daten benutzen, ich würde sie dazu nur etwas abwandeln, so daß die zusammengehörigen Meta-Daten (z.B. Motorname, Datum, Temp. Luftdruck) auch jeweils in einer Zeile stehen, also in der dritten Spalte:

Motor: Name
Datum: 2006-01-01 17:59:01 (das ist das ISO-Format)
Temperatur: 20°C
usw.

Um (einem Programm) klar zu machen, daß irgenwann mal ein Freitext-Kommentar folgt, einfach einmal die Dritte Spalte leer lassen und ab dann die Kommentare...

Anhang: beispiel2.txt

Ich würde natürlich aus Gründen der internationalen Zusammenarbeit und wegen der einfacheren Verarbeitung in Programmiersprachen die Zahlen mit . als Nulltrenner schreiben

Geändert von hybrid am 06. Oktober 2006 um 16:37

Hi,

sehe ich soweit ein. Wenn man aber rechtsbündig schreibt, sollte man zumindest die Nachkommastellen festlegen und mit folgenden 0 auffüllen. Sonst springt das Komma immer hin und her.

Gruß

Neil

Tja, auf wieviele Nachkommastellen?

5 müssen es für die Sekunden mindestens sein, das sieht aber kacke aus. m.E. schlimmer als Springen.

Vielleicht sollte die Vorgabe sein, es in jeder Datei einheitlich zu haben, damit es nicht springt, es gibt aber keine grundsätzliche Vorgabe über die Anzahl der Stellen?!
So sehen die Daten immer gut aus, wir haben aber keine Probleme mit 20kHz Abtastrate...

Geändert von hybrid am 06. Oktober 2006 um 17:19

So, habe es noch mal überarbeitet, nur ganz wenig Fehlerbehandlung drin, es macht aus


Zeit (s); Schub (N); Header/Kommentar
0.0; 0; Motor: pepe blala
0.1; 0; Datum: 2007-01-01 17:15:55
0.2; 10; Temperatur: 10°C
0.3; 20; Luftdruck: 1000mBar
0.4; 50;
0.5; 50; Nur ein kleiner Test
0.6; 50; zum Testen
0.7; 50;

folgendes

Motor <pepe blala> am 2007-01-01 17:15:55 Uhr bei 10°C, Luftdruck 1000mBar
0.00000s: _0.00N
0.10000s: _0.00N
0.20000s: 10.00N
0.30000s: 20.00N
0.40000s: 50.00N
0.50000s: 50.00N
0.60000s: 50.00N
0.70000s: 50.00N
Gesamtimpuls = 23.00N/s (Korrigiert )
Kommentare: Nur ein kleiner Test
zum Testen


(Die _ vor den Zahlen sind nur da, weil die Forensoft zwei Leerzeichen frisst...)

Anhang: schub1.txt (Korrigiert )

Geändert von hybrid am 06. Oktober 2006 um 20:24

Wozu denn das Rad neu erfinden? Welche Informationen sind in den wRASP-Dateien nicht enthalten, die Ihr noch ergänzen wollt? Im Zweifelsfall könnte man die einfach als Kommentarzeilen einfügen und eigene Programme die auch entspr. lesen lassen, während wRASP nur die normalen Datenzeilen erfasst.

Oliver