Drehgeber/Encoder: Auflösung/Frequenz zu hoch

Thomas Z. schrieb:

> An einem Motor mit Getriebe befindet sich auf der Motorachse der
> Drehgeber/Encoder. Durch das Getriebe ergeben sich auf der Abtriebsachse
> 1.200 Steps pro Umdrehung.

Häh?!

Wo ist denn das Ding nun, auf der Motorachse oder auf der Abtriebsachse?

> Lt. Drehgeber-Artikel müsste ich also mit 200kHz abtasten.
> Das ist zuviel.
> Idee: einfach mit zwei Binär-Zählern die Signale durch 16 teilen

Also 12500Hz wären ok ?

Dann rechne doch einfach noch mal nach,
10000 Steps, 4 Zustände, macht 40000 Hz Abtastung,
weit weniger als deine befürchteten 200000,
und sollten doch "drin" sein.

Natürlich kann man Incrementaldecoderauswertung auch in Hardware machen.

http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29

Thomas Z. schrieb:
> Gute Frage.

Wenn der Motor nicht gerade mit 500 U/min dreht, sollte sich ein 
Unsicherheitsfaktor von 4 mit ein paar Leuchtdioden (evtl. mit Treiber) 
an den Encoderausgängen doch ausräumen lassen.

Und ob man jeden Step 20 mal abtasten muss, damit man ihn mitkriegt, sei 
jetzt mal dahingestellt. Für die richtige Dekodierung muss man jede 
Phase des AB-Signals genau ein Mal erwischen.

Eigentlich fällt mir zu diesem Problem nur eine einfach Hardware-Lösung 
ein die mit Hilfe einer CPLD gelöst wurde und 2-Quad-Decoder in 
Richtung/Schritt wandelt. Es ist dafür nur ein einfacher TTL-Oszillator 
mit um die 1-2Mhz und eine XC9536 nötig. Ob der TTL-Oszillator nun 1,8 
oder 1Mhz hat, ist eigentlich egal. Bei 1Mhz Takt gehen auf jeden Fall 
250Khz am Eingang. Bei schnelleren Signalen müsste man zunächst mal 
etwas am Eingang filtern. Man kann dass auch in HDL schreiben, ich habe 
jedoch darauf mangels Bedarf darauf verzichtet. Das Mapping der 
Funktionen zum Pin des Chips macht man am besten in einer Datei oder 
erzeugt sie in der ISE (Xilinx

Der Dekoder ist kein Hexenwerk wie man sehen kann. Am Ausgang kommt der 
Takt und die Richtung an - der Takt geht in einen Counter-Eingang des 
AVR und mit dem Richtungsausgang an ein Portbit. Nun muss der Controller 
nur noch den IRQ für das Richtungsportbit bedienen und bei Änderung 
entweder vor- oder rückwärts zählen lassen.


Ich habe in einer weiteren Version ein 32Bit Vorwärts/Rückwärts Zähler 
implementiert. Der wird einfach mit 8Bit breiten Leitungen zum Chip 
ausgelesen  gesetzt  rückgesetzt. Der lies sich jedoch nicht mehr im 
xc9536 (5V) synthetisieren und musste in einem XC9572XL (3.3V) umziehen.
Die Schaltung kostete knapp €3.- gekostet und funktioniert bis ca. 
170Mhz.

 http://www.mikrocontroller.net/part/XC9536


// 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
+++++++++
// Modifiziert 04/2010 von G. Wesser, DD4DA zur Ausgabe der 
Ticks,Richtung
// Ein zweiter Decoder wurde integriert -- mit je ein 4-Bit Zählregister
// in dem XC9536 lassen sich keine zwei 8-Bit Zähler unterbringen
// da zu wenige IOB's da sind. Ein XC9572 würde jedoch funktionieren.
// vy 73 de DD4DA
// 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
+++++++++


// Initiated in 08/2009 and modified in 04/2010 by G. Wesser.
// This Project build two Quad-Decoder (gray code) for decoding the A 
and B Signal
// of an incremental encoder  to Ticks and Direction of each Incremental 
encoder.
// In addition, i add a 4 Bit binary counter for each decoder. This 
should gives a MCU
// the posibility to use normal I/O Ports instead Tick and Direction. 
IT's also usable
// as a prescaler 1/2, 1/4, 1/8 and 1/16 of the Ticks to get different 
resolutions.
// Use one of them and the direction signal instead the TICK output.


module quad(clk, quadA, quadB,quadC, quadD, count1, count2, richtung1, 
richtung2, ticks1,ticks2);

input clk, quadA, quadB, quadC, quadD;

output [3:0] count1;      // Output Register ist 4 Bit breit
output [3:0] count2;      // Output Register ist 4 Bit breit
output richtung1, ticks1,  richtung2, ticks2;



reg [2:0] quadA_delayed, quadB_delayed, quadC_delayed, quadD_delayed;
always @(posedge clk) quadA_delayed <= {quadA_delayed[1:0], quadA};
always @(posedge clk) quadB_delayed <= {quadB_delayed[1:0], quadB};
always @(posedge clk) quadC_delayed <= {quadC_delayed[1:0], quadC};
always @(posedge clk) quadD_delayed <= {quadD_delayed[1:0], quadD};


wire count_enable1 = quadA_delayed[1] ^ quadA_delayed[2] ^ 
quadB_delayed[1] ^ quadB_delayed[2];
wire count_direction1 = quadA_delayed[1] ^ quadB_delayed[2];

wire count_enable2 = quadC_delayed[1] ^ quadC_delayed[2] ^ 
quadD_delayed[1] ^ quadD_delayed[2];
wire count_direction2 = quadC_delayed[1] ^ quadD_delayed[2];



reg [3:0] count1;    // 4-Bit Zähler - kann ggf erweiter werden
reg richtung1;      // Richtung Rechts=Low Links=High
reg ticks1;        // Impulse für den Weg



reg [3:0] count2;    // 4-Bit Zähler - kann ggf erweiter werden
reg richtung2;      // Richtung Rechts=Low Links=High
reg ticks2;        // Impulse für den Weg




// Erster Quad-Decoder

always @(posedge clk)
begin

 if(count_enable1)
  begin
   if (ticks1 == 1 ) ticks1 <= 0;
  else  ticks1 <= 1;
   if (count_direction1)
    begin
   count1 <= count1 + 1;    // Zähler um 1 erhöhen
   richtung1 <= 1;        // Richtung ausgeben - High
    end
  else
    begin
    count1 <= count1 - 1;    // Zähler um 1 mindern
     richtung1 <= 0;        // Richtung ausgeben - LOW
   end
  end

end



// Second Quad-Decoder

always @(posedge clk)
begin

if(count_enable2)
  begin
   if (ticks2 == 1 ) ticks2 <= 0;
  else  ticks2 <= 1;
   if (count_direction2)
    begin
   count2 <= count2 + 1;    // Zähler um 1 erhöhen
   richtung2 <= 1;        // Richtung ausgeben - High
    end
  else
    begin
    count2 <= count2 - 1;    // Zähler um 1 mindern
     richtung2 <= 0;        // Richtung ausgeben - LOW
   end
  end
end


endmodule