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?
RC-filter för dämpning av kontaktstuds
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"...
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"...
Senast redigerad av sodjan 21 december 2005, 21:30:25, redigerad totalt 1 gång.
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.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...
Ä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.
-
JimmyAndersson
- Inlägg: 26578
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
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...
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.
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 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.
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.
