Warum Gray Code für Drehencoder?

Weil sich beim Graycode bei der richtigen Reihenfolge sich nur ein Bit 
ändert.
Hat Vorteile beim Fehlerdetektieren.

https://de.wikipedia.org/wiki/Gray-Code

Sven schrieb:
> Was für einen Vorteil hat denn dieser Gray Code im Vergleich? Für mich
> sieht das einfach nur komplizierter aus...

Na ja, bau das mal mit deinen "Tastern".

Dann merkst du, daß die Leute schon schlau waren.

Sven schrieb:
> Tom schrieb:
> 2) Mechanische Kontakte prellen. Bei Graycode egal, bei Deinen Tastern
> fatal.
>
> Echt jetzt? Egal?
>
> Kann mal bitte jemand den Artikel
> http://www.mikrocontroller.net/articles/Drehgeber überarbeiten und zum
> Beispiel den Code vernünftig kommentieren? Wäre schön, wenn auch Leute
> den verstehen würden, die keine AVR Pros sind -.-

Google! Es gibt hervorragende englischsprachige Artikel, die in der Tat 
wesentlich besser sind.

@ Sven (Gast)

>Kann mal bitte jemand den Artikel
>http://www.mikrocontroller.net/articles/Drehgeber überarbeiten und zum
>Beispiel den Code vernünftig kommentieren? Wäre schön, wenn auch Leute
>den verstehen würden, die keine AVR Pros sind -.-

Augen auf?! 1. Absatz!

"Der Vorteil dieser Codierung ist, dass ein Entprellen deutlich 
einfacher wird, da dieser Code die Eigenschaft besitzt, dass sich 
zwischen benachbarten Codes nur jeweils ein Bit ändert. Dies ermöglicht 
die asynchrone Abtastung, ohne weiter als einen Schritt vom wahren 
Ergebnis entfernt zu sein, weil ein sich änderndes Bit lediglich 
verspätet, aber nicht falsch erfasst wird."

m.n. schrieb:
> Quatsch, da wackelt auch nur das letzte Bit.

Oh Mann, m.n., immer mit seiner Unkenntnis dabei wenn es um Drehencoder 
geht.

Svens Vorstellung ist ein Taster, der schliesst, wenn sich die Achse im 
Uhrzeigersinn bewegt.
Logischerweise muss er sich aber auch gleich wieder öffnen, damit sie 
sich gleich wieder schliessen kann.
Er hat also vor, Impulse eines Tasters mit einem UP Eingang zu zählen.
Und den DOWN Eingang mit einem anderen Taster zu bestücken für die 
Drehrichtung gegen den Uhrzeigersinn.

Damit ist überhaupt nicht erkennbar, ob das Schliessen und Öffnen des 
Tasters wegen der Achsenbewegung erfolgt, oder wegen des Prellens der 
Kontakte, der Zähler würde munter vorwärts zählen.

So wie in Zähler, dessen UP-Eingang man mit einem einfachen Taster zum 
druafdrücken versieht. Der zählt bei jedem Tastendruck auch nicht +1, 
sondern um einige Impulse weiter, eben so viel wie der Taster prellt.

Man müsste die Tasterkontakte entprellen. Das geht natürlich nur, wenn 
Prellzeit und maximale Drehrate ausreichend unterschiedlich sind.

Ganz nebenbei wäre so ein Drehencoder, der direkt UP und DOWN liefert, 
schwer zu konstruieren.

@ Uups (Gast)

>Ein Inkrementalgeber ist inkrementell, waehrend ein Graygeber absolut
>ist.

Quark. Es gibt keine Graygeber. Es gibt aber Inkrementalgeber mit 
Graycode, das sind gefühlt 99,9% ;-)

> Dh allenfalls benoetigt ein Inkrementalgeber noch ein Indexloch.

Du verwechselst Inkrementalgeber mit Absolutwertgebern. Auch die 
arbeiten meist mit GRaycode, dann natürlich mit mehr Bits.

Schau Dir einmal den Wechsel bei binärem Code an:  (Beispiel 4 Bit)

     Stellung 1111    dazwischen, möglich:      Stellung 0000

           1            1             1               0
           1            1             0               0
           1            0             0               0
           1            1             0               0

Beim Übergang von 1111 auf 0000 müssten alle 4 Stellen gleichzeitig 
springen.
Das ist gerade bei langsam drehender Scheibe garnicht möglich.

