Forum: Mikrocontroller und Digitale Elektronik Drehimpulsgeber Rastung Bascom, welcher ist der richtige Typ?


von Dreher (Gast)


Lesenswert?

Hallo,

es wird in diversen Quellen beschrieben, das manche Drehimpulsgeber 
Probleme bereiten, da sie wohl mehrere Impulse pro Schritt erzeugen.
Anscheinend kann die in Bascom implementiere Funktion damit nicht 
umgehen.

Bei Reichelt finde ich Typen welche bei gleicher Rastung gleich viele 
Impulse erzeugen, oder solche welche bei 2 Rastungen ( Schritte) einen 
Impuls erzeugen.
Ist nun einer davon problematisch, oder sind die problematischen Typen 
ganz andere?

Bitte keinen Bascom shitstorm, sondern nur seriöse Antworten;-).
?
Danke

von Falk B. (falk)


Lesenswert?

@ Dreher (Gast)

>Anscheinend kann die in Bascom implementiere Funktion damit nicht
>umgehen.

Doch, man muss dann halt immer nur die Hälfte oder 1/4 der Zählvariable 
nutzen.

von Amateur (Gast)


Lesenswert?

Wenn Du die Richtung nicht brauchst, so nutze nur einen Ausgang.
Interessant wird es doch erst, wenn Du auf beide Ausgänge schaust.

von Dreher (Gast)


Lesenswert?

Falk Brunner schrieb:
> @ Dreher (Gast)
>
>>Anscheinend kann die in Bascom implementiere Funktion damit nicht
>>umgehen.
>
> Doch, man muss dann halt immer nur die Hälfte oder 1/4 der Zählvariable
> nutzen.

Also zählt Bascom dann für einen Schritt 2 oder gar 4 Impulse?
Somit löst eine einfache Division durch 2 oder 4 das "Problem"?

von Falk B. (falk)


Lesenswert?

Ja. Eine Schiebeoperation ist aber schneller als eine Division.

Sinngemäß so. Der encoder Befehl muss schnell genug in einem Timer 
aufgerufen werden.

Dim B As Byte
Dim Pos As Byte
Dim Pos_real As Byte

B = Encoder(pinb.0 , Pinb.1 , Links , Rechts , 0)
Pos_real = Pos
shift Pos_real, rigth, 2

Links:
pos = pos + 1
return

Rechts:
pos = pos - 1
return

von Thomas E. (thomase)


Lesenswert?


von Amateur (Gast)


Lesenswert?

Ich habe noch nie von Problemen mit mehr Schritten gehört.

Dann ist die Auflösung halt höher. Viele würden sagen: Toll!

Die heutigen Mikrokontroller haben mit der höheren Frequenz keine 
Probleme.

Da die Umdrehungsreferenz sowieso abstrakt ist, sollte die Änderung von 
"Umdrehung=1000" in "Umdrehung=2000" kein unüberwindliches Problem sein.

von Dreher (Gast)


Lesenswert?

Falk Brunner schrieb:
> Ja. Eine Schiebeoperation ist aber schneller als eine Division.

Perfektionist ;-)

>
> Sinngemäß so. Der encoder Befehl muss schnell genug in einem Timer
> aufgerufen werden.

20 ms 50 ms, was empfiehltst Du?

>
> Dim B As Byte
> Dim Pos As Byte
> Dim Pos_real As Byte
>
> B = Encoder(pinb.0 , Pinb.1 , Links , Rechts , 0)
> Pos_real = Pos
> shift Pos_real, rigth, 2
>
> Links:
> pos = pos + 1
> return
>
> Rechts:
> pos = pos - 1
> return

von Falk B. (falk)


Lesenswert?

Naja, so im Bereich 1-10ms.

von Max M. (jens2001)


Lesenswert?

