Codewheel Generator for Homebrew Optical Encoders

Cool. Is the long-range accuracy of printers really good enough for this?

I'd expect that one serious limitation with homemade encoders is that it's really hard to get the disc centred on the shaft accurately. A very cool addition to the program might be to use the sound card to look for phase modulation in the detected photocurrent, and compute how far, in which direction, to adjust the centering. A few iterations of that, and it ought to be possible to get 1-pixel centration, or even better on average.

Cheers,

Phil Hobbs

Phil, I'm sorry, but you've totally lost me here.

Printing the wheel is a passive, one-time thing. For the life of me, I can't figure the dynamics that would bring a sound card into the equation.

If you're talking about adjusting centering when the wheel is mounted on the shaft and, somehow, adjust the centering on the fly, that would be one incredibly complex mechanical assembly. Somehow, I don't think that's what you have in mind.

And if there is a centering error, it will show up, with respect to the photosensor, as a vertical displacement. Unless your tracks are hair-thin, the sensor will never notice it.

So, could you please expound?

Thanks,

Tom

I just downloaded it and tried it. It seems to have a bug - I always get "Missing or invalid track data" when I click on the Preview button or try to print it..

Leon

The accuracy of the encoder is critically dependent on how accurately it is centred on the shaft, because the optical sensor isn't sensing angular motion directly--it senses the passage of a pattern edge, and it's up to the code wheel to turn the one into the other.

