Genau, es soll hier ja kein neues Motor-File-Format rauskommen, sondern ein Prüfstands-Format, mit dem man mehr machen kann als nur die Schubkurve ansehen.

Wer sich nur für die Schubkurve interessiert, für den kann man gerne eine Export-Funktion anbieten. Die kann von mir aus auch alle möglichen Formate wie ASCII oder sonst was unterstützen. Aber die eigentliche Messdatei hat in meinen Augen einen anderen Anspruch.

Gruß,
Oliver

Wenn das ein Prüfstandsformat werden soll dann ist die bisherige Diskussion umsonst gewesen. Zuerst sollte mann dann vielleicht einmal festlegen was überhaupt alles aufgezeichnet werden soll und nicht mit dem Format beginnen.

Wenn man mehrere Datensätze hat muss man zuerst andere Dinge definieren. Neil möchte 2x Druck und Temp in dem Format haben. Wie werden diese getrennt? Kennziffern für verschiedene Sonsorentypen (Temp, Druck, ...)?

Was wenn jemand mal Virbrationen vom Motor messen möchte? Soll das dort dann auch rein?

Wieviele Personen interessieren sich für alle Werte? Also ich kann mir nicht denken das sich alle für die Auswirkungen von Druck auf Schub Interessieren. Wenn es um einen Motor geht dann interessiert man sich normal für die Schubkurve und das wars auch schon.

Wenn ein einzelner bestimmte Werte aufzeichnet weil ihn das interessiert muss das meiner Meinung nach nicht in ein Standardformat hinein das es alle lesen können.

Erinnert mich irgendwie an Windows.... Es gibt so viel was dort Standard ist aber nur von wenigen gebraucht wird.

Hi,

was aufgezeichnet werden soll ist eigentlich Nebensache. Vom Prinzip her machen wir ja nichts anders als die Daten eines eines Datenloggers zu lesen. Was da nun geloggt wurde ist der Software egal. Es muss nur bei den Daten stehen was da geloggt wurde. So könnte man z.B. die Daten in Spalten schreiben. Das erste Feld der Spalte ist der Name, das zweite die Einheit. Man muss in seiner Software dann nichts anderes machen als die Namen und Einheiten in der Achsenüberschrift zu kopieren.
Wenn man ein Format nehmen würde welches durch ein vorher vereinbartes oder in der Datei hinterlegtes Trennzeichen die Daten voneinander trennt, dann ist die Anzahl der Kanäle fast beliebig groß. Z.B. könnte man TAB als Spaltentrenner nehmen und ein CR um das Ende der Zeile zu definieren. Danach weiß die Software das eine neue Zeile angefangen hat. Es wäre aber von Vorteil vorher noch zu sagen, wieviele Spalten man einlesen möchte den diese werden in der Software in sowas wie ein Array geschrieben. Die müßte man erstmal initalisieren. Oder man liest einmal die erste Zeile Probeweise ein und zählt die Trennzeichen.

Gruß

Neil

Hallo,

ich lese hier von Anfang an mit und vermute, es gibt ein paar Missverständnisse:
Peter geht von einer wachsenden Zahl von vorhandenen oder entstehenden Prüfständen aus.
Ok., das kann sein, da hat er sicher den besseren Überblick, aber woher stammt die Ansicht, dass es einen größeren Bedarf zum Austausch von Daten gibt?
Wie sich in der Diskussion gezeigt hat, gibt es viele verschiedene Vorstellungen davon, was ein Prüfstand können muss, je nach Benutzer eben: vom simplen Schub-Zeit-Diagramm bis zum mehrkanaligen Aufzeichnen diverser Kraft-, Druck- und Temperaturparameter reicht bisher die Spanne.

Mal angenommen, es bleibt so wie bisher, d.h. Jeder entwickelt sein eigenes System nach seinen Bedürfnissen und Fähigkeiten.
Im Normalfall ergibt ein Versuch auf so einem Prüfstand dann eine oder mehrere Grafiken und Tabellen, aus denen der zeitliche Verlauf der aufgezeichneten Parameter ersichtlich ist.
Wenn nun aus irgendeinem Grund ein Anderer sich für diese Daten interessiert, dann bekommt er sie per e-mail als jpg-file oder Excel-Tabelle.

Diese Diskussion um ein normiertes Datenformat etc. wäre sinnvoll, wenn es hier ein Kollektiv von Konstrukteuren gäbe, die gemeinsam arbeitsteilig an einem Projekt arbeiten und darum auf ein gemeinsames Datenformat angewiesen sind. Sorry, aber wenn ich Eines nach 1 Jahr RMB-Forum lesen immer vermisst habe, dann ist es nennenswerte, überregionale, projektbezogene Teamarbeit

