Sida 1 av 2

"Decoda" en 3600 cpr encoder. Hur?

Postat: 16 december 2007, 20:50:00
av jonte_s
Hej.

Jag funderar over hur man lättast/smartast/bäst skall kunna lösa decodningen av en encoder. Det finns ett par alternativ som jag ser det.

1. Bygga något med D-flipflops och räknare som man läser av. Typ såhär: http://www.electro-tech-online.com/robo ... rface.html

2. Använda en separat, dedikerad microcontroller som man sedan läser av.

3. Kombination av 1 och 2.

Grejen är att encodern är på 3600 cycles/rev, vilket känns väldigt mycket. Vid 10000 rpm blir det en avläsningshastighet på 600 kHz! Vilket känns svårt att få till i den microcontroller som skall göra ”allt” annat också. Därför känns en extern lösning (någon av ovanstående 3 lösningar) som det bästa alternativet.
Är det någon som har erfarenhet av detta? Dvs. med så hög upplösning på encodern.

Jag vet att många använder external interrupt pins för att räkna de inkommande pulserna från encodern…
Kan man använda ”counter unit” hos microcontrollern på något smart sätt för att skala ned upplösningen något tro?
Hur läser man av en räknare eller microcontroller? Med SPI, I2C…?

Tänkte använda någon AVR @ någon lämplig hastighet.

mvh Jonas

Postat: 16 december 2007, 20:53:13
av sodjan
Är verkligen en 3.600 stegs encoder tänkt att användas vid 10.000 rpm ?

Postat: 16 december 2007, 21:01:57
av jonte_s
Jag såg precis att "no load speed" är ca 7000 rpm för de motorer jag har.
Det är dessa: http://www.elektronikforumet.com/forum/ ... c&start=15

Men i vilket fall, så blir det rätt hög interrupthastighet om man skall ha signalerna på externa interrupt...

Postat: 16 december 2007, 21:05:39
av sodjan
OK, ja då är det bara att räkna på det... :-)
Hinner man inte med i koden, så får det bli extern hårdvara.
Om man inte måste ha alla 3600 stegen per varv, så kan ju
bara räkna ner pulserna med t.ex 10 eller 16 eller vad som är lämpligt.

Postat: 16 december 2007, 21:15:01
av JBV
Encodern klarar max 200kHz eller ca 3333 rpm

Postat: 16 december 2007, 21:17:37
av jonte_s
Jo. Det lutar ju mot extern hårdvara. Hur skulle man kunna lösa detta med att räkna ner pulserna? Har ingen bra idé.
Skulle man kunna använda någon räknekrets som räknar upp till tex. 4 och sedan ger ut en signal, som man kopplar till en extern interruptpinne? Finns det sådana kretsar?

Postat: 16 december 2007, 21:20:09
av jonte_s
JBV: Aha. Tack, bra att veta :-)

Postat: 16 december 2007, 21:24:30
av Icecap
En del processorer kan dela insignalen på deras capture-enhet, då behöver man inte extern hårdvara.

Postat: 16 december 2007, 21:40:32
av jonte_s
Icecap: Jo. jag har funderat på det också, men dels har jag inte hittat någon AVR med fler än en input capture (har inte kollat igenom alla...) vilket gör att det känns som en rätt oflexibel lösning... Alltså att så få processorer inte har fler än en input capture (detta kanske inte alls stämmer).

Postat: 16 december 2007, 21:45:08
av Icecap
Med 7000RPM lär du inte behöva annan information från encodern än tacho-information och till det behövs bara en enda Capture-ingång.

Renesas & Fujitsu har ett antal Capture-ingångar, på Fujitsu MB90F583 är det 3 st som kan vara samtidig aktiva utan att störa varandra, på Renesas har jag inte kollat antalet än.

Postat: 16 december 2007, 21:56:04
av jonte_s
Tanken är väl att man skall kunna köra i hastigheter mellan 0-3333rpm.
Sedan hade jag tänkt använda en microcontroller som decodar två st encodrar, vilket gör att jag iaf minst behöver två input capture (om man nu skall använda det sättet). Om jag tänker rätt... :-)?

Jag försöker nog hålla mig till AVR.

Men vad tror ni om att använda någon form av extern räknare, som räknar antalet pulser och när räknaren har räknat upp till tex. 4 så skickas en signal till uc externa interrupt? Detta gör ju att man "delar" upplösningen med 4!? Frågan är bara om det finns några sådana kretsar? Är helst lost där...

Postat: 17 december 2007, 07:47:26
av JBV
Kolla här för en quadrature divider:
http://emergent.unpythonic.net/index.cg ... 1149348342

Det blir tydligen fel om man bara dividerar A och B var för sig:
http://emergent.unpythonic.net/index.cg ... 1149094674

"Here's how the circuit is supposed to work: the quadrature signal is treated as a step+direction signal. On the falling edge of "B IN", one count in the direction indicated by "A IN" is taken. When the waveform is moving in one direction, "B IN" will consistently be high when "A IN" falls; when it's moving in the other direction, it will be low.

When the encoder is consistently rotating one direction, this circuit behaves as described above. But what happens when the encoder reverses, or switches back and forth across a single transition? In the waveform shown in the image, DIR (A IN) is high, while CLK (B IN) has multiple falling edges. As a result, the output will erroneously count up."

Postat: 17 december 2007, 07:58:24
av maha
Om encodern bara ska rotera i en riktning så räcker det ju att titta på A eller B. Sen kan du ju lämpligtvis använda en 4040 för att dividera ner med 2, 4, 8, 16, 32, 64 osv... Eller en 4017 för att dividera ner med t.ex. 10 (eller 4 om det är det du vill). Men som JBV skriver, ska den kunna rotera åt båda håller blir det ju lite knepigare.

Postat: 17 december 2007, 10:24:17
av Tottish
Vet inte hur JBV fick reda på vad du hade før encoder men om vi utgår ifrån att den max får rotera 3300RPM så går ju dina motorer ændå før snabbt. Detta kan du væl løsa med en mekanisk nedvæxling? Om du sedan inte vill hålla på med elektroniska ræknare så kan du anpassa den mekaniska utvæxlingen så att du slipper. Detta torde inte vara så mycket jobbigare om du ændå måste bygga en utvæxling.

MVH
/Tottish

Postat: 17 december 2007, 10:57:55
av maha
Det är en encoder (jag gissar ju iofs också) från en av motorerna som badtastex sålde. I och med att de hade 3600 pulser/varv så kan man nästan vara säker på att det är den.