15Bit Absolutwinkelgeber auslesen

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

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • 15Bit Absolutwinkelgeber auslesen

      Hallo,
      zur Zeit versuche ich mich wieder in Bascom einzuarbeiten und das mit einem für mich schwierigen Vorhaben.
      Ich möchte einen Absolutwinkelgeber mit 15 parallelen Signal-Ausgängen auslesen, auswerten, umrechnen und den Winkel
      auf einem 1602 LC Display ausgeben.
      Meine Frage ist, ob es eine fertige Funktion in Bascom gibt mit der ich "einfach" umgehen kann.
      Ich habe schon nach codeschnipseln geschaut, welche meinem Problem ähnlich ist, aber bisher nichts passendes gefunden. Immer
      nur Drehgeber.
      Oder kann mir da jemand auf die Sprünge helfen? (Hallo Welt funtioniert schonmal) :whistling:
      Gruß und vorab Danke
    • Olly schrieb:

      Ich hatte an den Atmega8 gedacht, könnte aber natürlich einen anderen nehmen.
      Der Atmega8 hat zwar genug freie IO Pins (22 Stk), aber du willst ja sicher noch einen Programmieradapter benutzen (3 Pins) dazu noch einen Quarz (2 Pins) , ein Display (6 Pins), serielle Schnittstelle (2 Pins) und Taster und LED (2 Pins)
      In minimaler Beschaltung mit Programmieradapter, Quarz und einer seriellen Ausgabe könnte es gerade reichen.
      Mir wäre es zu knapp, ich würde hier auf einen Atmega 16 aufwärts gehen, der hat genug Pins und das Mapping auf die Zählvariable ist einfacher und schneller, wenn du ganze Ports benutzen kannst

      Olly schrieb:

      Der Winkelgeber ist ein 15bit von Codechamp.
      Das ist keine gute Nachricht.
    • Olly schrieb:

      Und mich interessiert auch warum Codechamp eine schlechte Nachricht ist.
      Die Nachricht ist nicht gut, weil sie zu wenig Infos hat. Eine gute Nachricht wäre es gewesen, wenn du den Typ und das Datenblatt verlinkt hättest. Vielleicht läuft das Ding mit 24 Volt oder hat noch eine andere Schnittstelle.
      Ich mein, du hast ja hier 2 Baustellen, einmal die elektrische Anbindung und einmal die Software. Bevor eine Zeile Software geschrieben werden kann, muss die Elektrik passen. Und so wie ich das sehe, würdest du schon gerne die Software fertig haben, oder? (ist ja das Bascom Forum ;) )
    • Also, ich sag mal auf die Sprünge helfen meinte ich nicht unbedingt eine fertige Software aus dem Forum (ich sprach ja auch von Codeschipseln, welche ja auch hier im Forum zu finden sind).
      Aber wenn es unbedingt sein muss, nehme ich auch ein fertiges Programm
      Zum Encoder kann ich nur sagen und soweit hab ich ihn getestet:
      1. er braucht 2 Sapnnungen --> 5V und 15V mit gemeisamen GND.
      2. er hat 15 Ausgänge welche jeweils von 0V auf 5V, bzw 5V aud 0V wechseln, je nach Winkel. Im Prinzip war das meine Eingansfrage.
      Den Rest der Hardware werde ich dann passend gestalten.
    • Olly schrieb:

      meinte ich nicht unbedingt eine fertige Software aus dem Forum
      das meinte ich auch nicht, du brauchst aber eine saubere elektrische Anbindung

      Olly schrieb:

      er hat 15 Ausgänge welche jeweils von 0V auf 5V, bzw 5V aud 0V wechseln
      dann legst du die auf die Ports deines AVRs, also Ausgänge 1 bis 8 an A0 bis A7 und die Ausgänge 9 bis 15 an C0 bis C6.
      Im Programm kannst du die beiden Ports direkt in 8 Bit Variablen (Bytes) einlesen, die auf eine 16 Bit Variable ge-overlayed sind.
    • Olly schrieb:

      @tschoeatsch
      Danke, aber ich versuche erstmal in Bascom es mit evtl. einem Atmega zu realisieren.

      und Danke Michael Admin, die Info ist ja mal ein Anfang. Ich werde darauf aufbauen.
      mein Vorschlag braucht schon noch ein (bascom)-Programm. Du sparst halt viele pins am Kontroller und mit shiftin hast du die Daten ratzfatz in einer Variablen.
      Raum für Notizen

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

      -----------------------------------------------------------------------------------------------------
    • Ich bin doch schon einen Schritt weiter gekommen, mit dem Simulator und dem Atmega8.
      Habe die 15 parallelen Eingänge und ein Display mit 4 Bit Ansteuerung. Später werde ich wohl schon zu einem Atmega16 kommen und einer 8 Bit Ansteuerung
      zum Display. Ich erhoffe mir eine etwas schnellere Anzeige... und wenn mir das noch zu langsam ist vlt. eine 7 Segment Anzeige.
      Auf dem Simulator mit Display werde alle Eingänge mit 1 und 0 ausgegeben und der Dezimalwert. Jetzt kommt nur noch die Umrechnung und das Grundgerüst
      steht schonmal.
    • Pluto25 schrieb:

      in etwa 30 mal so viel Zeit wie parallel nötig ist.
      Wir haben da verschiedene Auffassungen von ratzfatz.
      was nützt eine superschnelle Zeit bei parallelem Einlesen, wenn die Daten/Winkel garnicht so schnell abgelesen/kontrolliert werden können, wie sie sich ändern. Da muss man wohl einen Kompromiss zwischen der erforderlichen Ablesezeit, dem "schnellen" Einlesen und der benötigten Pin-Anzahl treffen.

      Bei einem 16MHz-Crystal-Clock und 15-bit seriellen Daten würde das Einlesen irgendwo bei 2us liegen, ob der Winkelgeber so schnell liefern kann?
    • Olly schrieb:

      etwas schnellere Anzeige...
      Für eine High speed Kamera? Mit vier Bit ist das Lcd erheblich schneller als das Auge erkennen kann. Da ist selbst bei I2c und 1Mhz Avr Clock noch so.

      Ulrich schrieb:

      Bei einem 16MHz-Crystal-Clock und 15-bit seriellen Daten würde das Einlesen irgendwo bei 2us liegen, ob der Winkelgeber so schnell liefern kann?
      Rechne nochmal, aber egal ob es 300ns oder 10ms sind. Ein Quarz und zwei Chips zusätzlich sind unnötiger Ballast.
    • Habe gerade mal auf codechamp nachgeschaut und finde dort eine LSB-Geschwindigkeit von 50kHz => 20us
      Mit 16MHz crystal meinte ich einen Arduino-Quarz, aber, wie du schon vermutest, wird Olly mit 8Mhz intern arbeiten wollen. a_27_b277ca12

      Sicherlich sind zwei zusätzliche Chip gemessen an einem fertigen Arduino-Board etwas aufwendig, aber irgendwo müssen 15 Leitungen angeschlossen werden, entweder bei den zwei zusätzlichen Chips oder beim Atmega. Ein unter diesem Aspekt vielleicht kleiner Vorteil wäre, die zwei zusätzlichen Chip in unmittelbarer Nähe des Winkelgebers anzuordnen, da 5 Volt ja vorhanden ist, und dann nur noch ganz wenige Leitungen zum entfernter angeordneten Atmega zu führen.

      Olly hat sich noch nicht geäußert, wie und wo er den Atmega 8/16 aufbauen will. a_20_e8d7189d
    • ulrich schrieb:

      Olly hat sich noch nicht geäußert, wie und wo er den Atmega 8/16 aufbauen will.
      Naja, den Atmega einfach eine kleine Platine mit dem "Hühnerfutter" drum rum, evtl noch Eingabe-Taster (ja, ich weiß, ab jetzt reicht der Atmega8 nicht mehr aus).
      Das Ganze in ein Gehäuse mit der passenden Buchse, an der der Winkelgeber angeschlossen wird. Die Kabellängen von Buchse zum Winkelgeber sind ca. 30 cm.
      Am aller besten die Schaltung mit einem Stepup Wandler mit 12V auf 15V bzw. 12V auf 5V mit Akku betreiben. Wobei evtl. das nächste "Probelm" mit der Entstörung
      des DC-DC Wandler kommen könnte.
      ABER ich wollte erst einmal das Programm zum laufen bringen, bevor ich an den Rest gehe :)
    • Ich würde gerne mal wissen wollen, für welche Applikation die Drehgeberanzeige verwendet wird und wie viele Inkremente der Drehgeber pro Umdrehung hat.

      Vielleicht reichen dann auch 8 Bit aus vom Inkrementalgeber und es klärt sich die Diskussion, ob nun seriell oder parallel eingelesen wird.

      Wenns nicht schnell gehen muss, geht evtl auch mit I2C-Bus. Damit lassen sich Displays ansteuern und Tasten einlesen.
      Damit wären dann ne Menge an Pins für den Inkrementgeber frei. Wobei man den auch an den I2C-Bus hängen könnte.

      Aber wie man es auch macht, gehts irgendwo immer um Anzahl Pin's versus Geschwindigkeit.
      Das hängt eben von der Anwendung ab.
      Da muss der Olly mal ein Wort sprechen und uns aufklären.