Lesen vom COM Port teils Fehlerhaft bitte um hilfe
-
Möchtest du das ich ungefähr so alle werte durchgehe ?
Ungefähr möchte ich erstmal gar nichts
ich möchte das du die zwanzig Werte aus meinem Post deiner 1982-Software-Variablen zuordnest
Post auf Seite https://www.c-plusplus.net/forum/331112-30 mit
Titel "noch ein bisschen weiter gemacht" vom 07:05:15 13.02.2015Abschnitt
->ich glaube diese werte kann/könnte man als (u)int16 little endian sehen (die werte sind so schoen gleichmaessig) - du braucht fuer jedes feld eine zuordnung was es sein können hier kommt wieder das wert-forcieren/laser abdecken/temperatur mit heisluft rauf usw. ins spiel um die richtige 1982-software-variable diesen hier zuzuordnen (nimm nicht einfach die erste die passen könnte - analysieren nicht basteln+wünschelrute) wertebereiche (von) 14 24 19 27 19 27 19 25 19 19 24 22 26 24 27 24 27 22 24 18 ?? 02 151 254 (bis) 16 26 22 30 22 30 22 28 22 22 26 25 28 26 30 26 30 26 26 20 06 152 255 solltest du diese ~20 felder sauber zuordnen koennen werden aus den 108 bytes unbekannt schnell mal ~60 bytes unbekannt - schon mal eine Menge weniger55 55 die (01 50) ergab die 80 und die 1. 80 könnnte die Kontrollernummer sein was die 1 darstellt frage.ich habe ehrlich gesagt keine Ahnung was du da machst - nicht alle Daten in dem Protokoll sind 16Bit- wiso denkst du das [01 50] zusammengehört
Ist mein Biespiel wirklich so schwer verstaendlich?
[12/02/2015 10:51:01] Read data ff ff ff ff 87 81 00 00 01 7d 01 50 8e 56 03 06 0f 00 18 00 14 00 1d 00 15 00 1c 00 16 00 1b 00 14 00 16 00 1a 00 19 00 1b 00 1a 00 1d 00 1a 00 1b 00 19 00 19 00 12 00 00 00 00 00 00 00 ff 0f 4e 00 00 00 ff 0f 00 00 21 01 00 00 f8 06 98 09 ff 07 01 00 00 00 00 00 00 00 a6 e2 df c1 57 b2 e4 3b 05 81 73 32 e1 a6 ad af bf 83 xx 11 22 22 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 44 33 33 33 33 x = scheinbar variant oder Teil eines int16, etc. 1 = uint8 laufnummer 2 = serien nummer als uint16 little endian 3 = bewegt sich um 27 - koennte die temperatur sein (kann die wackeln?), gibt es mehrere temperaturen? 4 = koennte kontroler seinBei dieser Schreibweise geht es darum das man die Informationszuordnung - welches Bytes gehören zu welchem Wert vereinfacht - man kann dann schoen sehen wo genau die Variable im Protokoll ist
du kannst natuerlich auch Seriennummer, Offset: 12, Laenge: 2, Typ: uint16 oder sowas schreiben - aber eben fuer alles was du schon erkennen kannst
-
Das ist ja das Problem ich kann diese werte nirgends wohin zuordnen.
Siehe bild was ich an meinem Monitor sehe
http://img4web.com/view/WTK8NE
ich sehe auch nich mehr als dieser Monitor ausgibt.
-
Warum machst du keinen Screenshots von der VM - dann kann man wenigsten alles klar erkennen
ich habe doch jetzt schon einige möglicherweise relevante Stellen im Protokoll aufgezeigt (viele davon bewegten sich z.B. in deinen angegebenen Temperaturbereich ) - nimm doch dieses Wissen und probiere ob du weitere Werte findest
der DocShoe hat die Sache herausgefunden das die Nr ganz vorne im Protokoll möglicherweise keine Laufnummer sondern Typkennung ist - weil wie du im meinem Sortier-Post gesehen hast sind dann die hintern 18 Bytes sehr homogen - die folgende 2 bytes sind wohle ein CRC16 oder sowas
du hast rumgespielt mit direktem schreiben um dann mit der 1982-Software zu prüfen
es gibt also echt einige Sachen die du machen kannst
btw: schreib mir doch mal eine mail an 35b_1p44v44y7ned@byom.de am besten mit Telefon-Nr
-
Hab die Mail rausgeschickt
-
55 55 die (01 50) ergab die 80 und die 1. 80 könnnte die Kontrollernummer sein was die 1 darstellt frage.
ich habe ehrlich gesagt keine Ahnung was du da machst - nicht alle Daten in dem Protokoll sind 16Bit- wiso denkst du das [01 50] zusammengehört
wieder keine Antwort
-
Ich dachte ein Protokoll kann nur eine bestimmte länge von Daten haben. Meiner Meinung nach wäre es nicht sinnvoll und fast unmöglich es so zu realesieren das 8 bit lange und 16 bit lange daten gemischt versand werden.
Kamm bisher in meiner Praxis noch nicht vor, zumindest nicht bei so alten system und bie so alten Protokolen, mann muss bedenke es ist auch ein altes gerät.
-
es wird und wurde immer gemischt - weil es einfach keinen Nachteil hat den passenden Typ zu wählen, das Protokoll wird dann einfach kleiner
-
ich habe noch nie ein Nicht-Daten-Variantes Protokoll gesehen - es macht auch einfach keinen Sinn, Wir sprechen hier von Inhalt nicht der Blockgrösse (welche hier ja fix ist) - aber selbst die Blockgrösse ist sehr häufig auch Variant
bei sehr trivialen Protokollen ist es so - aber nicht als Strategie, sondern weil die Daten eben alle gleich gross sind
-
Du willst sagen das wir hier eine folge gemischter längen haben können ?
Sprich mal sind es 8 bit mal sind es 16 bit, mal sind es 32?
Dann verstehe ich nicht die Aussage von vorhin, sprich ich dachte das die letzten 2 Bytes Prüfsummen sind von CRC16 und ich versuche die jetzt zu überprüffen. Mit dem x^16Polygon und den Rest.
Also bin jetzt ganz verwirt, leider kommm ich mit den Zahlen kein stück weiter.
soll ich noch ergebnisse aufnehmen und zusenden.
ich verstehe nicht wieso wir die 22158 also die serien nummer so klar sehen und alles andere so schwär ist.
Wer hat eine idee wie die negativen zahlen abgebildet werden können.
Und die nachkomamma stellen.
Schreibt es mir hier rein ich google oder prüffe es selber solange mein wissensstand reicht.
Oder führt mir beispiele hier auf, oder vermuttungen ich überprüffe dann alles.
-
wir haben uns falsch verstanden...
ich meinte nur das ein Datensatz aus verschiedenen Datentypen bestehen kann
z.B. [uint8][uint8][uint16][uint32][uint16]...
d.h. die Struktur/Offsets der Inhalte in einem Datesatz sind wohl schon fix/stabil
ich habe das nur angesprochen weil du in deinem Post die 0x01 vor dem 0x50 fuer den Kontroller (falls es das ist) in eine Variable reingesteckt hast - oder deine Schreibweise war einfach nur verwirrend
ich verstehe nicht wieso wir die 22158 also die serien nummer so klar sehen und alles andere so schwär ist.
Wer hat eine idee wie die negativen zahlen abgebildet werden können.deswegen ist es wichtig ueber Wert-Änderung z.B. nur die Betriebsstunden herauszufinden welche Bytes die Betriebsstunden sein müssen UNABHÄNGIG ob wir den Inhalt dann schon verstehen, z.B. koennten die Betriebsstunden ja auch eine Fließkommawert sein (den man ja in zig Arten kodieren kann) - alleine die Position waere schonmal wunderbar
-
3.die komplexitet ist nicht sehr groß und schwehr ich brauche auch nicht mehr als 10 bis 15 werte.
4. die erwarteten werte kann ich aus einem alten programm raussehen, welches von 1982 ist dies hab ich auf einem anderen rechner drauf es zeigt mir halt die werte an seriennummer , neigung , rollung, temperatur u.s.w das problem ist als neigung hab ich ein komma wert der mit - sein kann und wie der jetzt ausgelesen wird ist für mich auch eine frage, die werte können sich ändern dynamisch halt hängt von der position neigung u.s.w des läsers ab.bist du sicher dass "der laser" die werte selbst berechnet? ich würde nämlich eher davon ausgehen dass der PC das macht. also "das programm von 1982".
d.h. durch "inspektion" des protokolls alleine wirst du nie draufkommen wie du die nötigen werte erhältst.
wenn dann bräuchtest du den source des DOS programms, oder müsstest dieses zumindest mit nem disassembler auseinendernehmen.
-
bist du sicher dass "der laser" die werte selbst berechnet? ich würde nämlich eher davon ausgehen dass der PC das macht. also "das programm von 1982".
d.h. durch "inspektion" des protokolls alleine wirst du nie draufkommen wie du die nötigen werte erhältst.
wenn dann bräuchtest du den source des DOS programms, oder müsstest dieses zumindest mit nem disassembler auseinendernehmen.Der Laser ist nicht mit mir verbunden. Ich bin mit der Zieltaffel verbunden sieh Bild Testversuch oben. Ja es kann sein dass die Zieltaffel Werte ausgibt und diese im Programm berechnet und interpretiert werden, vielleicht auch berechnet.
Aber die serriennummer wird so übertragen, und ich denke die werte von roll und nick winkel müssen auch so übertragen werden da dort sensoren diese als pegel rausgeben(stimmt könnte sein das diese auch berechnet werden).
Ja was mach ich den jetzt.
Ich frag mal gezielt wieso gibt er die serriennummer 22158 so raus und alle anderen nicht. Besteht die möglichkeit dass alle anderen berechnet werden?
-
Ich frag mal gezielt wieso gibt er die serriennummer 22158 so raus und alle anderen nicht.
die Seriennummer laesst sich nicht berechnen - darum kommt sie auch direkt
Besteht die möglichkeit dass alle anderen berechnet werden?
klar warum nicht?
Ja was mach ich den jetzt.
jetzt zum 10. mal - alle Werte so weit es geht ruhig stellen und schauen wo sich die bytes veraendern wenn du einen einzelnen Wert beeinflusst - solange den einzelnen Wert beeinflussen bis du sicher bist das byte n..m dadurch geaendert werden - dann kannst du dich genau auf diese paar bytes konzentrieren wie da wohl der wert drinn steckt
Hier sagt niemand das du schnell zur Lösung kommst - das kann Wochen dauern
-
chirolog schrieb:
Aber die serriennummer wird so übertragen,
s.u.
chirolog schrieb:
und ich denke die werte von roll und nick winkel müssen auch so übertragen werden da dort sensoren diese als pegel rausgeben(stimmt könnte sein das diese auch berechnet werden).
wieso gehst du davon aus? geh mal lieber davon aus dass die messwerte zumindest noch irgendwie gefiltert werden. bzw. ich behaupte mal: da ist gar kein sensor drauf der direkt nen winkel messen kann. d.h. der winkel muss aus irgendwelchen anderen messwerten berechnet werden.
kann jetzt natürlich sein dass du ganz ganz viel glück hast, und diese berechnung in der zieltafel gemacht wird. ich würde aber, speziell bei einem so alten system, eher davon ausgehen dass die berechnung im PC gemacht wird.
bzw. ich würde das sogar heute noch so implementieren, da es flexibler ist: man muss nicht extra ein firmware update machen wenn z.B. mit einer neuen softwareversion etwas an der berechnung verbessert wird.chirolog schrieb:
Ja was mach ich den jetzt.
keine ahnung. weinen?
ich hab jetzt nicht die ganzen 8 seiten hier gelesen, also sorry falls du das schon beantwortet hast...: warum willst du das ding überhaupt mit ner neuen software auslesen?
chirolog schrieb:
Ich frag mal gezielt wieso gibt er die serriennummer 22158 so raus und alle anderen nicht.
WIE soll er die seriennummer denn sonst ausgeben??? soll er die extra verhunzen nur damit sie nicht so einfach erkennbar ist? wozu sollte das gut sein?
chirolog schrieb:
Besteht die möglichkeit dass alle anderen berechnet werden?
JA! siehe oben. irgendwo müssen die werte berechnet werden, da es mit an sicherheit grenzender wahrscheinlichkeit nicht einfach 1:1 ungefilterte messwerte sind. und da so ein PC einfacher zu programmieren ist als irgend ein kleines mess-kasterl, und es wie schon gesagt flexibler ist, hätte ich persönlich die berechnung ganz sicher im PC gemacht. und nicht im messkasterl.
was u.a. auch erklären würde wieso für eine messung so viele daten übertragen werden. weil er sich mehrere samples holt und dann filtert und rumrechnet.
-
Ja aber wäre dann unsere vermutung nicht falsch, wo wir angenommen haben das die letzten 2 Bytes CRC16 Prüffsumme der übertragung wären?
-
So nun mal paar antworten, wieso den winkel berechnung, wir haben eine spanung von -15 bis 15 z.B. in der Zieltaffel sind zwei wasserwagen, je nach neigung werden die werte anders angezeigt und übermittelt, so ungefähr, klar könnte ich noch ins detail gehen, aber ich denke für die meisten wird es verständlich sein.
JA! siehe oben. irgendwo müssen die werte berechnet werden, da es mit an sicherheit grenzender wahrscheinlichkeit nicht einfach 1:1 ungefilterte messwerte sind. und da so ein PC einfacher zu programmieren ist als irgend ein kleines mess-kasterl, und es wie schon gesagt flexibler ist, hätte ich persönlich die berechnung ganz sicher im PC gemacht. und nicht im messkasterl.
was u.a. auch erklären würde wieso für eine messung so viele daten übertragen werden. weil er sich mehrere samples holt und dann filtert und rumrechnet.Das ist eine gute Vermuttung, ich hab heute gemerkt wenn ich selber so ein Datenstring über die rs232 schicke, immer wider den selben, dann pendelt sich der nick wert erst mit der zeit ein, z.B. er war auf 10,7 und ich schick im den string mit der 9,4, dann zeigt er zuerst die 9,8, dann die 9,6 dann die 9,5 und dann erst die 9,4, es hab ich erst heute gemerkt. Aber die Temperatur und all die anderen standart sachen ändern sich sofort. Ich hab ja geschrieben das ich eine 2 bis 3 sekunden verzögerung merke.
Ich werde morgen vom morgens die versuche durchlaufen lassen, alles aufzeichen , protokolieren und euch jede stunde die ergebnisse rausstellen.
Vielen Dank für die Tips.
Ich bedanke mich würklich bei allen die dabei sind und mir helfen ich hätte es nicht glauben können.
-
Ja aber wäre dann unsere vermutung nicht falsch, wo wir angenommen haben das die letzten 2 Bytes CRC16 Prüffsumme der übertragung wären?
Was hat das eine mit dem anderen zu tun - die Checksumme (wenn es denn eine ist - kann auch ganz was anderes oder eine andere hausgemachte Checksumme sein) interessiert sich doch normalerweise nie für den Inhalt der mit Ihr validiertbar gemacht wird
-
genau.
nur dass die komplizierten berechnungen nicht im mess-kasterl gemacht werden heisst ja nicht dass das mess-kasterl nicht mal fähig ist eine CRC zu berechnen.
und da ne CRC, speziell bei einer so unsicheren übertragungsart wie RS232, eine tolle sache ist, ... schickt das mess-kasterl halt ne CRC mit.also kein widerspruch.
-
ps: wenn du da eh aufgezeichnete daten reinschicken kannst, dann kannst du ja auch "geschummelte" daten reinschicken.
=> hast du schon probiert einfach mal das eine oder andere byte in einer aufgezeichneten messkasterl-message zu ändern, und diese geänderte message reinzuschicken?
dabei könnte dich natürlich eine evtl. vorhandene prüfsumme stören. was aber schonmal ein guter test wäre um rauszufinden ob die kommunikation irgendwie abgesichert ist.
-
Ja ich hab versuche eine message zu schicken und ja es gibt eine Prüffsumme.
Bei einer veränderten message schreibt mir das Programm, übertragen daten Fehlerhaft.
