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.
Wenn Du die Richtung nicht brauchst, so nutze nur einen Ausgang. Interessant wird es doch erst, wenn Du auf beide Ausgänge schaust.
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
Und nach Drehgebern guckt du hier: http://stores.ebay.de/Logo-s-Elektronik-Kiste/Encoder-inkremental-/_i.html?_fsub=366805719 mfg.
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.
Gibt es eine Möglichkeit ohne Benutzung eines Timers für eine Auswertung? Ein Codeschnipsel wäre hilfreich
@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.
Dual Use.....spannend Wie sieht es mit einem Beispielcode aus ? Angenommen die Uhrzeit soll über Drehgeber eingestellt werden..
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.