Zitat:

---

Original geschrieben von hybrid

Wie sehen denn "Deine" Kurvenmeßdaten aus? Ist das Format beschrieben? Wenn ja, dann kann man es mit relativ wenig Aufwand umwandeln.

Grüße
Malte

PS: Programmieren ist einfacher als Basteln

---

Hallo hybrid,

ich habe diesbzüglich gerade heute mittag mit Peter telefoniert.
Es ist kein Problem die Daten zu konvertieren.
Wenn ich ihn richtig verstanden habe, gäbe es auch die Möglichkeit das Programm direkt zum Messen und Darstellen zu verwenden. Das wäre natürlich das nonplusultra, alles aus einer Hand.

ps. Mir fällt das kreative Basteln erheblich leichter

Gruß
Tom

Geändert von Tom am 07. Oktober 2006 um 17:05

Zitat:

---

Original geschrieben von Tom
Wenn ich ihn richtig verstanden habe, gäbe es auch die Möglichkeit das Programm direkt zum Messen und Darstellen zu verwenden.

---

Ja, das macht mein Programm zwangsläufig heute schon, es kommuniziert mit dem Prozessor im Prüfstand und liest dessen Daten in den PC aus. Das Bild unten zeigt einen der beiden Dialoge, die das Programm zu diesem Zweck anbietet. Zwei, weil jeder der beiden Prüfstände seinen eigenen Dialog braucht, denn jeder hat so seine Eigenheiten. Übrigens kann ich damit nicht nur die Daten auslesen, sondern auch den Prüfstand konfigurieren, z.B. den Wert für die automatische Schuberkennung einstellen.

Also könnte es einen dritten Bildschirm für Toms Eigenbau geben. Voraussetzung ist allerdings daß man "das Protokoll" kennt, mit dem so eine Elektronik arbeitet.

Unser Forenseelsorger könnte für seine Schubmessungen übrigens die Dateiendung .TOM verwenden

Hi,

ich halte sehr wenig davon die Rohdaten des AD-Wandlers direkt in einer Datei zu speichern. Das ist zwar sehr einfach aber es ist sehr gefährlich. Wenn ich sowas mache, muss ich weitere Informationen zu den Daten liefern. So z.B. die Kalibrierkurve des Sensors ( ich denke nicht das du die vom Eichamt hast aufnehmen lassen ). Dann erst hat der Anwender der Daten eine Möglichkeit richtige physikalische Werte daraus zu errechnen. Wenn ich das aber schon vorher mache, also vor dem Speichern in die Datei, dann muss ich mir als Anwender keine Sorgen mehr darüber machen. Das Ziel eines einheitlichen Formates für die Daten war ja das man die Kurven untereinander tauschen kann, damit nicht jeder jeden Motor messen muss.
Ich gebe zu, die Idee nur die AD-Wandlerwerte zu speichern hatte ich auch, aber dann viel mir ein, was ich danach noch alles mit den Werten gemacht habe bis die Kurve fertig war.
Die Frage nach der Samplerate ist doch völlig egal hier. Wenn ich in der Datei angebe mit wieviel Samples/s gearbeitet wurde, dann kann jeder Damit was anfangen. Die Idee mit immer höheren Raten zu arbeiten kam mir auch, doch sehe ich da praktische Probleme. Die Datei wird sehr groß, es dauert länger daran herum zu rechnen. Wenn ich z.B. in Excel eine Kurve speichere, ist die Datei heute schon mit 1kS/s ca. 3MB groß. So große Daten will ich garnicht haben. Ich denke hier ist eine eigene Diskussion fällig über den Sinn der Samplerate. Für die Schubkurve selber brauche ich diese nicht, eher um das Frequenzverhalten des Motors heraus zu finden. aber wie gesagt, hier geht es um die Daten und nicht um die Samplerate. Das können wir in einem anderen Thread diskutieren.

Gruß

Neil

Zitat:

---

Original geschrieben von Neil
hier geht es um die Daten und nicht um die Samplerate. Das können wir in einem anderen Thread diskutieren.

---

