mikrocontroller.net

Forum: Projekte & Code Einfache Drehgeberauswertung


Autor: phagsae (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Einfache Drehgeberauswertung.

Hier mal eine einfaches Beispiel einer Drehgeberauswertung.
Die Grundüberlegung ist dabei folgende:
Die Richtung und der Zählimpuls wird erst als relevant gewertet wenn die 
vollständige Abfolge der
Signale vorliegt.
Beim Vorliegenden Codeschnipsel handelt es sich um die Auswertung zweier 
magnetischer PickUp's auf einer drehenden Welle.
Wenn man von der Nullstellung ausgeht ( Beide Aufnehmer in Ruhe ) so 
ergibt sich folgende Kette.

Vorwärts ( CW ) 00->10->11->01
Rückwärts (CCW) 01->11->10->00

Also werden die „sicheren“ Sensorsignale einfach in ein Schieberegister 
geladen.
Irgendwann stellt sich einer  der beiden Zustände ein.
Also cw =0b00101101 oder ccw 0b01111000
Hier kann dann einfach ein Zähler inkrementiert oder dekrementiert 
werden.

Der Schaltpunkt kann für mech Drehgeber  mit Raste einfach angepasst 
werden.
Ist ZB eine mechanische Raste bei Übergang 1011 vorhanden so kann der 
Schaltpunkt rechts oder links daneben gelegt werden.
ZB 10_11_01_00
Zu beachten ist allerdings das beide Sequenzen zyklisch sein müssen 
sonst kann beim flattern zwischen 2 Werten eine Fehlstelle auftreten.
Also auf 00011101 für CCW muss 01110100  CW als „Gegen“ Schlüssel 
folgen.
Anfang und Ende sind jeweils Spiegelsymetrisch-Aber zyklisch tauschbar.
Flattert zB die Erkennung zwischen 11 und 01 so entscheiden erst die 
nächsten beiden Doppelbits
über die Richtung.

Die Routine ist komplett im Timer  Überlauf IRQ untergebracht –
Das ist für Zeit kritische Anwendungen wohl nicht optimal aber leicht zu 
ändern.

Da für eine prellfreie Erkennung jeder Pegel 4 mal Gleich und in Folge 
gelesen werden muss ist ein
Tastverhältnis von 5x Nutzsignal  wohl die  theoretische Grenze.
Da beide Sensor Signale in die Auswertung eingehen sollte das 
hoffentlich einigermaßen sicher sein.
Praktisch kann man das aus dem Fehler PIN mit einem Oszi bestimmen.
Allerdings sollte man auch mit der Abtastung nicht zu weit nach oben 
gehen.
Die Möglichkeit im Prellen 4 gleiche Signale zu gewinnen ist genauso 
warscheinlich wie alle anderen Kombinationen.
Erwartet man eine Prellzeit von 1ms sollte die Abtastung nicht viel 
kleiner ¼ ms sein.
Das Nutzsignal sollte dann wohl mindestens 2ms haben.

Zzgl werden noch folgende Sprünge von der Auswertung ausgeschlossen und 
als Fehler gemeldet.
00<->11 01<->10 ( Gray Code !)
Diese Kombinationen kann man leicht dadurch erkennen da diese als Summe 
3 ergeben.
Das sollte eigentlich gar nicht vorkommen-
Könnte aber durch Doppelprellen beider Sensoren oder durch 
Unterschreiten der Abtastfrequenz auftauchen.

Meine Lösung ist zugegebenerweise nicht so augetüftelt, aber leicht 
verständlich und hoffentlich leicht nachvollziehbar.
Also auch für Code-Grobmotoriker wie mich geeignet:-)

Der case Block mutet komisch an war aber die kleinste Lösung.
( kann man auch im asm listing sehen )
Über goto zu Streiten ist müßig....Have Fun !

Phagsae

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verstehe ich das richtig, das da nur jede zweite fallende Flanke auf 
Spur A gezählt wird?

Oliver