Es werden beim Übergang von 15 auf 0 also Pseudopositionen ausgegeben, 
die in Wirklichkeit an ganz andrer Stelle der Scheibe auftreten

In einem Regelkreis kann das tödlich sein: der Regler bleibt auf einer 
Zwischenzahl hängen anstatt an der wirklich erstrebten Zahl. Wenn sich 
die Scheibe langsam dreht und etwa 1101 als Sollpisition erreicht werden 
soll.

 Deshalb darf beim Übergang von einer Position auf die nächste nur ein 
Bit umschalten. Diese Eigenschaft, einschrittiger Code, ist beim 
Gray-Code vorhanden, es gibt übrigens auch andre einschrittige Codes.

Das Problem dieser Pseudowerte tritt ganz besonders bei langsam 
drehender Scheibe auf, hat also mit Prellen garnichts zu tun.

Sven schrieb:
> Ich meine, man könnte doch auch einfach wie mit 2 Tastern arbeiten

Könnten ja auch ein paar mehr sein, wenn du z.B. eine volle Umdrehung in 
4096 Schritte auflöst. Bei linearen Maßstäben können noch ein paar Bits 
mehr anfallen.
Prellen ist gar nicht nötig und tritt bei optischen Abtastern auch nicht 
auf, aber der Graycode hilft vor allem schwere Fehler durch eine geringe 
Schiefstellung des Abtasters zu vermeiden.

@ Hp M. (nachtmix)

>Prellen ist gar nicht nötig und tritt bei optischen Abtastern auch nicht
>auf, aber der Graycode hilft vor allem schwere Fehler durch eine geringe
>Schiefstellung des Abtasters zu vermeiden.

Ja, das auch. Aber auch sonst gibt es keine perfekte ASYNCHRONE 
Abtastung. Denn die Bewegung des Encoders ist zum Abtasttakt asynchron. 
Damit können die mehreren Bits des Positionscodes auch nie perfekt 
gleichzeitig den Zustand wechseln. Und in asynchronen FIFOs mit 2 
Takten muss man auch die Schreib- und Lesezeiger per Graycode in die 
andere Taktdomäne übertragen.

Ich möchte an dieser Stelle den Beitrag 'Drehgeber' diskutieren:

https://www.mikrocontroller.net/articles/Drehgeber

1. Die Überschrift lautet:
Drehgeber (auch Inkrementaldrehgeber, ............. genannt) dienen...

2. Das erste Bild unter 'Funktion' zeigt richtigerweise die beiden
um 90° versetzten Spuren A und B eines Inkrementalgebers.

3. Der direkt nachfolgende Satz lautet:
Drehgeber erzeugen bei Drehung der Achse an zwei Datenleitungen
am Ausgang ein sogenanntes Gray-Code-Signal.

Diese Aussage, bezieht man sie auf die Abbildung, ist falsch.
Der Gray-Code sieht - selbst auf 2 Bit bezogen - anders aus (mein Bild).

Mag sein, dass in der Elektronik des Drehgebers ein Wandler auf
Gray-Code enthalten ist und dieser am Ausgang zur Verfügung steht.
Aber das geht aus dem Beitrag nicht hervor; statt dessen ist etwa
im Text ca. ein Dutzend mal von 'Code' die Rede anstatt von
'Spur A und B'.

Möglicherweise ist das auch das Verständnisproblem vom TO.

Bernd K. schrieb:
> Mag sein, dass in der Elektronik des Drehgebers ein Wandler auf
> Gray-Code enthalten ist

Dieser „Wandler“ sind einfach nur die Kontakte.

Reiß mal so'n Teil auf, du wirst dich wundern, wie wenig da drin
ist. :)

Sven schrieb:
> und zum Beispiel den Code vernünftig kommentieren?

Was genau fehlt dir an meiner kürzlich hinzgefügten Erklärung (etwas
unterhalb des C-Codes)?

@ Bernd K. (bmk)

>1. Die Überschrift lautet:
>Drehgeber (auch Inkrementaldrehgeber, ............. genannt) dienen...

Wo ist das Problem?

>Diese Aussage, bezieht man sie auf die Abbildung, ist falsch.
>Der Gray-Code sieht - selbst auf 2 Bit bezogen - anders aus (mein Bild).

Nö, es ist Graycode.

>Mag sein, dass in der Elektronik des Drehgebers ein Wandler auf
>Gray-Code enthalten ist

Nö. Der Code wird direkt erzeugt.

