Hallo,

Zitat :

00 00 0 beide Leitungen führen low -> keine Bewegung 01 01 1 Phase A low, Phase B high -> Drehung z.B. nach links 11 10 2 beide Leitungen führen high -> keine Bewegung 10 11 3 Phase B low, Phase A high -> Drehung z.B. nach rechts

Nun, so stimmt das nicht (oder ich verstehe es falsch). Wenn sich der Zustand nicht ändert, dann gibt es keine Bewegung, egal bei welcher Kombination.

Wenn nun A die Wertigkeit 1 hat und B die Wertigkeit 2, dann kann man folgendes sagen (im Datenblatt eindeutig so dargestellt)
Wechsel von
1 -> 3 oder
3 -> 2 oder
2 -> 0 oder
0 -> 1 dann wurde im Uhrzeigersinn gedreht.

Bei Wechsel von
0 -> 2 oder
2 -> 3 oder
3 -> 1 oder
1 -> 0 dann wurde gegen den Uhrzeigersinn gedreht

Zwischen zwei unterschiedlichen Zuständen hat man 1/4 von 1/8 Umdrehung gemacht.

Wenn die EIN/AUS Zeit in jedem Kanal 50/50 wäre und die Kanäle 90° versetzt, dann hätte man bei 60 Umdr/min 31,25ms zwischen jedem Zustandwechsel. Angegeben sind aber zwischen 8ms und 2,5ms, also schon ganz schön mies. Und das Prellen ist mit 5ms angegeben - das vereinfacht die sache auch nicht.
Das Teil hat mechanisch 16 Rastungen, macht zwei Zustandswechsel pro Rastung - das sollte für eine Erkennung reichen.
Problematisch ist die Drehgeschwindigkeit. Man macht vielleicht nicht mit einer Handbewegung die vollen 360°, aber je nach Drehknopfdurchmesser doch locker 120°. Bei den angegebenen 60 Umdr/min wären das 1/3 sekunde - da muss man sich also beim Drehen schon sehr zurückhalten um vor lauter Prellen nicht Alles zu übersehen.

Prüfe also, ob die Verdrahtung in Ordnung ist. Schaltest Du eigentlich von 5V über den Taster direkt auf den Eingang, oder hast du das so aufgebaut wie in der Testschaltung vom Datenblatt?

Rafikus

Offtopic :

Nun, offenbar ist meine tolle Tabelle nicht sonderlich verständlich. Wir gehen nun erstmal davon aus, dass wir in diskreten Zeitabständen den Wert der Signale A und B erfassen. 00 wenn beide low sind, 01 wenn A low und B high ist, 10 wenn A high und B low ist und 11 wenn beide high sind. Beide Zwischenpostionen, nämlich 10 und 01 treten dabei nur auf, wenn gerade aktiv gedreht wird. Danach stellt sich entweder 00 oder 11 ein. Und hätte man meine vorherigen Beiträge zu der Tabelle gelesen, hätte man auch sehen können, dass diese Werte nicht direkt in die entsprechende Drehrichtung transformiert werden. Betrachtet diese Tabelle lieber als "Augenblickszustand" (wie soll man das nun wieder erklären ) und nicht als Tabelle, anhand der ich die Drehrichtung bestimme, indem ich die erfassten Bitkombinationen damit vergleiche. Ihr nehmt nun diese Bitkombination und berechnet daraus direkt eine Dezimalzahl; während ich diese Bitkombination als Graykode betrachte und ihn zuerst mal in eine Binärzahl wandle, bevor ich diese dann wiederum dezimal ausdrücke. Daher kommt auch das Missverständnis. Ist die Graykode-Zahl erstmal in eine Binärzahl gewandelt, kann man nämlich einfach sagen: beim Drehen nach links wird hochgezählt: 2,3,0,1,2, ... und beim entgegengesetzen Drehen wird nach unten gezählt, also 2,1,0,3,2,1, ... . Wenn ich dann, bääm, einfach das Vorzeichen der 1 bestimme, die ich hinzuaddiere, dann kann ich, nur aus dem Vorzeichen allein, die Drehrichtung bestimmen. Mit dem Prellen hatte ich erwähnt, das stellt speziell bei diesen Dingern von Pollin ein Problem dar. Ich hatte auch schon einen, der nur geprellt hat, man konnte auch beim besten Willen nicht 100% reproduzierbar die Drehrichtung bestimmen.

_________________


[ Diese Nachricht wurde geändert von: DonComi am 15 Sep 2010  0:28 ]

Nun, bei Deinem Wechsel von 0 nach 3 oder von 3 nach 0 sehe ich keine 1 bei der man das Vorzeichen bestimmen kann.
Eigentlich würde ich das in Hardware machen mit Richtung und Puls, aber es soll eben mit Software direkt im Rechner geschehen.
Du gehst davon aus, daß bei einer Raste 00 oder 11 ausgelesen wird. Mit der 11 bin ich einverstanden. Die 00 kann ich aber aus dem Datenblatt nicht entnehmen und wenn es gerade mal so ist, dann wird sich das bei der "Langzeitstabilität" von dem Teil bestimmt noch ändern.

