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
Verstehe ich das richtig, das da nur jede zweite fallende Flanke auf Spur A gezählt wird? Oliver
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
>Oder habe ich die Frage falsch verstanden ?
Eigentlich nicht.
Gezählt wird m.E. im folgenden Cadeabschnitt:
1 | if (buffer==CCW_SEQ) pulse++; // Sequenz CCW vollständig ? |
2 | 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
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
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
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
>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
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
> 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
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
mea culpa.... Im Code steht Inkrementalgeber.... naja 1/2 3 Uhr früh.... Phagsae
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
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:-)
>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
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.