0
\$\begingroup\$

Earlier I connected one of those Joral encoders to a motor via a gearbox and recorded some test data – unfortunately the encoder is sometimes sending what seems to be nonsensical values (numbers much bigger than the expected maximum, number of turns changing at the wrong time...).

Encoder mounting:

Since(in this case) the encoder rotates 62 times for a single revolution, the encoder must keep track of the number of turns as well as the angle. The encoder looks like it can remember up to 65536 turns. After that it forgets and starts over at zero. Realistically it means I can track the arm angle perfectly for 528 arm rotations from an arbitrary home position (32768 encoder turns / 62 = 528.51... which is not a nice round number) . If someone tries to move any further in that direction it will no longer be able to sense the angle accurately - It would be impossible to distinguish between true “home” vs 528.51 arm rotations as the data sent by the encoder would be the same for both positions.

Any ideas on what I could try to do here?

Much appreciate any help!

\$\endgroup\$
  • \$\begingroup\$ Perhaps reset the encoder each rotation? Or use an additional encoder to distinguish home vs 528.51? I suspect your guess for a solution is as good as ours without more information \$\endgroup\$ – CL22 Apr 20 '17 at 4:46
  • \$\begingroup\$ Yeah or I could replace the gearbox, because if the gear ratio was a power of 2 like 64:1 then the turn counter would reset after exactly 512 arm rotations (32768 / 64=512) and this problem would go away. But I wish it didn't have to come to that. \$\endgroup\$ – Raf Apr 20 '17 at 4:57
  • \$\begingroup\$ You could add a second very crude encoder that counted 1/2 turns, for example. Think of a minute hand on a stop watch. \$\endgroup\$ – George White Apr 20 '17 at 5:11
1
\$\begingroup\$

Store the previous encoder output in a variable before you receive a new reading. If the previous value was closer to 65536 rasher than 0, yet the new value is closer to 0 rather than 65536, you know that the count has overflowed or "wrapped around". You can then count these overflows in a separate variable: you decrement the overflow count by one when 0 -> 65536, you increment by one when 65536 -> 0.

You could then recover the actual turn count by multiplying the overflow count by the maximum encoder turn output range (65536 - 0) and adding the current encoder turn count.

\$\endgroup\$
1
\$\begingroup\$

For encoders, that I need to monitor position with, I almost never use the actual encoder value(s). I don't actually bother with absolute encoders, though it doesn't really matter, absolute vs. incremental.

You will need a processor capable of some math, and a couple registers. Designate some registers as "My_Encoder_Count", "Old_Count", and "Delta_Count". Every program scan, calculate Delta_Count from the Raw Encoder Value - Old_Count, move the current Raw Encoder Value to Old_Count, and add Delta_Count to "My_Encoder_Count". Done.

To reset the count, just clear My_Encoder_Count.

Some hidden advantages to this method, you can initialize Old_Count with the raw value on program startup to eliminate weird values from absolute encoders that forget their place (very common) or jitter from incremental encoders.

You also can decide to use a cheaper incremental encoder, and you can maintain the internal count through power cycles.

\$\endgroup\$
  • \$\begingroup\$ I think we have a winner here. I'll keep you posted on how it goes. Thanks mate. \$\endgroup\$ – Raf Apr 20 '17 at 23:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.