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
@ 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.
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"?
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
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.
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
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.
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.....
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.
@ 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.
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.
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.
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?
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.
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 ;-)
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.
@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" . . .
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 )
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.
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.
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.
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.
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.
