Forum: Mikrocontroller und Digitale Elektronik Sinn und Zweck von EC12


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Andy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Volker S. (vloki)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
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
von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dick Aufträger (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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!

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
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
von Andy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :*)

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Wolfgang (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Andy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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??

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
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
von Andy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

von Wolfgang (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
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
von Andy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Volker S. (vloki)


Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
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 ;-)

von Andy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
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
von Andy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Yalu X. (yalu) (Moderator)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Yalu X. (yalu) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.