>und dieser am Ausgang zur Verfügung steht.
>Aber das geht aus dem Beitrag nicht hervor; statt dessen ist etwa
>im Text ca. ein Dutzend mal von 'Code' die Rede anstatt von
>'Spur A und B'.

Was denn sonst? Spur A und B sind gray codiert.

Interessant.

Weil ausgerechnet die Bits 2 und 3 des Gray-Codes dem Bild der beiden
Spuren A und B eines Inkrementalgebers entsprechen, handelt es sich
natürlich und selbstverständlich um den Gray-Code. NAK.

Meine These:
Um bei Inkrementalgebern eine richtungsabhängige Erkennung zu
ermöglichen, hat man zur Spur A eine um 90° versetzte Spur B
eingerichtet. Hierdurch kann man durch relativ einfache Logik
die Richtung erkennen und auswerten. Dass die beiden Spuren
mit den Bits 2 und 3 des Gray-Codes übereinstimmen, war nie
beabsichtigt und ist rein zufällig.

Sven schrieb:
> Kann mal bitte jemand den Artikel
> http://www.mikrocontroller.net/articles/Drehgeber überarbeiten und zum
> Beispiel den Code vernünftig kommentieren? Wäre schön, wenn auch Leute
> den verstehen würden, die keine AVR Pros sind -.-

Dafür muß man kein AVR Pro oder Contra sein, normale Internetskills 
reichen (google, Wikipedia).

Ok, man hat vergessen dran zu schreiben, daß man im Internet bei Bedarf 
noch mehr Info findet.
Schon der deutsche Wikipedia-Eintrag erklärt doch schön die Problematik 
mit normaler Binärcodierung, bei dem sich mehrere Bits gleichzeitig 
ändern können, und daß man das mit Graycode wunderbar umgeht indem dort 
immer nur ein Bit kippt.

Possetitjel schrieb:
> Wenn Du Dir bitte mal die Spuren 2 und 3 Deines Bildes
> (oberes Diagramm "Gray-Code (Absolutwertgeber)") genau
> anschauen würdest?

Wenn man sich das genau ansieht, dann erkennt man, dass Spur 3 falsch 
gezeichnet ist und doppelt so lange "High" sein müsste.
Beim Graycode halbiert sich die Frequenz von jeder Spur zur 
Nächsthöheren.
Bei Inkrementalgebern hingegen haben beide Signale die gleiche 
Frequenz mit lediglich unterschiedlicher Phase.

Bernd K. hat schon richtig erkannt, dass die Signale eines 
Inkrementalgebers kein Graycode, im Gegensatz zum Absolutwertgeber, 
welche i.d.R. Graycode ausgeben. Insofern ist das im Artikel falsch,

Edit: Hab das Bild mal korrigiert

Bernd K. schrieb:
> 3. Der direkt nachfolgende Satz lautet:
> Drehgeber erzeugen bei Drehung der Achse an zwei Datenleitungen
> am Ausgang ein sogenanntes Gray-Code-Signal.
>
> Diese Aussage, bezieht man sie auf die Abbildung, ist falsch.
> Der Gray-Code sieht - selbst auf 2 Bit bezogen - anders aus (mein Bild).

Vielleicht wird's aus dem Bild im Anhang klarer.

Michael K. schrieb:
> Wenn man sich das genau ansieht, dann erkennt man, dass Spur 3 falsch
> gezeichnet ist und doppelt so lange "High" sein müsste.

Doch, das stimmt schon. Da, wo diese Signal wieder auf Low geht, beginnt
die nächste Periode des Zählers, wo er wieder bei 0 beginnt zu zählen.

Michael K. schrieb:
> Beim Graycode halbiert sich die Frequenz von jeder Spur zur
> Nächsthöheren.

Richtig, mit einer Ausnahme: Die höchstwertige Spur hat die gleiche
Frequenz wie die zweithöchste, da sich die Frequenz innerhalb der
Periodendauer des gesamten Zählers nicht nocheinmal halbieren kann.

Edit:

Die in unterschiedlichen Grüntönen hinterlegten Flächen sind die
Perioden eines 2-Bit-, 3-Bit- und 16-Bit-Gray-Code-Zählers. Würde man
beim 16-Bit-Zähler einfach nur die Spuren 3 und 2 weglassen, Spur 1 aber
unverändert übernehmen, würde der Zähler immer abwechselnd aufwäsrts und
abwärts zähle: 0-1-2-3-3-2-1-0-0-1-2-3-3-2-1-0. Das ist aber nicht das,
was man normalerweise möchte.

