Drehencoder anschließen

[Chris (Gast)]

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

[Falk B. (falk)]

@ 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

[Knut B. (Firma: TravelRec.) (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. 
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.

[Falk B. (falk)]

@ 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

[Thomas1123 (Gast)]

auf diese weise habe ich das mal mit nem PIC 16F84 abgefragt

// file: endlospoti.c

// Progrqamm zum auswerten der Drehrichtung eines 
// Endlospotentiometers
//------------------------------------------------------------------

#include "pic.h"
#include "htc.h"

__CONFIG (WDTDIS & XT & UNPROTECT);

char _taste = 0;
char fall_0;
//char fall_1;
char _dreh;
char fall_2 = 0;
bit _nix;


#define rechts 2
#define links 1

//------------------------------------------------------------------

// Portinitialisirung
// Funktion für die initialisation der Tri-State-Register
// und der Ports.
int port_ini (char _ta, char _tb)
{  
  PORTA = 0;
  TRISA = _ta;
  PORTB = 0;
  TRISB = _tb;

  return 0;
}

//------------------------------------------------------------------

// Tastenabfrage
// Gibt den Wert der ersten beiden Pins von PortA (RA0 + RA1) zurück
char tasten_abf (void)
{
  char _tast;
  _tast = (PORTA & 0b00000011);
  return _tast;
}

//------------------------------------------------------------------

// Funktion zum feststellen der Drehrichtung des
// Endlospotentiometers
int richtung (void)
{

  fall_0 = _taste;
  _taste = tasten_abf();
  
  switch(_taste)
  {
    case 0:
    {
      if (fall_0 == 1)
        _dreh = links;
      if (fall_0 == 2)
        _dreh = rechts;
    }
    break;
    case 1:
    {
      if (fall_0 == 0)
        _dreh = rechts;
      if (fall_0 == 3)
        _dreh = links;
    }
    break;
    case 2:
    {
      if (fall_0 == 0)
        _dreh = links;
      if (fall_0 == 3)
        _dreh = rechts;
    }
    break;
    case 3:
    {
      if (fall_0 == 1)
        _dreh = rechts;
      if (fall_0 == 2)
        _dreh = links;
    }
    break;
  }
  return 0;
}

//------------------------------------------------------------------

// var_x = (var_x << 4) | (var_x >> 4); // swap
// 
int count (void)
{
  if (_dreh == links)
  {
    fall_2++;
    if (fall_2 == 2)
    {
      //PORTB++;
      PORTB = (PORTB >> 1) | (PORTB << 7);
      fall_2 = 0;
    }
    _dreh = 0;
  }
  if (_dreh == rechts)
  {  
    fall_2++;
    if (fall_2 == 2)
    {
      //PORTB--;
      PORTB = (PORTB << 1) | (PORTB >> 7);
      fall_2 = 0;
    }
    _dreh = 0;
  }
}
//------------------------------------------------------------------

void main (void)
{
  port_ini(0b00000111,0b00000000);
  PORTA = 0b00001000;
  PORTB = 1;
  fall_2 = 0;
  
  for (;;)
  {
    richtung();
    count();
    if (RA2 == 1)
    {
      PORTB = ~PORTB;
      while (RA2 == 1)
        _nix = 1;
      
    }
    
  }
}

hoffe du kannst was damit anfanhgen

MFG
Thomas1123

[Knut B. (Firma: TravelRec.) (travelrec)]

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).

[Falk B. (falk)]

@ 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

[Knut B. (Firma: TravelRec.) (travelrec)]

@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.

[Falk B. (falk)]

@ 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

[Knut B. (Firma: TravelRec.) (travelrec)]

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)?

[Falk B. (falk)]

@ 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

[Knut B. (Firma: TravelRec.) (travelrec)]

Aha.

[Chris R. (mrgreen)]

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...