64 CPR Drehencoder am Pi 2

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hi,

    bei meinen Überlegungen zur Optimierung meines Sliders will ich den Antrieb mit einem 12V Motor testen, der einen 64 CPR Drehencoder verbaut hat - konkret handelt es sich um diesen Motor.

    Der verbaute 64 CPR Encoder kann - laut Datenblatt - mit 3,5 bis 5V betrieben werden. Schade eigentlich denn 3,3V wären mir lieber gewesen und das führt auch zu meiner Frage. Sehe ich das richtig, dass ich - um den Encoder am Pi 2 nutzen zu können - einen Logic Level Shifter vor die GPIO des Pi hängen sollte um ihm ein langes Leben zu bescheren? Oder hat einer von Euch soeinen 64 CPR Encoder / Hall Sensor schon mal in den Fingern gehabt und ihn mit 3,3V - die der Pi liefert - getestet?

    Laut Datenblatt soll er Hall Sensor ja nur maximal 10 mA ziehen, was mit den 3,3V des Pi vereinbar wäre.

  • Hallo.


    Der verbaute 64 CPR Encoder kann - laut Datenblatt - mit 3,5 bis 5V betrieben werden. Schade eigentlich denn 3,3V wären mir lieber gewesen und das führt auch zu meiner Frage. Sehe ich das richtig, dass ich - um den Encoder am Pi 2 nutzen zu können - einen Logic Level Shifter vor die GPIO des Pi hängen sollte um ihm ein langes Leben zu bescheren? Oder hat einer von Euch soeinen 64 CPR Encoder / Hall Sensor schon mal in den Fingern gehabt und ihn mit 3,3V - die der Pi liefert - getestet?


    Levelshifter auf jeden Fall... die kosten ja recht wenig.


    Laut Datenblatt soll er Hall Sensor ja nur maximal 10 mA ziehen, was mit den 3,3V des Pi vereinbar wäre.


    ...was soll mit 10mA und 3,3V vereinbar sein ?... nix.
    10mA ist viel zu viel. 2mA auf Dauer, mehr nicht.

    gruß root


  • ...was soll mit 10mA und 3,3V vereinbar sein ?... nix.
    10mA ist viel zu viel. 2mA auf Dauer, mehr nicht.

    Hi root,

    ich hatte irgendwie 16mA im Hinterkopf, die man maximal über die GPIO Leiste von einem Pin bekommen kann, daher das 'vereinbar'. Aber mit den max. 2mA auf Dauer ist wohl klar, dass ich auf die 5V Schiene gehen muß und einen Level Shifter vor meine GPIO Pins hänge...

    Die 2mA reichen dem Level Shifter?

    Einmal editiert, zuletzt von doing (10. März 2016 um 14:34)


  • Die grosse Frage ist, ob der PI schnell genug die Impulse auswerten kann

    Daher meine Frage ob einer der Anwesenden vielleicht schon Erfahrungen mit soeinem 64 CPR Encoder am Pi gemacht hat.
    Wichtig zu wissen ist natürlich, dass der Motor nur 200 U/Min macht.

    Einmal editiert, zuletzt von doing (10. März 2016 um 14:40)


  • das ist imho ein begründeter Einwand (Latenzzeiten).
    -> Hier <- wäre noch was zum Thema Entprellen ... das dürfte auch ziemlich wichtig sein.

    Ob das in meinem Fall relevant ist muss ich sehen, aber jetzt schonmal Danke für den Link! Aktuell laufen 3 verschiedene 12V Motoren über einen Adafruit Motor HAT und ich kann mich nicht beschwerden - der HAT schafft es alle Motoren recht geschmeidig zu steuern.

    Mir geht es eigentlich nur noch darum, dass ich die Verfahrwege in der Strecke steueren können möchte und dazu natürlich wissen muss, wie weit sich der Schlitten auf dem Slider schon bewegt hat - daher der Ansatz mit dem 64 CPR Encoder. Am Ende will ich steuern können wie lange der Motor beschleunigen, konstant fahren und wieder abbremsen soll - je nach vorgegebener Strecke.

  • Hallo Doing.

    .
    Die 2mA reichen dem Level Shifter?


    ..auf jeden Fall.

    Vlt. noch ne kurze Erfahrung von mir zu den Latenzzeiten.
    Ich kämpfe seit über nem Jahr mit nem 32"er Teleskop mit 4-Achsensteuerung/Decodern, und kriege es nicht 100%ig in Griff.
    Die 4 Decoder werden per Interrupt quasi parallel abgearbeitet.
    Das Problem seh ich beim RasPi in der Interruptstruktur.
    Der Raspi kann letztlich keinen "echten" Interrupt, da der an die DAM Taktfrequenz gekoppelt ist.
    Das reicht auch normalerweise vollkommen, aber wenn's kritisch wird?
    Bin im Moment dabei, das von nem 20MHz 6480 Z80 Derivad erledigen zu lassen, der mit dem RasPi gekoppelt ist.
    Bin ich aber noch am beißen... wird so Frühsommer werden.
    Das mal nur so nebenbei.

    gruß root

  • Hi,


    ... mit 4-Achsensteuerung/Decodern, und kriege es nicht 100%ig in Griff.
    ...


    naja ... wenn Du bei 4 Achsen bei 90% bist, dann sollte eine schon funktionieren ;)


    ...
    Der Raspi kann letztlich keinen "echten" Interrupt, da der an die DAM Taktfrequenz gekoppelt ist.
    ...


    naaa ... ich würde eher sagen, dass das daran liegt, dass Du im Userland unterwegs bist und demzufolge keinen Einfluss auf die Dir zugewiesenen time-slices ...
    Der DMA-Takt sollte schon ausreichen und mit einer vernünftigen lib ( z.B. pigpio ) kann man das minimieren.
    Im Zweifelsfall den EMLID RT-Kernel draupacken ... aber ich glaube, das wird nicht nötig sein.

    cheers,
    -ds-

    PS: wie wird das bei CNC-Maschinen gemacht? Ich glaube, da sind die Führungsschienen irgendwie codiert - das wird dann vermutlich über den Widerstand oder was weiss ich berechnet. So was wäre natürlich genial, weil damit wäre man raus aus der "Pseudo-"Interrupt Verarbeitung.

  • Hi -ds-


    naja ... wenn Du bei 4 Achsen bei 90% bist, dann sollte eine schon funktionieren ;)


    ...eben nicht, wenn ich Decodersignale verliere, weiß ich nicht mehr, ... wo guckt der jetzt hin ???
    Normalerweise reichen 2 Achsen.Deklination und Rektaszension.

    Ich habe vor lauter Verzweiflung gewagt, ein 2. kleines "Suchteleskop" auf das Hauptrohr gepflanzt, das Polaris im Fokus behält, also quasi gegenläufig fährt.
    Beide Verfahrenswege werden verglichen und versucht zu korrigieren.
    Die ganze Koordinatenumrechnung im Bezug zur Erdrotation unter einen Hut zu bekommen, war wie ein innerlicher "Reichspateitag" :D
    Bei visuellen Beobachtungen ist absolut kein Fehler erkennbar.
    Mist sind Langzeit-Tiefraumaufnahmen bei so ~8Std, hier muss ich letzlich "blind" fahren, und mich auf die Decoder verlassen... und hab Schlieren

    [quote='dreamshader','http://test.forum-raspberrypi.de/forum/index.ph…9618#post209618']
    Der DMA-Takt sollte schon ausreichen und mit einer vernünftigen lib ( z.B. pigpio ) kann man das minimieren.
    [/quote

    PIGPIO ist Pflicht bei sowas ... :D

    gruß root

    Einmal editiert, zuletzt von root (10. März 2016 um 19:25)

  • Hi,

    ich habe jetzt mal mit dem Motor / CPR Encoder, einem Logic Level Shifter und PIGPIO herumgespielt und was soll ich sagen - dank PIGPIO schafft es der Pi 2 Problemlos die Werte vom Motor auszulesen, verlorene Counts konnte ich - zumindest anhand der ausgegebenen Werten - bisher nicht ausmachen.

    Doof ist, dass der Encoder - bei identischer Speed und Laufzeit des Motors - im Vorwärtslauf anders zählt als im Rückwärtslauf. Fange ich bei 0 an und lasse den Motor beschleunigen, eine Sekunde Vorwärts laufen und dann abbremsen, dann lande ich bei Beispielsweise 450 Counts. Das Gleiche Rückwärts kommt dann nicht bei 0 sondern bei -8 zum stehen, im nächsten Durchlauf dann bei -16. Die tatsächliche Drehzahl des Motors scheint also, je nach Laufrichtung des Teils, unterschiedlich zu sein. Ich vermute die Reibung im Getriebe als Ursache. Mal sehen ob sich das noch ändert wenn der Motor eingelaufen ist und wie ich das kompensieren kann.

    Jetzt muss ich erstmal schauen wie ich den Motor Treiber Code und den PIGPIO Encoder Code zusammengewürfelt bekomme... ;)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!