Und wenn Du Dir mal eine Periode des Drehgeber-Signals ansiehst, ist die 
Bitfolge:

00 -> 01 -> 11 -> 10 -> 00

was mit einem 2-Bit-Gray-Signal identisch ist. Vielleicht kommt das 
Mißverständnis daher, daß die letzten beiden Stellen eines periodischen 
4-Bit-Gray-Signals mitnichten einem periodischen 2-Bit-Signal 
entsprechen, sondern die ersten?

Man kann ein Brötchen und noch eines in die Tasche stecken, und hat dann 
zwei  - auch ohne Addition zu kennen, kommt man auf die 2.

Yalu X. schrieb:
>> Beim Graycode halbiert sich die Frequenz von jeder Spur zur
>> Nächsthöheren.
> Richtig, mit einer Ausnahme:
Aargh, stimmt.
Ich nehm alles zurück :-)

Für das Verständnis ist es dann trotzdem ziemlich unglücklich, dass sich 
die Bezeichnung Graycode im Artikel wegen der nur 2 Spuren genau auf 
diese Ausnahme bezieht, denn das ist ja nicht, was den Graycode eigtl. 
ausmacht.

Yalu, das war eine super Erklärung!

Gruß, Stefan

@ Bernd K. (bmk)

>Weil ausgerechnet die Bits 2 und 3 des Gray-Codes dem Bild der beiden
>Spuren A und B eines Inkrementalgebers entsprechen, handelt es sich
>natürlich und selbstverständlich um den Gray-Code. NAK.

Hää?

>Meine These:
>Um bei Inkrementalgebern eine richtungsabhängige Erkennung zu
>ermöglichen, hat man zur Spur A eine um 90° versetzte Spur B
>eingerichtet. Hierdurch kann man durch relativ einfache Logik
>die Richtung erkennen und auswerten. Dass die beiden Spuren
>mit den Bits 2 und 3 des Gray-Codes übereinstimmen, war nie
>beabsichtigt und ist rein zufällig.

Unfug^3. Es IST Graycode, nur halt mit 2 Bit, der minimalen Bitbreite, 
die für so einen Code möglich ist. Das war/ist volle Absicht! Es gibt 
nicht DEN Graycode, denn bei >2 Bits kann man verschiedene Abfolgen 
konstruieren, bei der sich immer nur ein Bit ändert, trotzdem bleibt es 
einschrittiger Graycode.

Sven schrieb:

>> Was genau fehlt dir an meiner kürzlich hinzgefügten Erklärung (etwas
>> unterhalb des C-Codes)?
>
> Einfach mal den Code durchspielen. Was passiert da? main(). Okay, was
> ist PHASE_A und PHASE_B?

Wenn du dir das Datenblatt eines Drehgebers mal anschaust, dann
werden die beiden Spuren im Englischen in der Tat häufig genau so
bezeichnet (Phase A/B).

Ansonsten bezog ich mich ausdrücklich nicht auf den Quellcode, sondern
auf meine kürzlich hinzugefügten Erläuterungen zwei Absätze tiefer.
Hast du dir diese denn überhaupt durchgelesen?

Michael K. schrieb:
>
> Für das Verständnis ist es dann trotzdem ziemlich unglücklich, dass sich
> die Bezeichnung Graycode im Artikel wegen der nur 2 Spuren genau auf
> diese Ausnahme bezieht, denn das ist ja nicht, was den Graycode eigtl.
> ausmacht.

Genau das meine ich.

In der Tat sind die um 90° versetzten Spuren A und B eines
Imkrementalgebers mit den beiden höchstwerigen Bits eines Gray Codes mit 
einer Bitzahl >=2 identisch. Aber ein 'Code' steht für etwas anderes.

Wikipedia:
Ein Code oder Kode, deutsche Aussprache [koːt],[1] ist eine 
Abbildungsvorschrift, die jedem Zeichen eines Zeichenvorrats 
(Urbildmenge) eindeutig ein Zeichen oder eine Zeichenfolge aus einem 
möglicherweise anderen Zeichenvorrat (Bildmenge) zuordnet.[2]

Und da hört es mit der Gemeinsamkeit auf; ein Inkrementalgeber will
sicherlich nicht bestimmte 'Zeichen eines Zeichenvorrats' übertragen.

Michael K. schrieb:
> Für das Verständnis ist es dann trotzdem ziemlich unglücklich, dass sich
> die Bezeichnung Graycode im Artikel wegen der nur 2 Spuren genau auf
> diese Ausnahme bezieht

