ich möchte eine Buttonmatrix mit 5x Rotary Encoder + Taster (KY-040) erstellen. Leider habe ich hierzu nichts gefunden. Die Rotary Encoder können doch als 3 fach Taster angesehen werden? Ist die Schaltung so richtig? Welche Diode würdet ihr empfehlen?
ich möchte eine Buttonmatrix mit 5x Rotary Encoder + Taster (KY-040)
erstellen.
Warum? Hast du damit so viele IOs gespart? 5 Encoder sind 15 Eingangssignale, die man problemlos mit 2x8 Bit Schieberegistern einlesen kann. Dazu braucht es gerade mal drei IOs. Deine Matrix braucht 8.
Es müssen 8x von dieser Schaltung, sowie weitere Schaltungen an einen STM32MP151AAA3 (176 I/O Pins) angeschlossen werden. mit dieser Schaltung würde ich unter die 176 kommen.
Beim suchen nach einer Lösung wurde die Matrix immer den Schieberegistern bevorzugt. Zeitverzögerungen, Ausfallsicherheit kompletter Bereiche usw. wurden dabei angeführt. Oder hab ich das falsch verstanden?
Es müssen 8x von dieser Schaltung, sowie weitere Schaltungen an einen
STM32MP151AAA3 (176 I/O Pins) angeschlossen werden. mit dieser Schaltung
würde ich unter die 176 kommen.
Was umso mehr für Schieberegister spricht.
Beim suchen nach einer Lösung wurde die Matrix immer den
Schieberegistern bevorzugt. Zeitverzögerungen,
Unfug. Deine 8x2 Byte liest man selbst bei schnachlangsamen 1 MHz Takt innerhalb von "sagenhaften" 128us aus, real gut Faktor 10 schneller.
Ausfallsicherheit
Ebenso Unsinn. Wer eine handvoll Schieberegister nicht stabil betreiben kann, sollte was anderes machen.
Hat jemand eine config für die STM32 Timer, um die RotaryEncoder etwas zu entprellen? Die Timer zählen korrekt, aber es kommen tonnenweise Interrupts (trotz Filterung per status flag). Und das Up/Down Flag ist falsch, während man im Interrupt ist.
Beim suchen nach einer Lösung wurde die Matrix immer den
Schieberegistern bevorzugt.
Dieser Satz kein Deutsch.
Und deine Frage ist ein Paradebeispiel dafür, wie man es nicht macht. Wenn du 40 Encoder abfragen und dabei mit wenig Pins auskommen willst, dann solltest du das auch so sagen.
Es müssen 8x von dieser Schaltung, sowie weitere Schaltungen an einen
STM32MP151AAA3 (176 I/O Pins) angeschlossen werden.
Ein Encoder braucht auch bei Direktanschluß gerade mal 3 Pins, also 120 Pins für 8×5=40 Encoder gesamt. Natürlich führst du nicht näher aus, was "weitere Schaltungen" sind oder machst gar eine konkrete Rechnung auf a'la "ich habe X Pins für den Anschluß von Y Encodern".
Aber da anzunehmen ist, daß die Encoder sowieso auf einer größeren Platine angeordnet sein werden (A4 Größe ist für 40 Stück eher knapp) und das Routing von 120 Signalen eher häßlich wird, würde ich erst recht auf kaskadierte Schieberegister setzen. Im Extremfall ein einziges, 120=15×8 Bit langes. Vielleicht willst du aber Encoder lieber in Gruppen zusammenfassen. Weiß ja außer dir niemand.
Es müssen 8x von dieser Schaltung, sowie weitere Schaltungen an einen
STM32MP151AAA3 (176 I/O Pins) angeschlossen werden. mit dieser Schaltung
würde ich unter die 176 kommen.
Hat jemand eine config für die STM32 Timer, um die RotaryEncoder
etwas
zu entprellen? Die Timer zählen korrekt, aber es kommen tonnenweise
Interrupts (trotz Filterung per status flag). Und das Up/Down Flag ist
falsch, während man im Interrupt ist.
Ich möchte ein Main PCB erstellen. Dort sitzt der uC und diverse Schaltungen wie zb. die Schmitt Trigger um die WS2812B Signalleitung auf 5V hoch zu bekommen. Von dem Main PCB geht es dann über Steckverbindungen über eine Distanz von ca. 50cm (max.)zu den nachfolgenden PCBs:
Ich möchte ein Main PCB erstellen.
8x 5fach Rotary Encoder PCB
4x 2fach Rotary Encoder PCB
Dann würde ich das ganze modular gestalten:
Auf die PCBs jeweils noch einen kleinen µC (muss ja kein Tiny wie von m.n. vorgeschlagen sein) und die Verbindung zu deinem Main-Board über ein Bussysstem, I²C, SPI, UART, ...
Den Input-Platinchen dann halt jeweils noch ein Mäuseklavier/Jumper zum Einstellen einer Adresse spendieren, und schon können die Platinen identisch sein.
Dann bist du auch flexibel, und wenn du z.B. dann mal eine Input-Platine mit qTouch-Slidern etc bauen willst, kann die das selbe Interface nutzen.
So ein ähnliches System auf Basis eines CAN BUS habe ich schon in der mache. Ich wollte es eigentlich schlanker machen und die Kosten für eine Kleinserienfertigung (brauche vorerst ca. 10 komplette Systeme eventuell weitere 10 bis 20 im Nachgang) senken. Dies scheint aber wohl nicht der Fall zu sein?!
gerade bei Kleinserien überwiegen die Entwicklungskosten deutlich.
Die paar € für die zusätzlichen µCs sind im Vergleich zum Aufwand, sie zu programmieren pillepalle.
Musst du entscheiden, ob die reduzierte Komplexität für das Gesamtsystem und die vereinfachte Programmierung des "Master-µC" das wieder rausholt.
Ansonsten ginge bei der Schieberegister-Umsetzung auch ein Daisy-Chain über die einzelnen Input-Platinen. Dann limitiert aber die Verkabelung die maximale SPI-Frequenz.
So ein ähnliches System auf Basis eines CAN BUS habe ich schon in der
mache. Ich wollte es eigentlich schlanker machen und die Kosten für eine
Kleinserienfertigung (brauche vorerst ca. 10 komplette Systeme eventuell
weitere 10 bis 20 im Nachgang) senken. Dies scheint aber wohl nicht der
Fall zu sein?!
Dass CAN was kostet, hat die Automobilindustrie auch schon gemerkt und für die Dinge, die keine so hohe Bandbreite brauchen, LIN erfunden. Bei Mouser kostet ein CAN-Transceiver in EInzelstückzahlen ca. 2€ minimal, ein LIN-Transceiver aber unter einem €. Plus: Ein CAN-Knoten braucht einen Quarz, ein LIN-Slave kommt ohne aus, da er sein Bustiming am Synchronbyte ausmessen kann. Und ein Microcontroller mit LIN-fähigem(!) UART kostet deutlich weniger als einer mit CAN.
Nur mal so als Idee, was im echten Leben draußen so passiert.
So ein ähnliches System auf Basis eines CAN BUS habe ich schon
in der mache.
Dass CAN was kostet, hat die Automobilindustrie auch schon gemerkt und
für die Dinge, die keine so hohe Bandbreite brauchen, LIN erfunden.
Kleine uC mit CAN haben den großen Vorteil, dass der große uC nicht pollen muss.
Den Vorteil kann man aber auch mit einem normalen UART haben, ganz ohne CAN und ohne LIN. Man baut keinen Bus, sondern eine Daisy Chain, immer UART-TX an UART-RX vom nächsten. Als letzter hängt der große uC in der Kette. Ja, die Latenz ist bei jedem Knoten anders und wird mit jedem weiteren uC immer größer; bei 115200 Baud wäre die Grenze mit 3.6ms bei 42 Knoten ;)
Beim suchen nach einer Lösung wurde die Matrix immer den
Schieberegistern bevorzugt.
Einfach, weil es schon immer so gemacht wurde? Oder warum?
Basierend auf welchen Erfahrungen?
Zeitverzögerungen
Man kann da alle Schieberegister hintereinander schalten und eine DMA aufsetzen. Dann ist das keine Verzögerung oder gar Rechenaufwand in der Software.
Ausfallsicherheit kompletter Bereiche usw. wurden dabei angeführt.
Das ist ein Scheinargument. Denn auch wenn nur 1 Encoder ausfällt, dann ist das laut Murphy immer genau der, den ich gerade brauche. Da hilft es nichts, wenn die 39 anderen noch tadellos funktionieren.
Hat jemand eine config für die STM32 Timer, um die RotaryEncoder etwas
zu entprellen?
Per Definition müssen Drehencoder dank des Graycodes nicht entprellt werden.
Die Timer zählen korrekt
So soll es sein, das ist das Wichtigste.
aber es kommen tonnenweise Interrupts (trotz Filterung per status flag).
Welche Interrupts denn?
Der Zähler an sich braucht keine. Und wenn due den Zähler auslesen willst, dann tust du das am Besten dann, wenn es dir gerade so passt. Ich würde nie in meiner Software manuelle Eingaben einen Interrupt auslösen lassen. Da kann es ja sicher nicht auf die Millisekunde ankommen. Und bis dahin ist die Mainloop sowieso einmal durch.
Hat jemand eine config für die STM32 Timer, um die RotaryEncoder etwas
zu entprellen?
Per Definition müssen Drehencoder dank des Graycodes nicht entprellt
werden.
Das stimmt nur wenn die Drehencoder Graycodes ausgeben. Es gibt in der freien Wildbahn aber auch Encoder, die z.B. getrennte Drehrichtungsausgänge haben und dort je nach Drehrichtung kurze Impulse ausgeben. Also muss die Frage an den TO lauten, welche Encoder werden eingesetzt?
Das stimmt nur wenn die Drehencoder Graycodes ausgeben.
Drehencoder mit 2-Bit Gray-Code sind deutlich am weitesten verbreitet.
Bei solchen mit Rastung muss zusätzlich noch auf die Kanalzuordnung achten, damit man stabile Ausgangswerte bekommt.
Für die Auslegung der Abtastung ist die maximale Pulsfrequenz an den Ausgängen entscheidend.
Hat jemand eine config für die STM32 Timer, um die RotaryEncoder etwas
zu entprellen? Die Timer zählen korrekt, aber es kommen tonnenweise
Interrupts (trotz Filterung per status flag). Und das Up/Down Flag ist
falsch, während man im Interrupt ist.
Schaue dir mal die Funktion "encode" an. Die ist auch im Interrupt stabil und prellfrei.
ohne mir jetzt alles genau anzusehen: IMHO gehen die ganzen Decoderroutinen doch von fest an den GPIO verschalteten Drehencoders aus und arbeiten dann interruptgesteuert und dröseln das auf. Ich hab absolut keine Idee wie man da eine SPI-Schieberegisterkette eintütet. Gibt es da eine Referenzimplementation?
Ich hab
absolut keine Idee wie man da eine SPI-Schieberegisterkette eintütet.
Gibt es da eine Referenzimplementation?
Indem man nicht die Pegel direkt von den GPIO verwendet, sondern zuvor die Eingangspegel der Schieberegister in den Speicher holt und dann wie gehabt verarbeitet.
Pro 8 Bit SR könnte man von zwei Encodern jeweils drei Pins anschließen und die beiden freien unbenutzt lassen. War das jetzt schwer?
IMHO gehen die ganzen
Decoderroutinen doch von fest an den GPIO verschalteten Drehencoders aus
und arbeiten dann interruptgesteuert und dröseln das auf.
Nein. Die laufen per Timer-Interrupt oder per periodischem Task aus der main()-Loop, pollen den Zustand der IOs, und lösen den Gray-Code auf.
Das geht problemlos auch über Schieberegister oder I²C-Portexpander.
Und hat den Vorteil, dass der Zählerstand nicht wild durch die Gegend springt, gerne auch gegen die Drehrichtung, sobald der Drehencoder etwas älter wird und stärker prellt.
Das Polling muss nur schnell genug erfolgen, dass die maximale Umdrehungsgeschwindigkeit, die man per Hand noch hinbekommt, noch sauber abgetastet werden kann.
Auch die Schalter in Drehencodern prellen. Bei Gray-Code stört das
nicht.
Wäre schön, wenn diese Theorie in der Praxis zutreffen würde. Ich meide mittlerweile den Kauf von Geräten mit Drehencodern, weil sie so oft Probleme machen.
Ganz aktuell: Im vergangenen Sommer wurden im Büro smarte Thermostate auf die Heizungsventile geschraubt. Wenn man daran dreht, springt die angezeigte Soll-Temperatur um mehrere Grad wild rauf und runter. Es ist jedes mal ein Glücksspiel, da die gewünschte Temperatur einzustellen.
Wenn man daran dreht, springt die angezeigte Soll-Temperatur um mehrere
Grad wild rauf und runter.
Ich wünsche dem jeweiligen Programierer dann im ersten Augenblick immmer, dass er sich täglich mit solchen Geräten herumärgern muss.
Kurz danach fällt mir dann aber ein, dass es vielleicht tatsächlich so ist und er seinen Krempel deshalb so grauenhaft schlecht programmiert, weil er meint, es ginge sowieso nicht besser und es wäre somit gut genug, auch wenn der Wert ab und zu hin und her hüpft.
IMHO gehen die ganzen Decoderroutinen doch von fest an den GPIO
verschalteten Drehencoders aus
Das ist der einfachste Fall.
und arbeiten dann interruptgesteuert
Das sind gern die schlechten Encoder-Auswertungen, die mit ganz neuen Encodern "ziemlich gut" funktionieren. Aber wehe, wenn der mal eine winzige Oxidschicht auf den Schaltkontakten hat und schon beim Anfassen "kratzt".
Wie gesagt: du brauchst für deine 40 Drehgeber genau 1 einzigen Interrupt, nämlich den Timerinterrupt. Und in diesem einen Timerinterrupt verarbeitest du die zuvor per DMA eingelesenen 40 Encoder mit ihren 120 Signalen, machst auf den 80 Drehgebersignalen die Geberauswertung und entprellst zudem die 40 Taster. Danach startest du das Einlesen der Schieberegister per DMA für den nächsten Timerinterrupt.
Das schöne ist das er das auf einem STM32MP1 machen will. Das kann von "kein Problem", wenn die Auswertung im integrierten M4 erfolgen darf und an das Linux im A7 weitergegeben wird, bis "funktioniert überhaupt nicht zuverlässig", wenn die Auswertung auf dem A7 in $SCRIPTSPRACHE per sysfs GPIO-Bitbanging erfolgt, alle Zwischenstufen der Frustration erreichen :-)
Schaue dir mal die Funktion "encode" an. Die ist auch im Interrupt
stabil und prellfrei.
Auch die Schalter in Drehencodern prellen. Bei Gray-Code stört das
nicht.
Was ist eine "prellfreie" Funktion?
Wenn es sich ausgeprellt hat, stimmt der Wert. Das ist schon richtig.
Beim Prellen kann es aber passieren, das zwischen zwei Werten hin- und hergesprungen wird. Mit der Funktion ist es unmöglich zwischen zwei Werten zu pendeln. Sozusagen "prellfrei". Und das in der höchsten Auflösung, wenn man will.
Mit der Funktion ist es unmöglich zwischen zwei
Werten zu pendeln.
Dazu muss man nur den Drehgeber richtig anschließen. Die Ausgänge A und B sind nicht beliebig vertauschbar.
Bei der PeDa-Auswertung (Drehgeber: Signalauswertung) wackelt dann ggfs. das LSB im Zwischenspeicher, aber der "encode_read"-Rückgabewert bleibt stabil, und ändert sich nur exakt zwischen den Rastpunkten, nie "an" ihnen.
Mit der Funktion ist es unmöglich zwischen zwei
Werten zu pendeln. Sozusagen "prellfrei". Und das in der höchsten
Auflösung, wenn man will.
Pendelfreiheit erreicht man mit Filterung, gesteuert durch eine Hysterese zusammen mit Richtungsumkehr. Das bedeutet aber immer einen Verlust an Auflösung bei der Richtungsumkehr.
Bei rastenden Encodern mit voller Auflösung entsteht Pendelei (ggf. temperaturabhängig), wenn einer der Phasenumschaltpunkt zu dicht an der Rastposition liegt oder die Rastung ausgenudelt ist. Bei halber Auflösung kann Pendelei entstehen, wenn die Kanäle vertauscht sind.
Bei rastenden Encodern mit voller Auflösung entsteht Pendelei (ggf.
temperaturabhängig), wenn einer der Phasenumschaltpunkt zu dicht an der
Rastposition liegt oder die Rastung ausgenudelt ist. Bei halber
Auflösung kann Pendelei entstehen, wenn die Kanäle vertauscht sind.
Wenn der Encoder rastend ist, ist die mechanische Auflösung (vulgo: Rastpunkte) eigentlich immer gröber als die elektrische Auflösung. Manchmal halbe, meist sogar nur viertel Auflösung.
Oder anders gesprochen, eine Rastung alle 2 oder gar je 4 Schritte. Dann ist es immer möglich, den resultierenden Schaltpunkt so zu legen, daß der Encoder nicht klappert. Der Code im Artikel Drehgeber demonstriert das sehr schön.
Wenn der Encoder rastend ist, ist die mechanische Auflösung (vulgo:
Rastpunkte) eigentlich immer gröber als die elektrische Auflösung.
Das kann jeder Hersteller machen, wie er möchte. Es spricht prinzipiell nichts dagegen, die Rastung so fein bzw. die Kodierung so grob zu machen, dass die Rastung für beide Spuren jeweils gut zwischen den Schaltpunkten liegt, d.h. gleiche Auflösung für Rastung und Gray-Code. Ein Blick ins Datenblatt hilft.
Für die Anwendung ist es ziemlich sinnfrei, die Auflösung der Ausgabe anders zu wählen, als die der Rastung.
Mit der Funktion ist es unmöglich zwischen zwei
Werten zu pendeln.
Dazu muss man nur den Drehgeber richtig anschließen. Die Ausgänge A und
B sind nicht beliebig vertauschbar.
Bei der PeDa-Auswertung (Drehgeber: Signalauswertung) wackelt dann
ggfs. das LSB im Zwischenspeicher, aber der "encode_read"-Rückgabewert
bleibt stabil, und ändert sich nur exakt zwischen den Rastpunkten, nie
"an" ihnen.
Hört sich so an, dass man um jeden Preis, eine interessante Idee umgehen muss. Auf keinen Fall ausprobieren. Einfach schrecklich, wenn es funktioniert.
Falsch anschließen gibt es bei meiner Routine nicht. Funktioniert immer.
Selbstverständlich wählt man die Auflösung der Rastpunkte.
Es gibt aber auch welche ohne Rastung, dann kann man frei wählen.
Der Richtungswechsel wird ignoriert und es entsteht ein Impulsverlust. Aber nur bei der höchsten Auflösung. Und beim nächsten Richtungswechsel wird der Impuls wieder aufgeholt. Es bleibt positionsgenau. Dreht man rückwärst, fehlt ein Impuls. Beim vorwärts drehen passt es wieder. Das ist aber nur bei der höchsten Auflösung der Fall.
Niemand muss meine Routine benutzen. Ist alles freiwillig. Solle es jemand machen und Probleme entdecken, lasst es mich wissen.
Mit der Funktion ist es unmöglich zwischen zwei
Werten zu pendeln.
Das ist aber u.U. ziemlich hinderlich ...
Genauer gesagt ist es unmöglich zwischen zwei Codes zu pendeln. Bei Drehgebern mit Rastpunkt wechseln mindestes zwei Codes von Punkt zu Punkt. Da wird natürlich bei jedem Rastpunkt der Wert geändert.
Genauer gesagt ist es unmöglich zwischen zwei Codes zu pendeln. Bei
Drehgebern mit Rastpunkt wechseln mindestes zwei Codes von Punkt zu
Punkt. Da wird natürlich bei jedem Rastpunkt der Wert geändert.
Natürlich wertet man bei einem rastenden Drehgeber nur jene Pulse aus, welche sich nicht in der Rastung befinden. Bzw. gar nur eine Flanke auf der man rauf oder in der anderen Richtung eben runter zählt.
Es gibt aber nicht nur rastende Drehgeber mit 2 Codes pro Schitt, sondern zig verschiedene Sorten:
Einige geben alle 4 Flanken von Rastung zu Rastung aus, einige 2 Flanken, davon einige beide Flanken außerhalb der Rastung, andere eine Flanke in der Rastung, eine außerhalb, und wieder andere nur eine Flanke zwischen den Rastpunkten. Bei Letzteren muss man also um 4 Rastschritte drehen, um alle 4 Flanken 1x zu sehen.
Neben den fertigen Drehgebern (Bourns, Alps, ...) gibt es außerdem auch Dinger, die Gerätehersteller direkt auf die Platine ätzen und mit Schleifkontakten versehen. Mit und ohne Rastung.
Wenn der Wert nun zwischen 2 Rastpunkten zappelt, ist mir das völlig Wumpe. Dort ändert sich der Wert sowieso. Nur in der Rastung muss er stabil sein. Also dürfen dortige Flanken nicht beachtet werden. Wie ich schon geschrieben habe: Nur eine Flanke zwischen den Rastpunkten, die man beachtet.
Eine Filterfunktion habe ich die letzten 20 Jahre nicht vermisst.
Nur in der Rastung muss er stabil sein. Also dürfen dortige Flanken nicht
beachtet werden. Wie ich schon geschrieben habe: Nur eine Flanke zwischen
den Rastpunkten, die man beachtet.
Die Panasonic EVE Encoder sind ein Beispiel. An beiden Flanken von Signal A muss der Pegel von Signal B ausgewertet werden, um die Dreh-/Zählrichtung zu bestimmen und entsprechen hoch oder runter zu zählen. An den Rastpunkten passiert in der SW nichts. Die Auflösung liegt hier bei 1/2 Zyklus pro Rastung.
Bei Vertauschung von A und B hätte man an den Rastpunkten instabile Verhältnisse mit Pendelei.
DIE Routine, die ohne weitere Parametrierung mit allen Drehgebern zusammen arbeitet, gibt es nicht!
Und das ist vermutlich auch der Grund dafür, dass viele damit immer wieder Probleme haben.
Bei Drehgebern mit Rastpunkt wechseln mindestes zwei Codes von Punkt zu
Punkt.
Unsinn
Unsinn = Ausnahmen bestätigen die Regel.
Ich bin erstaunt, dass sowas hergestellt wird (ECW D0009). Es wird wohl Anwendungen geben, bei denen 9 Zyklen pro Umdrehung von Vorteil sind...
Da ist das Auslassen des Richtungswechsels störend.
Der Bourns ECW ist ein hochwertiger Drehgeber, der nicht auf einem Schaltpunkt einrastet. Ansonsten müsste ich ihn als "unbrauchbar" einstufen.
Die empfohlene Beschaltung ist interessant. Debounce mit MC14490 und 5ms delay. Also eine 5ms Abtastrate zum Entprellen. Das ist recht lang für einen Drehgeber, aber notwendig bei einer maximalen Prellzeit von 5ms.
Beim allen ECW ohne Rastung, würde ich den Richtungswechsel auslassen, um ein "Flattern" zu vermeiden, wenn er auf einem Schaltpunkt stehen bleibt.
Eine Universallösung gibt es nicht. Parameter die ich sehe:
Drehgeschwindigkeit: Eine höhere Abtastrate erhöht die Prellwahrscheinlichkeit. Hier sind andere Maßnahmen zum Entprellen erforderlich. Oder man nimmt ein leichtes Prellen in Kauf. Ignoriert man den Richtungswechsel, kann die Abtastrate beliebig erhöht werden, da das Prellen effektiv herausgefiltert wird.
Halten auf einen Schaltpunkt: Hier sollte der Richtungswechsel, auf Schaltpunkt ebene, ignoriert werden. Das ist nicht zwingend der Rastpunkt. Damit wird das "Flattern" auf dem Schaltpunkt zuverlässig verhindert.
"mindestens" ist keine Regel, sondern ein harter Grenzwert ;-)
Ihr nehmt es aber sehr genau. Gut so.
Für mich war es überraschend, dass man sowas herstellt. Ich frage mich aber auch, wann man Drehgeber braucht mit einem Rastpunkt auf jedem Schaltwechsel. Zumal 36 Rastungen auch mit zwei Schaltwechseln problemlos machbar sind und einfacher zu handhaben.
Für mich war es überraschend, dass man sowas herstellt. Ich frage mich
aber auch, wann man Drehgeber braucht mit einem Rastpunkt auf jedem
Schaltwechsel.
Wahrscheinlich gar nicht, aber es gibt genügend Produkte, bei denen die Entwickler nicht weiter denken als bis zur Mittagspause! Oder die Toleranzen der Produktion einfach nur grottenschlecht sind.
Nein. Damit, dass es Ausnahmen gibt, ist Deine Aussage einfach nicht zutreffend.
"Ich brauche für meinen Wagen mindestens 15000€!" "Ich biete ihnen 5000!" "Deal!"
Eine höhere Abtastrate erhöht die
Prellwahrscheinlichkeit. Hier sind andere Maßnahmen zum Entprellen
erforderlich.
Nein, es ist überflüssig!
In der nächsten Rastung passt der Wert wieder!
Es sei denn, Du drehst so schnell, dass das Nutzsignal kürzere Dauer als die Prellzeit hat. Da filterst Du dann aber auch nichts mehr.
Irgendwann werden die Strukturen auch zu klein.
um 18 oder gar 36 komplette Zyklen kostengünstig unterzubringen.
Das sag mal denjenigen, die auf einer Umdrehung 25000 Zyklen unterbringen. Kostengünstig sind die in Relation zur Leistung immer noch.
Es muss nicht alles immer billig, billig beim Buchhändler sein.
5x_Rotary_Encoder_Matrix.png
(17 KB)
