Forum: Mikrocontroller und Digitale Elektronik Frage zur Dekodierung von Drehencodern


von Manuel K. (manuel1139)


Angehängte Dateien:

Lesenswert?

Hallo!

Mache jetzt schon drei Tage an einem erst einmal sehr leicht aussehenden 
Problem.

Hab diesen Drehencoder von Pollin 
http://www.pollin.de/shop/downloads/D240313D.PDF

Wenn ich mir jetzt das Datenblatt ansehe dann "sitzt"  der erste 
Rastpunkt genau auf der B-Flanke.

Wenn ich jetzt am Decoder drehe dann bekomme ich alle möglichen 
Zustände. Was ich damit sagen will ist das der Rastpunkt alle "Werte" 
bekommen kann. AB 0,0 0,1 1,0 und 1,1. Ist das so gewollt oder verstehe 
ich da irgendwas falsch?

Ich hätte gedacht das  jeder Rastpunkt auf einem festen wert steht?!

: Bearbeitet durch User
von Jonas K. (jonas_k)


Lesenswert?


: Bearbeitet durch User
von Harald W. (wilhelms)


Lesenswert?

Jonas K. schrieb:

> https://de.wikipedia.org/wiki/Inkrementalgeber#Signalauswertung
> http://www.mikrocontroller.net/articles/Drehgeber

Oder auch dse faq. Wichtig ist, das man die Zustände, und nicht
die Flanken detektiert.
Gruss
Harald

von deathfun (Gast)


Lesenswert?

Hallo Manuel,

ja das ist so gewollt. Sonst könntest du ja keine Richtung erkennen.


Die Dinger heißen auch oft Drehimpulsgeber oder Rotary Switch. Eine 
suche hier im Forum ergab sogar etwas fertiges in der Codesammelung:
Beitrag "Drehimpulsgeber mit Rasterstellung bei 00/11 auswerten"




Gruß
deathfun

von Klausb (Gast)


Lesenswert?

Hi,

schau Dir mal den Kode hier an

Beitrag "Pollin Panasonic Encoder für Interrupt Fans"

Die Theorie dazu.

Vom Drehgeber A bzw. B wird mit einem Interrupteingang verbunden. Ich 
geh davon aus Pin A.
B wird mit einem normalen Eingang verbunden.

Der Interrupt erfolgt Flankengesteuert.
In der Interrupt Routine wird der Eingang für PIN B abgefragt. Je nach 
Niveu von B wird links oder Rechts rum gedreht.
Anschliessend wird die Erwartung für den nächsten Interrupt von fallend 
auf steigend beziehungsweise anderherum gesetzt.

von Thomas E. (thomase)


Lesenswert?

Klausb schrieb:
> Hi,
>
> schau Dir mal den Kode hier an

Lieber nicht!

> Beitrag "Pollin Panasonic Encoder für Interrupt Fans"
>
> Die Theorie dazu.
>
> Vom Drehgeber A bzw. B wird mit einem Interrupteingang verbunden. Ich
> geh davon aus Pin A.
> B wird mit einem normalen Eingang verbunden.
>
> Der Interrupt erfolgt Flankengesteuert.
> In der Interrupt Routine wird der Eingang für PIN B abgefragt. Je nach
> Niveu von B wird links oder Rechts rum gedreht.
> Anschliessend wird die Erwartung für den nächsten Interrupt von fallend
> auf steigend beziehungsweise anderherum gesetzt.

Funktioniert leider so wie der ganze Kot aussieht: Wie hingeschissen.

Drehenkoder fragt man nicht mit Interrupts ab. Oder glaubst du, die 
ganzen Leute, die das hier ständig predigen, sind alles Idioten und du 
hast das Ei des Columbus entdeckt?

mfg.

von Zittermann (Gast)


Lesenswert?

Thomas schrieb:
>Lieber nicht!

Was soll das?

Zitat aus dem o.g. Thread:
>Bisher keine Probleme wegen "Prellens" festgestellt.

Der Code ist dort 65 mal heruntergeladen worden und es gab keinen
Kommentar, daß er nicht funktionieren würde.

>Drehenkoder fragt man nicht mit Interrupts ab.
Das bestimmst Du nicht.
>Oder glaubst du, die ganzen Leute, die das hier ständig predigen, sind >alles 
Idioten und du hast das Ei des Columbus entdeckt?

Glaubst Du, anderen Leuten verbieten zu können, selbst etwas
auszuprobieren?

gez. Zittermann

von spess53 (Gast)


Lesenswert?

Hi

>Der Code ist dort 65 mal heruntergeladen worden und es gab keinen
>Kommentar, daß er nicht funktionieren würde.

Der Zähler erhöht sich schon, wenn man sich den Code ansieht. Also kein 
Indiz, das den jemand ausprobiert hat.

Vernünftigen Code findet man hier:

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

MfG Spess

von spontan (Gast)


Lesenswert?

Jeder kann die Fehler machen, die er möchte. Auch Du und alle anderen.

Das Problem ist aber ein anderes:
Du empfiehlst einen Code, hast aber anscheinend von der Problematik der 
Drehgeber keine Anhnung. Allein durch logisches Nachdenken ist 
erkennbar, was für ein Bockmist die Interrupt-Erkennung von diesen 
Drehgebern darstellt.