Sehr richtig, und diesen anderen Thread habe ich ja auch schon aufgemacht! Für diese Diskussion hier bleibe ich dabei, daß jeder Erbauer eines Prüfstandes die Freiheit haben muß, die Abtastrate einzusetzen die ihm gefällt und die er technisch realisieren kann.

Beim Datenformat hast Du einen wichtigen Punkt angeschnitten: Die resultierende Dateigröße. Die Kurve die am Anfang des Threads steht hat 0,5 MByte. Das ist ziemlich kompakt, denn jeder Messpunkt belegt gnadenlos nur die 2 Byte, die man unbedingt benötigt um Ganzzahlen zwischen 0 und 65535 zu speichern. Nachteil: Dadurch ist die Datei "binär" und nicht textorientiert = menschenlesbar.

Würde ich jetzt auf ein spreadsheet-freundliches "Textformat" wechseln wie z.B. CSV, dann würde allein schon die Zeilenschaltung nach jedem Messwert weitere 2 Byte kosten und die Datei auf 1 MB vergrößern. Zusätzlich müßte ich aus den 2 Byte für den Wert rund 10 Byte pro Messwert machen, je nach Anzahl der Stellen und inclusive Dezimalkomma und Trennzeichen. Das wäre aber immer noch nicht genug, denn ich hätte noch keine Zeitmarke. Man kann die sicher unterschiedlich definieren, aber Millisekunden dürfen es schon sein. Sagen wir mal 8 Zeichen, wiederum Komma (Doppelpunkt) und Spaltentrennzeichen mitgerechnet. Das wären dann insgesamt bereits 20 Byte pro Messpunkt, also das Zehnfache.

Dann hätte ich einen inhaltlich exakt gleichen Datensatz schon auf unhandliche 5 Megabyte aufgeblasen, wenn ich hier halbwegs richtig rechne. Das muß man auch bedenken, selbst wenn Speicherplatz heutzutage glücklicherweise nicht mehr ganz so im Vordergrund steht. Aber ich kann z.B. auf einem billigen Speicherstift für unterwegs / auf meinem Handy bei 128 MB Speicherkapazität 250 Datensätze unterbingen so wie heute, aber nur 25 der aufgeblasenen Datensätze.

Zitat:

---

ich halte sehr wenig davon die Rohdaten des AD-Wandlers direkt in einer Datei zu speichern. Das ist zwar sehr einfach aber es ist sehr gefährlich. Wenn ich sowas mache, muss ich weitere Informationen zu den Daten liefern. So z.B. die Kalibrierkurve des Sensors.

---

