Hi, ist das normal oder war der Kauf nur'n griff ins Klo :( (Japaner "APLS") mfg
Können wir den Beitrag nochmal "in richtig" haben?
Tip schrieb: > Vertausch doch mal die Leitungen Hätt' ich selber mal drauf kommen können :) hat den selben Effekt wie die Softwarelösung von Falk Brunner schrieb: > http://www.mikrocontroller.net/articles/Drehgeber#... Danke zu: auweh schrieb: > Können wir den Beitrag nochmal "in richtig" haben? Nein, für so was geht man in ein Rechtschrift-Forum! Würd ich Dir wärmsten empfehlen. Fühlst Dich dort sicher wohler als hier! mfg Manfred
An Deiner Rechtschreibung wollte ich nicht herummäkeln - als regelmäßiger Leser dieses Forums bin ich Kummer gewohnt ;-) . Mir war nur der Informationsgehalt Deines Beitrags zu knapp, um Dein Problem zu verstehen - zu Deinem Glück hatten Andere damit weniger Schwierigkeiten, und inzwischen ist mir deshalb auch einigermaßen klar, was Du eigentlich gemeint hast. Fröhliches Basteln!
auweh schrieb: > An Deiner Rechtschreibung wollte ich nicht herummäkeln - als > regelmäßiger Leser dieses Forums bin ich Kummer gewohnt ;-) . Mir war > nur der Informationsgehalt Deines Beitrags zu knapp, um Dein Problem zu > verstehen - zu Deinem Glück hatten Andere damit weniger Schwierigkeiten, > und inzwischen ist mir deshalb auch einigermaßen klar, was Du eigentlich > gemeint hast. > > Fröhliches Basteln! auweh schrieb: > An Deiner Rechtschreibung wollte ich nicht herummäkeln - als > regelmäßiger Leser dieses Forums bin ich Kummer gewohnt ;-) . Mir war > nur der Informationsgehalt Deines Beitrags zu knapp, um Dein Problem zu > verstehen - zu Deinem Glück hatten Andere damit weniger Schwierigkeiten, > und inzwischen ist mir deshalb auch einigermaßen klar, was Du eigentlich > gemeint hast. > > Fröhliches Basteln! Naja, bei mehr Fehlern als Zeilen in einem Beitrag wird es schon etwas schwierig zu verstehen was gemeint ist. Wir brauchen wohl beide ein besseres Poliermittel für unsere Glaskugeln. Gruss Harald
auweh schrieb: > An Deiner Rechtschreibung wollte ich nicht herummäkeln - als > regelmäßiger Leser dieses Forums bin ich Kummer gewohnt ;-) OK, Sorry. > Mir war > nur der Informationsgehalt Deines Beitrags zu knapp, um Dein Problem zu > verstehen - zu Deinem Glück hatten Andere damit weniger Schwierigkeiten, > und inzwischen ist mir deshalb auch einigermaßen klar, was Du eigentlich > gemeint hast. Dachte ich mir auch erst. aber welcher Inkrementalgeber hat schon ne "Rasterung" ;) mfg
Falk Brunner schrieb: > http://www.mikrocontroller.net/articles/Drehgeber#... Das ganze Mysterium der Inkrementalgeber mit dem Flackern des Bits ausgerechnet auf der Rastung klärt sich, wenn man die beiden Signale nicht als 2-Bit Gray Code, sondern als Daten und Clock auffaßt. Bei anderen Übertragungsverfahren mit separater Clock-Leitung kommt auch keiner auf die Idee, Signal und Clock zu vertauschen.
Matthias schrieb: > nicht als 2-Bit Gray Code, sondern als Daten und Clock auffaßt. Interessanter Denkansatz um http://www.mikrocontroller.net/articles/Drehgeber#Dekoder_f.C3.BCr_Drehgeber_mit_wackeligen_Rastpunkten in Assembler umzusetzen.(hab den C-Code nicht analysiert!) Danke! Matthias schrieb: > Bei > anderen Übertragungsverfahren mit separater Clock-Leitung kommt auch > keiner auf die Idee, Signal und Clock zu vertauschen. Was das mit meinem Händisch betätigtem Inkrementalgeber zu tun hat entgeht mir allerdings völlig :)
Manfred John schrieb: > Matthias schrieb: >> nicht als 2-Bit Gray Code, sondern als Daten und Clock auffaßt. > Interessanter Denkansatz um > http://www.mikrocontroller.net/articles/Drehgeber#Dekoder_f.C3.BCr_Drehgeber_mit_wackeligen_Rastpunkten > in Assembler umzusetzen.(hab den C-Code nicht analysiert!) Das ist doch schon lange passiert, allerdings ohne das Wiki als Vorlage, nur anhand eigener Gedanken: Beitrag "Re: Hilfe zu Drehencoder-Auswertung nach Wiki" > Danke! Bitte... > > Matthias schrieb: >> Bei >> anderen Übertragungsverfahren mit separater Clock-Leitung kommt auch >> keiner auf die Idee, Signal und Clock zu vertauschen. > Was das mit meinem Händisch betätigtem Inkrementalgeber zu tun hat > entgeht mir allerdings völlig :) ...
Manfred John schrieb: > Was das mit meinem Händisch betätigtem Inkrementalgeber zu tun hat > entgeht mir allerdings völlig :) Beim händisch bedienten Inkrementalgeber ändert sich ein Signal immer genau auf der Rastung und das andere genau dazwischen. Wenn man also nicht laufend zufällige Änderung haben möchte, ist es nicht egal wie man die Signale anschließt und auswertet. Von den beiden Phasensignalen, die zur Verfügung, muß daher dasjenige als Clock verwendet werden, was zwischen den Rastungen für die Datenübernahme von der anderen Phase sorgt. Bei händisch betätigten Inkrementalgeber dekodiert man also besser nur 2 Zustände der "Daten"-Leitung und verwendet die andere als Clock. Bei 2-Bit Gray-Code dagegen würde man 4 Signalzustände dekodieren, was dann zu den Sprüngen auf der Rastung führt.
Matthias schrieb: > Bei händisch betätigten Inkrementalgeber dekodiert man also besser nur 2 > Zustände der "Daten"-Leitung und verwendet die andere als Clock. So habe ich es in meiner Routine ja gemacht, von einer Leitung wird die Flanke detektiert (Clock), von der anderen der Zustand (Data) während der Flanke. Allerdings habe ich dabei nicht explizit an "Data und Clock" gedacht, diese Sichtweise ist aber ok. ...
@ Matthias (Gast) >Bei händisch betätigten Inkrementalgeber dekodiert man also besser nur 2 >Zustände der "Daten"-Leitung und verwendet die andere als Clock. NEIN! Genau das macht man NICHT! Warum das so ist, steht im Artikel Drehgeber. > Bei >2-Bit Gray-Code dagegen würde man 4 Signalzustände dekodieren, was dann >zu den Sprüngen auf der Rastung führt. NEIN! Man dekodiert ebenfalls Gray-Code und wertet aber nur die Häfte der Codewechsel aus. Siehe Artikel. MFG Falk
Also ich habe bisher keine Probleme mit rastenden Encodern gehabt. Rastende Encoder schalten ja erst nach 2 oder 4 Phasenwechseln (encode_read2 oder encode_read4 benutzen). Wenn die Ausgabe genau auf der Rastung wechselt, dann initialisiert man eben die Variable "last" entsprechend, daß dort nicht gezählt wird und gut is. Der Vorteil ist, daß dann immer noch die Entprellung durch Auswertung des Graycode erfolgt. In der Firma haben wir auch ne Kaffemaschien, wo der Programmierer offensichtlich nicht verstanden hat, wie man einen Encoder ausliest. Folge: Das Ding prellt wie Sau und das wird immer schlimmer. Als sie ganz neu war, hat sie fast nicht geprellt. Ich bin schon am Überlegen, das Ding aufzuruppen und einen ATtiny13 als Entpreller reinzupacken. Reparieren lassen würde ja nur kurzzeitig helfen, da ja die buggy Software das Problem ist. Peter
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.