Kommen wir doch mal zu einem Format, das im wirklichen Leben zum Betrieb zweier Prüfstände bereits benutzt wird und offenbar bestens funktioniert: Das PS3 Format. Winfrieds Prüfstand sendet den Datenstrom in diesem Format, und mein Programm speichert die Datei, so oft sie aufgerufen wird, erneut in diesem Format. Das Übertragungsformat und das Gebrauchsformat sind also identisch:

Geändert von Peter am 25. April 2008 um 08:55

Auch wenn das im ersten Moment von Olivers Vorschlag abweicht, weil ich beispielsweise keine Zeitmerken verwende, so liegen beide Ansätze nahe genug beisammen, um sie vereinheitlichen zu können. Was im übrigen kein Wunder ist, da wir uns zu diesem Thema seit langem austauschen.

Ich würde die Datensatzbeschreibung allerdings noch radikaler flexibilisieren und für wichtige Eckparameter je ein Byte im Strukturvorspann spendieren. Beispiel:

Byte 20: Anzahl der Kanäle (gibt immerhin 256 mögliche Kanäle, wird in diesem Leben keiner mehr nutzen)
Byte 21: Anzahl der Datenbyte pro Messwert.
Byte 22: Anzahl der Byte pro Zeitmarke

Kann man natürlich weiter ausführen. Aber schon mit diesen drei Parametern geht folgendes:

a) In Edenkoben hätte ich

"1" für die Anzahl der Kanäle in Byte 20 geschrieben,
"2" für die Anzahl der Datenbyte pro Messwert (da 16 Bit Auflösung)
"0" für die Anzahl der Byte pro Zeitmarke (da ich keine Zeitmarke verwende)

b) Oliver könnte z.B. folgendes machen:

"2" für die Anzahl der Kanäle (wenn er Schub und Druck messen würde)
"3" für die Anzahl Datenbyte (wenn er mit 24 Bit arbeiten würde)
"2" damit zu jedem Messwert eine Zweibyte-Zeitmarke hinzugefügt wird.

Diese Vorgaben kann man für jeden Versuch komplett umstellen. Mal messe ich einen Held 5000, mal einen Hybrid, dann gebe ich dem vielleicht vier Kanäle und speichere auch noch die Temperatur. Es richtet sich nur danach, was ich an Mess-Hardware anschließe.
Die Auswertungssoftware würde immer genau wissen, wie sie den Datenstrom zu analysieren hat.

- Trotzdem hätten wir kein festgefügtes Format, sondern großzügig Spielraum.
- Und trotz großer Flexibilität an sich hätten wir Datensätze fester Struktur, die man bequem mit "Zeigern" lesen und auswerten kann.

Für "Designer-Prüfstände" Marke Winfried ist das dadurch zu realisieren, daß der Prozessor des Prüfstands per Firmware dazu gebracht wird, einen Datenstrom dieser Struktur zu senden.

Für den "Volksprüfstand" gibt es zwei Ansätze.: Entweder umgehen wir die beigefügten Utilities und steuern die Hardware selbst an, oder wir nehmen das Zeug was diese Utility schreibt und konvertieren es einmal nach .rmb

Geändert von Peter am 25. April 2008 um 09:20

Hallo Peter,

Die Struktur entspricht bis auf eine Kleinigkeit genau meinem Vorschlag aus diesem Thread. Bei mir ist lediglich die Kalibriertabelle noch im ersten Bereich enthalten, ansonsten verwende ich genau die gleiche Aufteilung. Im Grunde müssten wir jetzt nur noch über die Details zu den einzelnen Sektionen sprechen, dann könnte das Format stehen.

Wenn ich die Info zu Neils LabView-Datenverwaltung richtig verstanden habe, dann scheint es für Neil etwas mehr Aufwand zu bedeuten, wenn er auf dieses Format aufspringen wollte. Ich kenne mich leider mit LawView nicht so gut aus, aber ich denke, mit einem entsprechend programmierten Modul wäre das auch machbar.

Gruß,
Oliver

@Peter:
Du solltest bei den Messwerten die Einheit mitführen ... schließlich geht es darum, die abgespeicherten Werte mit anderen austauschen zu können ... und die Wissen vielleicht nicht unbedingt, welche Sensoren du wo angeschlossen hattest.

mfG
Markus

Edit: Und damit würde ich dann einen zusätzlichen Kanal-Header einführen, der evtl. Skalierungsfaktoren, Zusatzinformationen über den Sensor und dessen Charakteristik oder eine eigene Samplingrate für den Kanal spezifiziert.

