Codewheel Generator for Homebrew Optical Encoders
Tom2000
I just released a freeware Win XP/Vista program that generates
codewheel images and prints them to any home inkjet or laser printer.
With a good codewheel in hand, you can build your own optical encoder.
I tried to generalize the program to provide wheels for any
application. "Canned" wheel types are Unencoded (for single-track
quad encoders), Unencoded with Index Track (for robotics and quads
with an index pulse), Two-track Quadrature (for mechanical simplicity
in homebrew quad encoder designs, Absolute Position, both Gray code
and binary, and a user-defined type for apps I haven't considered.
The program can generate wheels from one to eight tracks, at
user-specified size and resolution.
My favorite feature is its automatic 1:1, no hassle printing. Want a
2" diameter wheel? Set it for 2" outside diameter, and the wheel
image will automatically print at 2" diameter. No muss, no fuss.
You can spec the wheel image's resolution to anything practical. If
you have access to better printers than you might find at home, or
want to produce your wheels via photolithography, you can export the
image as a .BMP file, as either a positive or negative image.
And did I mention that it's free? It's so free that I don't even have
any advertising on my web page.
Speaking of my web page, I think I should probably tell you where to
find it:
http://www.mindspring.com/~tom2000/Delphi/Codewheel.html
Go forth and build!
Tom
Phil Hobbs
> Howdy, Folks,
>
> I just released a freeware Win XP/Vista program that generates
> codewheel images and prints them to any home inkjet or laser printer.
>
> With a good codewheel in hand, you can build your own optical encoder.
>
> I tried to generalize the program to provide wheels for any
> application. "Canned" wheel types are Unencoded (for single-track
> quad encoders), Unencoded with Index Track (for robotics and quads
> with an index pulse), Two-track Quadrature (for mechanical simplicity
> in homebrew quad encoder designs, Absolute Position, both Gray code
> and binary, and a user-defined type for apps I haven't considered.
>
> The program can generate wheels from one to eight tracks, at
> user-specified size and resolution.
>
> My favorite feature is its automatic 1:1, no hassle printing. Want a
> 2" diameter wheel? Set it for 2" outside diameter, and the wheel
> image will automatically print at 2" diameter. No muss, no fuss.
>
> You can spec the wheel image's resolution to anything practical. If
> you have access to better printers than you might find at home, or
> want to produce your wheels via photolithography, you can export the
> image as a .BMP file, as either a positive or negative image.
>
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
Tom2000
<pcdhSpamM...@electrooptical.net> wrote:
>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.
>
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
Leon
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
Phil Hobbs
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
Tom2000
<pcdhSpamM...@pergamos.net> wrote:
>Tom2000 wrote:
>> On Thu, 05 Jun 2008 07:24:54 -0400, Phil Hobbs
>> <pcdhSpamM...@electrooptical.net> wrote:
>>
>>> 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.
>>>
>>
< 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
Tom2000
wrote:
>
>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
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
Leon
> On Thu, 5 Jun 2008 09:05:54 -0700 (PDT), Leon <leon...@btinternet.com>
I used the default values.
Leon
John Larkin
<pcdhSpamM...@electrooptical.net> wrote:
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.
Tom2000
wrote:
>On 5 Jun, 19:00, Tom2000 <ab...@giganews.net> wrote:
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
Leon
> On Thu, 5 Jun 2008 11:04:32 -0700 (PDT), Leon <leon...@btinternet.com>
Thanks, Tom. It works OK.
Leon
Spehro Pefhany
<pcdhSpamM...@electrooptical.net> wrote:
>Tom2000 wrote:
>> Howdy, Folks,
>>
>> I just released a freeware Win XP/Vista program that generates
>> codewheel images and prints them to any home inkjet or laser printer.
>>
>> With a good codewheel in hand, you can build your own optical encoder.
>>
>> I tried to generalize the program to provide wheels for any
>> application. "Canned" wheel types are Unencoded (for single-track
>> quad encoders), Unencoded with Index Track (for robotics and quads
>> with an index pulse), Two-track Quadrature (for mechanical simplicity
>> in homebrew quad encoder designs, Absolute Position, both Gray code
>> and binary, and a user-defined type for apps I haven't considered.
>>
>> The program can generate wheels from one to eight tracks, at
>> user-specified size and resolution.
>>
>> My favorite feature is its automatic 1:1, no hassle printing. Want a
>> 2" diameter wheel? Set it for 2" outside diameter, and the wheel
>> image will automatically print at 2" diameter. No muss, no fuss.
>>
>> You can spec the wheel image's resolution to anything practical. If
>> you have access to better printers than you might find at home, or
>> want to produce your wheels via photolithography, you can export the
>> image as a .BMP file, as either a positive or negative image.
>>
>
>Cool. Is the long-range accuracy of printers really good enough for this?
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.
>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
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"
sp...@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Tom2000
wrote:
>
>Thanks, Tom. It works OK.
>
>Leon
Outstanding! I hope you'll be happy with the program.
Tom
Phil Hobbs
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
TT_Man
>
> 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
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
bg
Phil Hobbs wrote in message <4847CD06...@electrooptical.net>...
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
Martin Griffith
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
bg
Martin Griffith wrote in message ...
bg
Mark
> >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.
============
> 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.
great idea...thank you!
Mark
christofire
"Martin Griffith" <mart_in...@yah00.es> wrote in message
news:bikh44d7t6l5tan5p...@4ax.com...
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
bg
christofire wrote in message ...
The magnetic pickup contains it's own magnet like a guitar pickup, and the
flywheel has to be ferrous like guitar strings.
bg
Martin Griffith
Rich Webb
<mart_in...@yah00.es> wrote:
>can it do this?
>
>http://www.telegraph.co.uk/news/newstopics/howaboutthat/2144652/Most-complex-crop-circle-ever-discovered-in-British-fields.html?=rss
Heh. Clever indeed.
--
Rich Webb Norfolk, VA
James Arthur
I get the rest, but where's the "3" ?
Cheers,
James Arthur
James Arthur
> Martin Griffith wrote:
>> can it do this?
>>
>> http://www.telegraph.co.uk/news/newstopics/howaboutthat/2144652/Most-complex-crop-circle-ever-discovered-in-British-fields.html?=rss
>>
>>
>>
>> martin
>
> I get the rest, but where's the "3" ?
Oops, got it. Doh.
--James
John Fields
<bogus...@verizon.net> wrote:
>Martin Griffith wrote:
>> can it do this?
>>
>> http://www.telegraph.co.uk/news/newstopics/howaboutthat/2144652/Most-complex-crop-circle-ever-discovered-in-British-fields.html?=rss
>>
>>
>> martin
>
>I get the rest, but where's the "3" ?
---
The innermost arc goes 3/10 of the way around the circle.
JF
James Arthur
Thanks -- I'd missed that.
--James Arthur
JSprocket
>>
>> I just released a freeware Win XP/Vista program that generates
>> codewheel images and prints them to any home inkjet or laser printer.
>>
>> With a good codewheel in hand, you can build your own optical encoder.
>>
Nice one, I've created them using FastCAD but this saves a lot of
hassle, especially for Gray encoders.
Just a little request: an option to fill the page by step-and-repeat
when printing?
JS
Rich Grise
> John Fields wrote:
>> On Thu, 19 Jun 2008 18:55:56 GMT, James Arthur <bogus...@verizon.net>
>>
>>>> can it do this?
>>>>
>>>> http://www.telegraph.co.uk/news/newstopics/howaboutthat/2144652/Most-complex-crop-circle-ever-discovered-in-British-fields.html?=rss
>>>>
>>>> martin
>>> I get the rest, but where's the "3" ?
>>
>
>
I once saw a thing on teevee where the two guys who had been making all of
the "crop circles" show exactly how they did it. It's trivially easy to
walk through a grain field like that without leaving a trace - just walk
between the rows. And you can make a perfect circle by standing a guy in
the center with a rope, and you can figure out the rest.
But even after seeing that, the True Believers refused to believe that
the "real" crop circles were a hoax. ;-)
I'm thinking of making sort of a mask of that Jesus pic,
http://www.eyetricks.com/jesus.htm ,
and scorching it into a tortilla, and sell it on ebay: "Jesus on a
tortilla Hoax!" - it'd probably sell for tens of thousands. ;-)
Cheers!
Rich
Tom2000
wrote:
>Just a little request: an option to fill the page by step-and-repeat
>when printing?
>
That feature occurred to me the first time I looked at that lonely
little wheel in the center of the page. Then I thought that it would
be hassle enough to make one encoder. Who would ever want more than
one copy?
After trying to punch an accurately-located center hole, though, I
quickly realized why someone might want more than one. (It took me
three tries.)
So, I'll consider the feature for a possible future upgrade.
Thanks for your suggestion.
BTW... a bit of irony...
I ordered some tiny SMD phototransistors from Electronic Goldmine to
use in my homebrew encoder. With the transistors, I also ordered some
junkbox filler parts to fill out the order enough to make the shipping
costs worthwhile.
One of the add ons was an assortment of pots, since I thought I'd be
tearing more than one apart before I figured out a good mechanical
codewheel mounting arrangement.
Included in the pot assortment were two quadrature encoders! One a
Clarostat 128 CPR encoder, the other a beautiful Bourns ball bearing
256 CPR encoder.
I hope to find time to test them this evening. If either of them work
(particularly the Bourns), I won't have to fiddle around with a
homebrew encoder.
So there's irony for you. I bought the pot assortment as a throw-in
of project parts, and acccidentally received encoders that might
eliminate having to build the project at all!
There must be a lesson there. :-)
Tom