Wenn das Nachdenken nicht reicht, dann lies die erwähnten Artikel oder 
Applikationen dazu.

von m.n. (Gast)


Lesenswert?

Thomas Eckmann schrieb:
> Oder glaubst du, die
> ganzen Leute, die das hier ständig predigen, sind alles Idioten und du
> hast das Ei des Columbus entdeckt?

Darf man denn auch mit 'ja' antworten?

Im obigen Datenblatt sind Tiefpassfilter 10k/10nF in Reihe zum 
µC-Eingang eingezeichnet. In Verbindung mit der Eingangshysteres des AVR 
(?) ist dies schon eine hinreichende Entprellung.

Zittermann schrieb:
> Der Code ist dort 65 mal heruntergeladen worden und es gab keinen
> Kommentar, daß er nicht funktionieren würde.

Es hat aber auch keiner gechrieben, dass es funktioniert.
Vielleicht hängt das auch von der Einstellung von und zu delay() ab :-)

von spontan (Gast)


Lesenswert?

>Im obigen Datenblatt sind Tiefpassfilter 10k/10nF in Reihe zum
>µC-Eingang eingezeichnet. In Verbindung mit der Eingangshysteres des AVR
>(?) ist dies schon eine hinreichende Entprellung.

Das ist keine Entprellung. Das ist Bastelkram.

von ich (Gast)


Lesenswert?

Zittermann schrieb:
>>Drehenkoder fragt man nicht mit Interrupts ab.
> Das bestimmst Du nicht.
>>Oder glaubst du, die ganzen Leute, die das hier ständig predigen, sind >alles
> Idioten und du hast das Ei des Columbus entdeckt?
>
> Glaubst Du, anderen Leuten verbieten zu können, selbst etwas
> auszuprobieren?

Es geht hier nicht um "bestimmen" oder "verbieten". Es geht darum, daß 
es schon genügend Erfahrung mit dem Dekodieren von Drehgebern gibt. Und 
wenn es jemanden gibt, der auf dem Holzweg ist, dann sollte derjenige 
dann auch den Rat von den erfahreneren Leuten annehmen. "Das macht man 
nicht" ist kein Verbot, sondern ein Tipp, daß es falsch ist, das so zu 
machen.
Und auch hier im Forum gab es schon genügend Beiträge zu genau dem 
Thema. Jedesmal wird gezeigt, wie man es mit wenig Aufwand und ganz ohne 
Interrupts richtig macht. Und immer wieder gibt es Leute, die das nicht 
glauben und in der Verwendung von Interrupts die eierlegende 
Wollmilchsau sehen. Eine Suche im Forum würde viel Zeit ersparen und 
auch so manchen Frust...

von Harald W. (wilhelms)


Lesenswert?

Zittermann schrieb:

>>Drehenkoder fragt man nicht mit Interrupts ab.
> Das bestimmst Du nicht.

Es war noch nie besonders schwierig, anstatt einer guten, bekannten
Lösung für ein Problem, eine deulich schlechtere, unzuverlässigere
Lösung zu erfinden. Sinn macht diese "Interruptlösung" höchstens,
wenn man einen Encoder ohne µC nur mit D-Flipflops bauen will und
man das Ergebnis sieht und nachkorrigieren kann.
Gruss
Harald

von Zittermann (Gast)


Lesenswert?

Spontan unterstellte:
>Du empfiehlst einen Code, hast aber anscheinend von der Problematik der
>Drehgeber keine Anhnung.

Ich empfehle gar nichts, habe nicht einmal den Code ausprobiert.
Wogegen ich mich wende, ist die Einstellung: "Ich bestimme, was
und wie andere Leute zu programmieren haben!"

Jeder kann und darf seine Ideen auf dem Controller testen -er merkt
schon, wenn es nicht funktioniert.

gez. Zittermann

von Thomas E. (thomase)


Lesenswert?

Zittermann schrieb:
> Thomas schrieb:
>>Lieber nicht!
>
> Was soll das?
Das ist ein gut gemeinter Rat.

> Zitat aus dem o.g. Thread:
>>Bisher keine Probleme wegen "Prellens" festgestellt.
Ein Zeichen dafür, daß ihr die Technik des Enkoder-Einlesens nicht 
verstanden habt. Ein Enkoder braucht mit einer vernünftigen Abfrage 
überhaubt keine Entprellung.

> Der Code ist dort 65 mal heruntergeladen worden und es gab keinen
> Kommentar, daß er nicht funktionieren würde.
Dann gibt es den Kommentar jetzt: Der Code funktioniert nicht!

>>Drehenkoder fragt man nicht mit Interrupts ab.
> Das bestimmst Du nicht.

>>Oder glaubst du, die ganzen Leute, die das hier ständig predigen, sind >alles
> Idioten und du hast das Ei des Columbus entdeckt?
>
> Glaubst Du, anderen Leuten verbieten zu können, selbst etwas
> auszuprobieren?
Mach doch, was du willst.
Aber wenn einer fragt, wie man es machen soll und jemand ihm totalen 
Schrott anbietet, sage ich ihm, daß er die Finger davon lassen soll. 
Oder willst du mir das verbieten?
Der Link, unter dem steht, wie man es richtig macht, wurde mittlerweile 
von Spess gepostet.

