Dividera encoder pulser

[Rauken]

En lösning som Universal avände till sina komp.isättningsmaskiner, består av 1st 7474, 1st 7486, 3/4st 7400 och 74193.
Jag har kopplingen i pdf. Men hur gör jag för att lägga upp den?

[Borre]

Använd en uppladdningssida, tex http://pici.se/ , och klistra sen in länken här.

[Rauken]

OK, då får vi se om det funkar!
http://pici.se/p/hzNXiXPLE

[jesse]

Imponerande, men hur tar vi reda på att det verkligen fungerar under alla omständigheter? Blir jag tvungen att plocka fram lab-plattan?

tja... jag orkar inte bevisa just nu att den fungerar i alla lägen. Men i min andra länk där jag kladdat lite siffror, till synes planlöst - är ett funktionsschema där jag försöker få med alla tänkbara möjligheter.

Först utgick jag från en tidsaxel med de två signalerna A och B och försökte hitta på något med hjälp av att trigga på flankerna... Jag hittade en lösning som funkade i alla lägen... nej. Om den gick ett halvt varv och sedan tillbaks och samma sak om igen så registerades det som ett helt varv + ett till. Då gav jag upp den tanken och började skissa på andra sätt. (Jag frestades att ta till en kondensator (som i PDF-länken ovan) för att på så sätt registera flanker, men tyckte inte det var en "snygg" lösning då alltihop blir tidsberoende - förloppet får inte gå fortare än att kondensatorn hunnit ladda ur.)

Så jag försökte tänka om helt. Istället för att rita tidsaxel så ritade jag en cirkel med de fyra tillstånden 00 <---> 01 <--> 11 <--> 10 <--> (tillbaks till 00 igen). Eftersom den bygger på idén med gray-skalan så blir det inga problem vid omslag. Den kan bara ändras på två möjliga sätt i ett visst läge (fram eller bakåt i cirkeln).

Sedan valde jag att representera de fyra möjliga tillstånden med fyra separata signaler som jag då kallar 00,01,11 och 10 och som skapas med hjälp av en multiplexer.

Härifrån utgick jag från tanken att "ett varv medsols" räknas om det går från 00 till 00 igen om och bara om det börjar med 01 och slutar med 10 och däremellan passerat 11. Ett varv motsols samma fast tvärt om. Om den stannade och gick tillbaks ett steg skulle SR-vipporna återgå till det föregående status för att - om det går helt tillbaks till 00 resettas. Genom att göra en gtaf över alla tänkbara händelseförlopp under ett varv kan man alltså rita upp alla SR-vippornas tillstånd och hur de förändras under processens gång. Eftersom det bara finns två alternativ vid varje "läge" (fram eller bakåt) så blir diagrammet inte oöverskådligt stort. (se länk2 i min tidigare post)

Den enda osäkerheten som finns kan eventuellt vara vid uppstart - då SR-vipporna antar ett slumpartat läge och därmed kan signalera ett varv fram eller bak vid första förändringen. Det kan man lätt lösa genom en power-up-reset-signal till SR-vipporna och räknaren, eller helt enkelt ett par pull-up och pull-down motstånd på SR-vippornas utgångar så dom startar upp i rätt läge (dvs alla vippor Q = 0 ). Annars borde det räcka att räknaren får en reset vid uppstart - då händer ändå ingenting på utgången det första varvet.

Jag antar att det är du H.O som är domaren här, så vad ska man ha för kriterier? Om ingen på forumet kan komma på en hållbar invändning under en veckas tid, kanske?

[H.O]

OK, du verkar ha analyserat det hela tämligen ordentligt, just uppstarten var en grej jag tänkte på men det kanske räcker att bara resetta vipporna och räknaren - precis som du säger.

Kriterierna är ju rätt klara - de står i mitt tidigare inlägg och det är dom som gäller - det ska "bara" fungera, helt enkelt. Självklart kommer jag stå vid mitt ord och 500:- om det funkar. Det hela är lite för komplext för min hjärna att analysera så det bästa är nog att koppla upp det hela, IRL eller i datorn - någon som har bra koll på nått simuleringsprogram?

Tecno, är du kvar? Sugen på att labba lite

[jesse]

