Switching from Mechanical Encoder to Optical Encoder

Ian Rogers said:
I made a small PCB to interface the cable to the sensor, That way I have tons of room..
Click to expand...

Hmm, well a PCB may not be an option here, but I see no reason why Veroboard wouldn't work. Thanks for the idea Ian!
 
User always has choice of low side ot high side switch to invert the logic. ( common to 1 or 0)

The advantage of quadrature commutation is that logic is easy to ignore contact bounce or noise by decoding to direction and count pulse.

A count pulse cannot occur simultaneously with a change in direction.
 
MaxHeadRoom78 said:
Apart from the 25ma sink detail the actual (output) nature is not shown.
Click to expand...

True, but the minimum output high voltage spec, symmetrical rise and fall times with no conditions, and the absence of any mention in the interface drawings combine to give a pretty clear impression. imho

ak
 
The Bourns opto sensor is a good solution.
Note that two options 32 detents with 8 PPR or 32 PPR.

The detents are in between Channel commutation position, but doesn't mean slow rotation might cause some extra false pulses on one channel only depending on spring effects, backlash and optical hysteresis.
The logic ( or code) for Direction and step pulse will ignore this, which is the advantage of quadrature methods.
 
Last edited:
The opto encoder I have selected does not have the detent. I settled on the EM14A0D-C28-L032N (rated for 1M+ rotations, which is far better than the 200k for the ones with the detent. The original mechanical ones were rated for 100k).
 
Hi everyone. I felt I should just resurrect this thread instead of starting a new one, since this is the same project.

After discussions with the engineers who will be using the device these encoders control, we decided to use the Avago HRPG-AD32#56C instead, which is a detented encoder (datasheet: https://media.digikey.com/pdf/Data Sheets/Avago PDFs/HRPG_Series.pdf )

The whole PPR/CPR has been a bit confusing though. I understand PPR ("pulses per revolution") really should not be used for quadrature encoders, yet I frequently see it anyway.

After fitting the encoders in to the new board and hooking it up to test, we're seeing some issues with inconsistent increments per detent, and if it's spun very quickly it actually seems to register as going backwards. We never had this problem with the old mechanical encoders. Any thoughts on what would cause this?

I did notice quite a bit of flux residue on the boards, and the encoders had been sitting out of their packages for a while on a desk. Any chance they were damaged by ESD?

Thanks guys,
Matt
 
DerStrom8 said:
The whole PPR/CPR has been a bit confusing though. I understand PPR ("pulses per revolution") really should not be used for quadrature encoders, yet I frequently see it anyway.
Click to expand...
Just as the term 'Quadrature' when used with an encoder should not be used to describe the x4 technique of using the 4 distinct edges to increase the resolution.
Max.
 
DerStrom8 said:
The opto encoder I have selected does not have the detent. I settled on the EM14A0D-C28-L032N (rated for 1M+ rotations, which is far better than the 200k for the ones with the detent. The original mechanical ones were rated for 100k).
Click to expand...

For clarity...
The optical switch part is rated for 1e6+ in both, the detents are optional but are the parts which are rated for less.
The push switch in yours is also rated for less (100k), but should be more than adequate.
 
MaxHeadRoom78 said:
Just as the term 'Quadrature' when used with an encoder should not be used to describe the x4 technique of using the 4 distinct edges to increase the resolution.
Max.
Click to expand...
I was thinking that was a standard way of describing the operation of that type of encoder...?

Tony Stewart said:
For clarity...
The optical switch part is rated for 1e6+ in both, the detents are optional but are the parts which are rated for less.
The push switch in yours is also rated for less (100k), but should be more than adequate.
Click to expand...
Yes, I am aware that the parts that create the detent are what wear out the fastest. I understand it will still operate, but the user won't feel the detents easily after they wear out.
 
DerStrom8 said:
I was thinking that was a standard way of describing the operation of that type of encoder...?
Click to expand...

You will see quadrature encoder often used to describe the x4 feature, but the term quadrature encoder in this context refers to the 90° phase shift of the two pulses.
Whatever the resolution increase method used (or none).
Max.
 

Not so.

Quadrature encoders are used for any resolution of rotary or linear encoding with two orthogonal signals (90deg phase shift ) giving 4 binary (Quad) states.
Therefore PPR is very appropriate for rotary encoders. I think your confusion is the CPR. AVAGO has the same CPR as PPR whereas Bournes does not in the previous parts examined.



You may be using a higher PPR resolution such as 32x compared to the mechanical one before or spinning it faster and thus the reverse rotation ( wagon wheel effect) will occur when the sampling rate is slower than 1/2 of the quadrature pulse rate.

I did notice quite a bit of flux residue on the boards, and the encoders had been sitting out of their packages for a while on a desk. Any chance they were damaged by ESD?

Thanks guys,
Matt
Click to expand...

This would not explain your symptoms. But it is a good practice to follow ESD handling on parts you intend to use that require this.
 
DerStrom8 said:
if it's spun very quickly it actually seems to register as going backwards. We never had this problem with the old mechanical encoders. Any thoughts on what would cause this?
Click to expand...

