EXT-ENCODER (U161) proper use & tricky problem
-
Does anyone have any experience using the EXT-ENCODER (U161) to read rotary encoders? When I connect a Type LPD3806-360BM Rotary Encoder, I can accurately count the pulses if the RPM is very slow. When I look at the A and B inputs with an oscilloscope the EXT-ENCODER is adding capacitance causing the leading edge of the pulse to be rounded off. If the RPM is increased, the pulses never reach enough voltage to be counted. Disconnecting the A & B leads removes the capacitance and restores the encoder pulses to a perfect square wave even at high RPM. The EXT-ENCODER schematic shows pull up resistors which are required and they appear to be correct.
This is the first time I have worked with reading encoders & I need to learn more.
-
@earla said in EXT-ENCODER (U161) proper use & tricky problem:
LPD3806-360BM
The Encoder outputs are NPN Open Collector.
The Encoder output is active low.
The signal is normally 'high' and a pulse brings it to ground, 'low'.
Indeed, the manufacturer says that you cannot see pulses on an Oscilloscope if it is disconnected from the pull up resistors in the sensing Unit.
This can cause some confusion! -
@teastain Thank you! Good information.
-
@earla Hello, did you solve that problem with ext_encoder? Iam having same issue with omron encoder , its 2000rpr resolution with A B and Z channels. Iam gettig any readings only if iam spinning it very slowly.
-
@radzieju Could require pull up resistors. Could you provide the part number of the encoder, test wiring schematic and user sketch (program app)?
-
@teastain Hi, encoder is omron E6B2-CWZ6C 2000P/R 5-24v , channels a b z are connected to u161 ext-encoder with 10k ressistors. I tried with and without resistors , also i tried 4.7k.
pull up ressistors are between channels and +5v.
M5stickc is powered by usb.I am using uiflow blocks.
iam trying to measure a lenght of material, it shows a counter values and meter value , but i have to rotate a shaft very very slowly.When i spin a little faster it just stop counting and show same value. -
-
@felmue yes, there are 10k resistors built in into encoder unit i tried with and without them. No good readings.
-
I need to connect an encoder to a Raspberry Pi and noted the M5Stack EXT-ENCODER (U161) appeared to offer exactly what I needed. However, initial testing identified a couple of issues.
Two test rigs were used - both gave similar results. The first used a commercially available encoder rated at 1600 pulses / round (quadrature) and max rotation rate of 5000 rpm. For the first test, the encoder shaft was rotated by a motor driven friction wheel. The second encoder was a hobbyist unit pre-mounted on a small motor. In both cases the A/B encoder and power connections went to the M5Stack EXT-ENCODER which was further connected to the Raspberry Pi GPIO header as per specifications. No additional pull up/down resistors were added as my reading of the device spec was that these were provided internally by the EXT-ENCODER where required.
The test was run multiple times each driving the motor at higher rotation rates via increased PWM values. Each run was over a period of 20 seconds with the EXT-ENCODER pulse value sampled over the I2C bus every 200ms. The difference between the latest and previous count value was recorded.
The encoder values were computed as per the M5Stack documentation from the 4 bytes pulled from the I2C port 0x59 Register 0x10
The graph below plots the average change in pulse value for 200ms samples at each motor speed.
As expected, the value returned by the EXT-ENCODER increases as the motor rotation rate rises. However it reaches a point where increased motor speed results in no further rise in the value returned by the EXT-ENCODER and instead starts to drop. Any further increases in motor speed result in the device reporting the same value repeatedly. I should add these rotation rates were fairly low.
I’m wondering if this means the rate at which the encoders were generating pulses exceeded the EXT-ENCODER’s ability to ‘catch’ them.
So my question is - what is the practical maximum pulse rate the EXT-ENCODER’s STM32F030 microcontroller can sustain and still reliably report it over the I2C bus? I’m using the SMBUS package for this.
I’ve tried both increasing and decreasing the I2C bus speed on the Raspberry Pi but this made no difference.
Another observation during these tests was that the EXT-ENCODER would very occasionally show an unexpected and sudden change in the encoder count value returned from the EXT-ENCODER. The EXT-ENCODER holds the pulse count as an unsigned 32bit integer and can be shown to accumulate counts up to the max value of 4294967295 before wrapping round back to zero (the converse happening for rotation in the opposite direction). However, these random flips of the returned count were obviously happening in the EXT-ENCODER as subsequent I2C calls continued to return values rising from the
Two examples (below) - note that the erroneous value can be either higher or lower than a previously returned value with no change in motor rotation direction.
Eg 1
Prev_val New_val
210624 211307
211307 211989
211989 212667
212667 180582 <<<<<<<<<<<
180582 181266Eg 2
Prev_val New_val
32389 32506
32506 32622
32622 32736
32736 4294934607 <<<<<<<<<<<
4294934607 4294934720
4294934720 4294934837Any observations welcome.
john