Ska jag vara riktigt petig... och det måste jag ju vara - så har jag också funderat på vad som händer inuti en xor-grind när A och B slår om samtidigt. "samtidigt" existerar ju inte i verkligheten, men räknaren är synkron så det är så "samtidigt" som möjligt. Men en 74LS XOR-grind slår över på max 23nS... vad händer under tiden? För säkerhets skull, och enligt konstens alla regler plockar man därför bort alla korta pulser (både positiva och negativa) från XOR-grindens utgång med ett RC-filter och en schmitt-trigger-buffer. RC-nätet kan i det här fallet vara t.ex. 4.7kΩ och 100pF. Då filtreras allt under 0.5µS bort. Så är det problemet också löst (om det nu fanns ett sådant problem från början). Den korta fördröjningen ska inte påverka slutresultatet inom de marginaler som är uppsatta.

[Larsson90]

> Har sett att någon försökt sig på att knyckla nåt med AVR men inte sett nått med PIC

Det är väll egentligen bara att plocka in pulserna i PIC:en och sen skriva ett litet simpelt program som kollar hur många pulser den fått in?

Kod: Markera allt

double pulses = 0;
int conPulses = 0;

int main() {
     /* Denfinera ben och annat krafs */


     while(true) {
          if(PORTA.F0) {
               pulses++;
          }

          if((pulses/16) & 1) {
               conPulses++;    
          }

          if(conPulses == 3600)
               conPulses = 0;

     }

     return 0;
}

[tecno]

Hallå all kamrater,

visst är jag sugen på att labba då detta är ett 'problem' som jag gärna ville ha en lösning på. Ja inte bara jag utan många med mig som säkerligen har dessa 3600ppr encodrar eller dito med ännu större upplösning har ett intresse av att få till detta så vi kan börja leka med våra motorer.

[tecno]

Larsson90

Tydligen är det inte bara för då hadde nog detta funnits ute på nätet. Har heller inte sett ATT det fungerar fullt ut med AVR lösningen.

Jag är idel öra på en lösning den vägen om du kan få till det, detta är ju utanför H.O's utfästa 'tävling' dock.

[jesse]

>Det är väll egentligen bara att plocka in pulserna i PIC:en och sen skriva ett litet simpelt program som kollar hur många pulser den fått in?

om det hade varit så enkelt så hade nog inte den här tråden funnits.

[jesse]

hoppsan, tecno hann visst före mig där.

tecno: Är det mycket folk som söker efter en sådan? Vad tror du folk skulle ge för en färdigbyggd sådan delare? Hur stor skulle den få vara (max) och vad skulle den helst drivas på för spänning/ max-ström? Vilken typ av anslutningskontakter skulle vara lämpligast i sammanhanget? Skulle man vilja ha den färdig och klar i en liten egen låda, eller som kretskort för intern anslutning?
Är 1/16 en allmän delningsfaktor som duger åt de flesta eller behövs det flexibilitet här (dvs kunna ställa in /8 /16 /32 osv? kan det finnas behov även för t.ex /10 ?) Funderar om det kan vara lönt att konstruera en färdig modul?

[Larsson90]

har aldrig labbat med en encoder men det vara bara ett förslag för kan man få 1 och 0or på ingången så borde det i princip vara löst.

[H.O]

Jesse,
Jag håller på att fixa till schemat med lite pin-numreringar etc, sen ska jag se om jag får tid att koppla upp det hela. Jag hade allt utom XOR grinden hemma så jag borde kunna testa lite i alla fall. (Men det blir lite till och från när jag får tid.)

För en färdig "produkt" så skulle jag säga att det behöver gå att dela med annat än bara 16, helst även annat än potenser av 2. Din lösning - om den fungerar - är ju minst sagt "bökig" att använda i praktiken med sina 10 IC-kretsar. (Men det spelar ingen roll just nu). I praktiken är ju såklart en FPGA eller liknande den rätta vägen att implementera kretsen.

Larsson90, det är inte speciellt svårt att göra det med en PIC, problemet är frekvensen. 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å.

[SvenW]

>>> 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å.

I flertalet fall går det bra att undersampla, och då är det inga problem att använda en PIC, låt vara att en ATMega kanske är något snabbare.

Man beräknar hastigheten och predikterar positionen vid nästa sampling, och det blir inte mycket fel. Samplingsfrevensen kan ligga lång under pulsfrekvensen. Bara man har koll på när i tiden man samplar.

[H.O]

Du menar att man integrerar hastigheten och på så vis får fram en position som, så länge den ligger inom en kvadratur cykel, "syncas" mot encodern vid nästa sampling? Intressant men betydligt mer komplicerat och orden det blir inte mycket fel skrämmer mig. Om den KAN prediktera fel så gör den det förr eller senare och då faller allting - i alla fall i min bok.