HP / Avago Optical Codewheel / Sensor - Anyone used them?

Hi,

Has anyone here worked with the HP / Avago HEDS-9000-series (Sensor) and HEDS-5000-series (Codewheel) combination?

The reason I ask is that I’m involved in a project that uses this combo and we’re having issues with dropouts in the quadrature output waveform. The waveform on our 'scope looks nowhere near as clean as the one in the HP / Avago datasheet...

We have 4 different codewheels and 1 sensor (9100). They are sensitive to alignment, so we’re using both the alignment tools, for height and radius.

This product range has been in production for quite some time and I can’t envisage it being so if it’s as finicky about setup as it appears to be…

The engineer I’m working with (someone who knows a hell of a lot more about digital than myself!) can only suggest that it could be a faulty / static-damaged sensor (considering this is the first one we’ve purchased, from a statistical failure rate POV, it wouldn’t bode well if this were the case…).

HP / Avago’s technical support in the UK for this product line is pretty much non-existent by the looks of it. The staff we’ve spoken to have been helpful, but lacking in the specialist info we require for this range.

Has anyone here used this product-line? Not only have we checked alignment with the Avago-supplied gauges, but my associate checked the x/y coordinates via the digital meters on his mill – confirming supposedly perfect alignment in both axes…

From what I’ve seen, the Bourns optical encoders seem more popular in audio, but the resolution isn’t great (max 64 CPR?) and they’re expensive. The HP / Avago codewheel / sensor combo seems to get most use in electrical motor / position sensor (in theory, would make a superb coil winder…) apps, so one would tend to expect it to be rugged… Is there an elephant in our room that we can’t see?

If anyone could make a suggestion I’d be very grateful.

Thanks in advance,

Justin

Have you checked the radial alignment of the encoder wrt the code wheel? Also shaft eccentricity? They have some pretty tight specs listed in their datasheet on the codewheel for both eccentricity and axial play (probably creates a focus problem in the encoder). Also the usual suspects, clean power, ambient light interference, emi, etc.

Thanks for your comments, Burdij.

I've pasted this from an email sent to me by the engineer who's doing the work:

I actually got the alignment tool this morning.
The radial spindle-encoder alignment was spot on. I took another
0.25mm off your (axial) spindle position-locating collar and re-adjusted the wheel gap
with the other tool. With all this done, there's still some drop-out
etc. visible. I've got plenty of decoupling on the power
pins and 3k3 pull-ups on the outputs, a clean regulated 5V supply off my bench unit, so
every chance given to perform. I'll try with the other wheel - other than that
I wonder if the electronics could be slightly faulty ?
It'll be about good enough to drive the control board, but I'd not say it's great
performance, even now.

Click to expand...

:?:

Justin

[quote author="mediatechnology"]I have used these in an optical tach prototype I did for the MCI JH-Series. Mine were HP manufactured about 10-12 years ago. I found the quadrature to be quite clean. Do you suppose there is some kind of ambient light contamination?[/quote]

Hi,

We thought about this one because the wheel and sensor are contained in an enclosure made from plate alloy. However, it was concluded that the design of the sensor was such that this couldn't possibly happen...

Hmm... There are no other light sources in the enclosure.

Is contamination a problem you've witnessed?

Thanks,
Justin

Hi,

Since posting the original query, I now have an example of the controller wheel that uses the AVAGO pair of disc + optical sensor (same as posted in MT's photo).

So, it worked fine when it was posted to me by the engineer who programmed the code and designed the hardware for it... When it got to me, there were drop-outs...

I'm finding that I move the sensor by a nanometre and it drops out completely... Move it in another direction, again by a fraction, and it goes backwards!

I can align it to work perfectly, but this thing is so sensitive, I'm very worried about it playing up in the field...

We couldn't get it to work on HP's dimensional data (even when checked on a digital mill gauge - accurate to a micron), so we cut some slots so as the sensor could be moved. We can get it to work, but it's so twitchy...

These things are designed to be used in printers and the like - surely, they can't be that fiddly?

I can't help wonder if there's some kind of 'trade secret' to using these things, i.e. a way to work around a flaw that people know, but HP don't admit to... Am I being paranoid?

Anyone?

Thanks,
Justin

It is fairly common when interfacing controls to micro's to accommodate with software things like; dropouts, double hits, and sundry invalid input data. If it isn't robust on your bench it is not likely to be wonderful in the field.

I have seen improvements between proto and production from things like gold plated touch switch footprints vs. the tinned prototypes, so ambient light is a possible pre production variable, but it seems this would be addressed in data or application notes if problematic.

Does the data sheet mention missed codes?

Good luck..

JR

Thanks :guinness:

We have a selection of wheels. The one used at the moments is 200CPR.

Because we've tried 4 different wheels and 2 sensors, I am going on the basis that the obvious is alluding us... These parts wouldn't remain in production for so long if they were this idiosyncratic, would they?

The distributor knows less than we do to be honest...the technical guy handles many lines... They were kind enough to send us alignment gauges, but they seem to pose more questions than they answer... I'm wondering if we should've just gone for one of those one-piece optical encoders from Bourns, like Eventide use. They're pricier than the HP part, but the alignment's done for you...

Datasheet: http://www.farnell.com/datasheets/2616.pdf

http://www.farnell.com/datasheets/76714.pdf

Justin