Das kommt, wie so oft, darauf an.

Ich selber sehe in so einer Inkrementalgeberausgabe auch erst einmal
zwei phasenversetzte Rechtecksignale und nichts weiter. Ich habe vor
vielen Jahren ein Praktikum bei einem Hersteller von Drehgebern gemacht,
und dort hat es jeder genau so gesehen. Den Begriff Gray-Code hat man
ausschließlich in Verbindung mit Absolutgebern mit mehr als zwei Spuren
benutzt. Das war nicht nur in dieser Firma so, sondern auch anderswo.
Die beiden Bits werden herstellerseitig meist auch nicht als Bit 0 und
Bit 1 bezeichnet, sondern fast immer als A und B.

Auf die Interpretation der Inkrementalgeberausgabe als 2-Bit-Gray-Code
bin ich das erste Mal vor ein paar Jahren in Hobyelektronikforen
gestoßen. Vielleicht kommt demnächst ein IC-Hersteller auf die Idee, ein
Toggle-Flipflop als einen 1-Bit-Gray-Code-Zähler aufzuwerten ;-)

Es ist aber keineswegs falsch und in mancher Hinsicht auch durchaus
sinnvoll, die A- und B- Signale als Gray-Code zu sehen. So gibt es
Auswerteverfahren, die tatsächlich die beiden Leitungszustände als
Gray-Code in einen Zahlenwert von 0 bis 3 dekodieren, um anschließend
die Differenz zum letzten Zahlenwert (die immer -1, 0 oder +1 und nicht
-2 sein sollte, dewegen kann man damit auch Fehlerzustände erkennen) zu
einer Zählvariable hinzuzuaddieren. Wer den Gray-Code kennt, versteht
dieses Verfahren sofort, alle anderen sehen darin erst einmal schwarze
Bitmagie.

Bernd K. schrieb:
> Ich möchte an dieser Stelle den Beitrag 'Drehgeber' diskutieren:
> https://www.mikrocontroller.net/articles/Drehgeber

Dazu hättest du besser einen neuen Thread aufgemacht.

> 1. Die Überschrift lautet:
> Drehgeber (auch Inkrementaldrehgeber, ............. genannt) dienen...
>
> 2. Das erste Bild unter 'Funktion' zeigt richtigerweise die beiden
> um 90° versetzten Spuren A und B eines Inkrementalgebers.
>
> 3. Der direkt nachfolgende Satz lautet:
> Drehgeber erzeugen bei Drehung der Achse an zwei Datenleitungen
> am Ausgang ein sogenanntes Gray-Code-Signal.
>
> Diese Aussage, bezieht man sie auf die Abbildung, ist falsch.
> Der Gray-Code sieht - selbst auf 2 Bit bezogen - anders aus (mein Bild).

Falsch. Du hast einfach nicht begriffen was ein Graycode ist. Die 
Hervorhebung von ein ist wichtig. Es gibt nämlich nicht den 
Graycode, sondern viele [1].

Die wesentliche Eigenschaft eines Gray-Codes ist, daß sich zwischen zwei 
aufeinanderfolgenden Codes immer nur genau 1 Bit ändert. Oder etwas 
wissenschaftlicher ausgedrückt: die Hamming-Distanz zwischen 
aufeinanderfolgenden Codes ist genau 1.

Diese Definition eines Gray-Codes sagt insbesondere gar nichts über die 
Anzahl Bits die so ein Code haben muß. Und da du einen Gray-Code mit 4 
Bit (dein oberes Bild) mit dem vom Inkrementalgeber gelieferten 
Gray-Code mit 2 Bit vergleichst, kommt da natürlich Unsinn raus.
Du vergleichst Äpfel mit Birnen.


[1] obwohl es viele verschiedene Gray-Codes gibt, wird meistens der 
Standard-Code verwendet, der sich aus der Standard-Konstruktion ergibt.
Die Konstruktion ist rekursiv:

1. der Gray-Code mit 1 Bit ist {0, 1}
2. ein Gray-Code der Länge n+1 ensteht aus dem Gray-Code der Länge n 
indem man den kürzeren Code einmal vorwärts und ein ein zweites Mal 
rückwärts aufschreibt und das zusätzliche Bit in der ersten Hälfte auf 0 
und in der zweiten Hälfte auf 1 setzt.

