Hallo, als Mikrocontrolleranfänger befasse ich mich gerade mit dem Thema (inkrementeller) "optischer Drehgeber" , den ich über einen Flankeninterrupt auswerte. Dabei löst ein steigender Flankenwechsel des A-Signals eine Interruptroutine aus, in der die Zustände von A und B verglichen werden. U.a. laut Vertriebsmitarbeiter des Drehgebers die effektivste Art einen optischen Encoder auszulesen. Zudem habe ich ggf. geplant, das Auslösen der Routine sowohl bei steigender als auch fallender Flanke durchzuführen und so die doppelte Auflösung zu erhalten. Grundsätzlich würde mich nun nur allgemein interessieren, wie ich einen Jitter, der ggf. auftritt, rausfiltern könnte. Eine Möglichkeit, die ich mir überlegt habe wäre vorab den zeitlichen Abstand zweier Flankenwechsel bei max. Drehzahl des Motors zu bestimmen. Am Anfang der Interruptroutine wird ein Timer, (der am Ende der Routine wieder 0 gesetzt wird) mit der verstrichenen Zeit seit dem letzten Auslösen der Routine verglichen. Ist dieser kleiner als der Abstand bei max. Drehzahl so muss es sich um einen Jitter handeln. Was haltet ihr von der Idee, bzw wie könnte man es verbessern oder gar ganz anders und besser machen? Vielen Dank für eure Hilfe Roland
:
Verschoben durch Admin
@ Roland83 (Gast) >als Mikrocontrolleranfänger befasse ich mich gerade mit dem Thema >(inkrementeller) "optischer Drehgeber" , den ich über einen >Flankeninterrupt auswerte. Was schon mal der erste Fehler ist. Siehe Artikel Drehgeber. >Grundsätzlich würde mich nun nur allgemein interessieren, wie ich einen >Jitter, der ggf. auftritt, rausfiltern könnte. Mit der richtigen Auswertung. MFG Falk
Hallo Falk, den Artikel habe ich mir auch schon angeschaut und den Vertriebsmitarbeiter darauf angesprochen. Der hat mich "belächelt" und gesagt dass optische Encoder nicht prellen(!). Es kann eben max zu einem Jitter kommen wenn die Lichtschranke auf dem Zustandswechsel stehen bleibt und es durch Vibrationen zu "unrechtmäßigen" Flankenwechseln kommt. Und aufgrund der starken Mikrocontrollerauswertung eines timergesteuerten Interrupts (vgl. Code von Herrn Dannegger) hat er mir empfohlen einen Flankengesteuerten zu verwenden. Insofern... wäre es schön wenn ihr mir Tipps geben könnt wie ich Jitter bei meinem Anwendungsfall rausfiltern könnte. Danke
Sehe ich das richtig: Der Encoder hängt an einem Motor? Von welchen Drehzahlen bzw. Frequenzen reden wir hier eigentlich? Welche Auflösung hat der Encoder? Und welchen Mikrocontroller bzw. welche Architektur möchtest Du einsetzen? Roland83 schrieb: > Und aufgrund der starken Mikrocontrollerauswertung eines > timergesteuerten Interrupts (vgl. Code von Herrn Dannegger) hat er mir > empfohlen einen Flankengesteuerten zu verwenden. ??? Der Code von Peter Dannegger ist wunderbar für manuelle Drehencoder geeignet. Also bitte erstmal die Fragen oben beantworten. Erst dann kann man nach einem Lösungsansatz suchen. Duke
Roland83 schrieb: > Insofern... wäre es schön wenn ihr mir Tipps geben könnt wie ich Jitter > bei meinem Anwendungsfall rausfiltern könnte. dann teste doch mal die andere Möglichkeit, wenn dann kein Jitter da ist kannst du ja noch mal mit dem Vertriebsmitarbeiter reden. Bist du der Entwickler oder der Vertriebsmitarbeiter?
Vielleicht solltest Du deine Anwendung ein wenig beschreiben. Da Du Flanke zu Flanke messen möchtest, nehme ich an dass Du so etwas wie die Drehzahl des Motors oder ähnliches bestimmem möchtest. Muss es dafür wirklich jede Flanke sein? Eine Mittelwertbildung oder die Zeit über 100 Flanken erhöht die Messgenauigkeit genauso.
@ Peter 2: nene, bin nur n Azubi, der sich erstmal anhören darf was die anderen sagen :). Habe einen Atmega2560 zur Verfügung (ich weiß völlig überdimensioniert, aber das einzige gescheite was grad da ist, evtl bestellen wir aber noch n anderen). Encoder liefert bei 1 flankenauswertung 180 Impulse/Umdrehung. Wollte aber über eine Übersetzung kleinere gerade Bewegungen erreichen. Bei dem Ding handelt es sich in erster Linie um eine Übung wo wir einen einen kleinen Werktisch bauen sollen der in einer Achse verfahren wird (Motorumdrehung ca. 200 U/min) . Stehe noch relativ am Anfang, das mit dem Jitterfilter wäre optional, habe mir aber gedacht dadurch noch gute tipps zu erhalten :)
Roland83 schrieb: > den Vertriebsmitarbeiter darauf angesprochen. Der hat mich "belächelt" > und gesagt dass optische Encoder nicht prellen(!). Es kann eben max zu > einem Jitter kommen wenn die Lichtschranke auf dem Zustandswechsel > stehen bleibt und es durch Vibrationen zu "unrechtmäßigen" > Flankenwechseln kommt. Da sollte sich der Herr Verkäufer aber nochmal schlau machen, was "Jitter" ist. Bei optischen Encodern ist Jitter die Abweichung eines Pulses von der erwarteten Position. Wenn also z.B. bei einem 180-Pulse-pro-Umdrehung-Drehgeber die erste Flanke bei 0° kommt, die nächste aber nicht bei 2°, sondern bei 1,99° und die übernächste nicht bei 4° sondern bei 4,01°, dann hast du einen Jitter von 0,02°... Das Gezappel, wenn der Geber grad doof dasteht, hat keinen Namen, denn es hat seine Ursache nicht im Geber sondern in einem daran angeschlossenen System! Auf englisch heißt es dann auch "shaft jitter" = Wellenzittern.
Roland83 schrieb: > Und aufgrund der starken Mikrocontrollerauswertung eines > timergesteuerten Interrupts (vgl. Code von Herrn Dannegger) hat er mir > empfohlen einen Flankengesteuerten zu verwenden. Das ist viel schlimmer, weil du jetzt eine variable, nicht vorhersagbare Auslastung des Controllers hast - in einem Echtzeitsystem absolut unerwünscht. Von der "gesparten" Rechenzeit im Fall einer niedrigen Interruptrate kannst du dir nichts kaufen, dafür ist im Extremfall der Controller nur noch damit beschäftigt, Flankeninterrupts zu bearbeiten, und die restliche Programmausführung kommt zum Erliegen.
Roland83 schrieb: > Grundsätzlich würde mich nun nur allgemein interessieren, wie ich einen > Jitter, der ggf. auftritt, rausfiltern könnte. Gar nicht. Wozu auch? Du solltest aber einen Komparator benutzen, damit du ne Hysterese im Empfangszweig hast, denn optische Encoder haben keinen Sprung im Signal wie z.B. ein mechanischer Schalter, sondern deren Signal sieht eher "weichflankig" aus bis hin zu einer Art gekapptem Sinus. Ansonsten kann ich nur von dem hier offensichtlich allgegenwärtigen Atmel AVR ab- und zu einem kleineren Cortex von NXP zuraten. Grund: Einige dieser Cortexe haben nämlich zusammen mit ein wenig Motorsteuer-Peripherie auch eine Hardware eingebaut, wo man Encoder anschließen kann. Diese Chips haben also etwas, das bei den meisten anderen uC nicht vorhanden ist. Wenn ich mich recht erinnere, dann kann das Teil vor- und rückwärts zählen und sogar einen Wert über die Drehgeschwindigkeit liefern. Ach schau doch selber mal bei NXP nach. W.S.
Ich bin da von Meinung das bei eine doppelte Auswertung von A und B encoder das "jitteren" eigentlich keine Falschtellung verursacht. Nemen wir mal an das der Antrieb steht genau auf das Schaltpunkt von A encoder. A encoder schaltet dan ohne Grund. Bei eine positive Flanke von A wird erst B angeschaut. B steht hoch : bedeutet positions Zaehler erhohen. Jetzt komt wieder eine negative Flanke von A. Wir schauen B an, der steht noch immer hoch : bedeutet positions Zaehler niedriger !! Solange das jittern nur auf A oder B passiert, gibt kein Problem. Und da A und B spur um die 90° versetzt sein, soll das auf diesen Weise abgesichert sein. Wen ihre Hardware so schlecht ist, das A und B zusammen jitteren, ist naturlich ende.
@ Jan H. (jan_h74) Flattr this >Ich bin da von Meinung das bei eine doppelte Auswertung von A und B >encoder das "jitteren" eigentlich keine Falschtellung verursacht. Meinen kann man viel. Wissen ist was anderes. > Nemen >wir mal an das der Antrieb steht genau auf das Schaltpunkt von A >encoder. A encoder schaltet dan ohne Grund. Bei eine positive Flanke von >A wird erst B angeschaut. B steht hoch : bedeutet positions Zaehler >erhohen. So schön, so gut. > Jetzt komt wieder eine negative Flanke von A. Wir schauen B an, >der steht noch immer hoch : bedeutet positions Zaehler niedriger !! Wer sagt dir, dass dieses Jittern immer vollstängig vom u erfasst wird? Was ist, wenn die Frequenz so hoch ist, dass er es bsiweilen nicht mehr verarbeiten kann? >Solange das jittern nur auf A oder B passiert, gibt kein Problem. Und da >A und B spur um die 90° versetzt sein, soll das auf diesen Weise >abgesichert sein. Tja, das ist eine sehr vereinfache Betrachtung, die in der harten Realität auf Dauer nicht bestehen wird, wenn gleich es oft recht gut funktioniert. >Wen ihre Hardware so schlecht ist, das A und B zusammen jitteren, ist >naturlich ende. Dann ist er kaputt. Ausserdem ist der von dir beschriebene Effekt KEIN Jitter. Jitter ist ein zeitlicher Fehler eines Signals, meist einer Taktflanke. Dieses "Flattern" kann man am ehesten als "Prellen" bezeichnen, wenn gleich die Ursache nicht von Kontakten kommt. MfG Falk
Jan H. schrieb: > Ich bin da von Meinung das bei eine doppelte Auswertung von A und B > encoder das "jitteren" eigentlich keine Falschtellung verursacht. Jitter ist nicht das Gezappel auf der Schaltschwelle. siehe: Lothar Miller schrieb: > Wenn also z.B. bei einem 180-Pulse-pro-Umdrehung-Drehgeber die erste > Flanke bei 0° kommt, die nächste aber nicht bei 2°, sondern bei 1,99° > und die übernächste nicht bei 4° sondern bei 4,01°, dann hast du einen > Jitter von 0,02°...
@ andreas. wie gesagt ich bin nicht so bewandert in der mikrocontroller Programmierung. aber wieso ist denn ein flankengesteuerter Interrupt schlechter, der nur im betrieb ausgelöst wird und sich sogar der drehgeschwindigkeit des Motors anpasst oder ein timergesteueruter interrupt, der die ganze zeit ausgelöst wird und so schnell eingestellt sein muss wie die max. Drehgeschwindigkeit und auch im falle der Ruhezeit arbeitet? @Jan. Vielen Dank. das macht sinn. Dann werde ich beide flanken auswerten und somit auch die doppelte Auflösung haben :)
@ Roland83 (Gast) >Programmierung. aber wieso ist denn ein flankengesteuerter Interrupt >schlechter, der nur im betrieb ausgelöst wird Steht alles im Artikel Drehgeber. MfG Falk
Falk Brunner schrieb: > @ Jan H. (jan_h74) Flattr this >> > Wer sagt dir, dass dieses Jittern immer vollstängig vom u erfasst wird? > Was ist, wenn die Frequenz so hoch ist, dass er es bsiweilen nicht mehr > verarbeiten kann? > Das ist eigentlich eine schone Frage. Kan an einen Pin zwei Positive Flanke Interrupts hinter ein ander ausgelost werden ? Ohne zwischenliegende Negativ Flanke interupt ? Das ist in diesen Fall notwendig um eine falsche Zaehlung zu bekommen. Aber wahrscheinlich ist dan den µ schon lange abgesturzt wegend overflow... Und ja, jitter ist nicht die richtige Ausdruckung.
@Jan H. (jan_h74) Flattr this >Das ist eigentlich eine schone Frage. Kan an einen Pin zwei Positive >Flanke Interrupts hinter ein ander ausgelost werden ? Ohne >zwischenliegende Negativ Flanke interupt ? Kommt auf den uC an. Aber selbst wenn beide Flanke als Auslöser eingestellt sind wie z.B. beim AVR an INT0, muss die Plarität der Flanke im Interrupt per Software ermittelt werden, das dauert schon einige Takte. > Das ist in diesen Fall >notwendig um eine falsche Zaehlung zu bekommen. >Aber wahrscheinlich ist dan den µ schon lange abgesturzt wegend >overflow... Warum? Auch bei 100% Interruptlast gibt es keinen Stack overflow, aber dein Hauptprogramm kommt nur noch in Zeitlupe voran. MFG Falk
Falk Brunner schrieb: > Aber selbst wenn beide Flanke als Auslöser > eingestellt sind wie z.B. beim AVR an INT0, muss die Plarität der Flanke > im Interrupt per Software ermittelt werden, das dauert schon einige > Takte. Korrekte Lösung ist, nach einem LoHi-Interrupt nur eine negative Flanke als IR-Request zuzulassen und umgekehrt. Dann kommt es weder zu einer Überlastung noch zu einer falschen Zählung. Gruss Reinhard
Diese Interrupt-Routine wertet beide Encoder-Kanäle auf steigende und fallende Flanke aus, damit vierfache Auflösung. Funktioniert zuverlässig bis 10kHz oder so. Der Encoderstand aus ENCNT wird in einem Timerinterrupt regelmäßig ausgelesen und daraus eine Geschwindigkeit / eine Position berechnet. Damit wird ein Motor über einen PID drehzahlgeregelt und definierte Positionen angefahren. Heute würde ich es wahrscheinlich auch mit einer timergesteuerten Zustandsabfrage machen, zumal dann beliebige Eingänge für den Encoder genutzt werden können.
1 | .ORG INT0addr ;External Interrupt0 |
2 | rcall enc_int ;Encoder Interrupt Handler |
3 | .ORG INT1addr ;External Interrupt1 |
4 | rcall enc_int ;Encoder Interrupt Handler |
5 | |
6 | ;**** Init Encoder ExtInterrups **** |
7 | |
8 | clr ENSPD |
9 | clr ENCNT ;Init Encoder |
10 | |
11 | in TEMP1,PINint ;Encoderstand einlesen, Bit 3+2 |
12 | cbr TEMP1,0xFF-((1<<Pint1)+(1<<Pint0)) |
13 | mov ENOLD,TEMP1 ;Encoderstand ablegen |
14 | |
15 | ldi TEMP1,(1<<ISC11)+(1<<ISC01) ;ExtInt setzen, je nach Encoderstand |
16 | sbrs ENOLD,Pint1 ;prüfen auf ExtInt 1 high |
17 | sbr TEMP1,1<<ISC10 ;wenn low, Trigger 1 auf rising Edge |
18 | sbrs ENOLD,Pint0 ;prüfen auf ExtInt 0 high |
19 | sbr TEMP1,1<<ISC00 ;wenn low, Trigger 0 auf rising Edge |
20 | out MCUCR,TEMP1 ;Externe Interrupts 1 und 0 setzen, rising Edge |
21 | ldi TEMP1,(1<<INT1)+(1<<INT0) |
22 | out GIMSK,TEMP1 ;Externe Interrupts 1 und 0 enablen |
23 | |
24 | |
25 | ;Main |
26 | |
27 | |
28 | ;**** Encoder Interrupt beide Kanäle **** |
29 | |
30 | enc_int: ;Interrupt-Flags werden automatisch gelöscht |
31 | push TEMP1 |
32 | in TEMP1,SREG |
33 | push TEMP1 |
34 | |
35 | in TEMP1,PINint ;Encoderstand einlesen, Bit 3+2 |
36 | cbr TEMP1,0xFF-((1<<Pint1)+(1<<Pint0)) |
37 | mov ENNEW,TEMP1 ;neuen Encoderstand sichern |
38 | |
39 | ldi TEMP1,(1<<ISC11)+(1<<ISC01) ;ExtInt setzen |
40 | sbrs ENNEW,Pint1 ;prüfen auf ExtInt 1 high |
41 | sbr TEMP1,1<<ISC10 ;wenn low, Trigger 1 auf rising Edge |
42 | sbrs ENNEW,Pint0 ;prüfen auf ExtInt 0 high |
43 | sbr TEMP1,1<<ISC00 ;wenn low, Trigger 0 auf rising Edge |
44 | out MCUCR,TEMP1 ;Externe Interrupts 1 und 0 setzen, rising Edge |
45 | |
46 | ldi TEMP1,0x00 ;Operation AneuBneu und BaltnichtAalt |
47 | sbrs ENOLD,Pint1 ;prüfen auf Old 1 high |
48 | sbr TEMP1,1<<Pint0 ;wenn low, 3 nach 2 schieben, invertiert |
49 | sbrc ENOLD,Pint0 ;prüfen auf Old 0 low |
50 | sbr TEMP1,1<<Pint1 ;wenn high, 2 nach 3 schieben, nicht invertiert |
51 | |
52 | mov ENOLD,ENNEW ;neuen Encoderstand ablegen |
53 | |
54 | eor TEMP1,ENNEW ;verbinden alt und neu |
55 | brne enc_down ;wenn nicht 00, nächste |
56 | |
57 | inc ENCNT ;Inc SpeedCounter, Vorwärts |
58 | |
59 | rjmp enc_out |
60 | enc_down: |
61 | cpi TEMP1,(1<<Pint1)+(1<<Pint0) ;prüfen |
62 | brne enc_out ;wenn nicht 11, nächste |
63 | |
64 | dec ENCNT ;Dec SpeedCounter, Rückwärts |
65 | |
66 | enc_out: |
67 | pop TEMP1 |
68 | out SREG,TEMP1 |
69 | pop TEMP1 |
70 | |
71 | reti ;Encoder Interrupt zurück |
Statt 1<<Bitx + 1<<Bity besser 1<<Bitx | 1<<Bity zuweisen.
@ Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik) >Korrekte Lösung ist, nach einem LoHi-Interrupt nur eine negative Flanke >als IR-Request zuzulassen und umgekehrt. Dann kommt es weder zu einer >Überlastung noch zu einer falschen Zählung. Wunschdenken. Wer verbietet dem Encoder, schneller zu zappeln als der Mikrocontroller die Flanken auswerten kann? Ich glaube ich werd mal ein Testprogramm schreiben, das einen zappligen Encoder emuliert. Das kann man dann auf die "sicheren Flankenauswertungen" loslassen. Mal sehen wer dann weint . . . MFG Falk
Nach dem möglichen Problem, daß man Schritte verliert, weil zwischendurch die Abarbeitung der requests nicht nachkommt hatte ich im "Schwesterthread" 'wie viele Quadraturencoder hat ein uc' gefragt. Da hatte ich den Schwerpunkt meiner Sorge eher darauf gelegt, die letzte Flanke nicht mitzukriegen. Ist spezieller, aber geht ja in die selbe Richtung. Scheint so, als ob die Meinungen da getrennt sind. Es scheint sogar so zu sein, daß da professionelle Meinungen auseinandergehen. Im Moment noch sehr schwierig für mich, mir meine Meinung zu bilden :-(
Falk Brunner schrieb: > Wunschdenken. Wer verbietet dem Encoder, schneller zu zappeln als der > Mikrocontroller die Flanken auswerten kann? Ganz einfach: D-FFs an den Eingängen, welche die Siganle synchronisieren und die Änderungen auf die D-CLK Frequenz beschränken. Nimmt man zum Beispiel für D-CLK 100kHz, können die Flankenwechsel nicht kürzerer als 10µs sein und im Ruhezustand des Gebers wird 0% Prozessorleistung benötigt. Andererseits werden Flankenwechsel bis <100kHz sicher erkannt. Hardware Quadratur-Dekoder machen es ebenso, nur dass dort mit einigen MHz Taktfrequenz gearbeitet wird und die Flankenwechsel noch aufbereitet werden.
Falk Brunner schrieb: > Ich glaube ich werd mal ein Testprogramm schreiben, das einen zappligen > Encoder emuliert. Ach, das ist doch Tinneff: Erstens hat ein optischer Encoder auch eine Hysterese, zumindest die integrierten mit 3 Empfängerdioden und Schmitt-Trigger. Damit muss sich das Encoderrad nennenswert bewegen, um einen Pegelwechsel auszulösen. Und da ist der Interrupt allemal schnell genug durch... Ich hab das damals lang und breit an einem realen Encoder getestet. Probleme gabs mit verschluckten Impulsen, wenn die Drehzahl zu hoch wurde => was mein Motor real nie erreichen kann und was bei timergesteuerten Abfragen auch auftritt. Aber nicht mit Zappeln bei stillstehendem Motor. Höchstens Störungen auf den Encoderleitungen können ausreichend hochfrequent sein, um den Interrupt an die Grenze zu fahren. Aber wenn ich derart massive hochfrequente Einstreuungen habe, liegt mein Problem woanders. Obiger Code funktioniert. Wenn ich es jetzt anders machen würde, dann weil ich von den Interrupt-Pins unabhängig bin und die Abfrage möglicherweise einfacher ist (ständiges Umsetzen der aktiven Pegelwechsel fällt weg). Mit widerstrebte damals einfach der Gedanke, einen Timer ständig so schnell laufen zu lassen, obwohl die meiste Zeit gar keine Ereignisse anstehen.
Timm Thaler schrieb: > Mit widerstrebte damals einfach der Gedanke, > einen Timer ständig so schnell laufen zu lassen, obwohl die meiste Zeit > gar keine Ereignisse anstehen. Mit dieser völlig unqualifizierten Meinung stehen wir beide wohl allein auf weiter Flur. Anbei ein Codeschnipsel, der beide Flanken von INT0 und INT1 auswertet. Daran kann man abzählen, wie schnell ein ATmega48 die INTs verwurschteln kann. Init-Routinen und weitere Verarbeitung erspare ich mir.
@ Timm Thaler (timm-thaler) >> Ich glaube ich werd mal ein Testprogramm schreiben, das einen zappligen >> Encoder emuliert. >Ach, das ist doch Tinneff: Nö, es ist ein HANDFESTER Test, nicht nur seichtes Forumsgeplänkel! Stay tuned! MFG Falk
"Init-Routinen und weitere Verarbeitung erspare ich mir." Die weitere Verarbeitun und was sonst noch so auf dem Controller läuft finde ich schon wichtig. Wenn der alleinige Daseinszweck der Encoder ist, kommst du so natürlich schon schnell zu rande. Aber zusätzliche Auslastung kann dann schon zu sporadischen Problemen führen, die Falk meint. Hat ja keiner behauptet, daß das immer knallt. Wenn cnt in irgendeiner Berechnung gebraucht wird, musst du ja für die Zeit schon mal den int dichtmachen. Und wenn usb oder so was auf dem Controller läuft funkt eine Menge anderes dazwischen.
Falk Brunner schrieb: > @ Timm Thaler (timm-thaler) > >>> Ich glaube ich werd mal ein Testprogramm schreiben, das einen zappligen >>> Encoder emuliert. > >>Ach, das ist doch Tinneff: > > Nö, es ist ein HANDFESTER Test, nicht nur seichtes Forumsgeplänkel! > Stay tuned! > > MFG > Falk Mich würde mal ein originales Oszillogramm eines "zappelnden" optischen Encoders interessieren. Den Nachweis, dass sowas in echt auftritt hat hier noch keiner erbracht.
Klar, wäre eine Diskussionsgrundlage... Aber was ist DAS Referenzgezappel? Muss sich ja nicht jegliches Gezappel an das halten was da aufgenommen wurde.
Clemens M. schrieb: > Wenn cnt in irgendeiner Berechnung gebraucht wird, musst du ja für die > Zeit schon mal den int dichtmachen. Dann schreib Dir die Routine und zähle die Takte dafür. Dann kannst Du abschätzen, wie lange es braucht. > Und wenn usb oder so was auf dem Controller läuft funkt eine Menge > anderes dazwischen. Und Du glaubst, wenn ein periodischer Timer aktiv ist, ginge das alles schneller? Immer nur Meckern :-(
akaDem schrieb: > Mich würde mal ein originales Oszillogramm eines "zappelnden" optischen > Encoders interessieren. Den Nachweis, dass sowas in echt auftritt hat > hier noch keiner erbracht. Jeder, der schon mal Positioniersteuerungen entwickelt hat, weiß dass es dieses Zappeln gibt. Sei es durch externe Belastung der Welle, auf die der Encoder sitzt, oder nur durch den Stoppvorgang der Welle. Beim Stoppen kann auch nur ein einmaliger Richtungswechsel stattfinden. Wenn das alles korrekt erfasst und bilanziert wird ist das alles "kein Problem". ;)
"Immer nur Meckern :-("
Hä? Das hat doch wirklich nichts aber auch gar nichts mit Meckern zu tun
sondern mit einer (von meiner Seite aus) konstruktiven Diskussion über
ein Problem. Bin weder festgefahren, noch voreingenommen, sondern offen
für jegliche Argumente und Fakten.
Gerade das, was zwischen das irq funken kann ist doch eine potentielle
Ursache dafür, daß dieser eben ein von zig Tausend mal ärger macht. Und
das wollen wir doch besprechen oder hab ich das falsch verstanden?
Frage ist für mich: IST die irq Lösung eine Potentielle Quelle für
sporadische Fehler, wie groß ist die und ist das vertretbar einzugehen.
Verstehe ich wirklich nicht.
@ m.n. (Gast) >> Und wenn usb oder so was auf dem Controller läuft funkt eine Menge >> anderes dazwischen. >Und Du glaubst, wenn ein periodischer Timer aktiv ist, ginge das alles >schneller? DETERMINISTISCH! >Immer nur Meckern :-( Lesen, geschweige Verstehen, ist wohl nicht deine Kernkompetenz? Der "Trick" des Polling per Timer-Interrupt ist, dass es Zappel kann wie es will, die CPU-Last ist konstant und deterministisch und Trotzdem wird nicht ein eiziger Schritt verschluckt, selbt bei 1 GHz Zappeln. MFG Falk
Falk Brunner schrieb: > Wunschdenken. Wer verbietet dem Encoder, schneller zu zappeln als der > Mikrocontroller die Flanken auswerten kann? Nein, schlichte Logik. Wenn beim Zappeln eine Hi-Flanke erfasst wurde und danach eine Lo-Flanke übersehen, wird so auch noch die nächste Hi-Flanke ignoriert - und damit ist GENAU NICHTS passiert, ein schnellerer Zähler hätte eins rauf gezählt und dann wieder eins runter - überflüssigerweise. Bei einem sorgfältig entworfenen Quadratur-Decoder in Hardware passiert das gleiche und deswegen sind sie gegen Zappeln immun. Nach dem Verlauf des Threads scheint ein Quadratursignal in erstaunlich vielen Fällen die Denkfähigkeit zu überfordern. Gruss Reinhard
Hallo Der Artikel Drehgeber ist schon sehr gut verständlich, aber vielleicht hilft das Bild 2 in dieser Applikation: http://www.ichaus.biz/upload/pdf/EncoderAnschluss%20-WP22102011de.pdf die Funktionsweise der Quadratursignale in seiner Abfolge besser zu verstehen. Die Vorwärts-/Rückwärtsrichtung ist in der Flankenfolge A-->B und B-->A codiert. Ein guter Encoder verliert keine Impulse und es ist ein minimaler Flankenabstand definiert. Schafft der Mikrocontroller es nicht diesen Flankenwechsel zu verarbeiten, muss ein Richtungsdiskriminator und ein Hardware-Zähler her. Hier gibt es noch mehr Hinweise für eine Erfassung der Geschwindigkeit: http://imperia.mi-verlag.de/imperia/md/content/ai/ae/fachartikel/ei/2008/07/ei08_07_030.pdf . VG Horst
Angehängte Dateien:
-
Encoder1.PNG
3,6 KB
Im Anhang ein Vorschlag, der auf "Siemens Halbleiter-Schaltbeispiele 1973" zurück geht.
Falk Brunner schrieb: > Nö, es ist ein HANDFESTER Test, nicht nur seichtes Forumsgeplänkel! Es ist eine Simulation. Klar kannst Du den in der Simulation auch mit 1 MHz zappeln lassen. Oder mit 10 MHz. Ist nur völlig unrealistisch. Ich habe das real ausprobiert. Also genau so versucht, den Encoder (Sharp GP1A70R und ähnliche) auf eine Flanke zu setzen und dann springen zu lassen, und das Ganze auf dem Oszi beobachtet. Er tut es nicht. Liegt einfach daran, dass der detektierte Lichtstrahl nicht unendlich schmal ist. Damit ergibt sich kein abrupter Hell-Dunkel-Übergang, sondern eine Flanke mit einer Steigung dU / dw. Die Flanke wird über einen Schmitt-Trigger mit Hysterese (noch im Encoder) ausgewertet. Um einen Pegelwechsel H-L-H zu erreichen, muss die Hysterese überwunden werden, dazu muss der Winkel dw sich signifikant ändern. Da wir hier von realen Systemen und nicht von einer Simulation reden, geht eine Winkeländerung nur durch Überwinden einer gewissen Massenträgheit. Und dazu benötigt ein reales System Zeit. Für ein "Zappeln" muss sich der Encoder also erstmal bewegen, und das kann er nicht beliebig schnell. Disclaimer: Das gilt für optische Encoder, bei mechanischen Drehencodern mit Kontaktprellen sieht das anders aus.
@ Timm Thaler (timm-thaler) >> Nö, es ist ein HANDFESTER Test, nicht nur seichtes Forumsgeplänkel! >Es ist eine Simulation. Nö, eher Emulation eines Worst Case Szenarios. > Klar kannst Du den in der Simulation auch mit 1 >MHz zappeln lassen. Oder mit 10 MHz. Ist nur völlig unrealistisch. Hast du eine Ahnung von realen Störsignalen. Und selbst wenn es deutlich über reale Störsignal hinausgeht. Es zeigt prinzipielle Stärken oder auch Schwächen von Decodern.
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.