Dreher schrieb:
> Falk Brunner schrieb:
>> Ja. Eine Schiebeoperation ist aber schneller als eine Division.
>
> Perfektionist ;-)
>
>>
>> Sinngemäß so. Der encoder Befehl muss schnell genug in einem Timer
>> aufgerufen werden.
>
> 20 ms 50 ms, was empfiehltst Du?
>
>>
>> Dim B As Byte
>> Dim Pos As Byte
>> Dim Pos_real As Byte
>>
>> B = Encoder(pinb.0 , Pinb.1 , Links , Rechts , 0)
>> Pos_real = Pos
>> shift Pos_real, rigth, 2
>>
>> Links:
>> pos = pos + 1
>> return
>>
>> Rechts:
>> pos = pos - 1
>> return

1. Einen Encoder liest man nicht über einen Timer ein sondern über einen 
PinChangeInterupt!

2. Einen Gray-Code wertet man nicht über komplizierte if/else Konstrukte 
aus sondern über ein simples Array mit 16 Einträgen für alle möglichen 
gültigen u. ungültigen Bitkombinationen für alten u. neuen Zustand.

3. Man macht sich das Leben leichter wenn man den Encoderanschlüssen ein 
R/C-Glied zur Entprellung verpasst.

von Dreher (Gast)


Lesenswert?

Max Mustermann schrieb:
> Dreher schrieb:
>> Falk Brunner schrieb:
>>> Ja. Eine Schiebeoperation ist aber schneller als eine Division.
>>
>> Perfektionist ;-)
>>
>>>
>>> Sinngemäß so. Der encoder Befehl muss schnell genug in einem Timer
>>> aufgerufen werden.
>>
>> 20 ms 50 ms, was empfiehltst Du?
>>
>>>
>>> Dim B As Byte
>>> Dim Pos As Byte
>>> Dim Pos_real As Byte
>>>
>>> B = Encoder(pinb.0 , Pinb.1 , Links , Rechts , 0)
>>> Pos_real = Pos
>>> shift Pos_real, rigth, 2
>>>
>>> Links:
>>> pos = pos + 1
>>> return
>>>
>>> Rechts:
>>> pos = pos - 1
>>> return
>
> 1. Einen Encoder liest man nicht über einen Timer ein sondern über einen
> PinChangeInterupt!
>
> 2. Einen Gray-Code wertet man nicht über komplizierte if/else Konstrukte
> aus sondern über ein simples Array mit 16 Einträgen für alle möglichen
> gültigen u. ungültigen Bitkombinationen für alten u. neuen Zustand.
>
> 3. Man macht sich das Leben leichter wenn man den Encoderanschlüssen ein
> R/C-Glied zur Entprellung verpasst.

Wie wäre es mit ein paar Zeilen Pseudocode?
Bei der Methode der Auswertung scheint es zwei Lager zu geben.
Interrupt vs. Timer.
" Wer heilt hat Recht", aber was ist nun die "bessere Methode"?

Tendenziell wird die Timer Methode wohl besser mit dem Tastenprellen 
klarkommen, außer sie tastet gerade während des Prellens ab.....

von Max M. (jens2001)


Angehängte Dateien:

Lesenswert?

Dreher schrieb:
> Max Mustermann schrieb:
>> 1. Einen Encoder liest man nicht über einen Timer ein sondern über einen
>> PinChangeInterupt!
>>
>> 2. Einen Gray-Code wertet man nicht über komplizierte if/else Konstrukte
>> aus sondern über ein simples Array mit 16 Einträgen für alle möglichen
>> gültigen u. ungültigen Bitkombinationen für alten u. neuen Zustand.
>>
>> 3. Man macht sich das Leben leichter wenn man den Encoderanschlüssen ein
>> R/C-Glied zur Entprellung verpasst.
>
> Wie wäre es mit ein paar Zeilen Pseudocode?
> Bei der Methode der Auswertung scheint es zwei Lager zu geben.
> Interrupt vs. Timer.
> " Wer heilt hat Recht", aber was ist nun die "bessere Methode"?
>
> Tendenziell wird die Timer Methode wohl besser mit dem Tastenprellen
> klarkommen, außer sie tastet gerade während des Prellens ab.....