Yalu X. schrieb:
> So gibt es
> Auswerteverfahren, die tatsächlich die beiden Leitungszustände als
> Gray-Code in einen Zahlenwert von 0 bis 3 dekodieren, um anschließend
> die Differenz zum letzten Zahlenwert (die immer -1, 0 oder +1 und nicht
> -2 sein sollte, dewegen kann man damit auch Fehlerzustände erkennen) zu
> einer Zählvariable hinzuzuaddieren.

Letztendlich gibt es eigentlich nur ein Verfahren, AB-Signale 
auszuwerten:
Aktuellen Zustand betrachten und gültige Folgezustände sind der aktuelle 
oder die beiden benachbarten.
Da es vier Zustände gibt, kann man diese mit 0..3 bezeichnen und die 
Auswertung als -1,0,+1-Operation betrachten, damit komm ich auch 
"hintenrum" auf den Graycode, was ja logisch ist, da für den Spezialfall 
2 Spuren die Signale eben identisch sind. Insofern stimmen wir 
überein, anders geht es auch nicht.

Klaus schrieb:
> warum das Beispiel wie von Michael K. geschrieben "unglücklich" ist, ist
> ja auch nicht scharf definiert
Sicher ist es unscharf, aber ich bleibe dabei, dass es eine unglückliche 
Bezeichnung ist, denn wenn man Yalus Gedankengang fortgesetzt:
> Auf die Interpretation der Inkrementalgeberausgabe als 2-Bit-Gray-Code
> bin ich das erste Mal vor ein paar Jahren in Hobyelektronikforen
> gestoßen. Vielleicht kommt demnächst ein IC-Hersteller auf die Idee, ein
> Toggle-Flipflop als einen 1-Bit-Gray-Code-Zähler aufzuwerten ;-)

könnte man damit einen Inkrementalgeber auch als Absolutwertgeber 
bezeichnen. Das ist rein technisch sicher auch richtig, aber praktisch 
und vom Verständnis her wenig sinnvoll und sicher die wenigsten würden 
das als eine "elegante" Bezeichnung verstehen.
So gesehen kann ich dann auch einen Taster (oder wenigstens eine 
Kodierung mit nur einem Strich) als Absolutwertgeber bezeichnen, da er 
ja eine absolute 0 und eine absolute 1 ausgibt.

Michael K. schrieb:
> könnte man damit einen Inkrementalgeber auch als Absolutwertgeber
> bezeichnen

Das ist absurd. Ein Inkrementalgeber gibt über seinen gesamten 
Meßbereich ein periodisches Signal ab, ein Absolutgeber ein 
nicht-periodisches.

Bernd K. schrieb:
> Weil ausgerechnet die Bits 2 und 3 des Gray-Codes dem Bild der beiden
> Spuren A und B eines Inkrementalgebers entsprechen, handelt es sich
> natürlich und selbstverständlich um den Gray-Code. NAK.
>
> Meine These:
> Um bei Inkrementalgebern eine richtungsabhängige Erkennung zu
> ermöglichen, hat man zur Spur A eine um 90° versetzte Spur B
> eingerichtet. Hierdurch kann man durch relativ einfache Logik
> die Richtung erkennen und auswerten. Dass die beiden Spuren
> mit den Bits 2 und 3 des Gray-Codes übereinstimmen, war nie
> beabsichtigt und ist rein zufällig.

Na ja, das liegt wohl daran, daß beide dasselbe Problem haben:

Wenn sich von einer Position zur nächsten nicht nur ein Signal ändern 
muss sondern mehrere, wie stellt man sicher, daß sie sich auch exakt 
gleichzeitig ändern damit es keinen Zeitpunkt gibt in der 
Zwischenzustände auftreten ?

Richtig, gar nicht.

Also bleibt nur eine Codierung, bei der sich beim Überganz von einem zum 
nächsten Codepunkt nur ein Signal ändert.

Eine davon ist der Gray-Code. Bei 2 bit gibt es überhaupt nur eine 
Möglichkeit der codierung, bei 2 bit hat man also zwangsweise einen Gray 
Code.

Ob man den nun mit 2 bit für relative Erfassung oder mit (16) bit für 
absolute ocdierung baut, kann sich dann der Benutzer nach seinen 
Erfordernissen aussuchen.

