Wir werden kaum dahin kommen, dass man mit jeder Software jeden Prüfstand
anschließen und betreiben kann. Prüfstände, die z.B. zusätzlich vom PC gesteuert
werden sollen, benötigen sicher immer eine spezielle Software. Allein Prüfstände,
die in der Lage sind, Daten selbständig zu speichern und über USART die
Messung auszugeben, könnten vereinheitlicht werden. Wenn das USART-Protokoll
gleich ist und die Daten passend formatiert sind, dann können alle solchen
Prüfstände mit jeder passenden Software ausgelesen und die Daten anschließend
auf dem PC ausgewertet werden.

Prüfstände, die enger mit dem PC verbunden sind und ggf. von diesem gesteuert
werden, könnten die ermittelten Daten nach der Messung in dasselbe Datenformat
bringen. Dann sind auch diese Dateien für andere Programme nutzbar.

Wir brauchen also ein einheitliches USART-Protokoll und einen Header, der
die Messdaten-Struktur ausreichend beschreibt. Evtl. wäre eine zusätzliche
erweiterte Datenstruktur zu definieren, mit der die Datensätze anschließend
auf dem PC zu versehen sind, um z.B. die Darstellung der Daten auf dem PC
zu verwalten (Linien-Farbe, Linien-Breite, angezeigter Ausschnitt, Brennstart,
Brennschluss,...)

Wir sollten mal sammeln, welche Daten in den jeweiligen Strukturen enthalten sein
sollen.

?
Es geht hier doch gar nicht um ein Protokoll, sondern um das Dateiformat in dem die Ergebnisse abgespeichert werden können!
Ich würde die Kommunikation mit dem Prüfstand komplett von dem Format abkoppeln, mit dem die Daten auf die Festplatte geschrieben werden.
So kann jeder mit seinem Prüfstand seine "Suppe" kochen und weiß dann, wie die Daten im Programm zu interpretieren sind. Abgespeichert wird dann alles im universalen RMB-Format, welches von allen kompatiblen Prüfstandprogrammen importiert und dargestellt werden kann.
Durch die (hoffentlich) intelligente Auslegung kann jedes Programm die Informationen auswerten, die es kennt und verarbeiten kann, zusätzliche Daten werden schlicht und ergreifend ignoriert.

mfG
Markus

Stimmt Markus. Datenübertragung und speichern von Daten sind 2 komplett unterschiedliche Sachen. Egal wie die Daten beim Computer ankommen sie müssen alle im gleichen Format in der Datei abgelegt werden.

(Kopfzeile)
Datum;Motor
20080424;D12

(Eigentliche Daten)
Messwert;Schub
01;100
02;102
03;105
.
.
.

Wenn alle die Daten in zB. dieser Form bereitstellen passt alles. Völlig egal mit welchen Übertragungsmedium oder in welchem Format die Daten vom Prüfstand kommen.

Zitat:

---

welches von allen kompatiblen Prüfstandprogrammen importiert und dargestellt werden kann.

---

Welche Programme meinst du dabei eigentlich? Wie soll einen fertigen Programm beigebracht werden das es auf einmal das Datenformat akzepiert?

Zitat:

---

Welche Programme meinst du dabei eigentlich? Wie soll einen fertigen Programm beigebracht werden das es auf einmal das Datenformat akzepiert?

---

Das klappt nur mit einem Update der Software. Jetzt sieht es ja so aus, das jeder seine Software schreibt sein Format hat. Der nächste Schritt ist das Format zu vereinheitlichen. Dann muss jeder im folgenden Schritt diese Format in seiner Software einbinden.

Oliver hat noch einen wichtigen Punkt genannt. Wie markieren wir Ereignisse in den Daten? Sowas wie Brennschluß, etc.?

Gruß

Neil

@Blackpuma: Es geht hier um einen Standard, der verhindern soll, dass durch den "Prüfstandboom" X verschiedene Programme mit jeweils einem eigenen Dateiformat entstehen.
@Neil:
Deshalb XML: Ich würde den Datensätzen einfach einen weiteren Flag hinzufügen und gut ist ... es muss nur vornherein definiert werden, welche Werte/Strukturen möglich sind und was sie bedeuten, hinterher kann jeder selbst entscheiden, wie weit er diesen Standard umsetzen möchte.
Wenn jemand einen Prüfstand hat, der "nur" einen Haufen Daten abliefert, braucht der diverse Zusatzinformationen wie Kanäle etc. ja nicht zu "verstehen" oder abzuspeichern.