Geändert von MarkusJ am 25. April 2008 um 10:17

Also so wie sich das hier liest, scheint mir das Lichtjahre von einem Standard entfernt zu sein. Es ist alles viel zu felxibel aufgebaut. Dort was rein das dieses Angibt und dort was das jenes angibt...

In einem Standard sollte niemanden interessieren welche Charakteristik ein Sonsor hat! Ich habe Daten welche ich in einer Software einlese und daraus möchte ich eine Grafik. Vielleicht noch wann diese erstellt wurde und von wem.

Fixe Samplingrate das überall die gleiche Genauigkeit herrscht. Einheit wird im File definiert.

Viel mehr darf es in einem Standardformat nicht geben.

"Standardformat" hat nichtzwangsläufig was mit "einfach" oder "fix" bzw.
"unflexibel" zu tun. In einem Standardformat werden nur die Regeln
"fest"-gelegt, was aber immer noch zu flexiblen Strukturen der Inhalte
führen kann.

Wir sind auch keine Lichtjahre voneinander entfernt, wenn ich mir Peters
Format anschaue und das mit meinem vergleiche. Es kann allerdings sein, dass
wir beide Lichtjahre von dem entfernt sind, was sich andere von dem Format
vorstellen.

Der Hinweis von MarkusJ mit dem zusätzlichen Kanal-Header ist vollkommen
richtig, in meinem Format bereits enthalten und auch in meinem Format-Vorschlag
aus diesem Thread drin. Das gehört für mich zu den technischen Sensordaten.

Gruß,
Oliver

Hi,

jetzt will ich auch mal wieder meinen Senf dazu geben. Soßen mit Senf schmecken im übrigen sehr gut
Ich bin für ein Klartextformat. Warum? Weil es schon eine Menge Programme gibt die Klartext lesen können. Ein eigenes Byte orientiertes Format wäre diesen Programmen verschlossen.
Aber mit Klartext alleine kommt man auch bei diesen Programmen nicht weiter. Man sollte sich an deren Formatierung halten. Diese Formatierung wiederum basiert auf die Annahme, das ein Menschenlesbarer Text geladen werden soll. Die Daten sollten also so im Format vorliegen das man sie lesen könnte. Dies kann man mit vielen verschiedenen Möglichkeiten hin bekommen. Z.B. mit fixer Spaltenbreite, mit definierten Trennzeichen. So ein Format habe ich mal als Beispieltextdatei angehängt weil das Forum ja bekanntlich doppelte Leerzeichen schluckt.
Was sieht man.
Man sieht eine Beispieldatei von meinem Prüfstand oder dem vom Ernst. Es ist eine Datei die jeder mit Notepad oder einem anderen Textverarbeitungsprogramm lesen kann. Man kann es aber auch einfach mit Excel öffnen. Mit anderen Tabellenkalkulationsprogrammen oder wissenschaftlichen Auswerteprogrammen habe ich es noch nicht getestet.
In der ersten Zeile stehen die Spaltenüberschriften mit der Einheit gefolgt von den ganzen Testparametern und einer Kommentarspalte.
In der zweiten Zeile fangen dann die Messwerte an. Diese haben ein bestimmtes Format. Das Dezimaltrennzeichen ist ein Komma. Es folgen drei Nachkommastellen die bei Bedarf mit Nullen gefüllt werden. Links vom Komma können 5 Zeichen inklusive Vorzeichen stehen. Warum nur so wenig? Nun, ich will ab und zu mal mit Notepad da rein schauen. Bei mehr Zeichen würde die Tabelle zu breit werden um auf den Monitor zu passen. Der maximale Messwert beträgt -9999 bis 99999. Die Frage ist, ob man jemals ein Motor baut der 99999 Newton Schub liefert .Wenn ja, könnte man oben die Einheit wechseln und in kN messen oder irgendwas anderes. Hauptsache es steht oben. Auch für die Zeit sind 5 Zeichen vollkommen ausreichend. Mit den drei Nachkommastellen ist eine Auflösung von 100 Millionen Abstufungen möglich. Das sind weit mehr als 26Bit Auflösung des AD-Wandlers. Also doch mehr als genug.
Da der Text immer eine fixe Breite hat, ist es sehr einfach mit einfachen Programierschritten den Text aus der Datei zu lösen und in eine Zahl umzuwandeln. Mit der Rechenleistung von heute ist das kein Problem mehr.
Was man an diesem Format noch ändern sollte damit es für ein Standard gut genug ist, wäre eine weiter Zeile ganz oben einzufügen. Ich weiß welche Spalte was bedeutet. Ein andere nicht. Daher würde ich dort hineinschreiben was man darunter in den Zeilen findet. Also sowas wie:
Zeit; Kanal 1, Kanal2, Kanal3, Kanalx, Datum, Uhrzeit, Motorbezeichnung, Prüfer, Kommentar