Walter T. schrieb:
> Michael K. schrieb:
>> könnte man damit einen Inkrementalgeber auch als Absolutwertgeber
>> bezeichnen
>
> Das ist absurd.
Aber technisch gesehen ist es richtig:
Ein 2-Bit-Absolutwertgeber liefert exakt 2^2 Werte und umfasst damit 
einen Bereich von 0-3, also nicht periodisch.
Da das trotzdem noch ein üblicherweise als Inkrementalgeber bezeichneter 
Geber ist merkt man, dass die Aussage
>Ein Inkrementalgeber gibt über seinen gesamten Meßbereich ein periodisches 
>Signal ab,
falsch ist

Klaus schrieb:
> Wenn man auf die Weise weiter denkt, dann ist ein Inkrementalgeber auch
> eine Banane.
Sorry, aber während ich mich lediglich Yalu's Gedanken fortgesetzt habe 
bleibt mir unschlüssig, wie du auf eine Banane kommen willst.

Michael B. schrieb:

> Wenn sich von einer Position zur nächsten nicht nur ein Signal ändern
> muss sondern mehrere, wie stellt man sicher, daß sie sich auch exakt
> gleichzeitig ändern damit es keinen Zeitpunkt gibt in der
> Zwischenzustände auftreten ?
>
> Richtig, gar nicht.
>
> Also bleibt nur eine Codierung, bei der sich beim Überganz von einem zum
> nächsten Codepunkt nur ein Signal ändert.
>
> Eine davon ist der Gray-Code.

Falsch! Jede solche Codierung ist ein Gray-Code.

Zum wiederholten Male: es gibt nicht den Gray-Code. Es gibt lediglich 
Codes die Gray-Codes sind und welche die das nicht sind.

Walter T. schrieb:
> Das ist absurd. Ein Inkrementalgeber gibt über seinen gesamten
> Meßbereich ein periodisches Signal ab, ein Absolutgeber ein
> nicht-periodisches.

wenn du weiter drehst, siehst du bald, daß auch ein Absolutwertgeber ein 
periodisches Signal hat.
Sinnvollerweise hat man auch beim Übergang von einer Periode zur 
nächsten nur ein Bit, das wechselt.

Klaus schrieb:
> Weil Du von gewissen Eigenschaften eines Inkrementalgebers abstrahieren
> musst um ihn als Absolutgeber bezeichnen zu können.
Und die wären?

Ich befürchte eher, du verstehst den Gedankengang nicht und unterstellst 
mir daher eine Abstraktion, die nicht stattgefunden hat.

Ein Inkrementalgeber liefert zwei um 90° versetzte Rechtecksignale, die 
Einzelschritte in beliebige Richtung anzeigen, aber (eigentlich) keine 
absolute Position.

Ein Absolutwertgeber hingegen liefert, i.d.R. graycodiert, einen Wert, 
der einer absoluten Position entspricht.

Jetzt habe ich analog zur oben durchgeführten Spurreduzierung am 
Graycode
 das ganze auf Absolutwertgeber angewandt:
Ein 16-Bit Absolutwertgeber hat 16 Spuren und kann 65536 
Absolutpositionen ausgeben.
Ein 12-Bit Absolutwertgeber hat 12 Spuren und liefert 4096 Absolutpos.
Ein 12-Bit Absolutwertgeber hat 12 Spuren und liefert 4096 Absolutpos.
Ein 8-Bit Absolutwertgeber hat 8 Spuren und liefert 256 Absolutpos.
Ein 4-Bit Absolutwertgeber hat 4 Spuren und liefert 16 Absolutpos.
Ein 3-Bit Absolutwertgeber hat 3 Spuren und liefert 8 Absolutpos.
Ein 2-Bit Absolutwertgeber hat 2 Spuren und liefert 4 Absolutpos.*
Ein 1-Bit Absolutwertgeber hat 1 Spuren und liefert 2 Absolutpos.

Und der 2-Bit-Absolutwertgeber ist zufällig unser Inkrementalgeber :-)
Und so wie jeder eine Bezeichnugn eines Inkrementalgebers als 
Absolutwertgeber als "unglücklich" oder "abstrus" bezeichnen würde halte 
ich die Bezeichnung einen Inkrementalcodes als Graycode für unglücklich 
- auch wenn es technisch betrachtet richtig sein mag.

Und für die Textfragmentpicker: Ich würde nir einen Inkrementalgeber als 
Absolutwertgeber bezeichnen, ich sage nur, man könnte.

> Aber für  eine sachliche, irgendwohin führende Diskussion ist das nicht
> hinreichend.
Fass dir ersmtal an die eigene Nase, weil Hinweise auf Bananen sind 
weder sachlich noch zielführend :-)

