Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Switching from Mechanical Encoder to Optical Encoder

Status
Not open for further replies.
Matt, I agree with the diagnosis that the debounce may be too slow. Is debounce needed with that encoder? I have an Avago HRPG-ASCA #14F made for HP. It does not require debouncing and the transitions are very clean on a scope. This Avago application note PEX8509 seems to be on topic, but after several tries to download it this morning, I gave up. All I got was an acknowledge from the Avago site thanking me.

Now, I understand that you may not want to tell the boss that the other engineers are all wet ;), but if there is time-delay debouncing for a mechanical encoder, that may not be appropriate for an optical device. Thinking just hypothetically and with no device in mind, consider a mechanical switch . A typical debounce for a mechanical switch on change in state may wait 10 ms to see if that state is stable. From what I have seen on a scope, a 10 ms wait may be way too long for an optical encoder. If it is looking at states, 300 rpm =5 rps that x32 = 160 pps or 6.25 ms/pulse. So, at maximum rotation speed, you may still miss transitions (Sorry to repeat what others have already said. I wanted to be sure the specific numbers were here.) Can you find out just what was done to debounce?

John
 
Hi Matt,
A few years ago I built a piece of test equipment that will count and display the number of pulses from a quadrature encoder. This is the schematic. If it is any use to you for testing I can post a link to the source and HEX code



**broken link removed**
It was actualy built to simulate the signals from iGaging linear scales.

Les.
 
Now, I understand that you may not want to tell the boss that the other engineers are all wet ;), but if there is time-delay debouncing for a mechanical encoder, that may not be appropriate for an optical device.

While I normally try to find solutions that I can implement personally, I will tell the bosses if the changes are out of my hands and need to be made by the software guys. This is a newer version of the test equipment that will replace the older boxes out on the testing floor, so I can't imagine a small change to the software is out of the question. I just can't be the one to make it.

Thanks everyone for your help. I'm still not sure the debounce would be the cause for inconsistent increments though. That seems like more of a hardware issue....?

EDIT: Actually, thinking about it if the debounce delay ends after the knob has started turning, it would lop off a few of the pulses it received during the debounce period, leading to inconsistent measurements. The issue may lie fully in software after all.
 
I've experienced exactly the kind of problem you've described, and it was due to an excessively long debounce time in the software. Debounce isn't even necessary in a quadrature encoder, because any contact bounce will inherently resolve itself. However, software people who are accustomed to debouncing mechanical switch inputs as a matter of course, probably did it without realizing it was unnecessary.
 
Debounce isn't even necessary in a quadrature encoder, because any contact bounce will inherently resolve itself.

Don't think so. If the two encoder outputs are arbitrarily assigned the functions of clock and direction, then bounce on the one going to a clock input will cause false increments. An interlocked dual-flipflop circuit can prevent this, but that circuit rarely is used.

ak
 
Okay, I guess it depends on how you read the encoder. When I code these, I detect all transitions of the encoder signals. If one input bounces a few times while the other signal remains unchanged, then the count simply oscillates by one count until the input finally settles, and the final count will be correct.
 
That decoder has an ASIC (application Specific Integrated Circuit) in it, thus I would expect the edges to be clean and debounced. The push button would not be.

I think have seen small caps placed across the phase A and phase B "contacts".

I would probe for clean sharp edges of A and B.
 