mfg.

von ich (Gast)


Lesenswert?

Zittermann schrieb:
> Jeder kann und darf seine Ideen auf dem Controller testen -er merkt
> schon, wenn es nicht funktioniert.

Klar darf jeder seine eigenen Erfahrungen machen. Aber es ist nicht die 
feine Art, wenn man jemanden, der die Sackgassen kennt und einen davor 
bewahren will, auf die Finger zu hauen "ich kann programmieren, wie ich 
will". Man kann nicht jedes Problem von Anfang an kennen, aber man kann 
Irrwege vermeiden, wenn man auf Leute hört, die wissen, wie man es macht 
und vor allem, wie man es nicht macht.

von Manuel K. (manuel1139)


Lesenswert?

Hab mir hier schon einiges zu Drehencodern durchgelesen und hab mich für 
die Variante 1ms Interrupt entschieden.

Initialisert wird mit dem Einschaltzustand des Encoders. Dann 5x rechts 
+5 links und Breakpoint bei test_cnt>20. Das Array im Debugger ausgeben.

Leider ist das Ergebnis nicht wie erwartet eine Änderung der Bitfolge 
von z.B. 00 01 00 01 00 01 zu 11 10 11 10 11 10 beim ändern der 
Drehrichtung. Vielmehr wird immer  mit 00 01 angezeigt. Es scheint kein 
Richtungswechsel passiert zu sein.

Manchmal ändert sich auch die Bitfolge. Wenn ich zuerst nach rechts 
drehe dann kommt die 11 10 11 10. Auch hier ist die Änderung der 
Drehrichtung nicht zu sehen (immer noch 11 10 11 10) ?

Langsam drehen - schnell drehen - kein Unterschied.

