Svenska ElektronikForumet

Kollade runt på den här sidan : http://www.interq.or.jp/japan/se-inoue/e_ckt10_3.htm
för jag ska pyssla med en rotationssensor. Nu är frågan, vad bör jag i kretsen "Chattering prevention circuit" ha för R- och C-värden när kontaktstudsen är max 3ms?

Motståndet beror ju på vad du ska driva, om vi utgår ifrån att det är t.ex. en PIC-port-pinne i input mode kan du nog ha 10K.

Sen kan kondingen nog hamna i storleken 1nF-10nF.

Ja, en PIC. Men jag funderade faktiskt på lösningen med två flanktriggade vippor som i exemplet under på samma sida.

Behövs igentligen inte.
Ta hand om det i programvaran istället. Kostar inga extra komponenter...

(För övrigt har jag en batch med just ALPS rot-encoders av samma typ
på väg hem, kommer förhoppningsvis i mellandagarna...)

sodjan: Pris på dom?

Ja men jag tänkte köra med picbasic precis som vår vän $tiff i den gamla tråden från förra året...

OK, fel forum, but here we go...

Jag har inte räknat helt på det, men sannolikt ca 30-35:-/st.
För övrigt samma som ELFA 35-846-04 eller -20 (minns inte vilken).
Alltså med en inbyggd tryckströmbrytare...

EDIT : Blir en blänkare på "Köp / Sälj / Återförsäljare"...

Ber om ursäkt för off topicen, sista nu: Du får gärna höra av dig när dom kommit in, sodjan.

MadModder skrev:Ja men jag tänkte köra med picbasic precis som vår vän $tiff i den gamla tråden från förra året...

Nej, nej, fy! Lär dig C eller något liknande vettigt istället! Jag har gjort BASIC-misstaget en gång och vill inte rekommentera det för andra.
Är det verkligen ett stort problem med studsar i "rotary encoders"? Ett vanligt RC-nät innan ingången borde räcka långt tycker jag...
Själkvklart går det att till viss del studsa av dem själv i mjukvara, men det förutsätter att man har lite resurser att lägga på det. Antingen procvessortid eller en timer.

...och så var programmeringskriget gång.
Allvarligt skojjat så blir man ganska begränsad av de olika Basic-dialekterna. När man väl kan C eller Assembler så blir allt mycket lättare.


(Själv kör jag MikroBasic...)

Jag skrev en rot.enc rutin för en PIC18 (men blir i princip likadant för
en PIC16). En timer gav ett avbrott med 400 Hz. I avbrottsrutinen
kollades om A/B signaleran hade bytt värde, och i så fall i
vilken "riktning". En up/ner räknare håll reda på den rellativa
förflyttningen. Om encodern hade stått till en viss tid (över
10 succsesiva avbrott, tror jag), så sattes en flagga så att main
koden kunde "ta hand" om förflyttningen och up/ner räknaren
nollades igen.

Det finns ofta ingen anledning att "reagera" på vridningen så
länge det går snabbt, användaren märker i alla fall inte det.
Om man vrider långsamt, så hinner det gå (minst) 10 avbrott för
varje "steg", och då följer applikationen med i vridningen hela tiden.

Jag hade även en accelerations del, där om det var en viss kort tid
mellan två steg, så räknades up/ner räknaren up/ner två steg
istället för ett. Ungefär som en mus med dynamisk "hastighet".
Man kan alltså vrida snabbt för grovjustering, sedan långsamt för
finjustering.

Och, nej, jag skulle inte vilja göra detta i Basic...

>> sodjan

Det verkar vara en bra lösning. Jag funderar på om avbrottsavläsning genom att koppla en av rotationsmojängens signaler till en avbrottspinne som reagerar på alla flanker. Så länge man inte har problem med studsar så måste det gå väldigt bra. Kombinerar man det med en timer så kan man även göra acceleration, och lite egen avstuds om man så önskar.
Detta bör ta lite mindre processortid, även om din metod nu har fördelen att ta en någerlunda konstant andel av processortiden.

Jag skulle gissa att 400 Hz avbrottet tog 1-2 % av processortiden
(PIC18 vid 40 Mhz, ca 100 instruktioner). Några % mer vid lägre
hastighet, så klart...

Jag tycker inte att det nödvändigtvis är "fult" att lösa detta problem i hårdvara då det endast behövs två billiga externa komponenter och förenklar programmeringen om än inte mycket så iallafall en del.

När det gäller RC filter och du matar in en puls så kommer utsignalen att nå 63% (1-e^(-1)) av slutvärdet vid tiden t=R*C, du vill alltså antagligen ha en produkt R*C som är lite större (så ett studs inte hinner nå riktit så högt) än 0.003.

Mitt förslag är 47k och 100n vilket ger R*C=0.0047. Detta bör sedan kopplas in på en scmitttriggad pinne för bästa effekt.