Darum muss ich Blackpuma zustimmen: die Diskussion mag für Einzelne interessante Anregungen für's eigene Projekt bringen, - ein echter Vereinheitlichungsbedarf besteht aber nicht.

Gruß

Dino

ich fand die Diskussion eingentlich interresannt... bis ebend ...

Da es sich darum dreht, wie die "aufgenommenen" Daten von einer Software gespeichert wird klinke ich mich an dieser Stelle nun aus, da ich zwar sehr großes Interesse an einem Prüfstand hätte und diesen auch Elektronisch herstellen könnte und auch gerne würde, aber KEINE Ahnung von der Erstellung von einer geeigneten Software zum auslesen, Anzeigen oder Speichern habe ...

Was nutzt mir ein Prüfstand, wenn cih die Ergebnisse nciht verarbeiten kann ...

Also hat sich das Thema an dieser Stelle für mich erledigt ...

viele Grüße
Pierre

Neil, mich würde mal interessieren, wie das bei Deinem Prüfstand aussieht. In welcher Form bekommst Du Deine Daten geliefert, mit welchem Format und wie liegen die Daten nach der Aufnahme vor? Kannst Du da mal ein paar Details erzählen?

Gruß,
Oliver

Zitat:

---

Original geschrieben von Blackpuma
Nur wenn alle Dateien in einem Format vorliegen... Welche Software soll das dann lesen und was wollt ihr mit dem Prüfstanddaten eigentlich machen?

---

Eine sehr gute Frage, die uns genau ins Zentrum des .rmb Formatprojekts führt.

Es gibt ja spezielle Software, die Schubkurven einliest, auswertet und darstellt. Ich hab zum Beispiel so ein Programm. Halb RMB ist mit den Kurven kontaminiert, die wir damit aufgezeichnet haben, sämtliche BC-Kurven sind damit gemacht und einiges andere auch. Dieses Programm ist an Winfrieds Hardware angepaßt. Neuerdings ist Oliver dazu gekommen, der sich auch eine sehr schöne Lösung gebaut hat. Jederzeit könnte andere die Lust packen, sich auch was zu schreiben.

Neil wiederum hat sich Verdienste erworben um das Konzept Volksprüfstand was nach meinem Verständnis bedeutet, daß man aus fertig gekauften Komponenten einen Prüfstand zusammensetzt. Da wird auch noch die eine oder andere Lösung kommen.

Spätestens jetzt sind wir also an einem Wendepunkt angekommen. Entweder steuern diese Entwicklungen auf einen Wildwuchs an inkompatiblen Formaten zu, wo keiner die Dateien des anderen verstehen kann. Oder wir schaffen .rmb. Das gemeinsame Format hätte eigentlich nur Vorteile:

1) Wer sich einen Volksprüfstand baut und dann nicht recht weiß, wie er die elektrischen Signale in Kurven und Leistungswerte umsetzen soll, der könnte z.B. meine Software bekommen.

2) Wer gelegentlich Motoren testen läßt ohne selbst eine Meßanlage betreiben zu wollen, der kann auch die Software bekommen (oder auch eine andere Software, die das .rmb Format versteht). In Zukunft müssen sich diese Kollegen nicht mehr mit Screenshot-Bitmaps einer Schubkurve begnügen sondern können den Originaldatensatz (natürlich .rmb) haben. Vorteil: Selber beliebige Ausschnitte, Vergrößerungen, Überlagerungen darstellen können.

Das schöne dabei: Egal ob es heute der Peter mißt oder morgen der Oliver oder anderntags der Neil, jeden Datensatz kannst Du in derselben Software auswerten und darstellen. Und baust du dir irgendwann doch einen eigenen Prüfstand, gehts mit der gewohnten Software gleich weiter.

3) Wer Spaß daran findet, selber eine Motorensoftware zu schreiben, der muß nicht ein Dutzend Formate hin- und her konvertieren, sondern unterstützt genau ein Format: .rmb. Schon kann er alles anzeigen, was in der Szene gemessen wird, und kann seine Software jedem weitergeben.

4) Man könnte im Forum eine Bibliothek an Prüfstandsdatensätzen im .rmb Format aufbauen. Beliebiges Beispiel: Hybridentwickler könnten sich so mit Hilfe der frei verfügbaren Software über vorliegende Arbeiten informieren und ihre Ergebnisse austauschen.

Eine lohnende Vision, wie ich finde. Man muß sich vielleicht daran aufrichten, bevor Einzelne hier an den Bits und Bytes verzweifeln. Aber die kriegen wir auch noch hin..