1
char initialized = 0;
2
void Timer1Int(void);
3
4
UINT8 code_old = 0;
5
INT8 code_delta = 0;
6
7
void InitRotaryEnc(void){
8
    UINT8 code_new = 0;
9
    
10
    mInitRotaryEnc(); //input
11
12
    RegisterInt(TMR1_INT, &Timer1Int);
13
    mEnableInterrupts();
14
15
    CCPR1 = 0; //Timer data register zero (word)
16
    ADCON1 |= 0xF;  //all pins to digital
17
    IPR1bits.CCP1IP = 1; //Timer 1 as source
18
    RCONbits.IPEN = 1; //Interrupt priority
19
20
     // Configure Timer1
21
    OpenTimer1(T1_SOURCE_INT &
22
            T1_8BIT_RW &
23
            TIMER_INT_ON &
24
            //      T1_SOURCE_CCP &
25
            T1_PS_1_1);
26
27
    //get current detent steady point
28
29
    code_new |= PORTAbits.RA0;
30
    code_new<<=1;
31
    code_new |= PORTAbits.RA1;
32
    code_old = code_new;
33
34
    initialized = 1;
35
36
}
37
38
39
40
41
void Timer1Int(void) {
42
    UINT8 code_new = 0, code_diff = 0;
43
44
    static UINT8 tst_cnt = 0;
45
    static UINT8 tst_arr[100]= {0};
46
47
        code_new |= PORTAbits.RA0;
48
        code_new <<= 1;
49
        code_new |= PORTAbits.RA1;
50
51
        if (code_new != code_old) {
52
            code_old = code_new;
53
            if (tst_cnt < 20) {
54
                tst_arr[tst_cnt] = code_old;
55
                tst_cnt++;
56
            } else {
57
                tst_cnt = 0;
58
            }
59
        }

: Bearbeitet durch User
von Εrnst B. (ernst)


Lesenswert?

Manuel Kampert schrieb:
> Hab mir hier schon einiges zu Drehencodern durchgelesen

Im Artikel Drehgeber gibt's einen Abschnitt
"Dekoder für Drehgeber mit wackeligen Rastpunkten"

der Exakt für

Manuel Kampert schrieb:
> Hab diesen Drehencoder von Pollin

optimiert wurde.
Probier den mal.

von Axel S. (a-za-z0-9)


Lesenswert?

Manuel Kampert schrieb:
> Leider ist das Ergebnis nicht wie erwartet eine Änderung der Bitfolge
> von z.B. 00 01 00 01 00 01 zu 11 10 11 10 11 10 beim ändern der
> Drehrichtung. Vielmehr wird immer  mit 00 01 angezeigt.

Dann hat es geprellt. Bei einem prellfreien Drehgeber und hinreichend 
schneller Abtastung kommen immer alle 4 Zustände vor: 00 01 11 10 00 ... 
bzw. für die Gegenrichtung: 00 10 11 01 00 ...

Rastpunkte bedeuten nicht daß Zwischenzustände ausgelassen werden. 
Prellen bewirkt, daß das Encodersignal mehrfach zwischen immer den 
gleichen zwei Zuständen hin- und herspringt. Also bei Beachtung obiger 
Reihenfolge immer einen (Viertel-)Schritt vorwärts und einen rückwärts.

Eine vernünftige Software (im Gegensatz zur der Frickelei mit 
Interrupts von oben) schaut auf die Zustände und zählt nur dann, wenn 
die Zustände in der korrekten Reihenfolge durchlaufen werden. Wenn man 
allerdings die volle Auflösung will (Viertelschritte) dann bekommt man 
mit prellenden Encodern zwangsläufig häufige Wechsel +1/-1. Besser 
verwendet man Halbschritte, in einem kompletten Zyklus aus 4 Zuständen 
zählt man also nur zweimal weiter. Das ist dann auch garantiert 
prellfrei. Ganz ohne Gefrickel mit RC-Gliedern. Insbesondere kann man 
bei Encodern mit wackeligen Rastpunkten die beiden Schaltpunkte 
zwischen die Rastpunkte legen.


XL

von Manuel K. (manuel1139)


Lesenswert?

Erstmal vielen Dank für die ganzen hilfreichen Artikel. Eine letzte 
Frage:

        if (PORTAbits.RA0 == 0 && PORTAbits.RA1 == 0) {
            int i=0;
            i++;
        }
        if (PORTAbits.RA0 == 0 && PORTAbits.RA1 == 1) {
            int i=0;
            i++;
        }
        if (PORTAbits.RA0 == 1 && PORTAbits.RA1 == 0) {
            int i=0;
            i++;
        }
        if (PORTAbits.RA0 == 1 && PORTAbits.RA1 == 1) {
            int i=0;
            i++;
        }

sollte doch spätestens bei der achten Rasterung  bei 00 und 11 
angekommen sein - selbst  bei wackeligem Rastpunkt und starkem prellen?

von c-hater (Gast)


Lesenswert?

Thomas Eckmann schrieb:

> Drehenkoder fragt man nicht mit Interrupts ab.

Das bestimmst du?

> Oder glaubst du, die
> ganzen Leute, die das hier ständig predigen, sind alles Idioten

Alle nicht, aber einige von ihnen sind es bestimmt. Viele andere sind 
zumindest lernfähig.

In einem Punkt muß ich dir allerdings Recht geben. Der in

Beitrag "Pollin Panasonic Encoder für Interrupt Fans"

zitierte Code ist wirklich ziemlich Sch***. Er enthält gleich zwei 
wesentliche Schwächen.

Das bedeutet aber keinesfalls, daß es nicht möglich wäre, Drehencoder 
allein mit Interrupts sinnvoll und extrem rechenzeitsparend abzufragen. 
Man muß halt nur programmieren können, mehr ist dazu wirklich nicht 
nötig...

Und ja, ich muß zugeben, das geht sogar in C!

Jedenfalls wenn man über die in etwa verdoppelte allgemeine 
Interruptlatenz mal gnädig hinwegsieht, die in den meisten Anwendungen 
wohl keine so wichtige Rolle spielt. Jedenfalls nicht in denen, die 
sowieso rein in C geschrieben sind...

von Thomas E. (thomase)


Lesenswert?

c-hater schrieb:
> Thomas Eckmann schrieb:
>
>> Drehenkoder fragt man nicht mit Interrupts ab.
>
> Das bestimmst du?

Warum fragen eigentlich ständig irgendwelche Hampel, ob ich das 
bestimme?
Das ist einfach so. Also freu dich, Hatie. Du hast was dazu gelernt.

mfg.

von Axel S. (a-za-z0-9)


Lesenswert?

Thomas Eckmann schrieb:
> c-hater schrieb:
>> Thomas Eckmann schrieb:
>>
>>> Drehenkoder fragt man nicht mit Interrupts ab.
>>
>> Das bestimmst du?
>
> Warum fragen eigentlich ständig irgendwelche Hampel, ob ich das
> bestimme?

Du hättest es einfach anders formulieren müssen. Beispiel:

"Nur blutige Anfänger oder lernbehinderte Deppen fragen Drehenkoder 
mit Interrupts ab."

Da niemand freiwillig zugeben wird, in eine der genannten Kategorien zu 
fallen, wird der Widerspruch entsprechend geringer ausfallen.


XL

von Moritz A. (moritz_a)


Lesenswert?

Manuel Kampert schrieb:
> Erstmal vielen Dank für die ganzen hilfreichen Artikel. Eine letzte
> Frage:
>
>         if (PORTAbits.RA0 == 0 && PORTAbits.RA1 == 0) {
>             int i=0;
>             i++;
[…]

Du setzt in jedem der if-Blöcke eine lokale Variable auf 0, um sie dann 
um eins hochzuzählen. Sobald du aus den {} draußen bist, ist dein i aus 
dem Scope und damit "vergessen."

von innerand i. (innerand)


Lesenswert?

Manuel Kampert schrieb:

> sollte doch spätestens bei der achten Rasterung  bei 00 und 11
> angekommen sein - selbst  bei wackeligem Rastpunkt und starkem prellen?

Der sollte schon beim 3. Rastpunkt jeden Zustand durch haben.

btw: Was soll denn der Code den sie da gepostet haben Ihrer Meinung nach 
machen?

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Thomas Eckmann schrieb:
> Drehenkoder fragt man nicht mit Interrupts ab.
..
> Das ist einfach so. Also freu dich, Hatie. Du hast was dazu gelernt.

Du hast heute deinen arroganten Tag, ja?

Händisch bediente Drehencoder haben so seltene Ereignisse, daß man sie 
getrost per Interrupt abfragen kann - und sollte. Sowas zu pollen ist 
einfach nur Zeitverschwendung.

Schließlich kann der daraus entstehende Zählwert ja nur um exakt 1 hin 
und her wandern, wenn der Encoder prellen sollte. Das ist OK so, 
schließlich landet der Wert ja doch auf dem gewünschten Stand, sobald 
man über den Umschaltpunkt hinweg ist und in die Nähe der Rastung kommt.

Also, das "Das ist einfach so" kannst du getrost für dich behalten, es 
ist Mumpitz.

Und zum TO:
Manuel Kampert schrieb:
> AB 0,0 0,1 1,0 und 1,1.

Vielleicht ist dir aufgefallen, daß man das ganze reduzieren sollte. 
Signal A für den Interrupt und Signal B für die Richtung. Wenn also A 
sich ändert (beide Flanken beachten!), dann ersieht man aus (B xor A) 
die Richtung.

Drehrichtung = A xor B;

oder als ISR:
__isr void DrehMich (void)
{ if (a^b)
  ++MyCounter;
  else
  --MyCounter;
  ClearMyInterrupt();
}

Haben wir's jetzt?
(Leute, stellt euch nicht so ******* an!)

W.S.

von MaWin (Gast)


Lesenswert?

W.S. schrieb:
> Händisch bediente Drehencoder haben so seltene Ereignisse, daß man sie
> getrost per Interrupt abfragen kann - und sollte. S

Man ist blöd, wenn man das glaubt, prellen ist immer gleich schnell.

http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29

von Thomas E. (thomase)


Lesenswert?

W.S. schrieb:
> Du hast heute deinen arroganten Tag, ja?

> Also, das "Das ist einfach so" kannst du getrost für dich behalten, es
> ist Mumpitz.
Mit welcher Arroganz kommst du denn daher?
Erstens wirst du mir kaum erzählen, was ich für mich zu behalten habe 
und zweitens ist es kein Mumpitz.

Axel Schwenke schrieb:
> Du hättest es einfach anders formulieren müssen. Beispiel:

> "Nur blutige Anfänger oder lernbehinderte Deppen fragen Drehenkoder
> mit Interrupts ab."
Dem ist nichts hinzuzufügen.

mfg.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Das schöne bei gepollten Drehgebern ist, das man ihre 'Prellstärke' über 
das Zeitintervall in weiten Grenzen abfangen kann. Bei richtig ollen 
Drehgebern (z.B. aus alten Autoradios) ist die Prellerei so stark, das 
man am besten nur alle 5-10ms nachfragt.

Wer das in einem flankengetriggerten Interrupt macht, muss da richtig 
Zeit für aufwenden. Da die Timer ISR vorhersehbare Verarbeitungszeit 
besitzt und nebenbei z.B. auch noch Taster abfragen kann, halte ich das 
für keinen grossen Preis für eine zuverlässige Encoderabfrage.

Und ja, ich habe die Dinger früher auch immer per Flanken-Interrupt 
abgefragt. Das geht bei neuen Drehgebern auch sehr fein (vor allem, wenn 
sie nicht auf der Flanke rasten), baut allerdings mit zunehmendem Alter 
des Gebers ab.

von spontan (Gast)


Lesenswert?

Manuel Kampert schrieb:

>            int i=0;
>            i++;

Hab ich weiter oben gefunden, nuicht nur einmal, sondern 4x. Was willst 
Du damit erreichen?

von m.n. (Gast)


Lesenswert?

Matthias Sch. schrieb:
> Wer das in einem flankengetriggerten Interrupt macht, muss da richtig
> Zeit für aufwenden.

Nein; siehe Code von W.S. weiter oben.
Mit einem RC-Glied am hysterisierten Eingang wird sichergestellt, dass 
der nächste Flankenwechsel erst kommen kann, wenn der vorherige 
verarbeitet wurde. Rechenzeit wird nur proportional zur Frequenz 
verbraucht, egal, ob 10Hz oder 20kHz. In Ruhestellung wird garkeine Zeit 
benötigt.

In einem Jahr kann man somit 3h19m04,6472s an Rechenzeit sparen!

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

m.n. schrieb:
> Mit einem RC-Glied am hysterisierten Eingang wird sichergestellt, dass
> der nächste Flankenwechsel erst kommen kann, wenn der vorherige
> verarbeitet wurde. Rechenzeit wird nur proportional zur Frequenz
> verbraucht, egal, ob 10Hz oder 20kHz. In Ruhestellung wird garkeine Zeit
> benötigt.

Wenn mein 4 Jahre alter Golf mal das Zeitliche gesegnet hat, werde ich 
nachschauen, ob die auch so eine Sch... verbaut haben. Jedenfalls macht 
der Drehgeber für die Innenraumtemperatur seit ein paar Wochen alles 
Mögliche, wenn ich daran drehe - egal welche Richtung.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

m.n. schrieb:
> Mit einem RC-Glied am hysterisierten Eingang wird sichergestellt, dass
> der nächste Flankenwechsel erst kommen kann, wenn der vorherige
> verarbeitet wurde.

Genau das isses doch. Ein prellender Drehgeber erzeugt eben nicht nur 
eine Nutzflanke, sondern auch noch einen Haufen unnützer Flanken. Wer 
bestimmt denn, wann die Flanke verarbeitungsfähig ist?
Ich habe schon sehr viel mit Drehgebern aller Coleur gemacht, und es 
gibt solche, die mit Flanken-ISR gut funktionieren, es gibt aber auch 
solche, wo du entweder riesige RC Glieder einfügen müsstest, oder viele 
ms in der ISR vertrödelst.
Klar, wenn man nur einen (guten) Drehgeber hat und auch immer dieser 
verwendet wird, kannst du das anpassen, mir ist es aber lieber, wenn ich 
per #define die 'Qualität' des Drehgebers so anpassen kann, das es mit 
allen geht, die mir unterkommen. Das reicht dann von schrottigen alten 
Autoradios bis zu industriellen Qualitätsgebern der 300 Euro Klasse.

Frank M. schrieb:
> Jedenfalls macht
> der Drehgeber für die Innenraumtemperatur seit ein paar Wochen alles
> Mögliche, wenn ich daran drehe - egal welche Richtung

Nach 4 Jahren finde ich das unmöglich, vor allem in so einem teuren 
Auto...

: Bearbeitet durch User
von m.n. (Gast)


Lesenswert?

Laß mich raten: den hast Du Dir gekauft, nachdem Du einen ADAC-Test 
gelesen hast. Weiterhin ist dort wohl noch ein AVR verbaut; mit einem 
STM32 gäbe es keine Fehlfunktion :-)

Es gibt viele Möglichkeiten, Fehler zu machen. Auswertungen per 
Interrupt zu erledigen, gehört nicht zwingend dazu.

von Manuel K. (manuel1139)


Lesenswert?

das mit dem #

int i;
i++

hab ich nur gemacht das ich hier einen Breakpoint setzen kann :-) Gibt's 
da ne andere Möglichkeit? breakpoint; oder sowas?

