Hallo, ich versuche, einen Drehencoder anzuschließen. Der Code hier im Forum von Peter Dannegger funktioniert aus irgendeinem Grunde nicht... Laut Datenblatt erzeugt mir der Drehencoder folgendes Signal: "Output of A and B signals, proportionate to phase difference" [http://www3.alps.co.jp/WebObjects/catalog.woa/PDF/E/Switch/Encoder/EC12E/EC12E.PDF] Wenn ich nach rechts drehe, kommt also zuerst die Flanke auf Pin A, dann auf B. Wie erkenne ich denn, dass (nach kurzer Zeit) nach der Flnake auf A die Flanke auf B kommt? Ist das der vielfach erwähnt Gray Code? MfG Chris
@ Chris (Gast) >Wenn ich nach rechts drehe, kommt also zuerst die Flanke auf Pin A, dann >auf B. Ist doch super. >Wie erkenne ich denn, dass (nach kurzer Zeit) nach der Flnake auf A die >Flanke auf B kommt? Abtasten? >Ist das der vielfach erwähnt Gray Code? Ja, siehe Drehgeber. MFG Falk
Du brauchst doch nur auf die steigende Flanke von A abtasten. Findet diese statt und B ist ebenfalls logisch 1, dann wurde rechts herum gedreht. Ist B zu dem Zeitpunkt logisch 0, wurde links herum gedreht. Mit Kondensatoren 10nF an A und B nach Masse und aktivierten internen PullUps hat man eine wirksame Hardware-Entprellung. Ist mit etwas mehr Aufwand (Polling in festen Zeitfenstern) aber auch komplett in Software realisierbar.
@ Travel Rec. (travelrec) >Du brauchst doch nur auf die steigende Flanke von A abtasten. Findet >diese statt und B ist ebenfalls logisch 1, dann wurde rechts herum >gedreht. Ist B zu dem Zeitpunkt logisch 0, wurde links herum gedreht. Auch du solltest den Artikel Drehgeber nochmal in RUHE lesen und drüber nachdenken. Dein Vorschlag ist nämlich einen halbgare Bastellösung. >Aufwand (Polling in festen Zeitfenstern) aber auch komplett in Software So wird schon eher ein Schuh draus. MfG Falk
auf diese weise habe ich das mal mit nem PIC 16F84 abgefragt
1 | // file: endlospoti.c
|
2 | |
3 | // Progrqamm zum auswerten der Drehrichtung eines
|
4 | // Endlospotentiometers
|
5 | //------------------------------------------------------------------
|
6 | |
7 | #include "pic.h" |
8 | #include "htc.h" |
9 | |
10 | __CONFIG (WDTDIS & XT & UNPROTECT); |
11 | |
12 | char _taste = 0; |
13 | char fall_0; |
14 | //char fall_1;
|
15 | char _dreh; |
16 | char fall_2 = 0; |
17 | bit _nix; |
18 | |
19 | |
20 | #define rechts 2
|
21 | #define links 1
|
22 | |
23 | //------------------------------------------------------------------
|
24 | |
25 | // Portinitialisirung
|
26 | // Funktion für die initialisation der Tri-State-Register
|
27 | // und der Ports.
|
28 | int port_ini (char _ta, char _tb) |
29 | {
|
30 | PORTA = 0; |
31 | TRISA = _ta; |
32 | PORTB = 0; |
33 | TRISB = _tb; |
34 | |
35 | return 0; |
36 | }
|
37 | |
38 | //------------------------------------------------------------------
|
39 | |
40 | // Tastenabfrage
|
41 | // Gibt den Wert der ersten beiden Pins von PortA (RA0 + RA1) zurück
|
42 | char tasten_abf (void) |
43 | {
|
44 | char _tast; |
45 | _tast = (PORTA & 0b00000011); |
46 | return _tast; |
47 | }
|
48 | |
49 | //------------------------------------------------------------------
|
50 | |
51 | // Funktion zum feststellen der Drehrichtung des
|
52 | // Endlospotentiometers
|
53 | int richtung (void) |
54 | {
|
55 | |
56 | fall_0 = _taste; |
57 | _taste = tasten_abf(); |
58 | |
59 | switch(_taste) |
60 | {
|
61 | case 0: |
62 | {
|
63 | if (fall_0 == 1) |
64 | _dreh = links; |
65 | if (fall_0 == 2) |
66 | _dreh = rechts; |
67 | }
|
68 | break; |
69 | case 1: |
70 | {
|
71 | if (fall_0 == 0) |
72 | _dreh = rechts; |
73 | if (fall_0 == 3) |
74 | _dreh = links; |
75 | }
|
76 | break; |
77 | case 2: |
78 | {
|
79 | if (fall_0 == 0) |
80 | _dreh = links; |
81 | if (fall_0 == 3) |
82 | _dreh = rechts; |
83 | }
|
84 | break; |
85 | case 3: |
86 | {
|
87 | if (fall_0 == 1) |
88 | _dreh = rechts; |
89 | if (fall_0 == 2) |
90 | _dreh = links; |
91 | }
|
92 | break; |
93 | }
|
94 | return 0; |
95 | }
|
96 | |
97 | //------------------------------------------------------------------
|
98 | |
99 | // var_x = (var_x << 4) | (var_x >> 4); // swap
|
100 | //
|
101 | int count (void) |
102 | {
|
103 | if (_dreh == links) |
104 | {
|
105 | fall_2++; |
106 | if (fall_2 == 2) |
107 | {
|
108 | //PORTB++;
|
109 | PORTB = (PORTB >> 1) | (PORTB << 7); |
110 | fall_2 = 0; |
111 | }
|
112 | _dreh = 0; |
113 | }
|
114 | if (_dreh == rechts) |
115 | {
|
116 | fall_2++; |
117 | if (fall_2 == 2) |
118 | {
|
119 | //PORTB--;
|
120 | PORTB = (PORTB << 1) | (PORTB >> 7); |
121 | fall_2 = 0; |
122 | }
|
123 | _dreh = 0; |
124 | }
|
125 | }
|
126 | //------------------------------------------------------------------
|
127 | |
128 | void main (void) |
129 | {
|
130 | port_ini(0b00000111,0b00000000); |
131 | PORTA = 0b00001000; |
132 | PORTB = 1; |
133 | fall_2 = 0; |
134 | |
135 | for (;;) |
136 | {
|
137 | richtung(); |
138 | count(); |
139 | if (RA2 == 1) |
140 | {
|
141 | PORTB = ~PORTB; |
142 | while (RA2 == 1) |
143 | _nix = 1; |
144 | |
145 | }
|
146 | |
147 | }
|
148 | }
|
hoffe du kannst was damit anfanhgen MFG Thomas1123
Falk: >Auch du solltest den Artikel Drehgeber nochmal in RUHE lesen und >drüber nachdenken. Dein Vorschlag ist nämlich einen halbgare >Bastellösung. Nicht ganz, die Codediagramme im Beitrag entsprechen nicht dem aufgezeigten Encoder von Chris. Ein ähnlicher Encoder ist auch derjenige, den man bei CSD beziehen kann (PEC11). Diese geben nämlich eine volle Pulsperiode aus und landen in der Ruhestellung immer auf beiden Ausgängen = logisch 1 (also Kontakte offen). In Uhrzeigerrichtung gedreht schließt zuerst A, dann B, dann gibt A wieder frei, dann gibt B wieder frei. Diese Ausgabe folgt bei jedem Schritt. Die im Beitrag "Drehencoder" aufgezeigte Codierung verwendet sozusagen Halbschritte (also beide offen -> beide geschlossen -> beide offen). Bei dem von Chris verwendeten Encoder kann man meine vorgeschlagene Variante sehr wohl anwenden und sie funktioniert auch zuverlässig. Ich habe auch andere Drehencoder, die der Codierung vom Beitrag entsprechen und die so nicht abgefragt werden können (z.B. Panasonic von Pollin).
@ Travel Rec. (travelrec) >derjenige, den man bei CSD beziehen kann (PEC11). Diese geben nämlich >eine volle Pulsperiode aus und landen in der Ruhestellung immer auf >beiden Ausgängen = logisch 1 (also Kontakte offen). In Uhrzeigerrichtung Das ist egal, deine Auswertung ist trotzdem Murks. Siehe Link. >wohl anwenden und sie funktioniert auch zuverlässig. Ich habe auch Zu 99%, mehr nicht. >andere Drehencoder, die der Codierung vom Beitrag entsprechen und die >_so_ nicht abgefragt werden können (z.B. Panasonic von Pollin). Das wage ich zu bezweiflen. Hast du Links zu diesen Bauteilen? MfG Falk
@Falk: Falsch ausgedrückt oder falsch verstanden: die anderen Drehencoder (auch der von Pollin) haben die Codierung laut Drehencoder-Beitrag mit den Halbschritten und können somit mit meiner Methode nicht abgefragt werden. Der Encoder von Chris und der von CSD, die mit dem Vollschritt, können mit der Flankenmethode ausgewertet werden. Bei der Auswertung laut Beitrag würden sie (so vermute ich) 2 Steps pro Rastung erzeugen.
@ Travel Rec. (travelrec) >@Falk: Falsch ausgedrückt oder falsch verstanden: Hab ich wohl falsch verstanden. >Der Encoder von Chris und der von CSD, die mit dem Vollschritt, können >mit der Flankenmethode ausgewertet werden. Bei der Auswertung laut >Beitrag würden sie (so vermute ich) 2 Steps pro Rastung erzeugen. Schon klar, aber dennoch ist die Methode nicht wirklich OK. Sie läuft brauchbar, und für ne Hobbysache ausreichend gut. Aber sie hat immer noch die Macken, welche im Wikiartikle beschrieben sind. Pendeln ist das Stichwort. MFG Falk
Bei den PEC11 ist Pendeln ziemlich, naja - ich will nicht sagen "ausgeschlossen", aber sehr unwahrscheinlich, weil es ein handbedienter, rastender Encoder ist, der in der Rastung mechanisch recht weit von einer Schaltschwelle entfernt ist. Mit den Tiefpaßkondensatoren an den Terminalpins ist ein Übriges getan. Die von Dir aufgeführte Code-Variante ist sicher das Gelbe vom Ei, aber geht sie auch mit den Vollschrittencodern oder muß man da anpassen (bin nicht so fin in C)?
@ Travel Rec. (travelrec) >Code-Variante ist sicher das Gelbe vom Ei, aber geht sie auch mit den >Vollschrittencodern oder muß man da anpassen (bin nicht so fin in C)? Sollte laufen. MfG Falk
Dazu habe ich auch eine Frage: Ich habe mir denselben Encoder (ich denke, dass es der ist; die angeblich Herstellernummer, die Reichelt angibt, kennt Alps nicht) gekauft. Durch zwei LEDs habe ich rausgefunden, wie das Ding tickt: Im Ruhezustand sind beide LEDs an (an aufgrund meiner Beschaltung, das Prinzip ist das Wichtige), wenn man nach rechts dreht, geht erst A und dann B aus. Soweit so gut, wenn da nicht drei Rasterstellungen wären, wo das nich zutrifft. In diesen 3 Positionen bleibt die Flanke am zweiten Pin aus; es bleibt also dabei, dass A aus ist, B aber noch leuchtet. Da das aber nur bei 3 von 24 Stellungen auftriit (die 3 liegen nebeneinaner), glaube ich an SCheiß-Produktion, oder was meint ihr? Laut datenblatt soll er auch den beschriebenen Übergang (erst A low, dann B low) liefern...
Bitte 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.