Ich möchte mehrere (3 bis 4) Quadratur Encoder auswerten. Inkrementelle Drehgeber als Bedienelemente; also kein Motor. Nun kann man entweder spezielle Hardwarebausteine verwenden die schwer erhältlich sind, digitale Logik ICs verwenden oder die Dekodierung mit einem Mikrocontroller in Hardware oder Software machen. Wie viele Quadrature Encoder hat ein Mikrocontroller hardwaremäßig maximal ? Wie kann ich 3 bis 4 Drehgeber mit einem Mikrocontroller auswerten und welcher Mikrocontrollertyp z.B. aus der AVR-Familie sollte es minimal sein ? Alle Drehgeber sollen gleichzeitig genutzt werden können, nicht nacheinander.
Hans-werner M. schrieb: > Wie viele Quadrature Encoder hat ein Mikrocontroller hardwaremäßig > maximal ? Keine Ahnung. Aber wenn dein Geber nicht mehr als, sagen wir mal, 1000 Rastpunkte pro Umdrehung macht, kannst du soviele anschliessen und per Software auswerten, wie du Pins frei hast. Das ist für einen µC eine leichte Übung. Gib ihm noch was zu lesen, sonst langweilt er sich.
soweit ich weiss hat keiner Atmel soetwas, in software kann man soviel machen wie rechenleistung verfügbar. Dafür müsste man aber genau wissen mit wievielen impulsen pro s zu rechenen ist.
Hi
>soweit ich weiss hat keiner Atmel soetwas
ATXMega vergessen?
MfG Spess
>ATXMega vergessen? Der stirbt doch so in ein zwei Jahren weil die viel billigeren und leistungsfähigeren ARMs ihm das Wasser abgraben.
Hi >Der stirbt doch so in ein zwei Jahren weil >die viel billigeren und leistungsfähigeren ARMs >ihm das Wasser abgraben. Ändert aber nichts daran, das die Aussage 'soweit ich weiss hat keiner Atmel soetwas' falsch ist. MfG Spess
Hans-werner M. schrieb: > Ich möchte mehrere (3 bis 4) Quadratur Encoder auswerten. > Inkrementelle Drehgeber als Bedienelemente; Kein Problem, hänge die 4 Encoder an einen Port mit Pin-Change-Interrupt. Eine codesparende Auswerteroutine mit Entprellung findest Du hier. Hans-werner M. schrieb: > Alle Drehgeber sollen gleichzeitig genutzt werden können, nicht > nacheinander. Wie machst Du denn das, 4 Encoder gleichzeitig (Hände + Füße)? Peter
Bei mehreren Encodern gibts nur eine Software-Lösung. Hab ein Gerät am Laufen, da werden acht Encoder (Drehen geschieht per Hand) per Software behandelt, ein Encoder (512 Striche auf dem Umfang, schnelle Eingabe durch ruckartiges bewegen über einen großen Bereich) wird durch die Hardware des PIC eingelesen.
> Wie viele Quadrature Encoder hat ein Mikrocontroller > hardwaremäßig maximal ? 0 > Kein Problem, hänge die 4 Encoder an einen Port mit > Pin-Change-Interrupt. Autsch. Noch jemand der Incrementaldecoder nicht verstanden hat. > Wie kann ich 3 bis 4 Drehgeber mit einem Mikrocontroller auswerten Mit einem geeigneten programm > welcher Mikrocontrollertyp z.B. aus der AVR-Familie sollte es > minimal sein ? Einer mit zumindest 8 Eingängen. PINB // bit 0 (PB0) und bit 1 (PB1) sind Quadratureingaenge des ersten Encoders, bit 2 und 3 des zweiten Encoders, bit 4 und 5 des dritten Encoders und bit 6 und 7 des vierten Encoders int8_t table[4][4]={{0,1,-1,0},{-1,0,0,1},{1,0,0,-1},{0,-1,1,0}}; int position[4]={0,0,0,0}; // zaehlen wir mal die absolute Position int8_tnew_quadrature_value, last_quadrature_value=PINB; Folgenden Code ausreichend oft wiederholen (in der Programm Hauptscheife oder einer Zeitgeber gesteuerten Interrupt Routine): new_quadrature_value=PINB; for(i=0;i<4;i++) position[i]+=table[(last_quadrature_value>>(2*i))&3][(new_quadrature_val ue>>(2*i))&3]; last_quadrature_value=new_quadrature_value; und voilá sind alle 4 Positionswerte in position[0] bis position[3] passend hochgezählt/runtergezählt. Warum nicht Flanken ? Klar wegen dem möglichen prellen: http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29
Die TMS320F28er sollten sowas haben. In Hardware, eher gedacht um ein Motörchen auch innerhalb einer Umdrehung exakt auf Trab zu halten. Für manuelle Drehgeber braucht es die Hardware eher nicht.
Hans-werner M. schrieb: > Nun kann man entweder spezielle Hardwarebausteine verwenden die schwer > erhältlich sind FPGAs hast du noch vergessen. Gut zu bekommen und du darfst auch mal ein bisschen schneller drehen.
./. schrieb: > Datum: 24.02.2012 00:23 > Die TMS320F28er sollten sowas haben. > In Hardware, eher gedacht um ein Motörchen auch innerhalb > einer Umdrehung exakt auf Trab zu halten. Die wollte ich auch gerade vorschlagen. Wobei die LPCs auch teilweise einen haben.Evtl gibts sogar welche mit 2. Und Bastlerfreundlicher wie die TIs finde ich sie auch. Gruß
SNR schrieb: > Und Bastlerfreundlicher wie die TIs finde ich sie auch. Das nimmt sich glaub ich nichts.
MaWin schrieb: >> Kein Problem, hänge die 4 Encoder an einen Port mit >> Pin-Change-Interrupt. > Autsch. > Noch jemand der Incrementaldecoder nicht verstanden hat. ?? Ein Port der meisten 8-Bit MCUs (abgesehen von sowas wie z.B. bei einigen Tinys) besteht aus 8 Pins. 4 x 2 = 8. Das klappt also. Und entspricht genau dem, was du weiter unter sagst: MaWin schrieb: > Einer mit zumindest 8 Eingängen. Gruss Uwe
Hi, der Toshiba TMPM370 hat zwei in Hardware und würde den Rest in Software schaffen. Ist aber für rein diese Auswertung überdimensioniert. Was willst Du noch machen im System? Den die vier Encoder auswerten ist ja nicht das endgültige Ziel, oder?
STM32! gibts mit vielen Eingängen (auch Encodereingängen, die Timerhardware kann einiges bei den STM's)
Hans-werner M. schrieb: > ... und welcher Mikrocontrollertyp z.B. aus der AVR-Familie sollte es > minimal sein ? z.B. ein ATmega48/88/168. Je nachdem, wie groß dein Code wird und was der µC sonst noch alles bedienen muss. Gruss Uwe
Uwe N. schrieb: > MaWin schrieb: >>> Kein Problem, hänge die 4 Encoder an einen Port mit >>> Pin-Change-Interrupt. >> Autsch. >> Noch jemand der Incrementaldecoder nicht verstanden hat. > ?? > Ein Port der meisten 8-Bit MCUs (abgesehen von sowas wie z.B. bei > einigen Tinys) besteht aus 8 Pins. > 4 x 2 = 8. > Das klappt also. Und entspricht genau dem, was du weiter unter sagst: > MaWin schrieb: >> Einer mit zumindest 8 Eingängen. > Gruss Uwe Ich denke das hat sich auf den Interrupt bezogen.
...schau dir mal den BCR2000 an :-) Ist auch nur ein uC, der das nebenbei macht, macht auch noch USB, MIDI etc.... intern sind 74164iger Schieberegister die alle Encoder abfragen... JJ
>Kein Problem, hänge die 4 Encoder an einen Port mit >Pin-Change-Interrupt. Stellt mich an den Pranger, aber Pin-Change-Interrupt halt ich für dieses Problemchen den ganz falschen Ansatz. Die Encoder sind nix anderes als Taster, die in Abhängigkeit voneinander schalten. Die sollte man auch als Taster behandeln. Ist wesentlich einfacher und betriebssicherer.
Olle Kamelle schrieb: > Ich denke das hat sich auf den Interrupt bezogen. Wie meinst du das ? Der von mir vorgeschlagene Typ kann auf fast allen Pins ein Pin Change Interrupt auslösen. Siehe DB. chick schrieb: > Die Encoder sind nix anderes als Taster, die in Abhängigkeit voneinander > schalten. Die sollte man auch als Taster behandeln. Ist wesentlich > einfacher und betriebssicherer. Das würde ja bedeuten, das man sämtliche (hier 8) Pins gepollt abfragen muss. Wenn der µC sonst nix zu tun geht es vielleicht. Aber elegant ist es sicher nicht und ob es sicher ist ... Gruss Uwe
Uwe N. schrieb: > Das würde ja bedeuten, das man sämtliche (hier 8) Pins gepollt abfragen > muss. ja und das macht auch sinn. Denn wenn deine eingänge prellen dann wird deine ISR nicht fertig und der Rest vom PRogramm steht. Beim pollen hast du ein definiertes zeitverhalten.
Peter II schrieb: > Beim pollen hast du ein definiertes zeitverhalten. Aber hier prellt es auch. Das muss hier genauso gefiltert werden. Und ein definiertes Zeitverhalten geht auch mit PC_INT. Ich finde es halt ineffizient, die ganze Zeit Pins zu pollen, wenn man Änderungen per Hardware erfassen kann.
Uwe N. schrieb: > Und ein definiertes Zeitverhalten geht auch mit PC_INT ebend nicht. Wenn sich ständig ein pin änder weil der encoder zwischen 2 zuständen wackelt. Dann geht nichts mehr in deinem Programm.
Jedem seine Meinung. Es gibt immer veschieden Wege zum Glück. Pollen mit definiertem Zeitverhalten ist sehr effizient, sicher und paßt gut in eine Main, ohne Schnörkel.
chick schrieb: > Jedem seine Meinung. Es gibt immer veschieden Wege zum Glück. Richtig. Hans Werner wollte schließlich nur wissen, ob ein AVR dafür geeignet ist. Die Antwort ist Ja (da sind wir uns wohl einig), der Rest ist dann Geschmackssache.
ebendt Wer es ganz einfach liebt: ein RX62N hat vier Quadratureingänge per Hardware. Kanäle MTU1, MTU2, MTU7, MTU8 :-)
Peter II schrieb: > Uwe N. schrieb: >> Und ein definiertes Zeitverhalten geht auch mit PC_INT > ebend nicht. Wenn sich ständig ein pin änder weil der encoder zwischen 2 > zuständen wackelt. Dann geht nichts mehr in deinem Programm. Man kann vieles erzählen, wenn der Tag lang ist, aber hast Du sowas schonmal praktisch erlebt? Hohe Frequenzen sind nur mit optischen Encodern ohne Rastung und mit hoher Schrittzahl möglich. Die könnten dann auch manchmal durch Vibrationen ständig pulsen. Ein Kontaktencoder kann das aber nicht, der ist viel zu träge. Ein Encoder mit Kontakten prellt langsam genug, daß der AVR noch gemütlich Däumchen drehen kann. Bei den alten AVRs ohne PCINT habe ich auch im Timer (1ms) gepollt. Bei den neuen belastet PCINT die CPU weniger. Peter
Uwe N. schrieb: > Ich finde es halt ineffizient, die ganze Zeit Pins zu pollen, wenn man > Änderungen per Hardware erfassen kann. Mach dir nicht ins Hemd. Kein Mensch kann einen normalen Encoder mit einer Handvoll Rastpunken pro Umdrehnung so schnell drehen, dass man die Pollfrequenz exzessiv hochdrehen müsste. Und das was man dazu braucht bewegt sich im Bereich von weniger als 1% Rechenzeit. Also für die Effizienz völlig uninteressant. Sind die Encoder dann noch von dem Typ, die zusätzlich einen Druck-Taster eingebaut haben, dann geht dessen Auswertung innerhalb derselben ISR gleich nebenbei mit.
Karl Heinz Buchegger schrieb: > Mach dir nicht ins Hemd. Aus dem Alter bin ich raus, Karl Heinz. Ich sagte nicht, das mein Ansatz der beste ist. Ich sagte "Ich finde ..." und nicht "Das ist ...".
> Aber hier prellt es auch. Das muss hier genauso gefiltert werden. [x] Du hast was prinzipielles beim Entprellen nicht verstanden. > Jedem seine Meinung. Es gibt immer veschieden Wege zum Glück. Der Weg, der zuverlässig funktioniert, und der Weg, bei dem es ewig beim rumprobieren bleibt und der nur Probleme macht. > aber hast Du sowas schonmal praktisch erlebt Natürlich. Z.B. wenn UKW in eine aktuell auf Kippe stehende Leitung einkoppelt, besonders beliebt bei optischen Lichtschranken-Drehencodern.
Ich muss hier nochmal einhaken: Der oben genannte Einwand gegen die Interrupts beziehen sich auf die Prellerei oder geht es eher um einen definierten Abtastpunkt? Ich frage nämlich, weil ich hier einen optischen Encoder habe, ohne Rastung, der 2000 Schritte pro Umdrehung hat. Der wird in unregelmäßigen Zeitpunkten unterschiedlich schnell gedreht. Ist auch hier das Pollen die bessere Vorgehensweise? Ich müsste unter Umständen ganz schön häufig pollen. Angenommen der Encoder wird 5 Mal pro Sekunde gedreht -> 5*2000 Schritte/s =10000 steps/s. Wie häufig müsste ich nun Abtasten, würde 10000 Mal/s reichen, oder wäre eine Überabtastung sinnvoll? Muss ich gar das Abtasttheorem berücksichtigen (habe ich bei digitalen Signalen zwar noch nie gehört, aber bin noch recht frisch in der Materie...) Danke & schöne Grüße
Die Variante einen Encoder per Interrupt auszuwerten ist sogar so schlecht, dass es dafür ein ganzes Kapitel im Artikel gibt: http://www.mikrocontroller.net/articles/Drehgeber#Warum_Sparvarianten_nicht_gut_sind
Simon K. schrieb: > Die Variante einen Encoder per Interrupt auszuwerten ist sogar so > schlecht, dass es dafür ein ganzes Kapitel im Artikel gibt: Und was wäre das Internet, wenn es nicht auch ein ganzes Kapitel darüber gäbe, wo genau das Gegenteil beschrieben wird: http://www.mino-elektronik.de/mt12_iic/mt12_iic.htm Zusätzlich läßt sich an OC0B (PD5) ein 400kHz Signal ausgeben, mit dem man die Signale für INT0 und INT1 mittels 2 x 74HCT74 extern synchronisieren kann (sofern überhaupt notwendig). Ein internes Polling ist damit überflüssig. Dennoch kann die max. Zählfrequenz von 100kHz erreicht werden, was mit Polling garnicht möglich wäre.
@ m.n. (Gast) >Und was wäre das Internet, wenn es nicht auch ein ganzes Kapitel darüber >gäbe, wo genau das Gegenteil beschrieben wird: >http://www.mino-elektronik.de/mt12_iic/mt12_iic.htm Ach, und nur weil das im Internet irgendwie irgendwo steht, stimmt das auch? Wo bleibt a) die Erklärung und b) der Beweis? >Zusätzlich läßt sich an OC0B (PD5) ein 400kHz Signal ausgeben, mit dem >man die Signale für INT0 und INT1 mittels 2 x 74HCT74 extern >synchronisieren kann (sofern überhaupt notwendig). Ein internes Polling >ist damit überflüssig. Dennoch kann die max. Zählfrequenz von 100kHz >erreicht werden, was mit Polling garnicht möglich wäre. Aber sicher. Denkst du, bei 100KHz ist ein Interrupt schneller und effizienter als Polling? Kaum. Und warum diskutieren wir den Käse schon wieder? Ich dachte mit dem Artikel Drehgeber wäre das ein für alle mal geklärt. MFG Falk
m.n. schrieb: > Simon K. schrieb: >> Die Variante einen Encoder per Interrupt auszuwerten ist sogar so >> schlecht, dass es dafür ein ganzes Kapitel im Artikel gibt: > > Und was wäre das Internet, wenn es nicht auch ein ganzes Kapitel darüber > gäbe, wo genau das Gegenteil beschrieben wird: > http://www.mino-elektronik.de/mt12_iic/mt12_iic.htm Im Zweifelsfall trau ich PeDa's Code hier auf µC.net mehr über den Weg als irgendwelchem Code auf irgendwelchen Seiten, die ich nicht kenne. Von PeDa weiß ich, dass er immer gute Lösungen hat, die astrein die in sie gestellten Anforderungen problemlos erfüllen. Spannend wird es erst dann, wenn die Anforderungen so sind, dass sein Code nicht mehr mitkommt. Aber meistens hat er genug Reserve eingebaut, so dass man die Grenzen weit hinausschieben kann.
Ich meine, der STM32 kann das auch. Ich habe mal was im Datenblatt gelesen, dass Encoder-Eingänge gehen. Ich weiß jetzt aber nicht genau ob auch 4 Stück gehen. Musst Du mal Lesen im Datasheet. Infos zum STM32 hier im Artikel STM32.
Karl Heinz Buchegger schrieb: > Im Zweifelsfall trau ich PeDa's Code hier auf µC.net mehr über den Weg > als irgendwelchem Code auf irgendwelchen Seiten, die ich nicht kenne. Das steht Dir natürlich frei. Meinen Code kennst Du ja auch nicht. Meine Lösung muß in der Praxis funktionieren und nicht, weil er in einer 'Bibel' steht.
m.n. schrieb: > Meine Lösung muß in der Praxis funktionieren und nicht und das ist meist das Problem, du kannst nur dinge testen und sehen ob es geht. Aber hast du auch mit Drehgeben getestet der 3 Jahre alt ist und prellt? Mir ist es zumindest lieber wenn der code bewiesenermaßen fehlerfrei mit jeden Signal zurecht kommt, als in der Praxis einfach mal zu testen ob es geht.
@ Peter II (Gast) >> Meine Lösung muß in der Praxis funktionieren und nicht "funktionieren . . . " >und das ist meist das Problem, du kannst nur dinge testen und sehen ob >es geht. Das ist kein Testen. >Aber hast du auch mit Drehgeben getestet der 3 Jahre alt ist >und prellt? Eben das machen die Wenigsten, weil es bisweilen gar nicht so einfach ist, nachweislich und reproduzierbar defektes Verhalten nachzustellen. >Mir ist es zumindest lieber wenn der code bewiesenermaßen fehlerfrei mit >jeden Signal zurecht kommt, als in der Praxis einfach mal zu testen ob >es geht. Das ist KEIN Test. Einfachmal zusammenbauen und wenn es geht ist es "getestet". Da schießt man sich oft selber ins KNie, weil der Prototyp keine Worst Case Bedingungen sieht, wie prellende Kontakte, tiefe Temperaturen, maximal ungüstige Tolaranzen von Bauteilparametern, Versorgungsspannung etc. Ein Test, der den Namen verdient, versorgt das Prüfobjekt mit NACHWEISLICH gestörten Signalen so stark wie nur eben möglich. Wenn das Prüfobjekt besteht, DANN kann man von einer getesteten Lösung sprechen. MfG Falk
Peter II schrieb: > Aber hast du auch mit Drehgeben getestet der 3 Jahre alt ist > und prellt? Ja das habe ich, immer und immer wieder! Wenn es ausreicht, bin ich auch ein Freund von Polling, aber ein 'Feind' derer, die dies dogmatisch als einzig geltende Lösung propagieren. Siehe hier: Beitrag "Re: Decodierung von 6 Quadratur(Drehgerber)Signalen - extern zur Entlastung des PIC"
Die TPU vom MC68332 konnte sowas. Die gibt es wohl auch noch größer und Leistungsfähiger (eTPU) im MCF523X. Aber ich denke auch nen kleines älteres FPGA ist wohl moderner und billiger.
Karl Heinz Buchegger schrieb: >> http://www.mino-elektronik.de/mt12_iic/mt12_iic.htm > > Im Zweifelsfall trau ich PeDa's Code hier auf µC.net mehr über den Weg > als irgendwelchem Code auf irgendwelchen Seiten, die ich nicht kenne. Ich habe mir obigen Link zwar nur flüchtig angesehen, aber dort geht es um die Dekodierung von optischen Drehgebern. Die erfolgt analog, da man dann mit einem echten sin/cos Signal eine wesentlich höhere Auflösung erreichen kann. Eine solche Dekodierung hat mit der Dekodierung von normalen Drehgebern, bei denen üblicherweise Rechtecksignale herauskommen, nichts zu tun. Deshalb sind auch die Programme nicht vergleichbar. Gruss Harald
m.n. schrieb: > Simon K. schrieb: >> Die Variante einen Encoder per Interrupt auszuwerten ist sogar so >> schlecht, dass es dafür ein ganzes Kapitel im Artikel gibt: > > Und was wäre das Internet, wenn es nicht auch ein ganzes Kapitel darüber > gäbe, wo genau das Gegenteil beschrieben wird: > http://www.mino-elektronik.de/mt12_iic/mt12_iic.htm Deinem Nick nach würde ich ja mal darauf tippen, dass das deine Seite ist. Sich selbst als Quelle anzuführen kommt immer gut.
Noch mal eine Frage von mir wegen optischer Encoder. Ihr habt oben gesagt, daß die im Vergleich zu mechanischen z.B. durch Vibrationen schneller Prellen und auch kürzerere Zeit als eine 'Feder'. Würde es da nicht zumindestens die Gefahr geben, daß bei allgemein viel Interrupt Last ein Flankenwechsel kurz vor der letzten Flanke abgearbeitet wird, somit falschen Stand hat und die letzte Flanke gar nicht als irq gelatcht wird? Dann verliert man doch den Zählimpuls? Theroetisch find ich das zumindestens eine potentielle Gefahr
...oder eigentlich kann das doch auch bei nem mechanischen passieren. Dann wäre wenig irq aufkommen einzuhalten wenn man es nicht pollen sondern übber pin change macht.
Autor: Encoder (Gast) Datum: 16.04.2012 13:42 fragte, wie er seinen optischen Drehgeber auswerten könnte und wie er geschickterweise die Erfassung erledigt. Daraufhin kam die Warnung, dies bloß nicht per Interrupt zu machen, dem ich widersprochen habe. Harald Wilhelms schrieb: > Ich habe mir obigen Link zwar nur flüchtig angesehen, aber dort > geht es um die Dekodierung von optischen Drehgebern. Die erfolgt > analog, da man dann mit einem echten sin/cos Signal eine wesentlich > höhere Auflösung erreichen kann. Eine solche Dekodierung hat mit > der Dekodierung von normalen Drehgebern, bei denen üblicherweise > Rechtecksignale herauskommen, nichts zu tun. Doch, da die sin/cos-Auswertung 'nur' eine ergänzende Auswertung der Grundschwingungen ist. Optische Geber prellen nicht, können aber sehr hohe Frequenzen erzeugen, gerade wenn sie manuell bedient werden. Ein MT25-Taster (Heidenhain) zum Beispiel liefert senkrecht montiert und per Rückstellfeder beschleunigt locker 50kHz Signale. Bei 4-fach Abtastung müßte ein Polling der Signale mit >200kHz passieren, um keinen Schritt zu verlieren. Anstatt den µC damit deutlich zu belasten ist es geschickter, die Auswertung per Interrupt zu machen. Bei einem opt. Drehgeber können ebenfalls hohe Ausgangsfrequenzen auftreten. Wenn ein Schrittverlust nicht toleriert werden kann, muß die Auswerteschaltung für deutlich höhere Singanlfrequenzen ausgelegt sein. Das geht am besten per Interrupt, wenn in Ruhezeiten noch Prozessorleistung übrig bleiben soll.
Jetzt hast du aber nichts dazu gesagt, wie hoch die Wahrscheinlichkeit sein mag, einen Schritt zu verlieren wenn man bei kurzen Prellen kurz vor Ende den irq bedient und dann noch nicht wieder frei hat wenns aufhört zu prellen. Das beschäftigt mich grad ziemlich und ich würde mich über Meinungen freuen.
Hans-werner M. schrieb: > Wie kann ich 3 bis 4 Drehgeber mit einem Mikrocontroller auswerten Die Diskussion ist zwar müßig da sich der Eröffner nicht dran beteiligt, meine Antwort lautet aber keiner. Ohne Information wie schnell die Encoder ihre Daten ausgeben und ob simultan ist eine Antwort schlecht möglich. Langsam drehende geht in Software (s.o), bei schnell drehenden nimmt man halt mehrere "Einzeller" und fragt diese per I2C/SPI ab.
@ Der Rächer der Transistormorde (Gast) >> Wie kann ich 3 bis 4 Drehgeber mit einem Mikrocontroller auswerten >Die Diskussion ist zwar müßig da sich der Eröffner nicht dran beteiligt, >meine Antwort lautet aber keiner. Worst Case ^2. >Ohne Information wie schnell die Encoder ihre Daten ausgeben und ob >simultan ist eine Antwort schlecht möglich. "Inkrementelle Drehgeber als Bedienelemente; also kein Motor." Wenn gleich das keine technisch präzise Aussage ist, kann man schon eine Empfehlung abgeben. MfG Falk
Okay. Es gibt also verschiedene Meinungen, ich versuche dahinter zu steigen. Jetzt ist aber das praktische an dem STM32, dass dieser eben schon einen Encoder Eingang besitzt. Dieser wertet in Hardware die Flanken und auf dem anderen Signal die Pegel aus, wenn ich das richtig verstanden habe. Daraufhin inkrementiert/dekrementiert er einen Zähler. Wäre dieser Eingang dann z.B. für prellende Encoder überhaupt geeignet? Weil den Kern belastet das ja wohl nicht? Schöne Grüße
db schrieb: > Weil den Kern belastet das ja wohl nicht? Selbst wenn er prellt, dann wohl nur der Eingang, der grade auf Kippe steht, der um 90 Grad verschobene wohl eher weniger? In dem Fall wäre prellen kein Problem, der Wert würde nur um 1 Einheit hin und her schwanken.
@ m.n. (Gast) >geschickterweise die Erfassung erledigt. Daraufhin kam die Warnung, dies >bloß nicht per Interrupt zu machen, dem ich widersprochen habe. Interrupt ist schon richtig, aber bitteschön TIMER-Interrupt. >Grundschwingungen ist. Optische Geber prellen nicht, können aber sehr >hohe Frequenzen erzeugen, gerade wenn sie manuell bedient werden. Was nahezu das gleiche ist. >Ein MT25-Taster (Heidenhain) zum Beispiel Ist auf der Homepage nicht auffindbar. >liefert senkrecht montiert und >per Rückstellfeder beschleunigt locker 50kHz Signale. Bei 4-fach >Abtastung müßte ein Polling der Signale mit >200kHz passieren, um keinen >Schritt zu verlieren. Anstatt den µC damit deutlich zu belasten ist es >geschickter, die Auswertung per Interrupt zu machen. Bei 50 kHz muss der mindestens genausoviel arbeiten. >Bei einem opt. Drehgeber können ebenfalls hohe Ausgangsfrequenzen >auftreten. Wenn ein Schrittverlust nicht toleriert werden kann, muß die >Auswerteschaltung für deutlich höhere Singanlfrequenzen ausgelegt sein. Ach was? >Das geht am besten per Interrupt, wenn in Ruhezeiten noch >Prozessorleistung übrig bleiben soll. Nö. Von dauernden wiederholen wird das auch nicht besser. Und ein "polling" per Timerinterrupt ist vor allem deterministisch, da kann man problemlos noch sehr viele Sachen deterministisch nebenbei mache. Pin Change/Flankeninterrupt ist NICHT deterministisch und kann burstartig die CPU nahezu lahmlegen. MFG Falk
Bei Encodern mit ABZ-signalen braucht man, um die Vorwärts-/Rückwärts Richtung zu erkennen, einen Richtungsdiskriminator und danach kann Vor-/Rückwärts gezählt werden. Einige Positionssteller liefern gleich Vor-/Rückwärtszählausgänge ( z.B. iC-MA: http://www.ichaus.de/MA_datasheet_de ). Die Software muss so schnell sein, um die Richtung der vier AB-Eingänge zu dekodieren und danach zu zählen. Reicht die Geschwindigkeit nicht, so muss eine Hardware-Lösung her. Hier gibt es einen Applikationsbericht in Deutsch: http://www.ichaus.de/whitepapers . Man kann auch vier iC-MA mit 8-Bit Auflösung hintereinander schalten und seriell analog auslesen und mit A/D-Wandler im Mikro auslesen. Falls 8-Bit nicht ausreichen wirds aufwendiger.
Horst H. schrieb: > Bei Encodern mit ABZ-signalen braucht man, um die Vorwärts-/Rückwärts > Richtung zu erkennen, einen Richtungsdiskriminator und danach kann > Vor-/Rückwärts gezählt werden. Wenn ich unter "ABZ-Signal" das Gleiche wie du verstehst, bezweifle ich diese pauschale Aussage stark.
also: Ein "echter" Drehgeber (also nicht so ein Spielzeug mit 20 Rastungen / r) mit vermutlich differenziellen Ausgangssignalen prellt nicht! Da ist KEIN mechanischer Schalter drin. Es kann zu hohen Frequenzen kommen wenn der Geber direkt um eine Flanke "herumvibriert". Und das kann beim pollen schnell zum Problem führen. 2 Interupts, abhängig von der aktuellen Signalkombination, muss jeweils die negative oder die positive Flanke INT auslösen. Ein entprellen wie bei einem Taster ist bescheuert, man kann bei einem Drehgeber doch nicht einfach die Pulse wegfiltern. Aber alles spekulieren hilft nichts, da wir nicht mal wissen welches Ausgangssignal der Drehgeber hat. Haben wir eine oder zwei Signalspuren? Ist es evtl. sogar doch ein mechanisches Exemplar das dann doch prellt? Will der TO 2- oder 4-fach Auswertung (was den Namen des Themas erklären würde)? Und nicht ganz unwichtig: Mit welcher Frequenz werden die Pulse erwartet? Es soll eine Handbedienung werden. Ist es dann erlaubt dass einige Pulse flöten gehen? Mit den aktuell vorliegenden Daten kann man keine optimale Lösung erarbeiten.
> Ein "echter" Drehgeber (also nicht so ein Spielzeug mit 20 Rastungen / > r) mit vermutlich differenziellen Ausgangssignalen prellt nicht! > Da ist KEIN mechanischer Schalter drin. Falschaussage. Natürlich können auch nicht-mechanische Drehgeber Impulse auslösen, man nennt es dann flattern statt prellen, ausgelöst durch Vibration oder Einstreuung. > Es kann zu hohen Frequenzen kommen wenn der Geber direkt um eine Flanke > "herumvibriert". Und das kann beim pollen schnell zum Problem führen. Falschaussage. Gerade das Polling-Verfahren hat keinerlei Probleme mit prellenden oder flatternden Eingangssignalen. > 2 Interupts, abhängig von der aktuellen Signalkombination, muss jeweils > die negative oder die positive Flanke INT auslösen. Schlechte Lösung. Da beim prellen/flattern nicht vorhergesehen werden kann, mit welcher Frequenz die Impulse auftreten, führt das bei hoher Frequenz zu einer Überlastung des Prozessors (Interrupt direkt nach Interrupt oder sogar währenddessen) und das System kann seine ordnungsgemässe Tätigkeit nicht mehr ausführen weil es nur mit der Bearbeitung der Interrupts beschäftigt ist. > Ein entprellen wie bei einem Taster ist bescheuert, man kann bei einem > Drehgeber doch nicht einfach die Pulse wegfiltern. Falschaussage. Wenn man die maximale Drehzahl des Drehgebers kennt, kann man sehr wohl so langsam abtasten, daß nur diese Geschwindigkeit maximal erfasst wird und schnellere Impulse nicht gezählt werden - denn es waren unplausible Fehlimpulse. Es ist wirklich megapeinlich, wie du hier nach 100 Beiträgen so einen Schwachsinn als Resumee vom Stapel lassen kannst.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.