Rotary encoder usage

hippy

hippy

Ex-Staff (retired)
Have you done the basic tests on your hardware ?

Put LED's+R on Output B.1 and B.2 ...

Code: 
#Picaxe 18M2
dirsB = %00000110
Do
  pinsB = pinsC
Loop
Or even -

Code: 
#Picaxe 18M2
#Terminal 4800
Do
  b0 = pinsC & %00000110
  If b0 <> b1 Then
    b1 = b0
    SerTxd( #bit2, #bit1, CR, LF )
  End If
Loop
 
hippy

hippy

Ex-Staff (retired)
For the code in post #118 there's also a potential confusing data condition, where the encoder is changing faster than the PICAXE can process things, inputs on the left -

00
01 interrupt:
11
10 bit2 = pinC.2
00
01 bit1 = pinC.1
11

You'd have a result that interrupt occured on '01' but b0 holds '11'. Not sure if that would cause the code to jam up or just give odd results, and not sure if that's the case here.
 
E

Electromonkey

New Member
Hippy, thanks for the test code just ran it and checked back through the serial output which seems to highlight the problem:

10
11
01
00
10 good encoder output
11
01
00______
11
00
10
01
00 then output goes wrong
11
01
10
01

Have done basic tests on the encoder with leds and the input looked ok, will try another encoder but other than that may be a speed issue.
 
hippy

hippy

Ex-Staff (retired)
Rotary encoders shouldn't change two bits at a time so that's either the change happening too fast, the PICAXE too slow, or the encoder not working.
 
hippy

hippy

Ex-Staff (retired)
Running with SETFREQ M32 ( SERTXD baud rate 19200 ) may show better results or hold up for higher speeds. Adding any reporting such as SERTXD will impact performance though. I think one of the Finite State Machine versions included missed step detection to try and do a better job a higher speed.
 
E

eclectic

Moderator
hippy said:
Running with SETFREQ M32 ( SERTXD baud rate 19200 ) may show better results or hold up for higher speeds. Adding any reporting such as SERTXD will impact performance though. I think one of the Finite State Machine versions included missed step detection to try and do a better job a higher speed.
Click to expand...
Or, can
Electromonkey just slow it down a bit?

Half joking.

e
 
E

Electromonkey

New Member
This is where it puzzled me, if an 18x can keep up with me encoder spinning without fault why can't the 18m2?
Anyway just to keep you posted I had presumed that the 18m2 ran at 32MHz as default, but by adding 'setfreq 32' at the beginning it only fails once in roughly 300 encoder detents (or 3.5 revolutions) which I think I can live with :)
Thought that this might have been a red herring but took the line out again and it reverts back to throwing out random 0's and 2's.
Thanks guys for the advice over the past few days.
 
W

william47316

New Member
heres some code i wrote up for the 08M and an encoder from a junk home stereo, it has two outputs that goes 1,0 then 1,1 going anticlockwise and 1,1 then 1,0 going clockwise. the code is a bit simple however it will work quite well if in its own routine, uses pull down resistors. im not sure how well the other code people have posted would work on an 08M or other chips but mine should work on most chips with at least two inputs even an 08 probably however at times it does glitch a bit going the reverse of the direction your turning but for the most part it will work

Code: 
'rotary encoder program
symbol changeflag = bit0
symbol mainvar = w1
mainvar = 32676
main:
if input4 = 1 and input3 = 0     then
traploop:
if input3 = 1 then
dec mainvar
changeflag = 1
goto disp
end if
goto traploop
end if


if input4 = 1 and input3 = 1 then
traploop2:
if input3 = 0 then
inc mainvar
changeflag = 1
goto disp
end if
goto traploop2
end if
goto main

disp:

if changeflag = 1 then
changeflag = 0
sertxd (#mainvar,8,8,8,8,8,8,8)
end if
goto main
 
E

eclectic

Moderator
Electromonkey said:
This is where it puzzled me, if an 18x can keep up with me encoder spinning without fault why can't the 18m2?
snipped
Thanks guys for the advice over the past few days.
Click to expand...
I've just "found" an 18X.
Tested it using a version of Hippy's program.

Please note

the upper 11 01 transition is slow turning.

the lower 11 00 transition is fast spinning.

e
 

Attachments

hippy

hippy

Ex-Staff (retired)
There are differences with the 18M2 against the 18X; it does more so the token sizes and encoding are different in places and this will impact on firmware execution speeds but in general it should be pretty similar, and there should only be a few microseconds in it.

Could it be the 18X was running at 8MHz while the 18M2 is running at 4MHz ?

One of the major problems with trying to observe a system which requires speed of response is that putting anything in the program which reports results slows response rates down. There's probably more time spent sending the SERTXD data than the time it takes to otherwise go round the loop.

How many pulses per revolution will also affect the performance; the more step the faster they will arrive - How many steps per revolution are there ? In post 119 you said, "only fails once in roughly 300 encoder detents (or 3.5 revolutions)", so that suggests less than 100 per revolution.

100 pulses per revolution per second should be one per 10ms, and even at 4MHz the PICAXE should be able to keep up. Of course speed of turning will affect things; how fast is it being turned ?
 
Last edited:
A

alistairsam

Senior Member
Hi,

thought i'd post a video of a quadrature encoder test i rigged up using hippy's original finite state machine code.

this is using a 20x2 at 64Mhz, and another 20x2 for the display.

the codewheel and detector were salvaged from a hp deskjet 712 printer. it has 1800 CT printed on it, so that with quadrature amounts to 7200 which is what the picaxe counted.
they have two such detectors, one on the paper axis and another on the print head, so pretty good source if you want high res codewheels.

i just wanted to test the codewheel and detector.

http://www.youtube.com/watch?v=GdWUQ3rguUU

output from the detector was sine waves, so i connected it to a cd4093 schmitt trigger and back to another of its own NAND gate configured as a NOT gate.

Hippy's code is unaltered, and I think works well for my application which is for position control of a telescope's major axis.
thanks Hippy.

still trying to understand the code though!!.
 
Last edited:
You must log in or register to reply here.
Top