Hi,

du hast es nicht ganz verstanden.
Oben steht als Einheit . In der Tabelle mit 3 Nachkommastellen. Also auf 1ms genau. Das ist das was meine Hardware maximal kann. Wil ich mehr, muss ich nur das Modul austauschen und kann dann mit 150kHz samplen. Dann reichen die 1 ms Auflösung nicht mehr. Aber dann kann ich ja oben auch anstatt schreiben. Somit hast du dann die Möglichkeit auf 1/1000000s genau zu bestimmen. Mit den 5 Stellen vor dem Komma kommst du dann auf 99,999s. Reicht das nicht?
Oder habe ich dein Problem nicht verstanden?

Gruß

Neil

Zitat:

---

Original geschrieben von Neil
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.

---

Neil, könntest Du bitte noch eine Originaldatei hochladen, also genau das, was der Prüfstand auf Deinem PC erzeugt? Gerne auch binär

Ansonsten sehe ich in Deiner Argumentation eine Reihe von Irrtümern bzw. Inkonsistenzen. Beispiele:

1) Es ist nicht unsere Aufgabe, die Messdaten auszuwerten, dafür hat man heutzutage einen Computer. Wobei die Hardware des Computers nutzlos ist, solange nicht die richtige Software darauf läuft. Daher ist es völlig gleich, ob die Daten "menschenlesbar" sind. Computerlesbar müssen sie sein. Außer du blätterst eine Textdatei mit zehntausenden von Zahlen durch und malst danach kommentarlos die richtige Schubkurve...

Es würde ja auch keiner auf die Idee kommen, eine "menschenlesbare" XML bzw. RTF Datei "selbst auswerten" zu wollen. Statt dessen nimmst Du z.B. Word, das dir diese Dateien und ihre komplexe Formatierung in aller Vielfalt und Farbenpracht anzeigt.

Drum müssen wir an dieser Stelle eine elementare Wahrheit lernen: Auch Prüfstände brauchen eine spezialisierte Auswertesoftware. Excel kann da nur eine Notlösung für Arme sein, die nix besseres haben.

2) Wenn LabView so toll ist, warum nimmst Du es dann nicht einfach sondern redest dauernd von Excel?

3) Auch eine "menschenlesbare" Textdatei ist binär gespeichert. Ihren Inhalt kannst du nur lesen, wenn du ein geeignetes Tool nimmst, beispielsweise Notepad oder Wordpad, das diese binären Inhalte für dich umsetzt. Ohne dieses Tool ist dieser Text nämlich ein für dich nicht wahrnehmbares Magnetmuster.

4) Es ist ein Irrtum, wenn du davon redest, die Anzahl der Stellen vorzugeben. Die gibt in Wirklichkeit der AD-Wandler deines Prüfstands vor. Hat der 16 Bit Auflösung, dann liefert er 2-Byte Messwerte. Wenn Du die in Klartext umwandelst und dran herummachst, hast du rein garnix gewonnen. Darum nehmen Oliver und ich die Werte einfach originalgetreu so, wie die Hardware sie liefert.

5) Die Brenndauer automatisch bestimmen zu wollen, würde man bei Ärzten einen "Kunstfehler" nennen. Es hat sich hochgradig bewährt, daß der Benutzer den Moment der Zündung und das Schubende selbst markiert. Mit etwas mehr Praxis wirst Du mir recht geben.

Und wenn Du schon Ernst erwähnst: Der ist daran interessiert, seinen Prüfstand irgendwie mit meiner Software zu verbinden. Ich bin an dieser Stelle gerne für den offenen Wettbewerb: Nehmen wir doch Excel. Labview, weitere Tools und mein Programm bzw. das von Oliver und sehen zu, was Ernst am Ende mehr überzeugt. Das wäre dann nämlich ein wichtiger Schritt hin zu einem Softwarestandard für den "Volksprüfstand".

Geändert von Peter am 25. April 2008 um 13:36