Genau das halte ich für einen Vorteil. Meine Datensätze enthalten wie schon gesagt immer einen Kalibrierfaktor bzw. eine Eichtabelle (mir ist der Begriff Kalibriertabelle einfach zu lang und zu stolprig, drum denk ich an der Stelle immer mich knutscht ein Eich . Wenn das Programm den Datensatz liest, dann wird jeder der 2-Byte Rohdaten umgerechnet in einen Schubwert.

Der Vorteil dabei: Ich behalte die unverfälschten Originaldaten. Mal angenommen ich würde irgendwann feststellen, daß der Kalibrierfaktor nicht ganz stimmt weil eine gewisse Temperaturdrift besteht (nur so als beliebiges Beispiel), dann könnte ich für diese Temperatur einen neuen Kalibrierfaktor ermitteln und die Originaldaten nachträglich korrekt neuberechnen. Ist doch was!

Noch ein Einwand: Auch wenn Du von Black Box den Messwert vorab in eine Textdatei schreiben läßt, so ist das noch immer nicht der ganz korrekte "Schubwert", sondern nur ein "gemessenes Gewicht". Steht Dein Motor kopfüber auf dem Prüfstand, so mußt Du eigentlich den Treibstoffmassenverlust während des Abbrands einberechnen. Ferne mußt Du das abziehen, was durch das Eigengewicht des Motors und der Halterung an "Grundpegel" aufliegt. Das aber kann Deine Black Box nicht unbedingt erledigen. Denn vielleicht hast Du zum Zeitpunkt der Zündung die Treibstoffmasse noch nicht angegeben?

Ich behaupte also: Man rechnet "hinterher" sowieso. Da kann ich dann gleich konsequent die besonders kompakten Originaldaten speichern.

So betrachte ich das mit CSV und Excel genau anders herum: Es ist nicht die Basis, sondern ein zusätzliches Gimmick. In meinem Flugbahnberechnungsprogramm läuft z.B. ein Textlogfile mit, das mehrere MB groß wird, wen wunderts. Dafür kann ich dann Einzelpunkt für Einzelpunkt durch die Bahndaten blättern, sofern ich das überhaupt will. So ein "logfile" könnte ja auch eine Prüfstandsoftware ausgeben.

Geändert von Peter am 08. Oktober 2006 um 13:50

Zitat:

---

Noch ein Einwand: Auch wenn Du von Black Box den Messwert vorab in eine Textdatei schreiben läßt, so ist das noch immer nicht der ganz korrekte "Schubwert", sondern nur ein "gemessenes Gewicht". Steht Dein Motor kopfüber auf dem Prüfstand, so mußt Du eigentlich den Treibstoffmassenverlust während des Abbrands einberechnen. Ferne mußt Du das abziehen, was durch das Eigengewicht des Motors und der Halterung an "Grundpegel" aufliegt. Das aber kann Deine Black Box nicht unbedingt erledigen. Denn vielleicht hast Du zum Zeitpunkt der Zündung die Treibstoffmasse noch nicht angegeben?

---

Das Problem hast du aber auch mit deiner Datei, nur das du in nur einer Richtung neu rechnen mußt, ich aber einmal zurück.
Dafür hat aber deine Rohdaten + Kalib. Kurve ein anderes Problem. Was ist wenn deine Kalib. Kurve falsch ist? Dann hast du überall was falsches drin stehen und evtl. bekommt man das nicht mit.

Gruß

Neil

Hallo Neil,

da spielen natürlich auch persönliche Befindlichkeiten eine nicht zu unterschätzende Rolle. Was man schon hat, um ein Beispiel zu nennen, das ändert man nur ungern. Anderes Beispiel: Ich kann mich daran erinnern, daß ich am Anfang auch unbedingt eine Zeitmarke zu jedem Messpunkt haben wollte. Aus der Befürchtung heraus, daß beim seriellen Transfer mal Daten verschluckt werden könnten oder was auch immer.

Wenn man dann in der Praxis erlebt, daß die Datenübertragung erstaunlich gut funktioniert und halt nichts verschluckt wird, dann entwickelt man ein gesundes Grundvertrauen in die beteiligte Elektronik und achtet mehr auf ein kompaktes Datenformat. Darum können wie ja an diesem Punkt einfach festhalten, daß die Vorlieben momentan noch unterschiedlich ausgeprägt sind und mal einen ganz anderen Punkt angehen:

Könntest Du mir einen (oder mehrere) Deiner Datensätze zukommen lassen? Ich würde die Daten in mein Programm importieren. Dann kannst Du hinterher entscheiden, ob Dir das Ergebnis gefällt oder nicht.

Gruß
Peter

Hallo Peter,

ich würde dir gerne eine Datei zukommen lassen. Aber sehe ich den nutzen noch nicht, da ich selber mit meinem Format nicht glücklich bin. Da sind so einige Punkte noch drin die mir nicht gefallen. Da aber meine Software recht einfach abzuändern ist, wollte ich den Ausgang dieser Diskussion abwarten um dann das format anzupacken. Daher wäre es dann für dich doppelte Arbeit deine Software jetzt schon anzupassen.
Wenn du das trotzdem machen willst, dann schicke ich dir gerne eine Datei. Brauche dann nur deine Email.

Gruß

Neil

Hi,

Um mich als Aussenstehender (NichtPrüfstandBetreiber) mal einzumischen. Bei einem Austauschformat in einer heterogenen Hard- und Softwareumgebung fände ich es gut, wenn das Format grundsätzlich menschenlesbar, idealerweise selbsterklärend ist. Man kann ja trotzdem ohne Probleme noch zusätzlich Rohdaten in einem Container unterbringen. Ich habe mich mal kurz darauf los getippt um grob ein paar Ideen zu illustrieren. Vielleicht sind ja ein paar nützliche Anregungen darunter.

Zitat:

---

Original geschrieben von hybrid
PS: Ich warte noch bis einer kommt und "XML" sagt

---

Gruß
Reinhard
Anhang: prüfstand.txt

PS: Nicht zu genau auf die Daten sehen, die hatte ich noch von wo anders herumliegen.

Geändert von Reinhard am 08. Oktober 2006 um 21:55

Zitat:

---

Man kann ja trotzdem ohne Probleme noch zusätzlich Rohdaten in einem Container unterbringen. Ich habe mich mal kurz darauf los getippt um grob ein paar Ideen zu illustrieren. Vielleicht sind ja ein paar nützliche Anregungen darunter.

---

Grundsätzlich guter Ansatz, ich würde aber ein paar Dinge ändern:
1. keine Umlaute und andere Sonderzeichen in Tag-Namen. Das ist zwar alles legal, aber auf verschiedenen System unterschiedlich mühsam herzustellen, insbesondere aus Programmen (und ausserdem sind zuverlässige Unicode-Editoren immer noch Mangelware).
2. Umgebungstemperatur-Tag: in dieser Form muss der Inhalt geparst werden, was fehleranfällig ist. Besser
<Umgebungstemperatur unit="C">25</Umgebungstemperatur>. Analog für alle anderen Grössen: Einheit und Grösse immer trennen. So kann man zum Beispiel Umrechnungen oder Umformattierungen vollständig in Stylesheets erledigen, was ja auch richtig ist, da es sich dabei nur um ein Präsentationsproblem handelt. Analog Luftdruck etc.
3. Einheit-Tag: Der Inhalt dieser Tags sollte maschinenlesbar sein, damit Umrechungen in verschiedene Einheitensysteme automatisch erfolgen können. Dazu ist festzulegen, welche Werte möglich sind. Und auch hier: besser keine Sonderzeichen.
4. Inhalt des Messwerte-Tag: #START und #END sind redundant.

Zur Codierung der Daten: Grundsätzlich sollten die Daten so codiert werden, dass man die Daten mit den Methoden von XSLT bearbeiten kann. Dann braucht man für viele Darstellungsmöglichkeiten gar keine Programme mehr, es genügen ein paar Stylesheets. Ich möchte anregen, die Daten sowohl in roher Form (wie von Dir vorgeschlagen) als auch in strukturierter Form (etwas voluminöser) zu codieren, so dass jedes Datenelement über XPath adressierbar ist.

An der Stelle darf man einen wichtigen Punkt nicht aus den Augen verlieren: Das Auslesen des Prüfstands. Mit dem heutigen kompakten & binären PS3 Format dauert das rund 1 Minute. Wie schon weiter oben vorgerechnet würde man bei Umstellung auf "menschenlesbares Textformat" mit dem Zehnfachen rechnen müssen, bei XML eher noch mehr.

Frage 1: Wieso sollte man 10-15 Minuten auf das Auslesen der Daten warten, wenn es auch in einer knappen Minute geht?

Frage 2: Damit der (sagen wir: Atmel Prozessor) überhaupt ein XML Format senden kann, muß er über die Kernfunktionalität hinaus noch alle diese Tags "lernen". Lohnt sich das, und wo liegt der konkrete Vorteil?

Wenn die Schlußfolgerung lauten würde, daß man in der direkten Kommunikation mit dem Prüfstand besser kein Textformat verwendet, dann stünden wir plötzlich vor zwei Formaten. Eines ist das "native Format", in dem der Prüfstand bzw. die zwischengeschaltete Elektronik die Daten sendet. Das andere ist das "Gebrauchs- und Datenaustauschformat" das die auswertende Software aus dem nativen Datensatz erzeugt.

Frage 3: Ist es überhaupt sinnvoll, zwei Formate für dieselbe Sache zu verwenden?

Geändert von Peter am 09. Oktober 2006 um 06:37