Autor: phagsae (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Oliver

Also mit /\ Flanken hat das jetzt absichtlich nichts zu tun.
Natürlich stecken in der Abfolge /\ Flanken.
Aber eine Auswertung erfolgt nicht.
Jeder verwertbare Impuls wird gezählt .
Aber für die Richtungserkennung benötig man nunmal volle 4 Zustande 
beider
Schalter/Sensoren.
A->0110  _/""\__/""\_
B->1100  ""\__/""\_

Das ergibt in fester Reihenfolge in ein Register geschoben
01_11_10_00 oder B vor A 10_11_01_00

Und das wird Ausgewertet.

Oder habe ich die Frage falsch verstanden ?

Phagsae

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Oder habe ich die Frage falsch verstanden ?

Eigentlich nicht.

Gezählt wird m.E. im folgenden Cadeabschnitt:
if (buffer==CCW_SEQ) pulse++;         // Sequenz CCW vollständig ?
else if (buffer==CW_SEQ) pulse--;   // Sequenz CW  vollständig ? --> Dann Zählimpuls 

und zwar wird immer dann weitergezählt, wenn jeweils eine ganze 
Codefolge (01111000 oder 00101101) eingetroffen ist. Dazu brauchte es 
aber jeweils zwei Flanken pro Kanal.
Oder verstehe ich das falsch?

Oliver

Autor: phagsae (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Oliver

Ja die letzte Auswertung erfolg in dem genannten Code

##
und zwar wird immer dann weitergezählt, wenn jeweils eine ganze
Codefolge (01111000 oder 00101101) eingetroffen ist.
Dazu brauchte es aber jeweils zwei Flanken pro Kanal.
Oder verstehe ich das falsch?
##

Das mit den Flanken bereitet mit Kopfschmerzen.
Flanken sind für mich etwas Dynamisches.
Ich definiere den Inhalt des Registers als "Zustände"
Aber ja !
Es braucht sogar 3 neue Zustände um von CCW auf CW zu kommen.
Aber das ist normal das benötigt die Richtungserkennung immer.

Phagsae

Autor: Roger Steiner (edge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen drehgeber 'entprellen' zu wollen ist ziemlich sinnfrei.
Wenns drum geht dass das Menu beim Billigencoder nicht flattert
-> Spielaufnahme mit einem count.
Desswegen rasten die meisten Encoder ja auch erst nach zwei 
Flankenwechsel.

Cheers, Roger

Autor: phagsae (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moinmoin...

>>Beim Vorliegenden Codeschnipsel handelt es sich um die Auswertung zweier
>>magnetischer PickUp's auf einer drehenden Welle.

Und selbst wen erschließt sich mir die logik nicht warum 2 unsichere 
Signale 1 sicheres ergeben sollen.

Natürlich kann man zur Menüsteuerung nach dem dem Motto arbeiten:
"Da tut sich irgendwas dann schalt ich mal irgendwie"
Die Pausen werden schon lang genug sein.

Aber das war s.o nicht der Sinn der Sache.

cu Phagsae

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Es braucht sogar 3 neue Zustände um von CCW auf CW zu kommen.
>Aber das ist normal das benötigt die Richtungserkennung immer.

Na ja, eine normale Auswertung zählt normalerweise jede Flanke einer 
Spur, und nutzt die zweite zur Richtungserkennung. Bei 4-fach-Auswertung 
werden dann sogar die Flanken beider Spuren gezählt, vorwärts wie 
rückwärts.

>Aber für die Richtungserkennung benötig man nunmal volle 4 Zustande
>beider
>Schalter/Sensoren.

Bei deinem Verfahren schon, aber wenn man es anders macht, nicht.

>Flanken sind für mich etwas Dynamisches.

Und? Angst davor?

Vermutlich benutzt du das Verfahren an einer schnell laufenden Welle. Da 
passt das sicher ganz gut. Für einen handbetätigten Drehgeber fände ich 
es blöd, wenn sich erst nach jeder zweiten oder vierten Raste was tut.

Oliver

Autor: phagsae (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Oliver...
Dachte ich mir schon da liegt wohl ein Missverständnis vor.
Natürlich zählt meine Routine die volle Auflösung des Gebers.
Eine Flanke kann man ja auch durch 2 Zustände beschreiben
Vorher (Flanke)  Nacher.
2 Flanken braucht jeder für Posion+Richtung macht 4 Zustände.
Und genau das macht der Code auch.

Der Drehgeber befindet sich ja immer in "einem" Zustand macht dann zum 
nächsten erkennbaren einfach 3 neue.

Mit ein Vorteil ist wie gesagt das der Code sich von schwingen zwischen 
2 Zuständen ( Drehgeber ohne Raste ) nicht irritieren lässt egal wie oft 
und heftig da hin und her geschwungen wird.

Es wird immer nur das vollständige und fehlerfreie "Laufmuster" 
gewertet.


A->0110 /""\_
B->1100 ""\__
Das ist für mich eine Position mit Richtung.
Also 4 Zustände beider Sensoren
Also 8 Bit muster im buffer Register

Ich denke jetzt ist es klar oder
habe ich da einen Denkfehler ??

Phagsae

Autor: Roger Steiner (edge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Eine Flanke kann man ja auch durch 2 Zustände beschreiben
> Vorher (Flanke)  Nacher.

Soweit sogut.

> 2 Flanken braucht jeder für Posion+Richtung macht 4 Zustände.
> Und genau das macht der Code auch.

Komische Beschreibung. Der Drehgeber kann sich zu einer Zeit in  einem 
von vier Zustaenden befinden. Mit einer Flanke wird in den naechsten 
oder vorherigen Zustand gewechselt. Ergo hat eine Flanke zwei 
Informationen, naemlich dass ein Schritt getaetigt wurde, und dessen 
Richtung.

> Mit ein Vorteil ist wie gesagt das der Code sich von schwingen zwischen
> 2 Zuständen ( Drehgeber ohne Raste ) nicht irritieren lässt egal wie oft
> und heftig da hin und her geschwungen wird.

Das glaubst nur du, das ist abhaengig von der pollfrequenz und genau auf 
deinen Testfall zugeschnitten. Hiermit kannst du nur einen viertel der 
Frequenz erfassen die eigentlich moeglich waere.

Was hast du damit eigentlich gebaut? Ich kann mir keinen Anwendungsfall 
vorstellen wo einen Encoder entprellen noetig sein soll.

Cheers, Roger

Autor: phagsae (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK Kritik angekommen....

Erstmal beschreibe ich wohl wofür das ganze gut sein soll.

Im vorliegenden Fall geht es um eine Hydraulisch angetriebene 
Ankerwinsch.
Letztlich ist ein Ketten Zähler das Endprodukt.
Also wieviel Kette ist draußen ?
( Für !Segler :Das ist ein wichtiger Parameter um den Anker richtig 
"einzufahren" )
Das manöver läuft im groben so:

1/Schiff in Ruhe an Ankerort
2/Kette entsprechend Wassertiefe raus
3/Dann Schiff Rückwärts
4/Kette entsprechend Geschwindigkeit zugeben. ( GPS-DATEN )
( Regelung Geschwindigkeit Kette per an/aus )
5/Bei 3-4 X Wassertiefe Kette Stop
Schiff Ruckt Anker ein.


Mechanisch macht das bzgl der Sensoren einiges an Ärger.
Die einzige brauchbare Möglichkeit die Sensoren unterzubringen bestand 
darin den Magnet in eines der Planetenräder des Getriebes 
unterzubringen.
Spielfreiheit ist hier ein Fremdwort.
Die Ganze Mimik Bugspriet&Kette&Kettennuß&Umlenkrolle&Planetengetriebe
Rattern und Schwingen.
Zwischen Winsch und Umlenkrolle hängt die Kette 2m frei über dem Deck
( länge nicht höhe )
Das gibt stehende Wellen in der Kette.
Also flattern die Impulse manchmal.

Ich benötige allerding keine Auflösung die größer als 1 umdrehung ist
Habe ja nur 1 auf dem Planetenrad.
ca 40 impulse pro Meter bei max 1000 U/min an der Welle
( Mehr währe Möglich aber nicht sinvoll )
1m Genaugikeit Reicht dem Anwender


Also stimmt Richtig.....
Bei einem Inkrementalgeber würde mein Code die Halbe Auflösung
unterschlagen.

(Von encoder wahr eigentlich nur am rande die Rede das man den Code auch 
für mech Drehgeber nutzen könnte .
Inkremntalgeber oder Winkelsensor taucht gar nicht auf )



>>Komische Beschreibung. Der Drehgeber kann sich zu einer Zeit in  einem
>>von vier Zustaenden befinden. Mit einer Flanke wird in den naechsten
>>oder vorherigen Zustand gewechselt. Ergo hat eine Flanke zwei
>>Informationen, naemlich dass ein Schritt getaetigt wurde, und dessen
>>Richtung.


Ja komisch und auch wieder nicht .
Das soll sagen:
Von einem beliebigem Zustand bis zum nächsten als gültig detektierbaren 
müssen in jedem Fall 3 , in richtiger sequenz , aueinander folgende 
Pegel eingelesen worden sein.



Abhilfe könnte folgende ungetestete erweiterung schaffen.
Man muss ja nur je 2 Schaltpunkte definieren.
Ander Fehlersicherheit sollte das eigentlich nichts Ändern.
Für beide Schaltpunkte CCW muss ja die komplette historie gewährleistet 
sein.


Wenn der Schlüssel verdoppelt wird gilt das für jeden Schlüssel einzeln.
Dh von Erkennung zu Erkennung gilt dann ein Abstand von 1
Aber nur in der Summe !


( einfach die Schaltmuster um eine Halbe Drehung schieben )


#define CCW_SEQ_1  0b01111000  // 01->11->10->00
#define CCW_SEQ_2  0b10000111  // 10->00->01->11

#define CW_SEQ_1   0b11010010  // 11->01->00->10
#define CW_SEQ_2   0b00101101  // 00->10->11->01

if (buffer==CCW_SEQ_1||buffer==CCWSEQ_2) pulse++;
else if (buffer==CW_SEQ_1||buffer==CW_SEQ_2) pulse--;

Ich habe keinen Inkrementalgeber - Kann also die Sache nicht testen.
Währe aber interessant .......



Punkt 2 die Polling Geschwindigkeit.
Hier könnte man nachbessern.

Mögliche Lösung:
Bim Auftreten des ersten Unterabtastungs Fehlers ( Gray code )
Den Puls zählen aber die Timer frequenz hochsetzen.

Verringern wenn die Prellroutine zB 4 Hintereinander einen stabilen aus 
4 Abtastungen bestehenden Zustand meldet.

Also könnte man das polling dynamisch Anpassen.

Klar eine Obergrenze bleibt natürlich.
aber man kann ja den Tiny auf 16 Mhz hochjubeln.

Hat den code eigentlich schon mal jemand ausprobiert ??

Phagsae

Autor: phagsae (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mea culpa....
Im Code steht Inkrementalgeber....
naja 1/2 3 Uhr früh....

Phagsae

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kürzer, knackiger, erprobt und gut ist immer noch das hier:

Beitrag "Drehgeber auslesen"

Funktioniert übrigens auch mit Zuständen, auch wenn man das auf den 
ersten Blick nicht sieht.

Oliver

Autor: phagsae (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar kenn ich:
Weshalb dieser satz ?

Meine Lösung ist zugegebenerweise nicht so augetüftelt, aber leicht
verständlich und hoffentlich leicht nachvollziehbar.
Also auch für Code-Grobmotoriker wie mich geeignet:-)

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Weshalb dieser satz ?

Als Umdrehungszähler mag das funktionieren. Als Drehgeberauswertung mit 
wechselnden Drehrichtungen tut es das nicht.

Die Pulse zählen in der einen Drehrichtung auf einer anderen Flanke, als 
in der anderen. Daher ist damit schonmal keine Positionserkennung zu 
machen.

Und weil du für einen Zählimpuls immer vier vollständige gültige 
Zustände einer Drehrichtung benötigst, gehen bei einer 
Drehrichtungsumkehr nach weniger als vier Zuständen Impulse verloren.

Mals dir auf. Mit allen Möglichkeiten.

Oliver

Autor: phagsae (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Oliver

Ja leider muss ich Dir ja in allen Punkten Recht geben.
Der Code taugt nix....
Schade eigentlich. Die Idee schien so vielversprechend..
Aber die Tabelle spricht da leider eine deutliche sprache.
Als Kettenzähler gerade noch verwendbar.
Also in die Tonne den Mist ....
Sollte hier ein Mod vorbeischauen .
Den Quatsch bitte ins Datennirvana schicken...

Phagsae

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.