Klar, hier: http://www.car-mp3.de/RNetz/C200_62P.pdf
Hallo
Eine größere Last (kleinerer PullUp) würde vermutlich die Flanken der Eingangssignale steiler machen. Jetzt wäre der richtige Augenblick mal in das Datenblatt des "extra guten (und teuren) Geber mit optischer Auswertung" zu schauen. Hast du einen Link?Da der Encoder optisch funktioniert habe ich die NPN-Ausgänge einfach direkt an die Eingänge des AVR gehängt und dessen internen Pull-Ups aktiviert.
Gruß
mic
Bild hier
Atmel’s products are not intended, authorized, or warranted for use
as components in applications intended to support or sustain life!
Klar, hier: http://www.car-mp3.de/RNetz/C200_62P.pdf
Hmmm, keine Ahnung ob das bei diesem Encoder passt. Ich habe mal eine LED-Batterie in Reihe schalten müssen. Dort habe ich die Flanken bei sehr schnellen Schaltvorgängen - im untersten µs-Bereich - sehr verbessert, indem ich dem Basiswiderstand des Schalt-Transistors einen Kondensator verpasst hatte. Das Ganze ist mit Oskarbildchen belegt und hier beschrieben, der zu den Bildern gehörige Text fängt zwei Absätze VOR den Bildern an.Zitat von radbruch
Ciao sagt der JoeamBerg
Hallo oberallgeier,
leider komme ich an die Transistoren nicht ran, da diese im Encoder verbaut sind. Es bleibt mir also erst mal nur kleinere Pull Ups dazuzulöten. Mal schauen, was das bringt.
Viele Grüße
Andreas
Hallo
Aha, laut Datenblatt des Tiny2313 (Seite 181 ganz unten) hat der interen PullUp zwischen 20k und 50k, für den Geber werden aber 10k vorgeschlagen. Bei zu großem PullUp würde möglicherweise der High-Pegel am AVR-Eingang nicht sicher erreicht werden. Das würde ich zuerst versuchen.
Dann steht im Geberdatenblatt noch das:
Ich bin jetzt nicht so der TTL-Profi, aber ich habe das Gefühl, wir sind viel zu schnell mit unserer Abfrage! Der Tiny2313 läuft defaultmässig (mit /8-Prescaler an internen 8MHZ) mit 1MHz (Datenblatt S.25 "Default Clock Source"), ein NOP würde dann 1 µs verzögern. Bei Signalflanken kleiner 30ms wären das fast 30000 AVR-Takte? Warum ändert sich da was wenn wir count=4 verändern? Was ändert dein Clock/8-Fuse bei dem der Tiny dann eigentlich mit 8MHZ rennen sollte? Ich hätte erwartet, dass ein optischer Sensor viel schneller reagiert *grübel* (Dieser Ansatz ist vielleicht auch eine Sackgasse)Logic Rise and Fall: less than 30 ms
...
Contact Bounce: less than 4 ms at make
and less than 10 ms at break
Die 32 Rastungen(=Schritte?) pro Umdrehung kann ich auch nirgends finden. Sind es vielleicht nur 16? Das steht in der Teilenummer verschlüsselt. Bei 16 Impulsen pro Umdrehung würden die Dimensionen stimmen:
MaxSpeed: 100RPM
MinRiseandFall: 0,030s
60Sek/(16Imp/Umdr * 100)=60/1600=0,0375s
Das würde bedeuten, der Pegel bleibt mindestens 0,0075 Sekunden konstant? Lange Rede, kurzer Sinn: Du drehst einfach zu schnell
Wenn die kleineren PullUps nicht helfen sollten wir mal die Bitlängen des Gebers bei schnellem Drehen messen:
Keine Ahnung ob das so funktioniert.Code:#define AVRGCC #include <avr/io.h> /** PD2 Eingang Spur A PD3 Eingang Spur B PB0 Ausgang links PB1 Ausgang rechts **/ #define Links1 PORTB = (PORTB | (1<<PB0)) #define Links0 PORTB = ~(~PORTB | (1<<PB0)) #define Rechts1 PORTB = (PORTB | (1<<PB1)) #define Rechts0 PORTB = ~(~PORTB | (1<<PB1)) #define SpurA ((PIND & 0b00000100) == 0) #define SpurB ((PIND & 0b00001000) == 0) char SpurA_akt, SpurA_old, SpurB_akt, SpurB_old, count = 0, dir = 0; unsigned int count16; int main(void) { DDRB = 0b00000011; PORTB = 0b00000011; DDRD = 0b00000000; PORTD = 0b00001100; while (1) { count16=0; // vorsichtshalber 16Bit-Zähler bereitstellen count=5; // Dummywechsel (sollte ungerade sein) while(!SpurA); // warten auf Startpegel SpurA_old=SpurA; // das merken wir uns while(count--) // Dummyspurwechsel um volle Drehgeschwindigkeit zu erreichen { while(SpurA==SpurA_old); SpurA_old=SpurA; } // jetzt sollte der selbe Pegel wie beim Start gemessen werden while(SpurA==SpurA_old) count16++; // und nun steht in count16 die Zähllänge des Spurwechsels } return(0); }
Gruß
mic
Bild hier
Atmel’s products are not intended, authorized, or warranted for use
as components in applications intended to support or sustain life!
16 Impulse? Könnte natürlich sein, das ich mich da getäuscht habe... Ich zähle morgen mal.
Und wie soll ich von Hand denn zu schnell drehen? Ich vermute ich schaffe gerade mal so 1RPM.
Ich werde erst mal den Lötkolben schwingen und Pull Ups rein löten. Mal gucken ob das hilft. Die Zeitmessung halte ich (erst mal) für unnötig, da ich sogar Richtungsfehler bekommen, wenn ich den Encoder gaaanz langsam drehe, also Rastung für Rastung.
Hallo Bumbum.
Ich habe viele von den billig-Encoder von Pollin und verbaue sie gern. Ich habe dazu eine -zugegebenermaßen nicht unbedingt optimale- Routine geschrieben, die 100% Funktion hat. Nachteil ist, sie funktioniert nicht über Interrupts, d.h. der Controller muss es im Hauptprogramm machen.
Das ganze habe ich, wie im Datenblatt empfohlen, mit einem kleinen Widerstandsnetzwerk entprellt.
Wenn Interesse besteht, kann ich das ja mal dokumentieren, aber nur, wenn Du es wirklich brauchst.
Hallo thewulf00,
klar, immer her damit. In meinem ersten Posting hier schreibe ich ja, das ich dafür extra einen Tiny "geopfert" habe, der nichts anderes macht wie den Encoder auszuwerten. Ich würde deinen Code gerne mal probieren!
Viele Grüße
Andreas
Nachtrag: Das Lötkolben schwingen hat geholfen. Ich habe jetzt 10k Pull-Up-Widerstände eingelötet und das ganze funktioniert perfekt. Ich würde sagen zu 100%.
Vielen Dank an alle, die geholfen haben!
@thewulf00: Dein Code wäre trotzdem interessant.
Viele Grüße
Andreas
Juhu :)
Bild hier
Atmel’s products are not intended, authorized, or warranted for use
as components in applications intended to support or sustain life!
Lesezeichen