Hab hier was ausgeschnitten aus einem Prog. für Arduino.
War ein längeres Prog. Hoffe ich hab genug aber nicht zuviel 
weggeschnitten.

Die ISR für den PCI wertet den Enc. aus und setzt je nach Drehrichtung 
den Wert "EncClicks" auf +1/-1

In der Loop wird in der Funktion "SetSollTemperatur"  EncClicks zu 
SollTemperatur addiert und so die Solltemperatur zwischen 80 und 200 
Grad eingestellt.

Die Encoderanschlüsse (und alle Eingabetasten) sind mit einem R/C-Glied 
entprellt so das ich mich im Programm darum nicht kümmern muss.

von Falk B. (falk)


Lesenswert?

@ Max Mustermann (jens2001)

>1. Einen Encoder liest man nicht über einen Timer ein sondern über einen
>PinChangeInterupt!

Jaja, ist schon gut. Lies mal was zum Thema Drehgeber.

>2. Einen Gray-Code wertet man nicht über komplizierte if/else Konstrukte
>aus

Wo siehst du die?

>3. Man macht sich das Leben leichter wenn man den Encoderanschlüssen ein
>R/C-Glied zur Entprellung verpasst.

Kann man machen, ist bei einer gescheiten Auswertung aber nicht nötig, 
da steckt die Entprellung in der Software.

von Wolfgang (Gast)


Lesenswert?

Falk Brunner schrieb:
> Kann man machen, ist bei einer gescheiten Auswertung aber nicht nötig,
> da steckt die Entprellung in der Software.

Lass den Encoder doch prellen. Der Gray-Code stellt sicher, dass das 
keinen störenden Einfluss auf das Zählergebnis hat. Ob die Software sich 
mit Entprellung oder Hoch-/Runterzählen beschäftigt, ist doch schnuppe, 
insbesondere wenn man den Encoder per Timer abfragt.

von Max M. (jens2001)


Lesenswert?

Falk Brunner schrieb:
> @ Max Mustermann (jens2001)
>
>>1. Einen Encoder liest man nicht über einen Timer ein sondern über einen
>>PinChangeInterupt!
>
> Jaja, ist schon gut. Lies mal was zum Thema Drehgeber.

Also mein Atmega hat was besseres zu tun als ständig die Encodereingänge 
zu pollen. Vor allem weil das nur rel. selten vorkommt das sich was am 
Encoder tut. Die meiste zeit des Tages ist die Maschiene mit wichtigeren 
Sachen beschäftigt. Und bei einem schnell gedrehtem Encoder können die 
Impulse schon mal im 2-3ms Intervall kommen. Da fällst du mit 10ms 
Abtastzeit gehörig auf die Nase.

>
>>2. Einen Gray-Code wertet man nicht über komplizierte if/else Konstrukte
>>aus
>
> Wo siehst du die?

Die seh ich nirgens. Ich seh überhaupt keinen Code der die Drehrichtung 
auswertet und verlorene/falsche Impulse erkennt.

>
>>3. Man macht sich das Leben leichter wenn man den Encoderanschlüssen ein
>>R/C-Glied zur Entprellung verpasst.
>
> Kann man machen, ist bei einer gescheiten Auswertung aber nicht nötig,
> da steckt die Entprellung in der Software.

Siehe zu 1.



Aber Deutschland ist zum Glück einfreies Land.
Jeder darf sich seinen Code selbst verhunzen.

von Max M. (jens2001)


Lesenswert?

Wolfgang schrieb:
> Falk Brunner schrieb:
>> Kann man machen, ist bei einer gescheiten Auswertung aber nicht nötig,
>> da steckt die Entprellung in der Software.
>
> Lass den Encoder doch prellen. Der Gray-Code stellt sicher, dass das
> keinen störenden Einfluss auf das Zählergebnis hat. Ob die Software sich
> mit Entprellung oder Hoch-/Runterzählen beschäftigt, ist doch schnuppe,
> insbesondere wenn man den Encoder per Timer abfragt.

