Hallo, ich habe mit Drehimpulsgebern scheinbar noch leichte Verständnisschwierigkeiten. Wenn ich einen Geber 20/20 (20 Impulse/20 Rastungen) habe. In welchem Bereich habe ich dann die 20 Impulse? Sind das dann 20 Impulse pro Rastung? Zuerst dachte ich, dass dann ein Impuls pro Rastung kommt. Aber das ist nicht der Fall. Da kommen massig Impulse. Ich habe den STEC11B13 (http://www.reichelt.de/STEC11B13/3/index.html?&ACTION=3&LA=446&ARTICLE=73916&artnr=STEC11B13&SEARCH=stec11b13#av_tabtech) von Reichelt. Irgendwie spinnt der ganz schön rum, mal 20 Impulse hoch, 5 runter, obwohl ich hoch drehe.
Klaus W. schrieb: > In welchem Bereich habe ich dann die 20 Impulse? Sind das dann > 20 Impulse pro Rastung? Nein, 20 Impulse pro Umdrehung und 20 Rastungen pro Umdrehung, d.h. bei jeder Rastung kommt ein Puls. > Irgendwie spinnt der ganz schön rum, mal 20 Impulse hoch, > 5 runter, obwohl ich hoch drehe. Das wird wohl an deiner Auswertung liegen.
Klaus W. schrieb: > Irgendwie spinnt der ganz schön rum, mal 20 Impulse hoch, > 5 runter, obwohl ich hoch drehe. Die Kontakte des Encoders prellen. Externes entprellen mit 2 RC Gliedern hilft.
Beide Terminals mit 10kOhm/100nF RC-Glied entprellen, dann kommen vernünftige Impulse heraus.
Hi Die Routinen von hier zur Entprellung funktionieren problemlos. Und das auch noch in 20 Jahren. MfG Spess
Welchen µC nutzt Du? Falls Du z.B. einen STM32 benutzt, sind Entprellung und 2-bit-Gray-Code-Encoder bereits als Peripherie enthalten.
:
Bearbeitet durch User
> spess53 schrieb: >> Die Routinen von hier zur Entprellung > > Wozu braucht man die? ;-) :-p Na zur Entprellung natürlich! Es gibt nämlich auch andere µC neben dem STM32. Zum Beispiel die ARV's. Und wenn kein Hardware-Interface im µC vorhanden ist, macht man es eben per Software. Das funktioniert tadellos, wie Spess schon schrieb.
Drehimpulsgeber brauchen keine Entprellung, solange die Abtastzeit per Software schneller ist als die Zeit zwischen 2 Pulsen. Wenn es doch Probleme macht, ist der Auswertealgorithmus falsch.
Heizer schrieb: > Drehimpulsgeber brauchen keine Entprellung … und man wertet die Impulse nicht per interrupt aus, das wurde hier auch noch nicht diskutiert. Wartet doch erstmal ab, ob im µC des TO ein Hardware-Interface ^^ vorhanden ist.
Hi >Welchen µC nutzt Du? >Falls Du z.B. einen STM32 benutzt, sind Entprellung und >2-bit-Gray-Code-Encoder bereits als Peripherie enthalten. Haben ATXMega auch. MfG Spess
Ich verwende einen Atmega8. Entprellung habe ich auch schon probiert. Macht keinen Unterschied. Laut Beschreibung des Algorithmus soll dort eine Entprellung bereits integriert sein. Die Drehimpulsgeber sind als "Problemkinder" bekannt. Mit "normalen" Auswertealgorithmen lassen die sich gar nicht auswerten. Da hatte jemand lange dran rum gebastelt, um das hin zu bekommen. War glaube ich sogar hier im Forum, bin ich mir jetzt aber nicht mehr sicher. Die Auswertung erfolgt per Interrupt. Dürfte sich aber auch nicht anders lösen lassen, da das Hauptprogramm viel macht und vermutlich eh zu langsam wäre. Hier mal der Code des Algorithmus:
1 | Shift Zustandswechsel , Left , 2 |
2 | Zustandswechsel.0 = Encoder_a |
3 | Zustandswechsel.1 = Encoder_b |
4 | Zustandswechsel = Zustandswechsel And &B00001111 ' And 15 benötige nur 4 Bit |
5 | If Zustandswechsel = &B00000100 Then ' = 4 erst muss 01 kommen, dann 00 |
6 | Decr Enc_wert : Encoder_richtung = 0 ' Wert abziehen und Richtung setzen |
7 | If Nichtnull = 1 Then ' wenn 0 nicht erlaubt: |
8 | If Enc_wert = 0 Then Enc_wert = Enc_grenze ' wenn Wert=0 dann auf Grenze setzen |
9 | Else |
10 | If Enc_grenze < Enc_wert Then Enc_wert = Enc_grenze ' rechne: 0-1=255 Überlauf! , dann auf Grenze setzen |
11 | End If ' geht auch mit Word statt Byte |
12 | Else |
13 | If Zustandswechsel = &B00001000 Then ' = 8 erst muss 10 kommen, dann 00 |
14 | Incr Enc_wert : Encoder_richtung = 1 ' Wert erhöhen und Richtung setzen |
15 | If Enc_grenze < Enc_wert Then Enc_wert = Nichtnull ' wenn Grenze überschritten, dann auf 0 oder 1 setzen |
16 | End If |
17 | End If |
18 | If Encoder_richtung = 0 Then |
19 | Drehencoder_wert = Drehencoder_wert - 1 |
20 | Else |
21 | Drehencoder_wert = Drehencoder_wert + 1 |
22 | End If |
Klaus W. schrieb: > Ich verwende einen Atmega8. Entprellung habe ich auch schon > probiert. Was für eine Entprellung? Hardware? Software? > Macht keinen Unterschied. Dann funktioniert die Entprellung nicht. > Laut Beschreibung des Algorithmus soll dort > eine Entprellung bereits integriert sein. > Die Drehimpulsgeber sind als "Problemkinder" bekannt. Das sehen 99% anders. > Mit "normalen" > Auswertealgorithmen lassen die sich gar nicht auswerten. Auch das sehen 99% anders. Sie machen es einfach. > Da hatte jemand > lange dran rum gebastelt, um das hin zu bekommen. Glaube ich auch. Wenn man nur "bastelt" und es nicht richtig macht. > War glaube ich sogar > hier im Forum, bin ich mir jetzt aber nicht mehr sicher. Klar war es schon im Forum. Gefühlte 1000mal. Da bin ich mir sicher. > Die Auswertung > erfolgt per Interrupt. Aha, jetzt kommen wir der Sache schon etwas näher. Auch dieser Punkt wurde schon bis zum Erbrechen diskutiert. > Dürfte sich aber auch nicht anders lösen lassen, > da das Hauptprogramm viel macht und vermutlich eh zu langsam wäre. Das wurde mehrfach widerlegt. Unter anderem von Peter Dannegger. Such mal im Forum, das ist voll davon.
Joe F. schrieb: > Die Kontakte des Encoders prellen. > Externes entprellen mit 2 RC Gliedern hilft. Das ist die lange Schreibweise von "Murks". Klaus W. schrieb: > Da hatte jemand lange dran rum gebastelt, um das hin zu bekommen. > Die Auswertung erfolgt per Interrupt. Dürfte sich aber auch nicht anders > lösen lassen, da das Hauptprogramm viel macht und vermutlich eh zu > langsam wäre. Das ist die noch wesentlich längere Schreibweise von "Murks". > Die Drehimpulsgeber sind als "Problemkinder" bekannt. Mit "normalen" > Auswertealgorithmen lassen die sich gar nicht auswerten. Peter kann das. Ich kann das. Und andere. Man muss "Problemkinder" nur richtig analysieren und anpacken... Einmal in VHDL: http://www.lothar-miller.de/s9y/categories/46-Encoder Und einmal mit "Beschleunigung" in C: http://www.lothar-miller.de/s9y/categories/54-Encoder
Klaus W. schrieb: > Zuerst dachte ich, dass dann ein Impuls pro Rastung kommt. So ist es auch. > Irgendwie spinnt der ganz schön rum, mal 20 Impulse hoch, > 5 runter, obwohl ich hoch drehe. Das liegt sicher nicht am Drehgeber. Wie fragst du ihn denn ab ? So macht man es richtig: http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29 http://www.mikrocontroller.net/articles/Drehgeber So macht man es falsch: Joe F. schrieb: > Externes entprellen mit 2 RC Gliedern hilft. Hu Z. schrieb: > Beide Terminals mit 10kOhm/100nF RC-Glied entprellen, dann kommen > vernünftige Impulse heraus. Klaus W. schrieb: > Hier mal der Code des Algorithmus: Irgendwie verstehe ich deinen code nicht. Du wertest 2 Übergänge aus, von 01 nach 00 und von 10 nach 00, das war's, dabei gibt es 8 aktive Zustandswechsel, 4 passive und 4 illegale.
Torsten C. schrieb: > … und man wertet die Impulse nicht per interrupt aus, Doch, dafür gibt es je nach Anwendung praktische oder zwingende Gründe ;-)
m.n. schrieb: >> … und man wertet die Impulse nicht per interrupt aus, > Doch, dafür gibt es je nach Anwendung praktische oder zwingende Gründe Leierleierleierleierleierleierleierleierleierleierleierleierleierleierle ierleierleierleierleierleier... Natürlich wertet man einen Drehgeber im Interrupt(*) aus. Aber eben nicht per Interrupt(**). (*) Timerinterrupt (**) Pinchangeinterrupt
Klaus W. schrieb: > Laut Beschreibung des Algorithmus soll dort > eine Entprellung bereits integriert sein. > Die Drehimpulsgeber sind als "Problemkinder" bekannt. > Mit "normalen" Auswertealgorithmen lassen die sich > gar nicht auswerten. Der Algorithmus zur Auswertung von Drehimpulsgebern ist seit Jahrzehnten bekannt und u.a. in den DSE-FAQ beschrieben. Da keine Flanken sondern Pegel ausgewertet werden, braucht man auch keine Entprellung. Es gibt zwar eine einfache Auswertung über Flanken und D-Flipflops, die sich für "Handdreher" eignet, die funktioniert aber nicht immer sicher. Die "Standardauswertung" dagegen ist keinesfalls ein "Problemkind"; sie erfordert aber Grundkenntnisse über die Verwendung von Logikbausteinen, wenn man keine fertigen Unterprogramme verwenden will.
Lothar M. schrieb: > Natürlich wertet man einen Drehgeber im Interrupt(*) aus. Ja gut, nachdem die ISR durch einen PCINT ausgelöst wurde.
m.n. schrieb: > Ja gut, nachdem die ISR durch einen PCINT ausgelöst wurde. Nachdem die ISR durch einen Timer-Interrupt ausgelöst wurde natürlich.
:
Bearbeitet durch User
m.n. schrieb: > Ja gut, nachdem die ISR durch einen PCINT ausgelöst wurde. Wers so machen will, dass das auch in der EMV-verseuchten Umgebung deterministisch läuft, der nimmt den Timerinterrupt und pollt den Encoder...
Klaus W. schrieb: > Irgendwie spinnt der ganz schön rum, mal 20 Impulse hoch, > 5 runter, obwohl ich hoch drehe Kommt mir bekannt vor, so oder so ähnlich verhält es sich eigentlich allen Anwendungen, wo ich bislang damit konfrontiert wurde, vorzugweise aus dem Arduino Umfeld. ?!? schrieb: > Unter anderem von Peter Dannegger. Such > mal im Forum, das ist voll davon. Die Forumssuche ist Murks. Anstatt 100 Worte zu tippen wäre ein aussagekräftiges Stichwort oder auch ein Link hilfreicher. Über den Namen und mehrere Ecken habe ich letzlich einen Thread von P.D. dazu gefunden, aber erst, nachdem ich wusste, wonach ich suchen musste.
Lothar M. schrieb: > Wers so machen will, dass das auch in der EMV-verseuchten Umgebung > deterministisch läuft, der nimmt den Timerinterrupt und pollt den > Encoder... Wer keine anderen Drehgeber als den o.g. kennt, kann das ja so machen. Nur als allgemeine Lösung taugt das nunmal nichts, da hift kein Prollen.
bianchifan schrieb: > Die Forumssuche ist Murks. > Anstatt 100 Worte zu tippen wäre ein aussagekräftiges Stichwort oder > auch ein Link hilfreicher. Stichwort und Link gabs bereits vor über vier Stunden von MaWin. > Über den Namen und mehrere Ecken habe ich letzlich einen Thread von P.D. > dazu gefunden, aber erst, nachdem ich wusste, wonach ich suchen musste. Für Inkrementalgeber? Wie bereits gesagt, eine Entprellung ist unnötig. Leider wird im INet gerade über Inkrementalgeber sehr viel Unsinn verbreitet.
bianchifan schrieb: > Die Forumssuche ist Murks. Genau das musste ich auch schon feststellen. Da habe ich die Beiträge per Google-Suche besser gefunden. > Anstatt 100 Worte zu tippen wäre ein aussagekräftiges Stichwort oder > auch ein Link hilfreicher. > Über den Namen und mehrere Ecken habe ich letzlich einen Thread von P.D. > dazu gefunden, aber erst, nachdem ich wusste, wonach ich suchen musste. Ich sage zu den sinnlosen Antworten hier lieber nix. Hatte gedacht, hier gibts Fachpersonal. Danke an die sinnvollen Antworten, die anderen ignoriere ich. Behandlung per Interrupt-Auslösung wird sogar im Datenblatt von Hopt&Schuler beschrieben, ist also durchaus nicht so abwegig. Ich werde mir jedenfalls andere Drehgeber zulegen, die von Alps sind Murks, wie auch hier auf der Seite zu lesen ist: https://www.mikrocontroller.net/articles/Drehgeber Leider bin ich bei meiner Suche auf noch mehr von den "Schrott-Dingern" gestoßen. Wer die Raste exakt auf eine Flanke legt, hat das System definitiv nicht verstanden.
Klaus W. schrieb: > Wer die Raste exakt auf eine Flanke legt, hat das System > definitiv nicht verstanden. Das Problem lässt sich oft durch Vertauschen der beiden Ausgänge lösen. Grundsätzlich sind Flankenauswertungen bei Inkrementalgebern Pfusch. Das Pfusch manchmal trotzdem jahrelang funktioniert, sieht man tag- täglich in unserer realen Welt... :-)
Harald W. schrieb: > Grundsätzlich sind Flankenauswertungen bei Inkrementalgebern Pfusch. > Das Pfusch manchmal trotzdem jahrelang funktioniert, sieht man tag- > täglich in unserer realen Welt... :-) ...und leider wird dieser Pfusch von vielen Anfängern nachgemacht ("Steht ja im Internet, also muß es richtig sein"), siehe Klaus W. schrieb: > Ich sage zu den sinnlosen Antworten hier lieber nix. Hatte gedacht, hier > gibts Fachpersonal. > > Danke an die sinnvollen Antworten, die anderen ignoriere ich. > Behandlung per Interrupt-Auslösung wird sogar im Datenblatt von > Hopt&Schuler beschrieben, ist also durchaus nicht so abwegig. Was soll man dann noch sagen? Wer sich nichts sagen lassen will, dem kann man eben nicht helfen. Der muß eben mit Pfusch weiterleben, bis er vielleicht mal die Erfahrung macht, daß die anderen aufgrund langer Erfahrungen eventuell doch recht haben könnten.
Klaus W. schrieb: > Ich werde mir jedenfalls andere Drehgeber zulegen, die von Alps sind > Murks, wie auch hier auf der Seite zu lesen ist: > https://www.mikrocontroller.net/articles/Drehgeber Ich denke, für Deine vor noch 24h vorhandene Ahnungslosigkeit, bist Du jetzt ein wenig zu forsch. Weder sind diese Drehgeber einfach nur Murks, noch steht in dem bezeichneten, tendenziösen Artikel die alleinige Wahrheit. Und wenn Du noch mehr 'Schrottdinger' gefunden hast, solltest Du auch mal hinterfragen ob die Elektronik oder der Anwender 'schrottig' ist oder arbeitet. Nimm optische Drehgeber mit - sagen wir mal - 256 Impulsen/Drehung mit prellfreiem Ausgang. Da sollten dann alle Probleme entfallen, außer vielleicht das der Finanzierung. Noch etwas: Hopt&Schuler, muß man die kennen?
Klaus W. schrieb: > die von Alps sind Murks Klar, man kann auch teurere Inkrementaldrehgeber nehmen. Aber statt den Inkrementaldrehgeber kann man auch den µC wechseln. Hardware-Inkremental-Dekoder haben mit Pegelwechseln auf Rastpunkten kein Problem. @spess53 + Thomas W.: Danke für die Ergänzung: Der STM8S103F3P6 z.B. für 24 Cent, der SAM3X8E, der ATXMega usw. haben - wie gesagt - Hardware-Inkremental-Dekoder.
Klaus W. schrieb: > Danke an die sinnvollen Antworten, die anderen ignoriere ich. Ich hoffe, Du kannst die sinnvollen von den nicht sinnvollen Antworten unterscheiden. Die erste, sinnvolle Antwort kam m.E. von Torsten bereits nach einer Stunde.
m.n. schrieb: > Und wenn Du noch mehr 'Schrottdinger' gefunden hast, solltest Du auch > mal hinterfragen ob die Elektronik oder der Anwender 'schrottig' ist > oder arbeitet. Wenn ich nen Drehgeber habe, der Rasten hat und diese exakt auf einer Flanke liegen, ist das nicht im Sinne des Erfinders. Selbst wenn ich das mit Algorithmen raus rechne, ist es unnötiger Rechenaufwand. Dass der Kontakt bei jeder Erschütterung hin und her pendelt ist ja wohl klar. Um genau sowas zu vermeiden, hat er ja gerade eine Raste. Wenn ich das raus rechne, dann reduziere ich automatisch die Auflösung. Schließlich muss ich mir im Algorithmus immer die Frage stellen, ob das denn nun eine gewollte, oder ungewollte Bewegung ist. Der Wechsel erfolgt ja durchaus im erlaubten Rahmen, d.h. der Signalwechsel ist nicht von vornherein als illegal zu erkennen. Dementsprechend muss der Nutzer also den Regler weiter drehen, damit dies auch als Bewegung zweifelsfrei erkannt werden kann. Mit anderen, wo die Raste zwischen Flanken liegt, besteht das Problem erst gar nicht. Und bautechnisch ist das kein Mehraufwand, d.h. solche müssen also nicht mehr kosten. > Noch etwas: Hopt&Schuler, muß man die kennen? Nö, einer von vielen Herstellern. Man muss nicht alle kennen. Aber sehr viele Elektronikversender kennen die, da sie nämlich von denen was verkaufen.
Klaus W. schrieb: > Selbst wenn ich das mit Algorithmen raus rechne, ist es unnötiger > Rechenaufwand. Was willst Du da "rausrechnen? Ich denke, Du solltest Dich doch noch mal mit den Grundlagen von Inkrementalgebern beschäftigen. Übrigens gibt es Firmen, die mit Inkrementalgebern Auflösungen im Nanometerbereich erreichen. Natürlich muss dann auch die mechanische Stabilität stimmen. > Wenn ich das raus rechne, dann reduziere ich automatisch die Auflösung. Stimmt nicht. > Mit anderen, wo die Raste zwischen > Flanken liegt, besteht das Problem erst gar nicht. >> Noch etwas: Hopt&Schuler, muß man die kennen? > Nö, einer von vielen Herstellern. Wie bereits gesagt: Nicht alles was im INet steht, muss auch stimmen.
Klaus W. schrieb: > Wenn ich nen Drehgeber habe, der Rasten hat und diese exakt auf einer > Flanke liegen, ist das nicht im Sinne des Erfinders. Du wirst (hoffentlich) lachen, es gibt auch Drehgeber, bei denen ein Kanal die Impulse erzeugt, die gezählt werden können, und der andere Kanal von einem Schalter kommt, der in der einen Drehrichtung offen, und in der anderen Drehrichtung geschlossen ist. Der gibt nur die Richtung vor, so wie auch der 'flankende Rastpunkt' genutzt werden kann.
m.n. schrieb: > Du wirst (hoffentlich) lachen, es gibt auch Drehgeber, bei denen ein > Kanal die Impulse erzeugt, die gezählt werden können, und der andere > Kanal von einem Schalter kommt, der in der einen Drehrichtung offen, und > in der anderen Drehrichtung geschlossen ist. Der gibt nur die Richtung > vor, so wie auch der 'flankende Rastpunkt' genutzt werden kann. Ein solcher Spezialdrehgeber war in meinem Heizkörperthermostat verbaut und defekt. Leider findet man da praktisch keinen Ersatz. Jetzt muss ich mit einem Doppeltaster einstellen...
Harald W. schrieb: >> Wenn ich das raus rechne, dann reduziere ich automatisch die Auflösung. > Stimmt nicht. Richtig: Stimmt nicht, da es bei Alps zwei Flankenwechsel pro Raste gibt. Man shiftet den Counter um ein Bit nach rechts. So mache ich das seit Jahren und es funktioniert sogar mit 'nem Akkuschrauber-Test. :-p
Klaus W. schrieb: > Behandlung per Interrupt-Auslösung wird sogar im Datenblatt von > Hopt&Schuler beschrieben, ist also durchaus nicht so abwegig. Das Datenblatt hat dann natürlich auch extra RC an den Eingangssignalen: http://www.hopt-schuler.de/de/produkte/schalter/encoder/488
Torsten C. schrieb: > Klar, man kann auch teurere Inkrementaldrehgeber nehmen. Aber statt den > Inkrementaldrehgeber kann man auch den µC wechseln. Oder einen ergänzen: Beitrag "mini Quadraturdekoder + 32 Bit Zähler + TWI, Attiny25"
Clemens L. schrieb: > Das Datenblatt hat dann natürlich auch extra RC an den Eingangssignalen: > http://www.hopt-schuler.de/de/produkte/schalter/encoder/488 "Wenn ein Schalterpin an eine Unterbrechung Input des Mikrocontrollers angeschlossen wird" - naja, ob das die Glaubwürdigkeit des Datenblatts steigert? Allerdings wird die Polling-Variante ja auch explizit beschrieben. Aber warum soll man A und A' b.z.w. B und B' kurzschließen?
:
Bearbeitet durch User
Clemens L. schrieb: > Das Datenblatt hat dann natürlich auch extra RC an den Eingangssignalen: > http://www.hopt-schuler.de/de/produkte/schalter/encoder/488 Und die Interrupt-Variante wird als zweite Möglichkeit gezeigt. Das erste Beispiel behandelt das Polling mit Level- und nicht mit Flankenauswertung.
Torsten C. schrieb: > Klar, man kann auch teurere Inkrementaldrehgeber nehmen. Aber statt den > Inkrementaldrehgeber kann man auch den µC wechseln. Man muss weder noch tun. Die ALPS sind problemlos auswertbar mit den genannten richtigen Algorithmen, und es ist völlig egal, ob die Rastpunkte am Flankenwechsel liegen oder gar keine Rastpunkte da wären, gute Software funktioniert immer. Dein Algorithmus ist einfach falsch gewesen. Auch der Herr, der in https://www.mikrocontroller.net/articles/Drehgeber#Dekoder_f.C3.BCr_Drehgeber_mit_wackeligen_Rastpunkten rumgepfuscht hat, hat einfach ein völlig anderes Problem in den Auswertealgorithmus verlagert: Seine Eingaberoutine kam wohl nicht damit klar, daß sich von Abfrage zu Abfrage der Wert um +/-1 ändert, weil der Drehgeber mechanisch wackelt. Es war aber völlig richtig, daß dabei um +/-1 verändernde Werte geliefert wurden, denn so drehte sich auch der Drehgeber, er wurde völlig korrekt ausgewertet. Das Teilen durch 2 hätte nachher passieren sollen. Clemens L. schrieb: > Klaus W. schrieb: >> Behandlung per Interrupt-Auslösung wird sogar im Datenblatt von >> Hopt&Schuler beschrieben, ist also durchaus nicht so abwegig. > > Das Datenblatt hat dann natürlich auch extra RC an den Eingangssignalen: > http://www.hopt-schuler.de/de/produkte/schalter/encoder/488 Schrott funktioniert natürlich nur manchmal. Schrott muss auch nicht billig sein.
Raste auf Flankenwechsel ist Müll. Mag zwar kompensierbar sein und nicht unbedingt ein Argument einen anderen Encoder zu nehmen, das ändert aber nichts daran, dass das Müll ist. Bei Menuführung mit Drehencoder hab ich dann entweder ein Menu, was nur auf jede zweite Raste reagiert (wirkt seltsam) oder eine Stelle, in der es zappelt. Kann man sicher noch besser kompensieren, aber naja. Nicht optimal
Jan H. schrieb: > Raste auf Flankenwechsel ist Müll. Raste auf Flankenwechsel != Keine Flanke zwischen Rastpunkten
:
Bearbeitet durch User
Walter T. schrieb: > Jan H. schrieb: >> Raste auf Flankenwechsel ist Müll. > > Raste auf Flankenwechsel != Keine Flanke zwischen Rastpunkten Hat auch nie einer behauptet. Es geht einfach nur um die Aussage, dass die Raste exakt auf dem Flankenwechsel einfach Mist ist. Wenn im Ruhezustand ständis die Flanke zappelt, ist das nicht im Sinne des Erfinders eines Dregebers.
Jan H. schrieb:
> Raste auf Flankenwechsel ist Müll.
Der arme TO.
Hier schreiben so viele Leute Müll, wie soll der TO da noch
durchblicken?
Wer selbst (! das soll es auch noch geben!) programmiert und sich
Gedanken macht, für den ist so ein Drehgeber wohl kein Problem. Egal wo
die Rasterung zur Flanke sitzt.
Wer nur Code kopiert, für den ist alles was nicht auf Anhieb
funktioniert schlecht, kaputt, falsch, Mist und Müll.
Schade der TO hätte was lernen können, vor allem von Leuten die
Erfahrung haben.
Klaus W. schrieb: > dass > die Raste exakt auf dem Flankenwechsel einfach Mist ist Eigentlich stört sie nicht - man ignoriert sie einfach. Man muß nur wissen, welche der vier Flanken die "Nutzflanken" und welche die Flanken auf der Rastung sind.
Aber Flankenwechsel an dem Punkt, um den der losgelassene Encoder rum wackelt. Wenn er nach einer Erschütterung auf beiden Zuständen stehen bleiben kann, dann ist das wirklich unpraktisch. Wenn er eins hin und immer auch wieder zurück wackelt ist es eigentlich egal. Welcher der beiden Effekten tritt bei denen eigentlich genau auf. Ich hatte es interpretiert als ersteres.
Klaus W. schrieb: > Hat auch nie einer behauptet. Es geht einfach nur um die Aussage, dass > die Raste exakt auf dem Flankenwechsel einfach Mist ist. Wenn im > Ruhezustand ständis die Flanke zappelt, ist das nicht im Sinne des > Erfinders eines Dregebers. Walter T. schrieb: > Eigentlich stört sie nicht - man ignoriert sie einfach. Man muß nur > wissen, welche der vier Flanken die "Nutzflanken" Jan H. schrieb: > Mag zwar kompensierbar sein Korrektur auf: Ist mit geringem Aufwand kompensierbar. Müll ist ein zu starkes Wort dafür, da muss ich mich wohl entschuldigen. Es ist einfach suboptimal.
Warum ein Hersteller sich wünscht, mit seinen "Micro"-Schalterchen geladene Kondensatoren kurz zu schliesen, braucht man wohl nicht weiter erläutern. Oder doch? Er verkauft dann einfach mehr! (solange die Kunden das mitmachen)
Carl D. schrieb: > Warum ein Hersteller sich wünscht, mit seinen "Micro"-Schalterchen > geladene Kondensatoren kurz zu schliesen, braucht man wohl nicht weiter > erläutern. Oder doch? Er verkauft dann einfach mehr! (solange die Kunden > das mitmachen) oder er verhindert damit eine Oxidation der Kontakte. Der Strom bei 33nF sollte nicht zu einen Lichtbogen führen.
Carl D. schrieb: > Warum ein Hersteller sich wünscht, mit seinen "Micro"-Schalterchen > geladene Kondensatoren kurz zu schliesen, braucht man wohl nicht weiter > erläutern. Oder doch? Es gibt hier eine "Mindeststromfraktion", die Dir das sicher erklären kann. Derzufolge müssen Kontakte immer freigebrannt werden, damit sie nicht verstopfen aber auch noch nicht zusammenschweißen. Da ich persönlich sowieso in die Hölle komme, betreibe ich Kontakte mit Unterstrom u.a. auch im Mikroampere-Bereich. Das ist schwer verboten und dürfte garnicht funktionieren. Böse, böse. Insofern hätte ich mindestens 1 kOhm in Reihe zum Schalter eingezeichnet, was die Schaltung aber unnötig verteuern würde. Hier wird nämlich immer in Millionenstückzahlen kalkuliert und die beste Schaltung benötigt keinerlei Bauteile. Soviel zum Sommerloch-Drehgeber-Fred ;-)
m.n. schrieb: > Ich betreibe Kontakte mit Unterstrom u.a. auch im Mikroampere-Bereich. Aha. Bist Du vielleicht ein Untermensch? SCNR
Harald W. schrieb: > Aha. Bist Du vielleicht ein Untermensch? > SCNR Solange Du auf der anderen Straßenseite stehst und schnell laufen kannst, darfst Du das ruhig fragen ;-)
m.n. schrieb: > Oder einen ergänzen Wo bei ein ATtiny25 zwei bis dreimal so teuer ist, wie ein STM8S103F3P6 und auch keinen eingebauten Hardware-Incremental-Decoder hat. Aber ich weiss: Er ist im DIP und AVR ist sowieso besser. ;-)
Torsten C. schrieb: > m.n. schrieb: >> Oder einen ergänzen > > Wo bei ein ATtiny25 zwei bis dreimal so teuer ist, wie ein STM8S103F3P6 > und auch keinen eingebauten Hardware-Incremental-Decoder hat. > > Aber ich weiss: Er ist im DIP und AVR ist sowieso besser. ;-) ??? Wo kaufst Du Deine Bauteile? Digikey ATtiny25 1,36€ STM8S103F3P6 1,69€ Mouser ATtiny25 1,06€ STM8S103F3P6 1,56€ (Einzelpreise) Ja, ich weiss, dass das bei weitem nicht die günstigsten Bezugsquellen sind, aber ich wollte die Preise jeweils beim gleichen Anbieter vergleichen.
Ich hatte ja oben angedeutet, daß mir diese Millionenstückzahlschnorrer auf den Keks gehen, und prompt meldet sich einer zum Appell. Torsten C. schrieb: > Wo bei ein ATtiny25 zwei bis dreimal so teuer ist, wie ein STM8S103F3P6 Also ich zahle für einen ATtiny25 17 Cent. Was kostet Dein STM8 genau? Das zu dem Thema ;-) Für den ATtiny25 gibt es ein fertiges Programm, was funktioniert. Zum STM8 gibt es nur virtuelles Säbelrasseln.
m.n. schrieb: > Zum STM8 gibt es nur virtuelles Säbelrasseln. Nein, steht oben, da ist nix virtuelles. Das ist ein freundlicher Hinweis. Wie kommst Du auf "Säbelrasseln"? Bernd schrieb: > Wo kaufst Du Deine Bauteile Steht im China-Thread. ATTINY25-20SU: €0,67 / piece incl. Versand. Gehört aber auch in den China-Thread und nicht hierher.
:
Bearbeitet durch User
Walter T. schrieb: > Klaus W. schrieb: >> dass >> die Raste exakt auf dem Flankenwechsel einfach Mist ist > > Eigentlich stört sie nicht - man ignoriert sie einfach. Man muß nur > wissen, welche der vier Flanken die "Nutzflanken" und welche die Flanken > auf der Rastung sind. Dazu kommt noch, daß 20 Impulse pro Umdrehung gleich 40 Pegelwechsel sind (ein Impuls ist immer ein Übergang von L zu H und ein weiterer von H zurück auf L). Da üblicherweise die Impulse pro Phase und Umdrehung angegeben werden, sind es insgesamt 80 Codewechsel je Umdrehung. Oder 4 Codewechsel pro Raststufe. Feiner als eine Raststufe kann man einen rastenden Encoder ohnehin nicht auswerten. Selbst wenn der Rastpunkt genau auf einem Codewechsel liegt - die anderen drei Codewechsel sind stabil. Man findet also mit minimaler Anstrengung eine Auswertung, die stabile Werte liefert.
m.n. schrieb: > Es gibt hier eine "Mindeststromfraktion", die Dir das sicher erklären > kann. Derzufolge müssen Kontakte immer freigebrannt werden, damit sie > nicht verstopfen aber auch noch nicht zusammenschweißen. Aber diese Pauschalisierung ist leider falsch. Es gibt sonne und solche Kontakte. Welche, die mit sehr kleine Ströme gut zurecht kommen, und welche, die damit Probleme haben. Machmal werden diese Eigenschaften beim Kontaktmaterial auch kombiniert: Kontakte für große Ströme, die zusätzlich hauchvergoldet sind. Das Gold verhindert Oxidation und kann daher kleine Ströme schalten. Wird der Kontakt aber mit hohen Strömen belastet, verdampft das Gold und es ist nur noch ein Hochstromkontakt. > Da ich persönlich sowieso in die Hölle komme, betreibe ich Kontakte mit > Unterstrom u.a. auch im Mikroampere-Bereich. Das ist schwer verboten und > dürfte garnicht funktionieren. Böse, böse. Es muss also gar nicht böse sein wenn Du das tust. Aber musst Du auch genau wissen, was Du tust. Leider lässt sich die Welt oft nicht auf ein einfaches "gut" oder "böse" reduzieren ... Gruß Dietrich
Dietrich L. schrieb: > Aber diese Pauschalisierung ist leider falsch. Das wollte ich ja mit meinem 'Zitat' auch zum Ausdruck bringen. Ebenso wie es auch Gründe gibt, Drehgeber unterschiedlich auszuwerten: polling oder als Interruptquelle. Nur die vielen Fliegen kennen immer nur ihren Haufen und bestehen darauf, daß er der einzig wahre sei. Ab und zu muß man dann die Klatsche nehmen, auch wenn das Getöse groß wird ;-) Axel S. schrieb: > Feiner als eine Raststufe kann man einen rastenden Encoder ohnehin nicht > auswerten. Selbst wenn der Rastpunkt genau auf einem Codewechsel liegt - > die anderen drei Codewechsel sind stabil. Man findet also mit minimaler > Anstrengung eine Auswertung, die stabile Werte liefert. So ist es!
m.n. schrieb: > Nur die vielen Fliegen kennen immer nur ihren Haufen und bestehen > darauf, daß er der einzig wahre sei. Genau! Millionen von Fliegen können nicht irren: Scheisse schmeckt köstlich. :-)
m.n. schrieb: > Das wollte ich ja mit meinem 'Zitat' auch zum Ausdruck bringen. Ebenso > wie es auch Gründe gibt, Drehgeber unterschiedlich auszuwerten: polling > oder als Interruptquelle. Wie für m.n. üblich: Unvollständige Beschreibung lässt Interpretation scheunenweit offen. Interrupt kann hier Timerinterrupt oder Flankeninterrupt sein. Timerinterrupt ist kein Problem. Flankeninterrupt ist immer falsch. Damit ist die allgemeine Aussage "interruptquelle" nutzloses Geschwätz. Aber selbst das "Zitat" hilft m.n. nicht; Beitrag "Mindeststrom bei Taster/Schalter für sicheren Betrieb?" Hier kommt der Mindeststrom beim Kontakt her. a) Der Fragende in dem Thread hat wirklich ein Problem mit dem Mindeststrom. b) Die Antwort in dem Thread von m.n. ist nutzlos. Marvin M. bringt das gut rüber: Datum: 17.02.2013 14:20 @m.n. Dein Beitrag strotzt ja vor Wissen. Begründungen? Nur zur Info: Auch Goldkontaktschalter brauchen Mindeststrom, nur Quecksilberbenetzte Kontakte nicht, aber Quecksilber ist in Zeiten von RoHS rar. Man muss also sage. i.A. brauchen Schalter einen Mindeststrom. Sogar dann, wenn keiner im Datenblatt steht.-
MaWin schrieb: > Flankeninterrupt ist immer falsch. > Damit ist die allgemeine Aussage "interruptquelle" nutzloses Geschwätz. Damit der Sommerlochthread nicht stirbt: Ich finde es trotzdem gut! Bin ich doch viel zu faul irgendwas ständig abzufragen, das möglicherweise nie benutzt wird. Der Drehgeber soll mir gefälligst Bescheid sagen, wenn er was will ...
Volker S. schrieb: > Der Drehgeber soll mir gefälligst Bescheid sagen, wenn er was will ... Drehgeber: "Bescheid!"
Volker S. schrieb: > Bin ich doch viel zu faul irgendwas ständig abzufragen, > das möglicherweise nie benutzt wird. Der Drehgeber soll mir > gefälligst Bescheid sagen, wenn er was will ... Geht mir genauso. Auch der Timer soll sich melden, wenn er überläuft. Ihn dauernd sinnlos auf Überlauf abzufagen, ist doch richtig lästig.
m.n. schrieb: > Auch der Timer soll sich melden, http://www.mamiweb.de/nfs/premiummagazin/container/037/37418/schueler-melden-sich-l.jpg
Na, wo es hier gerade so nett zu geht, melde ich mich auch nochmal aus Interesse, selbst wenn ich weder ein Timer noch ein Drehgeber bin: Wo gibt es den ATtiny25 für 17Cent? m.n. schrieb: > Also ich zahle für einen ATtiny25 17 Cent. Was kostet Dein STM8 genau? 24 Cent bei 100 Stück incl. Versand, siehe Beitrag "µC mit 1K SRAM für 24ct"
Lothar M. schrieb: >> Die Kontakte des Encoders prellen. >> Externes entprellen mit 2 RC Gliedern hilft. > Das ist die lange Schreibweise von "Murks". Ach.. mal wieder eines der beliebten Themen, wo sich zwei aus schierem Grundsatz unversöhnlich gegenüberstehende Parteien bekriegen. Also: Drehgeber auf Basis von mechanischen Kontakten prellen immer, das ist Stand der Technik und es ist eben kein Murks. Drehgeber auf Basis von Optik prellen nicht, brauchen dafür aber Schmitt-Trigger-Eingänge wegen der recht "unsteilen" Flanken. Drehgeber auf magnetischer Basis (Austriamicrosystems) prellen überhaupt nicht und brauchen auch keine Schmitt-Trigger. Schick&Teuer Jede Sorte hat ihre Meriten - und die simplen mechanischen haben den geringsten Preis. Dafür prellen sie eben, bäh. Andererseits könnte man das Prellen schlichtweg ignorieren, sofern der durch den Flankenwechsel ausgelöste Interrupt (jaja, Lothar) nur schnell genug ist. Grund: der dahinter stehende Zählvorgang ist ja richtungsabhängig und so kann der "Zählerstand" eben auch für ne kurze Zeit prellen (also quasi +1, -1, +1, -1, +1) und wird sich nach der ganzen Prellerei auf dem neuen Stand befinden. Eben so, als hätte es überhaupt kein Prellen gegeben. Natürlich ist es lästig, wenn man auf jedes VOR und ZURÜCK und wieder VOR eine ganze Latte von µC internen Aktivitäten auslöst. Sinnvoller wäre es, mit jedem Flanken-Interrupt einen Timer zur Verzögerung zu (re)starten und die Weiterverarbeitung erst mit dessen Ablaufen zu starten - also wenn sich die Prellerei gelegt hat. Weitaus einfacher ist es jedoch, tatsächlich zu entprellen und dies in Hardware zu tun. Man braucht dafür aber nur einen Tiefpaß, nämlich den für die Interrupt-Erzeugung. Ach ja: Bei den hier eher wenig besprochenen Kinetis µC von Freescale gibt's die Entprellung in der Port-Logik. Find ich elegant. Hab sowas Ähnliches bislang nur noch bei Nuvoton gefunden. So. Hier mal ein Beispiel, wie das geht: /******* Interrupt vom Drehgeber *************/ __irq void PORTB_IRQHandler (void) { dword L; long i; L = GPIOB_PDIR; // Port lesen i = 1 & ((L>>2) ^ (L>>3)); // Richtung ? if (i) { ++DgPosition; Add_Event(idDrehR); } else { --DgPosition; Add_Event(idDrehL); } } Und noch ein Wort an Lothar, der ja Fan vom Polling ist: Entweder belästigt man den µC mit häufigem Polling oder man kriegt hie und da die Drehereignisse nicht mit - jajaja.. auch hier schlägt das Abtast-Theorem gnadenlos zu. Genau deshalb finde ich Polling grottenschlecht, denn immerhin ist der zeitliche "Dynamik"-Bereich bei Drehgebern wesentlich größer als bei Tasten aller Art. W.S.
W.S. schrieb: > Drehgeber auf Basis von Optik prellen nicht, brauchen dafür aber > Schmitt-Trigger-Eingänge wegen der recht "unsteilen" Flanken. > > Drehgeber auf magnetischer Basis (Austriamicrosystems) prellen überhaupt > nicht und brauchen auch keine Schmitt-Trigger. Schick&Teuer Drehgeber beider Sorten können durch mechanische Vibrationen an der Übergangsstelle deutlich schnellere Flankenwechsel liefern als durch Drehbewegung erklärbar, sich also wie bei prellenden Kontakten verhalten. Auch elektrische Einstreuungen können im Zustandsübergang zu einem hin und her des Signals führen, das sich nicht vom Prellen mechanischer Drehencoder unterscheidet und viel schneller ist als der Strichwechsel. Alle Drehencoder sind also auf der Auswerteseite gleich wie mechanisch prellende zu behandeln. W.S. schrieb: > Andererseits könnte man das Prellen schlichtweg ignorieren, sofern der > durch den Flankenwechsel ausgelöste Interrupt (jaja, Lothar) nur > schnell genug ist. Alle Interrupteingänge haben eine Maximalfrequenz des Signals bzw. minimale notwendig stabile Zeit. Dieses kann durch die oben genannten schnellen Flankenwechsel unterschritten werden (es ist nicht garantierbar, daß nicht). Flankeninterrupts sind also prinzipiell immer ein Risiko, sie können sogar den Prozessor überlasten, beispielsweise wenn die InterruptRoutine 12msec benötigt, und der Drehgeber im Schaltpunkt stehen bleibt wo die 100Hz der gleichgerichteten Netzfrequenz zu Flattereffekten führen: Der Prozessor bleibt immer in der Interrupt-Routine und führt das Hauptprogramm gar nicht mehr aus, ist also quasi abgestürzt. Dein Zusatz "sofern der durch den Flankenwechsel ausgelöste Interrupt (jaja, Lothar) nur schnell genug ist" ist also essentiell. Leider ist die benötigte Minimalzeit (Maximallaufzeit des Interrupts) nicht definierbar. Es reicht NICHT, die maximale Drehgeschwindigkeit des Encoders anzusetzen (siehe oben). W.S. schrieb: > Weitaus einfacher ist es jedoch, tatsächlich zu entprellen und dies in > Hardware zu tun. Man braucht dafür aber nur einen Tiefpaß, nämlich den > für die Interrupt-Erzeugung. Man kann mit Hardware (Tiefpass und Schmitt-Trigger) garantieren, daß Flankenwechsel nicht schneller als x bzw. Signalzeiten immer minimal y usec lang sind. W.S. schrieb: > Entweder belästigt man den µC mit häufigem Polling oder > man kriegt hie und da die Drehereignisse nicht mit - jajaja.. Unsinn. Polling erlaubt es, nur mit der realen Drehgebermaximalstrichgeschwindigkeit abzutasten, nicht den oben angesprochenen Prell- und Flattereffekten. Mit der realen maximalen Drehgeschwindigkeit muss der uC so oder so zurecht kommen, und zwar immer, wenn er es nicht kann, ist das Programm einfach unzureichend. W.S. schrieb: > Genau deshalb finde ich Polling grottenschlecht Genau deshalb ist polling die einzige zuverlässig funktionierende Lösung und Flankeninterrupts sind immer Scheisse. Klar daß die Deppen an all so was nicht denken. Dann gibt es halt Geräte, die manchmal funktionieren und manchmal nicht. So etwas kennen wir ja zur Genüge von kommerziellen Geräten.
MaWin schrieb: > Drehgeber beider Sorten können durch mechanische Vibrationen an der > Übergangsstelle deutlich schnellere Flankenwechsel liefern als durch > Drehbewegung erklärbar, sich also wie bei prellenden Kontakten > verhalten. Ich kann mir das bei den Dingern mit Rasten irgendwie nicht vorstellen. Die Raststellungen sind doch (hoffentlich) versetzt zu den Schaltstellen ...
Volker S. schrieb: > Die Raststellungen sind doch (hoffentlich) versetzt zu den Schaltstellen ... Wieso "hoffentlich"? Glaubst du, dass es irgendwelche Hinterhofklitschen gibt, die so etwas konstruieren? http://industrial.panasonic.com/lecs/www-data/pdf/ATT0000/ATT0000CE11.pdf
Clemens L. schrieb: > Glaubst du, dass es irgendwelche Hinterhofklitschen > gibt, die so etwas konstruieren? Wer weiß. Vielleicht die selben Hinterhofklitschen, welche die "kommerziellen Geräte" konstruiert haben auf die MaWin anspielt ;-)
W.S. schrieb: > Drehgeber auf Basis von Optik prellen nicht, brauchen dafür aber > Schmitt-Trigger-Eingänge wegen der recht "unsteilen" Flanken. Siehe Avago AEDR-8300. Flankensteilheit 100...500ns. Da brauchst keinen Schmitt-Trigger. Volker S. schrieb: > Ich kann mir das bei den Dingern mit Rasten irgendwie nicht vorstellen. > Die Raststellungen sind doch (hoffentlich) versetzt zu den Schaltstellen > ... Gibt es so oder so, speziell der Panasonic (z.B. STEC12) bietet in eienr Serie Beides an. rgds
W.S. schrieb: > Ach ja: Bei den hier eher wenig besprochenen Kinetis µC von Freescale > gibt's die Entprellung in der Port-Logik. Find ich elegant. Hast Du eine Größenordnung für die einstellbaren Zeiten? Auf die Schnelle finde ich das nicht im Datenblatt. Oder sind es die 'glitch filter' zu LPTMR. Bei den STM32 gibt es sehr weit einstellbare Filter an den Capture-Eingängen von ns bis fast in den ms-Bereich. Jetzt muß sich nur noch ein Spritti melden, dem nicht nur die Hände, sondern auch die Impulse zittern. Ich habe oft nachgefragt, aber zeigen konnte man mir diese Signale nie. Es sind offensichtlich Signale, die in Fanta enthalten sind und die die Zitter-Phantasie anregen.
6a66 schrieb: > 6a66 schrieb: >> Panasonic (z.B. STEC12 > Korrektur: ALPC STEC (ob 11, 12 oder andere). > rgds Also ich habe die zufällig beide, den ALPS STEC12 und den PANASONIC EVEQDBRL416B als alternative Bestückungsvariante auf unseren Mikrocontroller Boards für Studenten. Kann bei beiden kein Zittern feststellen. Aus den Abbildungen in den Datenblättern werde ich allerdings nicht ganz schlau. Die Darstellung des Rastpunktes ist irgendwie in keinem gelungen.
:
Bearbeitet durch User
Volker S. schrieb: > Also ich habe die zufällig beide, den ALPS STEC12 Da musst Du dann schauen, welche STEC12. Der D http://www.alps.com/prod/info/E/HTML/Encoder/Incremental/EC12E/EC12D1524403.html hat zum Beispiel andere Detent positions wie der E http://www.alps.com/prod/info/E/HTML/Encoder/Incremental/EC12E/EC12E2430401.html Das "Zittern" (aka Prellen) ist im verlinkten Datenblatt ganz unten angegeben (Sliding noise, chattering) rgds
In der Realität sieht das Signal doch ganz anders aus. Wenn man an so einem Encoder dreht, dann gibt es bei/zwischen jedem Rastpunkt bei den STEC zwei winkelversetzte kurze Impulse. Bei dem erwähnten Panasonic EVEQDBRL416B wechselt der Pegel. Diese Abbildungen mit den 50% sind doch irreführend. Warum wird/werden da nicht einfach ein/zwei Winkel angegeben ?
Volker S. schrieb: > Diese Abbildungen > mit den 50% sind doch irreführend. Das wäre ja noch schöner, wenn man so einfach herauslesen könnte, was man wissen muß. :-( SCNR Paul
Paul B. schrieb: > Das wäre ja noch schöner, wenn man so einfach herauslesen könnte, was > man wissen muß. Das ALLERBESTE ist die Abbildung, wo der Rastpunkt genau auf der Flanke des Signals B steht und darunter steht dann: Detent position canot be specified for B signal
Paul B. schrieb: >> Diese Abbildungen mit den 50% sind doch irreführend. > Das wäre ja noch schöner, wenn man so einfach herauslesen könnte, was > man wissen muß. Genau, schliesslich muss man doch die Laien irgendwie abwehren. Sonst kommen die womöglich noch auf die Idee, eine Steuerung mit Inkrementalgebern bauen zu wollen. :-)
Willkommen zum Drehgeber-Sommer-Theater! (Für alle die, die beim Drehgeber-Frühlings-Theater nicht dabei sein konnten...) 1.) Wer einen Drehgeber zu schnell dreht, der wird mit keiner Entprellung der Welt und keiner Routine einen Drehgeber einwandfrei dekodieren können. 2.) Wenn ein Kontakt eines Drehgeber prellt, fällt er zwischen zwei Zuständen hin und her. Also als wenn man an der Stelle vorwärts und rückwärts dreht. Eine schnelle Auswertung flimmert in dieser Zeit zwischen diesen beiden Zuständen um am Ende aber den richtigen Wert auszugeben. Es schaltet ja nur ein Kontakt. Sollte auch der andere innerhalb dieser Zeit schalten, sieht 1.) 3.) Du musst einfach nur regelmäßig die beiden Bits lesen und zu den beiden zuletzt gelesenen packen. Ich mache dies, indem ich die neuen Bits von unten in das Register mit den alten Bits hinein schiebe. Die oberen 4 Bits in dem Byte schneide ich per verUNDung ab. So habe ich 4 Bits. Oder eine Zahl von 0-15. Diese 16 Kombinationen sind die Aussage über vorwärts, rückwärts oder gar nicht gedreht. 4 der 16 Zahlen sind für vorwärts, und 4 weitere für rückwärts. Du musst also bei der einen Gruppe Deinen Zähler inkrementieren und bei einer Zahl aus der anderen Gruppe dekrementieren. Solltest Du an bestimmten Positionen nicht zählen wollen, so ignorierst Du diese Werte. Du musst dabei allerdings darauf achten, dass beide Werte an dieser Position ignoriert werden. Sonst zählt er bei prellen an dieser Position z.B. rauf, kann aber nicht wieder runter zählen, weil dieser Übergang ignoriert wird. Am einfachsten hat es sich erwiesen, eine Tabelle mit 16 Werten zu machen und den Wert aus dem Schieberegister als Index darauf zu verwenden. Wo aufwärts gezählt werden soll, steht eine 1, wo abwärts gezählt werden soll, steht -1 und an allen anderen Positionen eine 0. Der Wert wird geholt und zu Deinem Zähler hinzuaddiert. Fertig. Das Ganze macht man im Timer IRQ. Sind vielleicht 10 Befehle in Assembler, dann hat man seinen fertigen Wert. Als Lektüre empfehle ich auch diesen Thread: Beitrag "Versetzte Rechtecksignale auswerten, kein drehgeber" (Natürlich geht es um genau das ...) Gruß Jobst
:
Bearbeitet durch User
Klaus W. schrieb: > Ich werde mir jedenfalls andere Drehgeber zulegen, die von Alps sind > Murks, wie auch hier auf der Seite zu lesen ist: > https://www.mikrocontroller.net/articles/Drehgeber Dann verstehe ich nicht, wieso die bei mir astrein laufen. Aber du wirst wohl Recht haben ...
Jobst M. schrieb: > 3.) Du musst einfach nur ... OMG ! Bin ich froh, dass das bei mir immer austeichend gut mit einem simplen flankengetriggerten IR funktioniert, welcher lediglich den Zustand des anderen Signals checken muss ...
Vloki schrieb: > Bin ich froh, dass das bei mir immer austeichend gut mit einem simplen > flankengetriggerten IR funktioniert, welcher lediglich den Zustand des > anderen Signals checken muss ... Warts ab. Auch Drehgeber altern.
Vloki schrieb: > Bin ich froh, dass das bei mir immer austeichend gut mit einem simplen > flankengetriggerten IR funktioniert, welcher lediglich den Zustand des > anderen Signals checken muss ... Ich wette, dass es umständlicher ist! Gruß Jobst
Jobst M. schrieb: > Willkommen zum Drehgeber-Sommer-Theater! > (Für alle die, die beim Drehgeber-Frühlings-Theater nicht dabei sein > konnten...) > > 1.) Wer einen Drehgeber zu schnell dreht, der wird mit keiner > Entprellung der Welt und keiner Routine einen Drehgeber einwandfrei > dekodieren können. > > 2.) Wenn ein Kontakt eines Drehgeber prellt, fällt er zwischen zwei > Zuständen hin und her. Also als wenn man an der Stelle vorwärts und > rückwärts dreht. Eine schnelle Auswertung flimmert in dieser Zeit > zwischen diesen beiden Zuständen um am Ende aber den richtigen Wert > auszugeben. Es schaltet ja nur ein Kontakt. Sollte auch der andere > innerhalb dieser Zeit schalten, sieht 1.) > ... Und das funktioniert auch an einer Motor/Servowelle, wo es gar keine Rastungen gibt, und wo Murphy dafür sorgt, daß der immer an einem Umschaltpunkt zum Stehen kommt. MfG Klaus
Klaus schrieb: > Und das funktioniert auch an einer Motor/Servowelle, wo es gar keine > Rastungen gibt, und wo Murphy dafür sorgt, daß der immer an einem > Umschaltpunkt zum Stehen kommt. Danach ist aber doch gar nicht gefragt.
Jobst M. schrieb: > Willkommen zum Drehgeber-Sommer-Theater! Du bist spät! Hast Du denn schon ein Ticket erworben? Jobst M. schrieb: > 3.) Du musst einfach nur regelmäßig die beiden Bits lesen Aha, ein Poller ;-) Ich habe hier einen Drehgeber, der liefert 100000 Flankenwechsel/s. Den muß ich ja dann 100000*/s abfragen, die Schiebeoperation ausführen und den indizierten Wert aus einer Tabelle lesen - aber auch, wenn sich der Geber garnicht dreht. Na, wer macht denn sowas?
Ohne mich groß einmischen zu wollen;: Und inwieweit ist die ganze Zeit in einer Endlosschleife auf den nächsten Interrupt des Drehgebers zu warten, besser? Um den in irgendeinen Energiesparmodus zu versetzen und durch den Int aufwecken zu lassen, ist die Zeit zwischen 2 Impulsen ja bei der Impulszahl sicher zu kurz.
:
Bearbeitet durch User
Harald W. schrieb: > Warts ab. Auch Drehgeber altern. Ich fürchte so lange wird der gar nicht benutzt werden. Aber in extremen Anwendungsfällen muss man das in Erwägung ziehen. Jobst M. schrieb: > Vloki schrieb: >> Bin ich froh, dass das bei mir immer austeichend gut mit einem simplen >> flankengetriggerten IR funktioniert, welcher lediglich den Zustand des >> anderen Signals checken muss ... > > Ich wette, dass es umständlicher ist!
1 | void interrupt high_isr(void) |
2 | {
|
3 | if (ENC_IR){ |
4 | #ifdef ENCODER_PANASONIC
|
5 | mENC_INT_TOG_EDGE(); |
6 | #endif
|
7 | if(ENC_DIR == ENC_DIR_UP) |
8 | flags.encUp = 1; |
9 | else
|
10 | flags.encDown = 1; |
11 | mENC_IR_CLR(); |
12 | return; |
13 | }
|
14 | ...
|
Martin L. schrieb: > Um den in irgendeinen Energiesparmodus zu versetzen und > durch den Int aufwecken zu lassen, ist die Zeit zwischen 2 Impulsen ja > bei der Impulszahl sicher zu kurz. Also es geht hier doch um ein mechanisches Bedienelement, welches in aller Regel verhältnismäßig vernachlässigbar wenige Aktionen auslöst. Wenn es für das Programm nichts anderes zu tun gäbe, dann schätze ich die Zeit in einem evtl. Energiesparmodus doch best. >99,9%
Guten Morgen, ich habe Peter Danneggers C Programm für die Drehencoder Dekodierung in einer Hochsprache als assembleroptierte Version in eine Bibliothek gepackt. In der worst-case Analyse benötigt die Routine 119 CPU-Takte + 3 CPU-Takte (ISR-Call) - also 123 CPU-Takte. Wird der AVR µC mit z.B. 16MHz betrieben und mit einer Timer-Zyklusfrequenz von 2kHz betrieben, erfolgt ein Aufruf der Timer-ISR alle 16.000kHz /2kHz = 8.000 CPU-Takte. In diesem Timer-Zyklus beträgt dann die 'Auslastung' nur 1,54%. Auf alle 16Mio CPU-Takte bezogen dann auch nur: 2000 *7,69 *10⁻⁶ = 0,0154
:
Bearbeitet durch User
Uwe S. schrieb: > In diesem Timer-Zyklus beträgt dann die 'Auslastung' nur 1,54%. > > Auf alle 16Mio CPU-Takte bezogen dann auch nur: 2000 *7,69 *10⁻⁶ = > 0,0154 Wo ist jetzt genau der Unterschied zwischen 1,54% und 0,0154 ?
Volker S. schrieb: > Martin L. schrieb: >> Um den in irgendeinen Energiesparmodus zu versetzen und >> durch den Int aufwecken zu lassen, ist die Zeit zwischen 2 Impulsen ja >> bei der Impulszahl sicher zu kurz. > > Also es geht hier doch um ein mechanisches Bedienelement, welches in > aller Regel verhältnismäßig vernachlässigbar wenige Aktionen auslöst. Grundsätzlich ja, aber ich bezog mich -hätte wohl zitieren sollen- direkt auf den davor befindlichen Beitrag, in dem eben als Argument gegen Polling die hohe Zahl der Impulse kam. In den Energiesparmodus zu gehen wird ja nun bei der dort angeführten 100Khz Impulsrate auch nicht wirklich klappen, so daß die Abfrage per Interrupt gegenüber Polling da keinen echten Vorteil bringt.
m.n. schrieb: > Ich habe hier einen Drehgeber, [...] den > muß ich ja dann 100000*/s abfragen [...] - aber auch, wenn sich der > Geber garnicht dreht. > > Na, wer macht denn sowas? Für gesparte Takte kriegt man kein Geld zurück. Und für eine Auslastung des µC, die von der Bediengeschwindigkeit des Nutzers abhängt, bekommt man keinerlei Test-Mehraufwand genehmigt.
hi, und das sind grad mal 100kHz, ganz simpel, wenn man nicht alles in der IRQ macht sondern wirklich nur in Register lesen aus LUT lesen und die Position berechnen. Wenn das Signal ordentlich Aufbereitet ist und sauber zum µC kommt kann man auch Flankengesteuert auswerten, aber es gibt dir max beim Stromverbrauch durch Sleep Mode einen Vorteil, der Prozessor muss so oder so genug schnell sein für Drehgeber mit 100kHz Eingang. Mfg ich
Uwe S. schrieb: > Wird der AVR µC mit z.B. 16MHz betrieben und mit einer > Timer-Zyklusfrequenz von 2kHz betrieben, erfolgt ein Aufruf der > Timer-ISR alle 16.000kHz /2kHz = 8.000 CPU-Takte. > > In diesem Timer-Zyklus beträgt dann die 'Auslastung' nur 1,54%. Na gut, und bei 100 kHz Timerfrequenz sind es dann 77 %, wenn mein Taschenrechner mich nicht geprellt hat. Das ist doch ein guter Wert, wenn man den µC beschäftigen will ;-) Martin L. schrieb: > In den Energiesparmodus Wer redet denn von Stromsparen? Habe ich etwas überlesen oder suchst Du nach einem zufälligen Scheinargument? In der Regel soll der µC noch andere Sachen erledigen, als nur sinnlos vor sich hinzuzählen. Wenn man ihn mit Timer-ISRs zukleistert, bleibt da nicht mehr viel übrig. Klaus schrieb: > Und das funktioniert auch an einer Motor/Servowelle, wo es gar keine > Rastungen gibt, und wo Murphy dafür sorgt, daß der immer an einem > Umschaltpunkt zum Stehen kommt. Dazu braucht man Murphy garnicht. Die Erfahrung hat ja jeder einmal gemacht. Eine Motorwelle springt mal eben fünf Schritte vorwärts und dann wieder drei zurück; und das Alles in 10 µs. Das ist dann eine Art Kammerflimmern, was man nur mit Polling auswerten kann. Sommerloch-Theater: Tod einer Motorwelle ;-)
Walter T. schrieb: > Für gesparte Takte kriegt man kein Geld zurück. Und für eine Auslastung > des µC, die von der Bediengeschwindigkeit des Nutzers abhängt, bekommt > man keinerlei Test-Mehraufwand genehmigt. Ach jetzt wird es mir langsam klar, warum viel Code zur Auswertung sich lohnt ;-)
m.n. schrieb: > Martin L. schrieb: >> In den Energiesparmodus > > Wer redet denn von Stromsparen? Habe ich etwas überlesen oder suchst Du > nach einem zufälligen Scheinargument? Keineswegs. Ich habe da nur grade ein kleines Verständnisproblem. > In der Regel soll der µC noch andere Sachen erledigen, als nur sinnlos > vor sich hinzuzählen. Wenn man ihn mit Timer-ISRs zukleistert, bleibt da > nicht mehr viel übrig. Welche Sachen z.B. könntest Du denn den uC zuverlässig und geplant in der Zeit erledigen lassen, wenn jederzeit ein Interrupt auftreten und die 100Khz Auslastung auftreten könnte? Mir fehlt da grade das Vorstellungsvermögen. Die Aufgaben müssten ja also eh in jedem Fall so geschnitten sein, daß sie auch erledigt werden, wenn die maximale Frequenz auftritt. Ob das per Polling geschieht oder per Eingangs-INT ist ja egal. Welche echten Aufgaben, die erledigt werden müssen, kannst Du denn so schneiden, das sie von der größeren Zeit zwischen 2 Interrupts beim eingangsgesteuerten Interrupt profitieren, aber zuverlässig noch mit der geringstmöglichen Zeit zurecht kommen? Das einzige mögliche Plus, was mir also bei der Nutzung eines Eingangs-Interrupts eingefallen ist, war das sich bei längerer Nichtnutzung der uC schlafen legen kann. Aber da hat man dann eben u.U. bei entsprechend geringen Zeiten zwischen 2 Pulsen das Problem, dass die Aufwachzeit zu lang wird.
Martin L. schrieb: > Welche Sachen z.B. könntest Du denn den uC zuverlässig und geplant in > der Zeit erledigen lassen, wenn jederzeit ein Interrupt auftreten und > die 100Khz Auslastung auftreten könnte? Mir fehlt da grade das > Vorstellungsvermögen. Ich stell mir gerade vor wie ein Benutzer an einen 20/20 Drehgeber 5000 U/s macht ;-) Im Ernst, auch wenn das an der eigentlichen Fragestellung ETWAS vorbeigeht. Lieber Interrupts mit 100kHz die auftreten könnten und nur geringen Aufwand zur Abarbeitung benötigen, als Interrupts die mindestens mit 200kHz auftreten müssen und viel Abarbeitungsaufwand benötigen.
Volker S. schrieb: > > Ich stell mir gerade vor wie ein Benutzer an einen 20/20 Drehgeber 5000 > U/s macht ;-) Na, ich hab das nicht aufgebracht...
Hi, dann hast du aber was falsch gemacht. Es wird ja am ANFANG die n_max bestimmt/geschätzt und darauf entwickelst du dein System. Weil was macht dein System, wenn jetzt mit doppelter Drehzahl gefahren wird, Richtig: Auch nichts sinniges. Also bitte immer die Spec betrachten. MfG ich
Volker S. schrieb: > Im Ernst, auch wenn das an der eigentlichen Fragestellung ETWAS > vorbeigeht. Es geht darum, daß eine Flankenauswertung per Interrupt alle Möglichkeiten bietet, ob von Stillstand bis zu hoher Drehzahl: eine Lösung für alle Fälle. Es gibt nicht nur diese billigen, mechanischen Geber, sondern auch die mit höherer Auflösung, die auch bei manueller Bedienung und erst recht bei Positionierungen hohe Frequenzen liefern können. Alles fällt unter den Oberbegriff: Drehgeber. Wer sich nun aus Unkenntnis oder Ignoranz einer Erfassung per Interrupt konsequent verschließt, kommt halt aus seinem Sandkasten nicht heraus. Daher auch dieses Kindergeschreie. Immer wieder gehört und das allerletzte Argument: "das brauche ich nicht." Na denn ...
m.n. schrieb: > Es geht darum, daß eine Flankenauswertung per Interrupt alle > Möglichkeiten bietet, ob von Stillstand bis zu hoher Drehzahl: eine > Lösung für alle Fälle. Leider nein. Beim Polling kann man genau vorherschätzen, bis zu welcher Drehzahl/Taktzahl die Erfassung zuverlässig läuft. Bei größerer Drehzahl werden Takte verschluckt. Das ist ein definiertes Verhalten und beeinflusst i.A. die sonstige Stabilität meines Programms nicht. Noch dazu vereinfacht es die Planung. Ich kann jederzeit genau sagen, wann und wie lange gepollt wird. Es ist ja noch nicht einmal eine Verzweigung in der Polling-Routine. Bei einem Flankeninterrupt kann ich: a) im Allgemeinen nicht vorher sagen, bis zu welcher Drehzahl noch alles gut geht. Vorher müßte ich erst einmal profilen, wieviele Takte meine ISR in allen Fällen benötigt und wieviele Takte meine restlichen Bestandteile (Hauptschleife und andere ISRs) in allen Fällen benötigen. b) beim Überschreiten der zulässigen Drehzahl kann sich mein µC bis zum kompletten Aufhängen nur noch mit dem Drehgeber beschäftigen. Ob und wann Hauptschleife und andere ISRs noch dazwischenkommen kann niemand vorhersagen. Das ist kein definiertes Verhalten bei "Überdrehzahl". c) kommt Prellen hinzu, ist der Punkt der "Überdrehzahl" noch viel schneller erreicht.
Ich befürchte, Ihr redet aneinander vorbei. Ist jemand der Meinung, dass Flankeninterrupt ohne Tiefpass und Schmitt-Trigger auch bei Vibrationen oder ungünstiger elektromagnetischer Einstrahlung sicher funktionieren? Sicherlich nicht. Es gibt also so oder so immer eine Maximaldrehzahl, also sowohl bei Timerinterrupt als auch beim Flankeninterrupt. Diese Maximaldrehzahl ist durch den Tiefpass bzw. durch die Timerinterrupt-Frequenz bestimmt.
:
Bearbeitet durch User
Torsten C. schrieb: > Ich befürchte, Ihr redet aneinander vorbei. Ich denke mal die IR Fraktion akzeptiert durchaus, dass es Anwendungen gibt in denen das nicht die Lösung sein kann. Für die Poller ist einfach alles andere nur Scheiße ;-)
Volker S. schrieb: > Ich denke mal die IR Fraktion akzeptiert durchaus, > dass es Anwendungen gibt in denen das nicht die Lösung sein kann. > Für die Poller ist einfach alles andere nur Scheiße ;-) Du bringst es auf den Punkt!
Volker S. schrieb: > Für die Poller ist einfach alles andere nur Scheiße ;-) Wenn man eine Hardware-Auswertung über eine getaktete Logik auch dem Pollen zurechnet (was es ja ist): Stimmt. Einzige Ausnahme: Aufwachvorgang für ein Gerät im Standby. Und da auch nur für den ersten Takt.
Ich weiss nicht, ob das eine Übertreibung sein sollte, als MaWin schrieb: > Timerinterrupt ist kein Problem. > Flankeninterrupt ist immer falsch. Ich würde nicht sagen "falsch". Aber der Flankeninterrupt bringt kaum Vorteile und kann im worst-case Nachteile bedeuten: Einerseits kann man hoffen, Rechenzeit zu sparen, andererseits kann man sie nicht einplanen, weil man sich nicht darauf verlassen kann. Dabei ist es egal, ob die CPU in der (wenn man Glück hat) gewonnenen Zeit schlafen oder Hintergrund-Tasks abarbeiten soll. In beiden Fällen (Schlafen oder Hintergrund-Task) bleibe ich bei meinem STM8S103F3P6 für 24 Cent, denn der decodiert sowohl bei schlafender als auch bei 100% ausgelasteter CPU. In allen anderen Fällen (weder Schlafen oder Hintergrund-Task) ist es m.E. vollkommen egal, wie man es macht und spart beim Timerinterrupt den Tiefpass und den Schmitt-Trigger. Oder?
m.n. schrieb: > Hast Du eine Größenordnung für die einstellbaren Zeiten? Auf die > Schnelle finde ich das nicht im Datenblatt. Hmm.. ja. Portweise, also mit PORTx... folgende Register: - in PCR Filterbit setzen (1<<4), - DFCR und DFWR zur Aufgabe passend setzen. Es geht bei 1 kHz Filtertakt in Stufen von 1 ms, ich glaub bis 31 oder 63 ms - hab's nicht auswendig gelernt. Bei höherem Filtertakt entsprechend kleinere Zeiten. ------- Torsten C. schrieb: > Ich weiss nicht, ob das eine Übertreibung sein sollte, als > MaWin schrieb: >> Timerinterrupt ist kein Problem. >> Flankeninterrupt ist immer falsch. > > Ich würde nicht sagen "falsch". Ich schon. Ach, MaWin schreibt öfters sowas - und es ist tatsächlich falsch. Und wenn man ihm sagt, daß er falsch liegt, wird er ausfallend. Als anständiger Ingenieur konditioniert man Signale, die einer Konditionierung bedürfen, und führt sie erst dann ihrer Auswertung zu. Bei Pfuschern hingegen ist es völlig üblich, daß sie die korrekte Vorbehandlung ignorieren und das daraus erwachsende Fehlverhalten anschließend korrigieren wollen. W.S.
m.n. schrieb: > Ich habe hier einen Drehgeber, der liefert 100000 Flankenwechsel/s. Den > muß ich ja dann 100000*/s abfragen, die Schiebeoperation ausführen und > den indizierten Wert aus einer Tabelle lesen - aber auch, wenn sich der > Geber garnicht dreht. Da vergleichst du jetzt aber Birnen mit Tomaten. Es ging ursprünglich (und stückzahlenmäßig vorrangig) um diese kleinen Drehencoder im Preisbereich um 2€, die anstatt eines Potis zum Einstellen von Werten verwendet werden. Nicht aber um einen industriellen 4000-Schritt-Inkrementalgeber, der locker mal das 100fache kosten darf. So einen Geber schließt man sinnvollerweise an einen Hardwarezähler an, der komplett ohne jegliche CPU Belastung die Zählung übernimmt. Denn ich kann mir bei Interruptauswertung so eines (in Zahlen 1) Inkrementalgebers mit einem AVR sehr gut vorstellen, dass da einige ihre interruptgesteuerte Software dann so hinbekommen, dass entweder der Geber mit gewünschter Maximalgeschwindigkeit drehen darf oder die Software ihre sonstigen Aufgaben erledigen kann. Aber nicht beides zusammen... Torsten C. schrieb: > Es gibt also so oder so immer eine Maximaldrehzahl, also sowohl bei > Timerinterrupt als auch beim Flankeninterrupt. Und jetzt kommt der Knackpunkt: diese Drehzahl ist beim Timerinterrupt mit einer einfachen "1/" Division ermittelbar. Bei der Interruptauswertung kommt es u.A. drauf an, wieviele andere und höherpriore Interrupts im System und wie oft die aktiv sind. Und wenn das einer nicht weiß und 3 Jahre später noch einen "kleinen" Interrupt dazupackt, der nur 1x pro Sekunde kommt, dann kann es passieren, dass durch diese ganz woanders platzierte Baustelle der Encoder auf einmal seltsame Sprünge macht. Und das nur ab und zu, irgendwie... W.S. schrieb: > Bei Pfuschern hingegen ist es völlig üblich, daß sie die korrekte > Vorbehandlung ignorieren und das daraus erwachsende Fehlverhalten > anschließend korrigieren wollen. Ich verlagere Filterung und Entprellung gerne in die Software, weil die so leicht anpassbar ist. Aber ich halte das nicht für Pfusch, sondern habe die Theorie dahinter kapiert... > Torsten C. schrieb: >> MaWin schrieb: >>> Flankeninterrupt ist immer falsch. >> Ich würde nicht sagen "falsch". > Ich schon. Du sagst also mit Nachdruck, es wäre "immer falsch", einen Flankeninterrupt zu verwenden? Wie jetzt diese radikale Kehrtwende? > Und wenn man ihm sagt, daß er falsch liegt, wird er ausfallend. Ich fände deinen Ton im vorigen Post bestenfalls unter Freunden und nach 5-6 Hefeweizen akteptabel. Denn ich denke, du solltest solche Verallgemeinerungen wie "Pfuscher" nicht allzu unbedarft aussprechen. Wenn ich ein Verfahren als "Pfusch" bezeichne, dann ist es was Anderes, wie wenn ich eine Menschengruppe generell als "Pfuscher" bezeichne. Aber jetzt könnt ihr weitermachen. Es wurde schon alles gesagt. Des Öfteren...
Torsten C. schrieb: > und spart beim Timerinterrupt den Tiefpass und den Schmitt-Trigger. So ist es. Wie geschrieben ist das Problem am Flankeninterrupt die ggf. zu kurze Zeit, und wie von mir geschrieben kann man die mit externem Hardwarezusatzaufwand, aka RC und Schmitt Trigger, definiert verlängern. Bloss: Warum sollte man Hardware hinzufügen, bloss weil man schlechte Software geschrieben hat ? Da schreibt man die Software doch lieber gleich richtig.
Nach der endlosen Diskussion sollte doch der Auftrag erkannt worden sei: Baut ein Arduino Shield, dass Drehgeber auswerten kann und schreibt die Lib dazu!!! Dann könnt ihr das ganze ein halbs Jahr lang für teuer Geld auf ebay verscheuern (bis es dich Cinesen kopiert haben) und die dähmliche Fragerei im Forum nimmt deutlich ab.
Karl schrieb: > Dann könnt ihr das ganze ein halbs Jahr lang für teuer Geld > auf ebay verscheuern (bis es dich Cinesen kopiert haben) und die > dähmliche Fragerei im Forum nimmt deutlich ab. Gar keine dähmliche Idee... ;-) MfG Paul
Volker S. schrieb: > void interrupt high_isr(void) > { > if (ENC_IR){ > #ifdef ENCODER_PANASONIC > mENC_INT_TOG_EDGE(); > #endif > if(ENC_DIR == ENC_DIR_UP) > flags.encUp = 1; > else > flags.encDown = 1; > mENC_IR_CLR(); > return; > } Wo werden die Flags auf eine Variable addiert? Und wo wieder zurück gesetzt? Im von mir angegebenen Link findest Du Code von mir. Uwe S. schrieb: > In der worst-case Analyse benötigt die Routine 119 CPU-Takte + 3 > CPU-Takte (ISR-Call) - also 123 CPU-Takte. Hrcchhhg!? =-O Ich benötige 8 Takte! m.n. schrieb: > Ich habe hier einen Drehgeber, der liefert 100000 Flankenwechsel/s. Den > muß ich ja dann 100000*/s abfragen, die Schiebeoperation ausführen und > den indizierten Wert aus einer Tabelle lesen - aber auch, wenn sich der > Geber garnicht dreht. > > Na, wer macht denn sowas? Ich gehe davon aus, dass es sich dabei nicht um einen Drehgeber wie hier behandelt handelt. Sondern etwas mit richtig Auflösung. Also auch etwas, was ohne eine Rastung arbeitet und daher alle vier Flankenwechsel interessant sind. Man also bei Interuptabfrage auf beide Flankenwechsel an zwei Ports reagieren muss. Alleine das stelle ich mir schon problematisch vor, wenn auf einmal mehrere IRQs deshalb ausgelöst werden. Oder löst weiterhin nur eine Flanke an einem Port den IRQ aus? Du nutzt also nur 1/4 der Auflösung des Gebers und zahlst dafür teuer? Na, wer macht denn sowas? ;-) Gruß Jobst
Volker S. schrieb: > Ich stell mir gerade vor wie ein Benutzer an einen 20/20 Drehgeber 5000 > U/s macht ;-) Mit einer am Drehgeber angeschlossenen Platinenbohrmaschine sicherlich möglich. :-)
Und der Hersteller schreibt: 15.000 Cycles Livetime. Also nach 3 Minuten. Wenn man die auf hoffentlich ein paar Jahre streckt, dann reicht Polling, oder?
Bastler schrieb: > Wenn man die auf hoffentlich ein paar Jahre streckt, dann reicht > Polling, oder? Polling reicht auf einem 16MHz AVR für 920000 Striche/Sekunde, für 2 Drehgeber, also daran liegt es eher nicht.
Jobst M. schrieb: > Alleine das stelle ich mir schon > problematisch vor, wenn auf einmal mehrere IRQs deshalb ausgelöst > werden. Oder löst weiterhin nur eine Flanke an einem Port den IRQ aus? Nicht, um hier weiter zu diskutieren, sondern weil Du fragst: bei einem AVR kann man geschickterweise beide Phasen auf einen Port legen, wobei jede Änderung den PCINT zu dem Port auslöst. Aktuellen Code dazu, der das deutlich macht, finde ich gerade nicht. Im Grunde ist es die gleiche ISR Routine (ähnlich kurz wie von W.S. oben gezeigt), wie sie auch mit einem Timerinterrupt angesprungen wird - aber eben nur bei Bedarf und nicht zyklisch. Von einem ATmega8 kommend, der noch keine PCINTs bot, nehme ich vielfach INT0 und INT1, die auf beide Flanken triggern können und bei einem AVR die höchste Priorität nebst eigenem Vektor haben. Ein Beispiel hatte ich vor einiger Zeit in die Codesammlung gestellt. Beitrag "4-fach Flankenauswertung per Interrupt mit ATmega48/88" Die Flanken werden in Assembler ausgewertet, der reservierte Variablen für die Interrupts bietet: 'qcnt_6sub.s'. Liest man den Text, findet man die Optionen für flankengetriggerte oder auch Timer ISR, wobei erstere etwas schneller ist: 500 kHz zu 400 kHz. Weiter unten sind ergänzende Schaltungen gezeigt, wie man unsaubere mechanische Signale flankengetriggert auswerten kann, selbst wenn sie Spikes im einstelligen µs-Bereich aufweisen. Um linieare Weggeber auszuwerten, verwende ich diese Routinen immer flankengetriggert. Diese liefern teilweise sehr hohe Frequenzen, aber immer nur kurzzeitig. Es geht dabei kein Impuls verloren und dennoch kann der AVR volle Leistung liefern. Noch etwas zu Drehgebern: es gibt ja nicht nur diese billigen mechanischen Teile oder welche mit 4000 Schritten/Umdrehung (wobei die hohe Auflösung insbesondere auch für langsam drehende Achsen sinnvoll ist und nicht zwingend ultraschnell ausgewertet werden muß), sondern auch 'schlichte' optische Geber (Bourns z.B.) mit bis zu 256 Impulsen/U die bis 3000 Upm arbeiten. Rechnet man dazu die max. Impulsfrequenz aus, kommt man auf rund 50 kHz. Nicht konstant aber eben auch möglich und auswertbar! Als Beispiel habe ich eine Routine, die einen Schrittmotor als Drehgeber auswertet, sich aber auch für einen optischen Drehgeber mit höherer Auflösung eignet: Beitrag "Schrittmotor als Drehgeber mit Dynamik, AVR" Auch hier kann man erkennen, daß eine Auswertung per PCINT eine einfache Sache ist und den µC nicht kontinuierlich auslasten muß.
@MaWin: ich wollte nur den Irrsinn aufdecken, der da heißt "und wenn das Ding mit 10000 U/sec rotiert, dann ...". So schnell blättert niemand durch LCD-Menüs. D.h. wir sind auf der selben Seite ;-)
Angehängte Dateien:
Karl schrieb: > Baut ein Arduino Shield, dass Drehgeber auswerten kann und schreibt die > Lib dazu!!! Paul B. schrieb: > Gar keine dähmliche Idee... Das Breadboard-kompatible PCB (Bild) kostet ca. 77ct bei OSH-Park. Es sind noch zwei Aux-Pins und über 600 Bytes EEPROM frei. Dazu kommen noch: * µC: 24ct * zwei 0805-Kondensatoren * Alps-Dreh-Drückgeber * Pin-Header (8 Pins) Features: ¯¯¯¯¯¯¯¯¯ * Operating voltage: 2.95 to 5.5 V * Die beiden Aux Pins sind für PWM, WS2812, ADU oder DS18B20/DHT22/... (1wire) usw. nutzbar. * Konfigurierbar (z.B. TWI-Adresse, Aux-Pin-Funktion) über USB-VCOM und EEPROM, also ohne flashen. * Ansteuerbar über UART, I²C (TWI) oder SPI (dasy chain als slave), auch der freie EEPROM-Bereich. Harald W. schrieb: > … am Drehgeber angeschlossenen Platinenbohrmaschine … Sollte wohl gehen. Ich nutze nur die µC-internen Pullups. Interesse?
:
Bearbeitet durch User
Bastler schrieb: > Und der Hersteller schreibt: 15.000 Cycles Livetime. > Also nach 3 Minuten. ... 3 Sekunden! m.n. schrieb: > bei einem AVR kann man geschickterweise beide Phasen auf einen Port > legen, wobei jede Änderung den PCINT zu dem Port auslöst. Ach? Da bin ich nun aber neugierig, wie sowas gelöst werden soll ... Was liegt denn an dem Pin an, wenn eine Phase gerade H und die andere L ist? > Aktuellen Code dazu, der das deutlich macht, finde ich gerade nicht. Was mich allerdings wiederum nicht verblüfft. m.n. schrieb: > Liest man den Text, findet man die Optionen für flankengetriggerte oder > auch Timer ISR, wobei erstere etwas schneller ist: 500 kHz zu 400 kHz. Ich kann mit dem AVR per polling Signale bis 2MHz auswerten (gut, dann macht der nicht viel anderes mehr ...). Habe ich allerdings bisher nie benötigt. Was ich allerdings bisher benötigt habe, ist Drehgeber im Multiplex abzufragen. Da fällt Entprellung und damit PCINT raus ... Für mich bedeutet die Abfrage per PCINT mehr Hardware und unberechenbare Programmverarbeitung. Nö, da polle ich lieber. Wer mit IRQ glücklich wird, soll das tun. Für mich ist ein Drehgeber kein Ereignis, worauf immer alles stehen und liegen gelassen wird um darauf zu reagieren. Da gibt es andere Ereignisse. Und wer meint, an einem Steuergerät mit mehr als 100 Drehgebern es mit der Drehzahl übertreiben zu müssen, ja, der wird eben einfach mit den Fehlern leben müssen. > Weiter unten sind ergänzende Schaltungen gezeigt, wie man unsaubere > mechanische Signale flankengetriggert auswerten kann, selbst wenn sie > Spikes im einstelligen µs-Bereich aufweisen. Also Spikes, die sogar länger andauern, als ein Phasenabschnitt!? Großartig ...! Gruß Jobst
Ok, 3Sekunden. Ich hatte U/min gelesen, vielleicht weil nicht neben einer 300.000 U/min Bohrmaschine stehen wollte. Man liest eben, was man lesen will. Der Zahnarzt bekommt so was nur per Luftlager und als Turbine zum Fliegen. Von 5kHz drehenden E-Motor-Ankerteile perforiert zu werden ist ziemlich ungesund.
Jobst M. schrieb: > Wer mit IRQ glücklich wird … Ach ja, danke, vergessen: Einer der beiden Aux-Pins kann natürlich auch als Low-Active IRQ konfiguriert werden, wenn der Drehgeber am Arduino-Shield gedreht oder gedrückt wurde oder wenn anderweitig neue Signale anliegen. Volker S. schrieb: > Danach ist aber doch gar nicht gefragt. Über den Punkt, was gefragt war, sind wir alle doch eh schon weit hinaus! Falls ich die Idee von Karl hier jedoch zu sehr in den Vordergrund stelle, bremst mich bitte aus. m.n. schrieb: > ich zahle für einen ATtiny25 17 Cent wo?
:
Bearbeitet durch User
Jobst M. schrieb: > Volker S. schrieb: >> void interrupt high_isr(void) >> { >> if (ENC_IR){ >> #ifdef ENCODER_PANASONIC >> mENC_INT_TOG_EDGE(); >> #endif >> if(ENC_DIR == ENC_DIR_UP) >> flags.encUp = 1; >> else >> flags.encDown = 1; >> mENC_IR_CLR(); >> return; >> } > > Wo werden die Flags auf eine Variable addiert? Und wo wieder zurück > gesetzt? Ich versteh die Frage nicht ganz. Stell dir einfach vor, das es davon abhängig ist, ob und in welchem Menü sich das Programm gerade befindet. Heller-dunkler, vor-zurück, langsamer-schneller, nächstes-vorheriges Menü ... Ist doch nicht Teil des Problems der Drehgeber-Auswertung.
:
Bearbeitet durch User
Jobst M. schrieb: > m.n. schrieb: >> bei einem AVR kann man geschickterweise beide Phasen auf einen Port >> legen, wobei jede Änderung den PCINT zu dem Port auslöst. > > Ach? Da bin ich nun aber neugierig, wie sowas gelöst werden soll ... > Was liegt denn an dem Pin an, wenn eine Phase gerade H und die andere L > ist? > >> Aktuellen Code dazu, der das deutlich macht, finde ich gerade nicht. > > Was mich allerdings wiederum nicht verblüfft. Und, was soll ich Dir jetzt attestieren? Dummheit, Faulheit, Ignoranz oder etwa schon beginnender MaWinismus? Die Antworten auf Deine Fragen(?) hättest Du im nachfolgenden Text finden können. Ich konnte ja nicht ahnen, daß Du damit überfordert bist. Torsten C. schrieb: > m.n. schrieb: >> ich zahle für einen ATtiny25 17 Cent > > wo? Die Quelle für 1000er Stückzahl ist derzeit versiegt; es war zu Zeiten des Eurohöhenfluges. Derzeit ist Schukat ein sicherer Lieferant zu akzeptablem Preis, den ich mir leisten kann ;-) Auf eine China-Quelle würde ich mich aber nicht einlassen wollen, egal, wie der Preis aussieht. Ein Quadraturdekoder auf dem Chip ist sicherlich eine feine Sache. Beim uralten H8/300H war schon einer vorhanden und beim STM32F4 bietet fast jeder Timer mindestens einen Kanal mit enormer Bandbreite, was einen schon fast überfordern kann: "Ich kann mich garnicht entscheiden, ist Alles so schön bunt hier" ;-)
m.n. schrieb: > "Ich kann mich garnicht entscheiden, ist > Alles so schön bunt hier" ;-) ..würde Nina Hagen sagen. MfG Paul
Lothar M. schrieb: > W.S. schrieb: >> Bei Pfuschern hingegen ist es völlig üblich, daß sie die korrekte >> Vorbehandlung ignorieren und das daraus erwachsende Fehlverhalten >> anschließend korrigieren wollen. > Ich verlagere Filterung und Entprellung gerne in die Software, weil die > so leicht anpassbar ist. Aber ich halte das nicht für Pfusch, sondern > habe die Theorie dahinter kapiert... Ja, eben. Das IST Pfusch. Fehler, die man vorn in der Signalkette gemacht hat, kann man regelmäßig nicht mehr weiter hinten ausbügeln - auch nicht mit beliebig viel Theorie. Man handelt sich dabei nur noch weitere Constraints ein. Wir hatten das hier schon unendlich oft: bei PT100-Schaltungen, bei grandiosen Software-Frequenzzählern und so weiter. Also nochmal: Zuerst die Konditionierung, also Filterung, Entprellung, Schmittriggerung oder weiß der Geier was - und erst dann die Auswertung. Und wenn man denn schon die Signale per Vorbehandlung sauber gemacht hat, dann ist Polling - um das es hier ja ging - herzlich überflüssig. Und mit den Bierchen hast du ja so Recht, manchmal seid ihr alle zusammen nur nach ner dreiviertel Flasche Rotwein auszuhalten. Prost. W.S.
O.T. W.S. schrieb: > Und mit den Bierchen hast du ja so Recht, manchmal seid ihr alle > zusammen nur nach ner dreiviertel Flasche Rotwein auszuhalten. > > Prost. Um 13:19 ?? Kein Bier vor 4. --------------------------------------------------------------------- Gestern komme ich wie jeden Tag aus der Kneipe -da tritt mich doch so ein Rindvieh auf die Pfoten... --------------------------------------------------------------------- Onkel, spendest Du für's Trinkerheim? Ach was! Die sollen zu Hause saufen. ;-) MfG Paul
W.S. schrieb: > Fehler, die man vorn in der Signalkette gemacht hat, kann man regelmäßig > nicht mehr weiter hinten ausbügeln - auch nicht mit beliebig viel > Theorie. Tja, manche lernen's nie. verdumme uns aber nicht den Rest der Bevölkerung.
W.S. schrieb: > Also nochmal: > Zuerst die Konditionierung, also Filterung, Entprellung, > Schmittriggerung oder weiß der Geier was - und erst dann die Auswertung. Welche Teile davon sind Software? ;-)
Hallo, regelmäßig, also gibt es Ausnahmen. Man muss das halt im Einzelfall entscheiden, schon mal gesehen wie ABS funktioniert. Da ist auch nix mehr mit Regelmäßig. MfG ich
Volker S. schrieb: > Ich versteh die Frage nicht ganz. Stell dir einfach vor, das es davon > abhängig ist, ob und in welchem Menü sich das Programm gerade befindet. > Heller-dunkler, vor-zurück, langsamer-schneller, nächstes-vorheriges > Menü ... > Ist doch nicht Teil des Problems der Drehgeber-Auswertung. Hmmm ... finde ich schon ... läuft bei mir auch so. Für einen Drehgeber ein Register. Die komplette Menustruktur sowie deren Aktionen liegen in einer Tabelle / Array. Wechsele ich in ein Untermenu, wird der Inhalt des Registers auf einen Stack geschoben und das Register auf 0 gesetzt. Verlasse ich den Menupunkt, wird der Wert vom Stack wieder ins Register geschrieben. Ganz kleines, kompaktes, schnelles Stück SW. Nur EINE Auswertung. Also wertest Du die Impulse dann ausserhalb des IRQs aus? An zig verschiedenen Stellen? kopfkratz Stelle ich mir ungeheuer wartungsfeindlich vor ... Okay, bei dem Vergleich bin ich dann bei 5 Zeilen Code. Eine Auswertung ist das für mich dann allerdings nicht mehr ... Gruß Jobst
In Jobst M. schrieb: > Eine Answer tung Auswertung ist das für mich dann allerdings nicht mehr ... Mir langt's ( bisher-)
Angehängte Dateien:
-
enc.png
98 KB
Klaus W. schrieb: > Hallo, > > ich habe mit Drehimpulsgebern scheinbar noch leichte > Verständnisschwierigkeiten. ... und ich auch, vielleicht kann mir mal einer kurz helfen. "Messe" einen kleinen billigen mechanischen Alps gerade mit einem akustischen Durchgangsprüfer durch. So wie ich das verstanden habe sollte an bestimmten Einrastungen konstant Kontakt zwischen Terminal C zu einem oder zu beiden Terminals A/B bestehen. Egal wie weit ich aber drehe, es es kommt niemals dazu. Nur beim Drehen selber piepts- immer. Ob nun C-A oder C-B. Ist der Impulsgeber etwa defekt? Handelt es sich um ein anderes Konstruktionsprinzip? Oder was hab ich übersehen?
Michael schrieb: >an bestimmten Einrastungen konstant Kontakt zwischen Terminal C >zu einem oder zu beiden Terminals A/B bestehen. Es werden ja vier Zustände nacheinander durchlaufen und dann beginnt das Gleiche wieder von vorne. 00 10 11 01 00 10 11 01 Vielleicht hat dein Drehgeber den Rastpunkt genau bei 00.
Michael schrieb: > Ist der Impulsgeber etwa defekt? Wahrscheinlich nicht. Ist auch keine geeignete Testmethode.
Angehängte Dateien:
-
Durchklingeln.png
220 KB
Michael schrieb: > Egal wie weit ich aber > drehe, es es kommt niemals dazu. Kommt nicht wozu? Auch "beide aus" ist möglich (blaue Linie). Das liegt an <gelber Kringel>, alles in <rosa Bereich> könnte sein.
Angehängte Dateien:
-
enc1.png
130 KB
Günter Lenz schrieb: > Es werden ja vier Zustände nacheinander durchlaufen ja und deshalb sollte sich doch ein A/B<->C Kontakt bei fixer Stellung doch nach wenigen Versuchen feststellen lassen. Jobst M. schrieb: > Wahrscheinlich nicht. Ist auch keine geeignete Testmethode. Warum sollte sich ein A/B<->C Kontakt bei fixer Stellung nicht via (akustischem) Durchgangsprüfer feststellen lassen? Mehr möchte ich ja im Augenblick noch nicht. Torsten C. schrieb: > Kommt nicht wozu? Zu irgendeinem messbaren Kontakt A/B<->C an einem fixen Rastpunkt. Also auch für A... Das muß doch in irgend einer Stellung mit C verbunden sein? Im angehängten Bild ist der Übeltäter.
Es kann ja sein, daß sich drei Zustände zwischen den Rastpunkten befinden. Auf jeden Fall müssen sich alle vier Zustände nachweisen lassen, ansonsten ist er defekt.
Angehängte Dateien:
-
Durchklingeln2.png
220 KB
Michael schrieb: > Also auch für A... Das muß doch in irgend einer Stellung mit C verbunden > sein? Ja. Aber B nicht. Vielleicht hast Du A und B vertaucht? Michael schrieb: > Im angehängten Bild ist der Übeltäter. So sieht meiner auch aus, für Drehgeber_Arduino_Shield_Idee.png^^.
:
Bearbeitet durch User
Günter Lenz schrieb: > Es kann ja sein, daß sich drei Zustände zwischen > den Rastpunkten befinden. Auf jeden Fall müssen > sich alle vier Zustände nachweisen lassen, ansonsten > ist er defekt. Also 10 Rastungen hab ich hintereinander geprüft und nie kam (außer während des Drehens) irgendein Kontakt A/B<->C zustande. Torsten C. schrieb: > Ja. Aber B nicht. Vielleicht hast Du A und B vertauscht? Alle Kombinationen sind durchgeprüft. Also ich gehe mal von einem Defekt aus und werde mir weitere Exemplare besorgen. Danke für Eure Hinweise.
Michael schrieb: > Warum sollte sich ein A/B<->C Kontakt bei fixer Stellung nicht via > (akustischem) Durchgangsprüfer feststellen lassen? Ja, geht ja offensichtlich nicht ... trotzdem bin ich mir sicher, dass er in Ordnung ist. Wenn Du etwas anderes damit vor hast, als das, wofür er gedacht ist, ist er dafür vermutlich nicht geeignet. Meine Alps Drehgeber haben auch beide Kontakte offen, wenn eingerastet. Michael schrieb: > Im angehängten Bild ist der Übeltäter. Du hast die Kamera falsch rum gehalten. Der übeltäter ist auf der anderen Seite der Kamera! Im Bild ist nur ein Drehgeber, der für das alles nichts kann und so wie er aussieht noch nicht viel erlebt hat. Gruß Jobst
Michael schrieb: > nie kam … irgendein Kontakt A/B<->C zustande. Was bedeutet Dein Schrägstrich? Falls '/' == '|' ("oder"), dann kann der Geber tatsächlich nicht "enc.png"^^ entsprechen. Entweder hast Du einen anderen Geber oder Dein Geber ist - wie Du sagst - kaputt.
Michael schrieb: > Also ich gehe mal von einem Defekt aus und werde mir weitere Exemplare > besorgen. An Deiner Stelle würde ich so richtig Theater beim Versender machen!
Jobst M. schrieb: > Der übeltäter ist auf der > anderen Seite der Kamera! Wenn Du eine plausible Erklärung liefern kannst bin ich gern der "Übeltäter". Da ich mir unsicher war hab ich hier ja auch angefragt. Torsten C. schrieb: > Was bedeutet Dein Schrägstrich? Ob A oder B- egal... Jobst M. schrieb: > An Deiner Stelle würde ich so richtig Theater beim Versender machen! Bin ich nicht der Typ zu ^^
Jobst M. schrieb: > Meine Alps Drehgeber haben auch beide Kontakte offen, wenn eingerastet. Und wie sieht bei Deinen Drehgebern das Diagramm aus? Oder welchen Typ hast Du? Ich frage, damit der geneigte Leser eine Chance hat, mal ins Datenbalatt zu schauen. @Klaus W.: Wir haben seit dem 13.07.2015 um 16:11 Uhr nichts mehr von Dir gehört. Alles klar?
:
Bearbeitet durch User
Torsten C. schrieb: > Und wie sieht bei Deinen Drehgebern das Diagramm aus? Ja Torsten, berechtigte Frage. Antwort: Unbekannt. Ist ein Teil aus der Bastelkiste und wird von mir erstmalig verwendet. Ein Diagramm für ein solches mechanisches Alps, daß bei jeder Rastung beide Kontakte offen (mit C unverbunden) zeigt hat meine bisherige Suche aber noch nicht zutage gefördert..
Michael schrieb: > Wenn Du eine plausible Erklärung liefern kannst bin ich gern der > "Übeltäter". Da ich mir unsicher war hab ich hier ja auch angefragt. Nein, Du bist auch ohne ERklärung der Übeltäter und Du wirst es vermutlich noch feststellen. Und ich habe Dir gesagt, dass Du dazu nicht die richtige Messmethode hast. Das wolltest Du nicht einsehen. Gut kann man so machen. Bringt Dich nur nicht weiter. Torsten C. schrieb: > Und wie sieht bei Deinen Drehgebern das Diagramm aus? Kann ich Dir nicht sagen, da ich nicht auf die Rastung triggern kann. Sie tun ja auch einfach das, was sie tun sollen. Torsten C. schrieb: > Oder welchen Typ hast Du? Muss ich morgen mal im Lager schauen ... Gruß Jobst
Jobst M. schrieb: > Michael schrieb: >> Wenn Du eine plausible Erklärung liefern kannst … > Nein, Du bist auch ohne ERklärung der Übeltäter … Das werden wir sehen, … Jobst M. schrieb: > Muss ich morgen mal im Lager schauen … und zwar morgen. Ich hole schon mal die Cola und die Chips raus. :-)
:
Bearbeitet durch User
Torsten C. schrieb: > … und zwar morgen. Ich hole schon mal die Cola und die Chips raus. :-) Och, weißt Du, ich muss mich nicht von Dir erpressen lassen, Du wirst es auch ohne mich merken. Ich hatte gerade noch etwas geschaut, aber das behalte ich nun für mich. Bestell neue Teile. Die sind bei Leuten, die offensichtlich keine Ahnung davon haben immer kaputt.
Jobst M. schrieb: > ich muss mich nicht von Dir erpressen lassen Welche Erpressung? Jeder zieht sich den Schuh an, der ihm paßt. :-) Also nur heiße Luft. Auch egal.
:
Bearbeitet durch User
Jobst M. schrieb: > Ich sage doch … Das habe ich gelesen. Aber: Wem sagst Du das? Michael oder mir? Meine Geber funktionieren; die habe ich am 31. Mai 2013 bei maritalogo gekauft: http://www.ebay.de/usr/maritalogo Manchmal frage ich mich, wozu ich mir das hier antue. Aber besser als RTL und VOX ist das allemal. ;-) Michael schrieb: > Ja Torsten, berechtigte Frage. > Antwort: Unbekannt. Ich befürchte, Du hattest Recht. Ich packe die Cola wieder in den Kühlschrank und Chips wieder in den Schrank und gehe ins Bett.
:
Bearbeitet durch User
Michael schrieb: > So wie ich das verstanden habe sollte an bestimmten Einrastungen > konstant Kontakt zwischen Terminal C zu einem oder zu beiden Terminals > A/B bestehen. Das hast du falsch verstanden. > Nur beim Drehen selber piepts- immer. Ob nun C-A oder C-B. Das ist doch gut. Denn der Drehencoder soll ja dazu dienen, das Drehen zu erkennen und auszuwerten. Wo der genau rastet und ob das immer die selbe Stelle ist, das ist piepschnurzegal.
:
Bearbeitet durch Moderator
Michael schrieb: > [...] nie kam (außer > während des Drehens) irgendein Kontakt A/B<->C [...] Warum sollte jeder der vier Zustände in einem Rastpunkt liegen? Wie Du ja selbst (noch nicht) gemerkt hast, kannst Du einige Zustände nur während des Drehens erreichen. Frau Werwolf sagt, das gehört so.
Torsten C. schrieb: > @Klaus W.: Wir haben seit dem 13.07.2015 um 16:11 Uhr nichts mehr von > Dir gehört. Alles klar? Jaja, ich lebe noch. Ich lese und denke mir meinen Teil.
Angehängte Dateien:
-
screenshot25.png
62 KB
Michael schrieb: > Ist der Impulsgeber etwa defekt? Handelt es sich um ein anderes > Konstruktionsprinzip? Oder was hab ich übersehen? Es gibt mindestens zwei unterschiedliche Konzepte. Das eine, welches zu deiner Abbildung passt, funktioniert ungefähr so wie ein Wechselschalter. Von einem Rastpunkt zum nächsten wechselt der Zustand der Schalter. Es würde also in jeder zweiten Stellung piepen. Hier entsteht sozusagen nur ein halber Puls pro Raste (oder eben zwei Rastpunkte für einen Puls). Das andere ist eher eine Taster Funktion. Während des Drehens wird kurz der "Taster" geschlossen. Hier piept es nur beim Drehen. Das ist wohl so bei dem Teil das du hast. Bei diesen Typen hat man dann einen Puls pro Raststellung. Die Darstellung der Signale A und B auf den Abbildungen darfst du nicht so ernst nehmen. Die sind NICHT 90° versetzt (OK bei genau einer ganz bestimmten Drehfrequenz wird's wohl so sein). Da kann man nur sehen welches Signal früher und welches Signal später kommt. Das Tastverhältnis des Signals ist bei den "Tastern" auch nicht 50% sondern eigentlich immer wesentlich kürzer. In der beigefügten Abbildung sieht man links das Wechsler- und rechts das Taster-Prinzip. Wenn man ein Oszilloskop hat, dann schaut man sich das am besten mal an, dann weiß man hinterher Bescheid ;-) <edit>Da ist es dann natürlich von Vorteil wenn man eine Entprellung mit R/C Glied hat </edit>
:
Bearbeitet durch User
Angehängte Dateien:
-
screenshot26.png
17 KB
Ok, hier noch ein Bild. Das habe ich selber mal für ein Script gezeichnet, welches ich gerade überarbeite und auch deshalb dieser Diskussion folge ;-) Hier sind die zwei Typen in unterschiedlichen Farben dargestellt. Der Rastpunkt ist nicht eingezeichnet. Die gestrichelte Linie markiert den Flankenwechsel, den man mit der Interrupt Technik auswerten kann. Grün wäre ein Signal eines Drehgebers mit gleich viel Rastpunkten wie Pulsen. (Tasterprinzip) Violett ist dann ein Drehgeber mit halb soviel Pulsen wie Rastpunkten. (Wechsler)
:
Bearbeitet durch User
Volker S. schrieb: > Grün wäre ein Signal eines Drehgebers mit gleich viel Rastpunkten wie > Pulsen. (Tasterprinzip) > > Violett ist dann ein Drehgeber mit halb soviel Pulsen wie Rastpunkten. > (Wechsler) Hast Du konkrete Beispiele für jeweils beide Varianten (Datenblätter)? Bislang ist mir noch kein Drehgeber untergekommen, bei dem nicht zwei halbwegs genau 90° phasenversetzte Rechtecksignale mit 50% Tastverhältnis herauskamen.
:
Bearbeitet durch User
Walter T. schrieb: > Hast Du konkrete Beispiele für jeweils beide Varianten? Volker S. schrieb: > Also ich habe die zufällig beide, den ALPS STEC12 und den PANASONIC > EVEQDBRL416B als alternative Bestückungsvariante auf unseren > Mikrocontroller Boards für Studenten. Walter T. schrieb: > Bislang ist mir noch kein Drehgeber untergekommen, bei dem nicht zwei > halbwegs genau 90° phasenversetzte Rechtecksignale mit 50% > Tastverhältnis herauskamen. Mir geht es genau umgekehrt ;-) Wir reden hier doch immer noch über diese Drehgeber die man mit der Hand dreht um irgendwas einzustellen, oder ? Bei Encodern auf Motorwellen oder ähnlichem sieht das natürlich anders aus. <edit> Hmmm, hast du "Datenblätter" später angefügt, oder habe ich das übersehen ? In den Datenblättern sieht das immer so aus ... </edit>
:
Bearbeitet durch User
Volker S. schrieb: > Wir reden hier doch immer noch über diese Drehgeber die man mit der Hand > dreht um irgendwas einzustellen, oder ? OK, auch die gibt es in unterschiedlichen Qualitäten. Ich nutze gerne die hier: http://www.bourns.com/pdfs/bourns_em14_brochure.pdf und für einfachere Bedieneingaben die billigen EVEP von Panasonic: http://industrial.panasonic.com/lecs/www-data/pdf/ATT0000/ATT0000CE11.pdf Beide sehen von der Charakteristik auf dem Oszilloskop nach 50%/90° aus. Aber gut zu wissen, daß das nicht allgemeingültig ist. Volker S. schrieb: > Hmmm, hast du "Datenblätter" später angefügt, oder habe ich das > übersehen ? Ja.
:
Bearbeitet durch User
Lothar M. schrieb: > Das ist doch gut. Dann ist ja gut... Immerhin, das Teil ist auch nicht allzu alt und unbenutzt. > Wo der genau rastet und ob das > immer die selbe Stelle ist, das ist piepschnurzegal. OK. In den mir bislang ersichtlichen Diagrammen mit eingezeichnetem Rastpunkt gab es dort immer zeitweise Verbindungen mit Masse (C). Überhaupt bin ich erst fälschlicherweise davon ausgegangen, daß mit dem Drehen nur ein fixer Code an den Ausgängen wechselt: Der Blick in einen Code zur Auswertung (derselbe siehe Anhang) von Beitrag "AVR: Dreh-Encoder mit Interrupts" hat mich zur gleichen Schlußfolgerung verleitet, indem dort nämlich vom Encoder ein Startzustand abgefragt wird. Volker S. schrieb: > Das andere ist eher eine Taster Funktion. Während des Drehens wird kurz > der "Taster" geschlossen. Hier piept es nur beim Drehen. Das ist wohl so > bei dem Teil das du hast. Bei diesen Typen hat man dann einen Puls pro > Raststellung. Ja wunderbar. Wenn das so ist bin ich zufrieden. Daß diese mechanischen Drehgeber für die Auswertung eine ziemliche Wissenschaft sind geht mir nun auch langsam auf. Ein Oszilloskop ist dazu auch keine schlechte Idee^^
Walter T. schrieb: > Bislang ist mir noch kein Drehgeber untergekommen, bei dem nicht zwei > halbwegs genau 90° phasenversetzte Rechtecksignale mit 50% > Tastverhältnis herauskamen. Diese billigen mechanischen Eingabeelemente mit Namen "Encoder" (um die es in diesem Thread von Anfang an gehen sollte) sind allesamt asymmetrisch. Nur industrielle Inkrementalgeber haben den schönen Quadraturverlauf aus dem (Lehr)Buch... Michael schrieb: > hat mich zur gleichen Schlußfolgerung verleitet, indem dort nämlich vom > Encoder ein Startzustand abgefragt wird. Nach dem Einschalten steht der Encoder irgendwie. Und das ist der Startzustand. Danach kommt die Impulsfolge, wenn sich der Encoder bewegt... BTW: den angehängten Code habe ich nur kurz überflogen und wegen "viel zu kompliziert und umständlich" nicht näher analysiert. Wenn ich in VHDL (das anerkanntermaßen eine eher geschwätzige Sprache ist) nur eine dreiviertel Bildschirmseite brauche, dann muss alles, was mehr braucht unnötig kompliziert sein... http://www.lothar-miller.de/s9y/categories/46-Encoder
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Nur industrielle Inkrementalgeber haben den schönen > Quadraturverlauf aus dem (Lehr)Buch... Lässt sich eingebaute Decoderhardware z.B. im XMega dann problemlos auch für die "billigen" nutzen?
Walter T. schrieb: > Beide sehen von der Charakteristik auf dem Oszilloskop nach 50%/90° aus. > > Aber gut zu wissen, daß das nicht allgemeingültig ist. Ich denke mal bei den meisten (oder allen ?) optischen wird es 50% 90° sein. Bei den Panasonic muss ich mich jetzt ein bisschen wundern. Ich habe die EVEQ anstatt der EVEP die ja im gleichen Datenblatt sind. 50% ist klar, weil es ja "Wechsler" sind. 90° Phasenverschiebung kann ich aber beim besten Willen nicht sehen. Eine Platine mit einem EVEQ liegt genau vor mir und ich mache am besten mal einen Screenshot. (Und schau noch mal genau im Datenblatt, wo der Unterschied ist)
:
Bearbeitet durch User
Michael schrieb: > Lässt sich eingebaute Decoderhardware z.B. im XMega dann problemlos auch > für die "billigen" nutzen? Normalerweise ja, denn von Hand erreicht man keine 30 Umdrehungen pro Sekunde bei 1000 Impulsen pro Umdrehung...
Michael schrieb: > Lässt sich eingebaute Decoderhardware z.B. im XMega dann problemlos auch > für die "billigen" nutzen? Grundsätzlich spielt es (bei den Eingabeteilen) ja keine Rolle, ob der Signalverlauf wie aus dem Lehrbuch aussieht. Das Tastverhältnis und die Phasenlage sind hier egal. Michael schrieb: > Der Blick in einen > Code zur Auswertung (derselbe siehe Anhang) von > Beitrag "AVR: Dreh-Encoder mit Interrupts" > hat mich zur gleichen Schlußfolgerung verleitet, indem dort nämlich vom > Encoder ein Startzustand abgefragt wird. Der Startzustand wurde möglicherweise abgefragt um nicht die erste Flanke eines "Wechler"-Typs zu verpassen. Wenn man beispielsweise nur auf eine Flanke triggert und das entsprechende Signal am Anfang High-Pegel hat, dann muss die aktive Flanke natürlich auf "fallend" stehen um den nächsten <edit>den allerersten</edit> Wechsel zu erfassen zu können. (Bei jedem IR schaltet man dann die aktive Flanke um)
:
Bearbeitet durch User
Volker S. schrieb: > Das Tastverhältnis und die > Phasenlage sind hier egal. Ich dachte eher an Störungen des Signalverlaufs wie Prellen.
Am Wochenende bin ich wieder zuhause bei meinem Oszi und schaue auch noch mal nach. Volker S. schrieb: > Das Tastverhältnis und die > Phasenlage sind hier egal. So ganz egal ist das ja nicht - immerhin hängt die Wahl des minimalen Poll-Frequenz genau davon ab, daß alle erlaubten Zustände mindestens einmal abgefragt werden. Ist einer der Zustände signifikant kürzer, weil die Phasenlage nicht mehr 90° und/oder der Tastgrad nicht mehr 50% ist, muß die Schätzung der maximalen erlaubten Drehfrequenz/minimal erlaubten Pollfrequenz angepaßt werden - offensichtlich waren da meine Schätzungen immer deutlich weniger konservativ als angenommen.
Walter T. schrieb: > Ist einer der Zustände signifikant kürzer, weil > die Phasenlage nicht mehr 90° und/oder der Tastgrad nicht mehr 50% ist, > muß die Schätzung der maximalen erlaubten Drehfrequenz/minimal erlaubten > Pollfrequenz angepaßt werden Oh, DARAN habe ich gar nicht gedacht ...
Angehängte Dateien:
-
screenshot27.png
6,7 KB
Versprochenes Beispiel eines Signalverlaufs Panasonic EVEQ mit 32 Rastpunkten (20 ms/Div)
Moderate Drehgeschwindigkeit mit ca 1/3 Umdrehung pro Sekunde...
Volker S. schrieb: > Versprochenes Beispiel eines Signalverlaufs Panasonic EVEQ mit 32 > Rastpunkten (20 ms/Div) Mit Flankenauswertung per Interrupt ist das kein Problem - auch wenn man sehr viel schneller dreht.
Lothar M. schrieb: > Moderate Drehgeschwindigkeit mit ca 1/3 Umdrehung pro Sekunde... 32 Rastpunkte sind bei diesem Typ 32 Wechsel. Sagen wir die Pulse sind so ~50ms lang, dann kommt man auf 1 Umdrehung alle 1500ms also 1,5s. -> 2/3 Umdrehungen pro Sekunde. (immer noch moderat ;-) <edit> die Dinger haben ein recht hohes Rastmoment </edit>
:
Bearbeitet durch User
m.n. schrieb: > Mit Flankenauswertung per Interrupt ist das kein Problem - auch wenn man > sehr viel schneller dreht. Vorausgesetzt, die Interrupt-Routine fragt den anderen Eingang ab, bevor der auch wechselt. Allerdings hat die Interrupt-Flanken-Auswertung einen (weiteren) entscheidenen Nachteil: Dreht man wirklich zu schnell, so daß auch der andere Eingang gewechselt hat, erfasst sie die angebliche Drehbewegung einfach falsch. Das Polling-Prinzip (oder der Timer-Interupt mit Polling) ERKENNT wenigstens, daß sie zu langsam abgefragt hat (weil ein Wechsel 00 nach 11 oder 01 nach 10 stattgefunden hat oder zurück) und kann darauf hinweisen, daß ihr die Impulsabstände zu kurz sind bzw. die Bewegung zu schnell. Nur die Dümmsten verwenden Flankeninterrupts.
Volker S. schrieb: > Sagen wir die Pulse sind so ~50ms lang, Einfach mal von steigender Flanke blau bis steigende Flanke blau gezählt: wenn die Skalierung 20ms/div ist, dann dauert da ein kompletter Zyklus ca. 90-100ms...
Lothar M. schrieb: > Volker S. schrieb: >> Sagen wir die Pulse sind so ~50ms lang, > Einfach mal von steigender Flanke blau bis steigende Flanke blau > gezählt: wenn die Skalierung 20ms/div ist, dann dauert da ein kompletter > Zyklus ca. 90-100ms... Ja, aber ein kompletter Zyklus entspricht ZWEI Rastpunkten. (oder einem negativen und einem positiven Puls)
:
Bearbeitet durch User
MaWin schrieb: > Vorausgesetzt, die Interrupt-Routine fragt den anderen Eingang ab, bevor > der auch wechselt. Jetzt machst du dich aber lächerlich ...
Angehängte Dateien:
-
Panasonic_EVEP.png
44 KB
Volker S. schrieb: > Ja, aber ein kompletter Zyklus entspricht ZWEI Rastpunkten. > (oder einem negativen und einem positiven Puls) Das sieht man am Oszi-Bild natürlich sehr, sehr schlecht. Und das Datenblatt sagt dann auch etwas Anderes als die erwähnten 32 Rastungen. Mit den dort aufgeführten 8 Zyklen pro Umdrehung ist die Drehgeschwindigkeit mit gut 1,5 U/s schon recht zackig... ;-) BTW: genau das Ding verwende ich mit Beschleunigung seit ewigen Zeiten. Es macht seine Arbeit recht gut. Ohne Beschleunigung würde man sich bei 16 Schritten pro Umdrehung zu Tode kurbeln... http://www.lothar-miller.de/s9y/categories/54-Encoder
:
Bearbeitet durch Moderator
@Lothar Eigentlich würde ich von Dir als Moderator erwarten, daß Du die Pöbeleien schreiender Kinder einfach löscht.
Lothar M. schrieb: > Das sieht man am Oszi-Bild natürlich sehr, sehr schlecht. Und das > Datenblatt sagt dann auch etwas Anderes als die erwähnten 32 > Rastungen... Einfach mal in die rechte (richtige ;-) Spalte schauen. (links P - rechts Q) Jaaaaa, besser ich hätte nochmals explizit geschrieben: "32 Rastpunkte und 16 Pulse"
:
Bearbeitet durch User
Lothar M. schrieb: > BTW: genau das Ding verwende ich mit Beschleunigung seit ewigen Zeiten. Ich verwende den (EVEQ) einfach nur, weil es den billig bei Pollin gab (75ct) als ich einen günstigen Bausatz für unsere Studierenden zusammenstellen wollte. In diesem Sinne: Lieber Pollin als Polling (ha ha ha wie schlecht ;-)
Volker S. schrieb: > In diesem Sinne: Lieber Pollin als Polling > (ha ha ha wie schlecht ;-) Na, so schlecht nun auch wieder nicht. Ein Kalauer kommt immer gelegen. Ja, manche Drehimpulsgeber reagieren ziemlich impulsiv, genau wie jene, die daran drehen. ;-) MfG Paul
Lothar M. schrieb: > W.S. schrieb: >> Also nochmal: >> Zuerst die Konditionierung, also Filterung, Entprellung, >> Schmittriggerung oder weiß der Geier was - und erst dann die Auswertung. > Welche Teile davon sind Software? ;-) Immer die hinteren. Das kannst du dir merken, denn die reale Welt ist analog, danach kommt die Digitalisierung und dann die digitale Welt inclusive Software. Jegliche Digitalisierung wandelt zeit- und amplitudendiskretes Zeug in zeit- und amplitudendiskrete Signale um - und da schlägt IMMER das Abtasttheorem zu. Also muß man vorher im analogen Bereich so konditionieren, daß man nicht in Alias hineinrennt oder sich den S/N-Abstand kaputtmacht. Jeder halbwegs vernünftige Ingenieur weiß das, bloß MaWin nicht: MaWin schrieb: > Tja, manche lernen's nie. > verdumme uns aber nicht den Rest der Bevölkerung. Warum glauben Leute wie MaWin eigentlich, daß man durch das Klopfen derartiger Sprüche mehr Recht hat als durch sachliche Argumente? Oder gar durch das verstehende Lesen dessen, was andere geschrieben haben? Anstatt ausgerechnet MIR Verdummung vorzuwerfen, sollte er besser mal den Tietze-Schenk lesen, eine alte Ausgabe reicht für MaWin völlig aus. W.S.
Wenn ein Drehgeber das macht, was Volker SchK
in screenshot27.png zeigt, ist das meiner Meinung
nach Herstellerpfusch. Der Hersteller sollte schon
90 grad Versatz anstreben, zu mindest 45 grad.
Rastpunkt auf einer Flanke ist nach meiner Meinung
auch Herstellerpfusch. Am besten man nimmt Drehgeber
die Optisch abgetastet werden, die haben keinen Verschleiß
und prellen nicht.
MaWin schrieb:
>Nur die Dümmsten verwenden Flankeninterrupts.
Das kann man so pauschal nicht sagen.
Es kommt darauf an was man machen will.
Wenn man das drehen einer Motorwelle zählen will,
und das die Hauptaufgabe des Programms ist,
würde ich Polling verwenden, wenn das Programm
zum Beispiel die Frequenz eines Oszillators in
einen Kurzwellenempfänger überwacht,
würde ich Flankeninterrupt verwenden. Da braucht sich
das Programm nicht dauernd mit dem Drehgeber beschäftigen,
nur dann wenn der Benutzer am Knopf dreht.
Michael schrieb: > So wie ich das verstanden habe > sollte an bestimmten Einrastungen konstant Kontakt zwischen Terminal C > zu einem oder zu beiden Terminals A/B bestehen. Egal wie weit ich aber > drehe, es es kommt niemals dazu. Dann ist dir wohl mit der Pinbelegung etwas durcheinander gekommen.
W.S. schrieb: > sachliche Argumente Die sachlichen Argumente wurden alle genannt. Es ist die Borniertheit, der Falschgläubigen, die nicht merken, daß ihre Pseudo-Argumente "da wird der Prozessor nicht so belastet wenn keiner am Knopf dreht" hirnrissig sind. Der wahre Hintergrund lautet wohl: Sie haben noch immer nicht verstanden, WO die Probleme eigentlich herkommen, sie wundern sich nur, daß selbst manche kommerziellen Geräte so merkwürdig auf Drehgeber reagieren.
Wolfgang schrieb: > Dann ist dir wohl mit der Pinbelegung etwas durcheinander gekommen Nein, aber am Verständnis^^
Günter Lenz schrieb: > Wenn ein Drehgeber das macht, was Volker SchK > in screenshot27.png zeigt, ist das meiner Meinung > nach Herstellerpfusch. Der Hersteller sollte schon > 90 grad Versatz anstreben, zu mindest 45 grad. Ich bin fest davon überzeugt, daß das gezeigte Verhalten ein Artefakt der Meßmethode ist. Die 90° Phasenversatz gelten unter der Voraussetzung einer konstanten Winkelgeschwindigkeit. Die ist aber bei einem Drehgeber mit Rastung (gar einer so harten wie der Panasonic hat) und beim Drehen von Hand gerade nicht gegeben. Statt dessen kommt der Drehgeber nur langsam aus der alten Rastposition um dann schnell zur nächsten zu springen. Wenn man die Rastung abschalten oder ausbauen könnte (geht aber nicht, zumindest nicht zerstörungsfrei) dann würde man das normale Verhalten sehen können.
Thread beobachten
Seitenaufteilung abschalten
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.