Raketenmodellbau.org Portal > Forum > Experimental & Forschung > Motorprüfstände > Für Prüfstände: Das .rmb Format
Du kannst keine neue Antwort schreiben
Seiten (8): « 1 2 3 [4] 5 6 7 8 »

Autor Thema 
osmadie

SP-Schnüffler


Supervisor

osmadie

Registriert seit: Feb 2006

Wohnort: Rhein-Pfalz-Kreis

Verein: Solaris-RMB e.V.

Beiträge: 515

Status: Offline

Beitrag 6770940 [Alter Beitrag24. April 2008 um 13:12]

[Melden] Profil von osmadie anzeigen    osmadie eine private Nachricht schicken   osmadie besitzt keine Homepage    Mehr Beiträge von osmadie finden

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.

Der erste Schluck aus dem Becher der Wissenschaft führt zum Atheismus, aber auf dem Grund des Bechers wartet Gott.
Werner Heisenberg
MarkusJ

Gardena Master of Rocketry


Moderator

Registriert seit: Apr 2005

Wohnort: Kandel

Verein:

Beiträge: 2148

Status: Offline

Beitrag 6770942 [Alter Beitrag24. April 2008 um 13:57]

[Melden] Profil von MarkusJ anzeigen    MarkusJ eine private Nachricht schicken   MarkusJ besitzt keine Homepage    Mehr Beiträge von MarkusJ finden

?
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

WARNUNG: Dieser Beitrag kann Spuren von Ironie beinhalten
Ich bin weder eine Suchmaschine, noch ein Nachschlagewerk - PNs zu Themen die im Forum stehen oder dorthin gehören, werde ich nicht beantworten.
Bilder bitte NICHT über Imageshack oder andere Imagehoster einbinden!
Blackpuma

Epoxy-Meister

Blackpuma

Registriert seit: Jul 2006

Wohnort: Graz

Verein:

Beiträge: 374

Status: Offline

Beitrag 6770943 [Alter Beitrag24. April 2008 um 14:09]

[Melden] Profil von Blackpuma anzeigen    Blackpuma eine private Nachricht schicken   Besuche Blackpuma's Homepage    Mehr Beiträge von Blackpuma finden

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?

Einmal Weltraum und zurück!

http://www.modellraketen.at
http://wiki.modellraketen.at
Neil

99.9% harmless nerd


Administrator

Neil

Registriert seit: Aug 2000

Wohnort: Delft

Verein: SOLARIS

Beiträge: 7776

Status: Offline

Beitrag 6770945 [Alter Beitrag24. April 2008 um 14:16]

[Melden] Profil von Neil anzeigen    Neil eine private Nachricht schicken   Neil besitzt keine Homepage    Mehr Beiträge von Neil finden

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

Die Erde ist eine Scheibe. Egal in welche Richtung sich die Menschheit bewegt, sie geht immer auf einen Abgrund zu.


MarkusJ

Gardena Master of Rocketry


Moderator

Registriert seit: Apr 2005

Wohnort: Kandel

Verein:

Beiträge: 2148

Status: Offline

Beitrag 6770946 [Alter Beitrag24. April 2008 um 14:39]

[Melden] Profil von MarkusJ anzeigen    MarkusJ eine private Nachricht schicken   MarkusJ besitzt keine Homepage    Mehr Beiträge von MarkusJ finden

@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

WARNUNG: Dieser Beitrag kann Spuren von Ironie beinhalten
Ich bin weder eine Suchmaschine, noch ein Nachschlagewerk - PNs zu Themen die im Forum stehen oder dorthin gehören, werde ich nicht beantworten.
Bilder bitte NICHT über Imageshack oder andere Imagehoster einbinden!
Blackpuma

Epoxy-Meister

Blackpuma

Registriert seit: Jul 2006

Wohnort: Graz

Verein:

Beiträge: 374

Status: Offline

Beitrag 6770947 [Alter Beitrag24. April 2008 um 14:40]

[Melden] Profil von Blackpuma anzeigen    Blackpuma eine private Nachricht schicken   Besuche Blackpuma's Homepage    Mehr Beiträge von Blackpuma finden

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.


Einmal Weltraum und zurück!

http://www.modellraketen.at
http://wiki.modellraketen.at
MarkusJ

Gardena Master of Rocketry


Moderator

Registriert seit: Apr 2005

Wohnort: Kandel

Verein:

Beiträge: 2148

Status: Offline

Beitrag 6770948 [Alter Beitrag24. April 2008 um 14:50]

[Melden] Profil von MarkusJ anzeigen    MarkusJ eine private Nachricht schicken   MarkusJ besitzt keine Homepage    Mehr Beiträge von MarkusJ finden

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

WARNUNG: Dieser Beitrag kann Spuren von Ironie beinhalten
Ich bin weder eine Suchmaschine, noch ein Nachschlagewerk - PNs zu Themen die im Forum stehen oder dorthin gehören, werde ich nicht beantworten.
Bilder bitte NICHT über Imageshack oder andere Imagehoster einbinden!
osmadie

SP-Schnüffler


Supervisor

osmadie

Registriert seit: Feb 2006

Wohnort: Rhein-Pfalz-Kreis

Verein: Solaris-RMB e.V.

Beiträge: 515

Status: Offline

Beitrag 6770949 [Alter Beitrag24. April 2008 um 14:52]

[Melden] Profil von osmadie anzeigen    osmadie eine private Nachricht schicken   osmadie besitzt keine Homepage    Mehr Beiträge von osmadie finden

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

Der erste Schluck aus dem Becher der Wissenschaft führt zum Atheismus, aber auf dem Grund des Bechers wartet Gott.
Werner Heisenberg
Blackpuma

Epoxy-Meister

Blackpuma

Registriert seit: Jul 2006

Wohnort: Graz

Verein:

Beiträge: 374

Status: Offline

Beitrag 6771901 [Alter Beitrag24. April 2008 um 14:57]

[Melden] Profil von Blackpuma anzeigen    Blackpuma eine private Nachricht schicken   Besuche Blackpuma's Homepage    Mehr Beiträge von Blackpuma finden

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


Einmal Weltraum und zurück!

http://www.modellraketen.at
http://wiki.modellraketen.at
Neil

99.9% harmless nerd


Administrator

Neil

Registriert seit: Aug 2000

Wohnort: Delft

Verein: SOLARIS

Beiträge: 7776

Status: Offline

Beitrag 6771903 [Alter Beitrag24. April 2008 um 15:11]

[Melden] Profil von Neil anzeigen    Neil eine private Nachricht schicken   Neil besitzt keine Homepage    Mehr Beiträge von Neil finden

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

Die Erde ist eine Scheibe. Egal in welche Richtung sich die Menschheit bewegt, sie geht immer auf einen Abgrund zu.


Seiten (8): « 1 2 3 [4] 5 6 7 8 »
[Zurück zum Anfang]
Du kannst keine neue Antwort schreiben