Ich sage es gerne noch einmal: Ich empfehle dringendst, die Prüfstandkommunikation NICHT als Maßstab für das RMB-Format heranzuziehen.
Das RMB-Format soll doch prüfstandunabhängig sein, oder? Was macht man jetzt mit Prüfständen, die gar keinen µC haben?
Bitte trennt die Protokollebene/Prüfstandtreiberebene vom Austauschformat, nur so wird das RMB-Format flexibel und akzeptiert werden.

mfG
Markus

Zitat:

---

1) Es ist nicht unsere Aufgabe, die Messdaten auszuwerten, dafür hat man heutzutage einen Computer. Wobei die Hardware des Computers nutzlos ist, solange nicht die richtige Software darauf läuft. Daher ist es völlig gleich, ob die Daten "menschenlesbar" sind. Computerlesbar müssen sie sein. Außer du blätterst eine Textdatei mit zehntausenden von Zahlen durch und malst danach kommentarlos die richtige Schubkurve...

---

Wenn ich eine Software ein neues Dateiformat beibringen muss und ich bin kein Profiprogrammierer sondern nur einer der in seiner Freizeit mal zwischendurch was programmiert, dann bin ich sehr dankbar das ich mir die Datei auch mal so als Mensch anschauen kann.
Noch was zu dem "wir haben ja einen Computer der das für uns macht und wir verlassen uns darauf" blabla. Ich habe in meinen fünf Jahren als Projektleiter und Inbetriebnehmer gelernt, das man keiner Software trauen darf. Ich habe Stunden damit verbracht Text orientierte Dateien mit zig tausenden von Messergebnissen durchzusuchen um letzten Endes nicht den Fehler beim Bediener sondern in der Software zu finden. Hätte ich die Möglichkeit nicht gehabt mir die Rohdaten in für Menschen leßbarer form anzuschauen, wäre der Fehler nie gefunden worden. Das ist im übrigen nicht nur einmal passiert sondern mehr mals.
Zurück zum Prüfstand. Als ich diesen entwickelt habe, hat die Software auch nicht auf anhieb funktioniert. Die Daten die ich mir in einem anderen Programm anschauen wollte paßten nicht. Nur weil ich die Datei als Mensch lesen konnte, konnte ich den Fehler finden. Mit einer Byte orientierten Datei hätte ich den vielleicht auch gefunden aber viel später.

Zitat:

---

Es würde ja auch keiner auf die Idee kommen, eine "menschenlesbare" XML bzw. RTF Datei "selbst auswerten" zu wollen. Statt dessen nimmst Du z.B. Word, das dir diese Dateien und ihre komplexe Formatierung in aller Vielfalt und Farbenpracht anzeigt.

---

Wenn am Ende nicht ein Mensch drauf schauen soll, warum machst du überhaupt eine Ausgabe? Mach doch einfach ein Programm was munter bei der Auswertung der Dateien Rechenleistung verbraucht aber keine Ausgabe macht. Minimal kannst du ja ein piepen oder blinken am PC auslösen der dir dann auf Bit Ebene mitteilt das alles okay ist. Mehr braucht es ja nicht. Der Mensch muss es nicht lesen können, reicht wenn der PC es versteht.

Zitat:

---

Excel kann da nur eine Notlösung für Arme sein, die nix besseres haben.

---

Genau für die habe ich einen Export nach Excel gemacht. Für den größten Teil der Menschheit der keine spezialisierte Prüfstandssoftware hat. Damit so viele wie Möglich die Daten verarbeiten können.

Zitat:

---

2) Wenn LabView so toll ist, warum nimmst Du es dann nicht einfach sondern redest dauernd von Excel?

---

Weil vielleicht mehr Menschen Excel haben als LabView. Ich möchte mich an dieser Stelle mal selber zitieren um zu zeigen das ich nicht auf Excel herum reite sondern du.

Zitat:

---

... Weil es schon eine Menge Programme gibt die Klartext lesen können. Ein eigenes Byte orientiertes Format wäre diesen Programmen verschlossen....Es ist eine Datei die jeder mit Notepad oder einem anderen Textverarbeitungsprogramm lesen kann. Man kann es aber auch einfach mit Excel öffnen.