Zwei nicht entprellte Encodersignale bei dem die Impulse im 2-3ms 
Interval aufschlage abgetastet mit 10ms?

Was haben die Leute von AVR sich blos dabei gedacht als sie die 
externen- und die Pinchange-Interrupts implementiert haben?

von Falk B. (falk)


Lesenswert?

Und wieder ein Schlaumeier, der uns die Welt erklärt. Das mit dem 
sinnerfassenden Lesen müssen wir wohl noch ein wenig üben.

>> Dreher (Gast)

>>> Sinngemäß so. Der encoder Befehl muss schnell genug in einem Timer
>>> aufgerufen werden.

>>20 ms 50 ms, was empfiehltst Du?

> Falk Brunner (falk)
> Naja, so im Bereich 1-10ms.

von Wolfgang (Gast)


Lesenswert?

Max Mustermann schrieb:
> Zwei nicht entprellte Encodersignale bei dem die Impulse im 2-3ms
> Interval aufschlage abgetastet mit 10ms?

Du vergisst, dass die Signalflanken 90° phasenverschoben sind. Wenn die 
Prellzeit der Encoder länger ist, als der Impulsabstand, wird dir 
jegliche Dekodierlogik um die Ohren fliegen - auch eine mit 
Flankeninterrupt.

Natürlich muss die Abtastrate so gewählt werden, dass bei maximaler 
Drehgeschwindigkeit deutlich mehr als 1/4 Abtastung pro Encoderzustand 
statt findet ;-)

von Max M. (jens2001)


Lesenswert?

Wolfgang schrieb:
> Du vergisst, dass die Signalflanken 90° phasenverschoben sind. Wenn die
> Prellzeit der Encoder länger ist, als der Impulsabstand, wird dir
> jegliche Dekodierlogik um die Ohren fliegen - auch eine mit
> Flankeninterrupt.

Nein das hab ich nicht vergessen!!!
Hab das getestet mit einem Encoder mit 20Rastungen u. 4 Zustandswechsel 
pro Rastung. Das ergiebt 80 Zustandswechsel pro Umdrehung! Mit der 6mm 
Achse zwischen zwei Fingern kann man mit wildem drehen auf Intervalle 
unter 3ms kommen. Das hat mein Atmega@16Mhz ohne verschlucken 
weggesteckt.
Im Normalbetrieb steckt auf der Welle ein 12mm Drehknopf und  so wild 
wird auch nicht gedreht.

von Bascom User (Gast)


Lesenswert?

Gibt es eine Möglichkeit ohne Benutzung eines Timers für eine 
Auswertung?
Ein Codeschnipsel wäre hilfreich

von Falk B. (falk)


Lesenswert?

@Bascom User (Gast)

>Gibt es eine Möglichkeit ohne Benutzung eines Timers für eine
>Auswertung?

Warum? Hast du eine Timer-Allergie?

Ach ja, BASCOM-"Programmierer" . . .

von Bascom User (Gast)


Lesenswert?

Angenommen sind die vorhandene Timer bereits "belegt".?
Z.B. Eine Uhr tickt
Werden 3 PWM Kanäle verwendet , in solchen Fällen was tun ?
(verfügbare Timer sind bereits belegt )

von Wolfgang (Gast)


Lesenswert?

Bascom User schrieb:
> Angenommen sind die vorhandene Timer bereits "belegt".?
> Z.B. Eine Uhr tickt

Dann hast du da doch schon einen Ticker laufen, den du per Dual-Use 
einsetzen kannst.

Max Mustermann schrieb:
> Das hat mein Atmega@16Mhz ohne verschlucken weggesteckt.
Dann wird er auch einen Timer-IRQ mit diese (offensichtlich 
ausreichenden) Rate wegstecken.

von Karl H. (kbuchegg)


Lesenswert?

Bascom User schrieb:
> Angenommen sind die vorhandene Timer bereits "belegt".?
> Z.B. Eine Uhr tickt
> Werden 3 PWM Kanäle verwendet , in solchen Fällen was tun ?
> (verfügbare Timer sind bereits belegt )