von m.n. (Gast)


Lesenswert?

Matthias Sch. schrieb:
> Genau das isses doch. Ein prellender Drehgeber erzeugt eben nicht nur
> eine Nutzflanke, sondern auch noch einen Haufen unnützer Flanken. Wer
> bestimmt denn, wann die Flanke verarbeitungsfähig ist?

Jede Flanke muß verarbeitet werden! Das RC-Glied muß nur soweit 
verzögern, bis der vorherige Interrupt abgearbeitet ist. Wenn es dann 
5ms lang Prellen sollte, wird eben ein paar mal +1 und -1 ausgewertet.

Mich stören bei diesem Thema immer die Schreihälse, die ohne jemals 
differenziert nachgedacht zu haben lospoltern: "Das darf man nicht!"

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

m.n. schrieb:
> Mich stören bei diesem Thema immer die Schreihälse, die ohne jemals
> differenziert nachgedacht zu haben lospoltern: "Das darf man nicht!"

Jo, die stören auch mich. Wie oben erwähnt, habe ich eben alles mögliche 
ausprobiert, ohne Vorurteile und auf einigen verschiedenen Platformen. 
(AVR, Freescale, STM32, MCS51 usw.)

m.n. schrieb:
> Das RC-Glied muß nur soweit
> verzögern, bis der vorherige Interrupt abgearbeitet ist. Wenn es dann
> 5ms lang Prellen sollte, wird eben ein paar mal +1 und -1 ausgewertet.