---

Sie genau hin, da steht "auch" und nicht "nur". Wenn du schon auf Byteebene arbeitest, sollten dir solche Feinheiten auffallen. Danach folgt sogar noch ein Satz

Zitat:

---

Mit anderen Tabellenkalkulationsprogrammen oder wissenschaftlichen Auswerteprogrammen habe ich es noch nicht getestet.

---

Wenn du dir mal den Inhalt des Satzes anschaust, den mußt du ja interpretieren wie so eine Byte orientierte Datei, dann steht da als Information das auch andere Tabellenkalkulationsprogramme die Datei wohl auch lesen können, weil alle einen Import auf Textbasis haben, ich es aber noch nicht ausprobiert habe weil ich kein anders habe.
Trotz alle dem, kann mein Format schon mal von mehr Software gelesen werden als deins. Wieviele Programme können deine Daten lesen?

Zitat:

---

3) Auch eine "menschenlesbare" Textdatei ist binär gespeichert. Ihren Inhalt kannst du nur lesen, wenn du ein geeignetes Tool nimmst, beispielsweise Notepad oder Wordpad, das diese binären Inhalte für dich umsetzt. Ohne dieses Tool ist dieser Text nämlich ein für dich nicht wahrnehmbares Magnetmuster.

---

Das ist jetzt nicht dein ernst oder? Ich nehme das mal als Scherz auf und nicht als dein letztes Argument gegen eine Text orientierte Datei.

Zitat:

---

4) Es ist ein Irrtum, wenn du davon redest, die Anzahl der Stellen vorzugeben. Die gibt in Wirklichkeit der AD-Wandler deines Prüfstands vor. Hat der 16 Bit Auflösung, dann liefert er 2-Byte Messwerte. Wenn Du die in Klartext umwandelst und dran herummachst, hast du rein garnix gewonnen. Darum nehmen Oliver und ich die Werte einfach originalgetreu so, wie die Hardware sie liefert.

---

Das ist kein Irrtum von mir sondern von dir weil du das so sehen willst. Nur weil ich da jetzt drei Nachkommastellen habe heißt es noch lange nicht das dadurch die Genauigkeit besser wird. Es kann sein, das der AD-Wandler bessere Werte liefert die dann auf drei Stellen gerundet werden müssen. Es kann aber auch sein, das der AD-Wandler so schlecht ist, das die letzten beiden Stellen immer das gleiche darstellen. Ich habe mit meiner Aussage zeigen wollen, das die Anzahl der Stellen vor und nach dem Komma ausreichend sind um ein Ergebnis darzustellen, ohne es schlechter zu machen, was einem 26Bit Wert entspricht. Das bedeutet, das dein 16Bit AD-Wandler in deinem Prüfstand keinen Datenverlsut erleiden wird und schlechtere Ergebnisse liefert in Textform als Byte.

Zitat:

---

5) Die Brenndauer automatisch bestimmen zu wollen, würde man bei Ärzten einen "Kunstfehler" nennen. Es hat sich hochgradig bewährt, daß der Benutzer den Moment der Zündung und das Schubende selbst markiert. Mit etwas mehr Praxis wirst Du mir recht geben.

---

Das war nur ein Beispiel wozu die Software in der Lage wäre. Anders herum gefragt, wenn ich am Ende doch selber noch was zu der Kurve sagen muss, warum habe ich dann eine Software die mir den Motor vermißt? Ich könnte genau gut auch die Rakete einfach starten lassen und sagen "Ja das war gut."

Zitat:

---

Das wäre dann nämlich ein wichtiger Schritt hin zu einem Softwarestandard für den "Volksprüfstand".

---

