Rotary encoder accuracy - mine doesn't seem very good - Page 1
Forum section: electronics / projects

author: Corporate666
author_rank: Unknown
timestamp: March 06, 2019, 06:56:31 am
content: I picked up one of those cheap Chinese incremental rotary encoders from Amazon to use for measuring linear speed... I'm timing the gap between pulses to come up with a speed reading. I am seeing a variance of 15%, even when I turn the encoder at a very precise rate. I've attached a wheel to the encoder and mounted it to the table of my (pro, not hobbyist) CNC machine, and hooked up the encoder output to my oscilloscope and I see a variance of +/- 15% in pulse width (and time between pulses) as the encoder turns. It isn't random... it seems to cycle from -15% to +15% and back, which seems to suggest slop in manufacturing.I'm wondering if this is normal for these cheap Chinese encoders or is this possibly just a bum unit? I don't want to buy a handful more if they could all be expected to be equally bad. What about the $50-100 range encoders from the likes of Grayhill, Copal, and Honeywell - should I expect more accuracy from those units over the Chinese encoders from Amazon?Thanks for any input.

author: ataradov
author_rank: Super Contributor
timestamp: March 06, 2019, 07:23:24 am
content: What specific encoder you are talking about? I've used this typehttps://www.ebay.com/itm/DC5V-24V-360P-R-Encoder-Incremental-Rotary-360-Pulses-R-AB-2-Phase-6mm-Shaft/141656690772and a few units I've got were fine. But this was many years ago, so they may have optimized something in the design.

author: timpattinson
author_rank: Contributor
timestamp: March 06, 2019, 08:36:54 am
content: Is it inside the specified nonlinearity?

author: Corporate666
author_rank: Unknown
timestamp: March 06, 2019, 08:57:29 am
content: Quote from: ataradov on March 06, 2019, 07:23:24 amThe one I am using at the moment is this one:https://www.amazon.com/gp/product/B00Y9KDDCY

author: Corporate666
author_rank: Unknown
timestamp: March 06, 2019, 09:00:55 am
content: Quote from: timpattinson on March 06, 2019, 08:36:54 amI haven't seen any manufacturer of optical incremental encoders list a spec for non-linearity in their datasheets, and certainly not these Chinese units, so there's no way to know if it's in-spec or not. I assume it's just crap quality... so was hoping others could speak to their experiences with them.This is the OEM:http://www.china-encoder.com/and the encoder:http://www.china-encoder.com/product_detail/productId=24.htmlit seems to me that a variance of +/- 15% for an optical incremental rotary encoder is massive and shouldn't be the norm... but maybe I am expecting too much. Just wondering if I got a bad unit, or if it's par for the course, or if I should expect a $50 or $100 encoder from a name brand to be better (and if so, how much better), or how much I need to spend to get 1% or so?

author: OM222O
author_rank: Frequent Contributor
timestamp: March 06, 2019, 11:37:17 am
content: Can you provide the code/oscilloscope trace which you used to measure the speed? I've used cheapie ones without much of an issue tbh.

author: retrolefty
author_rank: Super Contributor
timestamp: March 06, 2019, 12:15:42 pm
content: Looking at the details of the listing for that encoder I see that it has open collector NPN A & B output pins. Are you to supplying proper pull-ups for these signals to operate properly?

author: Fungus
author_rank: Super Contributor
timestamp: March 06, 2019, 03:12:53 pm
content: Quote from: Corporate666 on March 06, 2019, 06:56:31 amSo? The RPM will be the same.

author: Peabody
author_rank: Super Contributor
timestamp: March 06, 2019, 03:22:58 pm
content: Seems unlikely that an optical encoder would vary that much. Does the +/-15% cycle coincide with one encoder revolution?

author: Corporate666
author_rank: Unknown
timestamp: March 07, 2019, 06:58:39 am
content: Quote from: Fungus on March 06, 2019, 03:12:53 pmNo, it won't.

author: Corporate666
author_rank: Unknown
timestamp: March 07, 2019, 07:00:05 am
content: Quote from: Peabody on March 06, 2019, 03:22:58 pmThe variance repeats... in other words, it's over in the same position of revolution each time and under in the same position of revolution and it generally smoothly transitions from the min to the max and back. That's what makes me think it's a manufacturing issue.

author: Corporate666
author_rank: Unknown
timestamp: March 07, 2019, 07:01:58 am
content: Quote from: retrolefty on March 06, 2019, 12:15:42 pmYep, I'm using pull-ups.