Aber damit ziehst du dir wieder die Unwägbarkeiten der verschiedenen 
Geber ein und musst das RC Glied entsprechend sorgfältig dimensionieren. 
Ich stimme dem aber zu, das externe Bedienelemente, die direkt auf 
Portpins eines MC gehen, ESD Problematik besitzen und man deswegen 
sowieso etwas Hardware einsetzen muss, um Transienten usw. vom MC 
fernzuhalten.
Aber während die Timer ISR vorhersehbar immer die gleiche Zeit in 
regelmässigen Intervallen zubringt, ist eine ISR, die auf jede Flanke 
eines prellenden Drehgebers reagiert, evtl. ein Grund für Seiteneffekte 
im Programm, auf die ich gerne verzichte, vor allem, wenn nebenbei noch 
irgendwelche zeitkritischen Routinen arbeiten.
Meine Timer ISR fragt Drehgeber und Taster ab, erledigt die Echtzeituhr 
und ist ansonsten unauffällig. Wenn dann noch die elegante 'Taster lang' 
und 'Taster kurz' Routine mit Repeat Funktion dazukommt, ist die gesamte 
Benutzereingabe in der einen Routine abgefrühstückt.

von m.n. (Gast)


Lesenswert?

Matthias Sch. schrieb:
> Aber damit ziehst du dir wieder die Unwägbarkeiten der verschiedenen
> Geber ein und musst das RC Glied entsprechend sorgfältig dimensionieren.

Anders herum, die Zeitkonstante muß zum µC passen. Wenn dieser in der 
Lage ist, z.B. alle 50µs eine neue Flanke zu verarbeiten, reicht eine 
entsprechend kurze Zeitkonstante aus.

