Home made optical rencoder issues

[Elnino]

Hi all, I'm hoping for a little input on where i might be going wrong with my latest project using some home made optical encoders.

My pic is a 16f628a and i have 2 sensors generating interrupts on portB. i.e they are not quad or grey output - just a single opto sensor each with no direction. Each increment a counter which is displayed on a LCD.

The code appears fine, the sensors work but not quite as they should. It could be a problem with my encoder wheels but here's what happens:

Without the chopper disks, if i break the beam on the sensor with something opaque, i get an increment of 1 on the counter and same when the beam returns to unbroken. This works as expected. If the sensors are left alone, i do not get any increment. With the encoder disks in place i can rotate them at pace and get believable increments. My encoders are ~50 pulse/rev and i can get about 50 pulses if i manually rotate it about 360 degrees.

My problem is when i rotate them slowly - i.e just a small movement might increment the counter by 10 or 20. My assumption is that the sensor is on the edge of the opaque bit on the encoder and 'flaps' a bit. But, i do not get this when i manually break the beam which seems odd.

The encoders are printed with a laser printer on transparency film and are only 23mm diameter. The marks are very opaque and the on/off time is uniform. The Sensors are RS 306-061 (now discontinued but i had a heap of them).

So, from what i can see i have a few options:
I can reduce the 'on' time by using a sensor that has much less clear than opaque, reducing the edges somewhat
I could introduce some sort of 'debouncing' in my code to prevent flapping on the edges (could mean missed pulses but the application is slow speed)
Some other code change?
Try printing the disks on a different/better printer
Move the encoder disk closer to the transistor side of the sensor?
Is there a change to the circuit i could make that will help?

I'm after general comments from people that might have had some experience with this sort of thing in the past.

My interrupt routine (modded version of someone elses on this forum)...

Rot_Encoder:
     New_Bits = PORTB & (%00110000)
     ' which encoder changed
     IF (New_Bits & %00100000) = (Old_Bits & %00100000) then No_Change_Rot1
     RotEnc1_val = RotEnc1_val + 1
     
No_Change_Rot1:
     IF (New_Bits & %00010000) = (Old_Bits & %00010000) then DoneRotEnc
     RotEnc2_val = RotEnc2_val + 1

 DoneRotEnc:
     Old_Bits = New_Bits
@ INT_RETURN

Pic of sensor schematic and example encoder disks attached...


P.S If anyone wants the .ps file i use for creating the encoder disks, let me know...

[Bill Legge]

I spent quite some time fiddling with home made units - got them working in the end:

1. Whilst the disks may have nice sharp/defined edges, the light source and detector probably occupy some 'area' and are not 'points.' so the interrupt is not a clean ON/OFF?

2. In one application I used the MC14490 de-bounce chip (Cost about $3 with 4 channels with internal pull-ups) and my problems went away - application was a tipping bucket rain gauge.

3. In my home made motor feedback project I had to 'sharpen-up' the pulses by using a 74LS14N Hex inverter Schmitt chip. The OSMC DC motor driver sprang into life and I had proper closed loop speed/position control.

4. Can you used some square wave source to emulate the interrupter to find out if it's dirty pulses or a frequency problem?

I've not used any software de-bounce but presume its fine as long as the delay is acceptable and info is not lost?

Good luck - let me know how you get on.

Gerards Bill Legge

[Elnino]

Thanks for the reply Bill, It looks like this might be more of a problem than i anticipated. I tried putting the disks closer to the photo transistor in hope that it might produce a squarer signal but that did not work.

supplying a square wave to the chip works fine. Even manually pulling the pin low with a mechanical switch does not produce unwanted pulses!

I might also try increasing the value of the pullup resistor so that it is much easier for the transistor to pull the pin low. I read on here someone using the sensors from an old ball mouse had to go in the order of 10m to get to pull low at all. These sensors are more sensitive/powerful but it might help reduce the issue of non-saturation of the transistor on the edge of a trigger point.

If all else fails i'll have to look at one of the chips you mentioned. I don't really want to go adding debouncing to the code and miss pulses at higher rpm.

Thanks for the input!

Andrew

[mackrackit]

Does the black portion of the disk completely cover the receiver and then some?
Use a very small clear opening and a wide dark for slow apps, also works for high speeds too.

[aratti]

Without the chopper disks, if i break the beam on the sensor with something opaque, i get an increment of 1 on the counter and same when the beam returns to unbroken. This works as expected. If the sensors are left alone, i do not get any increment. With the encoder disks in place i can rotate them at pace and get believable increments. My encoders are ~50 pulse/rev and i can get about 50 pulses if i manually rotate it about 360 degrees.
My problem is when i rotate them slowly - i.e just a small movement might increment the counter by 10 or 20. My assumption is that the sensor is on the edge of the opaque bit on the encoder and 'flaps' a bit. But, i do not get this when i manually break the beam which seems odd.

That simply means that your disk is not sufficiently opaque. Tray with two disks one on top the other (even three if you have room), this will increase the opacity by a factor of 2 or 3.

Al.

[Elnino]

thanks for the input people, i really appreciate it.

I am going to try printing them on another printer first. The other one i have is a Xerox which has the ability to 'pile on' the toner and make it really thick. The other hp laser i have is a little on the pathetic 'economy' side.

The awkward thing is, the data sheet does not really give specifics on the working area of the sensor, only where the optical center of it is. i.e it does not tell me the minimum width over the optical center to sufficiently break the beam.

I think i should be able to get it to work without any extra electrics or de-bouncing but it might take a bit more trial and error. I don't think its a debouncing issue as it does not bounce when i break the beam with something random - even a piece of torn off paper seems to be fine... It mush just be my dodgy disks.