Fick för mig att jag hade gjort ett grovt misstag, så jag har börjat räkna på sekvenserna igen (jag räknar för hand på papper!), men allt verkar stämma hur jag än vrider och vänder på det hela (än så länge).
H.O: Du ritar schemat i Eagle va? Det är inte så att du råkat få en ingång "osynligt oansluten" - dvs ledaren går fram men är inte kopplad. Annars kan den inte uppföra sig som i din simualtor. Jag har skrivit ut schemat och suttit och superkollat men inte hittat något fel.
Hmm...men som i fallet ovan (min sista bild) så skulle ju U/D räknaren räkna upp en gång för mycket eftersom det kommer en klockpuls EFTER det att rotationsriktningen ändrats men INNAN riktningsvippan slagit om och det "känns" fel Sen vet jag inte om det spelar någon roll men åt ena hållet så verkar klockpulsen gå hög på A's fallande flank medan den går hög på B's fallande flank åt andra hållet.
Schemat är ritat i Eagle men det är INTE simulerat - det är uppkopplat på labplatta och bilderna är från min logikanalysator så det du ser är vad som händer IRL.
Så mitt schema ser ut att stämma i alla fall? Om jag kan ha kopplat nått fel - you bet, men vad...
Aha, det är alltså en riktig encoder som du kör med nu!
>det kommer en klockpuls EFTER det att rotationsriktningen ändrats
Jo, men om det var riktigt kopplat skulle det inte komma något alls på "MED" efter att riktningen ändrats, och därmed skulle även det bli korrekt. Om du lyckas få "MED" att fungera som "MOT" gör (fast tvärt om) så ser du att "MOT" inte ger signal alls när riktningen är omvänd. Det ska inte heller "MED" göra. Så det problemet löser sig om du hittar felet på "MED".
Nästa gång du kör ett test så vill jag se hur det ser ut om du först kör motsols och byter riktning till medsols.
Yep, riktigt hårdvara, fysiska grejer - det har det varit hela tiden. Nånting är ju felkopplat det är klart men jag har inte lyckats hitta VAD, ska se om jag får lite tid i helgen.
Haha en väldigt simpel lösning hade väll varit att sätta 16 st d-vippor efter varandra och när sista vippan blir aktiv får man en puls samtidigt som alla vippor resetas. Lite OT nu när ni redan är inne på en lösning dock.
Ideer och ännu hellre lösningar är välkomna men "tävlingen" är avblåst. Jag räknande helt enkelt inte med att behöva koppla upp och utvärdera "bidragen" själv. Jag är fortfarande skeptisk till Jesses lösning men det är tydligt att nått är felkopplat på min lab-platta så jag ska se om jag kan reda ut det - annars går priset helt enkelt till Jesse eftersom ingen säger att det inte fungerar.
Men jag gör så att jag väntar ytterligare någon vecka eller så innan jag tar emot något pris, om det är OK för dig H.O. Jag vill själv undersöka mer noggrannt om det verkligen fugerar (dock ej på labbplatta, men på annat vis). Under tiden får folk givetvis fortfarande komma med invändningar om de skulle hitta något problematiskt med kopplingen. Vill absolut inte ta emot något pris om det senare visar sig vara felaktigt.
Men det var kul , de där 500 kr var en sporre (särskilt när man är fattig som jag) att verkligen fundera. Det är möjligt att någon av de senare bidragen fungerar lika bra med sin enklare konstruktion, men det är inget jag orkar kolla.
Nåja... jag kan inte hitta något fel än på mitt tävlingsbidrag. Om jag får 500 kr så lovar jag att koppla upp ett exemplar i hårdvara och testa (jag har börjat rita på en förenkling så att man kan skippa några kretsar utan att funktionen förändras). Tyvärr blir det nog i DIL-kapslar då jag inte orkar etsa dubbelsidiga kort för SOIC. Attiny var inte så lätt som jag trodde. Det hänger på hastigheten och marginalerna är små. Tror det finns varianter på Attiny som kommer upp i 20 Mhz, då kan det gå. Håller på med assemblerkoden till det.
Hade inte du utlyst en tävling hade det aldrig blivit något program till Attiny heller. Den borde inte ta mer plats än en SO8-kapsel och en avkopplingskondensator (+ ev jumpers för att ändra på div-faktorn).
Det är inte så lätt att verifiera med en verklig encoder. De tenderar att generera ganska enformig signal... svårt att skapa undantagen. Det är också väldigt lätt att simulera en encoder om man ska kolla max-frekvensen. Det "luriga" är att testa alla märkliga undantagsfall som kan uppstå, t.ex. om encodern byter riktning 500000 ggr/sek men bara hinner registrera en halv period. Själv anser jag att detta undantag aldrig kan ske i verkligheten och alltså inte borde ara relevant. Om axeln snurrar med en så hög hastighet så kan inte nästa persiod gå baklänges - det finns antagligen en kortast möjliga inbromsningstid - antagligen flera hundra mikrosekunder.
Om man förutsätter att encodern inte kan byta rikting direkt vid extremt höga hastigheter så kan den avkodas mycket enklare (särskilt med µC). Så fort den är uppe i en viss minimihastighet så vet µC'n att den inte kan byta riktning direkt och behöver inte göra lika många tester utan egentligen bara räkna pulserna in och dividera. Det är först i låg hastighet det är intressant att kolla om den byter riktning.
Hej,
Ursäkta att jag varit frånvarande i den här tråden. Jag "ligger ute" på jobb sen en vecka tillbaka så tid och internet-access är lite begränsat.
Vi säger att Jesse vinner och då får du självklart de 500:- jag lovade. PM'a kontoinfo så sätter jag in så fort spm möjligt. Men jag ser gärna at du kopplar upp och verifierar, men tänkt på att det skall vara enligt det schema du publicerat, inga ändringar för att bidraget skall vara giltigt.
Jag tror att en uC programerad att spotta ur sig sekvensen "i steg" är ett bra sätt att verifiera att man inte KAN tappa några "pulser". Tänkte själv göra så om/när jag får tid & lust att testa vidare. (Just nu behöver jag inte själv den här grejen så det har låg prio.)
>>> En PIC körandes på en 20MHz klocka har bara 10 instruktions-cycler på sig att göra vad som behövs när infrekvensen är 500kHz - det blir inte lätt då.
Men om man kör med en propeller på 80MHz får man ju 4ggr så stor hastighet jämfört med 20Mhz. Propellern har sen 8 kärnor som kan jobba samtidigt på mot samma portar vilket ger en 8 faldig hastighet. Då kommer antal cykler bli 10*4*8 = 320. Hur många cykler är nödvändiga för att systemet ska bli "stabilt".
)
Sen vet jag inte om det spelar någon roll men åt ena hållet så verkar klockpulsen gå hög på A's fallande flank medan den går hög på B's fallande flank åt andra hållet.