> aber so langsam habe ich den Eindruck, dass Du nur unbedingt recht haben
> willst.
Stimmt ... erwischt ... deshalb schrieb ich oben auch:
Michael K. schrieb:
> Aargh, stimmt.
> Ich nehm alles zurück :-)

Heizer schrieb:
> Man könnte noch ein weiteres Signal einfügen das die Gültigkeit der
> Daten anzeigt wie man das auch bei parallelen Bussen macht.

Dann weiß man zwar, dass das Signal ungültig ist/war, aber ggfs. nicht, 
wie es richtig ist. Gerade bei Positionsgebern wäre es fatal, wenn 
Schritte nicht erkannt werden, da die Synchronität verloren geht und 
dann ggfs. erst eine Referenz neu angefahren werden muss.

Und das zweite Problem: Wie bastelt man das Kontrollsignal bzw. welche 
Kriterien? Hier steht man dann wieder vor den gleichen Problemen wie 
beim entprellen.

Was für eine schrecklich unsinnige Diskussion. Aber es sind wohl 
Herbstferien und der eine oder andere Schüler hat Langeweile.

Auch wen ich den Mikrocontroller Drehgeber Artikel aus diversen Gründen 
persönlich auch für nicht besonders gelungen halte, so muss man dennoch 
zugestehen das  hier Leute unentgeltlich zumindest den Versuch 
unternommen haben etwas lehrreiches zu schreiben, Wem es nicht gefällt, 
der muss es ja auch nicht lesen. Wer meint es besser zu können und die 
Zeit und Lust hat, der kann ja jederzeit selber etwas schreiben.

Das Prinzip der Auswertung des für den gemeinen "Hobbybaster" 
interessanten Drehgeber's ist eben so simpel wie Tasten zu entprellen, 
oder ein "Hello World" zu programmieren. Man kann es auf die 
Handinnenfläche schreiben.

(1) Man liest in kurzen Zeitabständen die Encodersignale A u B ein.
Macht man das mehr als einmal hat mein jeweils immer einen Zustand (A u 
B) neu und einen Zustand (A u B) vorher, vorausgesetzt man speichert die 
eingelesenen Werte irgendwo zwischen.


(2) Jetzt wertet man aus: Ist A-neu ungleich B-vorher zählt man z.B. 
eine Variable hoch. Ist B-neu ungleich A-vorher zählt man die selbe 
Variable runter.

Das war es.

In Assembler sind das vielleicht 10,  15 Instruktionen, auch die kann 
man sich mal eben in der Handinnenfläche notieren.  Das sollte jeder 
umsetzen können der es schafft einen Timer nebst ISR ans laufen zu 
bringen.


Warum man dafür seitenweise Tutorials benötigt mit diversen bunten 
Bildern ist mir schleierhaft.

Michael K. schrieb:
> Und der 2-Bit-Absolutwertgeber ist zufällig unser Inkrementalgeber :-)

Das geht nur fuer einen Inkrementalgeber welcher 4 Positionen pro 
Umdrehung hat. Genauso wie ein 2-Bit Absolutwertgeber wird der sehr 
schwer zu finden sein.

> Und für die Textfragmentpicker: Ich würde nir einen Inkrementalgeber als
> Absolutwertgeber bezeichnen, ich sage nur, man könnte.

Fuer die Marktueblichen Inkrementalgeber kann man das nicht, da das 
'4-Bit Quadratur-Muster' mehrfach pro Umdrehung vorkommt.

Cheers, Roger

Da es sowieso nur eine theoretische Betrachtung ist...
Zumindest sind mir aber schon (ältere) Inkrementalgeber mit lediglich 4 
Impulsen pro U als Bedienelement begegnet.

@ Planlos (Gast)

>Kann dir aber völlig schnuppe sein.
>Ob deine Auswertung funktioniert, hängt nicht davon ab ob beim
>Programmieren explizit "Yay! Gray-Code!" oder "Hey! Flankenwechsel! Da
>ist was passiert!" gedacht hast.

Das ist das Hummelparadoxon!

Eine Hummel hat keine Ahnung von Aerodynamik und nach deren Gesetzen 
kann sie auch nicht fliegen! Sie tut es trotzdem!

@ m.n. (Gast)

>Hier werden sin/cos-Signale ausgewertet, was nun kein Gray mehr sein
>kann, da sich die analogen Spannungen immer gleichzeitig verändern.

Das ist ein QAM Demodulator ;-)