Aber ansonsten stimme ich Dir zu, so wie Du es machst. Bei manueller 
Betätigung von Drehgebern mit niedriger Auflösung kann man gemächlich 
pollen.
Anders sieht es aus, wenn nichtrastende optische Drehgeber verwendet 
werden, die keine stabile Flanke im Ruhezustand ausgeben. Da wird man 
sich schwer überlegen, ob man per Interrupt auswertet oder im 
kHz-Bereich pollt.

Optische Drehgeber bieten sich z.B. an, um die Drehung dynamisch 
auszuwerten: Frequenzabstimmung an einem Funktionsgenerator oder hoch 
aufgelöster, horizontaler Kurvenverschiebung bei einem Megabyte Oszi, 
was die Hersteller aus Billigheim noch nicht begriffen haben.
Das nervt mich mehr, als die Temperatureinstellung im Auto.

von MaWin (Gast)


Lesenswert?

Gestern müssen die Irrenhäuser zum Ausgangstag aufgerufen haben, so 
viele Noobs wie hier das eigentlich geklärte Thema 
Inkrementalödecoderabfrage mit ihrem himmelschreienden Unwissen über die 
Probleme der flankengesteuerten Abfrage verseuchen.

von Manuel K. (manuel1139)


Lesenswert?

Leider habe ich keine Ahnung warum hier jetzt so viele gerade diese 
Thema benutzen um sich hier so anzugreifen...

Ich denke es führen viele Wege nach Rom.

Ich habe meinen Fehler auf jeden fall - auch mit eurer Hilfe - gefunden. 
Ursache war das schöne bunte lange Flachbandkabel. Auf 5cm gekürzt läuft 
alles so wie ich mir das gedacht habe :-)

Vielen Dank!
  Manuel

von spontan (Gast)


Lesenswert?

>Ich habe meinen Fehler auf jeden fall - auch mit eurer Hilfe - gefunden.
>Ursache war das schöne bunte lange Flachbandkabel. Auf 5cm gekürzt läuft
>alles so wie ich mir das gedacht habe :-)

Stell doch mal ein Foto Deines Aufbaus rein. Obige Aussage glaub ich 
einfach nicht. Nicht bei Signalen unter 50 MHz.

von Thomas E. (thomase)


Lesenswert?

Manuel Kampert schrieb:
> Leider habe ich keine Ahnung warum hier jetzt so viele gerade diese
> Thema benutzen um sich hier so anzugreifen...
>
> Ich denke es führen viele Wege nach Rom.
>
> Ich habe meinen Fehler auf jeden fall - auch mit eurer Hilfe - gefunden.
> Ursache war das schöne bunte lange Flachbandkabel. Auf 5cm gekürzt läuft
> alles so wie ich mir das gedacht habe :-)

Wie lang war das denn vorher? Ich glaube, du hast eher die Symptome 
kuriert.

mfg.

von Falk B. (falk)


Lesenswert?

@ spontan (Gast)

>>Ich habe meinen Fehler auf jeden fall - auch mit eurer Hilfe - gefunden.
>>Ursache war das schöne bunte lange Flachbandkabel. Auf 5cm gekürzt läuft
>>alles so wie ich mir das gedacht habe :-)

>Stell doch mal ein Foto Deines Aufbaus rein. Obige Aussage glaub ich
>einfach nicht. Nicht bei Signalen unter 50 MHz.

Das hat mit 50 MHz direkt nicht zu tin, wohl aber was mit 
Anstiegszeiten. Siehe Wellenwiderstand. Wobei hier eher kein 
Laufzeiteffekt ne Rolle spielt sondern eher ein kapazitives 
Übersprechen. Allerdings kann ich mir bei einem DREHGEBER das nicht so 
recht vorstellen, es sei denn, auf der Nachbarader läuft ein aktives 
Signal.

von Harald W. (wilhelms)


Lesenswert?

Falk Brunner schrieb:

> Übersprechen. Allerdings kann ich mir bei einem DREHGEBER das nicht so
> recht vorstellen,

Zumindest nicht, wenn man eine vernünftige Schaltung ohne
Interrupt verwendet. :-)
Gerade Drehgeber werden ja oft über lange Kabel angeschlossen.
Gruss
Harald

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Harald Wilhelms schrieb:
> Zumindest nicht, wenn man eine vernünftige Schaltung ohne
> Interrupt verwendet. :-)

Aaargh, nicht schon wieder :-P
Lange Leitungen zu Tastern und so sind aber schon empfindlich, wenn man 
sich nur auf die eingebauten Pullups z.B. der AVR verlässt. Die sind mit 
ihren 30k-80k doch schon recht hochohmig und machen die Zuleitungen 
unnötig empfindlich. Kräftigere externe Pullups mit 1k-5k6 sollten das 
Problem dann beheben.

von m.n. (Gast)


Lesenswert?

Da muß mit der Auswertung grundsätzlich etwas nicht in Ordnung sein. 
Selbst die schwachen Pullup-Widerstände könnten nur für gelegentliche 
Störungen verantwortlich sein, aber nicht bei einigen Zentimetern 
Leitungslänge.

spontan schrieb:
> Stell doch mal ein Foto Deines Aufbaus rein.

Dem stimme ich spontan zu!

von Gerd H. (anatec)