Man kann einen Timer durchaus auch für mehr als nur 1 Sache benutzen. 
Das ist nicht in Stein gemeisselt, dass in einer Timerroutine nur 1 
Sache passieren darf. Zb. die Millisekunden für eine Uhr weiterzählen. 
Wenn die Uhren-Timer-Routine sowieso jede Millisekunde aufgerufe wird, 
dann wäre das zb der perfekte Ort um dort auch noch Tasten-Entprellung 
oder aber Encoder-Auswertung zu machen. Zumal es weder bei 
Tasten-Entprellung noch bei der Encoder-Auswertung wichtig ist, dass das 
genau 1 Millisekunde ist. Wenn du also eine PWM hast, die am Timer eine 
Zykluszeit von ca. 1 Millisekunde oder weniger ergibt, dann passt das 
schon. Wenn es zu kurz ist, dann kann man immer noch mit einem Zähler 
die Aktion dann eben nur bei jedem 2.ten oder 3.ten oder n.ten Aufruf 
machen.

von Thomas E. (thomase)


Lesenswert?

Bascom User schrieb:
> Angenommen sind die vorhandene Timer bereits "belegt".?
> Z.B. Eine Uhr tickt
> Werden 3 PWM Kanäle verwendet , in solchen Fällen was tun ?
> (verfügbare Timer sind bereits belegt )
Und?

Auf Timer2 läuft im Asynchronmodus eine Uhr. Der ist für nichts anderes 
mehr zu gebrauchen.
Timer0 und Timer1 machen jeweils zwei PWM-Kanäle.

Jeder dieser beiden PWM-Timer löst einen Overflow-Interrupt aus. Damit 
wird das Polling getriggert. Läuft Timer0 ungebremst kommt der Interrupt 
bei 16MHz 62500x in der Sekunde, also 62,5KHz. Fürs Dimmen einer LED 
reicht aber auch viel weniger.
In der ISR zählt man per Software eine Variable runter, setzt ein Flag 
und das Hauptprogramm arbeitet das Polling ab und liest den/die 
Drehgeber und Taster ein. Läuft der Timer langsamer kann man das auch 
gleich in der ISR erledigen.

mfg.

von Bascom User (Gast)


Lesenswert?

Dual Use.....spannend
Wie sieht es mit einem Beispielcode aus ?
Angenommen die Uhrzeit soll über Drehgeber
eingestellt werden..

von Karl H. (kbuchegg)


Lesenswert?

Bascom User schrieb:
> Dual Use.....spannend

was ist da spannend daran.

Du hast dir einen Timer konfiguriert, der in regelmässigen Abständen 
deine ISR-Funktion aufruft. In dieser ISR machst du dein Ding, zb. eine 
Software Uhr hochzählen. UNd dann kommt eben der zusätzliche Code auch 
noch mit dazu, wobei man sinnigerweise in der ISR nur den Drehgeber 
insofern auswertet, dass man seine Bewegung registriert. Was diese 
Drehung dann bewirkt, wird man eher im Hauptprogramm machen.

> Wie sieht es mit einem Beispielcode aus ?
> Angenommen die Uhrzeit soll über Drehgeber
> eingestellt werden..

Hier
http://rn-wissen.de/wiki/index.php/Drehencoder#Bascom_ENCODER-Befehl_mit_Anpassung
sollte auch für dich was dabei sein, mit dem du klar kommst.

: Bearbeitet durch User
von Amateur (Gast)


Lesenswert?

Zur Auswertung gibt es noch die Möglichkeit, die Impulse zu Zählen.

Wenn die Geschwindigkeit unwichtig ist, kommst Du so auch ohne Timer 
aus.

Impulse auf irgendeinen Zählereingang leiten und Zähler in der 
Hauptschleife abfragen/aktualisieren. Ist allerdings schrecklich einfach 
und deshalb wohl ausgeschlossen. Um eventuelle Überläufe (bei 
Motordrehzahlen oberhalb des Maximums) kümmert sich dann eine 
Unterbrechung.

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.