Say you have a simple pattern of N black wedges equally spaced in angle about a centre, and that the optical sensor is exactly 1 cm from the shaft axis, in the x direction. Now imagine that you mount the code wheel dx centimetres off centre, also in the x direction. (The choice of directions doesn't matter, but it makes the discussion more definite. Imagine dx being, say, 0.25 cm to make it visually obvious.)

Near theta=0, the period of the wedges is (2*pi/N)(1-dx), because the centre of the pattern is (1-dx) cm from the sensor. Near theta=pi, the period of the wedges is (2*pi/N)*(1+dx), because the centre is now 1+dx cm from the sensor. Thus for a constant rotation rate, the frequency of the signal from the encoder will go from 1/(1-dx) to 1/(1+dx) times the true rate--which is FM with a modulation index of dx/(1 cm). If you're assuming that the encoder resulting from your code wheel will have one-pixel accuracy, that requires a similar accuracy of centration.

The p-p phase deviation and the modulation phase (0 degrees in this case) are directly related to the centration error, so by running the shaft at a constant rate and using a sound card to digitize the resulting encoder signal, and then doing some fairly simple signal processing, it would be possible to say, e.g. that the coding wheel was

0.05 mm off in a direction 39.5 degrees counterclockwise from the index hole. A slight set-screw motion or a thin shim would correct this, and the second try would be much closer. There are similar effects from tilting the code wheel, but they're quadratic instead of linear. You can sort those out because they have a period of a half cycle instead of a full cycle, so it's even possible to calculate both from a single run.

Alternatively, one could produce a calibration table that gave the actual shaft angle as a function of apparent shaft angle from the encoder output. That would allow a more rigid mount, and probably less drift over time.

There are other sources of error in this calibration that would need thinking about, e.g. cogging in the motor and defects in the bearings, but in general they'd wind up producing different modulation frequencies, so they wouldn't be too hard to tell apart.

Cheers,

Phil Hobbs

< My stupid question skipped>

Phil, that is a superb explanation. Thank you! I haven't the heart to snip even a word of it.

Now I see what you mean: using the sound card to do a systems test on the mounted wheel.

I had no idea that the wobble was so critical, but you've certainly demonstrated that it is.

I need to re-consider my quad encoder design -- a 250 cell 2-track quad wheel with the hole punched by eye using my Harbor Freight hand punch. Right off the bat, I think that I'll need to develop something better.

Again, many thanks!

Tom

Hi, Leon,

That error message tells you that you've made an error in your track data entry.

My guess is that you have one or more blank track boxes without the "No Code" box checked for that track.

If that isn't the problem, and you can't resolve the cause of the error, please post

- the wheel type

- the number of tracks

- for each track data box:

- what you've entered in the track data box

- whether or not the No Code box for that track is checked.

Thanks!

Tom

I used the default values.

Leon

I had this idea once: mount a piece of photographic film on the shaft, maybe on glass. Spin it in a high-mass/low jitter system, phaselock to the spin rate, and modulate a laser or led to expose the film, many revolutions to average things out. Develop.

There are some diazo-based plastic films that are interesting for things like this. [1]

Hmmm, is there such a thing as a circular/radial interferance pattern?

John

[1] I once designed some roller-machine electronics and flashtube stuff for Kalvar. They have an interesting film, based on exploding micro-bubbles from diazo gas release. The result is optically diffusive, as opposed to silver which is absorptive. Resolution is pretty good, with no developing needed.

Ah! There's the problem.

The default values don't fill the track data boxes. (Those are the boxes that appear in the lower section of the screen, the number usually corresponding to the number of tracks you selected.)

For each of the displayed track data boxes, you need to enter either a value or you need to check the No Code checkbox for that track.

And you must enter a value in at least one of the track data boxes.

For example...

Let's say you've selected the Unencoded wheel, and have specified three tracks.

You'll see three track data boxes and three No Code checkboxes displayed on the lower area of the screen.

The No Code checkbox for the first track is grayed out, so for that track, you must enter the number of cells in the first track box. Type in something like 50 or 100.

For the next two tracks, you have the option of typing in a value (to generate a coded track) or checking the No Code box (to genrate a blank track). Try checking both No Code boxes.

When you now hit the Preview button, or try to print, you'll see an image of a wheel having a single track, out near the periphery of the wheel, with blank space between the track and the inner diameter circle.

If you're still having difficulty, please post the details of your setup.

Thanks!

Tom

Thanks, Tom. It works OK.

Leon

Depending on what you mean by "printer". I've done this with output on film from a Linotype. They have to be pretty good for 4-color registration. Absolute accuracy (or at least repeatability) is more important for linear encoders than for rotary encoders.

Nice idea.

High resolution encoders can use interference of two patterns and digitize the resulting analog quadrature signal to yield much higher resolution than a crude digital encoder. Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Outstanding! I hope you'll be happy with the program.

Tom

Kalvar was considered for an early IBM photo storage system, but wasn't stable enough. It's probably got better since then.

I don't know of a way to make really radial slices--most of the things that come to mind will produce a family of hyperbolas instead. Exposing things in situ is a good technology--that's more or less how self-servowriting in hard disks works.

Cheers,

Phil Hobbs

SNIP

I'm sure for the average hobbyist, this method and any offset is perfectly tolerable. Well done! For those purists who find it inadequate, go and buy one. For me, this is a dream come true in making a simple shaft encoder for rotary jack screws. RPM is about 5-10 and 10 steps per rev on a 1" disc will be more than adequate.10/10

The encoders for capstan motors used in high end recorders like studer and ampex used to put two sets of optics 180 degrees apart. As one side of the encoder sped up , the other side was slowing down. Speed accuracy was around point one percent (I think). I used a tool makers microscope to remount the encoders when they'd fall off. bg bg

Up to the A80, Studer used inductive pickups with grooves on the capstan motor rotor, not optical methods. I think the A800 was the same, but never did much with them

martin

this?

around

the

I forgot, it's been awhile! bg

============

great idea...thank you! Mark

The more-domestic A77 was the same. The rim of the pressed metal external rotor of the capstan motor had been punched inwards with a narrow rectangular tool, every 5 degrees or so, so to the adjacent pickup electromagnet it presented a square wave of reluctance as it rotated. What I can't remember is whether the rotor was made from aluminium alloy or steel - I guess it could have been either because a practical armature for an induction motor requires both. Also, was the core of the electromagnet a permanent magnet, as in a guitar pickup? ... and would that work with an aluminium rotor?

I'd need to move loads of boxes to get to the one I was given by John Fox when he retired. I'll let you know if I get round to it.

Chris