Ist es nicht ein großer Fehler einen Standard an einer Person fest zu machen? Sollte man nicht lieber ein Format wählen was die meisten Menschen erreicht? Wenn ja, dann wäre eine Datei sinnvoll die von den ganzen auf dem Markt zu findenden Simulationssoftwaren gelesen werden kann. Ich kann mich schwach erinnern das diese auf Text basiert waren damit jeder User seine eigenen Dateien mit Notepad oder weiß der Geier was erstellen kann. Leider wird an diesen tausenden von Menschen deine Software spurlos vorbei ziehen weil sie die einfach nicht nutzen können.

Mir sind bis jetzt nur Gründe für Text orientiert eingefallen aber keine so richtig dagegen. Außer diese Programmierfaulheit von den Byteschiebern.

Am Schluß möchte ich Makrus Meinung unterstützen. Wir sollte den Datenstrom vom MC zur Software trennen von der Datei die wir speichern.

Gruß

Neil

Zitat:

---

Original geschrieben von Neil

Zitat:

---

Ich habe Stunden damit verbracht Text orientierte Dateien mit zig tausenden von Messergebnissen durchzusuchen um letzten Endes nicht den Fehler beim Bediener sondern in der Software zu finden. Hätte ich die Möglichkeit nicht gehabt mir die Rohdaten in für Menschen lesbarer form anzuschauen, wäre der Fehler nie gefunden worden. Das ist im übrigen nicht nur einmal passiert sondern mehr mals.

---

Gruß
Neil

---

Hallo Neil,

das kann ich nur bestätigen...
Und wenn ich die Diskussion so verfolge, dann wurde zwar gefragt, wie man das Format den aufbauen könnte, aber so richtig bereit scheint keiner zu sein von seinem Standpunkt abzuweichen.
Wenn ihr mich fragt: Hierbei kommt NIX raus... das ganze wird sich im Sand verlaufen...

Gruß
Tom

Solange es Leute wie Peter gibt, die glauben die Lösung für alle gefunden zu haben und nicht davon abzubringen sind kann man diesen Thread auch gleich schließen.

@Peter:

Ein Standard ist dann ein Standard wenn er von vielen Leuten verarbeitet und verwendet werden kann. Niemand wird das Byteformat verwenden weil es einfach nicht lesbar ist. Ein Textorientiertes Format öffne ich mit einem Texteditor und sehe wie die Daten aufgebaut sind. Dann kann ich meine Software schreiben. Bei einem Byteformat habe ich keine Ahnung was ich da einlese und wie ich das einlesen soll wenn es keine präzise Dokumentation gibt. Und diese wird es nie geben wenn es so flexibel aufgebaut werden soll wie es schon beschrieben wurde.


Excel ist am weitesten verbreitet und kann mir meine Daten auswerten. Was kann deine Software so besonderes das ich die verwenden soll? Oder was kann andere Software so spezielles?

LG
Andreas

Zitat:

---

Original geschrieben von Blackpuma
Niemand wird das Byteformat verwenden weil es einfach nicht lesbar ist. Ein Textorientiertes Format öffne ich mit einem Texteditor und sehe wie die Daten aufgebaut sind. Dann kann ich meine Software schreiben. Bei einem Byteformat habe ich keine Ahnung was ich da einlese

---

Wer so argumentiert, hat in der Tat keine Ahnung. Nochmal: Jede Datei besteht aus Magnet- der sonstigen Mustern auf einem Datenträger, wozu ich auch das RAM rechne. Um eine Datei lesen zu können, benötigst du ein Tool, das diese Muster für dich lesbar macht.

Von wegen "Wenn ich die Textdatei sehe, weiß ich, wie sie aufgebaut ist". Du siehst das, was dein Tool dir vorgaukelt. Woraus besteht die Zeilenschaltung- aus 0D 0A? oder nur aus 0A? Das siehst du nicht, weil es im Textformat unsichtbar bleibt. Und die größeren Abstände- sind das alles Leerzeichen, oder stecken da auch echte Hex09 Tabs dazwischen? Auch das bleibt beim bloßen Hinschauen völlig offen.

