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!
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
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?)
:
Bearbeitet durch User
Bitte 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.