Hallo Leute, ich habe hier eine Datei, geloggt aus einer RS232-Schnittstelle. Ca 5sek lang. Kann mir einer sagen, welche Baudrate es ist? Habe es mit 115k probiert. Kann man das mit einer Log-Datei feststellen? Oder bedarf es da spezieller Geräte? Vielen Dank.
So geht das nicht. Du musst zuerst die richtige Baudrate einstellen, sonst empfängt dein Anschluss nur Müll.
Da Einfachste ist mit einem Oszilloskop die Zeit fuer ein Bit zu messen.
Michael Glaser schrieb: > Kann mir einer sagen, welche Baudrate es ist? ja, "geloggt" mit 115k (test_115.log) was drin steckt, das ginge mit der richtigen Baudrate loggen oder Oszi und beim loggen ansehen.
Michael Glaser schrieb: > Kann man das mit einer Log-Datei feststellen? Nicht mit dieser. Verschiedene Baudraten ausprobieren ginge mit einer Log-Datei, in der alle Flanken des Signals mit Zeitstempel aufgezeichnet sind, die hast du aber nicht. Mein Protokollanalysator macht das so, der hat aber sowieso auch eine Funktion zur Baudratenerkennung. Wobei zu beachten ist: man muss nicht nur die Baudrate herausfinden, sondern auch die Parameter Wortlänge, Parity, Stoppbits, um was vernünftiges zu empfangen. Das ergibt mehr als 100 Varianten. Georg
Für alle i∈[0,98] hat das Byte an der Position 4+260·i den Wert 53+i. Zufall? Wenn nicht, dann hast du die richtige Baudrate bereits gefunden. Wenn du etwa dreimal so viele Daten (also statt 5 ca. 15 Sekunden) aufzeichnest, müsste dieses Zählerbyte irgendwann überlaufen. Falls dann eines der beiden Nachbarbytes inkrementiert wird, kannst du ziemlich sicher sein, dass die Daten mit Absicht so aussehen und damit die 115200 Baud stimmen.
:
Bearbeitet durch Moderator
Angehängte Dateien:
-
log.png
6,1 KB
Ich hab mir das File mal mit nem simplen Textviewer angeschaut. Interessant die rot eingerahmte Spalte. Fällt da was auf? ;) Das ist viel zu viel System für ne zufällige Zeichenfolge aufgrund falsch eingestellter Baudrate. Ich denke daher, dass die 115 kBd schon völlig korrekt sind, nun muss man nur noch herausfinden, was die Daten zu bedeuten haben.
Hei, super beobachtet. Habe das File auch schon offengehabt, aber irgendwie nichts bemerkt. Aber jetzt wo Du's sagst! :-)) Auch in Col 14 und 256 gibt es so ändernde Zeichen, aber ohne ersichtliche Reihenfolge. Bis jetzt bin ich immer davon ausgegangen, dass es eine viel niedrigere Baudrate ist, und einfach bei steigenden Flanken ein Startbit sieht, auch mitten im Zeichen. Sich ändernde Zeichen würden dann grössere Sprünge machen als nur Inc/Dec um 1. Damit ist wohl ziemlich sicher dass es hundertfünfzehn-zweihundert ist... Gruss Chregu
Christian M. schrieb: > Hei, super beobachtet. Das geübte Programmierer-Auge erkennt sofort die ASCII-Tabelle, wenn es sie sieht. ;)
Vielen Dank für eure Unterstützung . Also kann man davon ausgeben,daß die 115kb stimmen. Ist das möglich, dass die Zeichen der umrahmten Stelle ein startbit ist? oder ein zeit/index-Wert? sind denn alle Zeichen immer glei,oder ändert sich da auch -abgesehen von dem index-wert - noch ein anderer Wert?.
Nein, das Startbit siehst Du nicht. Das ist beim Übertragen im Zeichen "enthalten" und wird dann wieder "entfernt". Ausser den von sylaina gezeigten Zeichen, die in der ASCII Tabelle stehts um eins steigen, eben noch das 14. und 256. Zeichen. Am Ende der Zeile ist ein LF, und sonst eine Menge NUL. Öffne das Ganze mal in einem Texteditor, der auch nicht druckbare Zeichen darstellen kann, oder in einem HEX-Editor! Nur Du weisst, von was einer Maschine/Apparat sie kommen... Gruss Chregu
Christian M. schrieb: > Nein, das Startbit siehst Du nicht. Das ist beim Übertragen im Zeichen > "enthalten" und wird dann wieder "entfernt". Das ist nur die halbe Wahrheit und funktioniert nur, wenn der Empfänger richtig synchronisiert hat. Dir richtige (Neu-)Synchronisation auf das Startbit funktioniert nur, wenn der Empfänger vorher im Wartezustand war. Innerhalb eines kompakt (i.e. ohne Pause zwischen den Zeichen) übertragenen Blocks, hat der Empfänger keine Garantie, dass er nicht irgendein Bit als vermeintliches Startbit auffasst, wenn er vorher nicht richtig auf Start/Stop-Bits "eingerastet" war. Meist wird er sich irgendwo im Block wieder fangen, aber bis dahin kann durchaus Müll rauskommen und Start-Stop-Bits als vermeintliche Datenbits - Statistik eben.
M. K. schrieb: > Ich hab mir das File mal mit nem simplen Textviewer angeschaut. > Interessant die rot eingerahmte Spalte. Fällt da was auf? ;) > Das ist viel zu viel System für ne zufällige Zeichenfolge aufgrund > falsch eingestellter Baudrate. Ich denke daher, dass die 115 kBd schon > völlig korrekt sind, nun muss man nur noch herausfinden, was die Daten > zu bedeuten haben. Gute Arbeit, Holmes! :-) Weitere These: Sieht so aus, als ob das } ein Framestartzeichen und das ~ ein Frameendzeichen ist (so ein bisschen an PPP angelehnt). Ich würde mal etwas länger mitschneiden und sehen, ob in dem "variablen" Part (also die ASCII Tabelle durch) diese beiden Zeichen mit durchlaufen werden. In einem sauber spezifizierten Protokoll dürfen nämlich die Framingzeichen innerhalb des Frames nicht auftauchen, damit der Datenstrom sauber auf das Frame synchronisiert werden kann. Die müssten dann durch Transposition o.ä. manipuliert werden. Also nochnmal mitschneiden (mindestens 256 Zyklen)!
Hallo Leute, nach etwas Pause, konnte ich eine neue Datei erstellen. Was meint ihr? vielen Dank.
Die enthält ja nur 00- und E0-Bytes. Da war deine erste Datei spannender :)
Na prima :( Neuer Versuch :) Ist jetzt was sinnvolles, zum ersten Beispiel passendes passiert? Vielen Dank.
Was für eine Antwort erwartest Du? Die Baudrate scheint immernoch zu passen. Wie die Daten zu interpretieren sind, musst Du wissen. Vielleicht kann hier jemand dabei helfen, wenn Du sagst woher die Daten stammen...
Ich erwarte keine Antwort, ich würde mich nur über die Antwort "ja, diesmal hat es geklappt, Daten sind dem Muster entsprechend" freuen ;) Nein, weil man ja die Daten vom Muster einem Gerät zuordnen könnte, nicht umgekehrt. Wer die Daten kennt, kennt auch ein Gerät dazu :)
Michael Glaser schrieb: > Habe es mit 115k probiert. Warum? Hast du es auch mal mit anderen Baudraten "probiert"? Es gibt ja nicht allzuviele "genormte"...
So auf die Schnelle: Man kann die Daten ähnlich wie im ersten Beispiel in Abschnitte unterteilen, die sich in ähnlicher Form wiederholen. Allerdings waren diese Abschnitte im ersten Beispiel 260 Byte groß, jetzt sind es nur noch 256 Byte. Außerdem werden vor dem ersten dieser gleichartigen Abschnitte noch Daten übertragen, die nicht in dieses Schema passen (vielleicht eine Art Startmeldung). Wie im ersten Beispiel enthält jeder dieser Abschnitte eine Art fortlaufende Nummer. Im erste Beispiel wurde diese von 53 bis 151 hochgezählt. Da diese Zahlen mit 8 Bit darstellbar sind, war es nicht klar, ob diese Nummer aus einem einzelnen oder aus mehreren Bytes bestehen (s. mein Beitrag vom 30.5.). Im neuen Beipiel kann man erkennen, dass die Nummer aus zwei Bytes im Little-Endian-Format zusammengesetzt ist. Ihr Wert reicht von 11 bis 2372. Der Bytestrom enthält somit eine aufsteigende Sequenz von über 2000 16-Bitzahlen, die kaum durch falsche Abtastung entstanden sein kann. Die 115 kbaud würde ich damit als endgültig gesichert ansehen. Vielleicht schaue ich mir die Daten heute Abend noch einmal etwas genauer an. Darf man fragen, von welchen Geräten diese Daten stammen?
Das hört sich schon besser an, vielen Dank :) Ist ein Steuergerät einer Automatiesierungsmaschine, so einer Art Fräs/Drehmaschine Habe ich das richtig verstanden: beim ersten, kurzen Log sind es 260Zeichen zwischen Anfangs- und Endzeichen. Jetzt, beim 2ten Log, sind es 256 Zeichen?
Angehängte Dateien:
-
byte002-003.png
63 KB -
byte161-161.png
74 KB
Michael Glaser schrieb: > Habe ich das richtig verstanden: beim ersten, kurzen Log sind es > 260Zeichen zwischen Anfangs- und Endzeichen. Jetzt, beim 2ten Log, sind > es 256 Zeichen? Es gibt keine expliziten Anfangs- und Endzeichen und auch keine Prüfsumme zur Erkennung von Übertragungsfehlern, was bei einem auf RS-232 laufenden Kommunikationsprotokoll schon etwas seltsam ist. Hier sind ausschnittsweise drei Beispieldatensätze aus der neuen Log-Datei:
1 | <——————————————————————————————— 256 Bytes ———————————————————————————————> |
2 | 0b 00 ... 91 01 00 8d 02 00 7b 23 01 ... 2d 05 64 47 ... 64 49 8b ... 00 00 |
3 | 0c 00 ... 95 01 00 8d 02 00 7b 24 01 ... 2d 05 64 3d ... 64 49 8b ... 00 00 |
4 | 0d 00 ... 94 01 00 8d 02 00 7b 24 01 ... 2d 05 64 33 ... 64 49 8b ... 00 00 |
Die ersten beiden Bytes bilden die fortlaufende 16-Bit-Nummer, von der ich oben schrieb (hier also dezimal 11, 12 und 13). Man erkennt in den Datensätzen an mehreren Stellen ähnliche Bytefolgen. Da diese sich alle 256 Byte in ähnlicher Form wiederholen, kam ich zum Schluss, dass die Datenübertragung wohl in Sätzen zu je 256 Byte erfolgt. Die Log-Datei enthält 592384 Bytes und damit 592384/256=2314 Datensätze. Die ersten beiden davon sind anders aufgebaut als der Rest (der zweite besteht sogar aus lauter Nullen), deswegen betrachten wir nur die 2312 verbleibenden Datensätze. Die Frage ist nun, welche Bedeutung die 256 Bytes jedes Datensatzes haben. Die ersten beiden, also Byte 0 und Byte 1, nummerieren die Datensätze einfach durch. Von den restlichen 254 Bytes ändern sich viele während der Aufzeichnung überhaupt nicht. Möglicherweise ändern sie sich, wenn irgendwelche Komponenten der Maschine aktiviert werden, was aber zum Zeitpunkt der Aufzeichnung nicht geschehen ist. An anderen Stellen ändern sich die Bytes aber tatsächlich, und ich vermute, dass es sich dabei größtenteils um irgendwelche Sensormesswerte handelt, da ihre Werte relativ kontinuierlich steigen und fallen, aber nicht so systematisch wie die laufenden Nummern in den ersten beiden Bytes. Bei einigen Bytes habe ich den Eindruck, dass sie für sich alleine einen 8-Bit-Messwert darstellen, andere scheinen als Byte-Paar einen 16-Bit-Messwert zu bilden. Ich habe die veränderlichen Bytes bzw. Byte-Paare über alle 2312 Datensätze als Digramme (32 Stück) plotten lassen und die Plots als Zip-File angehängt. In den Dateinamen sind jeweils die Byte-Positionen der geplotteten Daten innerhalb der Datensätze angegeben. Zusätzlich habe ich eine Datei mit den 32 Datenreihen in Tabellenform angehängt. Zwei Beispiele dieser Plots habe ich exemplarisch direkt angehängt, damit nicht jeder das ganze Zip-File herunterladen und auspacken muss. Die Daten in byte002-003.png könnten vielleicht den Motorstrom eines der Antriebe darstellen. Die Daten in byte161-161.png könnten vielleicht von einem Inkrementalgeber mit 8-Bit-Zähler stammen, mit dem die Drehzahl bspw. einer ständig laufenden Spindel überwacht und geregelt wird. Einige der Diagrammkurven weisen große Sprünge auf, um dann wieder für eine gewisse Zeit konstant zu verlaufen. Evtl. sind das gar keine Messwerte, sondern Statusinformationen. Um das Ganze genauer zu analysieren, müsste man die gesendeten Daten beobachten, während die Maschine läuft, um zu sehen, wie sie sich bspw. mit der Position und der Geschwindigkeit der einzelnen Antriebe ändern, Einige der im Log unveränderlichen Daten zeigen vielleicht auch den Status von Bedienelementen an und können durch Betätigen derselben zur Änderung bewegt werden. Du hast also noch einige Arbeit vor dir, wenn du tatsächlich das kommunikationsprotokll vollständig analysieren möchtest ;-)
Ich danke für die Analyse und werde wohl das Wochenende deine Ausführungen auswerten, so gut es geht ;) Es gibt also keine Start/Stopzeichen, wie noch beim ersten Log von dir vermutet, richtig? Ich bin jetzt leider total enttäuscht, ich dachte nämlich, daß das der Ansatz ist, die Daten loggen und entschlüsseln zu können? Denn wie soll man den Anfang bzw. das Ende der 256byte finden? Der Datenzähler ändert sich ja und kann so keinen "Nullpunkt" mehr bilden...
Michael Glaser schrieb: > Ich danke für die Analyse und werde wohl das Wochenende deine > Ausführungen auswerten, so gut es geht ;) > > Es gibt also keine Start/Stopzeichen, wie noch beim ersten Log von dir > vermutet, richtig? Ich bin jetzt leider total enttäuscht, ich dachte > nämlich, daß das der Ansatz ist, die Daten loggen und entschlüsseln zu > können? Denn wie soll man den Anfang bzw. das Ende der 256byte finden? > Der Datenzähler ändert sich ja und kann so keinen "Nullpunkt" mehr > bilden... Sehr gute Analyse, Yalu, chapeau!!! Tja, ungeframte serielle Protokolle sind richtig ekelig... dann kann es sein, dass entweder das timing kritisch ist (also z.B. zwischen Ende eines Frames und Start des neuen Frames strikte Zeitvorgaben bestehen) oder aber zusätzliche Leitungen zur Synchronisation benutzt werden. Für beides reicht das logging in der Form nicht aus. Müsstest Du mal ein Oszi ranhängen und möglichst ein komplettes Paket mitschneiden, dabei alle durchverbundenen Leitungen (ausser vielleicht Masse ;-)) anschliessen. Du sagst ja aber, dass das physikalische Protokoll RS232 ist. Hast Du beide Seiten zum loggen zusammengeführt, oder ist das nur der Trace in eine Richtung? Fehlen also vielleicht Soft ACKs, die das Protokoll synchronisieren?
:
Bearbeitet durch User
Michael Glaser schrieb: > Denn wie soll man den Anfang bzw. das Ende der 256byte finden? Es könnte einfach eine Ruhepause zwischen den Datensätzen sein. Diese kann man mit einer Timeoutbehandlung beim Lesen herausfinden. Aus Deinen Logs gehen solche Zeiten (Timestamps) ja leider nicht hervor. Sollten die Daten tatsächlich kontinuierlich übertragen werden, kannst Du Dich nur auf bestimmte Muster einklinken, d.h. Du wartest, bis eine unveränderliche Bytesequenz kommt. Yalu schrieb ja, dass einige Werte innerhalb des Datenstroms konstant sind.
Ja, einige Werte sind konstant, aber wie schon vermutet könnten das auch konstante Bedingungen etc sein. Darauf kann man sich wohl nicht verlassen. Timing? also es ist definitiv nur die RS232-Leitung. Nix weiter, kein Shake oder DX oder so. Wie könnte man denn ein besseres Logging über ein Terminalprogramm einrichten, was speziell auf Timing aus ist?
Michael Glaser schrieb: > > Wie könnte man denn ein besseres Logging über ein Terminalprogramm > einrichten, was speziell auf Timing aus ist? Bei HTerm kannst Du mit Zeitstempeln loggen. Aber wie war das mit der Rückrichtung? Ist die im log mit drin?
Ich benutze Hterm :) 0.81 beta, ist wohl die aktuellste Version...wo stellt man da was sein? Höre ich zum ersten Mal.. Rückrichtung? Die Maschine sendet nur Infos.
Das einfachste wäre ein Logik-Analyser...oder ganz simpel ein Oszi. Bit-Zeit ablesen und in Baud umrechnen. Angenommen die 115k stimmen, was fängst du mit dieser Info an, wenn du nicht weißt, wie die Daten zu interpretieren sind? Denn: Wenn man wüsste wie die Daten (Protokoll) zu interpretieren sind, wüsste man, was an Byte[0], Byte[1] usw. erwartet wird...und dann könnte man die Baud-Einstellung solange ändern, bis es passt. Von was für einem Gerät sind die Daten?
Michael Glaser schrieb: > Wie könnte man denn ein besseres Logging über ein Terminalprogramm > einrichten, was speziell auf Timing aus ist? Indem Du mal 15€ für einen CHina-Logicanalyzer ausgibts, dazu ein Breakoutboard mit einem MAX3232, die beiden Receive-Kanäle des MAX3232 mit auf die serielle Leitung (RX und TX) klemmst und dann am LA die Bitzeit ausmisst. Bingo. Länger als eine Stunde sollte das eigentlich nicht dauern. fchk
Michael Glaser schrieb: > Timing? also es ist definitiv nur die RS232-Leitung. Nix weiter, kein > Shake oder DX oder so. Das habe ich auch nicht erwartet. Aber ich vermute, dass zwischen den 256 Byte-Paketen eine Pause ist, die man detektieren kann. > Wie könnte man denn ein besseres Logging über ein Terminalprogramm > einrichten, was speziell auf Timing aus ist? Gar nicht. Dafür müsstest Du schon ein eigenes Programm schreiben, welches ab einer bestimmten Timeout-Schwelle die mittlerweile übertragenenen Zeichen ausgibt. Haben die ausgegebenen Werte einen Abstand von 256, hast Du die Schwelle gefunden.
:
Bearbeitet durch Moderator
Michael Glaser schrieb: > Wie könnte man denn ein besseres Logging über ein Terminalprogramm > einrichten, was speziell auf Timing aus ist? Du kannst im HTerm zumindest einstellen, nach wieviel ms er in einer neuen Zeile beginnen soll: "Newline after ... ms receive pause (0=off)" Falls jeder Datensatz mit diesem "2@P`5)" beginnt, dürfte es nicht schwer sein - bis es geordnet untereinander steht.
Adam P. schrieb: > Michael Glaser schrieb: >> Wie könnte man denn ein besseres Logging über ein Terminalprogramm >> einrichten, was speziell auf Timing aus ist? > > Du kannst im HTerm zumindest einstellen, nach wieviel ms er in einer > neuen Zeile beginnen soll: > "Newline after ... ms receive pause (0=off)" > > Falls jeder Datensatz mit diesem "2@P`5)" beginnt, dürfte es nicht > schwer sein - bis es geordnet untereinander steht. Du hast auch bei beim "Save as" die Option, Zeitstempel in den log einzufügen, was die Interpretation natürlich etwas schwerer macht. Aber wenn Du über ein einzelnes Zeichen mit der Maus wanderst, kriegst Du im jeweiligen Tooltipfenster auch die Zeitstempel.
Ich glaube, ich verstehe! Es gibt eine Übertragung und diese stoppt nach dem Ende für x ms und setzt dann wieder ein? Und das sieht man auf dem log nicht. Hat man nach dem Einsetzen der Übertragung das erste Zeichen, hat man auch den Anfang, richtig?
Michael Glaser schrieb: > Hat man nach dem Einsetzen der Übertragung das erste Zeichen, hat man > auch den Anfang, richtig? Ja, korrekt. Gerade wenn irgendwelche Frame-Markierungen in den Daten wie <STX> und <ETX> fehlen, wäre das eine sinnvolle Herangehensweise.
Michael Glaser schrieb: > Es gibt also keine Start/Stopzeichen, Genau. > wie noch beim ersten Log von dir vermutet Wo habe ich das vermutet? Frank M. schrieb: > Es könnte einfach eine Ruhepause zwischen den Datensätzen sein. Diese Pausen sind definitiv vorhanden, zumindest im ersten Log vom 30.5., denn: Michael Glaser schrieb: > ich habe hier eine Datei, geloggt aus einer RS232-Schnittstelle. Ca 5sek > lang. Die Datei umfasst 25740 Byte. Bei 260 Byte pro Datensatz sind das genau 99 Datensätze. Also wird alle 5s/99=51ms ein Datensatz übertragen. Die eigentliche Übetragung der 260 Bytes dauert aber bei 115200,8,N,1 nur 260·10/115200Hz=23ms. Es verbleibt also eine Pausenzeit von 51ms-23ms =28ms, die, wenn sie immer am Ende eines jeden Datensatzes eingefügt wird, durchaus zur Synchronisation genutzt werden könnte. Diese Pausen erhöhen auch deutlich die Wahrscheinlichkeit dafür, dass Start und Ende des Logs jeweils zwischen zwei Datensätzen liegen. Und tatsächlich ist die Länge beider Logs (sowohl des alten als auch des neuen) ein ganzzahliges Vielfaches der jeweiligen Datensatzlänge.
Frank K. schrieb: > Indem Du mal 15€ für einen CHina-Logicanalyzer ausgibts, ... Wo gibt es die denn noch für 15€? Da musst du inzwischen heftig suchen. http://www.ebay.com/itm/172169652368
Beitrag #5060731 wurde vom Autor gelöscht.
Hallo Leute, eine neue Datei. Diesmal im Ruhezustand und dann mit Start und kurzem Lauf der Maschine. Das mit dem Zeitlogging bekomme ich nicht hin :( Kann man nicht wirklich die 2@P als Bezungspunkt nehmen? Das Format ist wieder wie Version 1. Und bleibt auch diesmal dabei;) Hatte einen kleinen Fehler beim Loggen in der Version 3. Entschuldigung
Michael Glaser schrieb: > Diesmal im Ruhezustand und dann mit Start und kurzem > Lauf der Maschine. Falls die 115k stimmen, dann stimmt ebenfalls deine Aussage: Ruhezustand -> kurzer Lauf. Nehmen wir mal an, der Datenstream bildet interne Daten-Register ab (Zähler, Messwerte, etc.), dann erkennt man dies in deinem Log. Annahme: 260 Byte / Datensatz Log-Datei hat 3458 Datensätze Datensatz 0 - 1733 = Ruhezustand Bei Datensatz 2896 ist noch etwas passiert, mehr Mess/Datenwerte. Sieht man ganz gut mit dem Prog. "HxD". Zeilenbreite auf 260 Stellen und dann mal runter scrollen.
So, kurze Sommerpause vorbei und weiter geht es ;) Habe einiges probiert, aber mir scheint, es gibt da irgendwie keine feste Reihenfolge, kann das sein? Ich orientiere mich da an dem Zähler, der jedes mal um 1 nach oben gesetzt wird und beim erreichen von 255 das nebenstehende Byte um 1 erhöht...diese beiden finde ich aber immer an unterschiedlichen Stellen im Datensatz Ich habe jetzt bei hterm mal die Funktion "Neue Zeile nach x ms" eingestellt und einmal 18ms und einmal 22ms und dann 23ms probiert: gemessen von dem doch sehr statischen "2@P" sind die Zähler jedesmal wo anders :( Auch wenn ich andere "Anfangszeichen" wähle, sind die Zähler woanders...was mache ich falsch? Anbei noch ein etwas längerer Log, auch da sind die Zähler woanders, allerdings wurde da nicht irgendwie was mit neuer Zeile bei hterm angegeben, also ganz normal geloggt... Wer hat da eine Idee? Was mache ich falsch? Vielen Dank
Hast mal mein Vorschlag probiert? - Log die Daten einfach, ohne Interpretation in ein File (so wie du es schon gemacht hast) - Öffne diesen Log mit dem Programm 'HxD' und stell dort die Anzahl an Bytes auf 260. Dann hast du dein 'Counter' an Offset 0xEF und 0xF0. Oder im HTerm nicht nach X ms eine neue Zeile, sondern nach 260 Bytes. Kannst ja mal ausprobieren.
Hallo, ja habe ich. 260 Zeichenbreite ist ganz schön viel, aber ausser einem Musster kann ich da nichts erkennen, das ist ja das Problem. In der Ansicht sieht es alles schön geordnet aus..also habe ich mich verschaut und du findest den Counter immer an der selben Stelle in allen Datein?
OK, hast wohl recht, 260 scheint wirklich nicht korrekt zu sein. Zumindest in soweit nicht konsistent, dass die erste Zeile zu allen anderen passt. ...hab grad alle Dateien offen. 23.log: Hier scheint 260 zu passen, der Counter folgt immer auf die Sequenz 32 40 50 60 <Counter> 18.log: 22.log: 115k_6a.log: Bei diesen Logs hab ich unterschiedliche Längen und dann passen diese nur für die ersten 2 Zeilen. Falls der Datenstream zu Beginn mit 32 40 50 60 beginnt und, da sich dies immer wiederholt und danach der Counter steht, ist es evtl. auch die Kennung für einen Datensatz. Kommisch ist nur das es einmal passt und dann wieder nicht.
Irgendetwas läuft beim Aufzeichnen der Daten falsch. Ziemlich sicher ist, dass die Daten in Blöcken konstanter Länge übetragen werden. Bei deinen ersten Logs war die Blocklänge 260 Bytes, dann hast du Logs mit einer Blocklänge nur 256 gepostet. Zwischendurch enthielten die Logs nur Mülldaten. Bei den neuen Logs ist die Blocklänge wieder 260, allerdings ist bei drei der vier Logs der erste Block unvollständig. Ich habe von allen vier Logs jeweils die ersten drei Blöcke gehexdumpt. Jede Zeile des Dumps enthält 26 Bytes, ein kompletter Block besteht somit aus 10 Zeilen. Jeder Block beginnt mit der Bytefolge 32 40 50 60, gefolgt vom Low- und High-Byte der fortlaufenden 16-Bit-Zahl. Wenn man im ersten Block an geeigneter Stelle eine geeignete Anzahl Bytes einfügt, stimmen sowohl die Blocklänge als auch ein Großteil des Inhalts mit den anderen Blöcken überein. Die fehlenden Bytes sind in den Dumps mit "--" gekennzeichnet. Bei 115k_6a.log fehlen 25 Bytes, bei 18.log 18 Bytes und bei 22.hex 4 Bytes. Nur 23.log ist vollständig. Die fehlenden Bytes deuten auf einen Pufferüberlauf, Übertragungsfehler o.ä. hin. Ich weiß nicht, ob deine Tools fehlerhaft sind oder ob du sie falsch bedienst. Auf jeden Fall erschwerst du die Analyse damit gewaltig. Ich habe aber sowieso meine Zweifel, ob es dir jemals gelingen wird, das Protokoll zu entschlüsseln. Dazu enthalten die Blöcke einfach zu viele Daten, die sich über einen längeren Zeitraum nicht ändern. Aber selbst diejenigen Daten, die veränderlich sind und tatsächlich physikalische Mess- bzw. Stellgrößen zu enthalten scheinen (s. mein Beitrag vom 28.06.) sind nur schwer konkreten Sensoren bzw. Aktoren zuzuordnen, wenn man die Maschine nicht im Detail kennt. Ein gewisse Chance, das Protokoll zu entschlüsseln, würde ich höchstens dann sehen, wenn jemand, der sowohl Ahnung von der Analyse unbekannter Protokolle als auch von Fräsmaschinen hat, vor Ort direkten Zugriff auf die Maschine und einen Einblick in ihren inneren Aufbau hat. Aber selbst dann gestaltet sich die Sache immer noch sehr schwierig. Warum benutzt du die Fräsmaschine nicht einfach, wie sie ist, und erfreust dich an den schönen Dingen, die man damit fertigen kann?
Na prima :( Mein "Tool" ist ein recht frisch aufgesetzter XP-Laptop mit ausgeschaltetem Virusscanner und Hterm und einem billig RS232-USB-Wandler.. Was meinst du mit "fehlen"? In dem ganzen Log fehlt dann jeweils in jedem Block Daten? Oder wie ist es gemeint? Naja, ich krieg das schon irgendwie hin ;) Zumindest die Datenzuordnung..denke ich, ich bräuchte halt nur einen Anfang vom Datensatz... Ich hänge noch ein paar logs an, kannst du bitte mal schauen, ob die auch fehlerhaft sind? Wäre ja übel, wenn es da wirklich Probleme beim Loggen geben würde. Könntest du bitte einmal schauen, ob die auch nicht stimmen? Vielen Dank.
Grundsätzliche Frage: Wann fängst du an 'aufzuzeichnen'? Datei: 115k_5b.log Hat eine Datensatzlänge von 260 Byte, jedoch fängt hier der Mitschnitt mit 7d 00 01 ff ... an?! Kann es sein, dass du bei manchen Logs mitten im Betrieb anfängst die Daten aufzuzeichnen? Datei: 115k_4.log Datensatzlänge 260 Byte und fängt mit 32 40 50 60 an. Kannst du vllt. mal bitte eine Log anhängen wo du das Aufzeichnen startest, bevor du die Maschine einschaltest. (Also von Anfang an) Michael Glaser schrieb: > Was meinst du mit "fehlen"? Bei deinen vorherigen Log Dateien, fehlten bei einigen in den ersten 2 Datensätzen Bytes. Warum auch immer. Yalu X. schrieb: > Ich habe aber sowieso meine Zweifel, ob es dir jemals gelingen wird, das > Protokoll zu entschlüsseln. So sehe ich das auch.
:
Bearbeitet durch User
Oh...schande über mich! Selten am Start der Maschine, sehr oft logge ich einfach im Betrieb, wenn die Maschine läuft..bin am Wochenende wieder vor Ort und werde vor dem Start der Maschine den Logger einschalten.
:-D Das erklärt natürlich einiges. Dann erstell mal ein Log vom Start an und über eine längere Zeit (inkl. einigen Aktionen der Maschine). Hast du für uns nicht mal den Hersteller und Typ der Maschinensteuerung?
weiter geht es :) Was sagt ihr zu diesem Log? 2@P' scheint wohl doch der Anfang zu sein und der Counter befindet sich an der richtigen Stelle...nur wie bekomme ich raus, ob es ein 16-Bit-Wert ist (also 2 Bytes einen Wert ergeben) oder ein 8bit-Wert (ein 1Byte ein Wert)?
Das ist jetzt das Problem, welches wir schon angesprochen hatten. Die Interpretation der Daten kann beliebig kompliziert sein, da die Werte alles bedeuten könnten, sie könnten 8, 16, 32 bit sein. Mir ist noch aufgefallen, da der Counter nur 16-bit hat, erfolgt nach 18 Std. ein Überlauf.
Mh, okay, aber prinzipiell stimmst du mir zu, daß der Start mit " 2@P'" los geht, oder?
Angehängte Dateien:
-
byte-6-7.png
67 KB
Michael Glaser schrieb: > 2@P' scheint wohl doch der Anfang zu sein Nicht 2@P', sondern 2@P` bzw. 32 40 50 60 in Hexdarstellung. In der letzten Logdatei steht allerdings vor dem ersten Datenblock noch ein einzelnes NUL-Byte (hex 00). Möglicherweise sendet die Maschine dieses Byte einmalig direkt nach dem Einschalten. Dass viele deiner Logdateien direkt mit der Sequenz 32 40 50 60 beginnen, deutet daraufhin, dass die Pause zwischen den einzelnen Datenblöcken genau vor dieser Sequenz liegt und diese somit den Anfang des Datenblocks darstellt. Das NUL-Byte am Anfang der Logdatei kannst du also zunächst einmal ignorieren. > und der Counter befindet sich an der richtigen Stelle Ja. > nur wie bekomme ich raus, ob es ein 16-Bit-Wert ist (also 2 Bytes > einen Wert ergeben) oder ein 8bit-Wert (ein 1Byte ein Wert)? Man kann da nur raten, vermuten und hoffen :) Beim Zählerwort ist es noch relativ klar. Byte 4 des Datenblocks wird in jedem neuen Block inkrementiert und springt nach FF wieder auf 00 zurück. Bei jedem dieser Rücksprünge wird Byte 5 inkrementiert. Hier ist ein entsprechender Ausschnitt aus der Logdatei in Hexdarstellung:
1 | Byte 4 Byte 5 |
2 | ⋮ ⋮ |
3 | FD 00 |
4 | FE 00 |
5 | FF | 00 | |
6 | 00 | 01 | |
7 | 01 01 |
8 | 02 01 |
9 | ⋮ ⋮ |
Das sieht also sehr stark nach einem 16-Bit-Zähler aus. Bei halbwegs stetigen Mess- oder Stellwerten kann man eine ähnliche Überlegung anstellen. Hier ist ein Ausschnitt der Logdatei für Byte 6 und 7 jedes Blocks:
1 | Byte 6 Byte 7 |
2 | ⋮ ⋮ |
3 | 96 03 |
4 | D5 03 |
5 | D1 | 03 | |
6 | 1A | 04 | |
7 | 1A 04 |
8 | 47 04 |
9 | 98 04 |
10 | AF 04 |
11 | EC | 04 | |
12 | 07 | 05 | |
13 | F9 | 04 | |
14 | 06 | 05 | |
15 | D9 04 |
16 | DD 04 |
17 | AF 04 |
18 | 75 04 |
19 | 75 04 |
20 | 2D 04 |
21 | 29 | 04 | |
22 | E5 | 03 | |
23 | D5 03 |
24 | C6 03 |
25 | ⋮ ⋮ |
Die Zahlenwerte in Byte 7 werden immer dann inkrementiert, wenn Byte 6 einen großen negativen Sprung macht. Umgekehrt wird Byte 7 immer dann dekrementiert, wenn Byte 6 einen großen positiven Sprung macht. Das deutet darauf hin, dass die großen Sprünge von Byte 6 durch Überläufe verursacht werden, die jeweils zu einem Übertrag nach Byte 7 führen. Hat man erst einmal diesen "Anfangsverdacht", kann man die Daten auch grafisch vergleichen (s. Anhang). Welche der beiden Kurven würdest du als die "richtigere" ansehen?
Vielen Dank!! Genau das, was ich suche! Nur wie hast du aus Bit 7 und 8 eine Zahl bekommen? deine 16-Bit-Zahl stimmt, aber wenn ich 96 03 zusammenfasse zu 9603 und in Dezimal umrechne, komme ich auf 38403....
Michael Glaser schrieb: > aber wenn ich 96 03 zusammenfasse zu 9603 Vertausch das mal. 0x0396 = 918dez
Danke Rufus, das war es :)
Aber nächste Frage, bei der ich nicht weiterkomme:
Byte 54 und 55. Beide müssen zusammenhängen. 54 sieht analog aus, 55
fast digital, also von 255 direkt auf 1 oder 0. die Kurve von beiden ist
ähnlich und SEHR ähnlich zu einer Datenkurve, die ich hier habe. Daher
weiß ich, das 54 und 55 das ergeben, was ich haben will.
So wie ich es sehe, 55: 1 und höher wenn ein Wert x positiv ist
0 wenn ein Wert nahe 0 ist
255 wenn ein Wert negativ ist
Das Problem ist, die Kurve von 54 und 55 ist von Art und Weise ein Wert,
den ich habe, von der Optik her. aber von den Werten, gerade das
Einbringen von negativen Werten, bekomme ich einfach nicht hin, was
mache ich falsch?
Bei Byte 56 und 57 ist es genau so, sie sind fast Deckungsgleich mit
54/55 und es ist sicher das gleiche System..
Angehängte Dateien:
-
Zahlendarstellung.PNG
2,8 KB
Guten Morgen, falls die 2 Byte zusammengehören, dann könnte es sich um eine Vorzeichenbehaftete 16bit Zahl handeln (int16_t). Dann würde das Byte 55 wirklich von 0 direkt auf 255 springen, wenn der Wert in den Negativen Bereich wechselt. Anbei eine kleine Grafik zur Verdeutlichung.
Danke für deine Hilfe! Ich habe jetzt einfach die Daten durch einen Online-Konverter gejagt, der in alle möglichen Formate konvertiert, kein sinnvolles Ergebnis :(
Michael Glaser schrieb: > So wie ich es sehe, 55: 1 und höher wenn ein Wert x positiv ist > 0 wenn ein Wert nahe 0 ist > 255 wenn ein Wert negativ ist > > Das Problem ist, die Kurve von 54 und 55 ist von Art und Weise ein Wert, > den ich habe, von der Optik her. aber von den Werten, gerade das > Einbringen von negativen Werten, bekomme ich einfach nicht hin, was > mache ich falsch? Wenn die beiden zusammen eine 16 Bit Zahl bilden, muss es sich immer bei Byte 55=0 immer um eine positive Zahl handeln. Zeige doch mal den Verlauf von Byte 55 und von 54 (Hex- oder Dezimal-Format) in Abschnitten, wo sich z.B. Byte 55 von 1 auf 0 und weiter auf 255 ändert.
Leider ist es doch nicht so einfach wie gedacht. Byte 55 nimmt nämlich nicht nur 255 und 0 an, sondern auch 1 und 2 und sicher auch 3. Hier Zahlenpaar, die stimmen bzw zu 99,99% 7,453 =BA 03 3,695 =D9 01 0,43 =37 00 0,281 =24 00 -0,047=FA FF -0,063=F8 FF -1,5 =40 FF -0,273=C9 FF -0,375=D0 FF Bei 7,453 ist 55=03, bei 3,695 ist 55=01, bei 2,xx ist 55=01, bei 1,xx ist 55=00 und bei -x,x ist 55=FF ....also kein digitales Ein/Aus für negatives Vorzeichen oder nicht.. Ebenso ist mir 54 ein Rätsel. egal welchen Endian ich benutze, es kommt nix sinnvolles raus. Wer hat eine Idee? Vielen Dank
Das ist einfach: BA 03 -> 0x03BA / 0x80 = 7.453 D9 01 -> 0x01D9 / 0x80 = 3.695 37 00 -> 0x0037 / 0x80 = 0.43 ... Negative Werte - oberstes Bit gesetzt: FA FF -> -(0x10000 - 0xFFFA) / 0x80 = -0.046875 40 FF -> -(0x10000 - 0xFF40) / 0x80 = -1.5 usw. Das sieht für mich nach einer Form von Festkomma-Arithmetik aus. Die Division durch 0x80 entspricht einem entsprechenden Shift nach rechts. EDIT: Siehe auch Festkommaarithmetik
:
Bearbeitet durch Moderator
Michael Glaser schrieb: > egal welchen Endian ich benutze, es kommt > nix sinnvolles raus. Wer hat eine Idee? Wenn es immer komisch aussieht, dann mal mit float probieren...
Xaver schrieb: > Wenn es immer komisch aussieht, dann mal mit float probieren... Wieso? Das sind 16-Bit-Festkommazahlen in Zweierkomplementdarstellung mit 7 (binären) Nachkommastellen. Frank hat die Umrechnung, bei der die erwarteten Ergebnisse herauskommen, doch schon geliefert.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.