Codewheel Generator for Homebrew Optical Encoders

[Tom2000]

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.

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]

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?

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]

On Thu, 05 Jun 2008 07:24:54 -0400, Phil Hobbs
<pcdhSpamMeSenseless@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

 

[Phil Hobbs]

Tom2000 wrote:

On Thu, 05 Jun 2008 07:24:54 -0400, Phil Hobbs
pcdhSpamMeSenseless@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

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]

On Thu, 05 Jun 2008 12:34:34 -0400, Phil Hobbs
<pcdhSpamMeSenseless@pergamos.net> wrote:

Tom2000 wrote:
On Thu, 05 Jun 2008 07:24:54 -0400, Phil Hobbs
pcdhSpamMeSenseless@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>

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.

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]

On Thu, 5 Jun 2008 09:05:54 -0700 (PDT), Leon <leon355@btinternet.com>
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 5 Jun, 08:10, Tom2000 <ab...@giganews.net> 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.

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

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

 

[John Larkin]

On Thu, 05 Jun 2008 07:24:54 -0400, Phil Hobbs
<pcdhSpamMeSenseless@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?

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 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]

On Thu, 5 Jun 2008 11:04:32 -0700 (PDT), Leon <leon355@btinternet.com>
wrote:

On 5 Jun, 19:00, Tom2000 <ab...@giganews.net> wrote:
On Thu, 5 Jun 2008 09:05:54 -0700 (PDT), Leon <leon...@btinternet.com
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

I used the default values.

Leon

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

 

[Spehro Pefhany]

On Thu, 05 Jun 2008 07:24:54 -0400, Phil Hobbs
<pcdhSpamMeSenseless@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"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

 

[Tom2000]

On Thu, 5 Jun 2008 11:48:24 -0700 (PDT), Leon <leon355@btinternet.com>
wrote:

Thanks, Tom. It works OK.

Leon

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

Tom

 

[Phil Hobbs]

John Larkin wrote:

On Thu, 05 Jun 2008 07:24:54 -0400, Phil Hobbs
pcdhSpamMeSenseless@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?

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 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.

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

 

[Leon]

On 5 Jun, 19:00, Tom2000 <ab...@giganews.net> wrote:

On Thu, 5 Jun 2008 09:05:54 -0700 (PDT), Leon <leon...@btinternet.com
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

I used the default values.

Leon

 

[Leon]

On 5 Jun, 19:16, Tom2000 <ab...@giganews.net> wrote:

On Thu, 5 Jun 2008 11:04:32 -0700 (PDT), Leon <leon...@btinternet.com
wrote:



On 5 Jun, 19:00, Tom2000 <ab...@giganews.net> wrote:
On Thu, 5 Jun 2008 09:05:54 -0700 (PDT), Leon <leon...@btinternet.com
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

I used the default values.

Leon

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

 

[Martin Griffith]

On Thu, 5 Jun 2008 18:50:33 -0600, in sci.electronics.design "bg"
<NotValid@NotMe.com> wrote:

Phil Hobbs wrote in message <4847CD06.6050703@electrooptical.net>...
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?

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

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

 

[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

 

[Rich Webb]

On Thu, 19 Jun 2008 19:32:04 +0200, Martin Griffith
<mart_in_medina@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]

Martin Griffith wrote:

On Thu, 05 Jun 2008 00:10:17 -0700, in sci.electronics.design Tom2000
abuse@giganews.net> 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.

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


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" ?

Cheers,
James Arthur

 

[James Arthur]

James Arthur 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" ?

Oops, got it. Doh.

--James

 

[John Fields]

On Thu, 19 Jun 2008 18:55:56 GMT, James Arthur
<bogusabdsqy@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