Hallo,
Jeder kennt ja Drehgeber. hier wurde auch viel dazu gefragt und
geschrieben.
Einer der bekannteren Hersteller ist z.b. die Firma ALPS:
http://www.alps.com/prod/info/E/HTML/Encoder/Incremental/Incremental_list1.html
Schaut euch mal die Reihe EC12 an, insbesondere das Schaltmuster.
Die Rastungen liegen bei allen Exemplaren der Serie auf dem
Umschaltpunkt von Phase B.
Kann mir mal jemand den Sinn dessen erklären? Mir fällt jetzt kein
Einsatzfall ein, indem sowas gebraucht wird (und nicht ein anderer
Rastpunkt
viel besser geeignet wäre). Denn dabei wird die Auswertung nur unnötig
verkompliziert.(egal, ob einfaches Sampling oder flankengetriggert).
Kennt jemand einen Einsatzfall dieser Drehgeber?
Kopfschüttelnd
Andy
Andy schrieb:> Die Rastungen liegen bei allen Exemplaren der Serie auf dem> Umschaltpunkt von Phase B.
Ist doch in Ordung. Das A-Signal ist dort stabil. Und daraus leitest du
deine Zählerei ab.
Andy schrieb:> Die Rastungen liegen bei allen Exemplaren der Serie auf dem> Umschaltpunkt von Phase B.
Ist für die Leute, die Entprellen nicht verstehen (wollen).
Die schalten dann RC-Glieder dahinter und Phase A auf nen
Flankeninterrupt.
Andy schrieb:> Die Rastungen liegen bei allen Exemplaren der Serie auf dem> Umschaltpunkt von Phase B.
Das ist Unsinn! Die Rastpunkte liegen ~ in der Mitte zwischen den
Umschaltpunkten von Spur A und können für Spur B nicht spezifiziert
werden. Mess doch einfach mal nach, wenn du die Möglichkeit hast!
<edit> -> wenn man das mit Interrupts auswerten möchte, dann den IR auf
A!
Volker S. schrieb:> Das ist Unsinn! Die Rastpunkte liegen ~ in der Mitte zwischen den> Umschaltpunkten von Spur A und können für Spur B nicht spezifiziert> werden. Mess doch einfach mal nach, wenn du die Möglichkeit hast!
Es ist spezifiziert, dass die Rastpunkte beim Umschaltpunkt von Spur B
liegen. Folglich lässt sich nicht sagen, ob der Flankenwechsel von B vor
oder nach dem Rastpunkt erfolgt. Das kann sich sogar mit der Temperatur
oder sonstwas ändern.
Wolfgang schrieb:> Es ist spezifiziert...
Da steht doch "*Detent position cannot be specified for B signal"
Verstehe ich das jetzt vollkommen falsch?
Ist aber auch völlig egal, wenn die Auswertung bei den Flanken von
Signal A erfolgt ;-)
Im Zweifelsfall einfach mal messen!
Volker S. schrieb:> Da steht doch "*Detent position cannot be specified for B signal"> Verstehe ich das jetzt vollkommen falsch?
Das Diagramm sagt, dass der Flankenwechsel von B unmittelbar beim
Rastpunkt stattfindet. Es lässt sich aber nicht sagen, ob vor- oder
nachher.
Peter D. schrieb:> Ist für die Leute, die Entprellen nicht verstehen (wollen).> Die schalten dann RC-Glieder dahinter und Phase A auf nen> Flankeninterrupt.
Na, wo bleibt denn der obligatorische Link auf DEINE Entprellroutine?
Kann doch nicht angehen, daß diese Chance ausgelassen wird!
Wolfgang schrieb:> Volker S. schrieb:>> Da steht doch "*Detent position cannot be specified for B signal">> Verstehe ich das jetzt vollkommen falsch?>> Das Diagramm sagt, dass der Flankenwechsel von B unmittelbar beim> Rastpunkt stattfindet. Es lässt sich aber nicht sagen, ob vor- oder> nachher.
OK, anders ausgedrückt sagt das Diagramm: "Wenn du irgendwelche Flanken
auswerten willst, dann nimm die von Signal A"
(Wie das Signal B beim Rastpunkt aussieht, ist dann doch sch... egal ;-)
<edit> Zumindest ist es sch... egal bei der Flanken-Interrupt
Auswertung.
Klar hab ichs nachgemessen: Man nehme einen schönen großen
Plastedrehkopf oben auf die Achse, und schon hat man ein schickes
modernes Kohlemikrofonimitat.
Das Signal nerft einfach nur in der Schaltung rum und stört nur allein
deshalb kaum, weil es (bis auf einen kurzen Moment) stets ignoriert
wird.
Alternativ kann es auch als Lehrbeispiel zum Verständniss des
Entprellens herhalten: der Kontakt "hört nicht auf zu prellen". Ergo
helfen keine RC-Glieder und keine Zeitkonstanten.
(braucht man auch nicht)
Klar lässt sich das dekodieren. Aber welchen Grund gibt es, sowas
einzusetzen und nicht einen Geber, der im Rastpunkt definierte Signale
hat?
Ich dachte immer, solche Geber sind billig-Chinaware, die ohne Verstand
zusammengesetzt wurden. Und jetzt sehe ich, daß ALPS daraus ne ganze
Serie gebaut hat.
wirre Verschwörungstheorie: Das ist dazu da, um Leute zu verarschen:
Beim Analysieren einer Platine schaust du dir alle Eingänge an, siehst
da was unregelmäßig zappeln, schimpfst auf deinen Logikanalysator, weil
ers auch nicht erkennt, nur um dann zu schauen, daß das Signal vom
Drehgeber kommt :*)
Andy schrieb:> Das Signal nerft einfach nur in der Schaltung rum und stört nur allein> deshalb kaum, weil es (bis auf einen kurzen Moment) stets ignoriert> wird.
Bei der Flanken IR Methode wird es IMMER ignoriert, also was solls?
(Signal B muss man so gesehen auch nicht entprellen)
Unabhängig davon, dass es mir (gewöhnlich) egal ist, was Signal B im
Rastpunkt macht, habe ich bei meinen Messungen nie nachweisen können,
dass dieses Signal "im" Rastpunkt schaltet. Kann ich aber morgen nochmal
an ein paar von den Teilen testen...
Andy schrieb:> Klar lässt sich das dekodieren. Aber welchen Grund gibt es, sowas> einzusetzen und nicht einen Geber, der im Rastpunkt definierte Signale> hat?
Die (nutzbare) Auflösung ist durch die Rasten vorgeben. Was für Vorteile
versprichst du dir also von einer anderen Rastpunktposition?
Das AB-Signal kennt vier Zustände. Bei periodischer Abfrage und Nutzung
der geraden Zustände für die Positionsausgabe, hat man genau eine
(stabile) Ausgabe zu jedem Rastpunkt - mehr will man doch nicht.
Vorteile eines definierten Signals B zur Rastposition:
-durch Vertauschen der Drähte von A und B kannst du einfach die Richtung
wechseln, ohne den yC umprogrammieren zu müssen.
-in meinem Fall (von Dummheit) keinen Nachmittag sinnlos beim
fremde-schaltung-verstehen verschwenden (siehe Verschwörungstheorie)
-PeDas Drehgeberroutine nutzen können (die auf Sampling basierte)
vorteil obigen drehgebers: ein unzuverlässiger TRNG??
Andy schrieb:> Vorteile eines definierten Signals B zur Rastposition:> -durch Vertauschen der Drähte von A und B kannst du einfach die Richtung> wechseln, ohne den yC umprogrammieren zu müssen.
Wenn da Drähte sind...
> -in meinem Fall (von Dummheit) keinen Nachmittag sinnlos beim> fremde-schaltung-verstehen verschwenden (siehe Verschwörungstheorie)
Dieser Art von "Dummheit" ist keiner gefeit ;-)
> -PeDas Drehgeberroutine nutzen können (die auf Sampling basierte)
Warum funktioniert die nicht trotzdem?
<edit>Genau da soll doch der angebliche ultimative Vorteil liegen :-(
> vorteil obigen drehgebers: ein unzuverlässiger TRNG??
Was bedeutet TRNG?
PeDa hat eine elegant-einfache routine gepostet, die z.b. in einen
timer-interrupt mitläuft und keinen extra flanken-int. braucht.
Sie reagiert auf die Wechsel der Signale zur vorhergehenden Abfrage. Da
man damit prinzipbedingt nicht exakt den moment erfährt, an dem A
wechselt, kannst du nicht erkennen, ob die zufälligen wechsel auf B
einen Schritt zum Zählen bedeuten, oder ein Schritt des Bedieners vor
dem Gerät ist.
Klar kann man das umgehen: entweder man erhöht massiv die Timerrate oder
man zählt nur jeden zweiten Schritt (1x A erkannt= 1x B lesen. Jede
weitere Flanke von B ignorieren) und verliert so den Vorteil des
GrayCodes, da zwei Bitwechsel gelesen werden müssen (und somit nicht
mehr als Signal für Lesefehler gelten)
TRNG= true random number generator zufallsgenerator.
Würde mich nicht wundern, wenn jmd das tatsächlich so nutzt ;)
Andy schrieb:> Klar kann man das umgehen: entweder man erhöht massiv die Timerrate oder> man zählt nur jeden zweiten Schritt
Bei einem Drehgeber mit Rasten und ist es sowieso sinnlos, jeden Schritt
zu zählen. Es bringt nichts, pro Raste immer mehrere Schritte weiter zu
zählen.
Andy schrieb:> PeDa hat eine elegant-einfache routine gepostet...
Ja schon - und die müsste doch eigentlich auch bei prellendem Signal B
funktionieren!
Wie hoch ist denn die Abtastrate?
Ja, richtig. Jeden Flankenwechsel als Schritt zu zählen, macht bei
rastenden Gebern wenig Sinn. Mit Zählen meinte ich Erkennen. Falsche
Wortwahl.
Ja, PeDas Routine kann damit umgehen, aber das geschieht auf Kosten der
Sicherheit des Graycodes. Das liegt aber nicht an PeDas Routine, alle
anderen Routinen sind gleichermaßen gehandikapped.
Es liegt am Drehgeber: da du nicht weißt, wo B in Ruhe steht, kann ein
weiterer Fehler diesmal in A eine Fehlerkennung ergeben. Allein durch
die unglückliche Konstruktion des Drehgebers verliert man also
Sicherheit.
Andy schrieb:> Das liegt aber nicht an PeDas Routine, alle> anderen Routinen sind gleichermaßen gehandikapped.
Na ja, die Flankenerkennung von A wäre nicht betroffen ;-)
Andy schrieb:> Ja, PeDas Routine kann damit umgehen, aber das geschieht auf Kosten der> Sicherheit des Graycodes.
Also wenn die Rutine damit umgehen kann, wovon ich eigentlich überzeugt
bin, kann es doch kein Problem mit der Sicherheit geben.
Andy schrieb:> Allein durch die unglückliche Konstruktion des Drehgebers verliert> man also Sicherheit.
Den bekannten Spruch von Dieter Nuhr kennst du?
Was soll bei dem Geber unsicher sein?
Da hat es tatsächlich wer gewagt den Gott der Entprellung heraus zu
fordern Das hast du jetzt davon. -3! Ok ich geb dir ein Lesenswert, auch
wenn mich das wer weiß was kostet ;-)
Doch, gibt es: wenn bei einem "normalen" geber mal eins der signale
fehlerhafterweise wackelt, kann es zu 50% ganz weggefiltert, zu 50% ein
einzelnen fehlschritt geben.
Wenn beim EC12 mal das Signal A wackelig ist, kann dir der ganze Zähler
hinter der Geberroutine weglaufen. Und es gibt nichts, was das erkennen
kann.
Andy schrieb:> Wenn beim EC12 mal das Signal A wackelig ist
Warum sollte das Signal A wackelig sein? Bediener mit Parkinson?
Warum sollten A und B gleichzeitig wackelig sein?
PEEEDAAAAAA, erklär doch bitte mal dem ungläubigen Andy deine
unantastbare göttliche Routine...
Volker S. schrieb:> Andy schrieb:>> Das liegt aber nicht an PeDas Routine, alle>> anderen Routinen sind gleichermaßen gehandikapped.> Na ja, die Flankenerkennung von A wäre nicht betroffen ;-)
Jein. die Flankenerkennung gibt sich gar nicht erst die Mühe, einen evtl
Fehler zu finden und rauszurechnen. Von daher stehen dann alle auf der
gleichen Stufe.
Andy schrieb:> Jein. die Flankenerkennung gibt sich gar nicht erst die Mühe, einen evtl> Fehler zu finden und rauszurechnen.
Was für ein Fehler soll da denn sein?
Letztendlich ist mit beiden Varianten eine saubere Dekodierung möglich,
sofern man dabei richtig vorgeht.
Ein kleiner (ästhetischer) Vorteil der Rastung auf einer der beiden
B-Flanken wäre, dass die andere B-Flanke in der Mitte zwischen den
Rastungen liegt. Damit erfolgt auch die In-/Dekrementierung des
ausgegebenen Werts mittig (linkes Bild). Liegen die Rasten hingegen wie
im rechten Bild, erfolgt der Wechsel des ausgegebenen Werts immer
außermittig.
Da in beiden Varianten mehrere Flanken zwischen zwei Rastungen vorhanden
sind, kann dies für eine Hysteres beim In-/Dekrementieren genutzt
werden, so dass der ausgegebene Wert beim langsamen Drehen zwischen zwei
Rastungen nirgends zappelt. Soll der Hysteresebereich mittig zwischen
zwei Rastungen liegen, ist das ebenfalls mit beiden Varianten möglich,
im rechten Bild liegen dann aber die Schaltpunkte näher zusammen und
weiter entfernt von den Rastungen, so dass die Hysterese dem Anwender
weniger negativ auffällt. Das wäre also ein (ebenfalls ästhetischer)
Vorteil der rechten Variante.
Den meisten Anwender wird aber der Unterschied (Umschalten mittig oder
außermittig, mit oder ohne Hysterese) gar nicht auffallen. So dass ich
den Encoder eher nach anderen Kriterien, bspw. dem Wellendurchmesser
auswählen würde ;-)
Andy schrieb:> Jein. die Flankenerkennung gibt sich gar nicht erst die Mühe, einen evtl> Fehler zu finden und rauszurechnen.
Eine explizite Flankenerkennung brauchst du gar nicht. Es reicht, wenn
du einfach regelmäßig den Geberzustand ausliest. Du baust einen
Zustandsautomaten, der mit dem vorherigen und dem aktuellen Zustand
gesteuert wird. Der funktioniert ohne irgendwelche Fehlerstatistik und
Heuristik.
Wolfgang schrieb:> Andy schrieb:>> Jein. die Flankenerkennung gibt sich gar nicht erst die Mühe, einen evtl>> Fehler zu finden und rauszurechnen.>> Eine explizite Flankenerkennung brauchst du gar nicht. Es reicht, wenn> du einfach regelmäßig den Geberzustand ausliest. Du baust einen> Zustandsautomaten, der mit dem vorherigen und dem aktuellen Zustand> gesteuert wird. Der funktioniert ohne irgendwelche Fehlerstatistik und> Heuristik.
Genau, und darum sollte PeDa's Automat doch funktionieren.
Ich kann das Problem irgendwie nicht sehen...
Yalu X. schrieb:> Letztendlich ist mit beiden Varianten eine saubere Dekodierung möglich,> sofern man dabei richtig vorgeht.
Natürlich, wer würde sonst so was produzieren ;-)
Deine "zwei" Varianten sind jetzt aber ganz was neues in diesem Thread.
Bisher hatten wir ja nur die linke...
Volker S. schrieb:> Deine "zwei" Varianten sind jetzt aber ganz was neues in diesem Thread.> Bisher hatten wir ja nur die linke...
Die rechte (das Diagramm stammt vom EC11) dient nur dem Vergleich. Wenn
ich den TE richtig verstanden habe, entspricht diese voll seinen
Vorstellungen, während er bei der linken gewisse Bedenken hat.
Yalu X. schrieb:> Volker S. schrieb:>> Deine "zwei" Varianten sind jetzt aber ganz was neues in diesem Thread.>> Bisher hatten wir ja nur die linke...>> Die rechte (das Diagramm stammt vom EC11) dient nur dem Vergleich. Wenn> ich den TE richtig verstanden habe, entspricht diese voll seinen> Vorstellungen, während er bei der linken gewisse Bedenken hat.
Eigentlich ist der Unterschied der, dass bei der linken Variante
zwischen den Rastpunkten jeweils ein "ON"-Impuls kommt und bei der
Rechten das Signal zwischen On und OFF wechselt.
Die Linke Variante hat den Vorteil, dass im Ruhe/Rast-zustand beide
Schalter immer offen sind und so kein Strom fließen kann, falls Signal B
auch vor dem Rastpunkt wieder öffnet. Das war meiner Erfahrung nach auch
bisher immer der Fall. Andy hat aber anscheinend andere Erfahrungen
gemacht...
Die linke Art kann man sicher auch ohne Mehraufwand so konstruieren,
dass die Umschaltpunkte zuverlässig abseits der Rastpunkte liegen. Warum
sollte das also nicht so sein? (oder warum sind die Datenblätter so
merkwürdig?)
