So dann steuere ich auch noch mal ne Lösung bei.
[
attachment=11585]
Grüße Achimedes
Ich hab jetzt noch mal eure Lösungen verglichen...und es ergeben sich da gravierende Unterschiede beim Ergebnis. Die Kurven sehen zwar ähnlich aus (siehe Screenshot), es kommt aber nur bei meiner Lösung das richtige Ergebnis raus *grins*. Der korrekte Messwert für eine Datenpaket (erster Wert im read buffer : 115C83) ist mal exemplarisch unten rechts aufgedröselt...ich kann jetzt grade nicht nachvollziehen, warum das so unterschiedlich ist!
Die obere Kurve ist mit meiner Lösung erstellt, die mittlere mit der Variante von IchSelbst, die untere mit der Lösung von Achimedes!
[
attachment=11588]
@IchSelbst: Danke für deine Erläuterung! Ja, der von dir beschriebene Effekt tritt auf, und zwar gar nicht mal so selten! Man könnte das nur vermeiden, indem man wirklich jedes Paket überprüft. Das dürfte aber zu langsam sein...außerdem ist die Abweichung wohl zu vernachlässigen. Ich messe zwar tatsächlich im µ-Bereich (Unwucht bzw. Schlag eines Metallringes), aber durch die Mittelung über einen kompletten Pufferinhalt bin ich wohl trotzdem noch im grünen Bereich. Ich werde mich damit aber noch beschäftigen...
Gruß
Achim
' schrieb:ich kann jetzt grade nicht nachvollziehen, warum das so unterschiedlich ist!
Aber ich.
Die unterschiedlichen Spitzen (zwischen deinem und meinem, Archimedes' hab ich noch nicht angekuckt) kommen eben daher, dass sich bei dir die Daten verschieben. (Bei mir fehlt das Paket komplett, daher ist die Kurve kürzer.) Verschobene Datenteile => anderer absolute Wert => andere "Spitze". Irgendwann fehlt wieder mal ein Zeichen, was zur Folge haben kann, dass sich die ursprüngliche Verschiebung wieder rückgängig macht => Die Spitzen passen wieder.
Die Sache ist schon etwas verzwickt: Der Effekt tritt z.B. nur dann auf, wenn bei fehlendem M-Byte irgendwann mal sich das M-Byte ändert. Ohne Änderung würde sich der Effekt auch nicht bemerkbar machen. So kann z.B. eine Änderung (in den Spitzen) z.B. erst 10 Werte später sichtbar werden, nachdem der eigenliche Fehler (fehlendes Byte) aufgetreten ist.
Zitat:Man könnte das nur vermeiden, indem man wirklich jedes Paket überprüft
So wie ich das gemacht habe?
' schrieb:Das Byte fehlt, weil es auf der seriellen Leitung kaputt gegangen ist. Und das passiert prinzipiell überall innerhalb des Datenstreams.
Eben: Sollten. Zwischen Senden und Empfangen liegt aber die Strecke - und die ist fehlerbehaftet. Deswegen muss ja eine Sicherung gemacht werden.
Nun fehle mitten im String - warum auch immer - ein Mid-Byte:
H1 H2 H3 H4 H5 H6 H7
M1 M2 M4 M5 M6 M7
L1 L2 L3 L4 L5 L6 L7
Sorry wenn ich mich da einmische mit einer etwas komischen Frage:
Also ich hätte da auch mal eine Frage dazu, wegen dem fehlenden Bit oder Byte.
Es ist doch so, wenn ich sage lese 3 Byte und Serial-Port ist konfiguriert auf Baudrate,8Bit, usw. dann sorgt doch der darunterliegende Treiber (VISA,OS/Kernel) dafür, das die Daten nochmals angefordert werden oder dass ein Fehler gemeldet wird, wenn nur 7 Bit kommen.
(Framing ,Parity usw.)
Oder das Kabel besser abschirmen gegen Störungen.
Ich habe schon viele Serielle Komunikationen gemacht, aber solche Fehler habe ich noch nie festgestellt.
Kann es sein, dass das gar keine richtige serielle Kommunikation ist.
Im Moment sehe ich da nicht ganz durch, zeit Feierabend zu machen.
Hab meins nochmal durchgeschaut und verändert.
Am ergebnis dieses Strings ändert sich aber glaube ich nix
Es Muß Ident 0 dan 1 dann 2 kommen.
komt zB 1 und davor nicht 0 smeist er das Paket weg.
wenn 2 und davor nicht 1 kommt schmeist er auch alles Weg.
Es wird erzwungen das die Idents in wirklich der reihenfolge 0 1 2 kommen alles andere wird als ungültig in die Tonnen getreten.
[
attachment=11589]
Grüße
Achimedes
' schrieb:Es ist doch so, wenn ich sage lese 3 Byte und Serial-Port ist konfiguriert auf Baudrate,8Bit, usw. dann sorgt doch der darunterliegende Treiber (VISA,OS/Kernel) dafür, das die Daten nochmals angefordert werden
Was heißt "nochmals angefordert"?
Es handelt ich hier - wahrscheinlich - nur um den ganz ordinären RS232-Treiber (ob der vom Betriebssystem gemacht wird oder von einem Softwareteil von NI ist dabei egal). Dieser Treiber ließt die Daten aus dem Hardwarepuffer aus (und schreibt ggf. da hinein). Die gelesenen Daten werden zwischengelagert. Kommt nun jemand her und verlangt 3 Zeichen, werden die aus dem Zwischenspeicher herausgeholt und weitergegeben. Ob das richtige Daten sind (Bitkombination) oder ob da eines fehlt (z.B. das M-Byte) weiß der Treiber nicht. Zum M-Byte wird ein Zeichen erst in der Applikation, nicht im Treiber. Der Treiber erkennt nur die von dir angesprochenden Parityerror etc. Wenn also jemand 3 Zeichen verlangt, gibt der Treiber drei weiter oder wartet, bis er selbst drei hat. Eine Anforderung nach draußen an irgendwen, jetzt drei Zeichen zu senden, das macht der Treiber nicht. Ein solches Verhalten würde eine/einige Stufen (OSI-7-Schichtenmodell) höher liegen.
Zitat:Ich habe schon viele Serielle Komunikationen gemacht, aber solche Fehler habe ich noch nie festgestellt.
Naja, 112KB ist nicht wenig. Da muss das Kabel schon entsprechend gut abgeschirmt sein. Und auch die Treiberschaltungen (Hardware) sollten noch gut sein (was bei den Onboard-Schnittstellen nicht immer der Fall ist).
[*grübel*]
Aber so viele fehlende Daten wie hier sollten nicht auftreten. Bei einem meiner Prüfstände mit zwölf seriellen Schnittstellen mit jeweils 112kB treten so gut wie keine Fehler auf. Möglicherweise sollte Achim mal die Anzahl der Stoppbits überprüfen.
Zitat:Kann es sein, dass das gar keine richtige serielle Kommunikation ist.
Eine richtige würde ich schon sagen. Bei einer Adaption von RS485 (Endgerät) auf RS232 (PC) alleine mit Verdrahtung könnte ich mir aber diese Fehleranzahl vorstellen.
' schrieb:Die Kurven sehen zwar ähnlich aus (siehe Screenshot), es kommt aber nur bei meiner Lösung das richtige Ergebnis raus *grins*.
Ich bin aber dafür, dass Archimedes' und meine Version besser sind.
Wenn man nämlich in seinem Programm die Eingänge bei "In Array einfügen" tauscht (und Arraylänge vom dann oberen Eingang nimmt) und in meinem die Verschiebung von den falschen 5 auf die richtigen 6 (0x3F sind nämlich 6 Bits, nicht 5) berichtigt und das Feature "Bei Null immer von vorne beginnen" (so wie bei Achimedes schon vorhanden) durch einen Dekrementierer in den False-Cases erweitert - dann kommt nämlich bei Archimedes und mir die selbe Kurve heraus. Wie Grenzwerte sind dann für alle drei Verfahren gleich.
' schrieb:Ich bin aber dafür, dass Archimedes' und meine Version besser sind.
Hmm...Fakt ist aber, das bei euren Versionen falsche Beträge rauskommen! Wie in
Beitrag #12 im Screenshot vorgerechnet, kommt ein Betrag um die 7,18xxx raus, das war der wirklich gemessene Abstand, den das Lasermicrometer erfasst hat!
EDIT: Ahhhhhhhh....jetzt hab ich bei Achimedes Version die Vertauschung der Eingänge gemacht, dann stimmt auch der berechnete Wert!
Das mit den Stoppbits guck ich mir noch mal an...
' schrieb:Aber so viele fehlende Daten wie hier sollten nicht auftreten. Bei einem meiner Prüfstände mit zwölf seriellen Schnittstellen mit jeweils 112kB treten so gut wie keine Fehler auf. Möglicherweise sollte Achim mal die Anzahl der Stoppbits überprüfen.
Ich bin immer noch der Meinung, dass es nicht möglich ist, das so viele Fehler entstehen, gehe davon aus das die Einstellungen/Kabel usw. ok sind.
Es kann ja nicht sein, das ich ein Produkt kaufe, dass immer wieder Fehler macht, und ich durch Software die Fehler rausfiltern muss und Werte verliere. Ich würde das jedenfalls nicht/niemehr kaufen.
Vielleicht ist es ja gar kein Fehler, sondern es wird zu langsam aus dem Buffer gelesen. Da das ja ein Ringbuffer ist wird irgendwann mal das alte überschrieben. Da es nun 3 Byte sind kann ich mir vorstellen das beim nächsten lesen halt nun dort ein Tel 02 steht und nicht mehr das Tel01, jedenfalls kommt dadurch die Reihenfolge durcheinander, und 3 Byte gehören ev. gar nicht zueinander.
Vielleicht liege ich aber auch falsch.
' schrieb:gehe davon aus das die Einstellungen/Kabel usw. ok sind.
Da hab ich aber schon andere Sachen erlebt - bezogen aufs Kabel.
Zitat:Da das ja ein Ringbuffer
Und ich gehe davon aus, dass der Puffer im Treiber (den kann man nämlich einstellen) für mindestens 100ms ausgelegt ist. Abgefragt werden sollte er dann alle 50ms. Man darf aber auch nicht zu schnell abfragen z.B. alle 2ms. Dann ist wieder der Overhead des eigenen Programmes zu groß. Die eigene Laufzeit ist dann größer als 2ms und der Puffer läuft über.
Drei-Byte-Weise kann man bei dieser Geschwindigkeit (115kB) nicht arbeiten. Dafür ist der Overhead beim VISA-Auslesen etc viel zu gewichtig. Beim Auslesen von dann z.B. 250 Zeichen muss man auf jeden Fall mit einem falschen Paket am Anfang und am Ende rechnen. Dafür hat Achim ja schon was eingebaut.