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.

[boroko]

I remember reading somewhere that someone was having similar problems with printed disks. The issue was that since the detection was IR, the visible black was not being seen by the sensor. You might try something else for those detectors as a test, say stripes of black tape.

Just a thought.

Bo

[Acetronics2]

Hi,

Did you had a look to Parallax kit of 44 " stripes " wheel encoders ???

http://www.active-robots.com/products/motorsandwheels/nubotics-ww-01-wheelwatcher.shtml

look same as you try to do ...

Already working.

my two cents...

Alain

[Elnino]

I remember reading somewhere that someone was having similar problems with printed disks. The issue was that since the detection was IR, the visible black was not being seen by the sensor. You might try something else for those detectors as a test, say stripes of black tape.

Just a thought.

Bo

Yeah, i had thought of that but the size of my disks are only about an inch round OD - Pretty hard to do something like that by hand. Perhaps there are microscopic holes in the toner still letting the light through. I might pop one under a microscope at work and have a look. I also read somewhere else that when printing these, it can be better to print them on a colour laser printer but using CMYK to print it and not just the black. The theory there is more toner on the surface and it's more likely to block the IR. I might also give that a try.


Hi,

Did you had a look to Parallax kit of 44 " stripes " wheel encoders ???

http://www.active-robots.com/products/motorsandwheels/nubotics-ww-01-wheelwatcher.shtml

look same as you try to do ...

Already working.

my two cents...

Alain

Great find - i looked all over for something 'pre-fabbed' that was not too exensive but didn't find anything. Had i come across them before i might have gone that way, however i've now built the 'sensors' so i'd like to persevere with them for the moment.

[Acetronics2]

Ok ...

So ... The first good thing would be tho have access to the base of the phototransistor ...
just to make it less sensitive ... ( you've correctly read ).

Second ... SPEED ! Opto transistors really are lazy components ... I just dig into my docs to find an old 30 Years old Motorola scheme intended to make performances acceptable ...

Also consider Honeywell HOA 901 or equ. components ... worth the try.

Third: encoder Wheel ... did you try the transparent Polyester film for Inkjet Printers ???
... that's what I use for my PCB UV Exposure !!!

read you soon

Alain

[Macgman2000]

Oh been there done that. After a lot time in front of the scope I found the following issues when creating my own optical wheels.

1). photo transistor collector resistor if set too high will bounce output pulses. IE, it is too sensitive to ambient light. I suggest you take a black pen cap and poke a hole in the end facing the LED. This is just for a test to dial in the problem. Also try 4.7K~30K collector resistor using a 5v supply to stiffen the response to eliminate bounce. Try to change LED output level too. You will find through paper the difference between thresholds is very narrow, see point number 2 below if that is the case.

2). IR goes through paper even printed with black ink. The best optical wheel is one made of 0.020 black plastic or better yet aluminum with windows for stripes.

3). Try edge reflection rather than break beam. The problem will be how thin the stripes are on the disk. The finer you go the more likely you need surface mount parts with reduced photo transistor sensing area and narrower LED output. You will need a pin point light source/detector. I made quite a few with surface mount, the challenge is alignment affix all optics to the same board and space correctly.


Nick

[Elnino]

Thank you all for your input. It seems this was never going to be as easy as i initially thought.

I have not had much chance to play with the setup just yet. I have been concentrating on trying to print better disks. If the toner is totally opaque, it will block IR.

Alain you may use this method for UV exposure of your boards but UV is at the other end of the spectrum to IR. We can't really expect them to perform the same.

I have a 10k resistor on the collector of the transistor now, and as i have stated before, this setup works perfectly with other objects breaking the beam. No silly mass counts or bouncing of the circuit. The only other thing i thought of (and what nick just mentioned) was to reduce the intensity of the IR LED to see if it is less likely to penetrate any flaws in the toner (at least limit it enough to keep the transistor off).

Failing that, Although super awkward for something this small, i'll probably have a shot at aligning 2 disks as Al mentioned earlier.

I'm almost there - I don't really want to go to a full re-design of the sensors just yet...

[Elnino]

Ok, so i stuck one of my disks under the microscope and to be honest they look pretty darn good! The toner is solid and the edges are a little 'furry' but only about 1 micron (1/1000mm) is furry. I doubt many commercial encoders would be much better.

There were a couple of sub micron holes but this particular disk had not been cared for - it was one of my test ones. I doubt they would have any effect anyway.

So, where does that leave me? Well, it means doubling the disks is probably pointless but making the clear slots smaller might be of some help. I sincerely doubt that a 1 micron 'edge' is going to cause a problem for a sensor that is likely to have a beam width of probably at least 10 times that.

[Elnino]

Ok, so i've managed to have a bit of a play with my encoders - hardware and software and managed to get it 'smooth'.

I changed from disks with 6deg clear and 6deg black to 2 and 10deg. This made a big difference but did not resolve the problem.

I also printed these disks in colour but they are still black. The PS file i have for making the disks orgininally printed black. I changed it to print colour but all levels are 0 so it prints black but with the CMY colours. This makes for a much denser print.

On top of that, a simple 2ms pause at the top of the ISR before reading the port gave it sufficient time to settle in either an on or off position.

Problem solved! Thanks to all that helped me out.

Andrew