Der Weg über den Greycode ist für mich ein Umweg, dessen Vorteil ich nicht erkennen kann.

Rafikus

@Rafikus:
Also die Verkabelung hat gestimmt.
Habs gestern Nacht noch umgelötet. Wenn ich einen der beiden andern Kabel als Masse definiert hatte, gabs nur noch 0 oder 2.

Bei der momentanen Verkabelung gibts 0,3 oder 1.

Ich habe den Encoder direkt über 5V des Gameports angeschlossen.

Wenn ich es nach der vorgeschlagenen Schaltung aufbaue kann ich es vermutlich nicht mehr abfrage, da 10kOhm doch eine Menge sind.

Ich muss zugeben, ich verstehe nicht wirklich was die Schaltung macht.
(Hatte sowas leider nie in der Schule - bereue es sehr).
Sind die Kondensatoren da, die Preller abzufangen?

Würde es denn einen Unterschied machen, wenn ich es so aufbaue?

Also mein Program erkennt inzwischen zu 80% die Drehrichtung richtig.
Nur beim Richtungswechsel braucht er komischerweise 3-4 Umdrehungen bis er ihn registriert.

Gruß Martin

Wie siehtn dein Programm aus?

Gerade bei 2 Bit pro Abtastung kann man sowas sogar per Lookup-Tabelle erledigen
(man erspart sich die Sonderfälle der Überläufe 3->0 und 0->3):

Man sampelt einen Wert (n), legt in an Bit0 und Bit1 ab, holt sich den Wert vom vorherigen Sample (n-1), schiebt in zwei Bits nach links und verknüpft ihn ODER mit dem aktuellen.
Dann hinterlegt man für sämtliche Möglichkeiten (sind bloß 8*2, also 16, also auch 2⁴) die Drehrichtung kodiert in eine Tabelle.
Den wie beschrieben zusammengebauten Wert nutzt man als Tabellenindex und kann dann ganz einfach die Werte auslesen.


Das schafft ein µC in ein paar Taktzyklen, wenn man sich ein wenig beim Programmieren anstrengt (Assembler).

Also, der Möglichkeiten sind verdammt viele. Irgendwo habe ich auch mal eine Library gesehen, die das so implementiert, wie ich beschrieben habe. Sooo doof kanns dann wohl nicht sein...

_________________

Also das Program erkennt die Drehrichtung eigentlich gut.
Ich habs so gemacht, dass wenn nur 0 oder 3 pro Raststellung kommt, er einfach die Drehrichtung behält.

Wenn ich schön fein langsam drehe, kriegt er den Richtungswechsel mit, aber nur dann.
Ansonsten dauerts immer ein paar Drehungen, bis einmal wieder eine "2" mitkommt.

So kann ichs also nicht lassen.

Da hilft es auch nix, das Programm umzustricken.

Der Rechner bekommt die Zwischenschritte nicht zuverlässig genug mit.
Assembler kann ich nicht. Deshalb würde ich den µController gern erstmal weglassen. Und sonderlich gut programmieren kann ich auch nicht.


Wie siehts denn mit der Beispielschaltung aus. Was macht die genau?

Ich poste jetzt einfach mal meinen Quellcode (Basic).

Code :

Private Sub Timer1_Timer() counter = counter + 1 If counter <= 60 Then 'Soll anhand der Zeitdifferenz feststellen ob es sich um eine Drehung handelt, wenn 2 Ziffern reinkommen counter = counter + 1 End If Dim JInfo As JOYINFO ppstate = pstate 'state ist aktuell, pstate ist der Status im Schritt davor pstate = state GetJoystick 0, JInfo state = JInfo.Buttons If JInfo.Buttons <> pstate And counter > 20 Then List1.AddItem (Str$(JInfo.Buttons)) If state = 2 And pstate = 3 Then 'Fall für rechts List2.AddItem "rechts" List2.AddItem "-----------------------------" dirstate = "rechts" counter = 0 ElseIf state = 0 Or state = 3 Then 'Fall wenn nur eine Zahl reinkommt (0 ist ok, 3 kommt normalerweise immer mit einer 2 oder 0 zusammen -> 3 alleine heißt, dass er den Zwischenschritt nicht mitbekommen hat) List2.AddItem dirstate List2.AddItem "-----------------------------" counter = 0 ElseIf state = 2 And pstate = 0 Then 'Fall für links List2.AddItem "links" List2.AddItem "-----------------------------" dirstate = "links" counter = 0 Else List2.AddItem "weiß nicht " & state & pstate End If End If End Sub

Zitat :

Wenn ich einen der beiden andern Kabel als Masse definiert hatte, gabs nur noch 0 oder 2.

Zitat :

Ich habe den Encoder direkt über 5V des Gameports angeschlossen.

Versteht das Jemand?

Jetzt mach doch endlich eine Skizze Der Verbindungen oder warte bis Alle die Geduld verlässt.

