Edenkoben hat einen Trend fortgesetzt, den ich schon länger beobachte: Es gibt immer mehr Bestrebungen, Motorprüfstände zu bauen- einfach deshalb, weil es auch immer mehr Bedarf dafür gibt. Und weil die wenigsten, die so ein Gerät gerne hätten, es auch selbst bauen können, wächst der Wunsch nach Zusammenarbeit.

Das geht in zwei Richtungen: Für die Hardware kann man sich den Volksprüfstand überlegen. Das wäre aber Thema für eine gesonderte Diskussion. Mir geht es hier um die Software. Oliver und ich haben schon öfter darüber diskutiert, und ich finde, das könnte man auch öffentlich tun.

Also: Egal wie die Hardware eines Prüfstands aussieht, irgendwann werden die Messdaten unweigerlich in einer Datei landen. Die ganz zentrale Frage lautet: Wie soll das Formt dieser Datei aussehen? Eines ist klar: Wenn zehn Gruppen so vor sich hin basteln, kommen auch zehn verschiedene Lösungen heraus. Dann ist niemand mit nichts kompatibel.

Viel praktischer wäre es doch, wir könnten uns hier auf ein gemeinsames Datenformat einigen, das jeder neue Prüfstand unterstützt. Der Name für dieses Format drängt sich fürmlich auf, finde ich: .rmb. Was man auch als Raketen-Motorendaten-Beschreibungsformat lesen kann. So, der schwierigste Teil wäre eigentlich geschafft , gehen wir den Rest an:

Bei einem solchen Prüfstandsformat treten verschiedene Knackpunkte auf, und zu jedem dieser Punkte kann man aus guten Gründen unterschiedlicher Meinung sein. Zum Beispiel:

a) Zeitmarken ja oder nein?
Soll jeder einzelne Messpunkt mit einer Zeitmarke versehen werden, evtl noch mit weiteren Marken für Meßkanal usw.? Oder sollen die Messpunkte kompakt hintereinandergeschrieben werden, die Zeit ergibt sich aus der Position jedes Messpunktes?

b) Wie sollen mehrere Messkanäle verwaltet werden?
Angenommen, wir messen Schub und Brennkammerdruck, beides mit unterschiedlicher, zeitlicher Auflösung. Wie gehen wir damit um?

c) Wie verwalten wir die vielen, zusätzlichen Parameter?
Es gibt mindestens zwei Gruppen von Parametern: interne und externe. Die internen sendet -vielleicht- der Prüfstand: Messrate, Eichparameter, etc. Die externen Parameter fügt der auswertende Mensch nach Lust und Laune hinzu. Wie hoch das Treibstoffgewicht war, ist sehr wichtig, aber für das Funktionieren des Prüfstands selbst völlig egal.

Was meint ihr?

Geändert von Peter am 21. April 2008 um 22:43

Zitat:

---

Original geschrieben von Peter

a) Zeitmarken ja oder nein?
Soll jeder einzelne Messpunkt mit einer Zeitmarke versehen werden, evtl noch mit weiteren Marken für Meßkanal usw.? Oder sollen die Messpunkte kompakt hintereinandergeschrieben werden, die Zeit ergibt sich aus der Position jedes Messpunktes?

b) Wie sollen mehrere Messkanäle verwaltet werden?
Angenommen, wir messen Schub und Brennkammerdruck, beides mit unterschiedlicher, zeitlicher Auflösung. Wie gehen wir damit um?

---

Hallo Peter,

zu a)
Ich fände es sinnvoll einem Messpunkt die zugehörigen Zeitmarken etc. zuzuweisen
Bspw. wie an einem GPS Empfänger, wenn man ihn nach einem Datensatz fragt und er folgendes antwortet:

