Tricky rotary encoder from Alps
ciphernet
Posts: 24
Hi all,
I am trying to get a small 11mm ALPS rotary encoder to work, but..with some problems.
The small APLS encoders·differ from normal quadrature encoders by having detends, so every second idle state is high·for both·output pins and the next·step the encoder·outputs a low for both outputs. So the initial idle state, before turning the encoder can both be high and low... That´s seems quite tricky to me.
So, I was thinking about a state-machine that can handle both initial idle states by sampling the two outputs from·the encoder·four times in a continuous buffer·and keep on checking for any changes on the two outputs and then afterwards check·the direction.
I tried to tweak the code examples I have found, but it still works horrible.
Any surgestions ???
Jan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·Give me some slack, please.. I have programmed SX controllers for five years but the prop just blows my mind :-)
I am trying to get a small 11mm ALPS rotary encoder to work, but..with some problems.
The small APLS encoders·differ from normal quadrature encoders by having detends, so every second idle state is high·for both·output pins and the next·step the encoder·outputs a low for both outputs. So the initial idle state, before turning the encoder can both be high and low... That´s seems quite tricky to me.
So, I was thinking about a state-machine that can handle both initial idle states by sampling the two outputs from·the encoder·four times in a continuous buffer·and keep on checking for any changes on the two outputs and then afterwards check·the direction.
I tried to tweak the code examples I have found, but it still works horrible.
Any surgestions ???
Jan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·Give me some slack, please.. I have programmed SX controllers for five years but the prop just blows my mind :-)
Comments
best of luck,
Marty
<edit> wait? every other idle state is either both pins high or low? that sounds just like normal quadrature encoding. Really need to see the bit pattern now.
Post Edited (Lawson) : 6/24/2007 4:46:59 PM GMT
Using normal encoder code you should find that there is the same number of counts between each of the detent positions, it should be two because there are two edges between each although it does depend on the encoder.
Graham
The encoder is like a regular rotary encoder, but these small encoders have detents, and for every detent the encoder changes between idle high-state and low-state, so I have problems using the standard quadrature encoder method, since the idle state changes for every movement in either direction.
I have checked the pulse train with my scope and the "idle" state between turns are the only problem for me.
Also when turning the encoder either way, the encoder reacts "normal" and have the 90 degree phase difference, but the problem is that the standard quadrature method gives false results, meaning that when turning·either direction,·sometimes the·standard encoder routine gives a·wrong result, ACW becomes CW and vice-versa.
Jan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·Give me some slack, please.. I have programmed SX controllers for five years but the prop just blows my mind :-)
Thanks for your reply.
You are correct about the mechnical construction of the encoder. It is a nice feature that the encoder have the detents for my application.
The problem is that the standard encoder routine that I use from the object exhange, have no provision for the swapping of the idle state between high and low. The current routine just compares the old value read from the encoder and the new reading and since the new reading are different for each step, the standard encoder·routine generates many false readings.
How about my·idea of comparing both outputs from·the encoder·four·times (or more for that matter)·with certain intervals such as 1ms, so we can check if there has been movement with a phase shift. If both pulses are either high or low for·four samples, the encoder·must in an idle state and if the buffer shows a different pattern,·the direction can be read, depending on what·output from the encoder goes low (in my application) first.
How about that solution?
Jan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·Give me some slack, please.. I have programmed SX controllers for five years but the prop just blows my mind :-)
I would certainly not bother with time related solutions, there is a fixed relation between normal encoder counts and the current detent position assuming it is at rest when the program starts.
Graham
Maybe this project could help you? www.mcmanis.com/chuck/robotics/projects/lab-x3/quadratrak.html (Or someone else
Graham
www3.alps.co.jp/WebObjects/catalog.woa/PDF/E/Switch/Encoder/EC11/EC11.PDF
Thanks for your answer and your link to the datasheet. That is what I needed to know.
Jan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·Give me some slack, please.. I have programmed SX controllers for five years but the prop just blows my mind :-)
Great Link!! I forgot about that website. I did see it a while back but forgot all about it again. That PIC encoder code have the provisions for all the states that the Alps encoder provides and it´s·easy to translate it for use with the Prop.
I will hopefully get the Prop code up and running tonight!
Thanks!!
Jan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·Give me some slack, please.. I have programmed SX controllers for five years but the prop just blows my mind :-)
Graham
"The stable detent position cannot be identified in phase B"
sounds like poor translation to English:
More like "phase B cannot be identified in the stable detent position".
...Personally I would chuck it in the garbage, and get one where each detent is a 1/4 change in the quadrature code:
Detent: Low Low
Detent: High Low
Detent: High High
Detent: Low High
Works a lot better than the (surprisingly) more common:
Detent: Low Low
High Low
High High
Low High
Detent: Low Low
The only thing with the 1/4 detents is that when you power up, you have to read the initial state instead of assuming Low-Low.
It doesn't actually really matter anyway as long as you track the quadrature incrementally.
Graham