Du kopierst mal eben "Text" aus der Textdatei in Excel? Du würdest dich wundern, was Excel daraus macht, nur zeigt es dir das nicht. Auch "einfache" Tools können dir simplen Text vorgaukeln- und speichern in Wirklichkeit, sagen wir, in Unicode. Das sind dann 2 Byte, und wenns UTF-8 ist, können es noch mehr sein. Aber keine Angst- du "siehst" es ja eh nicht.

Vielleicht hat das Fehlersuchen ja deshalb Stunden gedauert, weil Neil und Tom die Textdatei genommen haben, statt sich den wirklichen Inhalt der Datei mit einem Hex-Editor anzusehen? Ob du nun Notepad oder einen Hex-Editor verwendest, beides sind Tools zum Lesen von Dateien. Allerdings: Der Hex-Editor zeigt alles an. Jede Datei. Egal wie binär.

Wenn ich beim Prüfstand jemals Fehler suchen muß, insbesondere beim Datenstrom in den Computer, dann schaue ich mir natürlich die Datei mit einem solchen Hex-Editor an. Ich will ja möglichst nur Minuten und keine Stunden mit der Fehlersuche zubringen.

Die Darstellung im Textformat ist nur ein Gimmick am Rande, und auch weniger für die Fehlersuche, sondern mehr für den Enduser. Beispiel: Die SALT-Software. Da kannst du den Report öffnen, und das ist nichts anderes als der gesamte Inhalt der -selbstverständlich binären- SALT Datei, ausgegeben in Textformat und mit Kommentaren.

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

Zitat:

---

Original geschrieben von Peter

Wer so argumentiert, hat in der Tat keine Ahnung. Nochmal: Jede Datei besteht aus Magnet- der sonstigen Mustern auf einem Datenträger, wozu ich auch das RAM rechne. Um eine Datei lesen zu können, benötigst du ein Tool, das diese Muster für dich lesbar macht.

---

Freut mich das du dir angeschaut hast wie eine Festplatte Daten speichert. Aber was interessiert mich das? Ich habe mein Programm das mir die Daten so ausgibt das ich was damit anfangen kann.

Zitat:

---

Original geschrieben von Peter
Von wegen "Wenn ich die Textdatei sehe, weiß ich, wie sie aufgebaut ist". Du siehst das, was dein Tool dir vorgaukelt. Woraus besteht die Zeilenschaltung- aus 0D 0A? oder nur aus 0A? Das siehst du nicht, weil es im Textformat unsichtbar bleibt. Und die größeren Abstände- sind das alles Leerzeichen, oder stecken da auch echte Hex09 Tabs dazwischen? Auch das bleibt beim bloßen Hinschauen völlig offen.

---

Was interessiert mich das HEX Format? Wenn ich meine Textdatei habe (sprich CVS) habe ich in jeder Zeile einen Datensatz. Die einzelnen Daten sind durch ; oder , getrennt. Damit habe ich kein Problem die Daten in mein Programm zu integrieren.

Beispiel:

Kanal1: Schub
Kanal2: Temperatur
Kanal3: Umgebungstemperatur
Sample: 1ms


Sample;Kanal1;Kanal2;Kanal3
0001;12;23;12
0002;13;42;15
.
.
.
0120;24;234;45


Wenn du das Beispiel in einem Texteditor ansiehst kannst du mir nicht erklären das sich da jemand nicht auskennt.

Zitat:

---

Original geschrieben von Peter
Du kopierst mal eben "Text" aus der Textdatei in Excel? Du würdest dich wundern, was Excel daraus macht, nur zeigt es dir das nicht. Auch "einfache" Tools können dir simplen Text vorgaukeln- und speichern in Wirklichkeit, sagen wir, in Unicode. Das sind dann 2 Byte, und wenns UTF-8 ist, können es noch mehr sein. Aber keine Angst- du "siehst" es ja eh nicht.

Vielleicht hat das Fehlersuchen ja deshalb Stunden gedauert, weil Neil und Tom die Textdatei genommen haben, statt sich den wirklichen Inhalt der Datei mit einem Hex-Editor anzusehen? Ob du nun Notepad oder einen Hex-Editor verwendest, beides sind Tools zum Lesen von Dateien. Allerdings: Der Hex-Editor zeigt alles an. Jede Datei. Egal wie binär.