$GPGGA,191410,4735.5634,N,00739.3538,E,1,04,4.4,351.5,M,48.0,M,,*45
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | | | | Höhe Geoid minus
| | | | | | | Höhe Ellipsoid (WGS84)
| | | | | | | in Metern (48.0,M)
| | | | | | | | | | | | | Höhe über Meer (über Geoid)
| | | | | | in Metern (351.5,M)
| | | | | |
| | | | | HDOP (horizontal dilution
| | | | | of precision) Genauigkeit
| | | | |
| | | | Anzahl der erfassten Satelliten
| | | |
| | | Qualität der Messung
| | | (0 = ungültig)
| | | (1 = GPS)
| | | (2 = DGPS)
| | | (6 = geschätzt nur NMEA-0183 2.3)
| | |
| | Längengrad
| |
| Breitengrad
|
Uhrzeit


Was hier aber wieder dazu kommt: Viele Zeichen die übertragen werden müssen...
Andererseits könnte man auch mal "ohne" Frontend in die "Kurve" schauen.
Ich denke mal im Zeitalter von schnellen Computern sollte das doch machbar sein. Mann muß ja nicht unbedingt mit 9600 über die serielle Schnittstelle arbeiten.

Zu b)
Man könnte, bei Verwendung eines ähnlichen Formates wie o.g. als erste Ziffernfolge vielleicht den Messkanal angeben ?

Grüße
Tom

Geändert von Tom am 22. April 2008 um 06:56

Hi,

a) Ich bin für Zeitmarken. Ich bin auch dafür das die Datei die zwischen den Programmen kompatibel sein sollte schon auf bestehenden Programmen wie Excel lesbar ist.

b) Pro Kanal eine Spalte. In der ersten Zeile steht die Überschrift. Wenn die Kanäle unterschiedliche Zeitstempel haben, bekommen diese jeweils eine eigene Spalte. Anders geht es ja nicht. Man kann ja nicht einen Messwert einem anderen Zeitpunkt zuordnen nur weil die Software das nicht gebacken bekommt.

c) Die zusätzlichen Parameter würde ich vor der Tabelle schreiben. Da ich meine Auswertung sehr gerne in Excel mache, ist es für mich einfacher das an den Anfang zu packen. Ich bin sogar fast dafür das man die Datei im Klartext schreibt. Das mögen vielleicht nicht viele, hat aber den Vorteil, das ich mal eben so da rein schauen kann, und dann die zusätzlichen Paramter im Header sehe.

Ich würde das hier angestrebte Format unabhänig von dem Datenstrom machen der von der Messelektronik in die Software geht. Speicherplatz ist kein Problem mehr, da kann die Datei so groß sein wie sie muss. Bei dem Datenstrom von der Messelektronik zur Software gibt es aber evtl. zeitliche Gründe die daten klein zu halten.
Edit:
Noch ein Nachtrag. Damit es ein Volksprüfstand wird, sollte das Format so einfach wie möglich gehalten sein, damit so viele wie möglich das Format selber in ihrer Software einbauen können. Was nützt das kompatibelste wenn es keiner hin bekommt.

Parallel zu der Formatsdiskussion sollte noch eine Hardware Diskussion los getreten werden. Evtl. macht es ja Sinn auch die gleiche Elektronik zu haben um auch dort kompatibel zu sein. So muss ja nicht jeder einen Satz Kraftaufnehmer haben wenn andere baugleiche mit unterschiedlichem Bereich haben. Ich erinnere nur an die M6 Befestigung bei den zur Zeit vorhanden Prüfständen. Alle haben bis jetzt eine einizge M6 Schraube womit der Motorhalter am Kraftaufnehmer montiert werden kann. Das ergibt Sinn und macht das Leben leichter.

Gruß

Neil

Geändert von Neil am 22. April 2008 um 07:54

Es wird die Dateien vermutlich extrem aufblähen, aber evtl. sollte ihr ein XML-basiertes Format in Erwägung ziehen

mfG
Markus

Zitat:

---

Es wird die Dateien vermutlich extrem aufblähen, aber evtl. sollte ihr ein XML-basiertes Format in Erwägung ziehen

---

Zitat:

---

Damit es ein Volksprüfstand wird, sollte das Format so einfach wie möglich gehalten sein, damit so viele wie möglich das Format selber in ihrer Software einbauen können. Was nützt das kompatibelste wenn es keiner hin bekommt.

---

Widerspricht sich das nicht irgendwie?

Gruß

Neil