Geändert von Peter am 24. April 2008 um 23:47

Hi,

neben der Interoperabilität hat so ein Standardformat noch einen weiteren kleinen Vorteil. Es definiert eben einen Standard welche weiteren Informationen neben den Schubkurven von Relevanz sind. Zumindest potentiell erhöht man damit auch die Qualität der Dokumentation der Versuche.

Zitat:

---

Original geschrieben von osmadie

Neil, mich würde mal interessieren, wie das bei Deinem Prüfstand aussieht. In welcher Form bekommst Du Deine Daten geliefert, mit welchem Format und wie liegen die Daten nach der Aufnahme vor? Kannst Du da mal ein paar Details erzählen?

---

Ich bin zwar nicht Neil, aber der kann mich ja nachher noch korrigieren.
Neil hatte mal erwähnt dass er ein fertiges USB-Modul in Verbindung mit LabVIEW verwendet. Die Treiber für LabVIEW werden mit dem Modul schon mitgeliefert. LabVIEW besitzt eine eigene graphische Programmieroberfläche, bei der man sich mehrere sogenannte VIs (Virtuelle Instrumente) einfach zusammenklickt. Das ganze System arbeitet nach dem Datenflussmodell.
Vereinfacht gesagt gibt es ein VI welches die Messhardware repräsentiert. Dieses liefert einen Datenstrom, welcher an weitere VIs weitergeleitet wird welche ihn in eine Datei schreiben bzw. am Bildschirm darstellen.

In Analogie zur "klassischen" Programmierung kann man die VIs als Prozeduren oder auch Objekte betrachten, während der Datenstrom in Form von Arrays (oder allgemeiner Structs) vorliegt.

Diese Kapselung in VIs ist sehr typisch für LabVIEW. Man merkt von den Lowlevel-Funktionen normalerweise nichts (es sei denn man kreiert eigene VIs).

Gruß
Reinhard

Geändert von Reinhard am 25. April 2008 um 03:26

Zitat:

---

Original geschrieben von CharlyMai

ich fand die Diskussion eingentlich interresannt... bis ebend ...

Da es sich darum dreht, wie die "aufgenommenen" Daten von einer Software gespeichert wird klinke ich mich an dieser Stelle nun aus, da ich zwar sehr großes Interesse an einem Prüfstand hätte und diesen auch Elektronisch herstellen könnte und auch gerne würde, aber KEINE Ahnung von der Erstellung von einer geeigneten Software zum auslesen, Anzeigen oder Speichern habe ...

Was nutzt mir ein Prüfstand, wenn cih die Ergebnisse nciht verarbeiten kann ...

Also hat sich das Thema an dieser Stelle für mich erledigt ...

viele Grüße
Pierre

---

Was hat hier die Hardware mit der Software zu tun? Wenn du dir einen Prüfstand bauen willst dann tu dies doch und schieb es nicht ab weil es kein einheitliches Format gibt! Oder arbeitest du auch nicht mit Office weil es kein Standard Format ist? (Office = Standard lass ich nicht gelten. Die können ja nicht mal brauchbar Dateien von einer Office Version in eine andere mitnehmen.)

Wenn du weißt wie mann einen Prüfstand baut dann wirst du auch wissen wie man Daten Seriell an einen PC schickt. Die Daten in einem CVS Format schicken und mittels Hyperterminal die Daten in eine Datei schreiben lassen. Schon kannst du die Daten in jedem Excel einlesen und Graphisch auswerten.

Also diese Ausrede "Ich bau mir keinen Prüfstand weil es kein einheitliches Format gibt" lass ich wirklich nicht gelten.

@Peter:

Ein einheitliches Format in dem nur eine Schubkurve gespeichert ist, ist leicht zu realisieren. Aber hier geht es anscheinend um viel mehr als nur eine Schubkurve zu Speichern.

LG
Andreas

Hi Charly,

Zitat:

---

Da es sich darum dreht, wie die "aufgenommenen" Daten von einer Software gespeichert wird klinke ich mich an dieser Stelle nun aus, da ich zwar sehr großes Interesse an einem Prüfstand hätte und diesen auch Elektronisch herstellen könnte und auch gerne würde, aber KEINE Ahnung von der Erstellung von einer geeigneten Software zum auslesen, Anzeigen oder Speichern habe ...

---

Ich würde mich an deiner Stelle ausklinken und getrennt über die Hardwarelösung weiter machen. Du wärst der richtige um eine saubere Hardwarelösung für den Eigenbau zu führen.

Gruß

Neil