Angehängte Dateien:

Lesenswert?

Auch wenns warscheinlich schon wieder zum alten Eisen gehört, ich habe 
mir gerade so eine Encoderauswertung mit Parsic entwickelt. Das Ding 
funktioniert tadellos und kommt ohne Interrupt aus. Da Parsic ASM Code 
für PIC's schreibt und das wohl weniger interessiert könnte aber das 
Prinzip von Interesse sein. Das Konzept verbraucht "für sich" etwas über 
1ms und wenn der PIC dadurch unnötig langsam wird, sollte der Code mit 
Bedacht in den Gesamtablauf eingebaut werden. Die Monoflop MF2 ist nur 
zum Test drin, da eine LED mit 1 Shot nicht reagieren würde. RS1 liefert 
je nach Drehrichtung H oder L.
Bei mir bedient diese Schaltung einen Aufwärts- Abwärtszähler den ich 
zur Steuerung einer China DDS mit AD9850 benötige.

von MaWin (Gast)


Lesenswert?

Gerd H. schrieb:
> Das Ding funktioniert tadellos

Nein, natürlich nicht, nur das siehst du in deinem Simulator mit idealen 
Eingangssignalen nicht. Warum muss man es mit aller Gewalt prinzipiell 
falsch machen und sich dann schönreden ? Die einfachere korrekte 
Schaltung ist nicht patentiert, die darf man benutzen.

        +---+
 A -----|D Q|---+
      +-|T  | +-(---------- Clock
      | +---+ | |   +---+
      +-------+ +---|   |
      | +---+   |   |XOR|-- Forward Direction
 B ---(-|D Q|-+ | +-|   |
      +-|T  | | | | +---+
      | +---+ | | |
  +---(-------+ | | +---+
  | +-(-------(-+-(-|   |
  | | | +---+ |   | |XOR|-+ +---+
  | +-(-|D Q|-(---(-|   | +-|   |
  |   +-|T  | |   | +---+   |XOR|-- Clock Enable
  |   | +---+ |   | +---+ +-|   |
  |   |       +---(-|   | | +---+
  |   | +---+     | |XOR|-+
  +---(-|D Q|-----+-|   |
  +---+-|T  |       +---+
  |     +---+
+---+
|555|
+---+

von Gerd H. (anatec)


Angehängte Dateien:

Lesenswert?

@MaWin
Aus voller Überzeugung .... nein, das Ding kann nicht funktionieren. 
Denkst du, ich glaube rein weg einem Simmulator? Wenn ich einen kleinen 
Beitrag veröffentliche, habe ich das vorher auch praktisch ausprobiert 
und auf Herz und Nieren getestet. Es führen viele Wege nach Rom und so 
falsch kann sie nicht sein, da ich 1. ne vollkommen logische Begründung 
für die Funktion habe und 2. das Ding auch praktisch funktioniert, mit 
zugegeben auch "schlechten" Exemplaren von P. Ich habe von den Dingern 
noch nen Sack voll und deren Eigenarten genau untersucht. gelle

Nachtrag: Die LED auf dem Bild leuchten natürlich nicht, is ja kein 
Strom drann, auch wenns so aussieht

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

Gerd H. schrieb:
> Denkst du

Ja, ich denke.

Du spielst hier denjenigen, der mit dem Perpetuum Mobile zum Patentamt 
will, und sich wundert, warum er ausgelacht wird.

von Gerd H. (anatec)


Lesenswert?

kopschüttel, was soll das ......
Solche Anmache und Überheblichkeit ist mir in noch keinem Board 
untergekommen. Kein Mensch hat etwas von Patent geschrieben. Ich dachte 
hier geht es um Elektronik, aber das Zwischenmenschlische scheint 
viiiiiel wichtiger.

Jetzt habe ich die anderen Beiträge von  MaWin gelesen, könnte glatt der 
"golden nugget" aus dem Progforum sein,;-)

: Bearbeitet durch User
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Die Panasonic Drehgeber sind recht gut und prellen von vorneherein recht 
wenig, vor allem wenn sie neu sind.
Mit zunehmender Lebensdauer allerdings bildet sich (vermutlich 
Silber-)Oxid auf den Kontakten und dann prellts ein wenig mehr, so das 
du evtl. die Zeitkonstante des (1ms) MMV anpassen müsstest.

von Gerd H. (anatec)


Lesenswert?

Hallo Matthias,
Du hast Recht, die Dinger sind sind gut. Einziges Manko, wenn das Fett 
im Inneren "ranzig" wird, wird der Verstellvorgang links / rechts träge.
Die 1 ms muss man bei Parsic nicht so dogmatisch sehen. Steht zwar am 
Modul, ist aber auch vom kompletten Programmdurchlauf abhängig. Man 
könnte zwar den tatsächlichen Wert errechnen, aber dann auch pratisch 
testen ist besser. In den Hilfen von Parsic steht die Formel, wie sich 
der Wert zusammensetzt. Die Wenigsten hier im Board werden das Prog noch 
benutzen und so gehe ich da nicht weiter drauf ein. Lassen wir die 1ms 
stehen oder entsprechend deiner Anmerkung eine längere Verzögerung.

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
Noch kein Account? Hier anmelden.