---

Also du willst wirklich das sich die Leute wegen dir in einen HEX Editor einarbeiten müssen nur weil sie dein Datenformat in ihr Programm integrieren möchten?

Zitat:

---

Original geschrieben von Peter
Wenn ich beim Prüfstand jemals Fehler suchen muß, insbesondere beim Datenstrom in den Computer, dann schaue ich mir natürlich die Datei mit einem solchen Hex-Editor an. Ich will ja möglichst nur Minuten und keine Stunden mit der Fehlersuche zubringen.

Die Darstellung im Textformat ist nur ein Gimmick am Rande, und auch weniger für die Fehlersuche, sondern mehr für den Enduser. Beispiel: Die SALT-Software. Da kannst du den Report öffnen, und das ist nichts anderes als der gesamte Inhalt der -selbstverständlich binären- SALT Datei, ausgegeben in Textformat und mit Kommentaren.

---

Das ist schön. Was soll ich nun als Enduser mit der SALT Datei?? Ich kann damit nichts anfangen. Wie soll ich diese Datei in mein Programm integrieren? Was soll ich mit Daten die ich nicht enschlüsseln kann?

Hi,

Zitat:

---

Vielleicht hat das Fehlersuchen ja deshalb Stunden gedauert, weil Neil und Tom die Textdatei genommen haben, statt sich den wirklichen Inhalt der Datei mit einem Hex-Editor anzusehen?

---

Nein haben ich nicht. Es gab da keine Datei die man sich im Hex-Editor ansehen konnte. Es hat einfach Stunden gedauert weil der Programmierer Scheiß gebaut hat und er es nicht einsehen wollte.

Im übrigen interpretiert dir dein Hex Editor auch nur die eigentliche Information die aus 0 und 1 besteht. Wer sagt denn das die Daten in 8 Bit vorliegen und nicht in 9? Aber warte mal, ist ein gesetztes Bit jetzt als 0 oder 1 zu betrachten? Liest man das von links nach rechts oder umgekehrt?

Gruß

Neil

Geändert von Neil am 25. April 2008 um 22:23

Hi,

mir viel noch etwas ein zu dem Thema Maschinenleßbar oder Menschenleßbar.
Die etwas älteren unter uns werden sich noch an eine Zeit erinnern wo man schnell einkaufen gehen konnte. Warum war das so? Nun die Ware hatte einen Preis. Der wurde mit einem kleinen Aufkleber auf der Ware angebracht. Da stand klar und deutlich für alle leßbar "7,99DM". Die Person an der Kasse, ich nenne sie immer gerne Kassentante was nicht böse gemeint ist, mußte also nur die Zahlen per Tastatur in die Maschine eingeben und noch das Komma richtig positionieren. Fertig war der Vorgang.
Dann aber kam die Menschheit auf diese Idee hier, gefunde bei computerwissen.de



