-         

Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 27

Thema: Drehimpulsgeber per Hardware auslesen?

  1. #1
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    06.04.2006
    Ort
    Bayern
    Alter
    27
    Beiträge
    182

    Drehimpulsgeber per Hardware auslesen?

    Anzeige

    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.

  2. #2
    Erfahrener Benutzer Lebende Robotik Legende Avatar von PICture
    Registriert seit
    10.10.2005
    Ort
    Freyung bei Passau in Bayern
    Alter
    66
    Beiträge
    10.970
    Hallo dreadbrain!

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

    http://www.roboternetz.de/wissen/ind...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

  3. #3
    Erfahrener Benutzer Begeisterter Techniker Avatar von Slowly
    Registriert seit
    08.05.2004
    Ort
    24558
    Alter
    49
    Beiträge
    265
    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

  4. #4
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    06.04.2006
    Ort
    Bayern
    Alter
    27
    Beiträge
    182
    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

  5. #5
    Erfahrener Benutzer Begeisterter Techniker Avatar von Slowly
    Registriert seit
    08.05.2004
    Ort
    24558
    Alter
    49
    Beiträge
    265
    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

  6. #6
    Erfahrener Benutzer Lebende Robotik Legende Avatar von PICture
    Registriert seit
    10.10.2005
    Ort
    Freyung bei Passau in Bayern
    Alter
    66
    Beiträge
    10.970
    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

  7. #7
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    06.04.2006
    Ort
    Bayern
    Alter
    27
    Beiträge
    182
    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

  8. #8
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    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.
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  9. #9
    Erfahrener Benutzer Lebende Robotik Legende Avatar von PICture
    Registriert seit
    10.10.2005
    Ort
    Freyung bei Passau in Bayern
    Alter
    66
    Beiträge
    10.970
    @ 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

  10. #10
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    06.04.2006
    Ort
    Bayern
    Alter
    27
    Beiträge
    182
    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

Seite 1 von 3 123 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •