Encoder auswerten/entstören

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Encoder auswerten/entstören

      a_475_f10f3094

      der Bascom -"encoder"-Befehl funktioniert ja schon großartig, aber im Vergleich zur industriellen Variante gibts da schon noch einen Unterschied.
      Wie machen die das bloß? Wenn ich am Encoder eines Sony DAB- Receivers drehe, wirkt alles so mühelos präzise. Mein Encoder hingegen wirkt immer etwas nervös.
      Wenn man in eine Richtung dreht und loslässt, kommt es mal vor, dass noch eine Rastung in die entgegengesetzte Richtung erkannt wird.
      Schnelle Richtungswechsel werden auch nicht so dankbar entgegen genommen (tänzelt im ersten Moment hin und her).
      Hat jemand Erfahrungen im "Bändigen" und "Zämen" von Encodern? Das Datenblatt von Alps (mein eingestzter Encoder) emphiehlt einen R/C Filter. Das habe ich auch gemacht, brachte aber keine Veränderung.
      Wait Befehle in der Auswertung sorgen eher fürs Überspringen/ Nichterkennen von Rastungen. Wie sieht das mit Encoder-Decoder-ICs aus? Es gibt ja ferige Bausteine, die Drehencoder auswerten. Sind die für höhere Ansprüche vorzuziehen?
      Also ich versuche nur das Encoder-Verhalten von Schulnote 3+ auf...sagen wir mal glatt 2 zu bringen. Hat sich mal jemand die Mühe gemacht, Finetuning vorzunehmen?
      Für Tipps/Empfehlungen wäre ich dankbar!
      Dateien
    • In der industriellen Fertigung für Home-Geräte werden wohl eher die Prozessoren mit spezieller Hardware für Encoder gefertigt damit sie präzieser reagieren.
      Ich habe auch schon Hardware gesehen, die einen C-Mos IC am Encoder haben, um sauberer schalten zu können. Also sowas wie einen Schmitt-Trigger.
      Ähnlich wie das hier:
      rot_enc.png

      Gibt aber bestimmt noch einfachere Schaltungen
      Eine Lösung habe ich nicht, aber mir gefällt Ihr Problem.
    • ichbinsmoin schrieb:

      ich glaube das dies die bessere Variante ist, dem Controller mit sauberen TTL Signalen zu füttern
      vermutlich nicht. Dem Code ist es egal ob das High von 1,237V oder 3,2V am Pin kommt. Die 1µ sind ausschlaggebend; sie wirkend entprellend,kontaktreinigend und vermeiden "Hyperspeed" . Sollte er nicht mehr schnell genug sein 0,47 oder 0,33 versuchen. Weit über 1µF wird aus kontaktreinigend kontaktzerstörend ;)
    • ichbinsmoin schrieb:

      Limo schrieb:

      Besser geht es mit 2 interrupt Eingängen und einer ISR für die Berechnung
      hatte ich schon gemacht.
      Isr_timer0:
      Timer0 = Timer0_reload
      B = Encoder(pind.3 , Pind.2 , Rechts , Links , 0)
      Return
      Das hast du falsch verstanden. Die Schalter des Encoders an interruptfähigen Eingangpins lösen interrupts aus und die Drehrichtung wird dann in der isr ausgewertet, ohne den Encoderbefehl von bascom.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Pluto25 schrieb:

      Die 1µ sind ausschlaggebend; sie wirkend entprellend,kontaktreinigend und vermeiden "Hyperspeed" . Sollte er nicht mehr schnell genug sein 0,47 oder 0,33 versuchen. Weit über 1µF wird aus kontaktreinigend kontaktzerstörend
      Eine Entprellung sieht anders aus.
      Die Kondensatoren hier zerstören die Kontakte in kurzer Zeit.
      Daneben gibt es lustige Spikes auf der Versorgung.
      Bei den geplanten langen Leitungen im Industrieumfeld wird das keinen Spass für den Entwickler.
    • tschoeatsch schrieb:

      Das hast du falsch verstanden.
      stimmt! Ich war so auf den Bascom Befehl eingeschossen, daß ich gar nicht mehr an die "manuelle" Auswertung gedacht habe.

      Michael schrieb:

      Die Kondensatoren hier zerstören die Kontakte in kurzer Zeit.
      wenn man bei gurgel auf Bildersuche geht, scheint das aber eine sehr häufige Variante zu sein. Insbesondere die Variante von djmsc in verschiedenen Versionen ist verbreitet.
      Ich probiere mal die six1 "auf die Schnelle". Wenns mir das nicht besorgt, dann muss ich an die Hardware.
      Danke erstmal für die Inspiration!
    • Nach meiner leidvollen Erfahrung kann ich nur folgendes vorschlagen :
      Die Methode nach Peter Dannegger hat bei mir zum Erfolg geführt.
      Mal danach Googlen.
      Einen oder beide Eingänge mit einem Interrupt versehen auszuwerten, hat bei mir nicht vernünftig geklappt.
      Wird auch von vielen Leuten nicht präveriert, da die Interrupts durch das Prellen wie wild geschmissen werden.
      Meine Hardware ist ein Xmega384C mit einem billigen Alps Encoder. Der Controller läuft mit 32MHz.
      Als C verwende ich nur 100nF über den Kontakten.

      Den Encoder verwende ich zum Navigieren in den verschiedensten Menüs und zur Sollwerteingabe.
      Pert Timer frag ich alle 500us die beiden Eingänge ab und lass sie durch die Routine laufen. Es wird dann eine Zählvariable Incrementiert oder Decrementiert oder halt so gelassen, wie sie ist.
      Die Reaktion findet dann im Hauptprogramm statt.

      Die Hardware im Xmega zu Encoder hab ich mit Bascom probiert, aber nicht zum Laufen gebracht...
    • Moin Düsentrieb!
      Ich habe die gleiche Anwendung: Display- Navigation und Sollwert-Eingabe. Habe jetzt auch einiges an Versuchen hinter mir.
      Bei mir ist ebenfalls ein billiger Alps am Start + Mega328@16Mhz /1ms Timer
      Die Danegger-Methode wird u.a hier beschrieben: rn-wissen.de/wiki/index.php/Dr…ODER-Befehl_mit_Anpassung
      Mandarin 15 erwähnte dies. Ich hatte bisher die Hannes-Lux Methode und die "on-the-fly" von six1 getestet. Die Hannes Lux war in meiner Programm-Umgebung eine
      erhebliche Verschlechterung. Die von six1 führte zur gleichen Perfomance wie der Bascom Befehl "encoder". Die Danegger-Methode probiere dann mal aus. Bin nun neugierig gworden.
      Ich betone nochmal, daß ich hier auf hohem Niveau jammere. Der Bascom encoder Befehl funktioniert nämlich 'ganz gut'.
      Ich fürchte, daß ich für noch bessere Ergebnisse mein Haupt- Programm komplett umstrukturien müßte. Außerdem könnte auch das relativ träge I2C- OLED nicht ganz hinterherkommen.
      Navigiert man mit dem Encoder (Ein Menü hoch und runter scrollen) können schon mal bei ganz wildem drehen Rastungen verschluckt- oder doppelt empfangen werden.
      Bleibt hingegen der Text stehen und nur eine Zählervariable wird geändert, ist das Ergebnis perfekt! Ich schließe daraus, daß der Encoder hervorragend ausgewertet wird, aber der Rest der Peripherie
      die Performance wieder herunterzieht. Bei meinem nächsten Projekt werde ich das Hauptprogramm an die Encoder- Auswertung ausrichten und nicht- wie jetzt umgekehrt.