Rafikus

Entschuldigung, ich will auf keinen Fall, dass euch die Geduld verlässt.

Ich habe mal ein Schaubild gemalt, das hoffentlich Klarheit schafft.


Nochmals vielen Dank allen!

Hallo nochmal,

ich habe ein wenig gegooglet und dabei folgendes gefunden:
http://www.rn-wissen.de/index.php/Drehencoder

Leider bin ich nicht in der Lage einen der Codes so zu übersetzten, dass ihn Visual Basic annimmt.

Ich verstehe allein schon nicht, was "shift" macht.
Ganz zu schweigen davon, dass ich das mit den 0 Bits, 4 Bits nicht verstehe.

Aber scheinbar kann man die Beispielschaltung zum Entprellen weglassen und die Entprellung in der Software vornehmen.
Leider gehen meine Programmierkenntnisse nicht mal annähernd so weit.

Auf der verlinkten Seite steht doch, daß der Encoder Aussetzer hat.
Wenn Deine Schaltung tatsächlich so aufgebaut ist und Du nie Den Wert 2 bekommst, dann kannst Du das Teil in (vorausgesetzt, das Programm macht da keinen Fehler).

Das Beste wäre mit zwei Messgeräten zu messen, oder zwei Leuchtdioden mal da dran zu hängen und dann gaaaanz langsam drehen. Wenn Du auch dabei nicht Alle Zustände siehts, dann wird es auch nix.

Rafikus

Zitat :

(vorausgesetzt, das Programm macht da keinen Fehler).

Daran wirds wohl liegen.
Keine Entprellung, zu langsames Programm und dann auch noch die Pushbuttons mit den Encodersignalen zusammengelegt. Irgendwann hilft dann auch kein Graycode mehr.

Andererseits wäre es auch denkbar, daß diese Teile vielleicht nicht ganz grundlos beim Pollin in der Wühlkiste gelandet sind ...

Ja, einmalig über das Programm schauen hat bei mir auch nicht zum Verständnis beigetragen.

Ich gehe weiterhin davon aus, dass das Programm die schnellen Signale nicht richtig registrieren kann bzw. mehr oder weniger zufällig dann doch mal in der richtigen Zeit die Übergänge mitbekommt.

Eventuell bringt es etwas, die D-Flipflop-Schaltung zu modifizieren. Sprich: die Drehrichtung in einem Flipflop zu speichern (statisch) und die Drehimpulse auf z.B. 10ms verlängern.

Dann würde die Software das schon registrieren und müsste auch nur zwei Werte einlesen: einmal vom Monoflop, DASS überhaupt gedreht wurde und dann zusätzlich die in einem Flipflop gespeicherte Drehrichtung.


Was perl meinte deutete ich auch schon an: ein Encoder, den ich mal bei Polin bestellte, prellte quasi nur und es war fast nicht möglich, die eigentliche Information aus den Prellsignalen zu filtern.

Ein anderer Encoder gleichen Typs und funktionierte jedoch 100% reproduzierbar mit der Software.
Kann also durchaus sein, dass der Encoder schlichtweg im Eimer ist. Wenn du jemanden mit Oszilloskop kennst (Speicheroszi!), kannst du den dort mal anschließen und schauen, ob die Phasen wirklich sauber geschaltet werden.

Zusätzlich fehlen für meinen Geschmack dort Kondensatoren (100nF-1µF) und Widerstände nach Masse, auch wenn evtl. intern Pulldownwiderstände vorhanden sind.

Damit fängt man schon einiges an Murks ab.


Übrigens, zwei der Methoden, die da in deinem Link stehen, habe ich bereits geschildert. Witzigerweise die mit Graykode und jene mit 4-Bit-Lookup-Tabelle...

_________________

Hallo.

Ich behaupte auf keinen Fall, dass das Programm perfekt ist.
Nur: Besser kann ichs nicht.

Das Programm erkennt durchaus 3 Zustände. Nämlich 3(beide Pins haben Durchgang),2(ein Pin hat Durchgang) und 0(kein Pin hat Durchgang


Wenn ich den Drehknopf ganz langsam drehe, kriegt das Programm den Zwischenschritt immer mit. Dann erkennt es die Richtung.

Beim normalen Drehen (also wie man eben einen Lautstärkeknopf drehen würde), kriegt das Programm den Zwischenschritt nur zu ca. 40% mit.

Ich war gerade beim Conrad und werde mal die Widerstände und Kondensatoren einlöten. Ich kann nicht voraussagen, ob der Gameport dann noch verwendbar ist (wegen dem großen Widerstand). Aber ich werde es versuchen. Vielleicht hilft es ja.

Ich danke euch, dass Ihr mir helft, auch wenn ich mich scheinbar mit dem Projekt übernommen habe.

Könntet ihr mir evtl. noch erklären, wie das Prinzip des Entprellens softwareseitig zu lösen ist?(Möglichst einfach).

Das wäre nett.

Gruß Martin