Sounds like the same stroboscopic effect that makes wagon wheels look like they're turning backwards in old westerns, otherwise know as frequency-domain aliasing. At 1 pulse per revolution, the output is rated for 5 Hz max. That's not much, and I'm not surprised that rapid spinning causes dropped pulses. If one output phase drops a pulse but the other one doesn't, that could look like a reversal. Also, if the external system input circuit debouncing/signal conditioning/whatever can't handle the higher speeds, the same thing will appear. If the apparent reversal is repeatable with a particular quick spin, a dual-trace capture could show the dropped pulse and confirm that the problem is in the encoder. If the system sees a reversal but the scope does not, then the problem is in the interface. Or something like that.

ak
 
Have you put a scope on the encoder output to verify it's dropping pulses?

Could be the encoder is working just fine but your uC isn't reading them fast enough or your denouncing method is too slow. Are you using interrupts or polling normal inputs?
 
strantor said:
Have you put a scope on the encoder output to verify it's dropping pulses?

Could be the encoder is working just fine but your uC isn't reading them fast enough or your denouncing method is too slow. Are you using interrupts or polling normal inputs?
Click to expand...

That's an excellent question. I did not design the software--That was done by the software group, I'm in the electronics group. The program is for a Xilinx Spartan (Opal-Kelly XEM3001 FPGA module) and I do not have access to the code. I will have to see about probing the outputs from the encoders to see if they are missing pulses, which could be due to the issues AK suggested (5 Hz output max). Quick math seems to put that at a little over 9 rpm (assuming 32 ppr). That sounds incredibly low to me. Did I screw up in my math?

32 pulses / revolution,
5 pulses / second = 300 pulses / minute

(32 pulses)/(revolution) * (1 minute)/(300 pulses) = (32 minutes)/(300 revolutions) = 9.375 revolutions/minute

If that's the problem, no amount of messing with the software is going to help.
 
I would be surprised if you can hit the upper limit of frequency by hand-turning. I haven't read the data sheet (I'm on my phone, sorry) and my experience is mostly with motor-mounted encoder, not panel knobs, so I might be speaking out of turn here, but seems to me that you would have to go out of your way to intentionally design an encoder to be that slow.
 
I didn't see the CPR table at the end of the datasheet, so my math is off. The mechanical limit is 300 RPM, times 32 CPR is 9600 CPM, divided by 60 is 160 Hz, or 3.125 ms per output pulse width, either up or down. I think this makes it even more possible that an overly aggressive debouncer is dropping pulses. With an FPGA, the encoder waveforms could be going into some gates to turn them into clock plus direction signals (which should be fast enough to keep up with anything), or they could go to a firmware CPU core that is executing 8051 or ARM assembler to do the interface in software running on firmware emulating hardware. Gotta love FPGAs.

ak
 
Hi,

Sometime a test tells you more than anything else can.

To find out the encoder pattern you can connect LED's or LED's connected with CMOS buffer gates. Turning the shaft reveals the pattern.

To find out the speed however you'd need to connect a dual channel scope to the encoder and turn the shaft and watch the output on the scope.
 
Can you say whether this encoder is being used for data entry, in which case missed steps may not matter. Or is it being used where missed steps will matter, such as a commutator? Nevertheless, 5 rpm is pretty slow and is pretty conservative for debouncing.

John
 
Unfortunately this is a fully built unit already and I can't really do any hardware hacks or breadboarding with it. I may be able to get a scope probe (or two) in somewhere to monitor the waveforms though.

I should be able to tell you. This device effectively syncs a strobing backlight with a camera shutter to catch "video" (or more accurately, a series of still images) of drops of liquid being ejected at a set frequency. The encoders select the frequency (usually in the tens of kilohertz range) and the delay of the camera shutter with respect to the backlight strobe. The encoders must increment the frequency by 500Hz accurately each detent. Right now it is very inconsistent, and if spun up quickly the frequency jumps around and even goes down.
 

Hi John,

That's actually a pretty good point. In most of the apps i intended to use one of the mechanical ones in, it would not matter too much unless the thing started missing steps on a regular basis which would make it annoying to use. Once in a while would not matter.
For example, i was going to use one for setting the frequency of one of those frequency generator chips. Each digit would be set individually, and if i turn the knob clockwise and most of the time the digit goes up one count, i dont think it would matter if it did not work once in a while as long as the next click did increment the digit. Maybe that will add more use life time to the encoder. I was a little worried about this wear out problem too, but hopefully that just means a skipped code once in a while.
I could always go to the switch route: one for 'up' and one for 'down', like setting an alarm clock, but the encoder seems to be the more modern approach.
 
You must log in or register to reply here.

Similar threads

S
  • Question Question
Is this an encoder?
Replies
6
Views
2K
stuhagen
S
E
  • Question Question
Switching negative voltages with a transistor (revisited)
Replies
7
Views
1K
shokjok
S
Tariff Updates from JLCPCB as of Today
Replies
1
Views
779
ZipZapOuch
Tarrifs from AliExpress
Replies
6
Views
3K
ahsrabrifat
A
A
  • Question Question
applying solder paste from a jar
Replies
4
Views
1K
Externet
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…