This morning, the downloading facility at Avago is working. The previously referenced document PEX8509 (post #41) does not apply to its optical encoders, and its datasheets for those encoders are not contributory to the question. However, this datasheet from Bourns is explicit that its optical, incremental encoders do not require debouncing: https://www.bourns.com/docs/default-document-library/enc1j.pdf?sfvrsn=0 From personal experience with the Avago reflective and the Bourns, the transitions viewed on an oscilloscope do not show bounce. Of course, I suspect that comment does not apply to any mechanical switch in the encoder.

John
 
This post has been bouncing around between my lobes for a few days and it sounded really familiar. I remembered experiencing this exact same issue, but couldn't put a finger on when/where until now. I still strongly suspect you issue is in software/debouncing, but since nothing's confirmed, I went ahead and dredged my archives and found the evidence.

FWIW here are some pictures of what a bad encoder signal could look like, to give you the symptoms you're experiencing:
A-Channel:
IMAG0403.jpg
B-channel:
IMAG0404.jpg
A- & B-channel:
IMAG0405.jpg

And here's a picture of a good output signal from an identical encoder that isn't screwed up:
IMG_0251.JPG

These came from a huge guillotine-style mattress-making bandsaw. Imagine a big carousel (merry-go-round) but instead of fiberglass horses on it, huge foam "buns." They go around 1 rev and all get cut, then the saw lowers 6"-10" (whatever the thickness of a mattress is), and they go around again, repeat. The giant bandsaw straddles the merry-go-round, and moves up/down on two big screws. These encoder waveforms came from the encoders on each lifting screw, that keep track of height/position. Position reference kept getting screwed up on one side; While travelling stead in one direction, position readout would go up, stop, go up, stop, go down, stop, go up, go down, stop.... and that's what I found. I didn't dissect the encoder to find out what was wrong with it but I suspect there was an internal short (channel-channel, and channel-ground), such that when only 1 channel was high, it didn't have enough power to output full voltage. Replacing the encoder fixed the problem.
 

Attachments

  • IMG_0251.JPG
    IMG_0251.JPG
    1.7 MB · Views: 234
This morning, the downloading facility at Avago is working. The previously referenced document PEX8509 (post #41) does not apply to its optical encoders, and its datasheets for those encoders are not contributory to the question. However, this datasheet from Bourns is explicit that its optical, incremental encoders do not require debouncing: https://www.bourns.com/docs/default-document-library/enc1j.pdf?sfvrsn=0 From personal experience with the Avago reflective and the Bourns, the transitions viewed on an oscilloscope do not show bounce. Of course, I suspect that comment does not apply to any mechanical switch in the encoder.

John
I am sure that old adage, you get what you pay for applies here. Spend a little more cash for good quality encoders. Those cheap ones found on the net are really sub-par and the bounce is pretty apparent.
 
Do you consider an optical encoder for $5.75 each, including S&H expensive or cheap? That is what I paid for the Avago encoders mentioned above and they work just fine. No bounce.
John
 
Thanks very much everyone. I think you guys have probably found the problem: The debounce delay. It makes complete sense to me. Unfortunately it looks like the person who wrote the VHDL for the Xilinx FPGA was a contractor, so I'll have to contact him and see how difficult (and costly) it would be to update the software to eliminate (or at least significantly reduce) the delay. If it turns out that it would be more expensive to have him do that and have us release a new version of the software than to simply keep replacing the worn-out mechanical encoders, we'll just stick with the mechanical ones. Thankfully I had the foresight to leave in support for mechanical encoders (pullups, mainly). We'd have to change the cables since the encoder pinouts are different, but that's not a huge deal.

Thank you everyone for your help, I expect that the debouncing is indeed the problem.

Matt
 
I recently acquired some of those cheap encoders off of Ebay (to help my 30 yr old son with music synth project), and the bounce was pretty awful (see attached waveforms). I implemented some hardware debounce using some programmable logic. So depending on your application, you may or may not care about bounce, but here is my hardware solution (I'm sure I will get some flak for the use of all the glue logic when it could be done with firmware).

Here is screen capture of the bounce.
pic_30_4.png

After some debounce added:
pic_34_3.png

My logic Diagram:
debounce2.PNG

Some my screen captures:
pic_34_10.png CW direction
pic_34_12.png CCW
 
Do you consider an optical encoder for $5.75 each, including S&H expensive or cheap? That is what I paid for the Avago encoders mentioned above and they work just fine. No bounce.
John

The optical encoders I selected are $30.90 each in one-off or $26.83 each in 25 qty from Mouser.

Knowing that $5.75 encoders don't bounce makes me feel more comfortable about seeing if the contractor will remove the debounce code.
 
Ouch, that's pretty awful. What encoder did you use, and how much did it cost?
The ones I got were el-cheapos from ebay, no part number or data sheet. 10 for $7.00, I would only use these for hobby use, never a production item as I am sure the operating life span will be short.
 
The ones I got were el-cheapos from ebay, no part number or data sheet. 10 for $7.00, I would only use these for hobby use, never a production item as I am sure the operating life span will be short.

Ah, that explains a lot! 70 cents each :eek:
 
I am sure that old adage, you get what you pay for applies here. Spend a little more cash for good quality encoders. Those cheap ones found on the net are really sub-par and the bounce is pretty apparent.

Hi there,

I have gotten some very cheap ones, like one doller (USD) each or something like that. They are mechanical, and i find that the only problem is getting the right software to match the encoder. Once i got the software and modified it as per suggestions right here in ETO, it worked every single time with no missing codes. I was actually very surprised that it could work that well.
Mine have 10k pullups on the clock and data lines, but in software both lines are treated the same...no preference for either one. I can post the code if anyone wanted to see it, and the encoder code pattern.
I also found that there are at LEAST two different code patterns for the mechanical encoders, and of course there could be more as i only had two different models to test.

I have also had some thoughts on "debouncing" these things, and i put that in quotes because i have to wonder if we really need this or not. I think we do need some debouncing when the encoder is read in software, but maybe not when it is done in hardward.

If we think about it step by step, it may be easier to understand.
The first thing that happens is the first switch closes, and that generates an interrupt. Now if we are using two interrupts (one for each pin) then we know already which pin started the sequence. It doesnt matter if that one bounces, because we have all the informaton we need from that one pin so far.
Next, we have to read the other contact or wait for another interrupt. Say we read it. If it reads low, then we know the sequence: the sequence was SW1 then SW2. There's no need to wait for anything else because we know what the sequence is.
There is a catch however, and that is if the bounce of the first switch was too long and we turned the shaft too fast, we might be already waiting for another interrupt, and that bounce may look like another interrupt. This means we'd need some time to wait, and i would call that the debounce time.

This is similar to debouncing a single push button switch: we wait for a change, and any change means it was pressed, then wait for some reasonable time after the state goes back to 'open' before we look for another change.

I cant say that all encoders will work like this of course because i only have experience with two models so far. They both work almost the same, except the switch pattern is different over one rotation.
 
There is a catch however, and that is if the bounce of the first switch was too long and we turned the shaft too fast, we might be already waiting for another interrupt, and that bounce may look like another interrupt. This means we'd need some time to wait, and i would call that the debounce time.
Agreed, during my testing, I found that playing with my sample clock affected the speed at which I could spin the encoder, but if the sample rate is too high, then you may trigger on a bounce. So it is a trade off.

At this point, I do not know if I care about the bounce or not, but I just don't like having the bounce in there, especially if I can fix it with HW. :)
 
Mikebits,
It is a bit confusing. Are you referring to mechanical encoders, and are your data from a mechanical encoder? Or, are you referring to optical encoders, and are any of your data from an optical encoder -- one that you are sure was an optical encoder?
John
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top