Damit sollte jeder die Datei auf anhieb verstehen.

Gruß

Neil
Anhang: test.txt

Geändert von Neil am 25. April 2008 um 11:29

Sowas ist für mich Standard. Klar definiert, lesbar und ohne Schnickschnack.

LG
Andreas

Hi Oliver,

hast geschrieben als ich es auch tat. Daher nochmal ich. Wir sollten als ersten Schritt auf dem Weg zum Standard festlegen ob wir jetzt Byte orientiert speichern wollen oder lieber Text orientiert. Die Folgen wären:

1. Byte orientiert
- Kleinere Dateien.
- Die Möglichkeit das der Prüfstand die Daten direkt in ein File schreibt.
- Nicht mehr kompatibel zu den üblichen Programmen für die datenanalyse (z.B. Excel)

2. Text orientiert
- etwas größere Dateien.
- Die Möglichkeit weit mehr als nur die eigene Software für die Analyse zu nutzen.
- Der Prüfstand kann nicht die Daten direkt schreiben.


Du hattest ja weiter oben gefragt wie ich die daten von der elektronik bekomme.
Ich mache das in Labview mit einem fertigen Baustein. In einer andere Programmiersprache wird es wohl ein Funktionsaufruf oder ein Objekt sein. Keine Ahnung wie das dort funktioniert.
Ich muss dem Baustein bestimmte Werte vorgeben für die Messung:
- Welche Elektronik soll genommen werden (ich kannz.B. soviele Datenaufnehmer anschließen wie USB verwalten kann)
- Welche Kanäle
- Welche Verstärkung (z.B. +-10V oder +5V)
- Welche Samplerate über alle Kanäle
- Wieviele Messungen über alle Kanäle

Ist das geschehen rennt die Software mit der Hardware los und ich bekomme am Ende der Messung folgende Werte:
- Messung OK oder Fehlercode
- Tatsächliche Samplerate (ich weiß also garnicht wann welche Messung war, muss diese nachträglich berechnen)
- Ein Array von Clustern. Pro Messung ein Arrayeintrag als Cluster wo alle Messwerte der Kanäle drin stehen für diese eine Messung. Format ist Word (16Bit unsign)

Ich muss dann nachträglich das Array von Clustern umwandeln in eine Fließkommazahl. Der Cluster wird dabei zusätzlich mit dem Zeitstempel versehen. Den brauche ich nämlich um einen XY-Graphen damit zu füttern. Bei der Fließkommaumrechnung wird jeder Kanal mit seinen Kalibrierwerten verrechnet. Meist nutze ich Werte um auf SI Einheiten zu kommen.
Mit diesem Array von Clustern steht mir jetzt die gesamte Welt der Kurvenanalyse von Labview 6.1 zur Verfügung. Das ist mehr als ich bis jetzt kapiere und wohl jemals mehr sein wird was Peters Software kann. Nur so als Beispiel könnte ich die Punkte wie Schubspitze oder Brenndauer automatisch bestimmen lassen. Es gehen aber auch so abgefahrene Dinge wie Frequenzanalyse. Ich kann also weiter Kanäle erzeugen wo dann Werte für die akutelle Frequenzen und deren Stärken vorliegen. Das sieht so aus wie bei den Echoloten in den U-Booten.
Später wenn ich dann in eine datei speichere sind es einfache Funktionen die aus dem Array von Clustern eine Tabelle erzeugen.

Gruß

Neil

Geändert von Neil am 25. April 2008 um 11:42

Ich habe ein Problem damit, wenn ich mir das Zeit-Format ansehe. Wenn ich
meine Daten aus dem Prüfstand auf so eine Zeitachse abbilde, dann gehen
mir bereits Informationen verloren. Deswegen kann ich mich nicht richtig
damit anfreunden. Alternative: Die Zeitspalte wird nicht absolut verwendet
sondern enthält direkt den Zeitstempel aus der Messung, der in meinem Fall
alle 0,42s über läuft.

Gruß,
Oliver

Geändert von osmadie am 25. April 2008 um 12:04