Drehimpulsgeber per Hardware auslesen?

[dreadbrain]

Hallo,
ich bräuchte eine Schaltung mit der ich einen Drehimpulsgeber auslesen kann.
Ich bräuchte ein Signal für Links/Rechts und einen Takt.
Hab dazu schon ein paar Schaltungen gefunden:
z.B.
http://www.elektrik-trick.de/sminterf.htm
oder
http://www.dse-faq.elektronik-kompen...e-faq.htm#F.29

Hat jemand eine solche oder andere Schaltung schon mal erfolgreich mit einem mechanisch Drehgeber in Betrieb genommen?

Oder sollte ich doch einen kleinen Atmega spendiern der diese Auswertung dann übernimmt?

Nur welche Methode is da die Beste?
Polling über Timer
oder Pin-Change Interrupt
oder die
http://www.mikrocontroller.net/topic/1503
und den Automaten in Bascom auf einen ATmega8 draufspielen und dann die jeweilige Operation(plus oder minus) auf die enstprechenden zwei ausgangspinns umcodiern?

Der Controller wäre nur für diese Aufgabe zuständig und der Encoder prellt meiner Meinung nach relativ stark.
(bei csd-electronics nach PEC11 suchen)

www.csd-electronics.de

Der Encoder wird per Hand bedient und sollte schon einigermaßen präzise funtkionieren da eine genaue Eingabe gewünscht wird.

Das Ausganssignal(takt, Links/rechts) wird wiederum einen Controller zugeführt, der aber durch andere Tätigkeiten schon sehr ausgelastet ist.
Ich möchte dadurch dem 2.Controller die Arbeit ersparen den Encoder andauernd zu beobachten und auszuwerten. Er soll praktisch nur an einen Interrupt einen Takt bekommen und dann schauen was das Links/Rechts Signal angibt und dadurch dan die Variable etc. verändern.
Dadurch das da nix mehr prellen sollte sollte der 2. Controller mit der Auswertung der aufbereiteten Signale keine Probleme mehr haben.


Wie kann ich dies Aufgabe am besten lösen?

mfg Benedikt

PS:Sorry für den x. Encoder Thread, aber ich hab dazu keine konkreten Informationen gefunden und weis auch nicht welche Methode die Beste ist solch einen Drehimpulsgeber mit einen µC auszuwerten.

[PICture]

Hallo dreadbrain!

Ich habe so ein Encoder z.B. für Menüsteuerung benutzt und in

https://www.roboternetz.de/wissen/in...w._Drehencoder

kannst Du einen ausführlichen Programmablaufdiagram finden, den Du nur in Bascom für einen ATmega8 "übersetzen" brauchst.

Ich hoffe, dass es sogar mit einem µC gehen sollte, da als die zum Entprellen min. 10 ms nötige Verzögerung (Warten), kann jeder immer sich wiederholender Unterprogramm mit entsprechender Laufzeit (z.B. Displayausgabe) benutzt werden, was den µC kaum zusätzlich belastet.

Du kannst das mit zwei µC realisieren, ich glaube aber nicht, dass es einfacher wäre, weil z.B. anstatt des Encoders der zweite µC abgefragt werden müsste oder das laufende Programm bei jeder Betätigung des Encoders per interrupt für einige Zeit unterbrochen würde.

MfG

[Slowly]

Moin !

ein HCTL-2000 von HP könnte die Drehgeberauswertung übernehmen. Der kann jederzeit ausgelesen werden und dein µC kann sich um wichtigere Dinge kümmern.
Gruß
Slow

[dreadbrain]

Hi,

@picture
hab mir dein PAD mal angesehen.
Kommt das mit Prellen klar?



Wenn ja dann würde ich das auf einen kleinen µC spielen und die Ausgabe so erweitern das bei decr ein Takt mit 0 an Rechts/Links entsteht und bei incr ein Takt mit 1 an Rechts/Links.

Würde es nämlich gerne trotzdem auf einen kleinen extra Controller auslagern da:

1. Der Haupt-µC is relativ beschäftigt
-Kommunikation mit 3TWI slaves(mindestens 5mal pro Sekunde an 2 der 3 ein Dabenpaket mit 16 Wörtern senden)
-Kommunikation mit dem PC per RS232,
-je 2x8 bit für Porterweiterung(In/out), davon 16 taster die entprellt werden müssen
-Timergesteuerte Aufnahme/Wiedergabe von Werten(mind. 5 werte pro Sekunde aufnehmen und mind. 2 andere Wiedergeben)
und dann noch ein relativ Umfangreiches Menü
etc.

2. Ich würde mir gerne so ein "Modul" mit Drehgeber bauen, das ich dan später nur noch an weiter Schaltungen anschließen muss und dann nur bei jedem Interrupt auswerten ob Rechts oder Links gedreht wurde und je nach dem decr oder incr.

Aus diesen zwei Gründen würde ich mir gerne so eine Art "Signalaufbereiter" für die Encoder bauen.

@slowly

Wo bekomme ich den HCTl 2000 her?

mfg Benedikt

[Slowly]

Naaa Deadbrain,

da hast Du mich aber erwischt.
So wie es aussieht, wird das Teil nicht mehr hergestellt.
Es ist schon ein paar Jahre her das ich mich das letzte Mal mit dem Baustein beschäftigt habe.
Avago stellt aber scheinbar einen Nachfolger HCTL-2022 her.
Im RS-components Katalog ist der auf jeden Fall zu finden.
Gruß
Slow

[PICture]

Ja, der Drehencoder wird dank der ca. 10 ms Wartezeit zwischen zwei nacheinanderfolgenden Prüfungen entprellt.

Bei deiner Kodierung wird ein bit die Richtung zeigen. Der zweite bit (von dir als Takt genannt) könnte Anliegen des neuen Wertes signalisieren. Dieser bit sollte dann nach dem Ablesen vom µC gelöscht werden. Wenn es genug oft abgefragt würde, dass keine Änderung verloren gehen könnte, lässt sich das ganze auch hardwaremässig mit ein paar digitalen ICs (ohne µC) realisieren.

MfG

[dreadbrain]

Hi,
@picture

Hättest du einen Schaltplan oder eine Idee wie ich das mit einzelnen Digitalgattern lösen könnte?

@ slowly

So weit ich weis kann man bei RS nur als Firma bestellen oder?

mfg Benedikt

[PicNick]

Wenn du schon bereit bist, dafür einen eigenen Baustein zu nehmen, dann nimm doch gleich irgendeinen Mini-Wuzi-Controller und programmier' ihn nach deinen Bedürfnissen.

[PICture]

@ dreadbrain

Eine Idee habe ich schon, aber brauche noch Zeit um sie genau zu überdenken und skizzieren. Es wäre sehr schön, wenn du die Portpins vom µC genau definieren könntest, oder sollten es, wie ich oben vorgeschlagen habe, 2 Eingänge zum Einlesen und 1 Ausgang zum Löschen sein?

MfG

[dreadbrain]

Hi,

@picture

Es wäre möglich einen Interrupt-Pin zu benuten und wenn nötig auch 2 andere Pins.

Wenn ich meine Idee so überdenke mit einem Takt und einer Richtung, dann kann es sein der 2. Controller ein paar Impulse verliert.
Mit dem Lösch-Signal hört sich das besser an.

Nur da muss der Hauptcontroller genug oft antworten sonst verlier ich auch die Impulse, oder versteh ich das falsch?

mfg Benedikt