author: ataradov
author_rank: Super Contributor
timestamp: March 07, 2019, 07:02:09 am
content: Those encoders use transparent plastic disc and a couple of optical pairs, and offset of that disc from the axis would produce this behavior.

author: Corporate666
author_rank: Unknown
timestamp: March 07, 2019, 07:05:28 am
content: Quote from: OM222O on March 06, 2019, 11:37:17 amI didn't save it but I just probed the encoder outputs in-circuit to see why I was getting such a variance in my reading, so there wasn't code involved as such. I am seeing the quadrature output and the square wave looks perfect. It's simply that the period and duty cycle/pulse width change over the course of a revolution, despite the encoder shaft being turned at a precise rate.I picked up a few more encoders and will see if they do the same or if this might be a bad unit.

author: IconicPCB
author_rank: Super Contributor
timestamp: March 07, 2019, 07:36:12 am
content: How will this cyclic error show up once the quadrature signals are decoded?As for speed, use a tacho these are used as positional sensors primarily.If used to synthesise a tacho signal... apply a bit more averaging and you wont notice it.

author: mikerj
author_rank: Super Contributor
timestamp: March 07, 2019, 01:04:59 pm
content: Looking at anOmron datasheetfor a similar (but $$) encoder, it specifies a maximum phase variation between the quadrature outputs of +-1/8th of the period of one complete cycle.

author: Corporate666
author_rank: Unknown
timestamp: March 08, 2019, 10:02:31 am
content: Quote from: IconicPCB on March 07, 2019, 07:36:12 amAs I mentioned in the first post, I am timing the pulses to determine speed. This is necessary to accurately determine speed.Can't average it out when it's +15% on one side of the wheel and -15% on the other side of the wheel. If the wheel was turning at sufficient RPM, that would work... but there are mechanical constraints I must work within on this project.

author: IconicPCB
author_rank: Super Contributor
timestamp: March 08, 2019, 11:02:37 am
content: Sooo...whas the pulse rate you are seeing at the rotational speed in question... parts of an RPM?few RPM?tens of RPM?

author: tecman
author_rank: Frequent Contributor
timestamp: March 08, 2019, 07:51:14 pm
content: Your machine rotating the encoder could have mechanical tolerances in the drive gearing that would give velocity variations within one turn. If you can determine that the error is at the same rotary phase angle it could be the drive. I have used many hundreds of encoders over my years (none chinese) and have never seen variations as you are seeing. The disc which is typically photo lithographed could have reeors that you are seeing, but it would be a gross error in production, and would generally effect an entire batch of products. I would be surprised by that.paul

author: techman-001
author_rank: Frequent Contributor
timestamp: March 12, 2019, 12:00:51 am
content: Quote from: tecman on March 08, 2019, 07:51:14 pmExcellent point, my money is on this reason as the cause. The OP needs to use a method of guaranteed rotational accuracy, perhaps on the cross slide of a lathe or milling machine etc.

author: exuvo
author_rank: Contributor
timestamp: March 13, 2019, 05:47:16 pm
content: In my opinion your encoder is just fine, you are just reading it badly. Don't measure the time between the last two transitions, that is way too sensitive to manufacturing errors. Instead measure the amount of transitions in a given time interval. If you have too few transitions in your time interval for decent speed resolution either increase the measurement period or gear up the encoder to produce more transitions.In my robot I use a hardware quadrature decoder and 16bit counter which i read often enough to ensure it has never moved more than half in either direction, otherwise i would not know if it went up or down between the last read. For me this rate is 50Hz, which gives the average speed over the last 20ms with good resilience to encoder step variability and random EMI events as the measurement includes hundreds of steps. This also gives the ability to count revolutions/distance at the same time.If I need to drive the motors really slowly I instead add the last 5 speed readings of the counter, effectively the last 100ms, and use that value with a differently tuned PID loop.

author: ataradov
author_rank: Super Contributor
timestamp: March 13, 2019, 05:51:14 pm
content: I think people here are talking about different things. The goal of this encoder is to determine the position. It is not an RPM sensor. You can't measure the amount of transitions in a time interval, it just does not make sense. You need to read each edge transition.

author: exuvo
author_rank: Contributor
timestamp: March 13, 2019, 06:00:41 pm
content: Quote from: Corporate666 on March 06, 2019, 06:56:31 amThat sounds very much like it is to be used for speed and not position? Either way my method still works fine for both. Just gear up the encoder so that you are not relying on the relative positions between individual transitions and can instead average out the edge to edge differences over a much larger amount of transitions at which point they are no longer noticable.