Die von uns allen geliebten Barcodes. Wofür sind die gut? Nun, es sind für die Maschinen leßbare Informationen. Die Maschine erkennt mit einem Laser den Code und kann aus der Kombination von dicken und dünnen Linien Werte erzeugen die dann in einer Datenbank zu dem gewünschten Preis führen. Die Idee war, das der Vorgang an der Kasse schneller werden sollte und das man gleich in der Datenbank wußte wann welches Produkt dem Ende entgegen ging. Ist das aber wirklich so eingetreten? Nein, im Gegenteil. Da das Personal an der Kasse nun nur noch die Ware über den Scanner ziehen mußte, war es hochgradig motiviert. Die Stimmung nahm deutlich ab. Mit regelmässiger Häufigkeit wollte der Automat den Barcode nicht lesen. Das lag daran, das der Aufkleber Falten hatte, der Scanner dreckig war, oder der Code nicht richtig am Scanner vorbei geführt wurde. Auch nach mehrmaligen Versuch, meist so um die 20 mit schütteln und drücken und fluchen, konnte der Automat nichts erkennen. Wie konnte man das Problem lösen, wie findet man jetzt den Preis heraus? Ein Weiser Mann kam auf die Idee, doch direkt unter dem Barcode eine Zahlenkolone hin zu drucken die von Menschen gelesen werden konnte. Dank dieser Hilfestellung war der Automat in der Lage doch noch die Ware in der Datenbank zu finden oder auch nicht. Den nicht immer steht die Ware auch in der Datenbank drin. Was dann, kostete die etwa nichts? Schaut man sich den Aufwand an, könnte man wirklich Produkte bis einige Euro lieber in diesem Falle verschenken als abzuwarten bis der Preis gefunden wurde. Es gab da noch eine Lösung die es so in ziemlich jedem Geschäft gibt. Neben oder über der Kasse befindet sich ein Ordner wo in Klartext drin steht: Orange 1kg = 2,95€. Dieser Ordner gefühlt nur mit für Menschen leßbare Information sorgt tagtäglich dafür das Millionen Menschen nicht verhungern müssen was sie sonst wären, wenn es nur Maschinenleßbare Barcodes geben würde.

Genug der Unterhaltung kommen wir zurück zu unserem Standardproblem. Ein Standard ist ja etwas worauf man sich einigt. Das muss nicht umbedingt sinnvoll sein, aber es sorgt dafür man überall mit seinem Standard zurecht kommt. Nehmen wir mal Schrauben. In Deutschland haben wir den metrischen Standard. Der steht auf jeder Packung codiert in der Größeangabe. M5 für 5mm Schrauben. Das tolle ist, jeder Hersteller egal wo auf der Welt der M5 Schrauben herstellt wird diese in jedem Gewinde oder Mutter nach M5 hinein bekommen das ist doch toll. Ob nun M5 die ideale Lösung für diese Größe von Schrauben ist, sei dahin gestellt. Der Vorteil liegt einfach daran das sich jeder daran hält.
KOmmen wir zurück zu unserem Versuch einen Standard einzuführen. Es gibt schon bestehende Standards an die wir uns tunlichst halten sollten. Sowas wo drin steht welches Bit welchen Wert hat und in welcher Reihenfolge diese dort abgelegt sind. Oder bei Text eben ob er auf ASCII oder irgend einen anderen Standard basiert. Wie man da ran geht ist völlig egal, solange man sich einig ist das alle das gleiche machen. Die Geschichte mit dem Barcode soll zeigen, das es durchaus Sinn macht in Klartext Informationen zu speichern und sich nicht blind auf die Maschinen zu verlassen. Ob nun Byte oder Text, in beiden Fällen sollte doch klar sein, das wenn man sich an den Standard hält, jede beliebige Information gespeichert werden kann. Es wird in beiden Fällen alles möglich sein. Der Klartext wird aber dem Programmierer der sich an seine eigene Software heranwagt es viel leichter machen diese Format einzubinden, weil er es einfach besser selber sehen kann.

Falls wir hier nicht zu einer Lösung kommen, so ist mir noch eine neutrale Lösung eingefallen. Wir nutzen ein Format was es schon gibt, was sehr leicht zu implementieren ist. Es kann sowohl vom Menschen gelesen werden, ist aber Byte orientiert. Wir nutzen ganz einfach das unkomprimierte BMP Format und hinterlegen die Daten direkt als Grafik. Mit den einfachsten Bildbetrachtungsprogrammen ist der Benutzer in der Lage an die Information zu kommen. Bei dem vielen ungenutzen Platz in der Datei, kann man Klartext und Barcode einfügen wo der Rest der Information drin steht die man braucht. da steht dann gut leßbar sowas wie "Motor war einfach scheiße" Darunter das ganze in den Pixeln (oder Bytes kodiert) die Information für den Computer damit er das in eien Variable einlesen kann.
Also, das Format gibt es. Es erfüllt beide Wünsche. Wir müssen uns nur einigen, wie wir den Barcoe plazieren damit der Computer den wiederfindet.

Gruß

Neil