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
@ 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
@ 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
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.