Deshalb wäre es sinnvoll, wenn man einmal alle (möglicherweise) benötigten Werte/Informationen es gibt, damit man sich dann über die Struktur Gedanken machen kann. Vielleicht gibt es gar nicht so viele Möglichkeiten, dass XML Sinn macht, auf jeden Fall sieht man so aber leichter, wie das Format strukturiert sein könnte.

mfG
Markus

Wenn du meinst wie es in der Datei markiert werden kann/soll wird das nicht das Problem sein.

(Eigentliche Daten)
Messwert;Schub;S/T
01;95
02;95
03;95
04;100;S
05;102
06;105;T
.
.

S hinter dem Wert für Start und T für Stop. Ist die Frage ob man das wirklich braucht. Wenn ich eine Grafik daraus mache sehe ich eigentlich diese Sachen.

Was auch noch zu beachten ist wäre die Angabe der Nullstelltung.

Die ersten 3 Messwerte liegen schon bei 95. Das soll dann die Nullstellung sein. Andererseits wenn es ein einheitliches Format ist dann können die Daten auch umgewandelt werden vor dem sichern.

Was mir noch gerade einfällt. Die Zeiteinheit in der die Messungen durchgeführt werden müssen eingetragen sein. Verschiedene Abtastzeiten heißt unterschiedliche Zeit zwischen den Messsignalen.

Was ist mit weiteren Flags? Zusätzlichen Kanälen oder weiteren Informationen?
Zeitstempel, Samplingrate, Informationen zur Prüfstand-Version und Software-Version etc.

Ganz so einfach sollte man es sich nicht machen, was jetzt einfach ist macht später viel Arbeit.

mfG
Markus

Ich habe für Prüfstands-interne Ereignisse einen eigenen Aufnahme-Kanal eingerichtet. Solche Ereignisse können z.B. sein:

- Zündstrom eingeschaltet
- Zündstrom ausgeschaltet
- Zeitstempel-Zähler übergelaufen

Diese Ereignisse werden wie Messwerte mit einem Zeitstempel versehen und mit der Messung gespeichert. Als Kanal wird der Ereignis-Kanal (bei mir Nummer 7, da der Prüfstand 6 reale Kanäle hat) eingetragen. Das Ereignis selbst wird in den 10 Bit codiert, die ich sonst für den AD-Messwert verwende.

Aber eine Markierung wie Brennstart/Brennschluss lasse ich nicht automatisch vom Prüfstand erzeugen. Solche Informationen sollen vom Benutzer eingetragen werden. Deswegen schlage ich auch zwei verschiedene Strukturen vor:

Eine Struktur, die im Prüfstand angelegt wird und die Messdatenstruktur beschreibt sowie zusätzliche Informationen der Aufnahme speichert.

Eine zweite Struktur, die erst im PC bei der Auswertung hinzugefügt wird und weitere Daten enthält, die der Prüfstand nicht kennen muss. Dazu gehören Werte wie Brennstart/-schluss oder auch die Farben und Linienbreiten der dargestellten Messkurven.

Beide Strukturen zusammengepackt mit den Messdaten, so wie sie aus dem Prüfstand kommen, das halte ich für eine gute Lösung.

Gruß,
Oliver

Zusammenfassen in einer Datei in Kopfzeile und Messdaten zB.

Weitere Flags kann man in der Kopfzeile definieren:

(Kopfzeile)
Datum;Zeit;Motor;Prüfstand;Samplingrate;Nullpunkt
20080424;12:34;D12;Mia 443;1000;95

Das ganze soll doch für Motoren sein. Wofür brauch ich dann eigentlich einen zweiten Kanal?

Wenn ich das ganze in XML abbilde, brauchen die TAGs mehr speicher als die eigentlichen Messdaten.

Ausserdem nachdem es ja "standartisiert" sein soll hat niemand nachher noch etwas hinzuzufügen! (Ausser in einer neuen Version)

Geändert von Blackpuma am 24. April 2008 um 15:00

Hi,

Zitat:

---

Das ganze soll doch für Motoren sein. Wofür brauch ich dann eigentlich einen zweiten Kanal?

---

Gute Frage.
Für die Person die nur die Schubkurve braucht um daraus eine Simulation für seine Rakete zu machen sollte es reichen. Wenn du aber z.B. einen Hybriden vermessen willst, so brauchst du noch weitere Werte wie Temperatur und Druck da der Schub davon abhängt. Ich z.B. baue gerade einen Prüfstand wo ich den Tankdruck und den Brennkammerdruck messen kann. Dazu kommen dann noch Temperatursensoren im Tank und an der Düse. Ich baue Hybride und mich interessiert es sehr wie stark der Schub von der Tanktemperatur abhängt, da der ja Druckförderung hat.

Gruß

Neil