Naja, der Vorteil von XML-Dokumenten ist, dass die XML-Struktur standardisiert ist.
Es gibt für viele Programmiersprachen Sourcecode zum Parsen von XML-Files, und selbst wenn nicht sollte sich das ganze recht schnell durchparsen lassen.
Der Vorteil ist, dass man in XML eigentlich schon mit einem Editor lesen kann, da alles Plaintext ist.

mfG
Markus

PS: Und was den Platzbedarf angeht ... einmal 7Zippen und gut ist.

Hi,

bei dem Platzbedarf sehe ich eher keine Probleme. Es gibt doch schon 19GB USB Sticks.

Gruß

Neil

Zitat:

---

Original geschrieben von MarkusJ
Der Vorteil ist, dass man in XML eigentlich schon mit einem Editor lesen kann, da alles Plaintext ist.

---

Das ist nur "akademisch" betrachtet so, in der Praxis eher nicht, denn:

a) XML neigt dazu, mehr Tags alles alles andere zu enthalten. Folglich sieht man den Wald vor lauter Bäumen nicht mehr. Hinter all dem "Spitze Klammer auf, viel Tag-Text, spitze Klammer wieder zu" muß man förmlich danach suchen, wo er denn steht, der wahre Messwert, der gesuchte Parameter.

b) Es mag ja Fertigkomponenten geben zum parsen von XML, aber damit begeben wir uns in eine Abhängigkeit von Drittanbietern. Für die meisten von uns wären das auch "Black-Box" Module, die sie nicht anpassen könnten.

c) Im Alltag gibt es nichts, was XML sinnvoll anzeigt. Bei Text hast du WordPad oder Notepad, aber bei XML? Denn dazu müßte die anzeigende Software die Tags ausblenden- welches Tool, das jeder von uns auf der Platte hat, tut das schon?


Wir müssen ferner unterscheiden zwischen dem

Urformat, so möchte ich das mal nennen, mit dem der Prüfstand/der PC die Daten gleich während der Aufzeichnung speichert, und dem

Gebrauchsformat das dann entsteht, wenn ein geeignetes Auswerteprogramm die Daten liest und danach wieder speichert.

Beispiel: Der Prüfstand könnte einfaches Textformat ausgeben (Urformat), das tust du in Excel packen und wenn du dort speicherst, dann üblicherweise als .XLS Format. Beide unterscheiden sich ganz erheblich, XLS ist ein vertracktes Binärformat, das alle paar Versionswechsel anders aussieht.

Daraus leite ich zwei weitere Gedanken ab:

1) Früher habe ich zwischen Urformat und Gebrauchsformat unterschieden und fand das auf Dauer lästig. Seit der "PS3 Reform" ist jetzt das Format, was Winfrieds Prüfstände schreiben, und das spätere Gebrauchsformat nahezu identisch. Einziger Unterschied: ich kann noch zusätzliche Parameter an die Urformatdatei anfügen.

2) Zu den Konstanten in einer solchen Diskussion gehört die Erwähnung von XML und von Excel. Ist Excel nun die Lösung, oder vielleicht doch nicht? Ich meine fast, den Punkt müßte man vordringlich klären.

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

Hi,

sicherlich muss man Excel und XML nicht berücksichtigen. Ich mache mit Excel nur halt sehr viel und es gibt schön einfache formatierte Textdateien die ohne Aufwand in Excel gelesen werden können. Die Daten sind dann mit gleich bleibender Spaltenbreite getrennt. Das kann z.B. Excel lesen aber auch jeder andere mit Notepad oder einen andere Editor. Meine Anforderung an dem Format wäre also nicht, das es Excel lösen können muss, sondern jeder normale Mensch mit einem Editor. Wenn das zutrifft wird es Excel auch können.

Ich würde schon den Datenstrom vom Prüfstand zum PC unabhänig machen von dem was die Software nachher speichert. Wenn es das gleiche ist, ist auch gut, aber manchmal klappt es halt nicht. Ich z.B. weiß garnicht was da über den USB Kabel an Daten ran kommen.

Um die Diskussion abzukürzen, würde ich hier schon mal nach ein paar Entscheidungen fragen.
Klartext ja oder Nein?

Gruß

Neil

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