Drehencoder anschließen

Chris Gast #683061
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Knut B. (Firma: TravelRec.) Persönliche Seite #683077
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Falk B. #683084
Lesenswert?
• ▲
▼ 
@ 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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thomas1123 Gast #683203
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Knut B. (Firma: TravelRec.) Persönliche Seite #683217
Lesenswert?
• ▲
▼ 
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).
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Falk B. #683225
Lesenswert?
• ▲
▼ 
@ 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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Knut B. (Firma: TravelRec.) Persönliche Seite #683231
Lesenswert?
• ▲
▼ 
@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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Falk B. #683234
Lesenswert?
• ▲
▼ 
@ 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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Knut B. (Firma: TravelRec.) Persönliche Seite #683251
Lesenswert?
• ▲
▼ 
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)?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Xris #686898
Lesenswert?
• ▲
▼ 
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...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren